[FILLED] Looking for artist(s) to develop new style for A Valley Without Wind.

[x4000]

Whew!  Step away for a few days and miss a lot.

Okay, I've skimmed a lot of this thread, and have a few things to add/say.  If there are any pressing questions that folks have that I miss here, please feel free to repeat them as I simply didn't see them:

1. In general, there are two approaches we are considering: "articulated sprites" which are basically procedurally animated.  And in that case they would be packed in a dictionary much more like what Bluddy is suggesting.  The alternative is full-frame pixelart sprites but at a lower resolution, in which case we'd keep to the general approach we have now.

2. The question of graphics formats is irrelevant, as unity 3D only supports runtime loading of PNGs.

3. At this time we have contracted three separate studios to do prototypes of what the game would look like with a re-skin.  We'll select one of these to go to the kickstarter with, and that will be "the style going forward" for the game if the kickstarter succeeds.

4. Keeping the old art available is something that we will of course do, but we will not be including it within the game anymore.  And it's possible that it may very well become incompatible with the game if we massively change the resolution, or move to articulated sprites, or even just change the number of frames being used.  In fact there's quite a good chance that most of that art wouldn't even be able to function with the game in its revised state, the more I think of it.

5. A lot of that comes back to the fact that this is not a skin-deep cosmetic change.  One way or another, this is also going to have a number of technical consequences on our render pipeline, and I strongly suspect that this will also impact our gameplay and enemy design going forward, as well.  We've trended toward having (by game standards) really enormous foes, and I feel like that has a lot of drawbacks from a gameplay standpoint as well as from an artistic standpoint (many times you can't even see but a tiny part of the foe you are fighting).  That's not to say there would be no massive enemies, but that they would be used more sparingly -- hello overlords, etc.  I think a lot of inspiration from the older Metroid and Megaman and even Mario games is in order here.  Heck, actually most any game I can think of that is a platformer, come to that, tends to have enemies that are mostly the size of the player or 2x that size at most.

6. Most likely we will make some changes to viewport functionality despite my previously having said that would never happen; scaling everything so people get a more consistent viewport regardless of their screen resolution would solve a number of issues (again more of a gameplay nature rather than an artistic one, although also an artistic one).

7. Currently two of the studios we have contracted are working on what is primarily pixel art (with some bitmap-style art for the backgrounds) at a lower resolution.  The third studio is working on articulated painterly sprites at something a lot closer to the current resolution.  I have no idea which will win out, it all depends on the final results; I have high hopes for them all.

8. If we go through an overhaul of this nature, it's going to invalidate all existing tilesets most likely, but it won't prevent anyone from making new tilesets just like they can now.  What we're talking about here is really a v2 of the entire concept of the visuals of AVWW.  The scope of this is enormous -- well over 4,000 pieces of existing art to convert (though not really quite all of those, since many of the particle effects will be left alone I think), and not only do we have to think about the time and cost of this initial conversion, we also have to think of the ongoing costs of supporting the new content as we add more stuff to the game.  Thus only if the kickstarter succeeds in being funded or we fall into a LOT of money will this go ahead.  But I am confident we should be able to make a pretty darn compelling kickstarter.

7. In the short term this does take away some of my capacity for work on AVWW and otherwise, because I have to see to the art as it is progressing and discuss with now three studios for the art.  However, within a month or two this should actually be a time savings instead, because they'll be used to me and I'll be used to them (whichever studio we continue on with, if the kickstarter succeeds), and I'll no longer have to spend any of my personal time on making art for the game.  That's variably between 10% and 30% of my personal time on this project, depending on what exactly we're working on at a given time, and all of that time of mine will suddenly be freed up if we're able to move to this sort of process.  So we'll be able to do a lot more, not less.

8. This will in no way impact the coming of another AI War expansion, either.  We'll have more news on that front in early August, when we expect to start development on that one; that one is going to be pretty much Keith's show, which should be happy news to everyone since his have been the most popular features of the game since I laid down the core game itself.  I will be acting in more of a support role on that particular expansion, so that I can continue to have my core focus be on AVWW.

I hope that helps to clear some things up!

[eRe4s3r]

@ Bluddy
You are right I always forget that if you don't use DDS what you end up with in memory is a blob of uncompressed image. But with DDS compression I meant that we could use DDS files and a proper engine would load them and use them WITHOUT uncompressing them ;p That is the entire point of the DDS file format. (All hail nvidia/3dfx(S3TC) for that ,p)

Side effect is we could zoom back 1 step (50% size) because we could just switch to the smaller mipmap stages on the fly) without using any extra memory.

Personally I hate PNG, it's a cumbersome to edit format that is completely superseded by DDS for games. And for games where you don't need bin transparency but need to use alpha maps (for various reasons relating to shaders) you should just go for TGA if you don't want (or can't) use DDS (which by the way, also supports near lossless compression). But really, if your engine doesn't support DDS, it's time to get out of that time paradox that kept you stuck in 1990 (Unity 3 sadly has abhorrent DDS support, meaning none). Actually I can not even fathom why unity uses internally only PNG and as such, uncompressed blobs in memory, sounds like a veritable design flaw of epic proportions.

[Brise Bonbons]

Sounds great Chris! My group of friends just picked up 5 copies of AVWW to play together, and we're loving it so far, it's such a unique and intelligent game. I personally find the current art endearing and beautiful in places, but I'm also excited to see a new vision of the game.

Personally I'm rooting for the articulated sprites, because I think that can be a really sharp, modern looking animation style. But I agree with others in the thread that a pixel art style would mesh incredibly well with AVWW's gameplay and music.

In short: Bring on the Kickstarter; I will prepare all of my moneys to throw at my monitor as soon as you are ready to catch it.

[TechSY730]

But really, if your engine doesn't support DDS, it's time to get out of that time paradox that kept you stuck in 1990 (Unity 3 sadly has abhorrent DDS support, meaning none). Actually I can not even fathom why unity uses internally only PNG and as such, uncompressed blobs in memory, sounds like a veritable design flaw of epic proportions.

Wouldn't be the first massive design flaw they have hit when working with Unity. However, IIRC, the other engines that looked at had even more design flaws of even more epic proportions. So essentially, Unity was the lesser of N evils. (Or at least, for they need in a game engine)

Still, these kinds of issues are why many companies either use an in-house engine or why they don't agree to an engine unless they also get a copy of the source and permission to redistribute in their product their modified version of it (often at a pretty large increase in cost to buy these rights). However, there is a good chance that neither of those options are very cost effective for Arcen at the moment.

[Castruccio]

RE #3 Above:  I'd certainly be willing to participate in a Kickstarter for this, but I wonder whether anyone other than the Arcen faithful will be willing to pay more for a game they have already paid for.  I can hear the controversy now:  Terraria cost $9.99 and they got the art right the first time, whereas AVWW cost 14.99 and now we have to pay for new art. 

[x4000]

Thanks, Brise -- I really appreciate it.

To the others, regarding unity support for varying types of compression, this is what they support: http://unity3d.com/support/documentation/ScriptReference/TextureFormat.html

Or if you like: http://unity3d.com/support/documentation/Manual/Textures.html

However, because of the way we are loading textures from disk at runtime rather than precompiling them into bundles via unity (which has all sorts of drawbacks), the only format we can store them on disk is PNG.  Unity then is able to store them in a compressed or semi-compressed state in RAM, but the more compression that is applied the more artifacting you get.

In terms of running away from unity because of lack of support for DDS: don't make me laugh.  If they eventually get to it that would be great, but that's not even on my radar as one of the major flaws of the engine. There are other things that bug me far worse.

Even so, there is no better engine than unity 3D if you want to program in C#, and I don't believe there is any more productive language than C# (certainly not for Keith and I at this point in time).  So the question of us leaving unity is extremely moot.

[x4000]

RE #3 Above:  I'd certainly be willing to participate in a Kickstarter for this, but I wonder whether anyone other than the Arcen faithful will be willing to pay more for a game they have already paid for.  I can hear the controversy now:  Terraria cost $9.99 and they got the art right the first time, whereas AVWW cost 14.99 and now we have to pay for new art.

It all depends on how it's presented.  If it's not worth it to players, then it's certainly not worth it to me.  But for all the people moaning "I'd play this game if only it didn't make my eyes bleed," this is a chance for them to put their money where their mouth is.  If they are serious, then they can help in the kickstarter and get whatever perqs come with that at the level of contribution they make.  If they were just mouthing off, then that answers that question and we can proceed with the current art style forevermore for this game.

This game was very expensive to make, much moreso than Terraria, I think largely because we tried to do so many new and exploratory things.  R&D costs money, as anyone can tell you.  Terraria and Minecraft both had a big leg up from the simple fact that players could construct so many things on their own: if you give someone a lego set, they don't need that many different unique pieces in order to have fun.  Our game doesn't have a construction component and so it's all about the worldbuilding and adventuring and so forth for us.

If people feel like it's a good value and they want the new art style, then they're free to invest however much it's worth to them.  If they don't, then the kickstarter will fail and it will answer the question definitively: this game isn't failing to reach some larger audience because of lack of art budget.

In point of fact, I rather hope that it's largely NOT the Arcen faithful who are doing most of the investing.  At some contribution level we'll undoubtedly be giving away a copy of the game as part of the perqs, and so I hope that this is a way for people to get into the game who otherwise would have given it a miss for the reason of graphics alone.

It all comes down to what people want.  People can make a controversy out of anything, but if they want to have a hand in deciding the future of titles that at least try to bring something new to the table, then this is one such chance.

[eRe4s3r]

Can I ask something stupid? What are the drawbacks of precompiliing the textures so that Unity can use them compressed properly? Because if you'd use DXT5 on those transparent png's you'd save 2 to 8 to infinity times as much ram and vram as if you didn't. So those ought to be some pretty massive drawbacks ;p Quality it can not be, unless Unity uses some silly "super-fast" compression setting for DXT5, you should not be able to see any visual difference, no difference really.

[x4000]

Can I ask something stupid? What are the drawbacks of precompiliing the textures so that Unity can use them compressed properly? Because if you'd use DXT5 on those transparent png's you'd save 2 to 8 to infinity times as much ram and vram as if you didn't. So those ought to be some pretty massive drawbacks ;p Quality it can not be, unless Unity uses some silly "super-fast" compression setting for DXT5, you should not be able to see any visual difference, no difference really.

The drawback is that unity has no way of loading an image at runtime that isn't a PNG.  And to my knowledge I don't have a way of creating a DXT5 file, although I'm sure that is the more slight of the two problems.

[eRe4s3r]

But.. why do you load images at runtime? Actually, I think I need to explain what I mean, in that 2nd link you showed that you can Import images into Unity and have them handled internally as DXT5, that is great. Do that for everything except normal maps ;p I assume what you mean is that Unity packs this all into a .. pack somehow and you'd have to load it at start completely? But is that really a problem? With DXT5 compressed textures internally your memory footprint would be small enough to do that. You'd use less than 250mb RAM if everything was DXT5 compressed (that is for all the graphics).

I assume I miss a huge obvious point here, because If you could do that you probably would... just seems like.. the obvious thing to do. To me

[keith.lamothe]

But.. why do you load images at runtime?

I don't remember everything, but the big thing is:

Precompiling them into the unity asset bundle would mean that every time we added a new art asset the next prerelease would have to include a new copy of the entire asset bundle.

That obviously precludes support for texture modding though we could live with that if necessary, but the big thing is much higher costs (your time, our money) for updates.  And fast updates are kind of important

It also basically means that for anyone to test a new piece of art in the game they have to have our unity project and a copy of unity pro; right now we're doing fine with just two unity licenses and in theory we could keep doing that if Chris is the artist, but it would be much more complicated if someone else was doing the art.

[tigersfan]

But.. why do you load images at runtime?

I don't remember everything, but the big thing is:

Precompiling them into the unity asset bundle would mean that every time we added a new art asset the next prerelease would have to include a new copy of the entire asset bundle.

That obviously precludes support for texture modding though we could live with that if necessary, but the big thing is much higher costs (your time, our money) for updates.  And fast updates are kind of important

It also basically means that for anyone to test a new piece of art in the game they have to have our unity project and a copy of unity pro; right now we're doing fine with just two unity licenses and in theory we could keep doing that if Chris is the artist, but it would be much more complicated if someone else was doing the art.

Also related to that, it would mean that it would be harder for me to test art, as I don't actually have (or need) a Unity seat.

[Nanashi]

@Bluddy: Actually, I have no idea how Unity handles 2d rendering. Most of my 2d ventures are non3d in nature because I use older engines software (with no 3D support at all, such as ScummVM) with 16 bit colour support - however, they also support lossy compressed formats for bitmaps (even jpg and gif). As far as I can tell, no conversion is necessary because your display is forced into limited colour from the very beginning.

If Unity (which I don't use, since it's primarily a 3D engine) forces everything to render in 3D before converting to 2D - I've already said that firstly, it's fundamentally a coding problem which wastes RAM (Why more than two rendering passes?) and secondly, that seems like a *really inefficient* way of handling sprite data.

Doesn't Unity have a VGA renderer plugin?

Edit: I just took a look at Unity's 2D support page and I see the problem. Its really is completely pseudo-2D - you're rendering mapped 2D vertices into a plane. This is definitely not how *most* engines do it - and if you're going to have this sort of rendering, it's probably a bad idea to have separate sprite sheets for everything. Why not combine all of your static object categories into one file?

Also, even if indexing the colour mode can't save active memory, reducing the palette is a very simple form of image compression that's pretty much compatible with anything. Given the same dimensions, a 256 colour image is always going to take up less active memory than a 7k+ one simply because it decreases the processing power needed of each memory call.

[tigersfan]

...
Why not combine all of your static object categories into one file?
...

See post #70, above.

[eRe4s3r]

@Nanashi

Unity doesn't have a 2D renderer (all modern engines actually don't) and the performance of 2D engines (Direct Draw....) is abysmal. It is always faster to render a 2D sprite in a 3D engine than it is to render it in a 2D engine.

AI War 1.0 was Direct Draw based and it ran pretty dang terribly compared to now Direct Draw is also end-of-life. Microsoft explicitly said not to use it anymore because broad compatibility is no longer a given. Microsoft says to render to polygons instead. With hardware acceleration this is up to 100 times faster too ;p

Anyhow, as a 3D engine unity doesn't care about what comes in, if it isn't DXT compressed it renders it to uncompressed image state with whatever bitrate the image had and then pushes it to the GPU wasting memory in the process (2 images are in memory, compressed and uncompressed which as you can imagine is a nightmare for ram usage). Lowering the colors to 256 works imo, as engines take it as it comes, so 512x512 * 256 colors would indeed use less ram and vram. That means even if you index it down to 3 colors, the image is loaded as a 256 color image and uses that much ram/vram the other 253 colors would then be considered black, still use the memory as if it was a full 256 color image ;p

Hence, converting what can be converted to 256 colors might be worth considering and it may be worth a test whether this lowers ram and vram usage or not, it is very well possible unity converts it to a specific color mode internally no matter what we put in.