Skip navigation

The first challenge that you will need to overcome when you begin programming a game is as the title suggests: how to think about the software you’re writing.

If you’ve done any kind of programming before it was probably some kind of LOB application, like a website or some winforms or maybe some scripts.  That kind of programming follows a specific kind of model that unfortunately is only partially applicable to game programming.  First, let’s talk about what you know.

In your typical web or winforms application, your software starts by running some kind of initialization code.  It sets up the UI, loads configuration, puts some things into memory.  If it’s a web application, your UI is scripted with HTML and rendered by the browser software.  If it’s a winforms application, your UI is still “scripted” with controls you’ve setup at design time and your operating system (or the runtime, or a combination thereof) renders them.  From that point forward, your application will generally only do things in response to interactions initiated by the user.  Your application responds to events.  You, the smart application developer, takes good care not to stall the UI with CPU-intensive things in the main UI thread – when you need to harness the CPU, you fire off another thread in the background.

The point is that application performance is practially an afterthought in most modern programming because frankly most tasks that a user wants software to automate just aren’t that hard to do for modern hardware.  As a result, most programmers – including me, I admit – have gotten lazy about it.  Thanks to my formal CS education I am aware of concepts like algorithmic complexity and I try to use linear (or logarithmic) algorithms over polynomial ones, but honestly, if I can write an n-squared in 10 minutes for an n in an hour, I’ll use the n-squared a lot of the time.

When you are writing a game, performance is the first consideration you need to make, all the time.

This is a big paradigm shift for most programmers because they’re used to getting so much for free – namely, the actual application display.  Web developers are by far the laziest in this respect because they don’t even need to worry about things like out-of-thread processing on event handlers because all of their processing is happening on the server  and is totally divorced from client display (scripts don’t count).

In the bad old days of C++ Windows applications, we programmers needed to write something called “the main loop” or sometimes called “the message pump.”  The message pump was basically an infinite loop that continually probed the operating system for kernel-level events related to the window created by the application – mostly things like “the user clicked the X widget”.  The details aren’t important but the fact that your program at its core was an infinite loop waws an important one, because nothing’s changed.  WinForms applications work this way too; .NET just hides it for you and does all the message pump handling automatically, at the CLR level.  And it’s really efficient.  The CPU overhead for all of the stuff .NET does for you, like actually draw your controls on the screen every time the screen refreshes, is tiny.

When you are doing game programming, you don’t get this for free.  Here’s what XNA gives you:

  • An Update method that executes essentially as fast as possible
  • A Draw method that executes as fast as your monitor’s vertical sync rate refreshes the screen
  • A handful of initialization methods that are executed at startup

I was a little bit surprised when I created a project from the XNA template and got a new subclass of Game and saw these methods, surprised because while they give the most possible freedom, they are also a bit overwhelming.  Without proper care, Update and Draw give you enough rope to hang yourself

Unlike typical app development where your application only really needs to do things in response to what the user tells you to do, when you’re programming a game, you have to be aware that your game is doing something all the time.  XNA is constantly calling these methods for you in the game’s main loop.

That’s important.  Web and forms UI developers don’t think about their presentation in terms of frames.  When you want to show something on the screen you create a dynamic control and add it to your layout; when you want to hide something, you remove it from your layout; your framework (browser/forms) takes care of it from there.

Game programmers have to remember that nothing appears on the screen unless you draw it every single frame.  This means that your Draw() method assumes the screen is empty because it is – you will be clearing the screen at the start of every frame.  This also means that every line of code that you write in Draw(), or in a method that is called in Draw(), will be executed (optimally) 60 or more times per second.  That’s a lot of times per second.  If your drawing code cannot finish in 1/60th of a second, your framerate starts to drop.

When you’re just starting out, your framerate, even on bad hardware, should never drop below your vsync rate, which is probably going to be 60 – so 60fps.  As your begin working with XNA, the first thing you should do is add a framerate counter to your application.  Use this one:

http://blogs.msdn.com/b/shawnhar/archive/2007/06/08/displaying-the-framerate.aspx

The reason that I recommend this is because the only way you’re going to wind up with something playable in the end is if you remain vigilant on drawing performance.  Any time you add anything to your game, whether it’s a new drawing technique or a new game logic function, if doing so causes your framerate to drop below 60, you’re doing it wrong.  I say this because it’s 2010.  You’re not doing real-time ray tracing.  You’re not doing Doom 3 ultra quality.  You’re not a Final Fantasy intro video.  You’re doing a hobby game for fun.  If you can’t render it in 60 frames per second, it means you’re making a systemic error in something you’re doing in code.  It doesn’t mean that the GPU can’t handle it.  (Unless, of course, you choose to load your screen with thousands and thousands of polgyons.  If you want to tank hardware, you can tank hardware).

Next tim XNA rookie mistakes

Advertisements

One Comment

  1. most people can’t program games because of the intense difficulty in modeling the code itself


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: