September 17, 2010

Windows Phone 7? Schmindows schmone schmeven

Filed under: XNA — bittermanandy @ 12:51 am

WARNING – rant follows. Those of a sensitive disposition should look away now.

I know this blog has lain dormant for long, but I’ve been working on my game just lately and really getting back into XNA. The chance to work with a halfway sane codebase has been a real relief from my day job, and I’ve really been enjoying it. So I feel bad about this rant, but I have to get this off my chest. It is undeniably one-sided and filled with a certain amount of invective; if you don’t like that kind of thing, it might be an idea to skip this article. There are no coding tips in this article, just heartfelt opinion from an angry man. You have been warned.

XNA is a wonderful and glorious thing of great beauty. It makes game development easy on Windows and more-or-less straightforward on Xbox (though with close-to-zero financial benefit from what I gather). Today XNA Game Studio 4.0 has been released, and what’s the one thing that they keep going on about? Windows Phone 7.

So much so, in fact, that XNA is now part of the Windows Phone Developer Tools. You can’t get away from it! And if you were to visit to the XNA Creators Club website (the first link up there) you’d be forgiven for thinking that it’s the Windows Phone 7 Gaming Creators Club website. Where the hell is all the Windows and Xbox stuff? It’s gone – oh no wait! There’s one tiny little box in the right-hand column that you have to be actually looking for to even notice.

It’s crystal clear where Microsoft are going with this. Windows Phone 7 is their target platform for XNA (Zune appears to have been quietly taken out and shot – hey Microsoft, you can’t create an international brand if you only release it on one continent) and the stuff that is actually cool, easy Windows and Xbox 360 development, has been reduced to nothing more than a forgotten sideshow.

Understand this very clearly. I am a Microsoft fanboy in any meaningful sense of the word. I even still use Internet Explorer despite the fact the whole world is telling me Firefox is better – hey, I like IE, OK? I do. I even worked for Microsoft for getting on for five years, and I enjoyed it, and in another life I might have found a way to stay.

But  here’s the thing. I owned a Windows Mobile 5.0 phone, and it should have been amazing. But that thing was pure hell. Simple tasks – like synching Internet Favourites – failed at the most basic level (one would disappear every time the phone synched, until they were all gone). As a smartphone it was supposed to run my life for me, but when half of my calendar appointments lose an hour if they are in the morning during daylight savings time, with the result that I no longer know when my appointments are, how is it realistically going to do that? That phone, that mobile operating system, that should have dominated the world, instead was a half-assed pile of steaming cow turd that failed on just about every level. I spent hours on the Connect forums for weeks trying to get that phone working, and it just didn’t.

Then the iPhone came along, and it looked really, really nice, but it’s Apple, and I’m a self-confessed Microsoft fanboy. Nevertheless my contract had expired so I could finally get a new phone – but it’s OK! I was told. Windows Mobile 6.1 is much better than 5.0! So (knowing I was making a mistake, but there it was) I got a Windows Mobile 6.1 phone… only to find that not a single one of the issues I had reported in Windows Mobile 5.0 had been fixed. Not one, literally. So again I spent hundreds of hours on the Microsoft support forums trying to sort things out, only to be told in every case “oh yeah, I never use that feature, it doesn’t really work properly”. And it was a two year contract that I couldn’t afford to buy my way out of, so I was stuck with it, and it was the worst phone I have ever owned. I could sit here and write for hours about what made it so bad, I really could.

Happily, I’ve just got an Android (phew, I avoided Apple!) and it’s a thing of beauty. It’s miraculous. I can actually open an internet site in the internet browser and it will actually render! If I then save it as a bookmark, I can come back a week later and the bookmark is still there! Doesn’t sound so amazing? You’ve obviously never had a Windows Mobile 5.0 or 6.1 phone then, because you’d appreciate these things! But now, Windows Phone 7 is on its way… well, no way on Earth was I waiting for that. Not a chance. I have spent hundreds of pounds and hundreds of hours of my life trying to work around basic bugs in Microsoft phone operating systems, and I am very well aware that WP7 is a complete restart compared to WM5 and WM6 (though that didn’t help the KIN…) but sorry, I simply don’t believe that Microsoft know what sane human beings want out of a phone, any longer. I gave them two chances and was punished for it with bug-ridden software and total apathy on their support forums. There will be no third chance. (I am also fairly sure that I am far from the only one to have been so badly burned by WM5 and WM6 – meanwhile, the rest of the world has an iPhone or Android – which by the way now have such magical futuristic features as copy-paste and multitasking, and the excuse “iPhone didn’t have it at launch four years ago” cuts no ice with me).

Long story short: I’m a Microsoft fanboy and even if Windows Phone 7 performed fellatio on demand, I still wouldn’t get one. No non-MS-fanboys are even aware that it’s an option, or if they are they’ll probably get confused with the old WM5 and WM6 phones which were awful. And yet Windows Phone 7 has become the overwhelming focus of XNA. I can see why MS might consider it strategically desirable but this upsets me. As far as I can tell there haven’t been many Windows and 360 features lost in XNA 4.0 (…right?) but if all we’re going to get from now on is Windows Phone 7 shoved down our throats every time we visit the website or the forums, and if all the new features the XNA team are working on are heavily WP7 focussed, XNA itself might get dragged down with Windows Phone 7 when it dies, and that will be a tragedy.

There. I said it. I told you this post would be something of a diatribe, and it got undeniably emotional at times, but I’ve spent the last several years crippled by a godawful mobile phone operating system and that’s the kind of thing that inspires nerd rage. XNA could really make a difference to game development now and in the future, but not if it’s so woefully mistargeted at a platform even Microsoft fanboys have no interest in.

That the next article will be less of a rant and much, much more positive. Pinky promise.

January 22, 2009

It’s not the size that counts

Filed under: Games Development,Games Industry,Personal,XNA — bittermanandy @ 10:37 pm

Indulge me as I walk down memory lane…

It was summer 2002 and I’d just landed my first professional job. (I’m still not sure how. I wasn’t very good back then. I like to think they saw that I’d become good, and I like to think I am good now. It might just have been luck!). I’d spent some time in the RnD department, to learn the ropes, become familiar with devkits (console hardware with added stuff to enable game development), and understand a bit about how the shared game engine worked; and then the time came to move onto a game team, of which there were five or six to choose from. The choice wasn’t freely given. Each team had different needs, so the question was asked: what did I want to work on? What did I want to specialise in?

I didn’t really know how to answer that. I was vaguely aware of the division between systems programming and gameplay programming, and knew that I preferred the former (I actually think the latter is better solved by a good data-driven system and a good designer, though I have worked with gameplay programmers who produced excellent results); but which system? And how would my choice affect my working day?

Games teams on “AAA” titles nowadays can easily have several tens of programmers. Clearly, if they all worked on whatever they fancied from day to day it would be a disaster. Each programmer therefore gets designated an area of responsibility. Generally speaking, the programming lead and the most senior programmers determine the overall architecture of the game early in development (or it may be mandated by the engine, particularly if it is middleware), and the programming team splits into several sub-teams, each led by a senior programmer who reports to the lead programmer. Examples of roles in the team (in no particular order) include:

Graphics: the celebrities of programming because they get to write code that produces awesome looking screenshots (or at least… code that lets the artists do so). Every time the publishers come for a visit, they’ll get led into the graphics programmers’ office and shown all the latest particle-laden explosions on flashy HDTVs. Graphics programmers spend a lot of time writing shaders, optimising the renderer, and talking with artists.
Networking: modern games are immensely complex and with multiplayer online being practically compulsory nowadays, every game will have network specialists. They tend to spend all their time trying to teach other programmers how to write code that doesn’t break the online mode, for example by sending 600KB packets every frame or updating something on the local client but not the game server. They usually look a bit stressed.
Physics: even with middleware like Havok (or in XNA, JiglibX and the like) available, physics remains one of the most complicated things in a game because it affects just about everything else. One game I worked on had five physics programmers.
AI: most games have enemies or some kind of non-player entity. While scripting and other designer-facing tools mean AI is not as hard-coded as it once was, someone’s got to write the code that interprets the scripts – that’s the job of the AI coder.
Audio: given that the only two ways your game can influence the player is via the screen and the speakers, audio is half of every game. Unfortunately it’s the second half (because it doesn’t look good in screenshots) and all too often audio is neglected. Done well, it can turn a good game into a mind-shatteringly atmospheric epic. Audio coders spend a lot of time talking to the musicians and SFX engineers, and they’re usually slightly bitter that the graphics programmers get all the plaudits (and flashy HDTVs).
Tools: there might be twenty programmers on a team, but there might be ten designers, fifty artists, and five audio engineers (as well as testers, producers, marketing, translators…). You can’t just give them a copy of Photoshop and Maya and tell them to get on with it. Every game needs specific tools that enables these people to get their assets into the game and tweaked until fun and in my experience, the better the tools the better the finished game.  Historically tools were DOS-based and unreliable; increasingly, they’re now written in C#/.NET and actually work more often than not. Tools programmers are the unsung heroes of the programming team. Their work is almost never seen by the public, but without them, the game itself won’t get seen by the public either.
Systems: asset loading. The game camera. Multithreading. Save games. Text, and menus. Achievements. DVD file layout. TCR compliance (rules that the console makers require you to obey before your game can be released). Support for steering wheels, dance mats, webcams and chatpads. The build process (putting together versions of the game to give to artists, management and testing). A veritable pot pourri of tasks that no game can go without. Some of these tasks will be given to the most senior programmers because they’re critical to the game’s success. Others will be given to the most junior programmers because they’re relatively self-contained and can be developed in isolation. Most don’t get noticed, until you try to make a game without them!

There’s more, but that’s a good initial summary. (Just think – when you write an XNA game, you’re responsible for all of the above! Lucky XNA itself is brilliant at doing it loads of it for you). My first ever task on a game team was to write the game camera, and looking back I’m pretty proud of how it turned out. Very soon afterward I also took on the audio programming. Eventually, on that first game (I worked on it for three years – some were working on it for twice that), I was responsible for, or otherwise involved with, text and menus, localisation (making the game support other languages), asset loading, the build process, save games and TCR compliance. Later I’d work on asset optimisation and arranging files on the DVD, and probably some other stuff I’ve forgotten. So it became clear: my specialisation was that I was a Jack-of-all-trades. Hurrah!

With all these people working on different things, it’s critical that they don’t interfere with one another by writing over one another’s changes. This is achieved by use of a Source Control System. Basically, this keeps track of every code file and asset in the game, keeps records of how they change over time, and tries to ensure that if two people make changes at once, those changes are seamlessly merged together. Different teams use different products and approach this in different ways. Some examples using the codenames of games I worked on:

Game Two: used CVS for source control. This is an horrific abomination that should be scourged from the earth. A coder would make all the changes he wanted, send out an email to the team saying “please don’t commit”, commit all the files he’d changed, and send another email saying “OK to commit”. Inevitably he’d have missed something so the next coder to update would have to come and ask him to fix the problem before they could continue. Worst of all, the artists couldn’t get anything into the game without giving it to a programmer to commit it for them. This was frustrating for everyone involved and meant that changes to a level, for example, could take two or three days to get into the game. Putting together a build was an eight hour manual process; all too often it wouldn’t start until 5pm the night before a deadline. I’m not completely sure how we managed to get the game finished, and I’m stunned that it turned out as good as it did despite everything. This is How Not To Do It.

Pocket/Pikelet: an improvement in every area, these teams used Source Depot (basically the same as Perforce) for source control. No more emails to control who could commit – a tool that lived in every developer’s System Tray would lock out commits while someone was going through the process of updating, building the game, running the unit tests and committing. A separate build machine would then automatically update to that version, run the tests again and if they were passed make the build available to all the non-programmers – who, incidentally, had the tools available to do all their work without needing to go through a programmer. It was brilliant, broken builds and artist downtime were unheard of – the game was bulletproof throughout development. There was only one small problem. Updating, building, running unit tests and committing took half an hour or more. In a normal eight hour day, only sixteen programmers could do it – at most. With twenty programmers on the team, there’s an obvious problem and it got very frantic near deadlines – and leaving at least a day between committing meant that you’d commit too much at once, introducing bugs (which would fail the unit tests and delay your commit even longer). This was a problem, but in general this was the best system I’ve had the pleasure of working in.

Polished Turd (not the real codename, just what I call it): again this used Perforce for source control, except this time without a formal commit queue like Pocket/Pikelet. The commit queue had originally been introduced to stop CVS from breaking everything, but Perforce is so much better than CVS that actually things rarely break even if you’re free and easy with committing. It meant that you could fix a bug, commit your changes, fix another bug, commit your changes, and iterate very rapidly through your work. You’d update over lunch and overnight, or when you noticed someone had committed something you need. If we’d only had the same team build system, unit tests, build suite, and artists tools from Pocket/Pikelet this would have been the ideal way of working. (Unfortunately all those things didn’t exist so the game was unstable, the artists couldn’t do their job, and every deadline was a mad scramble to put together get something vaguely playable that lasted more than five minutes between crashes).

Now, most people reading this will be hobbyists working in XNA on their own. At the moment, that applies to me too. However, I’m uncomfortably aware that the big blue blobs and soulless grey polygons that currently represent the actors and props in my game won’t inspire other people to play my game – and I’m closer to being autistic than artistic. So sooner or later, I’m going to need other team members to make models, textures, animations and sound for me. (Any volunteers?) And, while I’m currently planning to save all the coding duties for myself (with the XNA Framework itself and the multitude of excellent community libraries out there, this is a realisitic proposition in a non-trivial game for really the first time this side of about 1998) many of you will no doubt be thinking of forming small coding teams, to split the work among you. (I don’t blame you. Just look at the list above. Even a simple game has a lot to do…) So – how well does XNA support medium-to-large game teams? And what would such a team require?

Source control is absolutely essential the moment your team grows larger than one. And, with a team of one or two, there’s only one choice – Perforce, which is free for up to two users, and so good I use it even though no-one’s forcing me to. Unfortunately, as soon as your team size hits three people, it’s something like $700 a license. Ouch. Worth absolutely every penny and more if you’re a pro developer with your outgoings covered by a publisher, but out of reach of everyone else. I am told that Subversion is good for a free product, but I look at the lack of atomic changelists and cringe. Probably the next best if you can’t afford Perforce though. There’s nothing here that’s different for XNA than if you were using C++ or any other language.

It will be essential to have a configuration of your game that allows your artists to put their assets into the game without waiting for you to do it for them. The XNA content pipeline is a wonderful, wonderful thing of great beauty, but by default it is tied into Visual Studio – the content pipeline build occurs just before you run your game, and that’s it. An artist doesn’t want Visual Studio, and he doesn’t want to restart the game every time he changes a texture – he should be able to save off the texture file and see it change in-game. So you need to provide them with a version of the game that runs on its own (perhaps in a WinForm) and a tool that hooks into the content pipeline and will let them build assets while the game is running, notify the game, and the game then reloads that asset. This is pretty easy for assets that already exist in a content project, but the tool will need to support adding to the content project (hidden from the artist) and even creating new ones. All this needs to hook into your source control system without your artist needing to learn to type “p4 -d -a -q -z” or whatever.

The content pipeline causes a few other problems too. (Though don’t think for a second that I’m knocking it. What it does is amazing). Big games tend to generate thousands, even hundreds of thousands of assets – and in the content pipeline, each of those is a different file. People often don’t realise that opening a file, even from a hard drive, can sometimes take as long as a quarter of a second. That doesn’t sound like much until you multiply it by a hundred thousand. (You can very easily see this for yourself by using WinZip to zip up one large file of say 10MB, then compare it to zipping up a thousand files of 10KB each – I guarantee the latter will be much slower). To give an XNA-related example: Kameo, Pocket and Pikelet all used XACT, the same audio tool as provided with XNA (and which I’ve used very extensively). Pocket, in particular, had well over 200 soundbanks which all needed loading at startup. Even though they were only between just 1 and 4KB each, this took a long time to load from the DVD – so long that the 20 second load time mandated by Xbox 360 TCRs seemed an impossibility. The fix was pretty simple: we altered the build process to package all those soundbanks into a single file, loaded the file into memory, and loaded the soundbanks from that memory. Instantly the problem was solved. The same solution won’t work in XNA: there’s no method to load soundbanks from memory. It expects each soundbank as a separate file, and that’s that. A big game in XNA would really struggle under such restrictions. (Loading on a background thread won’t help, 20 seconds of disk access is 20 seconds of disk access and that’s that, though admittedly an XNA game would be on a hard drive not a DVD which helps a lot). You’d have to plan ahead very carefully – in terms of the game design, not just code; which is hard, because designers don’t understand arbitrary restrictions from code, and nor should they have to – to ensure that there was never a need to load so many individual files all at once.

With these caveats in mind I’m convinced a medium-to-large game can realistically be made in XNA. The “poor performance” of C# compared to C++ is for the most part a myth, though to get the absolute 100% optimum out of the hardware might require C++ – but you could get at least 95% of the way there with C#, and 98% of all games don’t need 100% performance. It’s unfortunate that the biggest win for hobbyists and small-team endeavours – the brilliant content pipeline – appears to be the biggest limiting factor for large teams. The issue of when and how assets are built, and how they can be rapidly iterated without restarting the game, is definitely solvable, though with a fair bit of coding effort; the fact that so much of the pipeline relies on a one asset, one file relationship is trickier. A hundred-thousand-asset game would need a hundred thousand files, and loading times would be horrific.

So really large games might not be easy in XNA. Happily (?) few large games nowadays are single platform, and since XNA is not available on PS3 and Gamecube, I don’t think many large teams will be evaluating XNA anyway. Medium teams, independents, and small hobbyist teams can definitely have a field day with it (though profitability of XBLCG at least has yet to be proven). Just remember that the limiting factor for such games is content, and put a lot of effort into making your artists’ lives easy. If they can make a model, put it in your game, play with it, tweak it, play with it again, tweak it, play with it, and check it into source control, they’ll beg to be allowed to make more. If they have to send you the model and wait two days for you to send them a build with it in, they’ll give up within a week. Frankly – even if you’re working on your own, and doing all the code and art yourself, a little bit of work to make good tools will make your own life easier; and isn’t that what we all want?

January 21, 2009

Any requests?

Filed under: Games Development,Personal,XNA — bittermanandy @ 1:51 pm

Wow, it seems like an age since I posted. I guess that’s because it is! Fable 2 took up far more of my time than I expected, I’ve barely touched Nuts and Bolts, and I still have to complete Tomb Raider and Prince of Persia before March, when Empire: Total War is released. This doesn’t leave much time for any meaningful development on Pandemonium, though I have recently chucked together a few little prototypes of stuff I might one day make into fully-developed games.

Anyway I don’t know when it will be that I’ve done enough on Pandemonium to make an update worthwhile. But I don’t want to leave the blog stagnant, it’s still getting a fair number of hits every day and people must have expectations… so I’ll put the question out there: is there anything (preferably XNA-related) you want to read about? Check out the stuff I’ve already written to get an idea of the kinds of things I know. Clue: I’m not the man to ask about whizz-bang graphical effects, but if there’s anything else you’d like to see, just ask.

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.

November 12, 2008

Easy Upgrade

Filed under: XNA — bittermanandy @ 10:08 pm

I was planning to spend the next couple of nights upgrading my Kensei engine and Pandemonium game to XNA 3.0, and making notes of the problems I encountered, so that I may write an article explaining how I overcame them and others may more easily overcome the same problems if they encounter them too.

Unfortunately, I can’t do that – because if I did, the article would consist of the following: “It just worked”.

Yes, it really was as easy as loading up VS 2008 and loading my existing solutions into it. It took a few minutes, to be sure, but I only had to press OK a few times and everything worked. It was so easy that I didn’t believe it at first – I did a batch build of all projects, then a batch rebuild of all projects, then double checked all the references to ensure it really was using XNA 3.0 and hadn’t just pretended to upgrade from 2.0. But it was true – the upgrade really did take zero effort.

So I thought I’d kick things up a notch – bam! – and investigate what Microsoft had seen fit to provide us with in an area that was sorely lacking in 2.0: installation and distribution of my game on Windows. Please understand that this is only a preliminary look at what’s offered, and I might easily have missed some subtleties. Basically you’ve got three choices:

Package as CCGame: this particular option seems to be quietly glossed over in the docs so I suspect it’s just a hangover from XNA 2.0. It’s got the same old drawbacks, in that the recipient has to have the XNA redistributable already installed, and it doesn’t offer any choice of installation location or creating shortcuts on the desktop or Start menu. However, on the plus side, the final output is a single compressed file. It’s much easier to give someone one file than several files and folders.

Setup Project: assuming you have VS 2008 Professional or higher, you can now create a VS setup project that creates an MSI file. (Instructions are also provided to use a third party installer such as Wise, should you so desire). This would also create a single file, as well as giving total control over installation folders, shortcuts, the ability to show licensing agreements; but the downside is that it doesn’t automatically recognise content project files as dependencies, which would need to be added individually. There could be thousands of these in a typical game. Not going to happen. You’ll drive yourself mad trying to keep it in synch with your game. Personally I’ll be avoiding this option like the plague.

ClickOnce: obviously the favoured choice at Microsoft, it’s got a lot of good things going for it. You can set version numbers (and make them update automatically), it installs the .NET and XNA prerequisites for you, you can massage which files get included and define download locations or whether to autorun the CD you burn it onto… brilliant. Plus you get all the expected shortcuts in the Start menu (but not the Vista Games folder, oddly). The downside? The final output isn’t a single file! It’s an exe, and a manifest, and a folder containing all your game files with the extensions changed to .deploy. I don’t really get what that’s supposed to save you. Sure, you can zip it up – but then your user has to open a zip file and run the right exe. You could just as easily zip your game from the bin folder and tell them to run the XNA installer separately, you’ve not saved anything.

Overall these options are a big leap forward from XNA 2.0 but I still wish they’d taken just one more step and either made ClickOnce create just one file, or made the Setup Project more intelligent. At least now there’s a better-than-evens chance that whoever you give your game to will be able to install and play it first time, but it’s still not quite as simple as it could be. It’s possible that I’m missing something, but where the upgrade from 2.0 to 3.0 was a perfectly smooth 10/10 experience, I’d still have to give the Windows distributable options no more than 8/10.

One thing I do like isn’t strictly an XNA feature at all, but C# 2008. Select View -> Code Definition Window, and every time you select a symbol in your code (class, function, namespace, enum…) the window will update to show you the code definition of that symbol. It’s priceless and I officially love it. I’m looking forward to using all the other new features of the IDE and the language.

(Though bizarrely, the Open Containing Folder feature on the active item tab only worked the first time I used it, and never since. If anyone can tell me why I’d be very grateful as I’d use that all the time).

September 2, 2008

Tools of the Trade – Part Five: Pot Pourri

Filed under: Games Development,Tools and Software Development,XNA — bittermanandy @ 11:02 pm

I think that FxCop, Reflector, CLRProfiler, and PIX – all of which I’ve previously discussed in some detail – are the most useful, bread-and-butter tools you’ll use in your XNA development. (In fact, all but perhaps PIX are useful regardless of whether you’re writing games or applications). There are of course many, many more tools, each with their uses, and I’d like to summarise some of them here. The sign of a good craftsman is using the right tool for the job, so I’d encourage you to explore all the different options available to you. Put bluntly, if you’re spending all your time performing repetitive tasks, or going through endless tweak-test-tweak-test cycles to try and hunt down problems in your code, you’re wasting your time. Your time may not be worth a lot to you, but mine is worth a lot to me, so I for one am always looking out for new tools and I think you should too.

Your primary development tool is Visual Studio itself (the Express version of which is available as a free download – possibly the most amazing free thing ever). I’m going to assume you already have it or you’d not be coding in XNA! However, I can guarantee that you are not using it to it’s full potential. I know I’m not. The reason I can make this guarantee is that the full potential of Visual Studio is huuuuuuuuuge. Almost every day, certainly every week, I discover new things it can do and think “that’s amazing!” Start by keeping up with the Visual Studio Tip of the Day, learn how to write macros, take some time to explore for yourself (especially consider keyboard shortcuts), and look out for plug-ins and extensions too. Project Line Counter is a personal favourite.

We’ve already looked at a couple of profiling tools but Perfmon (free with Windows) is the daddy of them all. As an example, hit Start then Run, and type “perfmon”. When the tool loads, select “Performance Monitor”, right-click on the counter list at the bottom and select “Add Counters…”. Select, say, the “.NET CLR Memory” category, then, for example, “% Time in GC”. Choose your game as the selected object and click “Add >>” then “OK”. Hey presto! A line displaying the exact processor cost you are paying for garbage collection will be added to the graph. There are hundreds of counters like this one, and much more that Perfmon can do.

I’m a bit loathe to mention this next one because, frankly, I hate it, but there are some bugs that can only be identified using WinDbg (or “windbag”, free with the Debugging Tools for Windows). Running out of memory and not sure why? Take a memory dump of your game, load sos.dll, call !DumpHeap -stat to see what’s live on the heap, call !DumpHeap -type <type> on the most memory-expensive type it lists to see all the items of that type, and call !GCRoot with the address of one of those objects to see exactly what is keeping it in memory and why. Sometimes there’s just no other way to work out what’s happening to your memory. WinDbg is an advanced tool and it’s an absolute swine to work with, but if the debugger in Visual Studio can’t solve your problem, WinDbg will.

I previously wrote about Reflector and described how it can reveal any assembly’s code to you. How does the code you write get translated from C# to the CLR and IL, and finally JIT-compiled into machine code? Well, I can’t help you with the JITter but IldAsm (free with Visual Studio) can provide a fascinating insight into the Intermediate Language stage of your code’s existence. Much in the same way that you don’t need to understand assembly language to write or use C++, but knowledge of assembly can help you fine-tune your C++ and fix the really tricky problems, knowledge of IL and an understanding of the translation process – while not essential – will make you a better C# programmer.

There’s a whole bunch of tools that are a bit more specialised or esoteric:

Perforce is absolutely the best choice for source control. I can’t live without Perforce now, it’s as though it has become a part of me. It’s free for up to two users, though very expensive for larger teams than that (absolutely worth it if you’re a professional company, perhaps less so if you’re a group of hobbyists, in which case try Subversion).

– If you’re a pro developer and aren’t using continuous integration, you face months of torment in an endless death-march of crunch at the end of the project. Do yourself a favour and use CruiseControl .NET (free).

– Continuous integration becomes even more useful when a build is run against a set of unit tests, and in fact they’re useful for finding mistakes early which is good for anyone, pro or hobbyist alike. I’ve heard good things about NUnit (free)… do as I say, not as I do, and use it… not doing unit testing is my worst programming habit that one day I will get out of. Don’t fall into that trap.

– Perfmon can tell you when you’re slow on the CPU and CLRProfiler can tell you if it’s garbage at fault, but if not and you want to know which specific functions are slow (and you very often do!) NProf is the tool for you, and it’s free.

– Finally, I’ve not used it yet but RPM (Remote Performance Monitor for Xbox, free with XNA) looks to be pretty damn useful for working out why you’re running fine on PC but slow on 360.

The best thing about all of these tools? Like XNA itself, they’re all free. That’s the kind of money I’m OK with spending! It means you have no excuse for not becoming familiar with them and, hopefully, rather than staying up bleary-eyed until 5am trying to find the bug in your code, you can fire up the appropriate tool, find and fix the bug and be home in time to see your family and get a good night’s sleep. Everyone’s a winner!

There’s only one major category of tool I’m missing, and that’s a decent bug database. I’ve tried Bugzilla and OnTime, and at work we have to use Sunrise, and I hate all of them as well as some others. By far the best defect tracking system I used was Product Studio, when I was at Microsoft, but despite being brilliant it is only available with the Team System version of Visual Studio which is very expensive. If anyone can recommend a good, usable, simple bug database that is not web-based and has a good UI, please let me know.

In fact, undoubtedly many of you out there will have your own favourite tools. Why not share the love, leave a comment and let me and everyone else know which tools make your life easier?

“If the foreman knows and deploys his men well the finished work will be good.” – Miyamato Musashi

September 1, 2008

Tools of the Trade – Part Four: PIX

Filed under: Games Development,Tools and Software Development,XNA — bittermanandy @ 9:44 pm

There is one more tool that I want to cover in a little bit more detail before presenting a round-up of the best of the rest (there really are so many good ones out there that this mini-series could last for months or years if I wrote a post for each one). The last article presented the CLRProfiler, a tool to help you manage your garbage and ensure it is being collected properly. Careless garbage collection is often the cause of poor performance on the CPU – but the CPU is only half the story, and to find out what’s causing poor performance on the GPU, you will need to use PIX (available free as part of the DirectX SDK).

Those of you who downloaded and used my Kensei Dev library might have noticed this comment in the Dev Shapes code:

// TODO I have noted some performance issues with this code when drawing very large

// numbers of shapes, but have not had time to profile it and fix it up yet, sorry!

Recently I had a bit of spare time so decided to go back and revisit this section. I set up a very simple test within Pandemonium, to draw lots and lots of spheres at random positions. I discovered that drawing 1000 spheres, or about 860,000 triangles (which doesn’t seem that many to me), caused the frame rate to plummet to only about 6Hz:

Lots of spheres!

Lots of spheres!

Using tricks that I’ve covered and linked to previously it didn’t take long to determine that the GPU was the bottleneck. (For example, returning early out of the game’s Update method, therefore dropping CPU usage as close to zero as possible, had zero effect on the frame rate). So my next port of call was PIX itself.

PIX (originally an acronym for Performance Investigator for Xbox) is an immensely powerful tool and we’re only going to scratch the surface of it here. At the most basic level, you can think of it as a recorder for absolutely everything that happens on the GPU. You can see exactly when every single function that used the GPU was called, and exactly how long it took. You can even rebuild a frame of your game method call by method call, seeing the results rendered step by step, instead of within a sixtieth of a second.

In this case, I want to see which functions are taking so long within a frame. I therefore chose to sample a single frame, as all frames are likely to be pretty much equal in this case. (If, for example, I was seeing a generally solid frame rate with occasional stutters, I’d have had to have chosen a different option).



After starting the experiment and getting to a point where the frame rate was low, I hit F12 to capture a frame (this can take a second or two). After I’d shut down my game, PIX generated a report:

A PIX report

A PIX report

There’s quite a lot going on in this image so let’s take a look at each section in turn.

The top window shows a graphical timeline. It’s not obvious from this picture, but you’ll see it very clearly when you run PIX for yourself, that the bars on the timeline indicate time when the GPU and CPU are busy doing things. As you click along the timeline, the arrows indicate where the GPU and CPU synchronise to the same call. With some classes of performance problem, you’ll see big gaps in one or other processor – these indicate whether you are CPU or GPU bound, for example, if you are GPU bound, you’ll see gaps in the timeline for the CPU where it was waiting for the GPU to catch up. The red circle in the top right of the picture shows the range of calls within our sampled frame (which occurred about 48 seconds in) – it looks mostly empty in the screenshot, but zooming reveals more details.

The middle window shows the DirectX resources in use (remember, XNA is just a layer on top of DirectX) including pixel and vertex shaders, vertex buffers, surfaces and such like. Not of much interest to us at this point.

In the bottom right I’ve selected the Render window. This shows us a preview of the frame as it was constructed. As you advance the cursor along the timeline, this preview is updated – initially getting cleared to Cornflower Blue, then having more and more things drawn onto it. This can be invaluable for detecting overdraw, and is really interesting in its own right. One of my favourite features is the ability to “Debug This Pixel”, which shows every call that affected the colour of any given pixel in the frame. This kind of thing is very useful when investigating transparencies, occluders, quadtrees etc.

Finally, in the bottom left is a list of GPU events, in sequence. Here you can see every call made to the GPU during the sample (note how they are all Direct3D calls, as mentioned above). Using the timeline view, I was able to visually identify which function call was the most expensive. Clicking on that call in the timeline synchronised it in the events window. I’ve circled the call in question. You can see from the StartTime of each event that the call to IDirect3DDevice9::DrawPrimitiveUP took 107349677 nanoseconds, or 107 milliseconds. When you consider that a whole frame normally completes in just 17 or 33 milliseconds, this one function call taking 107ms is a massive limiting factor on my frame rate.

Using a combination of intuition, logic, common sense, and the Render window (clicking on the call previous to DrawPrimitiveUP removed all the spheres from the preview, so it’s obvious what it was drawing!) I identified the corresponding code in my XNA program:


        PrimitiveType.TriangleList, s_triangle3DVerticesArray,

        0, s_triangle3DVertices.Count / 3 );

You may not think this tells me very much. I already knew that the Kensei.Dev rendering code was slow, that’s why I fired up PIX in the first place! In fact, this is hugely valuable information. I know exactly which line of code is causing my GPU to run like a dog with no legs.

As this is a call to DrawUserPrimitives, it seems likely that the reason for this call being so slow lies in the User part of the method name. That is to say, the Kensei.Dev code builds up an array of vertices (s_triangle3DVerticesArray) each frame, and passes that into the function. This involves copying all those 860,000 triangles from main memory into the GPU memory, and is in contrast to using a vertex buffer, which lives on the GPU. If I can find a way to use native GPU resources and avoid the User methods, I may get a substantial speed boost; on the other hand, the User methods exist for the very usage scenario I’m using here, which is of vertices that can arbitrarily change position from frame to frame and which are controlled by the CPU.

Alternatively, it was suggested on the XNA Creators forums that I may be expecting the GPU to do too much in one go, and that splitting up the calls into smaller batches may improve performance. This is somewhat contrary to my understanding of modern GPUs, which, I was led to believe, vastly prefer to perform fewer operations on larger datasets than more operations on smaller datasets; nevertheless I am far from a GPU expert so will be taking that advice, and experimenting with splitting the vertex array/buffer into smaller pieces to see if this improves matters.

There are a few more possibilities as well. I’d like to say this story has a happy ending, but it doesn’t, at least not yet – I am hopeful for the future. I am still trying to solve this problem and find how to avoid this bottleneck. However, whenever investigating performance it is absolutely essential to base your observations and lines of inquiry on hard evidence. At the beginning of this article, I knew that “something in Kensei.Dev is slow”. PIX has since revealed that “DrawUserPrimitives is taking over 100ms to draw 860,000 triangles”. This will allow me to precisely focus my efforts, and hopefully find a correct, performant fix for the problem.

PIX has an awful lot more to offer than just single-frame samples and as your game nears completion you will probably find a lot of value in it. There are a lot of bugs that simply can’t be solved any other way, and if you are doing anything remotely clever with your graphics I strongly encourage you to learn about what PIX can do for you.

“My mistress’ eyes are nothing like the sun…” – William Shakespeare

August 10, 2008

Come Play With Me

Filed under: Games Development,Pandemonium,XNA — bittermanandy @ 4:28 pm

The first few articles on this blog have been written with the intent of sharing ideas, information and best practices with everyone else out there with an interest in developing games. It sounds like at least some of you are finding it useful, and I’ve been getting some great feedback, as well as ideas on how to make it even better.

I hope you will forgive me if I take a moment to be rather more selfish, and shamelessly publicise my in-development game, Pandemonium. That said, as well as showing off (the very early stages of) my game, this video also demonstrates several of the techniques I’ve talked about previously, most notably Kensei.Dev.Options and using PropertyGrids to rapidly tweak game variables.

I know, it’s not exactly full of eye candy! At this stage it doesn’t worry me. You can probably tell that Pandemonium is going to be a third-person platform game, very much in the vein of the classic Mario 64 or Banjo Kazooie games. The key to this genre of games (as with all games, really!) is the character control – if the player doesn’t enjoy moving their character around, they’ll never enjoy the rest of the game; and I’ve therefore decided to concentrate on honing the control first, before I start worrying about graphics, models, shaders and other such trivialities.

To this end, I’ve knocked together a small test level, which I’ve called the Playground, that contains a whole bunch of geometry for my avatar to run and jump around. I’ll use this level to refine how my character moves, and establish early on how far it can jump, how fast it can run, and other constraints that will make later level design much easier. Over time, as I add more features to the game, the Playground will get expanded; by the end of development, I’ll be able to load up the Playground and instantly test or demonstrate anything the player can do on any level of the game proper.

I mentioned SketchUp (the 3D design tool I used to create the Playground) before, and I used Bulent’s Screen Recorder to capture the video.

“I think I can make an entirely new game experience, and if I can’t do it, some other game designer will.” – Shigeru Miyamato

August 2, 2008

The Path to Wisdom

Filed under: Games Development,XNA — bittermanandy @ 8:45 pm

I’d originally been planning to show off the the (very!) early stages of my game, Pandemonium, today; but I hit a minor bump in the road and it’s not quite ready for showing yet. (Top tip: if CLRProfiler.exe keeps displaying a “Waiting for the .NET Framework” message when you run your game, then keeps crashing when you shut it down, try running as Administrator. Took me hours to work that one out…)

Instead I think it’s a good time to tell you about the Five Books You Must Own If You’re Writing XNA Games

Game Coding Complete, 2nd Edition (Mike McShaffry)

You might think this a strange selection as XNA doesn’t even get a mention, not even once. All the code samples are in C++ and DirectX. So why is it the first book on the list?

The very simple reason is that whether you use C++ or C# is, really, just an implementation detail (though obviously, C# is better! :-). What you will get in this book is a massive 884 pages absolutely jam-packed with valuable information about games, making games, and the games industry from someone who has been there and done it all. I struggle to think of a single topic (XNA excepted) that the author doesn’t discuss with familiarity and wisdom, in an easy style. Design? Coding? Scheduling? Testing? Algorithms? Maths? Graphics? Audio? Networking? 2D and 3D? It’s all there. This is, I believe, the single best book about games development that has ever been written. You need it on your bookshelf – no, on your desk, within easy reach.

Microsoft XNA Unleashed (Chad Carter)

The range of XNA books available is slowly growing, and I’ve got most of them. (Not all of them are good. I’ve been through the pain of reading some of them so you don’t have to…). I keep coming back to XNA Unleashed for a few reasons. Firstly, it covers pretty much the whole range of what XNA can do, and takes great care to ensure that the earlier stages are described in great detail, making it an ideal first purchase if you’re just getting into XNA. The second reason is that the supplied code samples (on CD and downloadable) are particularly clear and well-written, and include a whole bunch of classes and methods that you’ll find yourself coming back to time and again. Recommended.

XNA Game Programming Recipes (Riemer Grootjans)

I wasn’t sure what to expect from this book when I ordered it. The idea of arranging the contents into recipes just seemed a strange way of doing it, it didn’t seem to match up to the way I read books.

All I can say is that it is a format that works brilliantly. The author writes in a style that is clear, simple and to the point. (This does mean the absolute basics don’t get treated in as much detail as in XNA Unleashed, but it is otherwise a much better book for intermediate or advanced coders). Each recipe is either self-contained or references the work that it builds upon, and there are some stunning ideas here, all explained very clearly and concisely.  It’s the kind of book you can flick through, open up a random page, read for a bit and think: “…that’s brilliant!” Even on my first skim through I noticed a couple of recipes that exactly solved issues I’d been pondering in my head for a while.

If I had to pick fault, it would be that the book could have used more diagrams. This is a minor complaint, though, because the whole point is to run it and see it in action – then use it yourself in your own games. I would also have liked to see more discussion about audio. Still, as a handy reference to remind you of how specific XNA concepts work, or as a source of inspiration for truly imaginative solutions to realistic problems, this book succeeds on almost every level.

Effective C# (Scott Wagner)

There’s a well-known saying in coding circles: “C is powerful but lets you shoot yourself in the foot. C++ lets you re-use the bullet”. Fortunately Effective C++ by Scott Meyers has come to be considered a compulsory text for any C++ programmer, because it shows you how to use the language properly.

I am very glad to say that the author has achieved with this book what Meyers did for C++. It is, simply, the definitive guide to developing C# code that doesn’t just run, but runs correctly, effectively and efficiently. I found it particularly appropriate for someone like me, coming to C# from a C++ background. I look back at the early code I wrote when I started playing with XNA and I wince – I’ve learned since then, and it was this book that taught me. To spell it out: if you’re writing in C# and haven’t read this yet, your programs are probably fundamentally flawed.

The only drawback is that it only covers .NET 1.1, and the framework changed a lot in 2.0 and later. I am reliably told there is a second edition due later this year that will cover newer versions. I will be buying the second edition as well. (This, and Game Coding Complete mentioned above, are the only books I’ve ever been able to say that about).

Develop and Game Developer

I know, technically these are magazines not books, but to make up for it I’ve listed two.

Together these publications cover just about everything that is new in the games business. Particularly of note are the Post-mortems in Game Developer, which provide a uniquely in-depth insight into the challenges that particular games encountered during their development. Both magazines also provide extensive job listings and offer regular columns on each of the major games development disciplines: coding, design, art, sound, and business.

If you’re a professional in the games industry (or possibly a student? not sure) you can subscribe for free if you live in the country of publication, but both are worth the subscription price even if you can’t take advantage of that offer.

I hope this helps – I know when I get started with something I’m always keen to buy a few books so I can gain the benefit of experience without quite as much trial-and-error as having to make mistakes on my own. With XNA in particular, there are a few books that really aren’t that useful; I don’t think it would be fair to call them out, but with any luck these recommendations of which ones to buy should help keep you from wasting money on turkeys.

(Disclaimer: I have no connection in any form to any of the authors or publishers of these books or magazines).

“A clever fighter is one who not only wins, but excels in winning with ease.” – Sun Tzu

July 26, 2008


Filed under: Games Development,Personal,XNA — bittermanandy @ 5:54 pm

Welcome to my games development blog!

As is this the first entry, I felt it would be appropriate to give some kind of overview of who I am, why you should care, and what I intend this blog to achieve. This way hopefully in later entries I will be able to simply say “go check out the first post, it will explain everything”.

So – who am I? Well, my name is Andy Patrick, and I’m a software engineer with many years experience, in my late twenties. I generally go by the moniker “Bitterman” on web fora, and I’m active on a number of such, the most relevant of which for the purposes of this discussion are the XNA Community Forums and The Chaos Engine. My Xbox Live Gamertag is also Bitterman. I’ve got a Masters degree in Computer Science from Loughborough University, and after I graduated I joined Rare, a games studio owned by Microsoft, where I remained for five years, releasing two games in that time and working on core technology used in a number of others. Eventually I realised the time had come to move on from Rare and left the games industry shortly after.

What does this mean to you? Well, directly, not a lot. However, while I’m no longer in games, I do enjoy making them in my spare time, and I’d like to talk a little bit on this blog about exactly what is involved with that. While the great majority of my time in the industry was spent at Rare, I’ve done an awful lot of (informal) research into how other companies and individuals go about it, and added to that I have a number of ideas of my own. I’d like to use this blog as an opportunity to share those ideas in the spirity of friendly co-operation; as well as discussing the concepts and theory behind it, I will be developing my own code, in my own time, along those good-practice principles, and I aim to make some of it freely available for your pleasure and gratification. Essentially, if making games – as a hobby or a career – is something you’re interested in, I hope you will find something of benefit to you here.

The coding I do in my spare time is written in C# using the XNA game framework as a basis. In case you didn’t know already, you should understand right from the start that this is not how most professional games companies currently operate. C++ has always been, and remains, the language of choice for the overwhelming majority of games studios – if you are considering a career in games programming , you will almost certainly need to know C++. However. This is something that I believe will change – not quickly; there are still very good business reasons to use C++, not the least of which is that existing staff already know it, and there are no C# compilers for Wii or PS3 – and, more to the point, writing games in C++ in your spare time is a royal pain. With over a decade of C++ experience and having delved into the language deeper than most, I consider myself highly competent in writing correct, efficient C++ code. Yet, having been using C# for not much more than six months, I find that I am able to get as much done in an evening’s C#/XNA coding as a week of writing C++. Given that this is my hobby, getting stuff done quickly is vital. I will likely be expanding on the C++ vs. C# vs. etc. question in a later entry.

You’ll noticed I mentioned XNA above. The XNA Game Framework is a freely available Microsoft-provided technology, built on C# and the .NET Framework, that allows developers (including hobbyists) to make games for Windows and Xbox 360. The core of XNA is a set of code libraries that provide a great deal of the functionality found in every game engine in the world – vector manipulation, maths functions, rendering code and shaders, and much more besides. Still, it’s important to understand that XNA is not a game engine; neither is it Games Development for Dummies nor, despite what Microsoft would have you believe, the YouTube of games development. What XNA is, is an amazing set of free tools that let you get on with the fun stuff, instead of reinventing the wheel. I will definitely be discussing XNA at length in later posts, along with language- and platform-agnostic recommendations on how to get the most value out of your game development.

(Incidentally: officially XNA isn’t an acronym, or, XNA’s Not Acronymed. Far be it from me to argue with the XNA team themselves, but when I first heard of it I was told it stood for cross-platform Next-generation Architecture, which to me seems as good a description as any).

And what, you may be wondering, will I actually be making? Well, having had a while now to get to grips with XNA and the possibilities it presents – and after a none-too-brief but inevitably doomed attempt at beginning a project which, I now realise, would have been far too epic in scope for me to ever actually stand a chance of finishing it without hiring a twenty-person dev team – I have begun work on Pandemonium (working title, and hence the title of this blog), a traditional third-person platformer which I intend to release on Windows and Xbox 360. I have tentatively pencilled in late 2008 or early 2009 for the release date, but I will not be drawn into making any promises on that front. You may rest assured that I will be discussing Pandemonium at great length in future posts.

Finally, a quick tip: check out the resources and blogs linked in the right column of this page. I don’t believe in linking for linking’s sake, so each site listed has something valuable to offer. If games development is your thing – and I hope it is, or you won’t get much out of this blog – you really ought to check all those other places out too.

“Any fool can use a computer. Many do.” – Ted Nelson

Blog at