Okay, this is all just my personal understanding of stuff.
[quote:1qrom6he]Can anyone point me toward resources (in any form) which cover some of the big picture principles of 2D game design? For example, why are tiled backgrounds and tile maps recommended, and how big of a problem is it if they aren't used? (I've read through the documentation and understand the basic argument, but feel as if there's a bigger picture that I'm not quite grasping.)
It's all about re-using content as much as possible to minimize A: time/effort spent making content, B: Graphics memory spent, C: GPU processing load, and D: Game size.
Out of these four, only A is really relevant today unless you're making mobile games. Then you might need to pay some attention to B, C and D too.
Whether they're AAA blockbusters or small mobile games, from 25 years ago or three months ago, most if not all games re-use assets all over the place. You might use six different bush variants for all 120 bushes in your game for instance and, if you're a bit clever about where and how you place them, no one will notice it's the same bushes used over and over again.
I guess if you feel confused about how and why tiles are used and why they're even a thing then it might help to remember they're just another method to re-use assets, one that came about in the console/home computer stone age In the 80's and to a lesser degree early 90's, graphics processors imposed very very strict limitations on what a designer could and couldn't do. For instance the Nintendo Entertainment System (NES) had 256 8x8 tiles you could use for backgrounds at a time (normally). Each 16x16 pixel area on the screen had access to ONE out of four palettes you could use at a time, and each palette amounted to a grand total of FOUR colors. The NES, the Sega Master System, the Commodore 64 etc, all had those kinds of restrictions. So designing tiles that could be re-used over and over and be used seamlessly together was a crucial part of game design.
2D hardware has been designed around using power-of-two tiles and sprites up to and including nintendo DS, because it's a neat way of doing things things in 2D. Saves memory, saves storage space, runs really fast if the hardware's optimized for it etc. 3D hardware is *not* optimized for it btw.
The reason I mention all this is that tiles aren't really something you need to worry about with today's hardware. There are no limits. Or rather, the limits are so generous that you can do things pretty much any way you want as long as you don't blow the gpu's video memory or fill-rate budget.
[quote:1qrom6he]We are also trying to understand sprite sizing issues, from the very basic question of "Does it really matter if they are squares?" to "What is a realistic size for sprites that will look good on contemporary phones?" We understand that graphics should be created as vector graphics, that they're supposed to be sized in multiples of eight, and that we will probably end up with two sets of graphics (a set for high-resolution browsers and a 'one size fits all' set of images for everything else). Some have suggested that the one size fits all sprites should be 64 x 64 pixels, but this seems *really* tiny.
If you're doing vector graphics you can make it as big as you like and scale down afterwards. You'll need to consider how big you need those sprites to be in relation to screen-space. Different gameplay suits different sizes. A fighting game sprite takes up a lot more screen space than a soldier unit in an RTS for instance. Look at games similar to what you want to make and see what size relative to screen space they're using.