Best resources for 2D game design big picture

0 favourites
  • 11 posts
From the Asset Store
Best car suspension with spring effect and very cool terrain generation.
  • Last semester, I used C2 for the first time in a course on mobile gaming. (We once used Flash Actionscript, but that is no longer a viable option.) This course emphasizes programming, graphic design, and game mechanics, but performance issues have never been a primary focus of the class. I'm working with a student to convert his "proof of concept" game into a full-blown game that will perform well across a variety of platforms.

    We are trying to get up to speed on best practices for 2D game development, particularly as far as developing graphical assets is concerned. We found Toby R's tutorial on game resolution to be very helpful, and we have also been reading through everything we can find in these forums. However, much of this information has been pieced together from bits and pieces of various tutorials.

    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.)

    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.

    I'm looking for any documentation -- from forum posts to books to video tutorials or podcasts -- that talks about these "big picture" issues related to 2D game design. Something that will help me understand what we should do, but -- even more important -- why we should do it that way. If there is anything that you've found personally useful in developing your strategic thinking as a 2D game developer, I'd love to know about it.

    For now, we're pulling together the first level of the game in question with the student's existing graphics that don't really follow many of the best practices for game assets. The sprites are of irregular sizes, some of the backgrounds are extremely large, etc. His graphics are beautifully drawn, and I'm hesitant to make him go back to the drawing board until he can see for himself that we are encountering performance problems. We're looking at this as an experiment, and I'm hoping that this will demonstrate in a tangible way *why* we should be following the best practices. At the same time, I'm trying to deepen my own knowledge and understanding of the big picture.

    I would be grateful for any and all suggestions. Thanks!

  • 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.

    I've been asking this same question for years now. I read this on Tigsource before I even started looking for game making software options but have not come up with a clear answer. The general here is C2 is designed to accommodate images of all sizes so this power of two rule shouldn't apply.

    Someone please correct me if I'm wrong.

    Is this power of two thing a myth or was this really a requirement back in the day?

    From what I can tell this might be true during the SNES era.

  • "Power of two images" really isn't an issue anymore as most modern gpus can handle most dimensions.

    That doesn't mean you can just shovel in assets as you please though.

    https://www.scirra.com/blog/112/remembe ... our-memory

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • 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.)

    Tilemaps are really a leftover from the 80's and 90's when memory and storage space were super-limited. You'd use small tiles of graphics that repeated seamlessly to cover large areas on the screen, kinda like how repeating textures are used in 3D games to save on memory. Nowadays they're not as relevant (unless you go completely ape with your assets) and mostly used by indies on a tight budget since they're very cost-efficient too.

    I've been asking this same question for years now. I read this on Tigsource before I even started looking for game making software options but have not come up with a clear answer. The general here is C2 is designed to accommodate images of all sizes so this power of two rule shouldn't apply.

    Someone please correct me if I'm wrong.

    Is this power of two thing a myth or was this really a requirement back in the day?

    From what I can tell this might be true during the SNES era.

    Yeah, old consoles like SNES and especially NES, Sega Master System etc had very strict sprite and tile size requirements which were all power-of-two. 32x32, 32x64, 16x16 etc.

    Here's a few fun threads from pixelation if you're interested in the kind of limitations NES developers had to wrestle with:

    http://pixelation.org/pixelation/index. ... ic=10057.0

    http://pixelation.org/index.php?topic=1 ... #msg144531

    http://pixelation.org/index.php?topic=19899.0

  • Yeah, old consoles like SNES and especially NES, Sega Master System etc had very strict sprite and tile size requirements which were all power-of-two. 32x32, 32x64, 16x16 etc.

    It's weird. I remember meeting up with a programmer back in '15 or so when I had concepts that I didn't know how to implement. I'd been creating assets for one of my first games by then.

    (I'd tried Gamemaker back then but this was before I discovered C2) He told be the same thing.

    He said I should resize my images to power of two if I wanted to implement them for iOS.

    Now I don't know where this comes from.

  • I agree is very hard to find all the documentation in one place, you really have to dig hard here on the forum and outside of the forum to find out the right answers piece by piece, and most of the times the why? we have to do it that way is missing so is not very clear and confusing, I had the same problem for the last two years and I still have basic questions similar to this that are like "The X-files " series unkown,

    and the only conclusion to this that I found is, learn by testing for yourself is the only way, read the most useful tips and tutorials and test test test, it would have been nice if they had all documentation straight to the point in one place at least for basic things like the ones you mentioned.

    Here are some links that may be useful:

    https://www.scirra.com/blog/ashley/10/how-the-construct-2-webgl-renderer-works?page=2

    https://www.scirra.com/tutorials/577/construct-2s-export-time-optimisations

    https://www.scirra.com/tutorials/577/construct-2s-export-time-optimisations

    https://www.scirra.com/manual/134/performance-tips

    https://www.scirra.com/blog/83/optimisation-dont-waste-your-time

    For Mobile:

    https://www.scirra.com/tutorials/298/performance-tips-for-mobile-games

    https://www.scirra.com/forum/optimizing-mobile-games-8-very-critical-tips_t174634

    https://www.scirra.com/forum/viewtopic.php?f=146&t=182264&p=1070221&hilit=Mobile+Optimization#p1070221

  • 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.

  • Thank you, ErekT, Tarek, MPPPlant Official, and Newt for your incredibly helpful replies. After reading through your explanations, and following the links, I have a much better grasp on this issue. This is exactly what I needed!

    The Construct development community is awesome!

  • When you start asking for best design principles in a forum like this you will get a thousand different answers and the truth is game designers all have their own style and game design today is a lot more about artistic use of mechanics and graphics to achieve the effect you want and graphics and effects have surpassed solid game play in my opinion.

    There are core behaviors you should understand and physics is an advanced technique worth learning and using effects to make your games sparkle but there are no rules for game design any more and no cookie cutter holes we have to fit our games in to thankfully!

  • That's great to know, Lamar!

    I understand that, as with web design or other areas of programming, there will be many different theories about best practices. My question was motivated by the desire to understand more about the *rationale* behind some of these practices. That's why I asked folks to point me toward resources (books, videos, etc.) that touch on the larger principles related to game design while providing additional context. I'm not looking for someone to say "you should do 'x' and not 'y'. It's much more helpful to hear people explain the rationale and context behind these practices -- *why* should we do certain things.

    One thing I've taken away from all of this is the recognition that, as you mentioned, there are no longer cookie cutter holes that we have to fit our games into. This is very cool indeed.

  • That's great to know, Lamar!

    I understand that, as with web design or other areas of programming, there will be many different theories about best practices. My question was motivated by the desire to understand more about the *rationale* behind some of these practices. That's why I asked folks to point me toward resources (books, videos, etc.) that touch on the larger principles related to game design while providing additional context. I'm not looking for someone to say "you should do 'x' and not 'y'. It's much more helpful to hear people explain the rationale and context behind these practices -- *why* should we do certain things.

    One thing I've taken away from all of this is the recognition that, as you mentioned, there are no longer cookie cutter holes that we have to fit our games into. This is very cool indeed.

    Best advice I can give you is to maybe get a few CAPX files from games in the arcade that get good reviews and study them and I look for 4 things:

    1) Playability- do all the controls work smoothly, is it easy enough for a kid and adult to play without a huge learning curve.

    2) Graphics- do they create a mood and fit the theme intended.

    3) Effects- this can be visual or aural effects and are they timed right to make the player sit on the edge of their seat when they happen or create intensity and raise expectations.

    4) Story line- not all games require a story but kids will be telling themselves a story when they play regardless because of their imaginations.

    Playability is a matter of understanding mechanics of the characters and also designing a game from the perspective of someone that has never seen the game before and wants to play.

    Graphics and effects are that artistic quality I was talking about and many games I see are great as an artistic venture but lack playability.

    Story is also artistic or creative and it takes trying to capture something that will resonate with your audience to get them feeling something about the game and that is the hardest part for most game creators to get into their games and is usually the failing of many games. That is a talent in itself that there is no book you can read to develop but reading books that require imagination and studying how to write stories does help.

    Hope that helps!

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)