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.

Mobile Game Review: Quantum Cheeks [iOS/Android]

I came across Quantum Cheeks on a fellow developer’s blog on WordPress, and decided to review it. It’s the first game from a small team of developers who are learning Unity, and the tone of my review takes that into account. The game is out for Android, iPad, and iPhone. I only played it on iPhone 6.

The concept of the game is simple – guide a hamster through a series of radioactive barrels. The controls are very simple: click anywhere on the screen to make the little thing jump out of his (her?) current barrel and hopefully into another one. Many of the barrels are in constant movement, rotation or translation along some path, and the core gameplay element of this title involves getting the timing right with respect to the barrels on screen. Each stage ends when you reach the ladder at the end of it. There are also some seeds you can collect along the way to get extra lives, similar to coins in Mario Brother.

The graphics are fairly simple but sufficient to support the gameplay. There are some little visual touches that caught my eye, like the fireflies on the first world. There was clearly a bit of effort put into this effect since their paths seem dynamic and there are different sizes of fireflies, plus a fading effect in and out. There is also a nice parallax effect with multiple layers of background, but I had to really pay attention to notice it. One minor nitpick is that the resolution of the barrels on the first world is too low and could use some refinement. The barrels on the second look pretty nice, though those on the third stage have a weird design, maybe a space ship?

Because of some issue I wasn’t able to hear sounds or music, although I think it is supposed to be there. Will update this post if I get that figured out.

My favorite thing about this game is element of shooting a hamster back and forth between barrels. It’s challenging, a little addicting, and adding the “hamster” idea gives life to what would otherwise be a dry physics simulation. I am not sure if the team plans to keep working on this game, but I think it would be interesting to expand on the concept, with more barrel types (maybe ones that explode after a single use) and more interaction with the world, for example bouncing off walls and such. Since they already have a physics engine I think some of these additions wouldn’t take that much additional development time.  I also like how you can just randomly shoot in one direction and have a chance at hitting a barrel in the distance, and I think if they can foster this sort of experimental play the game could be even better.

My biggest issue with this game is the bugs or inconsistencies I saw, which I notice even more being a software developer. I’ll give a detailed list here because I think they can probably fix these in a follow up release if they like.

1) Sometimes clicking on a barrel doesn’t seem to do anything. I noticed this mostly on barrels that are rotating back and forth 180 degrees, since it requires nearly perfect timing to eject the hamster at either endpoint. I would allow ejection at any point, and if the designers really want to limit this, queue up a click and eject when a valid point is reached.

2) Sometimes a rotating barrel will start ‘twitching’ back and forth for several seconds, after which it eventually stabilizes again. Seems like something has gone awry with the physics engine here. 

3) Once or twice it seems like a barrel ejected me before I touched the screen, though this is hard to reproduce.

4) There was at least one barrel (pointed up and to the right 45 degrees) which seemed to have less power than the others, so the distance the hamster was projected was unexpected.

5) At least once, I saw the game end before my character was completely off screen (on the right side). It would have gone off screen eventually, but the timing caught me off guard. This one is very minor, though.

6) I usually played the game in landscape mode, but there seems to be several issues with portrait mode which automatically triggers upon device rotation. Rather than go into all of them here, I recommend just disabling portrait altogether since it’s probably not worth the effort of supporting it.

In spite of these issues, the game is still fun to play, and I recommend you check it out. If you do, please consider giving their team feedback, since as a developer I can tell you this is one of the most important things for them (:

Link to the game’s release blog post with download links: https://rhyskucharski.wordpress.com/2015/07/04/quantum-cheeks-has-launched/comment-page-1/#comment-7

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.

Hobby Game Developers: to use version control or not?

Version control, sometimes called source control, is the process of using a program to manage multiple versions of a software project, typically saving things in a remote database or similar structure. There are many version control packages available, including CVS, ClearCase, Perforce, and Git, the last of which has risen to great popularity in the last few years.

There are several advantages to using a version control package, with some of the major ones being:

  • All changes are backed up, so if data is lost or accidentally erased on your machine you can recover it.
  • By looking at the various revisions in the system, you can follow the flow of changes. This can really help out in triaging bugs for complex projects.
  • You can work on several different versions in parallel and do an automated merge at some point to join the code from two or more versions. This comes in handy if you have a stable version that you are submitting to the app store, and a an experimental one with unfinished changes. In team projects where a single source file or module can be worked on by several people at once, this is even more important.

For any project that has more than two or three people, I’d say that source control is a necessity that can save hours if not days or work, especially for complex projects. Most of the projects I worked on in my day job used some form of version control.

However, for a hobby developer that is working on a game by him or herself, the advantages are much less. I’ve tried to use Git for one of my hobby projects, but ended up never needing it. This may be because of some habits I have developed over time. For instance, when I am going to make a major change to a function I often will copy that function, and keep the original one. This makes it easy to go back to the original if I end up breaking something, or decide the refactor I was attempting is not worth it after all. Also, I typically make sure my code is buildable every few minutes, as opposed to writing hundreds of lines of code for hours, and then trying to build. If you get a compile-time failure in that scenario, it can take quite a while to figure out where things are broken, and source control can potentially help there.

Instead what I do is simply zip my entire project directory and email myself once a day, so I have both a basic backup and ability to check previous versions. But I’ve almost never needed that, I do it primarily for peace of mind just in case my machine’s HD crashes – something that has happened more than once.

If you are on a Mac, you can use the Time Machine feature which will allow you to look at older versions to see what changed. However, unless you buy something like an AirPort Time Capsule or similar external storage solution, you are not protected against data lost. I just bought one of the capsules the other day, and it was pretty easy to setup.

If you are doing hobby game development by yourself, you’ll have to weight the pros and cons and decide what is best for you. If you don’t have experience with a software version control system, it’s probably a good idea especially if you consider making software development your career. I’d recommend Git since it’s popular, free, and you can set it up initially using just one machine (and expand to a remote machine later if needed).

Even if you are working on a hobby game with a handful of people, depending on how well segmented the work is you may not need a source control. For example, if one person is working on art, one on coding (implementation), and one on testing and story, then you may be able to craft a workflow which doesn’t require source control.

One more advantage of using source control even if you are working alone, you always have the option of easily sharing your code with people around the world, especially if you are using an internet-based system such as GitHub. This makes it easy to grow your team if things go well.

Are you hobby game developers out there using source control?

Lessons learned doing sound on iOS – the real story

A few days ago I wrote an article about using sound effects in iOS games. Just today I was doing some more testing and realized I had made a major mistake, and some things I said in that post were wrong. In this post I’ll let you know what I had did wrong.

I alluded to a single line change that would allow playback of MP3 files. Here is the specific line:

NSString *audioFilePath = [[NSBundle mainBundle] pathForResource:sampleName ofType:@”caf”];

I had simply changed the “caf” to “mp3” and since I was getting sounds I assumed things were working. The weird staticky sounds I got I explained by saying that several of the same sound were colliding and causing such an effect. Though sound collision can be a problem and sometimes it might make sense to have several variations of a sound effect, what appears to have been actually happening is that OpenAL didn’t know how to process MP3 and so it was just generating random noise.

After a tried a few different .MP3 files and they all sounded pretty much the same, I finally realized what was going on.

The solution was to return the code to use “caf” files, and use a line like the below to convert MP3 files to CAF files.

> afconvert -f caff -d LEI16@44100 chop.mp3 chop.caf

After doing this, my sounds finally started playing properly. I did find some strange effects that occur when sounds overlap quickly, but they were more subtle.

One additional step that is good to know is you will need to manually tell the .caf files you added to your project that they need to be included with the bundle that gets copied to the device. You can do this by dragging the file under XCode’s Build Phases => Copy Bundle Resources. I didn’t notice this problem for MP3 files, as it seems smart enough to add the to this list automatically.

The strange thing is I would expect OpenAL to throw an error somewhere instead of just spitting out noise. So either this set of APIs is pretty badly designed, or there is some code in AudioSamplePlayer that isn’t handling things properly. Either way, I got things working so not going to pry any deeper at this point.

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.

Why you *really* don’t want to make your mobile game anything but free

In the last year or so, I’ve had conversations with several developers who had tried to put their game or app on a mobile store with a price of “only” 99 cents. Of course, all of them were disappointed with only a handful of downloads.

Several years ago, I had the thought that if I could make any money, even a few dollars, it would be a way to get my foot in the door of a new opportunity. After that point, all I had to do was keep working on increasing that income slowly but steadily, and eventually I could make a significant amount of profit.

But, after having a few apps on the store myself, and doing some research, I realized how wrong I was.

I don’t have the exact figure in front of me, but I’ve read several places that nowadays something like 90% or greater of mobile games are free. Frequent browsing through iOS games pretty much confirms that, especially given that the apps I usually peruse are in the “popular” categories and even many of those are free. But what is more important than the fact that most are free is that many of the free games are really well made, with top-class graphics and gameplay – clearly something not done by a lone developer.

As you might expect, many of these games use in-app purchases to try and make a profit, and some games still use advertisements, though use of ads seems to be gradually decreasing over time (I consider that a good thing). There are other free games which, surprisingly, seem to have neither of these – the only explanation is that they are just trying to get their name out there in preparation for a followup game.

As a budding mobile game developer, it’s easy to fall into the trap of thinking your game will somehow be special, and achieve great popularly while earning you thousands of dollars (at a price of only $0.99). While this might be true if you have one or more people on your team with a great deal of experience making and promoting mobile games, for the average small team or hobby developer your odds are not so great.

So let’s say you were trying to decide between making your game free, where you could potentially have a few thousand downloads, and 99 cents, where you would be lucky to have a few hundred downloads (if that). Your first instinct might be to go for the cash, but that would be a terrible waste.

The reason is that while very few small-time game developers will make much money on their first game, they have a great potential – the potential to gather precious information.

The more downloads you get, the more chances you have of getting reviews, either directly in the app store or from a third-party website. Reviews are one of those things whose value can’t be measured easily. Not only do they tell you someone cared about your game enough to write a review, but they get to the heart of what a user enjoyed, or didn’t enjoy. For my first app I only got a handful of reviews, but they were all very valuable information, and helped me drive updates.

Another advantage of free games (especially if they have no in-app purchases or ads) is that it’s much easier to advertise them on the net, or with friends. You’ll less likely to get people saying your spamming or just trying to make a quick buck from a forum post. You still need to exercise caution and tact when advertising, but it’s a little bit easier.

Also, there is a higher chance your app will go ‘viral’ if it’s free, since all that takes is one or more people who have popularity to happen to mention your game, whether in a tweet or on their blog. At $0.99 if you get only 50 downloads compared to 500 when free, your odds of going viral are 10x higher when free.

And don’t forget other sources of hard data. Now with Apple’s analytics being released to all developers you have much more data to mine, and even the most basic data can be extremely valuable if you know how to analyze it. For example, using the number of reported upgrades gives you some idea how many people actually cared enough about your game to not delete it immediately. If you have used something like Flurry in your app you have even more data from each person who downloaded your free app. Tools like this can help you determine engagement, which is a measure of how much the user was really involved when using the game. Did they make it to level 7 after 2 hours of play, or give up due to frustration in the middle of the tutorial?

The other reason the bar for paid games is so high is because there is so much competition even in the realm of free games. As a user, I can tell that there is a major psychological difference between free and 99 cents, regardless of the monetary fact it’s “only 99 cents”. I’ve only paid for a handful of iOS games, but I’d say that at least 30% of them were disappointments which I stopped using after only one or two sittings – in spite of the fact the screenshots or app preview seemed impressive. Gameplay does matter. After being fooled I’m even more hesitant to spend anything on mobile games. In spite of my annoyance with the concept of in-app purchases and the “freemium” model (especially coming from PC gaming where everything used to be one-time purchases), I have to acknowledge that using free games to get users to experience the gameplay is a key aspect of the current mobile game market.

As a final note, while it’s true that you can do aggressive advertising to help up your downloads for both the free and paid models, your improvements in the free case are bound to be more drastic. Compare spending a few days of advertising all over to increase your sales from $20 to $40, as opposed to making free downloads jump from 1000 to 2000 (with a handful more reviews).

Once you’ve reached a moderate success with the free model, you can then either decide to add in-app purchases, ads, make a ‘pro’ version (as a separate download), or just use your newfound knowledge and start over with a new project. Whichever option you choose you can leverage the popularity of your free app to drive traffic to wherever you are trying to actually make money.