Delicate balances in mobile game design.
Author
So I am designing a mobile game from the ground up, and really wanting to do it right design doc, game concept etc. etc. I have a good bit fleshed out but the more I re-read my design doc I wonder if I am shooting to high, I wonder how other designers of mobile games budget the assets and resources for a game, how much design can one really do? I mean on some handsets the game will run with 10 of the planned levels in it, on others it will run only with 5 of the planned levels in it (due to resource restrictions etc.)
Anyone have good templates to help design around such wide ranges in handsets ? I mean there is the code side, but there are resources there, im asking more bout the design side.
I also am at a standstill on the design when it comes to setting and levels, I have two options: make the game settings and levels cover a wide range of areas with an urban environment, or focus on one area and have many facets to that one area. I am trying to decide which is the best approach. The wide range of areas sounds more intresting but I don't want it to feel disjoint and *too* expansive? but then the smaller more focused area might feel too clostorphobic in design, any good methods to help weigh the pros and cons appropriately? or help come to a third unseen posibility?
And sorry there are a lot of genericness bout this post, for obvious reasons I don't want to post specifics bout the gameplay or anything.
If anyone has some good links relating relatively closely to mobile game design then id love to see them or any other tidbits, experiences as well (ive scoured gamasutra.com but their search I find very picky on the words you have to use to get useful results).
thanks,
Shane
I played City of Heros for a while. For like 3 months. The thing that turned me off the quickest was that every zone was essentially the same: A city. Sure, the buildings looked different, but the actualy pathing the players took was the same. I played WoW for a while, and having evey zone wiht a unique feel and style really added to the experience. it felt like I was in a real world.
So, my personal prefference is a multi setting. However, dont try to do the "ice world", "fire world", "technology world" etc etc thing. Thats what sort of makes it disjointed. Have it flow. Id reccomend starting in, say, a forest, then moving on to a forest with more and more snow on the ground, then more snow, less trees and more rock, and eventurally youre in an environment of a mountain.. that sort of thing.
But then, I guess it kind of depends on the game play.
Id think the biggest obstical would be your use of tiles in a mobile game, seeing as how most cell phones arent exactly pentium 4s.
So, my personal prefference is a multi setting. However, dont try to do the "ice world", "fire world", "technology world" etc etc thing. Thats what sort of makes it disjointed. Have it flow. Id reccomend starting in, say, a forest, then moving on to a forest with more and more snow on the ground, then more snow, less trees and more rock, and eventurally youre in an environment of a mountain.. that sort of thing.
But then, I guess it kind of depends on the game play.
Id think the biggest obstical would be your use of tiles in a mobile game, seeing as how most cell phones arent exactly pentium 4s.
Author
ya tile size is a restriction, and then the way the gameplay is laid out different areas would most defiantly have to provide new bad guys (Cause bad guys are more than just obstacles in this game)...
thats why I was thinking one area I could recycle the bad guys more easily and acceptably, i.e. getting away with introducing the new bad guys at later and later times, instead of having to change areas quickly and introducing the whole new set of bad guys thats the biggest obstacle(Cause ya i could not introduce a whole new area right away but then the area u are stuck in woudl become drab quickly id suspect with the limited tile sets I could get away with)
thats why I was thinking one area I could recycle the bad guys more easily and acceptably, i.e. getting away with introducing the new bad guys at later and later times, instead of having to change areas quickly and introducing the whole new set of bad guys thats the biggest obstacle(Cause ya i could not introduce a whole new area right away but then the area u are stuck in woudl become drab quickly id suspect with the limited tile sets I could get away with)
You said "city environment" and I thought about RENEGADE. Part of the fun in that game (and many side scrolling fighting games) is that you always change environment: bad-famed backstreet, subway, some bar indoor, a work site. These locations have something special on their own, also they offer enough room for creativity. And they TAKE A LOT OF TILES. :)
I would strongly suggest that you should come with more different locations (all belonging to town setting for preventing disjoints) instead of same location from many points of view.
A possible flow in work could be the following:
- identify location needs in terms of gameplay (a character close-up game needs more attention to detail while a large view - check War of the Worlds game for mobile - need only a general idea about the environment).
- prototype some ideas about possible locations - as many as possible, also try to keep the same level of granularity for their sizes and description
- define graphic elements which defines all these locations and build some draft graphical representation for each of them
- pick up 2 or maximum 4 of these locations - the one that best fit and sustain your story and gameplay AND (very important) CAN BE REPRESENTED WITH FEW TILES.
- have your story fit in the two tilesets (never less than TWO) because on low-level handsets you will have to live with that
About game design:
I suggest you to design for the medium handset (for example Series40/128x128 pixels, 250k heap memory, images take space equal to width x height x 2 bytes, images must not use more than 16 color - including transparency) and always compute requirements by analysing some prototype resource (image, game specific data, etc). Farseeing possible problems is critical and always try to stick to minimum elements needed to make the game fun. Some features requires a lot of coding so, if you do not have the skills, try to work together with a programmer. As a final advice, when analysing requirements, try to figure out the hidden requirements which are bind to game specific data (ai files, animations etc). Do not ignore small things because sometimes they add up. Also, don't let this kill your creativity.
I consider that designing for very limited platforms (such as consoles and handsets) actualy improves creativity because you have to permanently reshape your initial design (and this includes working your brain to find "a better implementation for this idea").
Maybe if you give some more information about your game - camera, basic gameplay we can offer even better suggestions.
Keep it up!
Cod.
PS: I wrote a lot :D
I would strongly suggest that you should come with more different locations (all belonging to town setting for preventing disjoints) instead of same location from many points of view.
A possible flow in work could be the following:
- identify location needs in terms of gameplay (a character close-up game needs more attention to detail while a large view - check War of the Worlds game for mobile - need only a general idea about the environment).
- prototype some ideas about possible locations - as many as possible, also try to keep the same level of granularity for their sizes and description
- define graphic elements which defines all these locations and build some draft graphical representation for each of them
- pick up 2 or maximum 4 of these locations - the one that best fit and sustain your story and gameplay AND (very important) CAN BE REPRESENTED WITH FEW TILES.
- have your story fit in the two tilesets (never less than TWO) because on low-level handsets you will have to live with that
About game design:
I suggest you to design for the medium handset (for example Series40/128x128 pixels, 250k heap memory, images take space equal to width x height x 2 bytes, images must not use more than 16 color - including transparency) and always compute requirements by analysing some prototype resource (image, game specific data, etc). Farseeing possible problems is critical and always try to stick to minimum elements needed to make the game fun. Some features requires a lot of coding so, if you do not have the skills, try to work together with a programmer. As a final advice, when analysing requirements, try to figure out the hidden requirements which are bind to game specific data (ai files, animations etc). Do not ignore small things because sometimes they add up. Also, don't let this kill your creativity.
I consider that designing for very limited platforms (such as consoles and handsets) actualy improves creativity because you have to permanently reshape your initial design (and this includes working your brain to find "a better implementation for this idea").
Maybe if you give some more information about your game - camera, basic gameplay we can offer even better suggestions.
Keep it up!
Cod.
PS: I wrote a lot :D
Author
Thanks for the info, You wrote a lot but its all good stuff :) I didn't even think that the basic handset was 128x128 right there that changes the planned tile size I had in mind.
Honestly, the story was sorta going to be an after thought as its a mobile game and I realized I didn't want to get bogged down in storing pages of text for what is essentially a platformer.
The game will be very similar lost vikings, that is, getting from point A to point B utilizing the oppertunities at your disposal in a particular level to do so.
The thing with the tilesets and making it feel disjoint is that the gameplay would be very encounter specific, and designing multiple DIFFERENT encounters with whats essentially power ups (To get you from point a to point b) would be difficult, so thats another reason why going with the many different areas...I could introduce the new power ups (area specific) and keep the encounters fresh.
(again im using relatively generic terms)
as for requirements, im trying to figure out how many animation states for each enemy in the game, it seems there will be about 3 states: Idle state of osme sort, being attacked state, and dying state....
If I design the art requirements right, the dying state animations could be shared by any enemy...
As far as coding, i've got that covered and am currently targeting midp2.0 phones (This saves me from us having to port our game engine from PC cause midp2.0 gives a lot of nice fucntionality). The rest is the game specific implimentation.
I have one simple question thats been burning me from day one: If you are coding for a mobile phone, or another mobile device that requires a single file and/or has to have files synched. Why would you game the data driven? as for instance with j2me games, they are all compiled into a .jar file that is then ran on the phone or the emulator, why make something data driven? (as in having external files for ai scripts or something) sinceu to get it into a jar compressed and whatever else the compiler does to it would require a recompile anyway?
just curious, perhaps im short sighted here.
thanks for the long response...this is the stuff I needed :)
Honestly, the story was sorta going to be an after thought as its a mobile game and I realized I didn't want to get bogged down in storing pages of text for what is essentially a platformer.
The game will be very similar lost vikings, that is, getting from point A to point B utilizing the oppertunities at your disposal in a particular level to do so.
The thing with the tilesets and making it feel disjoint is that the gameplay would be very encounter specific, and designing multiple DIFFERENT encounters with whats essentially power ups (To get you from point a to point b) would be difficult, so thats another reason why going with the many different areas...I could introduce the new power ups (area specific) and keep the encounters fresh.
(again im using relatively generic terms)
as for requirements, im trying to figure out how many animation states for each enemy in the game, it seems there will be about 3 states: Idle state of osme sort, being attacked state, and dying state....
If I design the art requirements right, the dying state animations could be shared by any enemy...
As far as coding, i've got that covered and am currently targeting midp2.0 phones (This saves me from us having to port our game engine from PC cause midp2.0 gives a lot of nice fucntionality). The rest is the game specific implimentation.
I have one simple question thats been burning me from day one: If you are coding for a mobile phone, or another mobile device that requires a single file and/or has to have files synched. Why would you game the data driven? as for instance with j2me games, they are all compiled into a .jar file that is then ran on the phone or the emulator, why make something data driven? (as in having external files for ai scripts or something) sinceu to get it into a jar compressed and whatever else the compiler does to it would require a recompile anyway?
just curious, perhaps im short sighted here.
thanks for the long response...this is the stuff I needed :)
Quote:Original post by Codejoy
I have one simple question thats been burning me from day one: If you are coding for a mobile phone, or another mobile device that requires a single file and/or has to have files synched. Why would you game the data driven? as for instance with j2me games, they are all compiled into a .jar file that is then ran on the phone or the emulator, why make something data driven? (as in having external files for ai scripts or something) sinceu to get it into a jar compressed and whatever else the compiler does to it would require a recompile anyway?
No need to recompile, just repackage. It's not the same thing. But it's pretty much a moot point since the whole compilation/packaging process for a mobile game hardly ever takes longer than a few seconds.
The big advantage, although not quite relevant with the AI example, is that commercial mobile games usually have many different versions to cater for the vast variety of phones. So it's nice if you can put all the version specific stuff in data files and make a build process that knows how to take the necessary resources from different places to create many versions from a single codebase.
Also, if you design it well, data-driven design means you can shove more content in a smaller jar. A hard-coded map will usually take more jar space than a small method to load the map from a data file+the data file itself.
shmoove
Author
woah, you learn something new everyday. I was having netbeans do most the work for me, I just thought it would be more a pain in the butt to repackage than to just do it in code and let netbeans do it...
"Also, if you design it well, data-driven design means you can shove more content in a smaller jar."
They seriously need a book that shows you all these mean tricks to packing as much into a jar as you can.
Do phones have a limit to jar size? I get a little worried cause it seems the most basic game I have (an example from my book) is like 75KB-1xxKB.
"250k heap memory"
that was mentioned somewhere else, since he said heap im guessing thats run time memory?
Sorry this thread getting a bit technical, but I guess its still all about design :)
My goal is to design the game play and story eleements, and then code the first version of it on some platform, trying to have the platform i pick to be the most common. After that I will go back through and figure out how to optimize for other platforms. (Yes i realize this isn't probably how to do it, but since its my first stab at a complete and real mobile app I figured its not a bad approach)
"Also, if you design it well, data-driven design means you can shove more content in a smaller jar."
They seriously need a book that shows you all these mean tricks to packing as much into a jar as you can.
Do phones have a limit to jar size? I get a little worried cause it seems the most basic game I have (an example from my book) is like 75KB-1xxKB.
"250k heap memory"
that was mentioned somewhere else, since he said heap im guessing thats run time memory?
Sorry this thread getting a bit technical, but I guess its still all about design :)
My goal is to design the game play and story eleements, and then code the first version of it on some platform, trying to have the platform i pick to be the most common. After that I will go back through and figure out how to optimize for other platforms. (Yes i realize this isn't probably how to do it, but since its my first stab at a complete and real mobile app I figured its not a bad approach)
Most phones have limits on the jar size. And sometimes the telcos will also impose a limit on the size of downloads. If we take the Series 40 example (they actually have more like 200K of heap), the jars have to be under 64K.
Here are some links on minimizing jar size (and some other optimizations):
click
click
click
Now carry on with all that artsy stuff [wink]
shmoove
Here are some links on minimizing jar size (and some other optimizations):
click
click
click
Now carry on with all that artsy stuff [wink]
shmoove
Here I come again before going home ;)
Even I have some obsession for creating data driven engines here are some advantages for handsets development:
- less work for the the programmer to polish the game; instead he can use his time to repair engine bugs not game mechanics bugs;
- as shmoove said you just repackage when changing some data files (a new character in fonts after adding new language support with new text files - those with special characters like German, French, Spanish are just a few examples)
- more freedom and changes on-the-fly avaible for the designer - if I have scripted some events in level I can easily modify them in a editor, export to game format, repack and the game runs smoothly with the same code while the programmer is busy with adding new support for other types of events)
- simplified game logic at programming level = simplified code = more modular level = less bugs - you should always make a ballance between code vs data. Imagine you script character behavior and also add some movement and collision info in your animation files. You may create a new action without touching code, which is faster and more reliable. For a few actions avaible in game sometime you may gain just a few or no space but when you have a lot of actions, characters and behaviors you just win a lot.
- easier porting. Making the master version of the game looks like an easy task compared to the work involved in porting for other handsets. Java is portable. Phones are not compatible. This is learned fast and painful by mobile developers. When it comes to interface resizes or removing data and features to "fit into the jar size" this will really help.
- many more I think but I can figure out now :)
An out of discussion advice - don't design using a game logic based on physical coordinates/values. Instead use some internal measurement system to describe the game which will be scalled to every screen size.
Heap memory refers to run time memory. Note that some phones have a special VIDEO MEMORY for storing images (in Image format). As I know they are Sony Ericsson K500, K600, V/W800, K700, Z1010, T610 and Samsung C225.
Things to consider when designing (that's all i can figure out now) in order to prevent many many problems on some handsets:
- use images which have an odd width
- if you are using 'modules' (you have more images in a single bigger image and you only copy a rectangular area = 'module from the big image' on screen) they should fall under the previous odd width rule
More to come tomorrow. I have to run now, someone is waiting for me :)
Even I have some obsession for creating data driven engines here are some advantages for handsets development:
- less work for the the programmer to polish the game; instead he can use his time to repair engine bugs not game mechanics bugs;
- as shmoove said you just repackage when changing some data files (a new character in fonts after adding new language support with new text files - those with special characters like German, French, Spanish are just a few examples)
- more freedom and changes on-the-fly avaible for the designer - if I have scripted some events in level I can easily modify them in a editor, export to game format, repack and the game runs smoothly with the same code while the programmer is busy with adding new support for other types of events)
- simplified game logic at programming level = simplified code = more modular level = less bugs - you should always make a ballance between code vs data. Imagine you script character behavior and also add some movement and collision info in your animation files. You may create a new action without touching code, which is faster and more reliable. For a few actions avaible in game sometime you may gain just a few or no space but when you have a lot of actions, characters and behaviors you just win a lot.
- easier porting. Making the master version of the game looks like an easy task compared to the work involved in porting for other handsets. Java is portable. Phones are not compatible. This is learned fast and painful by mobile developers. When it comes to interface resizes or removing data and features to "fit into the jar size" this will really help.
- many more I think but I can figure out now :)
An out of discussion advice - don't design using a game logic based on physical coordinates/values. Instead use some internal measurement system to describe the game which will be scalled to every screen size.
Heap memory refers to run time memory. Note that some phones have a special VIDEO MEMORY for storing images (in Image format). As I know they are Sony Ericsson K500, K600, V/W800, K700, Z1010, T610 and Samsung C225.
Things to consider when designing (that's all i can figure out now) in order to prevent many many problems on some handsets:
- use images which have an odd width
- if you are using 'modules' (you have more images in a single bigger image and you only copy a rectangular area = 'module from the big image' on screen) they should fall under the previous odd width rule
More to come tomorrow. I have to run now, someone is waiting for me :)
Author
hee hee, thanks for the advice guys. Using modules? Not sure whats meant ther,e perhaps its this:
I have all my sprites in one big ol file, then I use animation sets to split up the animations into various states... so is that what ya meant? I will do the odd width, currently my art is like this:
Suppose I have a png file with a character who runs, jumps and does an idle animation. Suppose that frame 4 for the running animation has the biggest frame of animation at 28x32 (where the rest are say 22x32). Then all the frames are of that size, and I just resize (in code now, will be an external file) the image via changing the collision rect and that when I load. but when I create the image they are all 28x32 (or the biggest size of in the whole file)
This method was suggested by a nother forum member a few posts of mine back, it might of even been shmoove who suggested it to me (I was toiling at the time not having a real construct for sprite lists)
This is all very good info though, I don't see how a lone programmer can reallyc ode for all the mobile devices or even a small developer, it seems to me the publisher would have to help there and it would just be the developers task to ensure the code is as portable as possible.
I have all my sprites in one big ol file, then I use animation sets to split up the animations into various states... so is that what ya meant? I will do the odd width, currently my art is like this:
Suppose I have a png file with a character who runs, jumps and does an idle animation. Suppose that frame 4 for the running animation has the biggest frame of animation at 28x32 (where the rest are say 22x32). Then all the frames are of that size, and I just resize (in code now, will be an external file) the image via changing the collision rect and that when I load. but when I create the image they are all 28x32 (or the biggest size of in the whole file)
This method was suggested by a nother forum member a few posts of mine back, it might of even been shmoove who suggested it to me (I was toiling at the time not having a real construct for sprite lists)
This is all very good info though, I don't see how a lone programmer can reallyc ode for all the mobile devices or even a small developer, it seems to me the publisher would have to help there and it would just be the developers task to ensure the code is as portable as possible.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
