Monday, December 8, 2008

Art assets estimate

I just finished with a fairly comprehensive list of needed art assets for all of the ships and items players will generally interact with.

There are about 600 items on the list (some simple, some more complex).

They represent about 300 hours of artwork, and about 30 megs of in-game art assets (if we utilize channels properly- that's using one byte per pixel to store normal data, another to store colour [using a palette], and another to store alpha [alpha really doesn't *need* 256 levels, but the others can't take more compression than that]), and maybe as few as 15 megs after compression (there will be a fair amount of empty space in the files, averaging about 50%, the redundant data of which should be easily compressed).

This does not account for: GUI, Backdrops (planets and nebulae), particle effects, scenes, or profile images for characters.

The GUI, from what I've seen, can stand a lot of graphical compression for the final release (tiles for the redundant areas), and 50% of it should actually be able to re-use graphics that make up the ships (the background areas made up of plates and lattice from the ships- which will let us easily theme the GUI to match the ship automatically, if we so chose). A meg should be more than sufficient for the buttons, dials, and meters.

We should be able to find ways to systematically generate the background planets and nebulae based on compositing a few simpler images. Luckily, being background images which we probably won't need alpha on (if we use the right forms of colour channel addition when compositing the images) and which we won't need pristine clarity on, lossy compression like jpeg could be an option, bringing us down to, possibly, four megs with the release.

For backdrop scenes, likewise, we can probably compress them; although that all depends on how many we'll have.

With profile images for characters, if we do that, we'll probably want to use something like layering to swap out mustaches, monocles, hair do's, and clothing pieces. Will definitely need alpha there, if we did that, and more full colour depth with people, so any good compression is unlikely. Might be able to do it well with 30 megs.
On the other hand, if we didn't want to bother with customizable profile images (which we very well may not), we could get away with jpeg images at 15k a piece, and make a couple hundred of them for about three megs- which would all have a bit more character as hand drawn pictures (always nice), but would end up being more generically applied. Would be about... 400 hours of artwork.

Throw in a couple hundred hours (and a couple megs) of jpg scenes, and a conservative estimate (with the compression mentioned) would put the game at about 1,000 hours of artwork and 40 megs of graphics in the final release.

Any thoughts?

How big will all of the music and sound effects be?
How big will the needed libs and the code itself be?

I can only estimate on graphics, but it seems to me that a distribution of 100 megs could certainly be possible.


Lotus said...

40 Megs of graphics in the final release is a very good size. With today's connection speeds downloading 100-200 MB game shouldn't be an issue.

Using JPEGs to reduce file sizes is a good idea, although we will definitely lose quality and the alpha channel as you mentioned. If you feel the feel that the file size will be greatly reduced AND if file size is indeed a concern then we can certainly support the JPEG format.

The game binaries are not expected to grow much, they will not exceed 30 and more likely will end up at around 15 MB.

- said...

I think so, and if it's zipped/rared/etc, the graphics *should* compress down to under 25 megs (I was being conservative with half, it seems to usually take a channel down to almost 1/3rd the original size with a triangle).

I made a mistake on profile images:

"Will definitely need alpha there, if we did that, and more full colour depth with people, so any good compression is unlikely. Might be able to do it well with 30 megs."

I realized shortly after posting that if the face is separated from the clothing on the shoulders, using a 256 colour PNG palette would be no problem- that would drop the file size about 60%. Still ten times bigger than a well compressed jpeg, but more reasonable. As long as we didn't use a bunch of fancy poses, It would probably be more like 5 megs if we did the layered thing (of course, PNG isn't keen on compressing more than it already is, so it's still bigger than the three for JPG).

Art hours are also cut about 75%, down to about 100 hours.

I'm torn on that issue...
One the one hand, character portraits made using layered features are intrinsically less expressive because all parts of them have to align properly- can't have a bunch of different poses for each character (maybe only two or three expressions/poses total).

On the other hand, it's really weird to meet ten merchants and have them all look exactly the same (and one is more likely to remember the similarity with an expressive portrait). More importantly, if we're going to use these for crew profiles, there would be several identical images on any crew, and that's a negative aesthetic issue.

Not really any notable extra programming for portraits, since they're just plain layered graphics- I think that would just be scripted.

One nice thing about composited portraits is that if we should ever choose to introduce aliens, we can mix and match alien features for a great variety (at that point, it really does become much more efficient).

Anonymous said...

I would say jpeg support will be very useful for large sprites that do not use alpha transparency. Such as the distant layer of stars, or a planet surface. Having smaller frame sizes opens up the possibility of animating large objects smoothly without worry over disk space usage.

As a web designer, I frequently work in the format and know where compression can be noticed and where it can't from the naked eye; particularly with textures. Jpeg's also have a quality setting which at 90% and above looks very cool.

I don't know if jpeg 2000 format is possible, but that offers an alpha channel aswell.

PNG is the best format for most of our work, but for large scale entities such as a planet close up; we are talking megabytes instead of kilobytes in png format.

However, in terms of video memory; from my DB engine I understand an image in memory with no alpha channel is smaller (3 bytes per pixel, instead of 4). I'm not sure if this is the case in the TP engine.

- said...

A JPEG quality of 25 is sufficient for background images like planets and nebulae (I tried it out, and that's the lowest it looks good, but it looks fine at that quality). The stars, due to high contrast, will probably need to be PNG (and because we want to overlay them with nebulae), but we can hue adjust them in the engine, size them, rotate them- a single good still image is enough to make all stars in the background from; two or three small star images will be plenty there.

With a 2d game, video memory probably won't be a big issue- with modern machines, we should really be able to ham it up with effects without worrying.