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

Although conventional wisdom is to iterate frequently, the friction for submitting new updates to the App store is so low that developers seem to be taking this strategy to the extreme as an excuse to launch prematurely. These apps freeze, quit, or just don’t work as advertised and many times users write negative reviews as a result.  While some developers would argue that they get a ranking bump from new updates, and I have seen some applications that submit updates every 4 days or so for the 1st month post launch as a strategy, I think this is damaging to the brand they are trying to create and only serves to piss off the early users.

If your app is free the bar is set low, but if you are charging even $0.99 it might make sense to wait until you get the major bugs out.  Sometimes though it seems to come down to a game of chicken, where the financial urge and market opportunity considerations create a push to launch that runs directly in contrast to the need for more time to refine and debug.  The guys at ngmoco’s have a great post about why they choose to do their first update to Rolando now, 3 months after they launched the game on December 18th.  Clearly this is the ideal approach but ngmoco has a privileged position, having proven themselves early while also having the financial and structural flexibility to be able to run rigorous quality assurance protocols pre-launch (said to have fixed 1000 bugs before launch!).  It is a testament to their process that they have not had to submit any updates since release until this update.

For the rest of us amateur developers though the question is not so simple.  While I do not think we should emulate ngmoco’s strategy, as it is financially risky for an amateur developer to spend so much time and money on testing a totally unproven idea, I think it is to be patient and make sure the major bugs are dealt with before launching to paying customers.  If you are creating a crapware app that has little functionality and is simple then sure, launch it early, but if you have any pretensions of developing a community or following behind your game it might be wise to have all of your users, even the early ones, have a positive experience with your app from day one.

Another approach is to launch your app as a fully functional but with an extremely limited feature set.  The perfect example lies in the current No. 1 in the paid App store, Pocket God. Bolt Creative, the makers of the game, decided to launch after only 1 week of development and subsequently released 1 update per week for 10 weeks, adding a new feature each week.  While this strategy worked well by building a community and fostering an interactive ongoing relationship with the user, it looks like it strained the early users on the front end.  In a recent interview, one of the co-founders of Bolt Creative Dave Castelnuovo said that, at the beginning, they “felt really guilty releasing [the Pocket God] app for $.99 because people said there really wasn’t enough there.”  While I am sure all of the subsequent 10 updates made users happy, it is a risky approach that only works if your ongoing updates are good and if your idea does not get poached in the process.

From my point of view we thought about releasing iCombat with only 1 player mode and less options but in the end we decided to forgo the short term benefits at the risk of exposing our concept.  The tradeoff we saw was that, with such a quick turnover rate to developing new apps, we could be releasing our idea to the world to only have someone with a bigger more experienced team, steal our idea and do it better than us.  We chose to risk the 1st mover advantage as well as short term gain to come to market the first time with a better brand and a more defensible product. Clearly the market is evolving and many models will work, so only time will tell if tour approach was a wise idea when we launch in the coming couple of weeks.

Update:  We just submitted iCombat to Apple on Monday (2 days ago), while there were one or two design considerations we were still debating and figuring out how to perfect, we finally decided to let the users decide which features they liked most.  From our perspective, and maybe from also writing this post and thinking more about the Pocket God example, it just didn’t make much sense to keep working on certain design issues that we weren’t even sure the user cared about.

Related articles by Zemanta

• Rolando Getting a Lite Version [Rolando] (kotaku.com)
• Premium iPhone Games Coming Soon? (textually.org)
• Your iPhone Has Died of Dysentery: Oregon Trail coming for the iPhone (crunchgear.com)
• Apple Struggles With Flood of iPhone Games [IPhone] (kotaku.com)
• Developpers have a hard time getting their apps noticed in App Store (textually.org)

Another fascinating post was by Matt Roberts’ titled Usability and Game Design where he does a great job of reminding developers just how important the subtleties of game design and intuitiveness can be for making a game successful.  From determining if your controls are natural to making sure that the user always understands what is happening, these are hugely important albeit basic things.  As I reach the end of my game development process I think my distance from the coding has helped me focus more on these basics (relating more as a constant beta user), but still I can understand the feeling of sometimes losing a grasp on the importance of simplicity and intuitive design.

While the ngmoco gamemakers portion of the blog hasn’t been posting for more than several months and really only has a handfull of posts, everything I have seen is definitely worth reading so if you are in game development you should add it to your list.

Update: The ngmoco blog has been updated with several posts with insights from the GDC this year.  There is a really thought provoking post about the future of the App store and the evolving opportunity with the coming SDK 3.0 update.  Here they talk about how the value proposition will shift from a one time sale to a longer term outlook.  In their words, “with social gaming and microtransactions in the form of level packs and virtual items, games will become more than the first impression and need to upsell their services.  That in itself represents a new market opportunity for content differentiation.”  Exciting indeed to think that we will all have to start thinking about creating long term value as opposed to one time gimmicks or successes; this should benefit the entire App gaming market by refocusing us to the task of creating games with strong foundations upon which to build a following and deeper games.

Related articles by Zemanta

• Hideo Kojima to Keynote Game Developers Conference [Hideo Kojima] (kotaku.com)
• Self Rescuing Princess T-Shirt: Games and Game Design (tcritic.com)
• GDC09: Interview With A GDC Hot Dog Vendor (the-minusworld.com)
• Boing Boing Video Live Streaming Game Developers Conference 2009 (laughingsquid.com)

1. With people you know, you will never get the brutally honest answers you need so try to go outside of your immediate circle.
2. Getting a thoughtful, helpful review takes more time and thought than most people you demo it to are willing to give. it is not as easy as it looks to try something for 15 minutes and then offer intelligent suggestions or feedback so usually people will just shout out their first thoughts to give you something.
3. Sometimes you don’t actually want to hear what testers have to say – by the time you are testing your game on them the idea is pretty near finished so adding or shifting anything major (which people always suggest) is basically out of the question.
4. For many applications, it is impossible to know your end market – you may think it is high school kids, but in the end it might be picked up by an entirely different demographic. The only way to know is to put it on the market.
5. Relating to number 4, if you don’t have a clear vision of where you game should go from the beginning don’t expect your testers to answer that for you.  Odds are your sample set will not be big enough to lead you to one conclusion over another.
6. Unless you are careless and sloppy, testing it yourself will spot the glitches / bugs in the game better than your testers – you shouldn’t rely on someone else to do this who probably has a more forgiving eye and definitely less of an interest in seeing your game work flawlessly.  The flip side of this one though is that you may sweat unnecessary details more than you need to.
7. It is easier just to go to the local mall and find people to test your product on the spot than do Ad Hoc testing (in this case Starbucks gift certificates work great)

I guess the issue I have is that it is hard to separate the review from the reviewer.  And as soon as you start to look at the different demographics in your test group you find yourself needing to decide what group you want to cater to.  Herein lies my app game design dilemma – do you take the feedback of one of your groups over the other or try to cater to all of them?  For example I had my 11 year old cousin try my game and he loved it, but then several older people played and said it was just too difficult.

Well I know that the younger demographic is more active with sharing and consuming these games but it is the older people with the credit cards on file – so what do you do?  The iPhone with its diverse user base runs the full range of casual to experienced gamer so you have to decide early who you are going after.  Ultimately you just have to stick to your original idea and wait until the users in the App store validate your product one way or another.

But the question is a good one, how do you let user feedback – before or after launch for that matter – affect the vision you have behind your application?  While listening to users is incredibly important, in the era of rapid updates and constant new releases, where you draw the line is getting challenged more and more.  I wonder how long it will be before someone crowd sources the design of an iPhone game from beginning to end?

Related articles by Zemanta

• How to make an iPhone game (tuaw.com)
• School that uses game-based learning opens in NYC — Boing Boing Offworld (boingboing.net)
• Second Life web resources for February 23rd 2009 (vintfalken.com)

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.

What I was wondering today is how much experience do you need other than the intuition behind knowing what you like when you see it?  I am not a gaming fanatic at all, I don’t own a single console or handheld gaming device and haven’t since the Sega Genesis!  I guess maybe the iPhone counts but I definitely didn’t buy it for the App store (purchased it a 4am after a night out in NYC on the day it launched – way before there was any talk at all of the App store).  I have played the Nintendo DS and it only interests me, as with all games at this point, if I can play with someone else.  The reason we are creating a 2 player version in our game is this: I only care about playing / creating a game for 2 players.  While I know that the XBOX live forum has mimicked this social interaction, for me I need to be in the same room with the person.  Trash talking just can’t be as much fun over a headset.

Crayon Physics Deluxe

So what do you think?  Do you think more formal game development training and experience is important for creating iPhone games or can designing a simple iPhone game work the first time by amateurs?  We have seen Trism and iShoot work very well but you could argue that these were copying general proven themes and thus were sticking to relying on what was already proven to work.  One example of a very unique game idea that popped up last year by an independent developer was Petri Purho’s Crayon Physics (just came out on the iPhone).  If you have other good examples of other first time developers with truly original game design I would love to see them.

Update: I found an interesting post here talking about Gogogic’s initial design process for their games where they use flash to run through and explain the most common usage scenarios before coding.  A great approach for any kind of application design.   Also, if you have not seen the Photokast slides on product design they have 15 great tips from their experience here.

Related articles by Zemanta

• Indie Games Summit Includes Rants, iPhone HowTos and a Little Love [Game Developers Conference 2009] (kotaku.com)
• Games: Crayon Physics Rocks (mo.notono.us)
• iPhone Dominates Independent Games Fest Mobile Award Finalists [IPhone] (kotaku.com)
• Article: iPhone Gems: Three New Action Puzzlers, Three New Shooters (ilounge.com)

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.

So although I have no proof that this first run of layouts will last or even be playable, I am going to briefly go into how I laid them out because I think it was fairly efficient.  First, I traced the iPhone and screen size in 20 boxes to one of those huge Post-it Easel pads (for those of you like me who don’t work in an office with miles of whiteboards this is a great solution).

Then I started laying out sketches in pencil of the game level walls, enemy starting points, bonus items, etc.  Doing them all on 1 page makes it easy to avoid repetition and to get a united visual view of how the player experience progresses.  I didn’t focus too much on having a perfect arc in difficulty level because I figure I can always change that either A) in the PowerPoint mock-up version or B) when it comes to seeing how the levels play out.

Once I was happy with the levels I just used powerpoint and took a screenshot of the iPhone simulator and used that plus some copied building block graphics off of the web to compose my tanks, walls, background, etc.  While none of these graphics will make it in to the game it helps to have a visualized version so that the functionality can be developed in parallel with the graphics.  One thing that became very obvious once the levels were laid out though was that the AI behind the enemy movement is going to need to be good otherwise the game can easily become unplayably hard or easy.  I am trusting Taras and his team to help offer some insight as to how best create a good user experience.

Related articles by Zemanta

• Passage creator releases Primrose, an iPhone puzzle game (tuaw.com)
• Review: iShoot for iPhone (mobilecrunch.com)
• The World in my Hands (digital-teacher.co.uk)
• ReachMyFile allows you to do just that (tuaw.com)