iCombat

There is a great post in ngmoco’s blog from several months ago that talks about the complexity behind tuning games.  Specifically referring to Star Defense, Allen Ma talks about how any one factor when changed impacts the entire flow and resulting difficulty level of the game:

“For example, if the game allowed you to pause it while you placed towers or if there were a few more seconds between wave launches, Star Defense would lose its fast pace. If we altered the strength of the towers or how much it cost to upgrade them, it would influence how you played the game. If we handed out more credits for each enemy unit killed, it would change how you managed tower purchases and upgrades.”

Players underestimate just how difficult it is to design a game with a nice balance between being rewarding to play but challenging enough to want to continue playing.  Even with iCombat, which has a very simple game mechanic, it took several weeks to refine the level design and lay them out in a way that provided a steady progression from level 1 through 60. And this initial design has been refined and tuned throughout every update.

Aside from the level design which is the most visible factor that can affect game play, there are things like enemy AI (firing frequency, movement paths, speed, etc), the scoring mechanism, the frequency of power-ups or bonus items, the number of lives, upgrade prices and so one that are crucial to getting the game right.

An example of just how intentional these design elements are can be seen in iCombat’s score system, where many users wondered why we chose to go with a countdown (Enigmo style) method where each level begins counting back from 10,000.  The decision was focused at creating a scoring mechanic that rewarded speed, thus creating a nice interplay between playing it safe to preserve lives or playing fast to get points.  The result is that no 2 scores are ever alike.  This might seem like a small detail, but for the avid users it creates an entirely different decision tree when facing the harder, more involved levels.  Do you hide to preserve life, let the time expire, and then execute a level safely?  Or do you go guns blazing to finish with as many points as possible?  To extend this decision tree further and equalize players across difficulty level we made the countdown 12,000 for Hard mode, 10,000 for Medium and 8,000 for easy.

Another great example of where we made a decision to point the user behavior a certain direction came from the fact that one shot equals a player kill.  Here the logic was to force users to play more conservatively, pushing creative calculations with ricochet’s and bonus items.  And by limiting the map size, we managed to create a campaign mode that could be done in bite sized chunks, 5 minutes here and there.

So the next time you play a game think about how every single detail in the game was deisgned intentionally that way.  There are no default game layouts or settings so if it is in a game then the developer wanted it there.  Whether it was the right choice or not is a separate issue, but sometimes it helps to remember just how difficult it is to get the balance right.

Related articles by Zemanta

• BioWare’s Gaider: story is important, but not that important (destructoid.com)
• GDC Europe 09: Peter Molyneux (semanticmetadata.net)
• Review: GI Joe’s maddening controls, game mechanics a letdown (canada.com)

Being a first time game developer, I am finding that the final stages of game development, namely bug fixing and adding final polish (game menus, transitions, etc) take much longer than I could have anticipated.  It is only now that I am beginning to appreciate some of the complexities behind product development and launch.  From a technical point of view, it is difficult to know on the front end just how much time will be necessary to debug properly but also from a psychological point of view I am beginning to understand just how hard it is to finish well.  At some point, when you have done the most interesting part of app development (where progress on a day to day basis is much faster and noticeable) you are stuck sanding down the rough edges and a sort of development fatigue sets in.  With so little to show in terms of progress, i.e. spending days changing menu layouts or touching up fonts, the developers and the entire team get eager to just push it out the door already and see what happens.  This is where we, and I assume most developers, debate the merits of fine tuning their app versus just launching it in the market, where it can start to make money and give some immediate feedback. Read more…

I posted to Twitter about this but think it deserves mention here as well since it is such a great resource for game developers.  Ngmoco’s blog is short but incredibly dense in high quality advice from successful and experienced iPhone gamemakers.  The most recent posts aren’t so heavy on design advice but if you go to earlier entries you will find some awesome entries about game design and development.  The best post was from Kristine Coco titled With doing comes learning that gives some great insight into what works and what doesn’t for geographically distributed teams as well as for certain aspects of game development.  As an aside, Kristine will actually be giving a talk this year at the Game Developers Conference on working with external teams (clearly a topic important to me as I work with a team in the Ukraine!) titled I Say Green, You Hear Purple: Avoiding a Game of Telephone When Working with External Teams.  While I cannot attend unfortunately, it sounds like the ngmoco website will be posting the talk and slides after the presentation on their blog (update: see slides here). Read more…

I decided this weekend that I would get one last round of user feedback before we begin our final phase of development and debugging in the coming weeks. This was the first close to fully baked test I had done and I even prepared a list of survey questions for everyone that tested the game. In it I had questions regarding the user’s usage patterns (average number of applications downloaded a month, average amount of time playing games a week, how much spent in the last month on apps, etc) but I focused primarily on which aspects of the game they liked and disliked (best aspect, worst aspect, what would you add/ remove, any confusion, etc). Here I found the range of user opinion to be huge, so much so that I wonder how useful the entire exercise was. Here are some of the general observations I noticed in my small game test experiment: Read more…

It occurred to me as I sat here going through dozens of game sound effects and game graphics that I don’t have the foggiest idea what I am doing.  Sure I have played plenty of games and have a clear vision of what this app should look like but beyond that, I have not read one book or one article about good game design.  I did stumble across The Hummingbird Manifesto but this is little more than a cheeky bit of pretty intuitive advice.  As my game development gets further along though I find that I have made dozens if not hundreds of decisions and all I am going off of is my past game play experience.

Atari Pong Screenshot

I am fairly confident I have limited just how much I can screw this up by keeping the game simple and without too much of a plot as this seems to add another layer of design complexity. This is why I chose to do a game based off of some of the original gaming platforms: these focused on the quality of in game play rather than depth and variety of sound or visual effects (of course there was no choice back then).

After just building what we have, and you guys will get to be the judges of how well we have done soon, I can say I really respect professional game designers.  To have the vision to not only create a fully developed plot but then to fold in the complexity of quality sound and graphics really is a huge effort.  Especially when you are inventing a new theme or world from scratch.  No wonder game budgets are becoming so enormous like Spore’s estimated $35 million and there are tons of Bachelor’s degree programs for game development and design like this one. Read more…

It’s 6am and I just spent the last 14 hours mocking up my 20 levels so that the developers can have a foundation on which to build the game.  I did the entire set of levels in Powerpoint, it was surprisingly easy I guess I got one decent skill out of Investment Banking (still wasn’t worth it).  For anyone who has never cared to or ever tried to lay out a game, even a simple one like mine, let me tell you it is pretty impossible to have any sort of intuition around what will play well.

Level mock-ups

Of course you have to consider user habits, the quality of the enemy AI and so on, and even knowing that and expecting future revisions it is still frustrating how much of a shot in the dark it all is

The question I grappled with most was how will the accelerometer steering affect game play…impossible to really know until we start fiddling with different filters to find the right blend of speed and control.  I definitely want to avoid making a Labyrinth style experience, where the low friction coefficient makes steering so difficult.  Another thing I didn’t really appreciate beforehand was how little real estate an iPhone screen actually has -  you do have to be efficient in your design when it comes to games.

Read more…