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.

Programming Trick: Speeding up your recursive loops with a creative technique

Lately, I’ve been working on a new game project which is very different than all the other ones I’ve done so far. I’m planning on waiting until it gets a little further before I write about it in detail on this blog, but I ran into an interesting technical challenge and I’d like to discuss how I solved it.

To implement the game mechanics I need a graph of nodes, with various connections between each node. I have a need to find the shortest path between two nodes, where the path is calculated by the sum of the length of all connections as part of the path.

I started out with a simple recursive algorithm that started from each node and worked backwards to find all possible paths to get to it, and used a map to store the best connection to move, given a certain intermediate node and a certain destination node. This worked really well, although after around 13-14 iterations on a graph with many connections it started taking over a second to compute and them getting exponentially worse.

One option was for me to search for a more proper algorithm to find the shortest path, and I am sure this has been perfected by  programmers over the last few decades. But I had a secondary requirement to also store all non-optional paths as well, so some of those algorithms probably wouldn’t suffice.

Looking at my recursive function, I realized that there really wasn’t much going on in terms of sub-functions it called that do any significant calculation. If there was, I could try to optimize those or cache up some result. But the question remained – what was taking up all the time?

Looking at the function again I saw that I was passing four different arguments into it. If you have ever studied assembly, you probably know that there are several instructions just to push and pull each of these to and from the stack, and since the function is called so frequently I thought that maybe this added up to a big chunk of the total time.

I decided to test my hunch by making all the parameters into global variables. I purposefully didn’t use class variables since I knew there would be extra lookups required, translating to extra work for the CPU.

It was a bit of work to make this transformation, since for non-pointer variables I had to manually save the state before calling the recursive function, and then re-set it. But this was only for two of the variables since the other two were pointers anyway which were supposed to change (one was the map which stored the nodes that had already been traversed so far, and I already had code to adjust that when returning from the recursive function).

The resultant code was a bit harder to follow, but the performance was significantly better. For the test case I was using I was able to get several more iterations before it got significantly slow (>1 second), if I remember correctly to at least 19-20 iterations.

If I keep adding nodes and connections eventually it still gets slow again, but I will probably put limits on these anyway so I may be safe with this solution for the time being.

Although I enjoy designing games from a high level, after many years of coding I still enjoy these types of algorithmic challenges, and the satisfaction of a well-tuned function.

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.

Mobile Game Review: Does Not Commute

Does not commute, by Mediocre AB, is a game for the iPhone/iPad which was originally released on April 15, 2015. It recently won an Apple Design award and was listed in a special category in the app store, which is where I discovered it. I only played the iPhone version so this review is limited to that.

The game has a pretty unique concept: your objective is to drive a series of vehicles through a city, each from a starting point to a destination point. The interesting part is that as you begin controlling the second vehicle, the first vehicle starts taking the path you choose at the same time, and each successive car’s path gets layered onto the map until it becomes difficult to navigate and reach your destination in time.

If you are able to help all vehicles reach their destinations before time runs out, you get to go to a new area of the city which is effectively a new stage. On the way you can grab items to increase your remaining time, and use the rewind mechanic to retry the path of a car, though you loose some time in the process. Each vehicle has a little different steering, and there are upgrades to can get to improve things like traction. Hitting other objects damages your vehicle, which makes it start smoking and slow down.

The strongest point of this game by far is the graphics, which are done with an extremely visually pleasing top-view rendered with 3D and heavy use of lighting effects, such as headlights for each vehicle. The models are pretty simple but generally good enough, except for some of the lakes which look badly designed. The visual effect during the rewind function is pretty cool looking, and the intro pages are also very nicely designed. Above all, the entire game has a very distinctive visual atmosphere.

I enjoyed this game for around an hour but eventually started to get bored with it. One of the reasons is that the control of vehicles is pretty limited, such that you can only turn left or right, with no braking or acceleration. Also, I found the top-view much more disorienting to drive than a typical first-person view, though I understand why they chose the former to fit with the concept of each car commuting simultaneously.

Does not commute tries to give a personality to each character by giving a short textual description of what is going on in their life and why they are in a hurry, but I found that underdone and insufficient to make me care about any of their lives.

Having said that, with stunning visuals and a very creative concept, this is one of the better games I’ve played on mobile in the last few months, especially considering it’s a free game (with some In-App purchases).

Game Review Web Sites: it’s a dog-eat-dog world

For my latest mobile game I’ve been advertising on many different web sites whose primary purpose is to review and showcase games or apps. It has only been a few days since I did this so I don’t have much data yet, but I hope to eventually post about whether it was worth it to spend my time like this on advertising.

While I was searching for sites to post to, I discovered a few interesting things about this area of the net. Among these was the level of competitiveness between the various sites, and how these harsh conditions make for a pretty high closure rate of such websites. I realized this because roughly one-fourth to one-third of the sites I tried on a list from a few years ago (see this post) were completely gone. Others had changed their name, or began charging for even a basic listing.

I find it intriguing how an over-crowded and hyper-competitive mobile app market ends up creating a hyper-competitive market for websites advertising these same apps. Ironically, these sites have to market themselves using many of the same techniques, via things like SEO and using forums to advertise. Ultimately, all of these web sites must earn enough money to support their hosting and development costs via some form of paid advertising, such as charging for reviews or expedited listing.

The smaller a review site is, the easier it will be to get your app on there, but the less useful it will be because of the smaller amount of traffic to that site. Everyone wants to submit their apps to the sites with all the hits, and submitting them to the minor sites is less important. You can see some of this in my brief look at some page view hits when I advertised my previous game, where there was over a 10x difference between the site with most hits and least hits.

The funny thing about all these sites is that I think the average user doesn’t even know about them. I’ve been getting apps for iOS for years now, and until recently I’d say 90% of the apps I got were found directly on the Apple App Store, or because I heard about it from a magazine, news site, or word of mouth. Of these, discovery from the App Store leads to a very biased selection (with many games that make me want to scream “why is this popular?!?!”), but as a user it’s just so easy to do, instead of fishing through hundreds of review sites.

I think the fact that iOS apps can only be sold directly through the App Store is one reason that people are less apt to try out other stores, since you’re not going to find any good deals there. Compare this with how you can find various PC or console games in online retailers at varying prices, including used copies.

I’m starting to get the feeling that these app review sites may not really be worth my time (except possibly the most popular ones), though I don’t have enough data to make that judgement yet. But I’m quite confident that a really great app or game doesn’t need to be advertised on 1,000 different sites to become popular.

Mobile game poll

It’s been about a week since my latest game for the iPhone, Dokusen: The Art of Domination, has been released. I am planning on writing more details about how the game is doing in the App Store, but for now I’ll just say it is doing much better than my previous game based on the data from first few days.

In order to get some feedback on the game to help me improve it and future games I create, I’ve created a simple poll.

If you have a iPhone device, you can check out the iTunes page here and download it if interested. Or if you are not looking at this page on your mobile device, you can just search for “Dokusen” in the app store on your iPhone.

If you can’t or download want to download it that is fine too, but please consider taking the poll to explain why that is so.

You can also check out the game’s app preview video here.

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.