Sometimes it is amazing how many images are required for even a small video-game
blog.knolif.comProper planning is key, both to ensure that you don't find yourself suddenly and unexpectedly needing 500 new images, and to find areas for optimization.
What's the value in having enemies have slight differences in appearance as they get close to death? Will players actually notice or care about this? In a 2D games, it probably makes a lot more economical sense to add some kind of procedural effect to show this, such as tinting them red, making them flash, or showing a bright red outline.
The value is polish.
He's not making a data-driven business app, where a shadow here or a custom icon there are nice but ultimately unnecessary. He's making a piece of software in a field where the small details can often be the difference between obscurity and massive success.
Of course, there are exceptions to the rule (Dungeon Raid, Doodle God, etc), but they became successful in spite of their lack of polish by having excellent and novel gameplay. When you're "borrowing" someone else's successful formula, you're competing with all of the crappy clones out there and need to put in a little extra effort to stand out.
Plus, he's making the game for fun, and it's a hell of a lot more fun to make something you're really proud of.
That can work (as I'll dot that for frozen aka slow characters or rage aka fast characters) However certain things just can't be replaced, like a big bite out of a plant or a black eye on another character with blood on the corner of their mouth.
from the shoes of an indie dev, we can't afford 500 new images so we tend to use a lot of editing (i.e particles can have different colors, shapes, sizes ). Can't introduce so many 'new'/'groundbreaking' images.
This is why video game companies hire more artists than programmers.
Counting frames is often not productive though, cut-out animations (which PvZ appears to be using) allow artists to render many frames from one base illustration and some extra work. They're not necessarily easy but they're often a large time savings over frame by frame.
Yes, my idea behind it is generally draw a sprite, copy it into a new frame, move some parts of it, then reconnect and clean up the ugliness that results from an arm being completely disconnected from a shift in the rest of the image.
According to a pixel artist friend of mine, all the companies he's worked for using those types of anims will build a proprietary tool that essentially works like Flash in a pure-bitmap context; tweening, scaling, rotation, and bitmap cutouts(e.g. parts that bulge and bounce, like the belly of a fat character, simply reuse an area of the sprite and layer it on top). These tools are used for menu layouts and level design as well as sprites.
The figure I've seen is that typically 70% of a game's budget will go to art
wonder what's the typical split between programmers,visual and audio artists in a Zynga game budget
This is incredibly true. I've been making a flash game recently, and it's my first, but I've just been overwhelmed with how many images are required. At every step I'm realizing, "Oh damn, I need images for this. Finds my graphics buddy"
It really is a labor of love, best advice really is do as little organic / moving items as possible. They can be added later without feeling the need of "Oh my god not another batch!"
truly a work that never ends.
I started my indie game 4 months ago, and i'm still adding a few touches here and there. Guess it's a creator's bane.
There have been some approaches to client-side image generation in computer games [1][2], but they're not very successful commercially.
1. http://ifarchive.jmac.org/ 2. http://eblong.com/zarf/glulx/