Game development: reducing scope (traffic simulation)

One of the tricks of game development, especially that done by small teams, is reducing scope of each feature or element to a minimum necessary level. It is critical to make efficient use of developers’ time since there is only so many cycles available, and the longer a project goes on the more likely it is to get cancelled or postponed. The more games you get under your belt the more you start to care more about this kind of stuff.

To give an example of this – one of the core elements of my latest game in development is a series of connected roads with cars running through them, a little like what you would see in a modern version of a SimCity-type game. Starting several weeks ago, I experimented with several different ways to implement this “traffic simulation” element in my game.

Initially, I started with the idea that I would use Unity 3D, since that would allow me to show a very realistic simulation of cars moving through a network of roads. I was inspired by the mobile game Does Not Commute, which uses a 3D engine to good effect.

However, after learning a little more about the Unity 3D workflow, I realized I would be spending a big chunk of my time on the graphics and other 3D elements, which would make the core gameplay elements (behavior, logic, rules) take that much longer to do. Though the end result might look quite attractive, I had doubts that I could finish the game on my own if I took this route.

So for the time being I decided to make the game 2D. My next decision was whether I should use a physics engine or not. I’ve been interested in physics engines myself for some time, having made very simple ones years ago, so I decided to download and experiment with a few different frameworks, including Box 2D. In only a few hours, I was able to get some test programs running and there was a surprisingly rich set of functionality for the free frameworks I tested.

But again, I posed the question to myself – do I really need detailed physics simulation? Is having cars collide, spin out of control, and follow a physically accurate path really critical to my game’s core gameplay? While this would be a cool feature, I eventually decided this was overkill, and again reduced the scope of my traffic simulation efforts.

At this point I entered into prototype development, spending my evening hours making a bear-bones traffic simulation where each car was resented with only a handful of properties such as color, location, and speed. I got this working and am now experimenting with different game objectives, and creating stages to see what is actually fun (and challenging) – the most important aspect of any game.

If things go well and I feel I’ve made an entertaining prototype, I can continue to polish the visuals, or even consider going back to 3D. With a proven game idea, the risk for failure would be greatly reduced.

If I had determined that simulating cars as individual entities was not a critical element of my game, I could reduce scope yet again and simulate at a coarser granularity. For example, in the original SimCity game (which happened to be the first game I purchased with my own money), traffic was handled by road-piece granularity, where a stock animation was selected based on the traffic density of that area at the given time. You couldn’t follow a single car around since they would appear and disappear if you looked closely. While a system of roads was important in building an efficient city, tracking an individual car from point A to B wasn’t necessary, and players had more to concern themselves with. Also, I believe the original SimCity was only made by two or three developers. In more recent versions of that series it seems that cars are modeled as individual entities.

I’ll post some more about this project as things progress.

Dokusen: The Art of Domination (iOS puzzle game) — A month later

It’s been a month since I released my latest iOS game Dokusen on iTunes. At first I considered polishing some aspects of the game and releasing an update, but to be honest the idea of developing a new game from scratch is more attractive, so I’ve stared down that path instead. So in a sense you can consider this post a “post mortem” of this game.

At heart, this game was an experiment to see if a bigger focus on visuals would reflect in more popularity in the store. I also spent a much larger chunk of time advertising on net forums, on roughly 20-30 different sites.

From a downloads perspective, my personal goal was to get at least twice the downloads of my previous game. Initially things went great, with the number of downloads from Dokusen in the first two days surpassing those from the first week of my previous game. Unfortunately downloads suddenly decreased after that on the 3rd and 4th days, such that I only reached 75% of my target downloads (to date, Dokusen got 1.5x of my previous game’s count). Though this is a bit of a disappointment, I should look on the bright side because at least things are going in the right direction. The large spike on the first two days is still a bit of mystery to me, since with previous projects downloads leveled off at a much slower rate. Oddly, I got a large majority of downloads those first two days from France.

These numbers are a further confirmation that advertising on net forums is not a great way to pull in downloads. I did, however, get some good feedback on the game’s rules from on a board game forum I posted on, since it shares some elements with Go and Reversi.

A week or two ago I talked to one of the people who informally tested for me, and he remarked that my previous game was much more fun and easier to understand. This was good feedback, though altogether not that surprising since I feel the same way. Ironically, with Dokusen I had tried to build a game that would be popular with others, but not necessarily myself.

For my next game (codename “T.E.” for the time being), I am planning on making something which I enjoy more myself, in terms of both coding and gameplay. I also plan to make a proper tutorial, as well as get more playtesters (please leave a comment if you are interested in helping). This next game is rooted in a longtime passion of mine, and the work I’ve done on it already is more challenging and interesting than Dokusen. I’m aiming for a release in 3-6 months if things go well.

Though I implied this project was mostly done, I am always open to feedback on Dokusen or any of my other apps. If you looking for someone to review your game I am OK with exchanging reviews of your game for mine.

Mobile Game Development: learn your weaknesses and strive for consistent quality in all areas

Having taking a few iOS projects from conception to release on the Apple Apple Store, I’m starting to discover patterns in how I go through the development process. I plan to use this information to tune how I handle future projects, resulting in efficiency improvements as well as a higher quality result, hopefully leading to a larger user count.

I recently became more aware of the stages I go through in a typical project. I start development in what I would call a “creative” stage, where I am thinking of new ideas and enjoying the implementation process, as well as the iterative design that goes along with that. At some point when the project far along enough, I start to feel the need to just release something – what I’ll call the “get it done” stage.  I think this stems from my fear that other things will come up in my life and not have time to finish the project, or that I’ll just get bored of it and quit partway through, similar to why I would be hesitant to start reading a long novel.

The “get it done” stage is dangerous because the remaining tasks are done quickly, with lower quality than things done in the “creative” stage. For example, I usually create my app’s icons near the end of the project, and rush to just get something that looks reasonable enough. This is a bad idea since an icon is an extremely important part of the overall marketing presence of an app, and some people have even claimed changing only a game’s icon resulted in a major change in the download rate. Another example of this is creating a tutorial, as well as general visual polish.

For my next project, I’m going to try to get myself to think more long-term, and not jump into the “get it done” stage until the product is nearly ready to be released with high all-around high quality. It may be appropriate to rush to the finish line if there is a hard release date you are aiming for, for example to coincide with the release with a new OS version. But in cases where no such deadline exists, there isn’t much value in pushing things.

I am not sure if it is an appropriate comparison, but this reminds me of when I used to train in running to shave time off my mile. I measured how long it took for each 1/10th of a mile, and I found I got the best result when I had a good balance between these times. As opposed to having one or two areas where I sprinted and exhausted all my energy, a consistent good speed gave the best result. I feel that app development is similar, in that a consistent push through all areas is the best way to get a well-rounded product.

If I feel like I am too busy to make proper progress on a hobby project, rather than rushing it to release I’m going to try to just take a break. Odds are that I can just continue where I left off, whether it is a week or a month later.

The exception to this discussion is if you are working on your first mobile app or game. In that case I think it’s OK to just get something on the store, since you’ll gain valuable knowledge going through the entire process for the first time. For your second project, you can slow down and properly plan things out using your newfound knowledge. If you are worried about a low-quality app giving you a bad reputation, you can always pull it off the store at any time.

Apple Connect App provides incorrect download statistics

I check my app’s download statistics on Apple’s Connect app pretty frequently, and was surprised when a weekly total for my latest app was significantly less than the daily count from a few days ago. I tried restarting Apple’s app, but got the same figures.

Starting to get concerned that the figure reported a few days ago was mistakenly inflated, I checked the download statistics on the iTunes Connect site (under the Sales and Trends area), and was relieved to find the aggregate numbers there were close to what I had seen in the app for the daily numbers. The numbers in the App Analytics page are all still zero, probably because the app has only been out a week.

I have no way to verify for sure which number is correct, but the odds are that the aggregate numbers being displayed in the Connect app. In my case, the numbers were over 10x smaller than they should be, which is a pretty serious bug.

If this doesn’t correct itself, I may send Apple a note since it’s pretty bad a bug this basic could escape unfound by testing. But maybe it only happens in a rare situation that doesn’t effect most users. Though the numbers are slightly different for my apps that have been out for several months, the difference is no more than 10 downloads.

If a company like Apple can’t provide accurate download statistics, it might be wise to consider using some 3rd-party SDK like Flurry which should give a more accurate count, plus much more information on how your app was used. I haven’t tried this myself, but am considering it eventually.

If anyone has noticed this bug please let me know.

An argument for longer app store approval wait times

If you aren’t already familiar with the process of submitting to the Apple iOS App Store, lately you have to wait an average of 11 days until your app is approved. That assumes things go well, however, and if they don’t you could end up getting rejected, resubmitting (or appealing) and spending a month or more until your app actually gets listed, if ever.

The first time I found about this I was pretty annoyed, and I imagine that many of you felt the same. This can be ever more frustrating if you know that the Android store typically takes a day (at most) for the entire process, or so I’ve heard.

After going through this process a few times, I’ve finally come to the conclusion this large wait time actually benefits both the developer and the app store, for several reasons.

First and foremost, I feel that developers who know in advance they’ll have to wait for over a week will typically strive for higher quality than with a quick review process. I’ve seen this in my (very subjective) assessment of iOS vs Android apps. Specifically, developers are more likely to test their app more thoroughly because they know any bugs they find later, no matter how small, will take quite some time to get in the hands of their customers (though I’ve heard in rare cases Apple will make exceptions to fast-track critical issues). Also, since the iOS App Store has an image of being ‘strict’ in terms of what it permits, this will make developers think twice about much of their code, and as a result use APIs more properly. [I’ll leave the matter of whether the Apple app store is actually ‘strict’ for another article]

Another way to look at it is the professionalism, and sense of really releasing a product that this long delay gives to the developer(s) involved. There’s a feeling of satisfaction that you did something significant, and maybe even had a bit of luck on your side.

Although devs have the option to keep working on their app or game while waiting for app store approval, I generally don’t recommend this. The reason is that if you get rejected, you’ll probably want to submit the same exact version you submitted previously, with one or two surgical fixes, as opposed to a version with a bunch of new things that might fail the approval process in a different way, complicating things. If you are using source control this shouldn’t be hard in theory, but merging your changes can still be an annoyance.

I find this week or two period of respite really good for my mental state – it allows me to take a break from all of the focused development I’ve been doing and clear my head. This is a good time to put on your marketing hat and begin final planning of where, how, and when you will advertise your app or game once it is released. Hopefully you submitted it with the option to wait for manual release to the store after the approval process is complete, since this allows you some freedom for when you release. This is important if you are aiming to release on a certain day of the week, for example.

Other options for this break time are to begin planning what your next set of features will be, or even what your next app or game will be if you are ready to make that jump.

With all the money Apple has, it shouldn’t be too difficult to hire a bunch more people and keep the approval process to a maximum of a day or two. But I believe  they are purposefully keeping it roughly a week (with some variation) because of these benefits.

The only real disadvantage I can see to the long app store approval (besides frustration and uncertainty) is that if you working with a customer you might have to wait longer until you get paid. For one-off projects this can be troublesome, but anyone trying to make a business dealing with apps should consider pipelining several jobs at once, so that while they are waiting for approval for one job they can be progressing on another.

On a final note, I have heard many reports of Apple being inconsistent or illogical with some of the reasons they deny apps from the store. I think some of this is because consistently training everyone is difficult, but also for budgetary reasons because being extremely strict for all apps would take even more time. I see some parallel to the IRS’s audit process, whereby a few people get a stricter review and as a result the average level of adherence to the rules increases.

Game development and the art of wearing many hats

I’ve been thinking about making a new mobile game and have started work on prototyping and basic implementation. I plan to post on that more in upcoming weeks but today I wanted to write some more about game development in general, especially when done as a hobby by yourself or on a small team.

If we look at software development as the practice of writing code to fit a set of detailed requirements, the set of tasks involved is relatively well defined. Define the high level implementation, including modules and how they interact, then gradually drill deeper down until you get to the function level and are writing small chunks of well-defined logic. This is no means an easy job, typically requiring knowledge of one or more technologies or languages (iOS, objective-C, etc.) and possibly third-party frameworks (i.e. Unity). Implementation itself can take a handful of people to hundreds of people anywhere from a few hours to several years, but the point I’d like to make is that you can generally see the road ahead and make gradual progress [Exception: projects that stretch the limits of technology]. Worst case, you reach a testing phase and find out your design doesn’t support an important requirement, at which point you may need to re-design the modules or some algorithm.

Now lets take a step back and look at the scenario where there is no requirements document, or any clear set of things you want to accomplish. As a hobby game developer, you might just “want to make a cool game”, “want to make a RPG like Final Fantasy”, or maybe “just make a game that becomes popular”. Note that I purposefully omitted “want to make money” since that is one of the most difficult goals for a small team.

Here what you are supposed to implement is vague, or at worst totally undefined. If you are the perfectionist type you can take the ivory-tower approach, and write pages and pages of a specification document about what you game is going to be like: the world, game mechanics, interface, etc.

But as a hobby game developer, you have limited time and being an idealist just isn’t going to cut it. The only way you are going to get anything done is by bouncing back and forth between implementation and inspiration (design) modes. This can involve building a set of prototypes, or fine tuning a more fleshed-out implementation, but you can’t avoid jumping back and forth between these two modes. This is because that whether something is fun or easy to use is very subjective and requires someone actually playing the game.

Without design there is nothing to implement, but without implementation you don’t know if what you’ve designed is actually an enjoyable game. In some cases, you may not even know if it’s possible to code in terms of technology and development time. For example, if your game involves natural-language input (like classic adventure games), you need to either develop this technology yourself or find a third-party library. If during prototyping you discover you can’t properly parse the types of language you want the user to be able to input, you might have to go back to the drawing board and re-think the game’s interface.

If you are working by yourself, you’ll have to put on even more hats during this process: visual artist, sound designer, scriptwriter, gameplay balance engineer, QA tester, etc. There is research indicating that, for the average person, multitasking like this takes a toll on productivity, so you have to fine the right granularity of work to minimize this overhead.

Personally, after many years of doing software development as a career I’ve improved my ability to implement quickly and efficiently, and much of this carries over to my hobby game development activities. But I have a great deal to learn as far as design goes, especially the tricky act of juggling the many roles of a game developer.

I’d argue that the art of smart, efficient multitasking – knowing where and how much to spend your time at any phase in the project – is one of the most important skills to learn as a hobby game developer, and one of the hardest to learn. Another one is scoping (maybe a good topic for a future post), which means determining how much stuff you want to fit in a project for a given timeline.

Note: this post was inspired by this post I just read.

Difficulty in gaming

Difficulty of a game, how hard or easy it is and in what way, is an extremely important factor in game development. This is something good to keep in the back of your mind in nearly all stages of game development, including brainstorming, prototyping, implementation, and testing.

It’s easy to think about difficulty in simple terms (e.g. “This game is easy”, or “This game is hard”), but it’s actually much more involved than that. In this article I’ll discuss some of my ideas about difficulty in games.

Types of difficulty

Rather than a purely linear continuum, there are different types of difficulty that are good to be aware of, especially when deciding on your target audience. It’s pretty rare to find a game that just involves one of these – usually you get a mix of two or more.

A common type of difficulty in many games is calculational. These types of games challenge you to think ahead several steps and predict the outcome of a combination of events. A classic example of this is chess, and the ability to calculate ahead a few moves (along with a few other factors) is one of the keys to being a strong player. A related type of challenge is tactical, where players have to think about the relative positions of friendly and enemy units (ships, planes, tanks, whatever), and predict what the outcome of a battle will be.

Reaction time is another type of difficulty which can be seen in many popular mobile games like Mr. Jump or Alto’s Adventure, the latter of which is currently the #1 paid app on iTunes. In these types of games, besides being able to respond quickly to changes in your environment, you also have to estimate things like distances and paths you will take.

Memory difficulty is one that is less common in mobile games, though having a good memory may make it easier to remember common patterns to solve puzzle games. A good example is the class board game “Memory”. A language learning game that tests your knowledge of words using a flashcard-style interface is another example.

Another one is endurance difficulty, which means that you have to survive a long time in order to pass a certain point or level in the game. An example of that is many RPG games where bosses can take 30 minutes or longer to beat. The placement of save points (or some other mechanism to save state) is an important factor here. One of my pet peeves is games where you die after one mistake, putting you back minutes or even longer.

One final one to mention is system difficulty, which can also be called learning curve. By this, I mean the time required to learn the basic rules of the game before you can actually make any progress. A game with good tutorials reduces this type of complexity, otherwise it can take the user much experimentation to figure out what to do. I’ve played a few mobile games that seemed really great at first, but I lost patience and gave up before I got the hang of the system.

There are many others, such as deduction, but I think I covered the most common ones here.

Satisfaction and actual vs perceived difficulty

For a straightforward game like chess, the difficulty is obvious and there is no effort to convince the player otherwise. For other games, like the famous mobile game Candy Crush, there are a lot of distractions to take your mind off the basic gameplay elements. Candy crush has sound effects, exploding animations, and messages that pop up now and then to complement you (for example, “Sweet!”). As a result, you could tap somewhat randomly and feel like you are doing an awesome job. (Confession: I have not played this game for more than a few seconds, so I can’t claim to be an expert on it’s gameplay)

Ultimately, what’s more important than the objective level of challenge is the satisfaction gained by the player when he or she makes progress. If the game can fool you to thinking that you did an awesome job at the “difficult” task of randomly tapping, then great.

Difficulty ramp-up

How difficulty increases in your game is another important factor. Is there a bunch of levels with similar difficulty until you get to transition point when things become suddenly harder? Or do things gradually get harder as you progress? The user will quickly create their own expectations after playing your game for a few minutes, and if you betray those frequently that are liable to give up.

Another important factor is how/if you notify the user about the difficulty for each level or area. Is there a big sticker that says “HARD” on certain levels, or a color scheme? Is hinted at from the name of the level?

When you do increase the challenge level midway through a game, consider giving them several options. For example there could be three stages, from which they only have to beat one to move on. Forcing users to beat a certain stage which is extremely hard, with no other options, is one way to quickly alienate your users.

All or nothing vs optional goals

Rather than requiring perfect performance to complete a level, a common technique is to allow getting through the level somewhat easy while including optional goals that give extra points. For example, some mobile games will show you one, two, or three stars, indicating how well your performance was on a certain level. You can usually replay any level to try and get a better score, and replay value is always a great thing for games. This is another way to reduce the chances of users getting frustrated and giving up on your game.

Interpretation of difficulty

Ultimately, difficulty is a very subjective thing and varies between users. One game I might think is a piece of cake you might think is a nightmare, and vice-versa for a different game. Users may be less inclined to worry about the difficulty if the game has nice visuals and enough feedback (like the Candy Crush example above).

For seasoned gamers, each genre has it’s own expectations dictating what is reasonable. For example, many console RPGs from the 80s were known to have hours without a save point, and those who beat them got bragging rights. Users will be comparing your game to others in the same genre and if you deviate too much it may catch them off guard. For example, a puzzle game where the first few puzzles each take roughly 3-4 hours would be pretty unorthodox and scare away many players.

Because of the subjective nature of challenge, doing proper beta testing with users from your target demographic is extremely important to a successful game. Ideally, you would watch while they play, observing where they got stuck and where they blew through effortlessly. Ask each of them how they felt about the difficulty – was there any surprises and was it satisfying enough?

Using only main developers for gameplay testing is dangerous because they have a very biased view of game, with prior knowledge the basic rules and tricks. Until you show someone outside the team you’ll never really know how difficult and intuitive the game is, and the more people that playtest the better.

In fact, one can get a good feel for the difficulty of a game before the visual polish is complete, so consider making quick prototypes of the basic gameplay and having your testers try those at an early stage in the game’s development.

(Image credit: http://www.gratisography.com)

iOS development: why did my downloads plummet after only a few days in the store?

For those of you dabbling in iOS apps, you may have noticed a phenomenon whereby your app’s downloads drop significantly after a few days in the app store. You might have been getting ~30 downloads a day but now it’s only 1 or two. Not only have I experienced this myself but I’ve heard the story from a few fellow developers. What gives?

I don’t have any official information on how the Apple app store works, but I’m pretty sure I have a good idea what is happening here.

If you think about how people find apps, the number one way is surely through the app store itself – browsing the latest recommended games, new games, or in some other specific category or list.

None of these categories is infinite, and even if they were, mostly people would just look at the first few on the list. So the question is where and how Apple decides to showcase new games in their store.

They could give everyone a limited time (say one week), and then remove them – but that isn’t optimal since after all Apple’s goal is to get the total number of app downloads. This is obvious for paid apps since they get a cut, but even for free apps, the more people download games on their devices the bigger their market share is. And free games always have the chance to evolve into games with in-app purchases later.

Given this motivation, what they are likely doing is giving all new applications a chance, which means listing them on some relatively high-visibility category. I’m not sure if that is the “new apps” one or something else, but the exact place doesn’t matter. They do this for approximately a week, and then based on the number of downloads, they decide to either keep that app on the list, remove it completely, or maybe even upgrade it to a list with even higher visibility.

So if you happened to get a hundred downloads in the first week, you might be wishing to at least retain that level of popularity, but Apple determines this is not nearly good enough and declares your time in the limelight is over. You could beg to Apple and say “But, if I only had a few more weeks I would gather so much more popularity!”, to which they would respond “Sorry, you had your chance.”

With a huge number of new apps coming in each week, I’d say they are forced into this sort of strategy.

There are some unanswered questions here. For example, do they ever give you another chance on a high-visibility page? What happens for updates?

I don’t know all the details, but based on my recent experience they don’t seem to be giving another full chance when there is an app update – thought it could depend on the extent of the update.

What this all translates to is that to really have your best chances for a popular app, polish the heck out of it before putting it on the app store, since your first week may be your best chance to show Apple your app really has what it takes. Even without Apple’s help, you could advertise your game various places and eventually build up a big user base, but that’s significantly more work and takes much more time.

iOS development: Don’t unknowingly limit your users

Recently I asked a friend to try Play The Field, after which he replied he could not because the game required iOS 8.3, but his iPhone was currently still at 8.1. I hadn’t realized the app was set such that “Deployment Target” (in the XCode project’s General settings under “Deployment Info”) was set to 8.3, which means that 8.3 is the minimum OS required to install the game. This was very valuable information, and in the next release I’ll change this to 8.0.

Just be careful because your program may be using Apple APIs which aren’t supported by certain older OS versions. The father back you go the more you have to worry about writing code to dynamically detect the version and use alternate APIs.

If you are new to mobile development you might take the stance of “Why don’t the users just upgrade to the latest OS?”, but that naive stance won’t help you get any more downloads. There are several reasons people might avoid an upgrade: risk avoidance of new bugs and security problems, inability to upgrade on a jailbroken device, and fear of bricking their device. You may think having a device destroyed by an upgrade is impossible, but I have had a MacBook Pro totally messed by a failed OS upgrade before.

I doubt that once I remove this restriction the downloads will come pouring in, but it’s literally a single click to fix (excluding the whole process of uploading a new version to the app store, which I would have to do eventually anyway). Creating an iPhone version was significantly more difficult, but had the same end result – reducing a reason that user’s couldn’t download the app.