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.

Speed Dating

Game Connection is described as “speed dating” with publishers. We had 30 minute meetings with as many publishers as we could cram into our time. We had 1.5 of the 3 days Game Connection runs for as we shared a booth with the guys from Last Level Games. This ended up being ample time for us as we met 22 publishers and a few PR/marketing people. Our goal was to form contacts and show off our two prototypes we are developing for iOS, Android and web.

This “speed dating” style was a great way to get in front of publishers we would otherwise never have a chance of meeting face to face. Being from Australia, we are on the other side of the world to many of the publishers, particularly the larger ones. Also, there are a lot of developers pitching their games and having this condensed period for us to briefly meet was perfect.

I had heard from a few people that it is frowned upon for publishers to turn down a meeting with you no matter how small you are, which is perfect for a small team like ourselves. Thankfully, this was true. Nearly every meeting I proposed was accepted and we managed to meet all the publishers we were hoping, from the largest to many small unknowns.

The Process

The process for setting up meetings is fairly simple. A few weeks before the event, the system opens up and you can request meetings with as many people as you have space for. After a set period this shuts down and the system automatically matches you together and sets up a room for the two parties to meet. For the most part, we stayed in our booth (about 3x3m) and publishers came to us. Any spots that are free after this time can then manually be filled in with other publishers. The system does a good job of letting you know whether you both have a free spot at the same time.

My only complaint about this system is it’s a little harsh as I ended up having 16 meetings in 8 hours on my first day. This left me no time for grabbing lunch, let alone a break to use the amenities. Thankfully some of the meetings ran under time (and I had a single no-show) which gave me time to dash off for food and a comfort stop.

Response

Our two prototypes were very much in the prototype stage. I had spent a couple of days coding them and our artist had put a few hours into turning my primary coloured abomination into a nice looking tech demo.

Despite the simplicity of the demos every publisher could see the core of the game and judged it upon its merits. I was blown away by the response from the publishers with all but four giving us amazing responses. Everyone loved the ideas with a number of people giving amazing feedback within only minutes of seeing the games. We even begin discussing specifics of deals with a number of publishers during our short meeting.

One of our demo’s particularly shined and based on the feedback we received we have decided to pursue it next and look at our options for funding and publishing with the people we’ve met. Unfortunately I can’t give any more details as we move forward with our dealings, suffice to say we are extremely happy with the response.

Cost

We were extremely fortunate that the Queensland Government helped pay a large percentage of the usual cost of taking part in Game Connection. This support combined with sharing a booth made it affordable even for a small indie developer such as ourselves. If it weren’t for this, we likely would not have been able to justify the full price of 2,700 to 4,700 Euro’s for the event.

This cost will also likely be restrictive to many indie developers. It makes it hard for me to recommend the event to smaller developers where this amount of money makes up a substantial amount of their entire game budget. It really comes down to what you want to get out of the event. We managed to talk to many of the big publishers and a lot of smaller publishers from around the world that we would simply never be able to meet. If you factor in flying overseas to meet with a publisher this price point quickly becomes reasonable for the sheer volume of people you can meet.

I highly recommend any smaller indie thinking of taking part in Game Connection next year to check out the competitions on offer such as this years.

Should You Participate Next Year?

I highly recommend Game Connection to anyone looking to get their game published. It’s the perfect place to meet with a multitude of publishers to cast out the widest next possible. We found a few publishers we’d never heard of that seem like almost a perfect match for our small indie team. Meeting face to face is vitally important and this was a great way of achieving this.

In the end, it really comes down to the money. If you can afford $2-4k Euro’s then I highly recommend, however if you can’t I’d recommend petitioning your government to see if you can get assistance as we did. I would love to see an “Indie” pass or similar offered by Game Connection for a shorter time at a lower cost.

Conclusion

Have you been to Game Connection or do you plan to go next year? Or is this cost simply too prohibitive?

Single Responsibility Principle

“There should never be more than one reason for a class to change.”

The first principle is the cornerstone of the set and gives the greatest return on investment when followed correctly.  It states that each class should have only a single responsibility and therefore reason to change.  Keeping each class small and tightly focussed allows developers to know exactly where to go to find or add particular functionality to the game. 

Why is having more than one responsibility bad?  Multiple responsibilities means there is coupling between separate pieces of code.  Changes to one responsibility reduce the ability for the class to meet the requirements of the other responsibilities.  This leads to fragile design that breaks often and in unexpected ways.  “Why did changing from rendering API break jumping in the game?”

The way to fix code that breaks this principle is to separate each responsibility into its own class.  The first step can be to extract an interface per responsibility.  Other classes can then rely on these interfaces rather than the class itself.  The class can then safely be split up into separate classes for each responsibility that each implements a single interface.

When have you got it? – The usual culprit breaking this principle is that one (or group) class that’s hundreds or thousands of lines long.  You know the one I’m talking about. Often it’s the GameObject or Entity class that everyone seems to throw code into.  This class usually has about 500 reasons to change, and therefore 500 responsibilities.  It’s usually involved in the heinous bugs that crop up constantly.

Open Closed Principle

“Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.”

The goal of this principle is for each class to change as infrequently as possible while allowing it to be used in as many situations as possible.  While these two requirements may seem at odds they actually complement each other to generate robust design.  A class is open for extension means that the behaviour of a class can be changed in new and different ways as the requirements change.  A class is closed for modification when no source code changes are required for these changes in requirements to be met.

This principle can easily be resolved with data driven design.  By passing the required configuration data to a class it can easily be extended reducing its need for modification.  Any variables (in the mathematical sense) should be passed to the class so that the classes definition itself (the code) does not specify the functionality of the class alone.  I find this the easiest to think about in terms of the basic OOD principle of data and operations.  The class defines the operations it can perform (its functions) and the data that it operates on.  As much of this data as possible should be passed to the class/function.  This moves the configuration of its data outside the class itself to the calling code increasing its ability to change.

When have you got it? – This is the file you dread checking-in because everyone seems to be working on it all the time.  No matter what system you’re working on, these files always seem to be involved.

Liskov Substitution Principle

“Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.”

Inheritance and polymorphism are powerful mechanisms for solving complex problems with simple solutions.  They are also powerful mechanisms for creating bugs and problematic code.  This principle involves making sure inheritance hierarchies are sound and not being abused by code that introduces bugs that are hard to find.  While it seems simple on the surface, this principle can be quite complex to solve correctly.

The first steps to solving this problem are to find instances of checking for an objects type – both its own and that of objects it’s working on.  Beyond this easy first step comes a principle known as “Design By Contract”.  Each function has a set of conditions that must be true before it is called (pre-conditions) and a set of conditions it guarantees are met after its completion (post-conditions).  These are often implied conditions kept in the mind(s) of the programmer(s) working on them.  The first step is formalising these conditions into code.  Once this step is completed the following rule can be met – “Derived classes can only weaken pre-conditions and strengthen post-conditions”.  Put another way, functions of a derived class should expect no more than their base class and promise no less.  This principle is important because of the fact a model viewed in isolation cannot be meaningfully validated.  You don’t know whether your new “Tank” class is valid until you run it in the context of its parent, siblings and other game system.

When have you got it? – Classes breaking this rule are really easy to find.  Look for any base class that uses run-time type information (RTTI) to interrogate its own type (or the type of an object it’s working on).  As soon as the GameEntity class is checking if it’s of type “Tank” to do some special code, you’ve broken this principle.  The class should be able to polymorphically call functions without caring about the actual type of the object.

Interface Segregation Principle

“Clients should not be forced to depend upon interfaces that they do not use.”

Interfaces should be used for communication between different objects to encourage clean, modular code. This principle takes that concept further by making sure that the interfaces we use are themselves clean and unified. The larger the interface, the more the client is relying on functionality of another object. By keeping small segregated interfaces each object will rely upon only the smallest set of functionality it actually requires. This reduces the complexity of links between objects and more importantly, lets someone reading your code know exactly what each class relies upon. Rather than one “fat” interface we break the interface up into multiple smaller groups of functionality that each serve a different client.

This principle links back to the single responsibility principle nicely. In this case each interface should have a single responsibility. This lets you explicitly state the functionality requirements of each object based on the interfaces it requires.

When have you got it? – Look at all your interfaces (abstract classes) and make sure their listing of functions are homogenous.  An easy way to tell you’ve broken this principle is when there are small groupings of functions within the interface definition.  Whitespace is the key here, the more whitespace between the groups of functions, the more disparate they are.

Dependency Inversion Principle

“High level modules should not depend upon low level modules. Both should depend upon abstractions.”

“Abstractions should not depend upon details. Details should depend upon abstractions.”

This is a key point that I had not heard of at all in game development until recently. This principle is quite the opposite of how many developers are used to working. Usually, if a class depends on another class, the client will instantiate an object of that class and then act upon it. Dependency Inversion (also called Inversion of Control) turns this on its head. Instead of the client being responsible for creating the object, it is given the object it depends on. This takes the control away from the client and moves it to the owner of the client, often the game engine.

A good example of this is in a rendering system. Rather than instantiating a rendering object, or directly calling the classes of the rendering API, the rendering system should receive an interface to the low level rendering functionality. By relying on an interface that is given to the rendering system, the low level rendering API can be changed without making breaking changes to the client rendering system. It becomes obvious if breaking changes occur as the low level rendering API’s interface will require changing.

When have you got it? – When two systems are talking to each other, how do they do it?  If they are using concrete classes then look for opportunities for them to rely on interfaces instead.  The best way is for the class to take as parameter to its constructor an interface reference to the class it needs to work on.  This also makes it obvious what sub-systems are particular class is reliant on.

Conclusion

What are your thoughts on the SOLID principles? Do you see benefit from adopting these in the games industry as web and application development has done?

SOLID Motivational Posters, by Derick Bailey

1. Set Your Goals

It’s important to decide exactly why you’re making the prototype, and what you hope to achieve. These goals show you where to focus your time while developing the prototype. For us it’s about testing gameplay mechanics and proving the core concept of the game. A secondary goal is having playable prototypes we can show potential publishers to quickly get across the feel of the game.

Without these goals, it’s difficult to know where your time is best spent. Is this about testing a mechanic on a particular platform or finding whether certain gameplay is fun? Could the game better be served by a pen and paper prototype first? It’s worth spending some time before you begin, deciding the best use of your resources.

2. Timeboxing

I always set a specific limit on how long I can afford to spend on the prototype. It’s easy to get carried away once I start and I can easily lose a lot more time than is necessary. Timeboxing forces me to focus on the most important elements of the prototype as I can’t do everything.

The actual length of time allocated depends entirely on your situation. I allocate 20 man hours per prototype which fits nicely into two work days for me. I find two days is the perfect length for completing the core elements while keeping time short so I am forced to focus.

3. Throw It Away

This is a tough one for some people, but I always recommend planning to throw the prototype away. This has a number of core benefits:

1. Pragmatic – This stops me from doing any big design up front and forces me to do just enough to get the task done. It puts me in a completely different mindset while developing as I just want to get it done as quickly as possible.
2. Lessons learned – When you begin work on the real game you will have previous experience in implementing the same features and solving the same problems. This will help improve the design of the game, both at a software and gameplay level. With some particularly complex problems (“wicked problems” according to McConnell) we must try solving the problem first, before we can fully understand it and find the optimal solution.
3. Less Constraints – If you’re throwing away the prototype there’s less constraints on how you build the prototype. You can use whatever technology is best for prototyping, rather than the best for creating complete games. If you don’t follow company (or personal) guidelines during the development it’s less of an issue, as it’s a completely separate act.

Rather than laying the foundations for your game your doing the opposite, investigating the best way to build it so that when the time comes to lay the foundations you’re in a better position.

4. Key Gameplay Only

I only focus on what’s different about the current game. If I’m making a clone, then really, what’s the point in prototyping? I pick out the gameplay elements that make the game stand out and test those to make sure they work and tweak them. One of our prototypes is a new twist on the platformer genre. I spent as little time on the platformer elements and focussed on “the twist”.

Another way of looking at this is to test the highest risk elements of the game. Gameplay that will make or break the game is important to test as early as possible. Often I find some ideas simply don’t work, and it’s much better to find this out in the first few days of development.

5. Allow Tweaking

I expose as much as possible to my designers and even play testers so they can tweak the gameplay. The game will be in a very rough form and allowing rapid changes to core gameplay can help steer the game in the correct direction.

Another of our prototypes is an asynchronous strategy game. I’ve exposed the start and win conditions and all unit stats. Small changes to these completely change the way the game plays. This is perfect for a prototype as it lets anyone play with the values and suggest changes to the originals. This pushes the burden of experimenting, balancing and tweaking off the prototype team and onto anyone else that plays the game.

6. Divide The Game Up

If I’m working on a large game I’ll divide the different elements up into separate prototypes. For example in the “Total War” series I would make the strategic and battle maps completely different prototypes. This has a number of core benefits:

1. Separate teams can work on each prototype if needed
2. Different technology and tools can be used if helpful
3. Each individual part of the game can be judged independently. Perhaps some areas are less fun than others? You can look at each part as its own game and easily see its strengths and weaknesses.
   

7. Run On Target Platform

I always find that to get the full user experience of a prototype it’s best to run on the target platform. This is core to the gameplay experience and for certain platforms will completely alter the reaction to the prototype.

The only time I don’t do this is when it will blow out the schedule to do so or if there are other constraints that make it impossible (e.g. platform owner restrictions). In this case I do my best to imitate the platform it will run on to get the user experience as close to the real platform as possible.

8. Have External Material

Some things are better completed outside of the prototype itself to save time. I often write tutorials and help screens as a series of screenshots of the game with instructions overlayed. This is far quicker to do in Photoshop than implementing within the prototype. While having screenshots as a tutorial isn’t as good a user experience it saves time that can be spent implementing other features of the prototype.

Another time saver is to walk people through the prototype personally, replacing the tutorial. I like to watch people playing the prototype as much as possible and explaining the game to them is the perfect way to open up a dialog about the prototype.

Conclusion

What are your tips for prototyping? How long do you like to spend and do you throw them away once finished?