Virtual Reality

I’ve long been a fan of VR and have been disappointed with the consumer level hardware up to this point. That all changed in 2012 with the announcement of the Oculus Rift. With the backing of John Carmack, it was hard for the industry to ignore this new product. It looks like VR has finally turned a corner and (thanks to the booming smart phone market) the technology is available allowing a cheap (almost) consumer grade VR headset to be mass produced. Developers will have most of 2013 to prepare for the consumer grade headset and I see a lot of time and research going into these preparations. Rather than gamers peering through a small (24-70″) window into our worlds, they can now be completely immersed in them. The current fascination with (stereoscopic only) 3D  is one thing, but true immersive head-tracked 3D will take our games to the next level. While there are only a handful of games that support the Oculus Rift at this stage, by the end of 2013 I predict this to be in the hundreds.

Mobile/Tablet

I predict a large number of people (particularly indie’s) will make it big on mobile in 2013. This is still the direction I plan to head in 2013. While some people have moved toward social/Facebook gaming in 2011-2012 I see some of them returning to mobile/tablet gaming in 2013. With Microsoft entering the tablet market (and with a better mobile offering) I see this market growing substantially in 2013. The “get rich quick” attitude many had towards Facebook games has died off a little and I’m seeing a number of indie developers I know pivoting back to mobile rather than pure Facebook/social. I see the mobile/tablet market maturing in 2013 as many developers learn from their mistakes in the past and embrace the benefits of the platform (touch interface, always connected, etc).

Real Social Games

With Zynga shutting down a bunch of their games, I see the need for truly social games. Facebook and other social networks give game developers amazing opportunity for connecting gamers to their friends and others around the world. Rather than abusing these connections I see a switch to meaningful engagement. Games like LetterPress show the simplicity of Facebook to connect users rather than allowing users to bug their friends into getting them in-game items for free. True social games will take this simple connection and use it to enrich their game design. Many older gamers grew up playing together in arcades or lugging their giant computers to each others houses for a chance to play together. I’d like to see this same experience enabled by social games rather than the cheap “social” behavior we see currently. Like it or not, many developers go where the money is and the fact Zynga and the like are now falling on hard times shows the need for more than a superficial social connection if these types of games are to succeed.

No New Apple Product

I don’t see Apple releasing any significantly new products in 2013. They will continue to evolve their existing products, however I see the pace of of their evolution picking up. The iPhone 5 was a disappointment to many of the die-hard Apple fans I know. 2013 will be a real turning point for Apple as they forge new territory without Jobs at the helm. I’m sure much of 2012 had already been planned out but decisions like the iPad Mini show a new course is being set. I’d love to see a new product as innovative as the iPad, but I don’t see that occurring in 2013. Perhaps in a year or two we might see Apple move into the VR market, but I think they will wait and see the response to the Oculus Rift before making a large move like that.

Last Generation of Consoles

It’s looking like the next XBox and Playstation will be released in late 2013. I predict this will be the final “pure console” generation we see. As mobile, tablet and PC converge I think it’s logical that the concept of the console will disappear. With the current console cycle being closer to 10 years than 5, we can expect the next generation to be at least as long. With the current speed of innovation in the tablet/mobile sector, it will only be a matter of years before a portable device is as powerful as the next generation of consoles. The only difference then is the input/output mechanisms. Microsoft has already shown their Surface is compatible with a XBox360 controller and I see this trend continuing.

In the mid-term future, I forsee one, or maybe a couple, of devices powering most of our personal computing. This device will connect to the output device of our choosing to power our experience. On the road we will use the device itself (which will be around the size of a phone and/or tablet, depending on your preference). At work the computing device wirelessly connects to your mouse, keyboard and monitor(s). Playing games and watching movies it will wirelessly connect to a large TV or projector.

Summary

What are your predictions for 2013? Do you agree or disagree with any of my points? What would you love to see in 2013?

What Went Right?

1. Amazing Audio

Without a doubt, the first thing people comment on when they talk to me about Battle Group is the amazing audio. Mick Gordon our audio engineer went above and beyond with the audio for Battle Group. When we first pitched the idea of the game to Mick he was quite for a minute or so and then became even more excited than usual. He had grand plans for what he could do with the audio which included voice overs and movie quality explosions (and no snare drums). Voice overs for a mobile game is fairly uncommon, particularly from an indie studio, but amazingly he managed to pull it off and it sounds awesome. We were runner up in the Freeplay Independent Game Awards for audio based on a very early version of the game. Since release nearly every review has mentioned the high quality audio and we’re really proud of how well it sounds both on PC and mobile.

2. Good Reviews

As I mentioned previously, we’ve received a lot of great reviews for Battle Group. A few of them have been perfect scores with an average around 85% for all reviews. This was one of the biggest improvements since the release of Flick Buddies (our last original IP game). The major issues of not contacting enough press and terrible release timing were rectified and it paid off. We had a number of previews before the game was released and this helped build a buzz so our day 1 sales put us in a good position on the charts in a number of countries. These glowing reviews also helped push our sales in the initial few weeks which helped us to reach our “break even” point for the development of the game in a relatively short period of time. While we didn’t make it onto all the big sites like TouchArcade.com, we did manage to secure a number of major sites including a feature as app of the week on cnet.com.au which was also aired on Australian TV.

3. Multiple Platforms

From the beginning we designed Battle Group to work on as many platforms as possible. From mobile to tablet to traditional PC/Mac we wanted to challenge ourselves and release simultaneously on all available markets. We weren’t sure which would be the most successful and to our surprise the Mac App Store was one of the best sellers. We were featured on the Mac App Store and this drove some really great sales in the first few weeks. Thanks to Unity, porting to the different platforms was fairly painless. I’ve spoken of this previously so I won’t dwell too long, but suffice to say that without the non-iOS markets we would not have been as successful as we are with our sales. We also would not have secured a publishing deal for China.

So I guess the real question is, would I target multiple platforms simultaneously again? Generally speaking, yes I think this was a good move for us. While it caused a few headache’s at the time of release, it paid off as all marketing and advertising was then able to drive people to whichever platform they preferred. We had a number of people complaining that Flick Buddies was not on a particular platform and we saw this as a lost sale. By targeting all platforms simultaneously there was no excuse for people to not buy the game (unless they didn’t like it, but more on that later).

4. Simple Controls

One of the big lessons we learnt from Flick Buddies was to keep the controls as simple as possible. From the outset we wanted a game players could pick up and instantly understand. We met this goal allowing us to reach the largest market possible. The first instinct for new players was to tap the screen near an enemy. They instantly get feedback as a missiles flies out from their ship and ends in a rewarding explosion when it reaches the point tapped. We spent a lot of time playtesting Battle Group and from the youngest to oldest players we saw almost universal approval of the control system without any instructions or need for a tutorial. We included in-game queues if it seemed like players weren’t picking up the controls and this resolved the small number of people that didn’t instantly understand.

A secondary benefit of this simple control system was the unified input system across all platforms. Whether player with a mouse or finger/touch screen, players simple click where they want to shoot. This simplified the porting process and helped us hit multiple platforms simultaneously

5. Long Tail

As with all games, we saw a spike in sales at release with a slow decline over the following months. Unlike our previous games this decline stopped at a point where we are still getting reasonable sales to this day. The free version still sees a few thousand downloads per week and the paid versions (across all the platforms) are staying at a steady rate. This has allowed us to work on translations of the game for multiple platforms and Battle Group now has publishing deals in a number of Asian countries.

What Went Wrong?

1. Release Day Bug

The down-side of a simultaneous release on four platforms was that a fairly critical bug crept into the iOS version at release. The bug meant that on the new iPhone 4S the water did not render leaving a large black gap in its place. Thankfully it was an easy fix and we had the patch submitted to Apple on the day of release. After the month’s of development it was disappointing that bug like this got through the cracks, however it’s taught us another valuable lesson in thoroughly testing the FINAL version of the game on as many platforms as possible.

2. Raster Lines

During our discussions with publishers we came up with the idea to add “raster lines” to the game to make it seem like the player was looking at an old screen TV on a warship. Every second line was rendered black giving the appearance of an old screen and adding a distinct feel to the game. This ended up being a polarizing decision and resulted in a number of negative user reviews on the various app stores. We also found that screenshots and video’s taken that were scaled in any way resulted in weird artifacts. We rectified this by turning them off by default and allowing users to add them back in from the pause menu.

3. Over Budgeted Time

We rapidly moved Battle Group from concept to first playable and received a lot of positive feedback on the core design. After this point, things began to go off the rails a little. Our “vertical slice” was continually pushed back until the point where most of the art assets were created before we could lock down a single level to make sure the full game had a cohesive feel. Once we finally reached this vertical slice we found that some of the decisions we had made relating to the look and feel of the game were off. This required a bunch of new assets to be created and more features to be implemented to fill out the design. The end product worked really well and had an excellent difficulty curve, however this came at a cost of extra time. By the time the game was released we ended up missing our original release date for a number of months.

Solving this problem is a key goal for our future games. We have begun stage-gating our future games and making sure we have definite milestones throughout development with the minimal amount of work from each department (art, audio, programming, design) is completed for each milestone. This will allow us to pivot more easily without throwing away resources and time and encouraging us to get as much fun out of each game.

4. No Big Review Sites

As with our previous games, we still did not make it onto a number of the large, key, review sites for iOS games. Despite contacting them and offering exclusive content we were still not able to secure enough media attention to turn the game from a modest success into a huge success. We plan to solve this problem by partnering with a marketing company like Surprise Attack from the outset of our future titles. Without these large review sites it makes achieving a place in the top 10 games more challenging.

Summary

So that’s a brief overview of the release of  Battle Group. Have you played Battle Group? If so, what did you think? If not, was there a reason you didn’t? You can grab it on the various platforms below:

iPhone/iPad
Mac
Android
PC - Direct Download

• Firstly could you introduce yourself, tell us a bit about what you are working on and what your favourite games are?

Hey, I’m Alex Norton, Creative Director and Lead Developer of Visual Outbreak, a Brisbane indie group that’s been around longer than most people would realise. We started out back in 2003 when we released Dungeon Master Pro, a web client for playing Dungeons and Dragons with people online while still using all of the books and whatnot. It got to version 3 and had quite a big following, and I think some people still use it… Anyway, now we’re working on an RPG for the PC called Malevolence:

The Sword of Ahkranox which we’re hoping will both shake the games industry and revitalize an old genre. It’s played like the old classic RPGs of the early 90s (such as Might & Magic, Eye of the Beholder, Wizardry, etc) but is set in an infinite, persistent world, populated by procedural locations, enemies, items, quests and more. When we’re not working on that, though (which isn’t very often) we’ll generally play team strategic combat games such as Battlefield 1942, Rainbow 6: Vegas and S.W.A.T, switching to Diablo II and NWN when we feel like something a bit more laid back. When playing on my own these days I usually just hook up to the Battlefield 3 servers and see what’s going on. I generally hate playing online, but BF3 is still pretty fun.

• What game engine are you using for Malevolence?

It’s called the Hellfire II engine, and it has been custom written by myself and my team. The original Hellfire engine was written as a proof-of-concept for a project at QANTM about six years ago, and it had gathered dust until 2010 when we cleaned it up and expanded on it. The new version allows persistent interaction with an infinite 3D world that isn’t constrained by upper and lower limitations of data types (like other procedural games are, such as Minecraft). Like most crazy ideas it started with us being told that it wasn’t possible, so we accepted that as a challenge.

• If you started over again, would you build your own engine or would you use an existing engine (like Unity or Unreal)

That’s a hard question to answer, to be honest. I’ve always been a very strong believer in re-inventing the wheel wherever possible. So many people always say “don’t reinvent the wheel!” but if you never do then you never give yourself the oppourtunity to make the wheel better. Writing the game’s engine from scratch definitely has slowed down the game development process a great deal, and has caused more frustrations than any other part of the game’s construction, however that could also be attributed to there being only one coder on the whole project! I think if I was presented with a game engine that was powerful enough to do what I needed it to do, and yet open enough for me to go in and tweak what I needed to, then perhaps I would take it on. But it’d have to be pretty damn convincing!

•  Why is Malevolence unique?

Many reasons! It’s unique amongst todays games because it is both first person and turn-based, which is something you don’t see very often in games these days. The grid-based movement of Malevolence was extremely popular in FPRPGs (First Person Role Playing Games) of the 90′s, and more modern games such as Legend of Grimrock make use of it, but aren’t turn-based as well.
In addition to that, however, the in-game world of Malevolence is infinite. Not just infinite, but persistent as well. You can walk for a billion miles in one direction, then head back the way you came and everything will still be there, just as you left it. Items and monsters, however, do change as our procedural algorithm uses a time coefficient to establish “volatile” world components. But an infinite world can get boring after a while, so we’ve also made the item generation system procedural to give the player an infinite number of items to find, and also infinite weapons as well. We’ve gone one step further with the weapons and made the actual weapon graphics be procedurally generated as well, so you can keep finding new weapons, and they’ll keep looking different as well as having different stats and abilities.

On top of that we also have a procedural quest generation system, which links in heavily with our procedural dialogue system. The NPCs in the game use an AI system we’ve developed which follows a six-degrees-of-separation methodology, meaning that if you’re talking to someone in Town A, they may know someone in Town B who needs some help, but the person in Town B may have forgotten where the dungeon where they lost their favourite dagger is, so you’ll have to ask around to see if anyone knows a local map-maker or ranger to help you find it. The game does all of this procedurally and on its own, ensuring that you never run out of things to do.

• Haven’t procedural game worlds been done before?

Yes, and much further back than many people realise! Some older gamers will remember earlier games such as Sentinel and Elite, which used procedural generation to create their game worlds. In more recent history, earlier RPGs such as the Diablo series and TES: Daggerfall used procedural generation, but always within limitations, which was a real shame. It seems that many developers are scared of making a game with a fully realised INFINITE world because it will cease to be interesting. We’re set to prove that theory wrong.

• How do you achieve an infinite world?

That’s the big secret! We’ve had lots of people want to know, but frankly, if we just handed out how we managed do it, we wouldn’t be very good salesmen! I’ll tell you a bit about it, though. Yes, The Sword of Ahkranox’s in-game world is quite literally infinite. No, I’m not exaggerating. The engine makes use of a new type of procedural generation that I invented myself. No fractals, no Perlin noise, no blobs, no diamonds. Instead it makes use of a hyperbolic paraboloid generating seeds which are used to create the world in four dimensions. X, Y and Z co-ordinates as well as a time coefficient. Changes that the player makes to the world as they move through it are stored in a temporary database but are then reset after the player has given enough time and distance between them. So, if you empty a chest in one dungeon, then travel across the world, eventually that chest will re-fill, however, due to the time coefficient, the seed that generates the content of that chest will now be different, thus putting different content in that chest.

The AI of NPCs and monsters also follows this procedural generation, so people won’t just sit in one spot, but will travel around the world while you play, depending on their role.
This generation accounts for almost everything in the game. Spell creation, item creation, weapon creation, potion creation, NPC dialogue system, even the spell effects that happen on the screen. Due to this, the world that the player explores will be ever-changing and infinite. They won’t keep finding the same old weapons or items, there will be no end to the number of spells they can find or use, they won’t even keep having the same conversations with NPCs. ”That’s impossible!” I hear you cry. Well, it’s already working just fine

• Have you had any difficulties in attempting to revive a relatively extinct genre?

Augh, if we had a dollar for every time we’ve had to explain the notion of the game to someone… Unfortunately, a good proportion of gamers out there are quite young (18 and under) and they were born into a world of GTA, Morrowind and Mass Effect. So when they see Malevolence and see the 3D, shaded graphics, they assume that we’re trying to be the next Skyrim because they simply don’t know what Wizardry is, or Might & Magic, or Eye of the Beholder, or Dungeon Master. We get inundated with questions like “Why is the movement grid-based?”, “Why is the gameplay turn-based?”, “Why is the view distance so small?”, “Why can’t I see my weapon on the screen?”. The worst part is that most people have been ignoring the technological breakthroughs of this game and focusing on the way the game is played, because they simply don’t understand, much as we try and explain it. The sad fact is, Joe Public thinks he is entitled to have his say on how your game is made, but we’re making this game because it NEEDS to be made, not because we want to appease people and make money. This game is the 90s era RPG that never was, and we’re determined to give it life.

• What if people want to get involved?

We actually have a team of 39 people working on the game, so new team members aren’t really needed. The biggest thing people can do is donate to the project via the FAQ page on the website or via our crowdfunding. Though the game is getting close to done, we’ve launched a KickStarter page going over the next month to raise funds to add some serious polish to the game. People should definitely go and check it out at this link.

To be honest, though, if you want to keep up to date on everything to do with the game, just like us on Facebook (www.facebook.com/malevolencegame) as we update it regularly with links to everything that’s going on, wether it’s new blog posts, crowdfunding sources, screenshots, gameplay videos, the lot!

Get Business Cards

The simplest issue is one I’m constantly frustrated by. The majority of teams have business cards or other suitable contact information, but there is always at least one team that has no way of me contacting them. Often, this team will have the star programmer of the night that I really want to hire. There are countless options for cheap and free business cards and I think this is far more important than anything else you will spend money on for the evening (like posters and t-shirts).

Also on this topic, make sure you give out business cards for the whole team. At the most recent industry event, I was speaking with the game designer from a team of 5. I asked for “all your business cards” and he proceeded to give me 5 of his own business card.

Research Local Companies Before The Event

All of the industry nights I’ve attended have been in Brisbane, Australia. Home of a number of large studios in the past (Auran, THQ, Pandemic) and smaller extremely successful studios like Halfbrick. It pays to spend a few hours before the event researching the companies in your local area as there’s a good chance they will send at least one representative. Knowing what they have recently released and are currently working on will give you a good opportunity to lengthen the conversation you have while they visit your booth. It’s also a good opportunity to pick the favorite studios you would most like to work for. Check out their “positions available” page to find out the sort of talent and amount of experience they are looking for in each field.

Don’t Drink Too Much Alcohol

Most of the events I go to have free alcohol for those attending. I remember my poor university student days and the excitement when free <anything> was offered. However if you’re at these events showing off your games PLEASE take it easy with the free alcohol. I usually only make it towards the second half of the industry nights and by then there is always at least one team that has consumed their weight in free alcohol. I realise these events are held at the end of an extremely stressful period, however I implore you to wait just one more night. Use your college student ingenuity and stockpile the free alcohol in a safe container for later consumption if you really must.

Don’t Pack Up Early

Most of the events only last a few hours. Game developers are busy people and can’t always make it along to the entire event. There’s nothing worse than walking around the booths with 30 minutes to go and seeing people packing up their equipment. There is always ample time at the end to pack up and you’re missing out on one of a very few opportunities to put your work in front of prospective employers. If you can’t last the few hours required for an industry night you’re unlikely to make it through a multi-year development cycle.

It’s Not A Pro Gaming League

Many teams go for local multiplayer in their end of year projects to save on time writing AI code. This is a great idea and lets multiple people experience your game at the same time during the industry night. Just remember that you not only created the game, but have countless more months experience with it than prospective employers. Getting absolutely smashed in a game I barely understand and then having (slightly drunk) graduates whooping and high-five each other is a bit of a turn off. It’s difficult to gauge the quality of a game when I die every 15 seconds. We had this same problem with an MMO we were showing to a prospective publisher. The development team treated it light some kind of pro gaming league and completely wiped the floor with the “noob” publishers. Your job prospects will likely go the way of this ill-fated MMO.

Designated Spokesperson

I’ve noticed a number of teams have a designated spokesperson that speaks to people entering the booth. I have mixed feelings about this   setup. It’s good for a key person to grab the attention of people walking past and give a good introduction to the game and the team. However this role usually falls to the project manager/lead game designer of the team and if I’m looking for an artist or programmer I want to talk to these team members. If you are going with a dedicated spokesperson, make sure they ask if there is anyone on the team in particular they would like to speak with. Also, make sure the whole team is about for most of the evening. If you are the spokesperson, make sure you introduce yourself and be confident.

Send Emails

I remember how desperate I was to get business cards of video game developers while I was studying. As soon as I got one I’d email them and make sure I got on their radar. It seems about 10% of people I give cards to at these events act in the same way. The other 90% either lose my card or just don’t bother replying. Even if you’re not looking for work right away, its invaluable to have contacts in the industry, particularly in Australia at the moment. Sending a quick introduction email to all the business cards you receive on the night should only take a few hours and I guarantee at least one of them will pay off in the future.

Make Something Playable

This tip doesn’t apply to the industry night specifically. Make sure when planning the game you will show at the industry night, you keep the scope small enough so that you will have at least something playable to show. Gameplay videos are great, but they take time to create and don’t do as good a job at showing off your work. Having a playable build, no matter how buggy or unpolished is going to impress prospective employers more than a simple gameplay video. Also this is a great time to get a whole bunch of free user testing done on your project. Spend as much time on polish as you can as a beautifully polished, simple game, is far better than a grandiose, buggy one.

I remember one of the first industry nights I went to, about seven years ago. I walked up to the booth to find the familiar scene of Visual Studio and a coder hacking away at a bug. While it was great fun hunting down the crash bug with him, it didn’t instill much faith in their abilities to deliver a project on time and on budget.

Conclusion

These are just a few tips I’ve noticed on multiple occasions throughout the past few years. Do you have any recommendations for students showing their games at industry nights?

Another great resource for tips: http://altdevblogaday.com/2011/08/26/game-dev-students-represent/

Why?

Why would you want to separate out the gameplay from the rest of the game? There are a few main reasons for this:

• Gameplay code varies widely between different games. Whereas other systems like rendering, audio, animations and input have many similarities between different games. (Eg while Battlefield 3 and NFS: The Run share an engine, their gameplay is substantially different).
• Gameplay code has different ownership to the other systems in the game. Most teams are split into gameplay and engine divisions. These two areas require different skill sets which is why there is specialisation in each. Often the size fo the gameplay team will be similar in size to the engine team.
• Designers deal solely in terms of gameplay and so they should. Designers should not be concerned with shaders or specific input code. Separating this code out simplifies their job and protects them and the engine from each other.
• Allows unit testing specific to gameplay code. As the test suites are gameplay focused they are simpler and easier to maintain.
• “Finding the fun” is one of the hardest and most important parts of game development. By separating out gameplay developers can focus solely on this task without worrying about other engine related issues. By dealing with less code, developers have a better velocity to make changes and prototype new ideas throughout development.

How?

We’re using Unity and C# for our game development. We split the gameplay out into it’s own library (a .dll specifically). This library has no reference to Unity and is completely engine agnostic. In theory, we could swap out Unity for XNA or another engine that is able to communicate with a .NET library.

The game engine then “includes” this library and uses it for simulating the game world. In Unity this is as simple as dragging the .dll into the project and you instantly have access to all it’s public types.One option is to make all access from the game engine into the library through interfaces. This gives you the best separation of concerns and completely decouples the game engine from the implementation of the gameplay. I did this for the first game that used this technique but have since moved away from it. I highly recommend having all communication through an interface for larger games and teams.

I’ve also used this technique in an XNA project which was also a simple process. Simply add a reference to the gameplay .dll and start coding against it.

Scripting Languages

This separation is often achieved through scripting languages. Certain behaviour within the game is exposed to designers through a scripting language like Lua. I’ve done this on a number of projects and this separation works well. I’ve also spoken about why I think C# should be used as a scripting language. Separation of gameplay is an extension to the regular scripting language breakup.

Separation of gameplay flips the classic scripting language paradigm on it’s head. Rather than exposing some functionality of the game engine to designers and gameplay programmers to create the game world. We let the designers and gameplay developers create the world and engine developers use this world. This frees both teams up to work at full velocity initially as they build the ground work of the game. Both have set functionality they must achieve and can communicate through a simple, well defined interface. Designers can focus on implementing fun gameplay while engine coders work closely with artists to get the look and feel they want from the game.

Engines like Unity and Unreal all gameplay code is already in a scripting language (Unreal Script and C# vs the engine’s C/C++ code). However I’m arguing for taking this a step further and even within these scripting languages we create a separate library independent of any of the engine specific code. We then have three main domains within our game:

1. Gameplay specific code (eg Player ship and Torpedo)
2. Engine code specific to this game (eg Taking raw input and passing it in a nice form to gameplay specific code or shaders)
3. Engine code (for Unity and Unreal this is the C++ code we generally don’t access)

Negatives

I did find a few down sides to this approach. For games where game engine and gameplay ARE tightly linked there can be a lot of duplicated data. As the gameplay code is unaware of the engine data structures like transform must be duplicated in the gameplay code. This increases memory usage and processing as the data structures are converted.

Another downside is that some useful features of the game engine are not accessible to the gameplay. Two key features of Unity that would have been great to use were triggers and coroutines. Once again, code duplication is required if the gameplay is to use these features. (See future plans below for a solution to these issues)

Two Worlds

In effect, there are two instances of the game world. A gameplay specific instance and an engine/rendering specific instance. For complex games this separation is a good thing as it frees engine developers to store the world in their own optimized data structures. This decoupling also simplifies the process of multi-threading the game engine as there is a distinct breakup between gameplay specific code and rendering/input code. I’ve worked on a large project which made this split after a multi-year development and while it was painful to implement once complete the teams velocity increased significantly.

Unit Testing

I spoke about unit testing in my last post and this is one of the major advantages of separation of gameplay. You can easily unit test the gameplay itself and have a suite of tests specific to making sure the gameplay is “correct”. When unit tests deal only with gameplay they can be simpler and higher code coverage can be achieved. One area I am looking at in the future is formally turning the game design document into a suite of gameplay specific unit tests. The gameplay team have complete ownership over the gameplay code and the test suite that tests it.

Future Plans

There are a few areas I plan to experiment with in the future that I haven’t had the opportunity to yet. The first is solving the issue of duplicated data between the gameplay and game engine. My thoughts on solving this problem are for the gameplay to have a reference to the game engine data structures where appropriate. For Unity3D this would be as simple as including the UnityEngine.dll. Spatial data structures (Vector3, Quaternion, etc) can then be used directly in the gameplay. This breaks some of the abstraction between the gameplay and game engine but if done sparingly I think it will add a lot of value. Specific to Unity I’m going to experiment with creating MonoBehaviour entities within the gameplay as well to see whether this works and how badly it breaks the abstraction.

As I mentioned with Unit Tests, I’m going to look at ways of formalising the game design itself into a suite of unit tests. I’d like to experiment with Domain Specific Languages (DSLs) to make this as simple a process as possible for game designers. A DSL would also let them speak in their own language. I’ve experimented with fluent game design in the past and this is another area of interest for me.

Conclusion

What are your thoughts on separation of gameplay from the rest of the game code? Is this already achieved with scripting languages or do you see extra value with allowing gameplay developers to create the entire gameplay model themselves and have engine developers use world through an interface?

Test Driven Game Development?

The idea behind Test Driven Game Development is writing automated Unit Tests to confirm the correctness of your production code. Unit tests can be written to test all areas of a game from gameplay to rendering engines and anything in between. As I stated previously, there are three main goals from TDGD:

1. Find out when code breaks. If you make a code change that breaks something that was previously working (and is tested) you will know about it immediately.
2. Forces modular code.  For code to be “unit testable” it must be modular with clear boundaries and “separation of concerns” between various systems.
3. Allows you to “find the fun”.  Once you’re guaranteed that certain requirements are met, you’re free to experiment with gameplay to make it more enjoyable without breaking the game.  This also extends to giving designers more freedom when scripting.  Encouraging experimentation by designers without programmer intervention is invaluable.

How We Did It

In general the development of new gameplay features followed these steps:

1. Design the unit test for the new feature, testing the outward interface seen by the rest of the system
2. Implement the feature as quickly as possible, cutting corners as needed so the feature is playable in the quickest time possible
3. The team tests the feature, makes sure it’s working and fun and we make iterative improvements to it
4. Once happy with the feature I then refactor the code to clean up any shortcuts and make it the optimal solution

This system worked extremely well and lead to a high development velocity both for the creation of new features and maintenance/update of existing features.

Gameplay Testing

All of the unit tests created for Battle Group were testing gameplay code as this is the most complex area of our game. Unity does the heavy lifting for most of the technology based systems (eg rendering, input) freeing us to have ~90% of the code in the project related directly to gameplay. The main motivation for this testing was to allow us to rapidly develop features and experiment with existing code without breaking existing systems. For the most part, this motivation was met throughout the lifetime of the project. While the gameplay stayed fairly constant throughout the 4 month development cycle, there were a couple of major changes we made and the unit tests were invaluable during these changes.

Battle Group started out (as most games do) as a game design document. We then prototyped the game, tweaked the design document and began working on the alpha build. This design document was translated into unit tests. While I (the programmer) was responsible for this, I plan in the future for our game designer to begin to take over the role of writing gameplay specific unit tests. As the project progresses, the artifacts of its design move from a static design document/wiki to an active, maintained set of unit tests. As design changes requests came in from the team I would focus my time on updating the unit tests to match the new design.

What About Prototyping?

We did not create these unit tests during the prototyping stage (about a week’s work) as this was a throwaway prototype and unit tests would have slowed us down without much real value. One of the negatives related to TDGD is the reduction in velocity while making fairly major changes to the codebase. This is often the case while prototyping and therefore I strongly urge against TDGD during the prototyping phase of your development, particularly throw away prototypes.

The prototyping phase is a great opportunity to start fleshing out the design of your testing suite however. As you work on the core features of the game you can see where the bulk of the coding effort is likely to go and also which areas are most susceptible to change throughout the life of the project. A good example of this was the blast radius and velocity of the weapons used in Battle Group. Small changes to this had a major impact on the feel, flow and accessibility of the game. For this reason I made sure that this was both easy to change and robust in the changes I made. As velocities increased the distance traveled per frame became quite large. Coupled with this was the low physics frame rate on older mobile devices and it was crucial that we had repeatable behavior at varying frame rates and data values. As I had already planned to implement TDGD post-prototype I was mindful of these areas of code and made a mental note to test these areas first and thoroughly.

Code Coverage

Whenever I discuss TDD with someone in or outside the game development industry, there’s often a heated discussion about code coverage. Code coverage is the percentage of production code that is “covered” by unit tests. There are purists that claim you’re not really doing true TDD without 100% code coverage and there are others who say some arbitrary percentage is enough. My stance is that the game/code itself should determine the code coverage you should aim for. Sometimes certain tests are causing more trouble than good (eg changing a few lines of code requires 10 times more lines of unit testing code to be updated). Either the tests need a rethink in the way they are implemented or it’s best just to remove them.

I didn’t “watch the clock” when it came to code coverage on Battle Group. My main focus was to get the best value from my limited resources (as the sole programmer on the team). During prototyping and throughout development I noted which areas of code were critical or breaking often and made sure to get the highest code coverage possible on them. There is certainly a point of diminishing returns when it comes to code coverage which differs between projects and between systems within a project.

Test First Development

I opted for a “Test First” development style where I would create my unit test and then implement the feature being tested. This allowed me to design exactly how I thought the code should be used rather than writing the solution to the problem. I found this was invaluable to keeping a clear separation of concerns and made sure everything was as modular as possible. By thinking about the outward interface of the functionality first, it helped me get in a mindset of creating exactly what I wanted. When solving an interesting and complex problem it’s easy to lose site of the original reason for the code’s existence. Test first development focuses your efforts where they are needed most, on defining and then implementing the functionality of a piece of code as seen by the rest of the system.

NCrunch

One tool that was released during the development of Battle Group was NCrunch. This tool will completely change the way you unit test. I won’t go into too much detail as it’s a little off topic, but I strongly recommend you grab it and experiment with how it works. The whole system can be summed up in two points:

1. Unit test code has real-time inline green/red lights to indicate whether it is currently passing. Tests are continually running in the background to keep this constantly up to date
2. Production code has a similar green/red light system showing how many unit tests covering this code pass and fail (or if there are no tests at all)

Constructive Criticism

The most important way I feel I grow as a programmer is to listen to criticism from my peers. In the past (particularly during puberty) I found this quite difficult to do. Over the past few years as my confidence has grown my view of constructive criticism has changed from fear to embracing wholeheartedly. I’m now at the point where I’ll purposely ask people to give me negative feedback on my code, design, games and in general so I can learn. If nothing else in this list resonates with you, I strongly recommend at least thinking on this point. I’ve met many programmers in the past (including myself) that either ignored criticism or actively fought it. There will always be better programmers than yourself out there and taking constructive criticism from these people is an excellent way of improving.

Continually Learning

I tend to go through peaks and troughs when it comes to reading and learning. During the middle 80% of a project and particularly deep within crunch I find I put my blinkers on and ignore most of the world around me. Once completing a project, and as I start on a new one I’ll resurface and look at what I’ve missed in the previous months. I think learning new techniques, technologies and generally discussing game development with my peers is a great way of improving my skill-set and maintaining an optimal development velocity. I generally count GDC in this as I find I’m invigorated after each visit to SF.

Complete Difficult Problems

When time is short (when is it not) for a particular milestone I find myself shying away from difficult problems in favor of a quick fix or doing something different entirely. I’ve found this is often a sub-optimal solution as the problem is often not solved and inevitably crops up again later in the project. On a project-wide time frame the problem ends up taking far more time to solve than if I had simply taken the time initially to solve the original difficult problem at the expense of the milestone time frame. My solution to this situation is to allow enough padding in my milestone estimates so that I have time to dig deep into a complex problem when needed without worrying too much about the ticking clock. This is easier said than done, however focusing on the project-wide velocity improvement makes it an easy choice to solve complex problems as they crop up.

Cross Discipline

Unlike other software development I’ve done, game development has an extremely wide range of skills across a team. One of the most stark differences is between programmers and artists. With our different hemispheres at work programmers often band together and feel like they are working against the other disciplines in the company. This was the case for the first few jobs I had in the video game industry and it wasn’t until I worked on a cross-discipline team that I realized how incomplete my earlier teams had been. Without a working knowledge of the other key areas of game development I was missing a large part of the big picture. Not until I sat next to an artist and watched them complete repetitive tasks for hours at a time did I realize that spending 10 minutes writing a simple tool for them would make their live much easier. It wasn’t until our latest game that I worked closely with a sound engineer and learned how easy it is to build an extremely powerful sound system to rival many AAA games on the market. Spending time with developers from other disciplines is invaluable to both becoming a better programmer and improving the quality of your team.

Critical Thinking

I often fall into the trap of completing a particular task in a certain way as “that’s the way it’s always been done”. It’s not until I discuss my processes and thinking with other programmers that I realize there can be a better way. There are two main groups I find I get the most “aha” moments that often have radical changes to the way I do things. The first group is junior developers newly out of university. They will often be exposed to new ways of thinking or have simply thought outside the box to solve problems. The second group is developers from outside the video game industry. Test driven development is a great example of something I picked up from a web developer friend (and have since started evangelizing to other game programmers). Looking introspectively at your processes and development style at the end of a project is a great time to be critical of how you do things and see if you can improve.

Conclusion

Do you have other recommendations and thoughts on becoming a better game programmer? What techniques have you picked up over the years that have helped you grow?

Overview

Our primary platform for Battle Group is iOS (iPhone, iPad and iPod Touch) while our primary development platform is PC. This took us approximately four months to complete and it took a further 10 days to port to Android, Pc and Mac. Our first two games were both iOS exclusive so this was our first time developing for the other three platforms as an indie team.

Input Changes (Mac and PC)

One of the biggest challenges was making the game work well with both touch and mouse input. Back when we created Flick Buddies I created a unified input system so that the mouse and touch are treated through the same code path. This went a long way to simplifying the process of targeting both input systems. The input basically boiled down to “On Down”, “On Move” and “On Up”. Unity’s “Touch” class is extremely helpful and saved us a lot of time. The only game specific challenge we faced was around ship selection. We made use of the scroll wheel and keyboard for extra player control, both of which only took an hour or so with Unity.

Overall we were really happy with the way the input worked across all platforms and we decided to keep them very similar.

Multiple Resolutions (PC, Mac and Android)

The area I’m least happy about with Battle Group is the multiple resolution support. While we support any resolution and aspect ratio, the fact we targeted iPad primarily (1024×768) meant the game isn’t really wide screen. We decided to fully support any aspect ratio between iPad and iPhone and add letterboxing to resolutions outside this. For gameplay reasons we could not allow an unlimited amount of aspect ratios without letterboxing. The biggest concern for me is that letterboxing usually runs along the top and bottom of the view and people expect this. In Battle Group, as we targeted iPad primarily, our letterboxing runs along the left and right handside for extremely widescreen aspect ratios.

The actual implementation of multiple resolutions was fairly straightforward with Unity. As Battle Group is a 2D game we were using an orthographic camera and I simply adjusted the size of the camera’s view area to accommodate different resolutions. The biggest complexity involved created the settings page allowing players to choose the resolution and full screen. Unity has amazing support for resolution changing, including full screen and windows. I have horrid memories in DirectX of lost context and all sorts of issues that are gracefully handled for us now.

One small point of concern is multiple monitor support. Out of the box, Unity doesn’t support locking the mouse cursor to the primary screen. There are some platform specific workarounds but nothing I was happy with and so for version 1 we don’t lock the mouse cursor. This is a personal pet hate of mine and so I was quite disappointed however timeframes didn’t allow me to obsess to long on this feature.

Demo Version (PC)

The PC version we sell through our website has a demo that unlocks with a CD key. I spent a while looking for example code for CD keys but couldn’t find any I was happy with. Instead I spent a few hours and threw together my own CD key generation and checks and it’s worked quite well. I used Unity’s built in text box for the CD key input and this actually worked quite well. Players can cut and paste the CD key from anywhere and I then do some quick validation. I always warn my students not to use the built in Unity GUI, however in this case it worked really well.

Mac App Store

We decided to release a Mac version on their Mac App Store to coincide with the iOS release. Having already ported to PC this was an extremely simple process until the very end. Unfortunately there’s a little monkey work that needs to be completed in the final step that Unity does not currently handle. Check out the following links for detailed instructions on how to complete this:

• http://technology.blurst.com/unity-games-and-mac-app-store
• http://forum.unity3d.com/threads/71340-Submit-Unity-games-to-the-Mac-App-Store!

One key point is that you need to make sure “Player Log” is turned OFF. We failed certification the first time as we were still writing out our log file.

The Mac version of Battle Group is actually our best seller at the moment. We were featured in “New & Noteworthy” and we are currently the #4 game in Australia and #12 game in the US. This was a great surprise and we were really happy we took the time to port to the Mac App Store.

Android

After initial issues setting up the ADB driver for my Android device this was another smooth process. The Android shares nearly all the code of its iOS sibling and the only major difference was supporting multiple resolutions and aspect ratios for all the different Android devices. I had already completed the resolution code for the PC version and therefore this all “just worked”.

Post release, we had a small hiccup with “1 star spam” where someone (probably a competitor) spammed our game with 40 1 star ratings in under 30 minutes. Thankfully Google were quick to rectify this, however it was not a great feeling.

Performance

I spent a week or so heavily optimizing the game and rendering for Battle Group about three quarters of the way through development. Per platform optimizations weren’t really necessary and we’re happy with the frame rate on all platforms. There were really only two limitations I put on our game designer as he created levels, both of which were increased at his request a number of times. These were mainly around the number of concurrent enemies on screen at one time as both the game logic and rendering increased linearly with this number. The only major outstanding concern I didn’t get enough time to look into was load times on some slower devices. For some reason Android particularly takes a lot longer to load than its iOS counterpart and this is something I am planning to fix in a future patch.

Closing Thoughts

Overall I was overjoyed with how well the porting process went. I consider it one of my least favourite parts of video game development and the fact it went so quickly and smoothly was excellent. I always listed cross platform support as one of Unity’s biggest drawcards and now I can confirm this. Not just that, but the simplicity of this cross platform development is a real plus. For a small studio, spending months porting to new platforms simply isn’t an option for us and this has allowed us to hit all the platforms we wanted on the same day.

Instead of spending time porting we can now work on updates to Battle Group and future games that we have begun prototyping.

What’s Working

• Tools

The biggest change I’ve seen in our game development lives in the last few years is the ubiquity of high quality game engine tools. It’s no secret that I’m a big fan of Unity and we’re currently using it to create our third game. Unlike our first two games, this time we’re planning to release on no less than 4 platforms simultaneously. Without the power of Unity this would simply not be feasible for a small indie company that’s still in startup mode. I’ve heard the promise of “write once, deploy anywhere” a number of times in the past but it seems like this is the first time it’s actually come true. Unreal and CryEngine are now free giving indie’s great access to high quality development tools.

Along with multi-platform support is the breadth of features found in these tools that means we can create small to medium sized games with multi-month development cycles with only a single programmer in the team.

• Distributed Development

Internet communication has reached a level where we can build an entire game together from the comfort of our respective homes. Leasing an office at this stage in our company would cost more than the rest of the games development combined. With the use of Skype, Dropbox and Acunote we can work seamlessly together sharing ideas and large files as if we were in the same office. There’s still a few issues that come up, but most of these are resolved with weekly face-to-face meetings. We’re still planning to get an office in the near future, however it’s not as pressing a concern as it has been in the past.

• Platforms

Something else that’s changed considerably since I left mainstream game development is the number of platforms we can target. It’s easy to take this for granted, particularly as they’ve grown at a fairly linear rate over the past few years. I’ve always been a firm believer in letting a game design pick the platform that suits it best, however not until recently has this been a feasible option for indie game developers. We can now choose between console, mobile, web and more traditional platforms and have the ability to target them with even the smallest budget. With the barrier to entry being measured in the hundreds of dollars even a hobbyist student can forgo drinking for a few weeks to fund their next game.

What’s Not Working

• Games still take too long to make

I’m continually frustrated with the time it takes to create games. Every game I’ve ever worked on has run overtime, often by over 50% of their original estimate. After speaking to other developers, thankfully this is not just something I struggle with. I’ve found there are two major milestones a game developer reaches in their career. The first is actually finishing a game, something I had trouble with when starting out (I still have countless half-finished projects laying around my old HDD). The second is finishing a game within the original estimate, something nearly every developer I know still struggles with no matter how many years they’ve been working.

I spend considerable time and effort trying to solve this problem and I feel as though each project we refine our process and things are slowly getting better. Despite my first point, I feel tools are the biggest opportunity for us to solve this issue. When I started out in game development I had a very negative view on tools development and felt it was not my job to create tools. I’ve since learnt this is a very closed minded view of game development. Team Bondi’s recent game (and closure) is a perfect example of this. I’ve heard a number of developers share anecdotes of the development where making simple changes (such as the placement of a trigger) would have a turn-around time measured in the tens of minutes. Small issues like this add up over time and cause games to blow out their time and budget.

• Australian Game Industry

I left Auran two weeks before it closed down back in 2007. Since then I’ve watched as many of my closest friends and ex-colleagues lose their jobs as the number of large studios dwindles. There are countless reasons for this downsizing but what’s important is the fact many of the smartest people I’ve worked have been forced to move overseas to find work in the game industry or worse, move into more mundane jobs to make ends meet. I am hopeful that the growing number of independent studios forming from the ashes will see success and we will have a second chance at building the Australian game industry while learning from our previous mistakes.

I’ve heard Alex speak a number of times in the past and a recurring theme is that he is always being asked when his game is finished, and when it will be released. Alex has some strong views on this that I completely agree with, relating to quality levels required before a game is ready for release. Our own game Battle Group has been pushed back from our (internally planned) release date a number of times in it’s 4 month development. It’s a recurring theme on every game I’ve worked on, both independently and at larger studios, they are always late. The question is, how can we objectively determine when the game is finished?

“You’re game is finished when someone who hasn’t played it before can play through it’s entirety without assistance” 

Lets dig a little into what this means. Firstly you (or a few key team members) need to sit and watch people play your game. If you’re not doing this, your game shouldn’t be released, period. Without sufficient playtesting there’s no objective way you can determine if your game is ready or not.

Someone can only play through your entire game once you have no show stopper bugs. I can play a game I’m working on for days on end and never come across an issue which a play tester finds within the first few minutes of playing. The game also needs to teach them enough to be able to play through it’s entirety without your help. This is a really difficult task when watching someone make seemingly simple mistakes in your game. I’ve spoken about this previously with “Virgin” playtesters and spending the weekend watching people play Battle Group only reinforced this for me. If you have to help someone through a certain part, something is wrong.

Related to bugs and assistance is the requirement that you are happy to show people the game in it’s current state. This seems like a no brainer, if you’re not happy to show someone, why would you release? Surprisingly, I’ve seen a number of people so desperate to “just get it out there” that they break this rule. They were all apologies and excuses when I tried to play the game but they felt they were still ready to release it to the world, as if people they don’t know would be more forgiving.

When deciding when a game is finished, there are two areas that people run into trouble:

1. Some people fall into the “it’s never finished” trap. They are usually small teams that aim for absolute perfection and are never happy with the game. These games often disappear and the team gets bored and moves on to something else.

2. At the other extreme are games that are shipped far too soon. These often come from larger studios with external time and money constraints imposed on them.

Either extreme is dangerous and obviously we want to aim for the middle ground between these. Knowing which end of the spectrum you are more likely to favour is important so you can set expectations at the start of the project. The further a game progresses in development the easier it is to diverge towards one of these extremes. When talking about setting the quality level before you begin production on a game I use the analogy of going out drinking. It’s important to set the number of drinks you plan to have in an evening before you start drinking as once you’ve started down that path, your judgement is impaired. The longer your on a project, the more impaired your judgement becomes. Either wanting to “get it out the door” because your sick of working on it, or not wanting to waste the months you’ve been working by releasing an imperfect game.

Only by setting your expectations at the beginning of a project can you have a reasonable chance of setting the quality bar at a safe level. Look at the team makeup, objectives of the game (retail success vs portfolio piece) and project budget/length when deciding what quality bar to aim for.