Pandemonium

July 30, 2008

Efficient Development – part four

Filed under: Games Development — bittermanandy @ 1:11 am

So the time has come, this is the moment you may have been waiting for… the Efficient Development mini-series is over and it’s time to release Kensei.Dev to the world! And talk about feeling the pressure – thanks mostly to a link from Shawn’s blog my hit count went through the roof today. I hope not to disappoint!

Before I provide the download link, there are some disclaimers…

  • You can do whatever you want with this code. Change it, modify it, improve it, fix it, redistribute it, use it, anything. Except, that is, try to blame me if it goes wrong / doesn’t work / formats your hard drive / steals your car. You use it at your own risk, but may use it for whatever purpose you deem appropriate. I’m probably supposed to provide some kind of license with this code, but we’re all adults here, right? Of course, if you do use this code, it’d be nice to get a mention in the credits when your game sells a trillion copies, but, y’know, I’m not going to hunt you down if my name isn’t there.
  • I don’t claim the code is necessarily perfect. There may be bugs. It might take you a few minutes to integrate it with your code. Most of it got written when I was still more of a C++ programmer than a C# programmer, so it may not be perfectly optimal in a managed environment. Well… it’s free! Go figure. The point is I’m confident it will save you time in the long run, and if you spot or fix any issues, please let me know.
  • Known issue: you’ll need to put the spritefont and shader files in the right folder in your Content project. There are better ways of doing this but I’ve not had time to set this code up to use them.
  • Known issue: I realised while editing for posting that I was using two functions from a book I’d bought. It’s straightforward stuff, but I don’t have the rights to publish that code, so I had to replace it with a home-rolled version. You may therefore notice some imperfect behaviour with keyboard input in Dev.Command. It shouldn’t be too hard to fix up yourself.
  • There are a number of TODOs in comments in the code. These represent features I’d like to do one day, but have decided that for now I’d rather get on with making actual games instead. You may wish to use those as starting points for your own improvements to it.

With that lot out of the way… here you go.

There’s still a couple more things I want to mention. The first of these is the next obvious addition to the library. Dev.Options does a great job of providing a simple and easy to use way to switch flags on and off. What if you want to edit a bunch of ints, floats, or enums? Sure, you could use a Dev.Command for each one, but it’s time consuming (not what we want!) and not very elegant. Well… why not put the values you want to edit into an object you then show in a Property Grid? As Scypior pointed out in the comments of Part One, you can even drop your GraphicsDevice into a property grid and the rest is done for you, which is pretty amazing stuff and reminds me why I love C# so much.

An alternative to a property grid – which would be a lot more work, but would produce more elegant results; probably not worth doing if you’re in a team of one, but if you want designers and artists to use your tools it would be well worth the effort – would be to use reflection to create customised Windows Forms controls. In a previous life, working with C++ for Xbox 360, our build tools would scan the code looking for structures containing lines like this:

    //! type=float control=slider min=0.0 max=360.0 default=45.0

    float angle;

When an object of a type containing that member was edited in the level editing tools, it would parse that comment and create a slider control with the specified ranges, attached to the variable. This system was used for an entire data-driven system. That’s how I know this idea is plausible – there’s games out there that were created using exactly these techniques! Now, as we all know, C# is better than smelly old C++ and could do this without needing a seperate tool to scan the code, and with greater type safety, by making use of reflection and custom attributes:

    [SliderControl( Min = 0.0f, Max = 360.0f )]

    float angle = 45.0f;

Your reflection code would simply check the attributes for each member of a type and create the corresponding controls in a Windows form. Just to be clear – there’s probably not much you can do with this that would be impossible using a property grid. But, property grids aren’t that pretty, and designers and artists (and end users!) prefer pretty things to ugly things so for some of you, it may be appropriate to go the extra mile. There’s probably a lot more that could be written about this, so I may come back to it one day.

The other tip I wanted to share is related to the nitty-gritty of debugging. It’s a fact of life that, as programmers, we probably spend more of our time debugging stuff than coding. So have you ever been frustrated while in the debugger to see something like this:

The debugger obviously knows quite a bit about the object, but isn’t telling us anything more than its type! Not until we expand the [+] symbol or open up a Watch window, anyway. Try using the DebuggerDisplayAttribute instead: 

    [DebuggerDisplay("Name = {m_name}")]

    public class CueInfo

    {

        string m_name;

        // … remainder of class implementation

Now you will find that the debugger will tell us something rather more useful while we’re debugging:

It’s a little thing, but I like it. If this kind of thing appeals to you too, you may also want to check out DebuggerHiddenAttribute, DebuggerBrowsableAttribute, and a whole bunch of others. I tend to add them to most of my types by default as it only takes a few seconds. There’s only one real drawback: for reasons best known to the Compact Framework devs, they’re not implemented on Xbox 360. That means you’ll either need to wrap #if !XBOX360 … #endif around every use of these attributes (ugly) or, just once, define dummy attributes like this:

#if XBOX360

namespace System.Diagnostics

{

    [AttributeUsage( System.AttributeTargets.Class | System.AttributeTargets.Struct

        | System.AttributeTargets.Delegate | System.AttributeTargets.Enum

        | System.AttributeTargets.Field | System.AttributeTargets.Interface

        | System.AttributeTargets.Property | System.AttributeTargets.Assembly,

        AllowMultiple = true)]

    public sealed class DebuggerDisplayAttribute : Attribute

    {

        public DebuggerDisplayAttribute( string value )

        {

            // Do nothing!

        }

 

        // NOTE the “official” implementation of DebuggerDisplayAttribute

        // has more in it than this, which you may need to add dummy code

        // for if you use any of it in Windows.

    }

}

#endif

And that about wraps it up. I hope you’ve got something out of this little mini-series, and thanks to all those of you who have left comments. Please do let me know how you get on if you decide to use this stuff, or if you have any questions or observations about it. I’ve not yet decided exactly what I’ll be writing about next, or when that is likely to be, but I’ll try to keep things interesting!

July 28, 2008

Efficient Development – part three

Filed under: Games Development — bittermanandy @ 11:54 pm

Neither of the articles in this mini-series so far have been particularly revolutionary, though I do think I’ve implemented them in an elegant, almost effortless way. Most pro developers out there will have used tools much like them on most of their games; but I think they represent the kind of “obvious” tip that hobbyist developers never get told about, so hopefully they will have been of interest to at least a few people out there. The next tip, though, is something so blindingly obvious that every non-trivial development effort will have something like it. Or so I thought, until I (briefly) worked at a studio where there wasn’t much like it at all, and what little there was took fifteen lines of code where one ought to have been enough. In particular, it reduced 3D development to guesswork, and it showed in the quality of the game. So if you haven’t got stuff like this in your toolkit already – do it now! (Or, wait for a couple of days until I publish my Kensei.Dev code, then you can use that).

Pictures are worth a thousand words so here you go (you’ll want to follow the link to see it in detail):

Dev shapes and text

Dev shapes and text

This is a screenshot from the map editor mode of Shihan, a game which will, sadly, never see the light of day; XNA may be brilliant, but it eventually became clear that one person still can’t do the work of forty, and it would need forty people to make Shihan what I wanted it to be. That’s OK – lesson learned before too much time had been lost, and Pandemonium is a much more realistic target.

There’s quite a lot going on in the screenshot. In addition to the ground textures (from here), the skybox (from here) and the tree (procedurally generated by the wonderful XNA library here) you can see a whole bunch of other stuff:

  • In the top left is text that is printed as though it were on a page. This is useful for messages to the developer and stuff that remains in view over several frames. In this example, it prints the current camera position and the frame rate (essential information at all times). This uses Kensei.Dev.Text.Print.
  • In various locations across the screen is text, printed at a position in 3D space. This is invaluable for showing precise vector co-ordinates, as seen in this screenshot, and other data that needs to be readable but positioned in space. It uses an overload of Kensei.Dev.Text.Print.
  • In the centre of the screen, in red, green and blue are lines indicating the 3D axes, using Kensei.Shape.Dev.Axis. Note XNA’s leftright-handed coordinate system!
  • The green lines form the edges of a box around the currently editable ground tile. You can also see the red and yellow lines, which indicate the shapes formed by the control points and polygon edges of the ground respectively. Boxes and lines are invaluable for showing regions of the game world without blocking the view and are drawn with Kensei.Dev.Shape.Box, Kensei.Dev.Shape.Line and a number of others.
  • The solid white 3D arrow in the centre of the view indicates the light direction. Solid shapes, including boxes, cylinders, spheres, frustums, etc. are also useful for showing regions and can even stand in as “programmer art” for game objects, as you’ll see in the next screenshot. Above, you can see Kensei.Dev.Shape.Arrow; below, the player is represented by a Kensei.Dev.Shapes.Capsule.
  • Below also shows a couple of hollow spheres (Kensei.Dev.Shape.Sphere) indicating the minimum and maximum ranges of a currently playing test sound. Note how text positioned at the same location as the sound gives us valuable information about it.
  • Also available are frustums, cylinders, cones, crosses, and triangles, each in wireframe or solid, and in whatever colour is required.
A Dev Capsule standing in for the player character

A Dev Capsule standing in for the player character

 It’s practically unheard of for me to be running the game during development and not have some of this stuff turned on (controlled using Kensei.Dev.Options, obviously). It’s fundamental to the game programming art (especially in 3D but it’s useful in 2D too), and trying to work on that game without it was a nightmare, it’s as simple as that.

By now you will not be remotely surprised to learn that the code for all this is pretty simple to implement. Here, for example, is the entirety of the rendering code for our stand-in player character:

    Vector3 bottom = m_position;

    bottom.Y += HumanRadius;

    Vector3 top = m_position;

    top.Y += HumanHeight – HumanRadius;

    Kensei.Dev.Shape.Capsule( bottom, top, HumanRadius, playerColour, true );

Or as another example, the sound source includes code to help show where sounds are coming from as follows:

    if ( Kensei.Dev.Options.GetOption( “Audio.ShowSoundPositions” ) )

    {

        foreach ( CueInstance cue in m_attachedCues )

        {

            Kensei.Dev.DevText.Print( m_xactEmitter.Position, cue.ToString(), Color.LightBlue );

        }

    }

 

    if ( Kensei.Dev.Options.GetOption( “Audio.ShowSoundDistances” ) )

    {

        foreach ( CueInstance cue in m_attachedCues )

        {

            Kensei.Dev.Shape.Sphere( m_xactEmitter.Position, cue.MaxDistance, Color.LightGreen, false );

            Kensei.Dev.Shape.Sphere( m_xactEmitter.Position, cue.MinDistance, Color.Lime, false );

        }

    }

It really doesn’t get much easier than that.

Behind the scenes it’s pretty straightforward too: the Kensei.Dev.Shape (and Kensei.Dev.Text) static classes track what they are asked to draw during the frame, then render it all in one batch during the Draw method. Working out how to draw some of the more complex shapes was a bit of a pain, but not horrendously so and anyway if you use Kensei.Dev when I release it, that will all be done for you.

I hope you understand what I mean by Efficient Development by now. It’s not just having options in your game; it’s the ability to add options with one line of code, and control them during debugging with one mouse click. It’s not just having a command line interface; it’s the ability to add a new command to it with less than five minutes work and have it available forever after. It’s not just being able to draw shapes – it’s the ability to do so in one line of code and turn them off and on at will, so you can visually understand why your 3D code is misbehaving or put off creating complicated 3D models until later. Efficient Development is putting in a small amount of work up front to enable big gains later. It’s also knowing when to stop – almost all of the stuff I’ve written could be polished further (and you are encouraged to do exactly that if you decide to use it), but being a one-man team it’s enough for me at the moment. Efficient Development is about finding the balance between creating time-saving tools, and spending so much time making time-saving tools that you never quite get around to finishing the game.

Speaking of which: in the next and final part of this mini-series I’ll make the Kensei.Dev code available for download, and cover a few final miscellaneous tips; then we’ll move onto something more exciting.

“Step by step walk the thousand mile road.” – Miyamato Musashi

Efficient Development – part two

Filed under: Games Development — bittermanandy @ 7:26 pm

In part one of the Efficient Development mini-series, I talked about the importance of providing a simple set of boolean switches that can be set up and used with an absolute minimum of effort, to gain the absolute best possible use of your development time. I also showed how my Kensei.Dev library reduces the effort involved in setting such options up, to basically one line of code.

I mentioned in the closing comments of that article that Kensei.Dev.Options has some limitations. For a start, it only allows you to turn options on and off (or, set up a delegate that is called whenever the on/off state is changed). It’s not hard to imagine that you might encounter a situation where you need much more power and flexibility than that.

Let’s look at a slightly more concrete example. Let us suppose that we are getting into the closing stages of development on our game, and are starting to encounter frame rate issues. We’ve read through what Shawn Hargreaves has to say about profiling XNA games, and working on a combination of his advice and what we’ve already learned about Efficient Development, we’ve set up a couple of Kensei.Dev.Options we can use to help us determine whether we are CPU or GPU bound:

    protected override void Update( GameTime gameTime )

    {

#if PROFILE

        if ( Kensei.Dev.Options.GetOption( “Profile.Sleep1msOnUpdate” ) )

        {

            // If enabling this option does NOT reduce frame rate,

            // we must be GPU bound

            System.Threading.Thread.Sleep( 1 );

        }

 

        if ( Kensei.Dev.Options.GetOption( “Profile.SkipUpdate” ) )

        {

            // If we are not GPU bound, if enabling this option improves frame rate,

            // we must be CPU bound (else balanced).

            Kensei.Dev.Manager.Update();

            base.Update( gameTime );

            return;

        }

#endif

        // … rest of Update method

After determining that we are GPU bound, we continue to read through Shawn’s brilliant performance articles and notice the following advice:

Try running your game in a tiny resolution, say 100×50. … If reducing the resolution speeds things up, you must be limited by one of the pixel processing stages.

Good tip. It’d be great if we could do this whenever we wanted instead of hard coding it, so obviously we need to add another Kensei.Dev.Option that will set the resolution to 100×50.

Wait right there! Doesn’t it strike you that 100×50 is a bit, well, fixed? Undoubtedly running in a very low resolution will be handy for profiling. Still – wouldn’t running in a very high resolution be handy for showing the game off to our friends? How about changing aspect ratios to check how our user interface behaves? In fact, shouldn’t we be able to run the game in absolutely any resolution we want?

This is clearly a situation where Kensei.Dev.Options is insufficient. Luckily, at this point Kensei.Dev.Command steps up to the mark.

The idea is a very simple one, and not new (though I think the way I’ve implemented it is pretty clever). It’s something you can and should add to any of your games, even if you choose not to use my implementation. Basically it involves adding support for a command line interface to the game – and making it trivially easy to add new commands, and for the player/developer to issue such commands. You’ve undoubtedly have seen this before – most likely in the Quake series and Half-Life 2, which ship with these command interfaces even in their distributable builds.

In Kensei.Dev.Command, registering a new command is very easy:

    Kensei.Dev.Command.AddCommand( “SetResolution”, SetResolutionDelegate,

        “Sets the display resolution.” );

This simply registers the command string with the delegate in a Dictionary. When the command is issued, the delegate is called with an array of strings representing the full command line. This is exactly analogous to the way command line arguments are passed to an executable, so you can use the same well-known techniques to parse these arguments. Providing the parameters in this way separates Kensei.Dev.Command completely from the way any particular command behaves.

    private void SetResolutionDelegate( string[] parameters )

    {

        switch ( parameters.Length )

        {

            case 1:

            default:

                Kensei.Dev.Command.Print( “Sets display resolution.

                    Usage: SetResolution <width> <height>” );

                break;

 

            case 3:

                try

                {

                    int width = int.Parse( parameters[1] );

                    int height = int.Parse( parameters[2] );

                    m_graphics.PreferredBackBufferWidth = width;

                    m_graphics.PreferredBackBufferHeight = height;

                    m_graphics.ApplyChanges();

                }

                catch ( System.Exception )

                {

                    Kensei.Dev.Command.Print( “Invalid resolution.” );

                }

                break;               

        }

    }

That’s it – that really is all there is to it. Not very much code for a very useful, flexible and powerful feature.  Not the way you’d want to present the choice of resolution to a player of the final version of your game, but it gives us the flexibility to change resolution at will completely arbitrarily. At runtime, we use a Windows Form (much like the one used by Kensei.Dev.Options) to allow the developer to enter their commands. The command line has full support for typical Doskey features (for example, using the up and down cursors to scroll through previously issued commands) and there are some common commands that every game is likely to need.

An example Dev Command

An example Dev Command

I think the separate form for input is the most elegant way of achieving this, but obviously that won’t work on Xbox 360, so I’ve also supported the more Quake-like technique of drawing the command line interface over the top of the game itself. You can plug any USB keyboard into your Xbox 360 (you can pick up a cheap one for maybe £5-£10), and instantly have access to the full range of dev commands, exactly the same as you have on Windows, shown here. (You can see listed the full range of commands currently available to my Modelviewer tool. Note in particular “setoption” and “getoption” - this is how it’s possible to use the Kensei.Dev.Options stuff on 360, where there are no Windows Forms).

Using the in-game Dev Command interface

Using the in-game Dev Command interface

I hope it’s obvious how useful Kensei.Dev.Command (or your own similar implementation, if you prefer) can be, and how little extra code it involves. I use it to take screenshots; to save, load, and change levels; and to interrogate the game database as to the current state of an object; among many other things. If your game uses a scripting language (and as we’re talking about Efficient Development, that is something I would strongly recommend for any complex game) it is trivial to use this command line interface to issue commands in that language, allowing you to make changes to the fundamental behaviour of your game on the fly, without recompiling, and dramatically speeding up your development iterations. You could even allow whole scripts to be created and run via the command line, removing the tedium of repeatedly entering the same commands.

So this was another straightforward tip but a very powerful and flexible one. Combined with the easily-switchable options discussed in the previous article, this will really help make your development sessions faster and more efficient. In the next part of this mini-series, we’ll look at some more techniques to help you do just that.

“Make everything as simple as possible; but no simpler.” – Albert Einstein

July 26, 2008

Efficient Development – part one

Filed under: Games Development — bittermanandy @ 11:13 pm

I thought I would begin the real meat-and-two-veg of this blog with a short series of (three or four) posts describing some of the most useful, bread-and-butter tools that any XNA game needs during development. In the last post of the series, I’ll make the code available for free, for you to use, improve, and generally do with as you will.

In fact: there is absolutely no reason that the ideas and techniques I’m about to demonstrate should be limited to XNA games alone. The code I’ve written could be used in a non-XNA C# game with almost no changes, and converted to any other language with just a little effort as well. XNA and C# can do these things particularly easily due to their access to the .NET framework, but several of these techniques were inspired by tools I’ve used on previous projects that didn’t use .NET and didn’t always run on Windows. As if that’s not enough, I’d go further – there’s no reason games projects should be the only ones to benefit from this stuff. Any non-trivial software development effort would be made easier using techniques and tools like these.

I’ve entitled this mini-series “Efficient Development” to give a flavour of what I’m trying to achieve with this; I’d have used “Agile Development” but that has a very specific, well-defined meaning (even if no-one seems to agree on what that meaning is). Nevertheless, this is all very much in the spirit of Agile Development in the abstract – ways to work on software with minimal time wasted in recompiling, restructuring, and generally wrestling with the code. Having used techniques very similar to some of these ideas before – and thought “wouldn’t it be great if” for others – I knew before I wrote a single line of XNA that getting this stuff together would be mega handy, because it would make my coding life easier and save me a bunch of headaches later. When you might only get ten hours a week (or fewer!) to work on your game, you want to spend as little of it as possible faffing around.

Below you can see a screenshot from a tool I’ve developed for viewing models, imaginatively called the Modelviewer. XNA supports a wide range of model formats and it’s easy enough to write converters for your own custom types. With the Modelviewer, I can download models from the internet, or build my own, and very easily examine them (either using the Modelviewer as a standalone tool or a mode in another game). As my code develops, I will add features to it such as animations, particles, sound editing etc.

The classic Stanford Bunny in my Modelviewer

The classic Stanford Bunny in my Modelviewer

It’s pretty handy to be able to check out models in this way. But that’s not the focus of this article (useful though it is). Instead – let’s imagine I’ve downloaded this model and I want to use it in my game. But, maybe, I want to get a better idea of exactly how many polygons are involved. (The XNA Model class can give me a number, but suppose I want to use my intuition). Or perhaps I can see a defect in the model and want to work out what’s going wrong. The obvious answer is to view the model as a wireframe.

Look at all those lovely polygons

Look at all those lovely polygons

XNA is pretty good at making it straightforward to do things like this. All you have to do is ask the Graphics Device to render in wireframe:

    GraphicsDevice.RenderState.FillMode = FillMode.WireFrame;

Easy! Except… I had to change code to do that, which meant I had to recompile. Suppose I’ve got a whole batch of models I want to view at once, and want to be able to switch between wireframe and normal rendering. Changing this code every time I want to do that is going to be laborious. I could comment it out, or wrap it in “#if false… #endif”, but that makes the code look ugly and is hard to maintain. If we look to the future, when I might want to do this at any arbitrary time while a game level is running to see what is being rendered on the other side of a wall, changing the code every time is clearly out of the question. I could assign a key shortcut to it – but I’ll soon run out of shortcuts, or forget them, and how would that work if I tried to run it on Xbox 360?

Clearly a better solution is needed.

Using Kensei.DevOptions to toggle features at runtime

Using Kensei.Dev.Options to toggle features at runtime

That better solution comes in the form of a set of toggleable options, which can be freely switched at runtime. The dialog box (a separate form, by the way, not a child – I’d usually keep it out of the way of the game window) that you can see in the screenshot shows how easy it is to change things on the fly. In this example, I’ve set the flag “Draw.Wireframe” to off, and replaced the previous black background with a more axiomatic “Draw.CornflowerBlue” option. It’s worth noting, by the way, that the dialog box is not the only way these options can be controlled (were you about to say, “well you can’t get Windows Forms on Xbox 360!”?) but I’ll talk more about that in a future post. The key thing is that the runtime behaviour of the game can be rapidly changed during development by means of a simple set of options – you’ll see just how simple in a moment.

Behind the scenes it’s all very straightforward. The static class Kensei.Dev.Options maintains a Dictionary of strings (the name of the option) and bools (the current state). It wraps this up behind a bunch of public functions that control and check the status of these options. That’s the core of this tip, really – a single centralised location where any arbitrary flag can be set to allow rapid changing of game state during development. It’s not intended for player-controlled options – but it will allow you to change things on the fly without recompiling your code.

The dialog box itself, by the way, is a standard .NET Windows Form, though I suppose if you’re not using C# you could use MFC if you’re still living in the Dark Ages. It adds all the Dev Options as checkboxes and maintains a live update of each option’s state with the game (so whether the option is changed in the dialog box, or in code, or by some other method, it will always remain in sync). You can see that the main form contains a tab control – there can be as many tabs as you like, with each containing as many checkboxes as you like. The form even automatically resizes itself as more options are added.

So what code is involved in this, you ask? Well, the whole Options.cs file is less than 500 lines in size, writing which was a one-off cost on my part that will save me (and you, if you decide to use it when I make it available for download) lots and lots of time in the future. The game simply needs to add one function call in its over-ridden Initialize() method (this Manager initialises all the stuff I’ll be talking about in this mini-series):

    Kensei.Dev.Manager.Initialise( Content, GraphicsDevice );

…and perhaps another to make the dialog box appear automatically at startup – or it can be summoned later (here I have limited it to Debug configurations):

#if DEBUG

    Kensei.Dev.Options.DoModelessDialog();

#endif

From this point on, it only takes a single line of code to add an option. Options default to off, but that can be controlled with an overloaded function call, or they can be added separately to explicitly state whether they should start on or off. You can even add a delegate that gets called when the option changes, which is useful in a number of scenarios. My wireframe option simply looks like this:

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

    {

        GraphicsDevice.RenderState.FillMode = FillMode.WireFrame;

    }

There are millions of things this can be useful for during development. Testing a difficult part of the game and need to get past it? Turn on Cheats.Invincible. Noticing your frame rate drop? Switch on Profile.ShowFPS and see how bad the damage is. Need to know what your bad guys are thinking to work out why they’re running away from the player instead of kicking his ass? AI.ShowInfluences should do the trick. Absolutely anything you can think of that you might need to change on the fly at runtime during development can be controlled using Dev Options, and it only takes one line of code to implement.

This kind of thing is what I mean by Efficient Development. It saves time, it saves effort, it keeps the code clean and maintainable. I hope you’ll have seen the benefits – firstly of having a centralised development option store, and secondly of making them easy to change via a standard Windows control. Of course you’ll already have noticed some limitations, too. It only controls booleans, for example, and from all you’ve seen so far it’s Windows only. In part two of this mini-series, I’ll show you another Kensei.Dev feature, that will go even further to making your development efficient and fast.

“Controlling complexity is the essence of computer programming.” – Brian Kernigan

PS. I can heartily recommend the Copy Source As Html add-in for Visual Studio, without which writing this blog would be much more painful.
PPS. Please, please do leave comments. Was this useful to you? Too long? Too short? Too obvious? Very clever? Questions, or suggestions?

Genesis

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

The Rubric Theme. Create a free website or blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.