Switching to Game Development

Video games are the driving force behind many programmers aspirations.  I grew up with a Commodore 64, with a tape drive and 3 games of my own.  After beating all 3, I wanted more… but as a kid, buying more games was not an option.  Knowing I couldn’t buy games, I decided to try to make my own.  I dove into the basic language of the C64, wrote text to the screen, discovered the amazing GOTO function and made some pretty terrible stuff.

While the games I built weren’t really worth playing, the experience of writing my own code sparked something inside me.  I realized that even a kid could control computers, make them do what I wanted… I learned that I could code.

Even though my first attempts at coding were all with games, like many people, my first actual programming job had nothing to do with games at all.  In-fact I’ve spent a lot of my career working on business apps, high traffic web sites, hardware test tools, and a variety of other non-game software.  And in that time, I’ve met dozens of ‘business programmers’ who were inspired to learn the craft by video games.  Many of them also had long run deep desires to one day program their own games.  But as professional developers, with bills, families, and responsibility, they often struggled to take the dive.  A couple of them attempted to make the transition into ‘game development’, but most struggled to get started, and that’s for a good reason.

Game development is different

There’s a tendency many people have to think that ‘programming is programming’.. the idea that it’s all the same, you’re just using slightly different libraries or syntax.  I’ve always found this argument to be flawed.  You wouldn’t hire a firmware programmer to build a high traffic AWS hosted web site.  And I wouldn’t hire a database tool programmer to write firmware for my phone.

While all programming is loosely related, and knowing one form does help you learn another faster, there are huge differences in how you code depending on your platform, project, and language.  The same is true for game development.

Don’t let that discourage you though.  If you learn the differences and embrace them, you can quickly take your existing skills and start building games of your own.  But the key there is embracing the differences.. if you try to code your game like you code your WPF app, you’ll struggle, make life harder than it should be, and increase the risk that you never complete a project.

In this series, I’ll cover some of the key differences.  I’ll try to explain how to translate your existing skills into game development, and give you a heads up on pitfalls to avoid.

Embracing the Engine

I want to start with the biggest mistake I see people make as they try to transition.  Almost everyone I’ve worked with who took the dive failed here first.

When I say embrace the engine, I mean really embrace it.  Don’t jump in with the plan to start building your game as the first project you do.  Instead, when you start out, build a bunch of very different games from samples, guides, video tutorials, or anywhere else.  Build small things that can be completed in a day or two.

Imagine you were teach a new junior programmer your craft.  If you’re a web developer, what would you recommend they do first?  Build their ‘facebook but better clone’?  Or setup a simple sample page using your framework of choice?

Remember that when you’re switching to a new platform and technology, you’re starting out like a junior developer.  Perhaps a brilliant junior developer, but still junior none the less.

Building these small games will teach you a lot.  You’ll discover that some things you thought would be hard are actually really easy, if you know what you’re doing.

Moving things

Another area I’ve seen almost everyone struggle with is basic movement.  Many of the developers I’ve known were so accustom to moving objects on their screen via code and never think to try out the animation system.  Instead of spending 5 minutes creating a beautiful animation, they spend hours hard coding movements, then break down when they want to change it even a bit and everything breaks.  Game engines do plenty of things really well, and animation is one of the things they do best.

The same applies for physics..

For example, you may think that building a rope game like Cut the Rope requires some complex physics code, advanced math knowledge, and a ton of work.  But if you know the engine, you can build the entire thing without writing a line of physics code and little to no math skills.

I’ve known people who tried to do similar games, coding it from scratch, because they never took the time to learn about HingeJoint2D component..

The Loop – You can see it! (kinda)

In most programming environments, there’s a hidden loop running.  That loop is pumping messages and events to your components, making your object interactions clean and seamless, calling your web controller methods for you.  This abstraction is extremely helpful for business and web apps, you wouldn’t want to write that code yourself and you don’t need to.

When you jump into game development though, you’ll notice that the loop is visible (or pretty close to visible).  In Unity, the engine calls methods on every gameobject that’s active in your scene, without you telling it to.

These methods call at different times and you need to know how to use them.  For example the Awake() method is called early in the objects lifecycle and is often used to cache references to other objects & initialize state.

The Update() method is called every frame and is a common place for movement code & input handling.

But don’t think you’d do collision checks in Update.. in-fact going back to embracing the engine, collisions are sent to you in a more eventful way using methods like OnCollisionEnter, OnCollisionStay, OnTriggerEnter, etc.

Wait, what’s the difference between a collision and a trigger??  This is exactly the kind of thing that you want to learn early.. (triggers don’t do physics interactions like bouncing/stopping and just call code, while collisions act as you’d expect physics to do)

To learn a bit more about these methods in Unity, take a look at the Execution Order page here.  It has a nice chart that shows you the methods and when they’re called: https://docs.unity3d.com/Manual/ExecutionOrder.html

Frame Rate Matters

Of course we all know that the frame rate of our games is important.  If it drops too low, the game feels bad.  But it also impacts how our code runs..

That’s because methods like Update() are called every frame.  So if your game runs at 10FPS, Update is called 10 times a second.  If it runs at 300fps, well you’ll call Update 300 times a second..

Why does this matter?  Because your code needs to take this into account.  If you move an object on it’s x axis by 1 unit every Update, the speed will vary based on framerate.  At 10fps, it’d move 10 units per second, at 300fps, it’d move a whole lot further..

Again, there’s an easy solution to this in the Time.deltaTime static float you can access.  Multiplying your movement amounts by this will smooth everything out based on your current framerate… but you have to know it exists to use it.

Project Setup

Another thing that’s VERY different from traditional business programming is the project setup.  In my experience, I usually had a solution file that referenced some project files which all referenced code files..  And I had a couple images in a resources folder.

In Unity, the setup is completely based on folder structure, and code is only a tiny portion of your project.  Remember that it’s important, code is only a tiny portion of your project!

And the startup method of your project?  The void main()?  You won’t see it.  For your purposes, it doesn’t exist.

Instead, you start with a scene, in that scene you can do your setup, or in many cases the scene will already be setup and ready to go.. with little to no code initialization required.

That may sound disturbing.  There’s no single place of truth in code that defines how your app starts, where dependencies go or what order to initialize everything in.

It’s not in code… but it is in your scene.  Your scene is where you setup these things.

Often experienced developers find out about this, and immediately create a ‘setup’ scene with a single code file and a setup / main method that builds up their game.  Don’t do this….

This is exactly what fighting against the engine looks like..  Scenes exist for a reason, to make game development clean and quick.  Building everything up in code makes it harder to build, harder to debug, harder to expand, and harder to complete… with no benefits beyond that warm cozy feeling of having a main() or App_Start() replacement.  Scenes are there to help you, and learning to use them correctly is vital to having success.

What about dependencies and Injection?

I’ve written posts in the past about DI in Unity.  After a quick stint of web development, my love for DI was renewed and I experimented again with building a Unity project with DI.

Dependency injection is great in most environments.  If you’re building a web site or a business app and not using a good DI container, you’re probably missing out…  In game development DI is a bit different.

There are a few frameworks out there that do DI for Unity, but they don’t get a ton of traction.. and there’s a good reason..  they also fight against the engine.  They do exactly what I just said not to do, they build up the game in code instead of in the scene.

But how do I setup my dependencies?

Instead of using a DI framework, you really need to embrace the concepts of prefabs and component based development.

Prefabs are somewhat analogous to dependency injection for Unity.  Instead of configuring your object dependencies in code, you do it in the editor and create a prefab to be re-used later.

What about components?

Another big difference with game development is that engines are generally driven by a component based system.  In Unity, this is done by adding ‘components’ to ‘gameobjects’.  These components are just classes that you write (or come with the engine).  The classes all inherit from a common class called MonoBehaviour, and as I covered earlier, these components have built in methods that are called by the engine loop.

Every gameobject in Unity contains at the very least 1 component called a transform.  The transform handles position, rotation, and scale.

To create a working thing in your game, you’ll combine a variety of components.

For example if you were creating a coin that the player could grab, you’d have a transform, a sphere collider, an animator (to make it spin), and a script of your own to handle the coin being hit and consumed.

In this example your code could be as simple as implementing the OnTriggerEnter() method and calling a single line to Destroy the coin… and maybe another line to increment the players coin count..

The biggest benefit of component based development is reusability.  If you develop your components to be small and generalized, you can often mix and match them on a gameobject to create the behavior you want.  Don’t expect to do this right away or in every case, but keep it at the forefront of your mind when writing your own components.

Some skills that translate well (and will give you an advantage)

So far, I’ve talked a lot about things I’ve seen developers struggle with when making the transition to game development.  But there are some skills I’ve seen that are more common on the non-game side of programming and can give you a good boost getting started.

SOLID – If you’re an advocate of solid principals, they can be very helpful.  I’d especially focus on the single responsibility principal.  I’ve seen countless experienced game developers who do amazing things, but struggle to understand and use the benefits of the Single Responsibility Principal.  Remember it when you’re building your components, keep them small, reusable and replaceable.

Another skill I’ve found to be more prevalent in the web world is good use of design patterns.  It’s important to remember not to use patterns that are fighting against the engine, but when you do have a good use for a pattern, having the experience to recognize it, and code it, can be a great help.  A simple example of this would be a knowing when to build a simple state machine instead of a giant switch statement… (i’ve seen way too many of those giant switches).  But again, it’s important to know that there’s also a visual state machine built into the engine with mecanim… it’s primarily used for animation, but fill some other roles occasionally.

And of course your general programming experience is helpful.  And knowledge of the .net framework is a huge help for Unity.

Next Up

There’s still a lot I want to cover.. differences in testing, art, rendering, assets, audio, scene management, project management and more..

In the followup article, I’ll cover some of those things and questions people may have in the comments.

So if you’re wondering about how to translate some skill into game development, please ask away.