***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!
