December 10, 2008

The Masonic Handshake

Filed under: Games Industry,Personal — bittermanandy @ 11:43 pm

I’ve had a few people contact me to ask, “do you have any advice for how to get into the games industry?” Besides being ironic given that I’m no longer a part of the industry myself, this is a phrase that I really despise, because – well, I’ll get to that in a minute.

I’m going to start by making a couple of assumptions. I’m going to assume that the the person asking the question is really asking, “how do I get a job as a games programmer?” The reason for this assumption is that it’s the only thing I can speak with any experience about. Modern games (at least, console and AAA PC games, which is what people usually mean by “the games industry”; casual or flash games, not so much) involve teams of tens or even hundreds, involving programmers, artists, designers, scriptwriters, musicians, testers, producers, marketing, and a whole bunch of other roles. I’ve worked with all of the above, but I’d be guessing if I tried to tell you how they ended up there.

The second assumption I’ll make is that working as a games programmer is something you really want. The pay is low, compared to non-games programming. The hours are longer (though this is starting change) and the respect from management lower. Most games – and hence, the games worked on by most people – aren’t the amazing high-quality AAA 96%-rated blockbusters like Half-Life 2 that we’d all love to be a part of; in fact, most of the work you do will be soul-destroying just like in any other job. If you’re lucky, you’ll get to work at a company that lets you leave at 5pm, in which case you will get to see the sun; but even if you don’t have to crunch you could easily go months without seeing those strange creatures they call “females”. In fact, for all these reasons and more, I no longer work in games myself. But be clear about this – I’m glad I did it (for about six years). Knowing you’re doing a job you love, and finally seeing your baby on the shelf at Game and hearing someone say “yeah I played that, it’s quite good actually”, is a buzz of fulfilment like no other. Decide for yourself whether the balance works for you. It did for me, for a long while.

Anyway, where was I? Oh yes – “getting into the games industry”. I hate that phrase. It suggests there’s something magical about it, as if you need to know a special password or shake hands with the interviewer in a particular way. The truth is that games have matured into an industry like any other and you’ll get a job programming games the same way you’d get any other job.

Let’s pretend I’m going for a job as an architect. Should I:

(a) spend all day looking at my favourite building, but not really bother about any others because they suck, take a course in Social Studies because you only have to go to three lectures a week, then wonder why architecture companies don’t even respond to my applications even when I put “…it’s what I’ve always wanted to do, and I’m a fast learner!” on my CV; or

(b) learn how to be an architect, get qualified, put together a portfolio, apply for jobs, and make sure I nail the interview?

Third assumption: you answered (b).

Get Competent

If you’re going to be a games programmer, you need to be a good programmer. Sounds obvious really. I’m tempted to say, “it’s that simple”, but of course it’s not. The thing is, if you’ve yet got a job as a professional programmer, you’re probably not aware (even if you think you are!) of what being a good programmer means. That’s OK. The good news is: no-one expects you to.

The simple fact of the matter is that learning to program well comes only with experience. And, if you don’t have QA teams tearing your work to shreds, or customer complaining your software crashes, you may never realise when you’re making mistakes. (Don’t let that stop you coding – a lot – in your spare time. Any experience is better than none). When I first began applying for jobs, I rated my coding skills as 8/10. Looking back, I was more like 2/10. I’m not sure I’m more than 7/10 now, more than six years later. That’s fine – companies looking to employ new hires only really expect 2/10. So why, you might wonder, bother putting any effort into learning to code at all? You’ll learn it all on the job, right? Wrong. Getting to 2/10 is hard (remember the default state is zero!). If you don’t understand pointers, if you can’t fix compiler errors and warnings, if you can’t identify and eliminates bugs in your own code and other peoples’, if you can’t make estimates about the performance of a given algorithm: either learn that stuff or give up now. No company will expect a new hire to be the finished product. But no company will hire someone who hasn’t bothered to learn what they need to know to do the job, either.

What language should you be programming in? I’d love to say C#, but I can’t. Not yet anyway, perhaps in a few years. Currently, most companies only use C# for tools (and some not even then). The overwhelming majority of games companies use C++, and most of the rest use C. (Or, mobile developers probably use Java?) A few devs are starting to use C#, but most don’t and sadly won’t. There are a few very good reasons for this, despite the fact that C++ is a dinosaur and C++0x is going to be at least ten years too late. The first very good reason is that companies currently have millions of lines of C++ and tens of C++ programmers, and they’re not about to throw either of those away just because someone like me claims C# is more productive. The second very good reason is that there is no C# compiler for PS3 or Wii – and that’s a winning argument for companies intending to make games for those platforms. So if you want to make games,  I recommend C# and XNA. But if you want to get a job as a games programmer, I’d be doing you a disservice to say anything other than to learn C++.

You should also have a passing familiarity with two or three other languages (even if only to know that “the major differences between C++ and <language> are…”), an understanding of computer science principles, and above all, the ability to work as part of a team, including with team members who are non-programmers.

Get Qualified

Already, I’m sure some of you out there are screaming at me about this. “You don’t need a degree to be a good programmer!” they’re shouting. That’s not in dispute. “Just because you have a piece of paper, doesn’t mean you are a good programmer!” they’re adding. Completely agree with that too. However, nowadays, if you don’t have a degree in some kind of computing-related field, you probably won’t get past the recruiter’s first cut. Yes, there are exceptions, but they are exceptional! You could take a gamble, but the odds are desperately slim and you’d be much better off getting a degree. (The only time I’d say that doesn’t apply is if you’ve already been working as a professional programmer for years, in which case, yes, experience counts at least as much as a degree. But for a school-leaver or graduate, a degree is, to all intents and purposes, essential).

But – a degree in Computer Science or similar traditional field, or a new-fangled degree in Computer Games Development, perhaps even from a games-specialist University? Well… I cannot deny my prejudice here. My degree was in Computer Science, and I learned things on that course that I don’t think I’d have learned on a games-specific course that since proved invaluable. There is also the consideration that, should things not turn out as you hope, a CompSci degree will get you a job in a non-games company. I’m not sure that a Games degree would do the same. Or, look at it another way: any company will hire someone with a CompSci degree, some companies won’t hire people with a Games degree. That may change over the years, in fact I expect it to, but again – play the odds!

I should mention that at least two excellent people I worked with had Games degrees, so I wouldn’t dismiss someone with a Games degree out of hand. But, I got the impression that they were brilliant despite their Games degree, not because of it. I’ve also seen a lot of applicants with Games degrees who were simply awful and had clearly been let down by their course. It’s up to you, in the end – a Games degree or a CompSci degree is entirely your choice, and either can be made to work – but I’d still suggest that, for now at least, the latter is the better option.

Put Together a Portfolio

So you’re a good programmer and you have a piece of paper to prove it. Excellent! Regrettably, companies will still need convincing. There’s only one way to do that – happily, it coincides with the first piece of advice, “get competent” – and that’s to write some code to show to a prospective employer. (Writing the code will help you become competent, and as you become more competent you will have better code to show to employers).

What kind of code? Well, you’ll need to show a few things really. First, a simple, yet complete, polished, and bug-free game. When I say “simple”, I mean something like Tetris – but when I say complete, I mean with menus, high-score tables, multiplayer, pause, an options screen… everything you get in a pro game. Bug-free should speak for itself… Secondly, you’ll need a more advanced game that may be incomplete but demonstrates more demanding problem-solving. It should involve two or preferably more of the following: 3D graphics, 3D audio, physics, networking, AI, data driven development, and save/load. Finally, you’ll need one game component (from the list above, or “something else”) that is highly polished and well developed and could be plugged into someone else’s game if they chose to use it, so should also be clearly documented with a sensible API.

You should provide this code with your application, either on CD if it’s by snail mail, or on a website  if your application is in electronic form. Provide your complete source code, and make crystal clear exactly which parts were written by you and which by someone else. Also provide the built versions of the software (on the CD, or as a separate download from the code) but remember that actually it’s the code that’s important – recruiters probably won’t run the game and certainly won’t play it for more than five minutes to check it doesn’t crash, but they will be interested in whether your code is well-written. Only ever show your latest, best code – quality beats quantity every time.

Apply For Jobs

First impressions count for a lot: make sure yours is positive. Ensure your CV and covering letter are polished, clear and professional. There’s a lot of websites with good advice which I won’t attempt to repeat here.

Where should you apply? Well, there’s a lot of options. Do some research (subscribe to Develop and Game Developer, and join Gamasutra,, and probably a bunch of other places), and try not to close too many doors. When I was a graduate, I applied to forty games companies. I got three interviews, one of which was cancelled the day before the interview itself, and one job offer, which became two a few months later, after I’d already started working for the first. (In contrast, when I started looking to leave Rare, just six applications garnered me six interviews and five job offers – that’s the power of experience!).

Remember that large companies (EA, Microsoft, Sony, Nintendo, etc) are more likely to recruit new hires than small companies, who may not be able to afford to employ someone who will, inevitably, not be very productive for at least the first six to twelve months. Bear in mind the corporate culture of such companies – though remember you might not be able to afford to be choosy. Medium-sized companies sometimes offer a less corporate culture while still hiring graduates; some are more noted for recruiting out of University than others, for example Rare, Blitz and Codemasters in the UK. (Again consider the implications. Are they hiring graduates because they are able to recognise untapped potential – which is a very good thing – or to get a cheap source of labour – which is a bad thing? You’ll need to work that out for yourself at the interview). Whatever happens, don’t apply blind. I’d encourage you to send lots of applications, but you do need to understand what you’re applying for and why, before you do.

Ace The Interview

Again, there’s plenty of websites that can teach good interview technique, so do some research. I can tell you that having done some interviews myself, there are many things I’d be looking for, but basically I’d be looking to answer these questions: (1) will they be any good at the job? (2) will they fit into the team? (3) would I want to work with them myself? Three yes-es and I’d make an offer, any no-s and I’d give a polite “no thanks”.

To answer (1), as a programmer, you should absolutely expect to be given a programming test at (or possibly before) an interview. I’ve taken a lot of these – erm, about twenty-eight altogether? – and they vary a lot. Some – the worst – ask you obscure questions about bizarre corner cases of C++ in an effort to find out what you don’t know (that the examiner does); others ask you to debug code and write some of your own, to find out what you do know and how well you know it. Most are written, some involve giving you a laptop with a game project on it and asking you to fix the bugs. Some involve general programming knowledge, others are strictly C++ only. Whatever happens, all you can do is your best, and if you’re competent, you’ll do well enough to pass.

(2) and (3) are much more up to you. Remember that they’re looking for someone who is competent and confident, but not arrogant. One of my favourite interview techniques is to say something the candidate should know is wrong. If they agree with me, they don’t know their stuff – no hire. If they quietly say nothing, they might know it’s wrong but aren’t confident – I’d try to give them the chance to show that, but it would leave a question mark. If they argue with me or (as one candidate did) call me stupid, it shows they might have trouble fitting into a team environment, especially with temperamental non-technical types – and I won’t be offering them a job. If, however, they calmly explain that I am mistaken, and in fact the truth is this, which they know because they once did that – well, that’s a model answer.

With all that said, there’s a couple of things you need to bear in mind. Firstly, the company has gone through potentially hundreds of CVs and code samples and chosen you as someone worth inviting to interview. They may have spoken to you on the phone, and they’ve certainly set aside time for one or (usually) more people to take time out from developing a game to interview you. They wouldn’t do that if they didn’t want you to do well. If you’ve been invited to an interview – when you get there, relax. The interviewers will want to hire you, or they wouldn’t have asked to meet you: you just need to convince them that they’ll be right to do so. Secondly – remember that in a sense you are interviewing them, too, and not just when they ask “do you have any questions for us?” You should try to get a sense of the working environment, see if you get on with the interviewers, and think deeply about whether, if an offer is forthcoming, you’d want to work there. I had five very good years at Rare and I have generally positive memories, but my second games job was a big mistake, the biggest of my life – one that I could have avoided if I’d been smarter. At some stage you’re going to have to take the plunge, but if there’s a nagging voice in your head saying “…are you sure?”, make sure you can answer “yes” before accepting the job.

Getting In

With that lot under your belt you’ll soon be getting hundreds of job offers. Good luck! Hopefully you’ll be able to choose a company that is right for you. Making games for a living is a lot of fun and I’m very glad I did it. One day, I may even go back – who knows what the future holds? If you’re visiting this blog chances are you already make XNA games as a hobby and, yes, there are few things better than being paid to do something you’d be doing for fun anyway. Just remember that ultimately it’s a job like any other and you’ll do fine.

Oh yeah- speaking of which – money! Again, do some research (principally in Develop and Game Developer magazines which have annual salary surveys) to find the range of starter salaries in your area. Last I was hiring in games, about 18 months ago, £23-25K was a decent offer for a graduate programmer in the UK (outside London). Unfortunately, as a graduate you’re unlikely to have much leverage to ask for more, but equally, don’t quietly let yourself get shafted just to take a job, any job. You should also consider working hours, benefits, location, company size and stability, and whether there is a career path. In what proportions? Well, that’s up to you!

December 6, 2008


Filed under: Games Development,XNA — bittermanandy @ 12:04 am

Wow, what a time. After having barely played a game all year, I spent weeks playing Fable 2 (very good, though could have been even better), and I’m about to get cracking on Banjo Kazooie: Nuts and Bolts (the last game I worked on before leaving Rare) and Banjo Kazooie XBLA. I’ll be getting Tomb Raider Underworld and the new Prince of Persia for Christmas, and sometime in January, I’ll be surrendering every waking moment to Empire: Total War (seriously – I plan to take a week off work when it comes out). I’ve not so much as had a spare second to check out the games on Xbox Live Community Games, which probably makes me a terrible hypocrite who will be punished in the afterlife. Frankly it’s beyond a joke. I don’t even have enough time to play all of these games, all coming out within two months of each other – never mind time for my other hobbies!

Fortunately the other day I managed to squeeze in a few hours with XNA and spent the time fixing up a few odds and ends I’d been meaning to look at for a while. Specifically, I rearranged the structure of my engine and game code, for clarity and useability. It’s well worth emphasising a couple of points here: first, while I’ve built up this structure after a fair bit of experience with professional game engines and a lot of careful thought, there are undoubtedly other ways of doing it. I encourage you to hunt around, look at what others have done, and deeply consider what will work for you. Second, this is very much a work in progress. I will undoubtedly be tweaking things yet further as time goes by, and I’ve had to make a few decisions “blind” – I’m pretty sure they’re the right choices but it’s entirely possible I’ll reverse them later as experience dictates.

So. At the highest level, the XNA code I write is split into two general groups: engine code (shared code, usable by more than one game, written in such a way as to be reasonably general purpose without being so abstract as to be useless); and game code and assets (specific to one particular game, though sometimes code can start life here before being moved into the engine later). In an ideal world, all your code would exist in the engine, and there would be no game-specific code at all. Games would be differentiated only by their assets – the single executable built by the engine would search for an XML file or similar, that would define what other assets to load, and by a combination of scripting and data-driven design, the game would run with no unique code at all. Realistically, that’s not an achievable goal, and a game will always have game-specific code. The trick is to find a balance.

(First a plea. Don’t “write an engine”. The XNA Framework is so close to being an engine that such a task is pointless, and you’ll also find that no-one will use it – because you won’t have solved the problems you’d encounter if you wrote a game. Hobbyist DirectX programmers all set out to write an engine, and barely any of them ever complete a game. In fact, it wouldn’t be bad advice to write a game first, then only when it’s finished, go back and look at how it can be separated into engine and game code, ready for your next game).

Anyway, let’s have a look at the folder structure of the engine and the games in turn. You’ll want to store all your stuff in a single folder – mine are in Documents\Code\XNA – Visual Studio will encourage you to put everything under the Documents\Visual Studio 2008 folder, but that’s a really bad idea because when Visual Studio 2010 and XNA 4.0 come out you’ll just have to move everything, which apart from being generally inconvenient can be a royal pain if you’re using source control!

Engine Folder Layout

My engine is codenamed Kensei, and is therefore stored in the Kensei folder. Here, you will find the Kensei.sln Visual Studio solution file, as well as my Kensei.FxCop project (with CustomDictionary.xml) and a couple of handy batch files which I’ll come to in a minute. Everything else is stored in subfolders, corresponding to the code projects that are referenced in Kensei.sln (which in turn correspond to the assemblies that can be used by my games).

Kensei – the “core” project containing the majority of the code I write. In here exists my audio engine, camera management code, handy development utility code, command pattern implementation, and everything else I’ll come up with as I add features. Each logical unit is stored in a subfolder of this folder, so for example my audio code exists in Documents\Code\XNA\Kensei\Kensei\Audio – but it’s all built together in a single C# project called Kensei. (I’ve worked on games where each logical module had its own project. It just meant we ended up with fifty-odd projects and fifty-odd assemblies where one would do. It might make it easier to keep things decoupled, but adds headaches via complexity, especially as C# makes circular references awkward or worse. Don’t bother).

Kensei.EmbeddedResources – there are a few things in the Kensei engine that require specific assets. For example, Kensei.Dev uses a font for simple text and a shader for simple shape rendering. At first, these assets had to be copied into the content project of each game prototype I created but that quickly became a pain. The answer (as Shawn Hargreaves describes expertly) is embedded resources.

Kensei.Pipeline and Kensei.Pipeline.Runtime – XNA makes working with assets an absolute dream and most non-trivial games will extend the content pipeline to support custom asset types. Kensei.Pipeline extends the content pipeline itself, while Kensei.Pipeline.Runtime acts as a bridge between the content pipeline and the game – again, Shawn explains in full.

DebugContentBuild – it’s an inevitable fact that all code has bugs, so I followed Stephen’s advice and created a project that vastly simplifies the process of debugging my content pipeline extensions. Basically, running this project attaches to MSBuild.exe and runs the content pipeline on the assets in its content project – allowing me to step into my Kensei.Pipeline code and see where it’s going wrong.

(Other Code Projects) – one of the things I love about the XNA community is the easy willingness with which people share their work. Make use of it! I don’t want to spend my hobby time reinventing the wheel or rewriting something someone else has already done perfectly well (unless, of course, it’s the main differentiating point of my game, or something I have a specific interest in doing or learning. Always in-source your USPs, but don’t even attempt to do everything yourself!). Therefore, my Kensei engine solution contains projects for JigLibX, the Curve Editor Control, and a few other public components, as well as code supplied with various books I own. Which books should you own? Start here!

External – of course, some code isn’t supplied with source, but as a standalone assembly. For example, I use Perforce for source control (accept no substitute! It’s the best there is, period – it’s so good, I use it even though I don’t have to, and I’ve not yet come across any other source control I’d say that about) and the rather wonderful P4.NET lets me write the ability to work with Perforce into my tools. This allows my game editor to automatically check out assets that I work on, for instance. This, and other such assemblies, are all stored in the External folder (with a handy text file so I don’t forget where I got them from…).

Now, with all these projects and assemblies floating about, each built into their own build directory, finding them from the individual games becomes awkward! It’s much easier when all the engine assemblies are in the same place. With this in mind, I wrote the following PostBuild.bat batch file. Every project in the solution runs this as a post-build step (details in the script itself). It copies the output files of the project into the bin folder, so when I create a new game, I only have to look in that one folder for all my references.

@echo off
rem ————————————————————————
rem Run this script as a Post Build Step from every Kensei library to be
rem used by a project or game outside of the Kensei solution.
rem It will place all built files into solution\bin\platform\configuration.
rem This will make them easier to find when adding references.
rem ————————————————————————
rem Post Build Step:
rem call “$(SolutionDir)PostBuild.bat” “$(SolutionDir)” “$(PlatformName)” “$(ConfigurationName)” “$(TargetDir)” “$(TargetName)”
rem ————————————————————————

echo —- Post Build Copy —-
echo Copying %4%5.* to %1bin\%2\%3…
xcopy   %4%5.*   %1bin\%2\%3   /Y   /I   /F

Finally, with all these assemblies floating around, it’s nice to be able to clear everything out and know that a build will start completely afresh. (Why does “Clean” do nothing on a C# project? Alright, Visual Studio handles C# a hundred times better than C++, but I still sometimes want to know that everything that isn’t a source file has been deleted). So I wrote a CleanAll.Bat (warning, use at your own risk, especially if you make use of folders named ‘obj’ or ‘bin’):

@echo off
rem Script to completely start afresh without *anything* still hanging around from previous builds.
rem This is useful to, for example, check what would happen if it was checked out on a clean machine.

echo ——————————–
echo Delete Visual Studio local files
echo ——————————–

del /Q /S *.csproj.user
del /Q /S /AH *.suo

echo ————————————
echo Delete intermediate and output files
echo ————————————

FOR /R %%i IN (*) DO IF EXIST “%%i\..\obj” rmdir /Q /S “%%i\..\obj”
FOR /R %%i IN (*) DO IF EXIST “%%i\..\bin” rmdir /Q /S “%%i\..\bin”


That’s pretty much it for the Kensei engine (well, more or less, as you’ll see in a moment). After seven or eight years with playing around with Visual Studio and trying to arrange large game projects in a way that preserves my sanity, I’m pretty confident that this layout is the easiest to work with.

Game Folder Layout

The whole point of the above is to make creating new games prototypes quick and easy. I’ve got ten or twelve game ideas in my head right now, although Pandemonium remains my main focus, and every time I get a new one, I like to be able to spend one evening slapping something together that just works with a SpriteBatch (for 2D) or Kensei.Dev.Shapes (for 2D and 3D) without spending any time at all plugging the lower-level stuff together. So, all my games exist in the Documents\Code\XNA\Games folder, and reference assemblies in the Documents\Code\XNA\Kensei\bin and External folders. Taking Pandemonium as an example, Documents\Code\XNA\Games\Pandemonium contains (as you’ll have come to expect) the Pandemonium.sln Visual Studio solution, and the Pandemonium.FxCop file (and CustomDictionary.xml) as well. Then there are the following projects in the following folders – again you should be able to guess what they are, and they should be fairly self explanatory when read in combination with the above:

Pandemonium – the game itself. Of course, the content project and all assets are stored in here too.
Pandemonium.Pipeline – content pipeline extensions for the game.
Pandemonium.Pipeline.Runtime – a bridge between the two.

It really is as simple as that, and if I were just writing a quick prototype there would probably only be the first one.


There’s one project I didn’t mention above in the Kensei engine. I’ve only just started doing things this way, and although so far it’s working well I’m a little concerned it may prove inflexible in the long run. I’d encourage you to experiment with it – after all, if a particular game finds it hard work fitting into this model, just don’t use it. It will save you a lot of time on those games that work alright with it.

Basically, I’ve created a project named Kensei.Game, and it contains a single class, Kensei.Game, which derives from Microsoft.Xna.Framework.Game. (Unimaginative names, I’m afraid…) If you’re wondering why it’s a separate project and not part of the Kensei project, that’s because it uses code from all the different assemblies and it was easier to keep it apart than try to prevent them from referencing one another in a circular manner. The idea is, that all of my games can inherit from Kensei.Game instead of (more directly) Microsoft.Xna.Framework.Game, and Kensei.Game can handle all of the things that each individual game would have to do for themselves.

Allow me to provide an example. Kensei.Game provides the following (sealed!) implementation of the Draw method: 

/// <summary>

/// This is called when the game should draw itself.

/// </summary>

/// <param name=”gameTime”>Provides a snapshot of timing values.</param>

protected sealed override void Draw( GameTime gameTime )


    // Prepare the game for drawing


    if ( Kensei.Dev.Options.GetOption( “Draw.Wireframe” ) )


        GraphicsDevice.RenderState.FillMode = FillMode.WireFrame;



    if ( Kensei.Dev.Options.GetOption( “Draw.CullModeNone” ) )


        GraphicsDevice.RenderState.CullMode = CullMode.None;



    Color clearColour = Color.Black;


    if ( Kensei.Dev.Options.GetOption( “Draw.CornflowerBlue”, Kensei.Dev.Options.BehaviourIfNotPresent.ReturnTrue ) )


        clearColour = Color.CornflowerBlue;



    GraphicsDevice.Clear( ClearOptions.Target | ClearOptions.DepthBuffer, clearColour, 1.0f, 0 );


    GraphicsDevice.RenderState.DepthBufferEnable = true;

    GraphicsDevice.RenderState.AlphaBlendEnable = false;

    GraphicsDevice.RenderState.AlphaTestEnable = false;


    // Perform game-specific drawing


    DrawGame( gameTime );


    // Complete drawing


    Kensei.Dev.Manager.Draw( GraphicsDevice,



        Window.ClientBounds.Height ); 

    base.Draw( gameTime );



/// <summary>

/// This is called when the game should draw itself.

/// </summary>

/// <param name=”gameTime”>Provides a snapshot of timing values.</param>

protected abstract void DrawGame( GameTime gameTime );

What this means is that each individual game I write has much, much less to do in it’s (abstract) DrawGame method. I can’t forget to call base.Draw, and I always get the benefits of the same Kensei.Dev options and Kensei.Dev.DevText and Kensei.Dev.Shapes drawing – completely for free. The DrawGame method in Pandemonium is simply this (admittedly, it’s very much work in progress and there’s not much to draw yet, but you should get the idea of how little code there is to write per-game, or per-game-state when it’s a little more developed):

/// <summary>

/// This is called when the game should draw itself.

/// </summary>

/// <param name=”gameTime”>Provides a snapshot of timing values.</param>

protected override void DrawGame( GameTime gameTime )


    m_background.Draw( m_camPosition, ViewMatrix, ProjectionMatrix );

    m_angel.Draw( m_camPosition, ViewMatrix, ProjectionMatrix );


Update, Initialize and other methods are similarly simplified for the individual game, with as much complexity and common behaviour as is feasible moved into the engine.

Incidentally, when you have a base method that needs to do things before and/or after the derived method, I much prefer this pattern of having the base method (Draw here) as public, and have the base method call into protected virtual (or abstract) methods (DrawGame here). This is much superior than having a single protected function and relying on your more-derived class to remember to call the base version of the method. It’s too easy to forget, and too easy to get subtle bugs as a result! Of course, there is a cost. It may be, as I develop my games, that I discover I need to call some game-specific code after base.Draw (or base.Update, or what have you). That would become difficult or impossible in this pattern. If things turn out that way, I’ll have to change it. For now, I’m enjoying the simplicity of my game-specific methods. I can, quite literally, create a new XNA project, change the main class to inherit from Kensei.Game instead of Microsoft.Xna.Framework.Game, and I’ve got all the functionality of my Kensei engine instantly available. It’s very powerful.

(My original plan was going to be even more powerful; I’d create a simple project using Kensei.Game, and with all the necessary references to the Kensei\bin assemblies, and use that as the basis of a Visual Studio Project Template. Then, when creating a new project, I’d select “New… Kensei Game” instead of “New… Microsoft XNA Framework 3.0 Game”. It nearly worked! Everything was perfect, in fact, except that the Export Template wizard didn’t pick up the content project. That’s very unfortunate, and means I can’t use this trick as I’d wanted, but if anyone knows a way around it, please let me know.)

I think that’s enough for now. I hope what I’ve written makes sense, and gives you some ideas on how to structure your own engine and games, code and assets. I don’t claim for a second that this is the only way of doing it, and in fact if you’ve got some better ideas, I’d love to hear about them – leave a comment. This has been a fairly high-level view of the problem and my solution to it, and there are so many tradeoffs to be made at a lower level – something for a future article perhaps, though I’ve tried a number of different structures over the years, and have heard of still more without trying them out yet, and have yet to settle on a favourite. Something to experiment with, for sure. Anyway – let me know if this was useful to you.

Create a free website or blog at