Programming a video game: The Prequel

***Alert: too much pictures of cats posted lately; it’s time for the programmers to take control of this blog!***

I am Alex (BurritoAl) the programmer of the team.  I will try not to dig too deep into technical details and may start a blog of my own at some point for those interested in the programming challenges involved in creating a game.

It’s been a few month I’ve been programming our game (official name unveiled soon!).  Looking back the first thing I notice is that creating a game really is an organic process and that the design and specs change almost every week.  You cannot get too much attached to your code and need to get into a real prototyping mindset.  Also your team will have a lot of ideas and you cannot get everything done at the same time, so you need to sort out your tasks and prioritize carefully.  Keep things flexible: refact often and early, but not unless necessary.

Tools of the Trade
We settled on Unity as our game engine: simple, cross-platform, big active user community and powerful enough for our needs.  I am not sure how it compares to the big engines for cutting-edge AAA titles, but for our isometric game it is more than enough features (and we took advantage of the new 2D Sprites engine introduced in the 4.x version).

Be wary though that even if Unity is free you will most definitely need to buy the Pro license at some point to (1) have control over the loading screen and remove the Unity logo (2) have access to some automation & advanced build-process functionalities and (3) have access to advanced rendering & debugging facilities when you’ll be in the final stages of development.

But here’s the catch: the Pro license has a per-user and per-platform fee, and you cannot mix free & non-free licenses for the same project.  This can get costly very fast.  For instance, having two developers working on a mobile Android & iOS game quadruples the license cost (not exactly, because you will probably only have 1 build-machine making the mobile-specific versions, but you get the idea!)  For this reason I had to create some editing tools to avoid everyone having to install Unity on their desktop, more on that later.

Also note that even though Unity is cross-platform, iOS is a pain an interesting challenge to develop for compared to Android/PC/Web ports.  Fortunately, we focus on a PC-only release for now!

All-in-all, Unity is an amazing game engine and I’m eager to see what they have done with the version 5 that is bound to come soon.

Our other main tool is a dedicated SVN server which grows exponentially in size as the visual and audio assets are flowing in.  Some tips: try to start using source-control from day-1 of the game development, don't hesitate to branch to test things out, always keep archives of the raw assets and make frequent backups!

For communications / mail, wiki, web-hosting, etc. we are entirely in the clouds.

An Editor within and Editor

Our level editor went from being a plain text-file with some extra scripts, to a text-file with lots of scripts to automate generation, to a more WYSIWYG experience.

It is currently still depending on being run from within the Unity editor, but my goal is to make it completely stand-alone (partly because of the license costs per-user mentioned above).

What I can say is that once you have a full graphics team up & running, they will generate assets like crazy and as a programmer you don’t want to be the integration bottle-neck because you’ll already have a lot on your plate, so having an editor that is somewhat intuitive and efficient to use is the key.

We put the bar quite higher on visual aesthetics as time went by (jumping from a small mobile release to a fully-featured PC release) and the tools have to keep up.  It takes a lot of time to develop and maintain but it also saves a lot in the long run.

Engine Architecture
I will briefly cover some topics about engine architecture:

     - First of all, make sure to clearly separate your data state from the game logic and think about persistence and serialization beforehand.  For example, I added some sanity checks via reflection that raise an error every time they catch a non-persisted data member or field: if a few of them slip through it could be very hard to find bugs after re-loading a game or a map.

-    - Separate internal engine code and make a public interface: the first thing I did is separate into two different modules everything that was internal engine code VS everything that could be scripted on top of it, and I created interfaces to describe the state of every game object.  I have the opportunity to work with talented people that know a little about scripting and I can give them all the tools to create interactive dialogs, triggers and describe a monster behavior without them ever having to modify internal game code.

-     - Game loop & state machines: Unity abstracts the major part of the game events sequencing, game objects management and the actual graphics rendering.  Try to keep the same philosophy by making small independent components.  Think data first (where is the data persisted and what you can do with it).  Don’t create too much dependencies, and magically you will be able to add or remove a whole game mechanics or add a new type of enemy on the fly without breaking everything.

General Development Workflow
    - Always have a playable build;

-          - Set fixed milestones or sprints (for example: a demo or release every 2 weeks);

-          - Stick to your deadlines;

-          - Discuss & clarify ideas: half the work of designing game mechanics and validating gameplay can be done on a whiteboard or pen & paper.  Make sure with the team that the rules are clear: if they are not, define what kind of tests & prototypes can be done to validate the correct direction;

-          - Provide debugging facilities for your team!  Cheat functions, walkthrough statistics, heads-up debug displays, etc.  Anything that can be used to quickly test a situation and understand it.  Take the extra time to develop these, it is well worth the effort;

  - Keep an FPS counter visible somewhere and always be on the lookout for performance drops and memory leaks!



Ok! Enough programming stuff for the day, we’re really eager to reveal some screenshots and actual gameplay descriptions and videos … let’s go back to work and see you soon!

And if you have specific technical questions, please do leave a comment and I’ll be pleased to respond!