Prototypes: an integral part of software development

This time I’d like to talk about the process of creating prototypes. Though this blog is about mobile gaming, prototypes can be a valuable tool for almost any time of software development.

What is a prototype?

A prototype is an limited version of a program which is intended to test something, such as a new game idea. It’s definition is fairly open-ended, but it contrasts from a production version which is something designed to be used by customers, as a complete game or application.

When do I need a prototype?

Creating a prototype is typically warranted when there is some uncertainty the project which needs to be worked out, essentially de-risked, before taking on the full production project. Prototypes are usually appropriate when the full version will take quite a long time, possibly months or longer with a team of several developers and other staff.

The idea is that you want to avoid expending too many resources (money, time, etc.) until you have some level of confidence the project will succeed. Success is defined differently for each project, but it can involve making a certain amount of money, or just making a game that is fun to play.

The idea of prototypes also assumes the developer(s) have the capacity to work on more than project over time. If you compare working on a single project for a year, with a 50% chance at failure, as opposed to developing 10 prototypes during that time to find which idea(s) have the most potential, the latter could be considered a more efficient use of time.

How do I make a prototype?

The most important thing about prototypes is deciding exactly where is the risky part of your project, or the element(s) you want to validate. As an example, let’s say I have this great idea for a game that is a cross of checkers and a word game, and it seems really fun to imagine how it would work. In this case, the purpose of the prototype would be to see how enjoyable such a game would actually be, and to work out some of the gameplay elements.

You can work iteratively, trying one idea until you determine it doesn’t quite work, at which point you can add or change an element and do some more play testing. For example, in our checkers-word game example, you can play around with different scoring systems to see which is fair and offers the most challenge.

Tips for making a fast prototype 

The prototype creation process helps guide you what order you do your activities in. If you are testing the gameplay of the checkers-word game, there is no need to spend any time on the main menu system, the credits page, or the sound effects. You should be spending most of your time in the risky or uncertain element you are trying to test.

With games, graphics assets are one area which can take a long time to produce, whether you are doing it yourself or with the assistance of graphic artist(s). For many prototypes, you can skimp on graphics and keep things very minimal and simple. Rather than a photo-realistic game tile, you can stick with a simple single-colored square, and so on. Of course, if your idea involves creating a game with a certain atmosphere (like a horror game), the graphics and sound might be more important than the gameplay, in which case your prototype would require more effort on those assets.

One nice thing about prototypes is that you have much more freedom. For example, you can potentially leverage a test license for a game engine which you couldn’t otherwise use for a commercial project without paying big bucks. You can do the same for other assets which are legal for non-commercial purposes, though if you switch to a more serious commercial project, you’ll have to purchase the proper licenses for everything being utilized.

Prototype coding practices

When developing a prototype, you also have some more freedom regarding how you write your code. You can probably get by with spending significantly less time on things like commenting, proper modular design, and efficient algorithms. However try and avoid taking things too far, since adopting horrible practices like stuffing all code into a single giant function would make modifications of the prototype difficult.

Also, some things which you typically try to avoid in production code, such as global variables and cryptically named variables, would probably be OK in a prototype. Proper memory deallocation can also be put off, since you can always restart the app as often as you like during test.

Levels of grey in prototyping

Prototyping isn’t all or nothing, in the sense that you don’t have to throw all your code away after a prototype. You have the option of reusing parts of your code in the production version, probably after some refinement, or even in another project.

After writing many prototypes, I’ve gotten into the habit or always writing “TODOs” in my code so that if I do get to make a production version, I know what I need to fix. I also always think about whether it’s worth the few minutes to write a block of code properly, or decide to leave it in a quick, “hacky” state. Spending the few extra minutes to write proper code also makes you a better developer in the long run.

Prototypes need planning too

If your coding is just as a hobby in your free time you can do whatever you like, but if there is a chance you will try to go commercial or enlist the help of other people, it’s good to have a plan even for your prototyping.

First, decide roughly on how you are going to measure the success of the prototype. Will you just play it yourself for a few hours and see if it feels fun enough? Or will you show it around to your friends to get their feedback? You could even target an app store (mobile or desktop) as an end goal to your prototype. You probably won’t get too many downloads because of the lack of polish, but the process of getting on a store is always a learning experience.

Second, get a general idea of how long you think the prototype should take. Generally, I would say a few days to a few weeks is a good range. If your prototype is taking more than a few months then I wouldn’t really consider it a prototype anymore.

For new developers

For those new to software development or game design, your first few projects will probably all be prototypes, whether you think of them that way or not. In that sense, the goal of your effort doesn’t have to be to make a great app or game, but instead just learn something.

As your coding skills improve, you’ll be able to write a rough prototype in a shorter span of time. Saving code you’ve written in the past and reusing it when possible is a great time saver.

A real life example

Recently I had an idea for a casual mobile game which I felt had great potential, so I tried to make a quick prototype to vet the idea. By surgically ripping out parts of a previous project, I managed to make a working prototype in only two hours, and then added a computer AI player in another two.

The idea turned out to be a little less interesting than I imagined, so I’m glad I didn’t try writing everything from scratch. But at the same time, I feel with a few tweaks the gameplay might be taken to a new level, so I’m going to try a few more things when I get a chance.

All prototyping is essentially an experiment, so have fun!

Gameplay element: warp-in time

In this post, I’d like to focus on a gameplay element from my mobile game Play The Field and see how it helps improve the game’s overall balance and sense of fairness.

In traditional Real Time Strategy games (like Blizzard’s Starcraft series), each unit type can only be created at a specific building, and there is a time delay between the time the user decides to start building a unit and when it is finished. The opponent typically doesn’t know what unit is being built, but in some games like Starcraft 2 there is an indication that something is being built.

In Play The Field, in other to create new opportunities for tactics and avoid the extra work of maintaining buildings, units can be played anywhere on the map, given there is sufficient funds. The only exception is a few boards which have one or more red region(s), at which units cannot be placed.

In order to balance out for this extra freedom in unit placement, I made each unit take time to ‘warp-in’. During that time there is a visual indication that the unit is coming in and the enemy player can begin attacking the unit even before it is fully warped in. While a unit is being warped in it cannot attack or movie.

By adding this game element, the player has to have a good idea about the maximum attack distance of each unit and put more consideration into placement, which adds depth to the game. Placing haphazardly can lead to wasted funds and possibly even loosing the stage.

As with most gameplay elements, ideas only go so far – you have to test them. After playing a bunch of stages with this element enabled, I felt confident that it improved the game’s challenge in a fair way. It also helps to balance units that do spread damage to several opponents at once, since they cannot immediately appear in the middle of a enemy crowd and do damage before they are taken down.

Developing games for multiple devices on iOS: Part 1 – how screen differences effect gameplay

One of the challenges of writing games for multiple devices is that there are typically several form factors you need to support. In the Android world, you literally have hundred of devices to consider, though you can target popular ones and probably make most people happy. I haven’t done too much development on Android however so can’t give too much detail here.

In the iOS world, it’s a bit easier since you have a much smaller universe of models to tend to. Grouping all the similarly sized devices into categories (and excluding old models that aren’t supported anymore) you end up with only six device types, which isn’t too bad.

There are only two things to really be concerned with for each screen type: it’s resolution (number of pixels horizontally and vertically) and physical size. Sometimes you hear about pixel density (DPI or PPI), but this can be derived from the size and resolution of the screen.

In this series of articles I’m going to talk about some of the challenges I came up when porting Play The Field from iPad to iPhone, and along the way give some ideas that may help you doing the same for your game. PTF is a minimalist RTS game, but I expect many of the things I discuss will apply to other game types as well.

Though as I mentioned above there are six devices types on iOS to worry about (at least as of May 2015), I’m just going to focus on iPad Retina (which I originally wrote the game for) and iPhone 6. You can see the full list of specs for all currently supported iOS devices here here.

Before I get any deeper I’ll explain a little more about how Play The Field works. There are two sides, the user and the computer, and each has their own units – you can think of them as little tanks if you like though the game is mostly non-violent. There are different unit types, but most share in common the following characteristics: movement speed and attack distance, both specified in pixels.

Movement speed represents how many pixels the unit can move in a turn, and attack distance is the maximum distance to an enemy before it can begin attacking it. One more important piece of information is that there is a series of levels, each with a different layout of enemy units, and I wrote the engine to scale the layout to the screen size.  So if a certain level contains 10 units in a circle, this circle will be adjusted to fit properly on any resolution without being cut off.

iPad Retina has a resolution of 2048 x 1536, and iPhone 6 has 1334 x 750. The latter is a little smaller than you would expect given the resolution difference, because the pixel density is roughly 23% higher. What this means is that if I draw a circle of a certain radius (in pixels) on both devices, the one on the iPhone 6 will be approximately 23% smaller. In the case of PTF, I determined this was not a major problem so I left the unit sizes the same. If the density difference was significantly higher, I would have had to scale all the unit sizes accordingly.

The problems begin when you consider how the levels get rendered on each device. Just ignoring the menus for now, there is 2048 – 1334 = 714 pixels extra in the vertical direction on the iPad Retina, as compared to the iPhone 6. Assuming I don’t change the speed of the units or the board layout at all, it would take units significantly that much longer to cross the board. Also, assuming I don’t change the attack distance, this means the board is effectively more cramped. For example, on some levels where I could have added a unit safely without being attacked immediately by an enemy, now there is less space and my unit will get attacked right away. As a user playing the game on both devices and comparing, because the physical distance is almost the same, this difference would seem strange. After all users don’t actively think about resolution.

I knew these factors could have a pretty major effect on the gameplay, so I play-tested the levels on the iPhone to see how it was. Fortunately, though the game had a different feel, most levels were playable and still had a good degree of challenge. I did tweak a few things to make them work better on the smaller resolution, however. For example, I removed the red area (which blocks unit placement) on one stage because it limited the user’s choice too much. Another option I had when doing the port was to just scale everything down to match the lower resolution: the unit size, speed, and attack distance. In theory, this should keep the gameplay the same as the larger device, as if you were watching recording an iPad on a camera and replaying it on a small TV.

But this approach has its own issues. First, the units would not be much physically smaller, which would render them hard to see as well as hard to select. Accidentally selecting the wrong unit would also happen more often. Also, the speed of units (as seen visually), which had been carefully adjusted, would now be significantly slower on the iPhone. This is because the units are moving the same speed relative to the number of pixels available, but the physical size of the screen is smaller so this translates to less distance per movement.

Yet another option would be to redesign each level from scratch for the smaller form factor of the iPhone. This has the potential to have the best user experience because things are fine-tuned, but it puts a heavy burden on the developer for the redesign process. I am considering doing this eventually, but for the initial iPhone release I just wanted something that was playable and fun, and was able to achieve that without the extra work.

But alas, our work is not yet done! There is still one more area where I had to put in extra time to fit the iPhone’s smaller screen and resolution – the menu system.

I’ll dedicate part 2 of this series to the menu changes I made.


Play The Field – Apple Watch version (ok, not quite yet…)

I’ve been excited about Apple Watch for some time now, and today I got my first look at one in person. It was surprisingly light, with great physical design and eye-catching UI. After playing with it for a few minutes, though the interface had some quirks overall, it felt responsive and easy to use.

I’m already thinking about how awesome it would be to create a version of Play The Field for this new device, though it will probably be months before I can get my hands on one of these. An even bigger issue is how to adjust the game to accommodate the smaller screen size and battery requirements, but I have some ideas related to that already.

Personally, I haven’t worn a watch in over a decade and find them annoying. And yet the idea of a completely new platform for gaming, and apps in general, is quite refreshing as well as challenging. Judging from the fact there is already over 3,500 3rd-party apps for the Apple Watch, I’m not the only one who feels this way.

Though there have been competing watches, from the little bit I’ve researched on these they don’t seem as good or functional as the Apple Watch. Having said that, there are still many limitations on the version version of the watch, for example apps cannot be created which work stand-alone on the watch. Instead it just acts as a controller, and most of the real processing happens on the iPhone. Fortunately, much of this is due to purposeful limitations on the SDK, which Apple is rumored to (at least partially) lift in the next few months.

At the same time, I’m still open to some of the competitors, such as Pebble, to improve to the point where it is worthwhile to develop on those platforms. While I do enjoy Apple devices, I try to stay away from devotion to any platform, and will always consider other options for any future development.