Begining Game Development

	This is Part 1 of an introductory series on game programming using the Microsoft .NET Framework and managed DirectX 9.0. WARNING: Managed DirectX is no longer supported.  If you want to do 3D graphics with the .NET Framework, please use XNA (http://creators.xna.com)
Credits : Derek Pierson 3Leaf Development Difficulty: Intermediate Time Required: 1-3 hours Cost: Free Software: Visual Basic or Visual C# Express Editions, DirectX SDK Hardware: None Part I – Introduction

           Welcome to the first article of an introductory series on game programming using the Microsoft .NET Framework and managed DirectX 9.0. This series as aimed at beginning programmers who are interested in developing a game for their own use with the .NET Framework and DirectX. The goal of this series is to have fun creating a game and learn game development and DirectX along the way. Game programming and DirectX have their own terms and definitions that can be difficult to understand, but after awhile, you’ll crack the code and be able to explore a new world of possibilities. I will keep things as straightforward as possible and decode terms as they appear. Another part of the learning curve comes from the math you’ll need to deal with DirectX. I am going to point out some resources along the way that will help you brush up on, or learn, the math skills you’ll need to keep going in DirectX.
In this series, we are going to build a simple game to illustrate the various components of a commercial game. We will cover how to create great looking graphics in 3D, how to handle user input, how to add sound to a game, how to create computer opponents using Artificial Intelligence, and how to model real-world physics. In addition we are going to cover how to make your game playable over the network and how to optimize your game for performance. Along the way, I will show you how to apply principles of object-oriented development and, as well, I will share some of my experience in creating well-organized and elegant code.

Tools:

Before we start writing our first game we need to talk about the tools we will use.
The most important tool for any developer is the Integrated Development Environment (IDE). This is where you are going to spend the majority of your time writing and debugging code, so it needs be powerful and fast.
Visual Studio 2005 (also known by the codename “Whidbey") is the third version of the standard Microsoft IDE for .NET Framework-based applications. Visual Studio 2005 introduces a number of Express versions that provide most of the functionality of their more advanced counterparts but are simplified for the novice, hobbyist, and student developer and cost much less (There are express versions available for VB, C#, C++, J# and for Web Developers using ASP.NET). For this series, I am going to use both Visual C# Express and Visual Basic Express. If you have not already done so, download the C# or Visual Basic Visual Studio Express IDE at: http://msdn.microsoft.com/express.
The second important tool we need to create a great looking game is a graphics Application Programming Interface (API). Without such an API it would be extremely difficult to access the graphics capabilities of your PC. The API we are going use is the DirectX API. This API allows us to create powerful multimedia applications on the Windows platform. To work on the game, you will need to download the latest DirectX SDK at: http://www.microsoft.com/windows/directx/default.aspx. Make sure that you download the SDK and not just the runtime. The SDK includes samples and other utilities that are extremely useful when developing using DirectX.
At some point in your game development experience you are going to have to create or modify graphics. Every copy of Microsoft Windows comes with Microsoft Paint, and while it is not the most powerful program, you already own it and it is good enough for most of our needs.
As we dive deeper into DirectX and cover 3D models and sounds, you might find the need to use other programs to manipulate the image or sound files. As we cover these topics I will point you towards free or inexpensive programs and resources on the Web.
Finally, you need to know where to go to get help. One of the best places is  the public newsgroups. Here, you can ask questions and get answers from people with the same interests as you. Microsoft MVPs and employees also monitor these newsgroups and provide help for you along the way. The newsgroups that are going to be of most interest for game programming are:

• Managed DirectX: microsoft.public.win32.programmer.directx.managed
• C#: microsoft.dotnet.languages.csharp
• VB: microsoft.dotnet.languages.vb

Other places to go for inspiration and help for gaming are:

• The ZBuffer: http://www.thezbuffer.com/
• GameDev.net: http://www.gamedev.net/
• flipCode: http://www.flipcode.com/
• Gamasutra: http://www.gamasutra.com/ [Professional audience, but many articles from Game Developer, including tutorials]

 What makes a successful game?

My first experience using a computer was in 1981 on a Sinclair ZX Spectrum. The first 5 years of my computing life were spent on nothing but writing and modifying games for the Sinclair and later the Commodore 64, but, heck, what else are you going to do as a teenager? While much has changed in terms of hardware capabilities and available APIs, the properties of a great game have not.
Games today have become so complex that they require large numbers of developers, graphic artists, testers and managerial overhead to develop. They rival large commercial enterprise application in their complexity and cost many millions of dollars to develop and market. The payback, however, can be enormous and rival Hollywood blockbuster movies in sales – Halo 2 grossed $100M in its first day of availability.  
All successful games have a couple of features in common that made them stand out.

• The main ingredient for a successful game is the game idea. Regardless how cool your graphics are, how good the music is, if the idea is lame no one is going to play the game.
• The second most important feature is the playability of the game. If the game is too hard then players are quickly going to get frustrated and stop playing. Conversely, if the game play is too easy then the player is going to get bored and stop playing. A good game provides multiple levels of difficulty that continuously challenge the player without overwhelming or boring them.
• Together, the game idea and its playability are the “game design” (not to be confused with “level design,” which is the application of the overall game design to specific segments of the game). There are certain game designers who have a golden touch. Shigeru Miyamoto (the creator of Donkey Kong, Zelda, and Mario) and Will Wright (Sim-everything) are two prominent examples. Miyamoto’s keynote address to the 1999 Game Developer’s Conference is available at http://www.gamasutra.com/features/20030502/miyamoto_01.shtml and Wright’s recent discussion of the design philosophy of Spore (http://www.gamespy.com/articles/595/595975p1.html?fromint=1) are good inspirations for designers of all stripes, while the book “Theory of Fun for Game Design” by Raph Koster has gotten excellent reviews in the community.
• The third ingredient to a successful game is the set of graphics. They need to be good enough to compliment the game idea and game play but not so resource intensive or flashy that they distract from it.
• The final ingredient is performance. No one wants to play a slow game. I still remember an adventure game on my Commodore64 that took 10 minutes to render each scene. I still played it, mind you, because the game idea was great and there were no other options around but it was irritating.  Graphics and performance are closely related. The more fancy graphics you add to a game to slower the performance. The next biggest performance issue is the AI. A lot of game development today focuses on how to make things faster and not coming up with new ideas. However, when you’re learning a complex programming technique such as game programming, it’s vitally important not to optimize prematurely. An understanding of the performance pipelines, and the skills to write clean code, profile it, and improve it are much more important than any single optimized function.  

If you apply your design efforts in this order you, too, can create a great game. It may not be a refined first person shooter like Battlefield 1942, but Tetris is arguably one of the most popular games and has neither fancy 3D graphics nor Dolby digital sound. Even today, games like Gish (http://www.chroniclogic.com/index.htm?gish.htm) demonstrate what can come from creative independent developers. If you can write enough of a game to show your game idea, then maybe you can interest the large gaming companies in your game. The Independent Games Festival is the “Sundance” of the game community, runs concurrently with the professional Game Developers Conference and, believe me, is among the most closely-watched events at the show.

Our Game idea: 

Now that you know what features make a great game, the next step is to lay out the game proposal for our game.
Idea: Since coming up with a unique and creative game idea is the core of any game, I am going to cheat and use the game idea from the first 3D game I ever saw: Atari’s Battlezone. (If I had that great idea why would I let of all you know anyway?) Battlezone is a basic first-person shooter game in which you are looking through the viewfinder of a tank into a 3D landscape. The goal is to destroy as many of the opponent’s tanks as possible before getting destroyed yourself. The landscape includes random objects behind which you can hide. The game screen includes a radar to show you the location of your opponents and the current score.
Playability: The original game started out fairly slowly but kept adding more opponent tanks and other random enemies.  The game also increased the speed and intelligence of the opponents. All of this kept the game challenging but playable.
Graphics: The original game used graphics that proved just engaging enough to feel like you were in a 3D world, but because of the hardware available in 1980 (an 8-bit processor running at 1.5 megahertz) it rendered the 3D objects as wire frames. These graphics were advanced when the game first came out, but we are going to improve upon them using the magic of DirectX (and the magic of 25 years of Moore’s Law!).
Screenshot of Atari’s Battlezone game – complete with wire frame mountains, tanks, and even a wire frame moon for added realism!
Performance: This game pushed the limits of the hardware available at the time. This is evident in the use of the wire frame objects. If the game had been written to fill these objects then it would have been unplayable. With today’s advanced hardware we should not have any performance issues other than those introduced by us writing sloppy code.
Now that we have decided on a game, the next step is to write down the goals of your game. This does not need to be anything formal but the simple act of writing things down has the tendency to make ideas clearer. At a minimum you need to determine the object of the game, what the player can and cannot do and how the player interacts with the game. We also should define what the scoring system is going to be like and what are the victory conditions.
For our game these are the simple specification I came up with.

• A 3D first-person shooter game
• The goal is to destroy as many enemies as possible
• The player can move through the landscape on the ground just as a regular tank can. The tank can not fly, nor can it change speed.
• The game play will be controlled through the keyboard for moving and shooting. The mouse will be used to interact with the menus and start/stop the game. We will not support a joystick.
• The player will receive a score that is based on the distance at which the enemy tank was destroyed. The further the tank was, the higher the score. Each round fired reduces the score by a set amount, unless that round hits a target.
• The game will be divided into levels. Each level will have a pre-defined number of enemies. Once all enemies have been eliminated, the player advances to the next level. There is no limit to the levels.

Now we are ready to do some coding. In general, it is best to write down just the overall idea of the application. Spending a lot of effort upfront designing every little detail is just a waste of time. As we add more functionally to the game we will continuously do small design sessions to formulate our ideas. This iterative approach to developing software is the best way to create good software, and is more fun at the same time.

Creating the game Project:

Now we are ready to write some code. The first step is to create a new solution in Visual Studio 2005.

• Select File | New | Project and choose Windows Application from the template list. In the Name field at the bottom of the dialog, replace the default WindowsApplication1 with BattleTank2005 and click OK.

Visual Studio now creates a new solution for us called BattleTank2005 that contains a single project with the same name.
First, we need to rename the class to something more descriptive. Naming is one of the most efficient methods of keeping code well organized and understandable. Always choose names that clearly describe what the item is doing and avoid meaningless names like Class1 and Form1.

• From the Edit menu, select Find and Replace, then select Quick Replace. Set the Find What field to 'Form1', Replace What field to 'GameEngine' and the Look in field to 'Current Project' (see Figure below). Click Replace All to make this change (there should be five changes made)
• Next right-click Form1 in the Solution Explorer and select Rename. Change Form1.cs to GameEngine.cs.

Replacing Form1 text with GameEngine. You'll thank yourself later.
Another trick to keeping things organized is to ensure that the files in the Solution Explorer are named exactly the same as the classes they contain and to always create a separate file for each distinct element such as each class or enumeration.
Now we have a Windows application that we can run, but it doesn’t do anything. The form has no other controls on it such as buttons you can click or textboxes to display any information. In a regular Windows Forms application we would now add such controls to the forms to create our final application, but for our game we are going draw everything using the DirectX API rather than the Windows Forms API.
We really only need the Form for its Windows Handle, which is basically its unique name among all the other windows on the screen. We will use this handle to set up our DirectX drawing surface. The other use of the Form is that it contains an event that we are going to use to create our render loop.

Adding the Render loop

A game is much different from a regular application, such as Microsoft Word. Word presents a screen to the user that mimics a page in a typewriter and then waits for the user to do something. This something could be pressing the keys on the keyboard or selecting a menu item from the menu with the mouse. While waiting for the user to interact with the application Word does nothing. (Actually I lie: it does do things like run spell checking and auto save in the background but nothing you as the user can see). Generally, programs written using the Windows Forms library generally have the same behavior – they don’t consume CPU time unless the user is doing something (of course, it’s possible to use the Timer control or the capabilities of the System.Threading namespace to do things independent of the user).
Games are different. As you know, smooth movement in games requires the screen to be updated many times per second. The “flicker fusion threshold” at which static images begin to fuse is generally taken to be 1/16 of a second, although it actually varies depending on illumination (brighter lights like computer monitors require higher frame rates) and where on the retina the image falls (peripheral vision requires higher rates than foveal vision). Although movies are shown at 24 frames per second (FPS), 30 FPS is often considered the lowest-acceptable rate for video games, and most actiongame players tune their graphics for no less than 60 FPS.
Because the render loop is called dozens of times per second and runs nonstop, game programming almost always uses the render loop as the “stopwatch” of the game, calculating everything inside the loop, not just graphics, but physics, AI, checking for user input, and scores. (Again, you could use the Timer class or threads to write a multithreaded game, but doing so would introduce significant complexity without any clear benefits and although multithreading in the .NET Framework’s Common Language Runtime  is quite efficient, the slight overhead could knock a couple frames per second off your game.)
So how do we get the computer to run this loop? The form we added earlier has an event called the Paint event. The Paint event for a Windows Form object is called whenever the form is redrawn. This normally occurs only when you maximize a form or when a form is covered by another form that is moved.
As all Windows Forms programming, even game programming, is event-based, understanding the principles of events and event handlers is critical. Although the event is triggered automatically, we need to create a special method called an event handler to be able to intercept the event and do something in response to it..

• In the GameEngine class add the following code after the constructor.

Visual C#

protected override void OnPaint(PaintEventArgs e)
{
          
}

Visual Basic

Protected Overrides Sub OnPaint(ByVal e As PaintEventArgs)
          
End Sub

This is our event handler. When is it called? “OnPaint” – when the Paint event occurs. One thing is still missing. Even though Windows and the Windows Forms library automatically raise the event, some actions that we might expect to trigger the Paint event don’t. Minimizing a window, for example, does not trigger the Paint event, since Windows does not see the need to repaint the entire form (Windows is just being efficient since we are actually displaying less when we are shrinking the form). So we cannot rely on these automatically-created events to manage the loop we need for our game.
Luckily, we can programmatically trigger the Paint event by calling the Invalidate method of a form. This causes the Paint event to be triggered and Windows to enter back into our OnPaint event handler. Then we execute any code we want to run every frame and start all over again by calling the Invalidate method.
You might ask, “Why can’t we just add a while(true) loop directly within OnPaint() and never leave it?” The answer is that even though we’re game programmers, we’re expected to play well with others. Creating a loop within OnPaint() would starve the rest of the programs running on the system. While our game might gain a few frames per second, the rest of the system would become, at best, ugly, and at worst, unstable. So, instead of directly looping, we essentially “ask” to be called again as soon as possible.

• In the OnPaint method add the following line of code:

Visual C#     

this.Invalidate();

Visual Basic

Me.Invalidate()

That’s it, we’ve created our render loop. But there is one more problem. It turns out that not all painting is done in the OnPaint method, Windows Forms triggers another event when the background is erased and by default performs some painting (well, erasing) in response. To force our application to truly only paint inside our method handler, we need to add one more line of code to our application. Since we need to ensure that this code is run when the application starts, we place it into the constructor of the form. This means that we are guaranteed that this code is run before we call any methods on that class.

• In the GameEngine class add the following line of code to the constructor immediately following the InitializeComponent method call.

Visual C#

this.SetStyle(ControlStyles.AllPaintingInWmPaint |
    ControlStyles.Opaque, true);

Visual Basic

Me.SetStyle(ControlStyles.AllPaintingInWmPaint Or 
    ControlStyles.Opaque, True)

Setting the ControlStyles to AllPaintingInWmPaint ensures that Windows only uses the OnPaint event handler to redraw the screen. The second parameter simply informs Windows that our window is not going to be transparent.
Now we have the basic framework for our game. Everything we are going to create from now on out will be actions that occur inside the render loop.

Everything about timers

One issue with this type of loop is that fact that the speed in which the computer can accomplish the tasks in the render loop varies from computer to computer. It even varies on the same computer according to how much memory and CPU time is available for the game at any given moment. We need to have some way of accounting for these differences to make sure that we animate consistently. So instead of treating each frame the same, we are going to calculate the time elapsed between frames and apply that value to our calculations.
There are a couple of different ways of keeping track of time in Windows:

1. System.Windows.Forms.Timer: This is the most common timer used in Windows programming. While it is easy to use, it only has a resolution of 1/18^th of a second. Since we could have up to a thousand frames per second this resolution is not good enough for a game program.
2. timeGetTime: This Windows DLL provides a resolution of 1 microsecond on some versions of Windows and 5 microseconds on Windows NT. This is too variable, and we really don’t want to check the operating system our game is running on to see if we need to adjust the timer values.
3. System.TickCount: This managed call returns the number of ticks that indicate the number of milliseconds. This is close to what we want, but we can do better.
4. QueryPerformanceCounter: This is the preferred timer to use; it has a resolution of less than 1 microsecond. This is the timer most often used in game development.

The last timer is kind of tricky to write since it requires calls to a low-level DLL (kernel32 if you need to know) in Windows. Luckily for us the need for a high-resolution timer is universal and a timer class is included with the DirectX SDK. You can find the timer class in the \Samples\Managed\Common directory underneath the install directory of the SDK. The file we are interested in is called dxmutmisc.cs, but we will use most of the other files in that directory as we add more functionality to our own project.
Before we add dxmutmisc.cs we are going to create a separate folder. Organizing a solution by folders makes it easy to group related items together and keeps the project more organized.

• Selecting Add | New Folder. Name the new folder: DirectXSupport. This is where we are going to add the various support classes as we make use of them throughout this project.

Now we are going to add the existing file to our project. This copies the file to our directory structure. 

• Right-click the DirectXSupport folder and select Add | Add Existing Item and browse to C:\Program Files\Microsoft DirectX 9.0 SDK (February 2005)\Samples\Managed\Common and select the dxmutmisc.cs file.

If you want to, you can browse the contents of this file, it contains various other helper classes that save you from writing a lot of code yourself in addition to the FrameworkTimer class
Since the timer class is contained in a different namespace we are going to add a using statement so we can use the FrameworkTimer without having to write “Microsoft.Samples.DirectX.UtilityToolkit.FrameworkTimer” every time.

• At the top of the class in the using directives region add the following line of code:

Visual C#

Microsoft.Samples.DirectX.UtilityToolkit;

Visual Basic

Microsoft.Samples.DirectX.UtilityToolkit

Next we need to have a way to store the value of the time elapsed. We are going to store this value in the deltaTime variable. Notice that we are declaring this variable as a double. If you declared it as an integer you would lose all of the resolution provided by our high-powered timer since everything would be rounded to an integer.

• At the end of the class above the last two braces add the following line of code.

Visual C#

private double deltaTime;

Visual Basic

Private deltaTime As Double

We want to start the timer at the last possible moment in the render loop so we can get the most accurate time possible.

• At the end of the OnPaint method right before the this.Invalidate call add the following code.

Visual C#     

FrameworkTimer.Start();

Visual Basic

Microsoft.Samples.DirectX.UtilityToolkit.FrameworkTimer.Start()

We need to calculate the elapsed (or delta) time at the start of each loop, because we are going to pass it to most of the subsequent calls we are going to make.

• At the very top of the OnPaint method, before any other code, add the following line of code.

Visual C#

deltaTime = FrameworkTimer.GetElapsedTime();

Visual Basic

deltaTime = Microsoft.Samples.DirectX.UtilityToolkit.FrameworkTimer.GetElapsedTime()

That’s it. We now have a way to track time. As an added bonus, in the next article, we will use this timer to compute our frame rate. You will notice that the solution now will no longer build. This is because the classes in the file we added require DirectX to be referenced. We are going to cover which parts of DirectX we need in the next article.

Summary

We have accomplished a lot in this first article. First, we covered the tools needed to created managed DirectX games and then we discussed the features that make a great game. Next, we defined our game idea and created our game project. After that, we created the render loop we are going to use throughout the game, and finally we added a high resolution timer to our project. 
The next steps all require DirectX, which we will cover in the next article. I hope that this initial article has motivated you to begin that game you always thought about. Game development can be one of the most satisfying experiences in computer programming, and as we progress through this series, I am going to teach you all the fundamentals you need to accomplish that goal.

Zero to 95,688: How I wrote Game Programming Patterns

source: journal.stuffwithstuff.com

About an hour ago, in the quiet of my living room, alone except for a sleeping dog next to me, I accomplished the biggest goal of my life. I finished writing Game Programming Patterns. It’s a book on game programming (it would be a weird title for a book ornithology) that I started writing about four years and a lifetime ago.

What I see now when I run the script that converts my Markdown manuscript to HTML.

It feels weird writing a blog post that doesn’t have any real content beyond my own personal story, but what the hell. It’s not like I have anything better to do! I get some vicarious pleasure mixed with globs envy when I read about other people finishing their books, so I’ll try to add to the canon.

The Call to Adventure

Like most stories, it starts with the hero having something bad happen to him. (Did I just call myself the hero? Seriously? God, this is already going my head.)
About five years ago, I was a game programmer at Electronic Arts in sunny Orlando, Florida. That’s the studio that does Madden, NCAA Football, Madden, Tiger Woods Golf, Madden, and also this football game you’ve probably heard of. They did a few other one-off games too.
I’d been there seven years, which is an impressively long time to actively dislike football while working in an office that lived and breathed it. The last game I worked on, Henry Hatsworth in the Puzzling Adventure was an absolute blast, the kind of dream project you imagine game development to be all about. Just seven dudes hanging out making a cool game they all loved.

My pixel art alter ego in the end credits.

After we shipped, EA decided to never make that kind of mistake again and refocused on
suckling the withering teats of its aging cash cowsthe shareholder-friendly profitability of beloved annual franchises. My entire team quit except me. I ended up bouncing around onto a bunch of different projects.
I was so burned out chunks of char were falling off me, and I was really frustrated by how hard it was to ramp up every time I was airdropped into a new team and its disorganized, deeply coupled, inconsistent code. I’d find bits of real elegance sitting just a few source files away from some hairball that would have benefitted from the exact same structure. People just weren’t talking to each other about their craft and weren’t learning.
Game dev culture, at least at the studio I was at, is kind of weird. One quirk of it is that a lot of the programmers I worked with didn’t give credence to ideas from the larger world of software. Things like Design Patterns were for Nancy-boy enterprise programmers, not real game coders.
On top of this stress, I’d just had a kid, an eventuality I did not plan for when I purchased a 900’ house at the peak of the housing bubble. One frustrated drive home from work, I had an idea: I knew some basic software architecture. I liked writing stuff down. What if I wrote a book specifically targeted towards game developers about this? If I aimed it straight at them, maybe they wouldn’t dismiss it out of hand.

A few notes from when I first started thinking about the book. Note that even then I was pandering to the masses on reddit!

(Also, let’s be honest, it’s not hard to write a more enjoyable read than Design Patterns. I’m pretty sure the Addison-Wesley style manual explicitly demands crushingly boring prose.)
Now, I am a world class project starter. I’ve got hard drives full of stories, videogames, art, music, screenplays, photography projects, table-top games, hell, there’s probably some poetry in there somewhere. But virtually none of it’s done. About the only thing I’d been able to get out the door at that time is the occasional blog post.
I was fully aware that taking on this project was pretty much doomed to failure. But, after visiting the Pacific Northwest, my wife and I really wanted to move, and a book would make for a nice bit of résumé padding to help me find a new job.

How could you not want to live here?

I felt like the book could be our ticket out west. So I needed to figure out every psychological trick I could play on myself to actually get it done.

The structure

If blog posts were the only thing I could finish, why not take a cue from that? Design Patterns is a stack of mostly unconnected chapters. I could organize my book the same way. Then instead of writing a whole monolithic book, it would feel more like writing a few dozen separate articles. Less novel and more anthology.
Likewise, each chapter in Design Patterns has the same top level headings and organization. I could do the same thing, so I didn’t need to come up with a unique outline and narrative for each chapter. They’d just be recipes with different ingredients and instructions.

The workflow

I’m an inveterate tinkerer and I knew if I didn’t put the kibosh on that, I’d spend all day futzing with CSS or some other stupid thing that wasn’t writing. So I spent a day or two putting together a minimal script that would take a file of Markdown for each chapter and convert it to HTML. Once I got it worked, I swore to myself that I wouldn’t monkey with it (much).
Now I couldn’t get distracted by design, style, editors, or anything. Just me, Sublime, and a handful of markdown syntax.

The shame

One thing I’d heard was that telling your friends and family that you intend to do something is a good way to keep yourself honest. So I totally made myself look like an ass and told everyone, “Hey, I’m gonna write a book. Because I’m so awesome. Don’t you wish you were as erudite as me?” Maybe I didn’t word it exactly like that, but I’m pretty sure that’s how it came across.

After working at EA for seven years, they give you seven weeks off. I used some for my honeymoon and then started writing.

The incentive

I’d been blogging for a year or so and one thing I’d learned is that the possibility of a good reddit discussion about my writing was incredibly effective at getting me to complete something and put it out there. So I planned to put each chapter online as I finished it instead of waiting for the entire book to be done.

One of the first chapters posted.

Crossing the Threshold

I rolled this all by my wife and, unbelievably, she agreed to it. Even though it meant she’d have to spend even more time taking care of our infant daughter while I wrote. Even though she knew I’d never finished much of anything before.
I’d like to think she believed in me, but maybe she just really wanted to move out of that tiny bungalow. Seriously, that house was so small we had to move the stroller into the living room every time we did laundry.
With her OK, I started working on a plan. Since padding my résumé was a primary motivation, I needed a real publisher. I figured putting my self-published book on my résumé would sound about as impressive as that “World’s Best Son” mug I got from Mom.
I spent a bunch of time reading submission guidelines. They usually want an outline (check) and some sample chapters (oops). So I spent a couple of weeks writing and revising a couple of chapters. This was a nice trial to see if I could actually write something that looked like a book chapter. Miracle of miracles, I could! For the record, the first chapter I wrote was Object Pool.
I carefully looked at a range of different publishers and their compensation packages before making an educated choice about which ones to submit too. And by that I mean I sent it to O’Reilly because OMG having a book with an animal on it like Perl’s camel book would be SO RAD.
I emailed them the submission with butterflies in my stomach which, when you think about it, is an absolutely pointless physiological reaction given that I was in my house all alone staring at my computer and not being attacked by a sabretooth tiger. A heightened sympathetic nervous system does not actually make email arrive faster.
Unbelievably, they got back in touch. They were interested! I had an editor! He had feedback! He talked to me like I was an actual writer and not some jackass who decided he was an author because he thought it sounded cool. There was talk of a (small) advance. I felt like hot shit.
And then… somehow… it sort of fell through. I don’t remember the exact details, but at some point they decided to not move forward after all. I reached out to a few other publishers and found another one. I signed a contract with Apress and was super pumped to be back in business. We had a writing schedule and everything.
During all of this, I was still writing and managed to get a couple more chapters done. Unfortunately (but unsurprisingly and understandably) my publisher was a little hesitant to have me put them all online, so I didn’t get that jolt of dopamine every time someone on the Internet acknowledged my existence.

The Ordeal

I thought I was back on track but then something funny happened. It turned out I didn’t need to pad my résumé after all. I got a new job. Outside of the game industry and in the city we were desperately hoping to move to.
All of the sudden, we were packing up our belongings, kid, and pets; saying goodbye to friends and family; and moving along what is practically the longest straight line move you can make in the continental US. I was plunged headlong into learning all sorts of new stuff at work that had nothing to do with games. We got another dog and had another kid.
That writing scheduled was looking a little, uh, unrealistic. Eventually, I realized my heart just wasn’t in the book anymore. I called my editor, apologized profusely, and backed out of my deal. Without the pressure to write, I forgot about the book almost completely. I hadn’t abandoned it, really. I told myself I’d get back to is some day. It languished for a year. Then another.
It would have gone into my overflowing bucket of unfinished projects if it wasn’t for one thing: people kept emailing me about it. You see, I’d put the entire table of contents online along with the handful of chapters I had written. Every now and then I would get a long, wonderful email from someone telling me how a chapter really helped some abstract concept click in their mind and how they couldn’t wait for the next chapter. Good god, their enthusiasm made me feel terrible.

Resurrection and Rebirth

About a year ago, I had an unpleasant realization: as I got farther and farther from my days as a professional game developer, my expertise was getting out of date. I was losing the ability to finish the book.
While all my other unfinished projects didn’t bother me that much, the book was special. I’d only ever tried to write this one, and to have it die would break my heart. I figured it was now or never.
Around this time, I’d stumbled onto that article about Jerry Seinfeld’s trick for staying productive. It’s pretty simple: work on it every single day. Don’t break the chain of sequential days. I also met Chris Strom who’s been blogging this way for something like a million years.
Without putting much thought into it, I figured I’d give it a try. I hadn’t written a word on the book in well over a year, but on June 7th, I started a new chapter on Game Loops. I wrote 777 words of first draft, less than an hour of work.
The next day, I wrote 489 words. Then a meager 178. But it wasn’t zero. This weird desire not to break the chain made me drag myself off my ass and at least write something, and once those 178 words were done, I was that much closer to the end. The next day, I did 889 words. The day after that, I finished the first draft.

Interlude: How a Chapter is Made!

I got so wrapped up in my own little narcissistic narrative I forgot to tell you anything useful about the actual mechanics of how I write! Since I decided to post chapters online as I completed them, I knew I couldn’t just do a first draft of the whole book before revising anything. Trust me, no one wants to read a first draft. Instead, I treat each chapter like a little standalone piece of writing. I do it like this:

1. Outline the chapter

Most of the chapters have the same top level structure, but within those headings, I do a pretty detailed outline of what points I want to cover and how they flow together. By the end, I have basically all of the material for the chapter, just with no actual punctuation or grammar. It’s everything I want to say, said really poorly.
Here’s a chunk of outline from the Game Loop chapter:

- old programs used to be batch: ran and quit
- then came interactive programs. these ran forever, which meant loop
- if you write gui app, the os has event loop
  - you receive ui event, handle it, and return to event loop
  - js is a great example
  - you don't see loop, but it's there
  - when app isn't handle user input, it isn't doing anything, just sitting
    there
  - this can work for simple games (minesweeper, solitaire)

I don’t think those bullet points or indentation even mean anything. It’s just word salad.

2. Write the code

The outline will hint at the example code so I know what blocks of code need to be written. Then I come back and write the actual code. Sometimes I’ll interleave this with writing the text, other times I’ll do all of the code up front.
I write the code in separate C++ source files so that I can compile it and makes sure it’s free of errors. For some chapters, I even wrote unit tests. The script that converts the Markdown to HTML pulls in the code snippets directly from those files.
Here’s a bit of markdown for the prototype chapter:

To create a ghost spawner, we just create a prototypical ghost
instance, and then create a spawner holding that prototype:

^code spawn-ghost-clone

One neat part about this pattern is that it doesn't just clone
the *class* of the prototype, it clones its *state* too...

The little ^code tells my script to hunt in the C++ code until it finds:

void test()
{
  //^spawn-ghost-clone
  Monster* ghostPrototype = new Ghost(15, 3);
  Spawner* ghostSpawner = new Spawner(ghostPrototype);
  //^spawn-ghost-clone
  use(ghostSpawner);
}

It stitches in those two lines of code and we’re good!

3. Write the first draft

I hate first drafts. I hate the blank page. I do a detailed outline up front to try to make this easier. And then I rush through this as quick as I can to get it over with. Even so, this part takes the longest and I usually only get about 500 words a day on it.
I try to silence my internal critic during this phase so I can keep making forward progress. I rely heavily on later revisions. Knowing I will edit later gives me the freedom to not edit now.

4. Do the second draft

As soon as the first draft is done, I circle back and do the second. This involves fixing all of the mistakes, bad grammar, and poor flow of the first draft. Sometimes, there’s major surgery here when I decide something I crammed in just isn’t working. I make a lot of changes:

A chunk of the diff from the first to second draft of the last chapter I wrote.

The second draft is shorter than the first. I treat writing like pottery. I slap all the clay on the wheel in a big blob and then iteratively refine it down to the final work. I can get about 1,000 words of this done a day.
I love this part. Feeling the prose get tigher and clearer is exactly as satisfying as refactoring messy code. It’s less stressful because I feel like anything I do now just makes it better but the chapter is safely complete regardless. There’s no more blank page so editing is just pure goodness.

5. Do the third draft

This is the home stretch. At this point, the chapter is almost in its final form. For this last pass, what I’m looking for is mistakes and rhythm.
I read the entire chapter out loud. I can’t stress enough how helpful it is. You can read something ten times and think it’s fine but the first time you run it through your lips you’ll find all of the wrinkles. This fixes awkward repetition and bad cadence. If the prose reads naturally and easily, that’s not because I wrote it naturallly and easily. It’s because I edited the hell out of it.

6. Illustrations

The last thing I do is draw a few illustrations for the chapter. I think visuals are hugely important for making abstract concepts concrete in the user’s mind.
I spent a lot of time trying to figure out how I wanted to illustrate the book. I’d done a few illustrations in Photoshop, but didn’t like how the text looked pixellated. It also made at a real pain to change the design of the site, and looked terrible when retina displays came on the scene.
I thought about doing something like SVG, but that seemed like a huge time sink to get the level of quality I wanted. Eventually, I hit upon the idea of going in the other direction. I decided to hand-draw and scan the illustrations. I could scan them at a high enough resolution to look sharp on a retina screen. More importantly, their intentional imperfection would help turn off the OCD part of my brain that would be unsatisfied with anything less than perfect Edward Tufte-quality diagrams.

Some of the 66 hand-drawn illustrations.

7. Publish and fix bugs

At this point, I think the chapter is done. I put it online and tell the world, and immediately they point out a bunch of glaringly obvious bugs that somehow survived several rounds of editing. I fix those, and now the chapter is mostly solid.

The Long Road

OK, where were we? I started logging each day’s work in a little text file. Less than two weeks later, the chapter was done:

2013-06-18 - Finish third draft of Game Loop
2013-06-17 - 1,280 words revised in third draft of Game Loop
2013-06-16 - ~1,000 words revised in third draft of Game Loop
2013-06-15 - Finish second draft of Game Loop
2013-06-14 - Revise couple of paragraphs of Game Loop
2013-06-13 - Revise ~500 words of second draft of Game Loop
2013-06-12 - Revise ~900 words of second draft of Game Loop
2013-06-11 - Finish first draft of Game Loop
2013-06-10 - 489 words on first draft of Game Loop
2013-06-09 - 178 words on first draft of Game Loop
2013-06-08 - 889 words on first draft of Game Loop
2013-06-07 - 777 words on first draft of Game Loop

I spent some time redoing the design of the site not to be totally busted on mobile devices and then started the next chapter. Now, if this was a movie, this is when the eighties instrumental rock would start and the montage would kick in. Before you know it, the book would be done.
But, I tell you what, I lived that montage, and it did not pass quickly. Working on this damned book was a pain in the ass every single day. I work full time, and have two small kids. We bought a house and all of the work that that entails and it turns out that, holy crap, it’s pretty easy to fill an entire day with stuff that’s not writing a book.
I started getting up early in the morning before the kids so I could have some quiet time. Ostensibly, I would write then, and sometimes I did. But, more often than not, I’d just drink coffee and stare at the Internet while I slowly roused myself. Then, after I’d worked, made dinner, gotten the kids cleaned up and ready for bed, read them books, gotten them milk, cleaned up a bit and gotten them in bed, then, I’d still have to write.
Yet, strangely, I would. I’ve never demonstrated an ounce of self-discipline in my entire life, but for some reason I just didn’t want to skip a day. Even though I was often dog tired, I would scrape up just enough energy to put in a barely half an hour of writing. I would look at the pathetic word count and feel bad before going to sleep exhausted.
But here’s the thing. Even tiny amounts of effort add up if you keep at it. I’d have entire weeks where I felt like I didn’t have a single good writing day, but after two of those weeks… that’s a whole chapter.
Because I was writing every day, it made it easier to build it into the routine. I never had a chance to get used to not writing. It was just this thing that must be in the schedule, like brushing my teeth or eating, even when I traveled or did outings with the kids. I gave a talk at Strange Loop last year, and every evening after dinner, while others were out at bars socializing, I went back to my hotel room so I could write. When I flew to another office for all-day meetings, I wrote on the plane.
The only insurmountable problem I ran into was a camping trip. I couldn’t imagine bringing a laptop to the woods and charging it in my car or something. Instead, I did what comic strip artists do: I banked some days. For two days leading up to the trip, I wrote two sessions a day. Then I wrote early in the morning before leaving, so I only ended up skipping one day. I basically loaned myself the time, with interest.

Refusal of the Return

Once I started putting chapters online again, people started noticing. I got that feedback and encouragement that I thrive on and I was delighted to have stuff to talk about on reddit again.
Around this time, an editor at another publisher reached out to me. Now that I was working on the book again, would I be interested in a publishing deal? She was super nice and was very willing to work with me. I could keep the book online, I could be involved in the design and layout. It could be everything I wanted and more.
I kind of dragged my feet for a while before I finally realized my reluctance was trying to tell me something. When I’d had publishers before, the power relationship felt really strange. O’Reilly and Apress were both great, but I felt like they were in charge, which is really bizarre when you think about how much effort the author puts into it compared to the publisher.
What I was finding was that I really liked it being my book. I’m not doing this for the money, which means I’m doing it for my personal satisfaction. And what’s most satisfying to me is feeling like I got to put as much of my own creativity into it as possible without someone else calling the shots.
That’s not to say I don’t like collaboration. I’ve gotten about 130 bug reports along with a bunch of pull requests, not to mention lots of comments and email. I absolutely treasure all of that, and the book is way better than it would be without that.
I really like working with readers and contributors, but I’m not really interested in working for a publisher. About half-way through the book, I decided to self-publish. That meant I needed to start doing the things a publisher does. In my mind that’s:

1. Developmental editing. When you get a book deal, this is what the editor you work with does. It’s their job to guide the overall direction of the book to make sure it lines up with what audiences want.
   
2. Marketing, advertising, and distribution. Basically, getting the book in front of people and in stores. Making sure people know it exists.
   
3. Copy-editing, proof-reading, illustrations, and design. The sort of blue collar stuff that turns a manuscript into a book.
   

I’d been putting chapters online and interacting directly with my audience since I started the book, so I felt like I had a better handle on what they wanted than most editors would. Having an inbox with hundreds of emails from people is pretty helpful when you’re trying to figure out what they want.
All of the manual labor side of things—editing and design—are some of my favorite parts. Before I was a programmer, I was a graphic designer, and I’ve dreamed of typesetting and laying out a book. Bug reports from readers helped do some of the work of copy-editing. (Special shout-out to mystery superhero colms who basically line-edited the entire book free of charge.) Finding a freelance proof-reader didn’t seem too hard.
Of course, distribution is a mostly solved problem now. Especially with technical books, people buy them from Amazon or get eBooks. I can do those just as well as any New York publisher. You don’t need deals or shelf space any more (though it certainly doesn’t hurt).
That left marketing and advertising—making sure people knew about the book. So I created a mailing list. I added a little blurb to the top of each page saying the book was a work-in-progress and to sign up if you want to know when chapters come out. As of this morning, I have a little over 3,000 subscribers, which is probably more reach than a “real” publisher would have given me.

Finishing the Damn Thing

Once I had that decided and squared away, all that was left was to write the rest of the chapters. So I wrote. And wrote. And wrote. Every single day. I wrote while my wife gave the kids a bath. I wrote at five in the morning before we went on day trips. I wrote when I was sick. I wrote on Halloween, Thanksgiving, Christmas, and New Year’s.
When I finished a chapter, I’d spent a few days where “writing” consisted of fixing bugs, responding to email and other minutia. But then I’d get to the next chapter.
After a while, writing the book receded into the back of my mind. It wasn’t something I thought much about during the day. When people asked what I did outside of work, I’d forget to include it sometimes. It was just ever-present background noise. Exactly 322 days after I started the first draft of Game Loop, all of these little slices of low thread priority background work on the book added up.
95,688 words. 21 chapters. 66 illustrations. 133 fixed issues. Hundreds of commits. Yesterday, I committed the third draft of the last chapter and the manuscript was complete.
I’ve wanted to be able to claim that I’ve written a book for so long that it feels weird to finally be on the other side of finish line. I wrote a book. Not “want to write”. Not “will write”. Not even “am writing”. Wrote.

How 'Game Jam,' an indie game dev reality show, collapsed on its first day of filming

By Colin Campbell 

Game_Jam, a TV-style reality show focused on the efforts of indie game developers, has collapsed in the most publicly acrimonious way imaginable, participants say.

Touted by its makers as a contest to show off the skills and personalities of indie game developers, the Mountain Dew-sponsored production was brought to a halt after just one day's filming, as participants walked off the set, en masse. In a story first reported by Indie Statik, developers accuse the show's makers of grossly misunderstanding the nature of game developers, of attempting to manipulate them for ratings and of crass sexism.

Respected developers like Zoe Quinn (Depression Quest), Davey Wreden (The Stanley Parable), Robin Arnott (SoundSelf) and Adriel Wallick (Candescent) all quit the show along with all other contestants, after what they say were intolerable creative differences with the production crew. The last straw, participants say, was the involvement of a producer called Matti Leshem who insisted on following a line of questioning to the developers about the value of having female developers on the team.

At one point Leshem, who runs a company called Protagonist and represented the interests of sponsor Mountain Dew, reportedly asked Wallick, "Do you think you're at an advantage because you have a pretty lady on your team?" Leshem, they add, displayed an excessive zeal for his bosses at Mountain Dew, insisting that contestants at the show be seen only drinking that beverage.

Arnott, Wallick and Quinn have all posted blog entries about the experience. Jared Rosen, a journalist who has worked under contract for the show's producers and was present , also wrote an extensive and scathing report on the debacle for Indie Statik.

Originally envisioned as a showcase of indie development talent, the show devolved into a reality-style contest, participants said, in which teams were asked to perform various tasks, only loosely connected with game development, for trifling prizes (such as a set of Mountain Dew lawn chairs). Overall prizes were equally derisory, including a trip to a Mountain Dew ski event and a lifetime supply of the drink, as well as a vaguely worded promise of a contract to join the ID@Xbox indie development program.

                            Even prior to filming, the project was dogged by contractual wrangling, as Polaris and its parent Maker (recently bought by Disney) reportedly sought to insist on clauses that irked participants. These included an attempt to control how the developers communicated during and after filming, as well as onerous follow-up obligations, such as attending anniversary shows. We've contacted Maker and Polaris representatives for comment.

 "We all understand it was first a show and second a game jam," Arnott told Polygon. "Our bullshit meters were hanging out at about 15 to 20 percent already going in, but that seemed worth it in order to demonstrate something magical to the public. We knew there would be challenges that would be basically bullshit, but as long as we were working with our friends and showcasing what is magical about our community we were fine."

  By challenges, Arnott here is talking about reality show-style competitions, like creating a YouTube video about their project, or making a presentation about their game using non-digital means.

"Our whole interaction with anybody before the jam went down was nothing but respectful and excited," he added. But the tone of the show, and its alien insistence on confrontational entertainment, soon rubbed the developers up the wrong way.

"They thought they would be able to get a bunch of developers together and put them in a weird situation and turn them against each other," added Wallick. "That is so against the indie culture. It is mind-blowing they didn't see this coming and they thought it was a good idea. We all help each other out. There are interpersonal connections and people argue, but they were so off the mark by what they thought they were going to get out of us. As soon as they tried to pit us against each other they realized, no, this is not going to work."

Wallick said Leshem asked her team if felt they had an advantage because they had an attractive woman on their side. Arnott spoke up, saying they had an advantage because Wallick is a good programmer.

"At this point he's really riled me up," said Wallick. "He's insulted me and everything I hold dear about myself. It crushed my soul in a way. My face was red and insulted. It was awful."

Then, to all-male teams, Leshem reportedly asked if they thought they had an advantage over teams with women on them.

Both lines of questioning caused fury among the contestants, and led to the walk-out.

Wallick and Quinn were the first to say they were leaving, soon followed by the other developers. Leshem was removed from the project, but various attempts by the producers to get the show back on track came to nothing.

"We were all exhausted and stressed out and had nothing to tap into," said Quinn in an interview with Polygon. "If we did try again in that moment, I can't speak for the others, but I know I wouldn't be doing my best work. I wouldn't be showing anything to the world that I'd want to show, and I didn't see a point in it. Plus I couldn't support something that Leshem touched, or was allowed to touch."

The various blog posts all state that Leshem's offensive line of questioning was indicative of a project that had gone badly awry. Attempts by Polygon to contact Leshem have not been successful. One of the show's producers, Jason Serrato, contacted by Polygon via phone, declined to be interviewed.

Akira Thompson, an indie developer and adviser to the of the Interactive Media and Games Division of USC's school of Cinematic Arts, was hired as a consultant to the project, and helped pull together the teams. He said that the show went adrift from its original premise when the sponsorship money came in, and outside producers were hired.

"Early on I was consulting with the Polaris people and telling them what a game jam is, the kind of community we are and the kinds of people we should get involved with," he said. "Although it was pitched to me as a reality show I said, no it can't be that. It needs to be about allowing people to see how games are made and who makes them.

"What happened is that the Polaris guys had the best of intentions but once the money came, the project got too big for them and that is when an outside production company was brought in, from reality TV, and they know what they want to get and they wanted that very specific thing that none of us were privy to.

"They didn't get it and everyone else got fucked. I am angry. This was not what I signed up for. I got my friends to come into this thing and we all thought it was going to be something different and now I look like an asshole, I look like an idiot. It turned into a massive failure and my name is associated with it and so I am very angry about it."

He said that the whole affair is likely to land Polaris and Maker in trouble with owners Disney. Those involved in the show estimate a loss of around $450,000. "I don't believe it is to Maker's benefit to have a lawsuit [against contestants]. Right now they are looking bad," he said. "I think that the best thing that can happen would be a cleaning of house."

• SOURCE
 
• Gamasutra
 
• Indie Statik
 
• Adriel Wallick
 
• Zoe Quinn

UNITY TIPS THAT EVERY DEVELOPERS SHOULD KNOW

5 tips every Unity developer should know

Whether you’re new to developing with Unity or are well-versed in using the tool, we all can appreciate tips that will improve our workflow. With the help of veteran developers who either are or have been part of the official Unity Support Team, I’ve put together a list of great tips that every Unity developer should know and use.

Unity error searching

If you are searching for the meaning or solution to an error message you received in Unity, you can easily find documentation about the specific error with a site search. Using Google, type “site:unity3d.com” followed by your error message. This searches for that error throughout all of Unity’s site and resources, including their forms, tutorials, API documentation and knowledge base all at once.

Garbage collection

If you ever find yourself with the problem of a consistent stutter in your frame rate, which is especially noticeable on a mobile build, the culprit is usually related togarbage collection (GC). GC attempts to reclaim memory occupied by objects that are no longer in use by the game. These are some of the common improvements and misuses which affect the GC.

GameObject instantiate and destroy

If you make frequent calls to instantiate and destroy throughout the lifetime of your game or app, this could affect the GC substantially. Try to create a pool of game objects at the start of your game, which you can then enable and disable throughout your game.

GetComponents

This might be used in tandem with interfacing to create a modular way of having your game objects interact with each other. A collection of components is generated and returned when GetComponents is called, and once this collection is no longer needed, it triggers the GC. Make sure you profile its use and determine if it’s acceptable. You might have to develop another type of architecture to support your game object interaction that does not depend on GetComponents.

String concatenation

This is very common for C# developers. When you concatenate strings (“Hello” + “World”) you are creating a new string object. If you do this each frame, you are adding a good amount of unnecessary GC work when you could be caching or concatenating without +.

Profiler

For those with Unity Pro, the profiler is an invaluable tool that allows you to detect memory leaks and garbage collection issues before your players do. You can run the profiler remotely with Android, iOS and web browsers which will test your game on the actual platform instead the editor. Also when you’re testing remotely, the profiler won’t affect performance like it does when it runs in the editor on the same machine, giving you more accurate data. Another great feature of the profiler is the ability to create code blocks that profile your scripts. You can place the start and finish profiler calls anywhere in your script and really start to dig deep into your game’s or individual algorithm’s performance. If you don’t have Unity Pro, there are some third-party profilers in the Unity Asset Store that work with the free version.

Interfacing behavior

As you become more experienced and comfortable with Unity and design principles, you eventually come to an important conclusion: The more generic a script is, the more it can be reused, making less duplicate code. And the less duplicate code and maintenance there is, the quicker one can roll out a new game. This is a great thing!

And if you develop in C#, once you learn about interfaces and abstract classes, your scripts can even get more generic. I would go as far as saying that with interfaces, you can achieve the most generic design of a single game’s concern or responsibility.

Imagine having a player and an enemy game object in Unity each with their own scripts: a player script, and an enemy script. As these scripts are developed to handle the responsibility of dying for example, chances are it will start to smell of duplicate code. At this point you could create a separate death script with the duplicate code removed from both player and enemy. This is an improvement, but now you’ve created a dependency love triangle between these three scripts. We could instead create an IKillable or IDeath interface. This allows us to easily identify a single responsibility for the concept of dying. At this point we would create a PlayerDeath and EnemyDeath implementation.

But don’t go crazy here either. When some developers first start to use interfaces, they tend to use them for almost every class. This could end up causing the same maintenance problems you were trying to fix, or it could just be a waste of time. There are certain rules and situations which call for the use of interfaces. Make sure you’re aware of them.

Test-driven development

Like a rocketship, test-driven development (TDD) for an individual or group that hasn’t used it before is hard to get off the ground. But once you do, it’s smooth sailing and the benefits begin to show themselves. It all begins with a test that defines the expected behavior of a feature. For example, say your character needs to spawn,at a specific position when they die. You write a test that spawns a player, kills them, then asserts that their position is near that spawn position (or that they collided with a spawn pad maybe). The key is that the spawn code to make the test pass does not exist when you write the test. You only add enough code to make your game compile, which could mean writing an empty spawn class and function. Once the test fails (since you do not have your spawn implementation), you can begin to work towards making it pass. Once the test passes, you can move on to the next feature.

TDD can get much more elaborate, but the benefits are clearly great. Imagine running dozens of tests which all light up green, meaning your game is working as expected. If you get advanced with continuous integration, you can commit your game to source control. This automatically builds, tests and deploys your game for you. Your team can even receive emails when your game passes or fails tests. The downside to TDD, which my team has experienced, has been in maintaining the tests. We wrote hundreds of tests for a third-party Unity testing system, which the developers gave up on. We ended up having to convert them over to Unity’s official test tools, which has just recently been released, and it was time consuming.

Applying these tips when you’re developing with Unity can save you time and frustration. Do you have any methods that make your Unity workflow easier? What are your must-know Unity tips and tricks?