# Question
Title: In XNA, how do I dynamically load parts of a large 2D world map?
I want to develop a huge world map; at least 8000×6000 pixels in size. I have broken it into a 10×10 grid of 800×600-pixel PNG images. To avoid loading everything into memory, the images should be loaded and unloaded depending on the player's position in the grid.

For example, here is the player at position `(3,3)`:

As he moves to the right to `(4,3)`, the three images at the far left are deallocated while the three images at the right are allocated:

There should probably be a threshold inside each cell of the grid triggering the loading and unloading. The loading should probably happen in a separate thread.

How do I design such a system?

# Answer
> 11 votes
There are a few problems to solve here. The first is how to load and unload tiles. The ContentManager by default will not let you unload specific pieces of content. A custom implementation of this, however, will:

```
public class ExclusiveContentManager : ContentManager
{
    public ExclusiveContentManager(IServiceProvider serviceProvider,
        string RootDirectory) : base(serviceProvider, RootDirectory)
    {
    }

    public T LoadContentExclusive<T>(string AssetName)
    {
        return ReadAsset<T>(AssetName, null);
    }

    public void Unload(IDisposable ContentItem)
    {
        ContentItem.Dispose();
    }
}

```

The second issue is how to decide which tiles to load and unload. The following would solve this problem:

```
public class Tile
{
    public int X;
    public int Y;
    public Texture2D Texture;
}

int playerTileX;
int playerTileY;
int width;
int height;

ExclusiveContentManager contentEx;
Tile[,] tiles;

void updateLoadedTiles()
{
    List<Tile> loaded = new List<Tile>();

    // Determine which tiles need to be loaded
    for (int x = playerTileX - 1; x <= playerTileX + 1; x++)
        for (int y = playerTileY - 1; y <= playerTileY; y++)
        {
            if (x < 0 || x > width - 1) continue;
            if (y < 0 || y > height - 1) continue;

            loaded.Add(tiles[x, y]);
        }

    // Load and unload as necessary
    for (int x = 0; x < width; x++)
        for (int y = 0; y < height; y++)
        {
            if (loaded.Contains(tiles[x, y]))
            {
                if (tiles[x, y].Texture == null)
                    loadTile(x, y);
            }
            else
            {
                if (tiles[x, y].Texture != null)
                    contentEx.Unload(tiles[x, y].Texture);
            }
        }
}

void loadTile(int x, int y)
{
    Texture2D tex = contentEx.LoadEx<Texture2D>("tile_" + x + "_" + y);
    tiles[x, y].Texture = tex;
}

```

The final issue is how to decide when to load and unload. This is probably the easiest part. This could simply be done in the Update() method once the player's screen position was determined:

```
int playerScreenX;
int playerScreenY;
int tileWidth;
int tileHeight;

protected override void Update(GameTime gameTime)
{
    // Code to update player position, etc...

    // Load/unload
    int newPlayerTileY = (int)((float)playerScreenX / (float)tileWidth);
    int newPlayerTileX = (int)((float)playerScreenY / (float)tileHeight);

    if (newPlayerTileX != playerTileX || newPlayerTileY != playerTileY)
        updateLoadedTiles();

    base.Update(gameTime);
}

```

Of course you would also need to draw the tiles, but given tileWidth, tileHeight, and the Tiles\[\] array, this should be trivial.

# Answer
> 0 votes
What you want to do is pretty common. For a nice tutorial on this and other common techniques, check out this tile engine series.

If you haven't done anything like this before, I recommend watching the series. However, if you wanted you could get the last tutorials code. If you do the later, check out the draw method.

In a nutshell, you need to find your min and max X/Y points around the player. Once you have that you just loop through each one and draw that tile.

```
public override void Draw(GameTime gameTime)
{
    Point min = currentMap.WorldPointToTileIndex(camera.Position);
    Point max = currentMap.WorldPointToTileIndex( camera.Position +
        new Vector2(
            ScreenManager.Viewport.Width + currentMap.TileWidth,
            ScreenManager.Viewport.Height + currentMap.TileHeight));

    min.X = (int)Math.Max(min.X, 0);
    min.Y = (int)Math.Max(min.Y, 0);
    max.X = (int)Math.Min(max.X, currentMap.Width);
    max.Y = (int)Math.Min(max.Y, currentMap.Height + 100);

    ScreenManager.SpriteBatch.Begin(SpriteBlendMode.AlphaBlend
                                    , SpriteSortMode.Immediate
                                    , SaveStateMode.None
                                    , camera.TransformMatrix);
    for (int x = min.X; x < max.X; x++)
    {
        for (int y = min.Y; y < max.Y; y++)
        {

            Tile tile = Tiles[x, y];
            if (tile == null)
                continue;

            Rectangle currentPos = new Rectangle(x * currentMap.TileWidth, y * currentMap.TileHeight, currentMap.TileWidth, currentMap.TileHeight);
            ScreenManager.SpriteBatch.Draw(tile.Texture, currentPos, tile.Source, Color.White);
        }
    }

    ScreenManager.SpriteBatch.End();
    base.Draw(gameTime);
}

public Point WorldPointToTileIndex(Vector2 worldPoint)
{
    worldPoint.X = MathHelper.Clamp(worldPoint.X, 0, Width * TileWidth);
    worldPoint.Y = MathHelper.Clamp(worldPoint.Y, 0, Height * TileHeight);

    Point p = new Point();

    // simple conversion to tile indices
    p.X = (int)Math.Floor(worldPoint.X / TileWidth);
    p.Y = (int)Math.Floor(worldPoint.Y / TileWidth);

    return p;
}

```

As you can see there is a lot going on. You need a camera that is going to create your matrix, you need to convert your current pixel location to a tile index, you find your min/max points ( I add a little to my MAX so it draws beyond the visible screen a little bit), and then you can draw it.

I really suggest watching the tutorial series. He covers your current problem, how to create a tile editor, keeping the player within bounds, sprite animation, AI interaction, etc...

On a side note TiledLib has this built in. You could study their code as well.

# Answer
> 0 votes
I've been working on something very similar for my current project. This is a quick run down of how I'm doing it, with some side notes on how to make things a bit easier on yourself.

For me, the first problem was breaking the world into smaller chunks that would be appropriate to load and unload on the fly. Since you're using a tile based map, that step becomes significantly easier. Rather than considering the positions of each 3D object in the level, you already have your level split nicely into tiles. This lets you simply break up the world into X by Y tile chunks, and load those.

You're going to want to do that automatically, rather than by hand. Since you're using XNA, you have an option of using the Content Pipeline with a custom exporter for your level content. Unless you know of some way to run the export process without recompiling, I'd honestly recommend against it. While C# isn't nearly as slow to compile as C++ tends to be, you still don't want to have to load Visual Studio and recompile your game every time you make a minor change to the map.

Another important thing here is to make sure you use a good naming convention for the files containing your level's chunks. You want to be able to know that you want to load or unload chunk C, and then generate the filename you need to load to do that at run time. Finally, think of any little things that might help you down the road. It's really nice to be able to change how large a chunk is, re-export, and then see the effects of that on performance immediately.

At run time, it's still pretty straightforward. You'll need some way to asynchronously load and unload chunks, but this is highly dependent on how your game or engine works. Your second image is exactly correct -- you need to determine what chunks should be loaded or unloaded, and make the appropriate requests to make that the case if it is not already. Depending on how many chunks you have loaded at one time, you could just do this whenever the player cross a boundary from one chunk to the next. After all, either way, you want to make sure that enough is loaded that even in the worst (reasonable) load time, the chunk is still loaded before the player can see it. You're probably going to want to play with this number a lot until you get a good balance between performance and memory consumption.

As far as actual architecture goes, you're going to want to abstract the process of actually loading and unloading the data from memory from the process of determining what should be loaded/unloaded. For your first iteration, I wouldn't even worry about performance of loading/unloading and just get the simplest thing that could possibly work, and ensure that you are generating the appropriate requests at the appropriate times. After that, you can look at optimizing how you load to minimize garbage.

I ran into a lot of additional complexity due to the engine I was using, but that's pretty implementation specific. If you've got any questions about what I did, please comment and I'll do what I can to help out.

---
Tags: xna, tiles, tilemap, loading, xbox360
---


# Question
Title: Any tips for creating cross-platform games?
Do you have any tips/recommendations when creating a cross-platform game in C/C++?

# Answer
**Hide anything platform-specific behind abstraction layers**

This means stuff like rendering, audio, user input, and file IO. One common trick to abstracting that without inducing a run-time performance penalty is platform-agnostic headers with platform-specific implementation files:

```
// FileSystem.h
class FileSystem {
public:
    FileHandle OpenFile(const char * path);
    // other stuff...
}

// FileSystemWindows.cpp
FileHandle FileSystem::OpenFile(const char * path) {
    // call windows API...
}

```

Then configure the builds for each platform to build against the proper .cpp file.

**Make your content pipelines read in platform-independent assets and output platform-specific content for each platform**

For example, author your textures as .tga or just .psd, then have a pipeline that can automatically convert those to the different platform-specific formats you need.

**Don't assume a specific memory layout or endianness in your data**

Platforms may vary in byte order, padding, alignment, and word size. Any code that cares about that must be thoroughly tested on all platforms.

**Test on all platforms, all the time**

You *will* get bitten by platform-specific bugs. Would you rather get bitten now, or right when you're trying to get the game out the door?
> 47 votes

# Answer
* Use an api like opengl/sdl which will give you minimum hassle when going from platform to platform.
* Make sure you know what platforms you want to support. Don't use opengl just because you think you might want to support multi platform in the future. Start as you mean to go on.
* Know what hardware limitations are on each of the platforms you want to support.
> 10 votes

# Answer
Try to avoid scattering `#if defined(_FOO_) ... #elif defined(_BAR_) ... #else ... #endif` all over the code.

Sometimes it looks like the it's the easier way, but it will give you troubles in the long run. You should try to limit them to their own file, so that every platform implementation is self contained.

Adding a platform should be mostly about adding new implementation files, and just modify the few needed existing ones.
> 7 votes

# Answer
There are plenty of libraries that are themselves cross-platform; you don't need to write directly in OpenGL to run anywhere. OGRE is a great example of a rendering engine that works on any platform you'd care to name.

In my experience, the biggest concern is your build system. If you develop on Windows with Visual Studio, your *code* might compile in Linux, but you'll have a tough time getting it to *build* easily. Look at build systems like CMake that can use the same build instructions to generate platform-specific project files (makefiles on linux, VS Projects on windows, XCode Projects on Mac, etc).
> 4 votes

# Answer
When writing your functions for saving and loading files, or communicating over a network, don't forget about endianness.

Instead of reading a big structure with a single call to fread/fwrite or something low level like that, create a ReadByte/WriteByte and ReadFloat/WriteFloat. Then you will have fewer places to make changes if you decide to target a different platform later.
> 4 votes

---
Tags: c++, c, cross-platform
---


# Question
Title: How to handle game states for a single-player / multiplayer game?
I'm developing a little simon-like game and I'd like to know what the best approach is when it comes down to game states.

What would be the best approach?

* Creating different states/screens for 1-player and 2-player game sessions.
* Creating just one state/screen with validation from a variable that holds the selection made by the player on the title screen.

# Answer
You want your 1 player and 2 player game to be the same class with a 1/2 player toggle. Otherwise your code base is going to be unnecessarily forked.
> 4 votes

# Answer
Generally the game is only "multiplayer" when the game is in the actual gameplay mode--ie state 3. It is fairly common to just allow one player to "drive" in all other states. This is why you are often asked to "Press \[button\] to continue": to determine which controller/player is "driving". Then, when the main gameplay state is reached, the screen is split based on how many controller or players are actually connected.
> 5 votes

---
Tags: architecture, software-engineering
---


# Question
Title: What is "ROAM" related to terrain rendering?
I saw it mentioned on this question, but no one explained what it is.

# Answer
ROAM stands for "Real-time Optimally Adapting Meshes." It is a level of detail algorithm for rendering large terrains. It's somewhat complicated so I'll link to some more in depth explanations:

Here is the paper: https://graphics.llnl.gov/ROAM/roam.pdf

The following is a slightly less academic explanation: http://www.yaldex.com/game-programming/0131020099\_ch14lev1sec4.html
> 15 votes

---
Tags: graphics, terrain-rendering, level-of-detail
---


# Question
Title: What happens in pre production of a game?
I see a lot of games in "pre-production" and was just wondering what actually happens in this stage. Is it just planning or does a prototype get made or what?

# Answer
> 7 votes
It depends from project to project and from company to company. Typically "production" starts when the main work begins on what you could call the "construction" phase of the project, usually when the main coding work begins.

In the pre-production phase the groundwork for the project is being laid.

The core team of designers will be setting out the overall design goals, agreeing on an art style and discussing general technical requirements with the code team (say, deciding that destructible scenery is *needed* as supposed to wanted).

They will probably be creating design documents for the overall design, and possibly beginning some detailed design of the very early stages of the game, or more likely, the first parts to be implemented for the VSD.

Art may be producing some concept art for themes from the design and gathering some source material as reference.

Code may well be working on existing engine tech, or producing some prototype elements to test feasibility of some required components before the main work begins.

# Answer
> 3 votes
Pre-production is the stage where design documents are written, a production plan is created and often a review of the technology to be used. A proof of concept is also common.

Basically, getting the ideas down on paper, with the most general version of the concept sorted out.

# Answer
> 2 votes
It depends entirely on the game team what *exactly* pre-production is. Its intent is always the same: To prove out that this game can be made, within the given constraints, and has a chance at being a success.

In my opinion, preproduction means that you've established the entire pipeline from initial art & design work into the final engine, the core of your game engine, and you've proven that the core mechanics are fun. When prepro is done, you should be able to fairly painlessly ramp up the team size and create the game without any majore surprises.

---
Tags: planning
---


title: Cross platform low level graphic API

text:
# Question
Title: Cross platform low level graphic API
When creating a system abstraction is better to have the platform different APIs hidden by a common interface at the lowest level that makes sense.

Taking in account the different modern (with no fixed function pipeline) native graphics APIs: OpenGLES 2.0+, OpengGL 3.0+, DirectX 10.0+, Xbox DirectX 9, LibGCM

If one was to create a *stateless low* level graphic API to sit on top of them all, what would be the best way to go to make it as thin and as fast as possible?

# Answer
> 5 votes
The lowest level that makes sense from my point of view is something that talks about the resources involved in rendering - vb/ib, render surfaces, textures, shaders, state blocks, etc.

The problem here is that some of these need to be in different formats, depending on the API - that's where it gets a bit tricky. The easiest way around it is to pre-process static resources for the respective API. For dynamic ones, use *only* shaders to generate them - that makes it fairly straightforward to stay in native formats.

All you then do on the higher level is set up pipelines with attached resources and hand them to the GPU. You'll find that not everything can be abstracted out nicely in that way, especially if you take advantage of hardware-specific tricks. But it's a good start.

(Sidenote: if you treat platform-specific tricks as a special kind of resource, you can push this whole concept quite far. )

So in a way, you'll create two things: A hardware resource manager, plus a toolkit to set up a DAG of these resources.

# Answer
> 9 votes
Given the broad range of APIs you wish to cover, the typical wrapping approach is likely to be inefficient and prone to difficulty in mapping API concepts across several other APIs which may or may not support particular functions to varying degrees.

As a result, the most sensible approach would be to create a **feature-centric** API. While this approach prevents the API user from utilizing all available functionality, it greatly simplifies the implementation of each backend, and enables backend-specific optimizations that would not otherwise be possible.

It also greatly simplifies management of unsupported functionality for the API user; they no longer have to check if function X exists, and determine which features are affected, but instead need only query the feature itself to see if it is supported with the current configuration. Even if you support partial or limited modes for features, the context provided makes it much easier to manage.

In terms of creating a stateless (also known as submission-based) renderer, typically a 64bit key is used to pack and submit commands for rendering. From that point there is a great deal of flexibility in terms of how to execute commands and what information to submit depending on what features and capabilities you want to support.

# Answer
> 1 votes
To start with, each API does things differently so it should go without saying that wrapping all of the above APIs would be difficult. That said, it is sometimes necessary to do so: at some point a game simply needs to run on more than one platform regardless of how hard it is to do so.

I think the best way to go about doing this is to come up with the functionality that can be implemented on all of the underlying API's and abstract that and only that. If you are developing a multiplatform game, you wouldn't implement every obscure piece of functionality that each API supports, you would only implement what you need. This also helps to keep the API small and fast.

To avoid the clutter of each different API's implementation being packed into the output, compiling should be done with platform neutral header files and platform specific code files. Then, the code file specific to the target platform would be the only one compiled keeping the API small.

# Answer
> 0 votes
There is an article on GPU Pro about this, by Emil Persson (Humus)

http://gpupro.blogspot.com/2009/12/making-it-large-beautiful-fast-and.html

> A cross-platform interface for rendering. The advantages of having one, and how we crammed DX10 into a common interface with DX9 consoles and maintained good performance.

# Answer
> -3 votes
You might want to check out the SDL library or Allegro. Both of them are low level, highly-portable game libraries, which have a way to plug them in an OpenGL context so you can render your graphics there. SDL has the fame of being used by he defunct Loki Games to port some popular games from the 2000s to Linux, and Allegro has a lot of time running on and has a great community of amateur game developers.

---
Tags: architecture, software-engineering, graphics, cross-platform
---


# Question
Title: What is "procedural generation" and how is it done?
I hear a lot about "procedural maps" and "procedural textures". What does that mean exactly, and what resources are there for learning these techniques in a game?

# Answer
The textbook definition of "procedural" is something that's generated from some kind of algorithm instead of predefined, i.e. from a level editor or image editing program.

See also this question, specifically for procedural textures: What happened to procedurally generated textures?

For procedural maps, there are a lot of techniques you can use. In a basic example, you can do things like create some kind of grid that you pseudo-randomly lay down paths for. You can set up a bunch of prefabricated pieces that have certain areas tagged as doors, etc, and just randomly throw them together.

In a way, you're writing an AI to design your levels on the fly.

If you're planning on doing this at run time on the user's machine, you lose the ability to precompute things across the map. For example, you have to lose or find alternate solutions to things like visibility, navigation data, and lightmaps.

However there is a benefit to procedurally generate content during production and then use that as a seed to making data. For example, you can procedurally place trees on a terrain to create a forest, and then save that as your map, instead of placing all the trees by hand.

At the end of the day, though, how you do it is heavily dependent on what your game design needs are. I'm personally of the opinion that procedural maps are usually not worth it as a level designer can make more fun, better looking, maps in less time than it would be to set up a system to make anything close, but there's room for debate on that.
> 25 votes

---
Tags: procedural-generation, terminology
---


# Question
Title: Why aren't more games 64-bit executables?
Until now I've seen that many games are still compiled in 32-bit architecture although nearly 50% of current Windows users are on 64-bit OS? Why is this?

If the reason is for getting larger audience (since 32-bit app could run on 64) why don't they make two versions of it, since it is more or less about recompilation and running 64 bit apps could give performance benefit due to more available CPU registers and other features.

# Answer
> 15 votes
This MSDN blog about why there isn't a 64 bit Visual Studio version addresses many of the issues that also affect games. The gist of it is that going to 64 bit may actually hurt performance in many cases because of the effect on the processor's cache (more data with 64 bits, but the same size cache).

The additional addressable memory could help, but few consumer machines have more than 4 gigs of memory anyway. Add that to the pain of distributing two binaries for Windows, and it's easy to decide that the time isn't right for 64 bit games (yet).

# Answer
> 6 votes
At my previous job we ported our entire engine (MMO) to 64bit, and ended up running a 64bit client in a few places as part of the development pipeline in order to preprocess data. But, we would never ship a 64bit client to end users.

First, the performance improvement is very minor, and most PC games end up being GPU limited in any case.

Second, very few end users have enough ram to take advantage of a 64bit executable, and any engine that is even vaguely designed for consoles (which max at 512mb remember) is not going to be optimized for large available memory.

Finally, having 2 executables in your distribution pipeline is a giant pain in the ass. You can't only ship a 64bit executable, because then 30% of your audience can't run it. So you have to ship both a 64bit and a 32bit executable, as well as some sort of wrapper that runs the correct one. If you're an online game that means an extra multi-megabyte file to patch every time any code changes, and additional complexity in making sure the right version gets to the right player. It's just not worth the effort for the minor benefits.

# Answer
> 2 votes
If it was simply a matter of recompilation we would have 64bit version of all the games.

Unfortunately it's not that easy, specially with game engines with an older code-base.

Porting to 64bit would take lots of effort in this case. Simply put the advantages for now weren't enough for this to be worth.

---
Tags: architecture, platform, operating-system
---


# Question
Title: Same game logic on two separate graphic libraries
What code philosophy/structure of abstraction/program design would allow a game to be used with both 2D and 3D graphics (separately) WITHOUT having to re-code the Game logic?

We're talking taking the same code, changing a minimum of things (for example, exchange filenames for 2D assets with filenames for 3D assets), and maybe plugging in a few specialisations of a base class per generics/templates.

To put it in a real context where it makes sense: imagine a LAN-multiplayer game where there is one top-notch, performance-hungry 3D client for the players with some really good gamer rigs, and a more humble 2D client for the old dusty boxes that someone found in their attic. But it's still the same game - the same events are registered (someone picked up a coin), the same Network protocol is used, the worlds are proportional, etc.

To put it in a MVC context: The Controllers are the exact same (pressing the "Up" key will set the players acceleration at 3.5 units/second), the Views are totally different (2D versus 3D), and the Model is the same except for anything directly related to graphics (a collision check for the environment is performed every 5 seconds, and it uses the same algorithm. Note that this would mean there IS a Z-coordinate for all the Game Objects in the 2D version, but it's just ignored or displayed to the user in another way, for example by a shadow that is displayed further left when the player is in the air).

What makes this such a fascinating topic is that it would FORCE the developer to have a very clear idea of how his data is structured and how control flows. Note that this does not imply using anything other than a graphics library like SDL, D3DX or OpenGL. No game engines!

Since this is a mostly theoretical question, I'll leave programming languages out of it, but if you want to give an example you can use any language you like, C++ if you want to go the whole hog, or even Brainfuck if you feel up to the challenge (Any concrete answers will be appreciated, as well as any abstract ones!).

# Answer
> 8 votes
I think that all (?) you would need would be a layer of abstraction wrapping your graphics library; you would need a new one for each library you would be using, and each one would need to have the exact same external API.

Think of localization of strings: instead of hard-coding the string "Inventory" into your game, you would instead call your (possibly custom-built) localization library, which would do some processes and return a proper string, depending on the context of the game.

In the same way, all calls to your graphics engine would be made *through* your wrapper around it.

In doing this, you limit/restrict what commands you can give your graphics engine. Here are some essential ones:

1. Draw (graphic object) at (location)
2. Modify (alpha, rotation, etc.) property of (graphic object)
3. Move (graphic object) to (location)
4. Build map of (level name/data structure)

And some others, which you will find as you work on your project.

If you are using a Strict-Typed Object-Oriented Language, you would call the above commands the **interface** that your wrappers will all implement. Preferably, these will be the **only** un-protected/public methods.

Now, create a new wrapper for each of your graphics libraries, and **implement the API**. When a command to draw **\__ at \__** is given to you, you must use code to create the sprite or model, and draw it into your environment. This might require some trickery, such as storing each sprite in a hash to be re-accessible at another time by a given symbol.

As for building maps, the most efficient way would be to pre-build each map for each graphics engine before-hand and do a lookup. Alternatively you could store the map in your own custom data structure and then use your wrapper to build a map from that data structure.

Hope this helps gets you started =\]

# Answer
> 2 votes
Building your game's architecture with a paradigm close enough to MVC to allow complete abstraction of the display code would likely be quite difficult for any large project. However, it seems like the biggest impediment to creating a game that supports both a 2D and 3D client would be designing a game in which both clients are equally capable.

It would be necessary to begin your game's design with the full intention of creating and supporting the two clients, and it would probably be safest to restrict all game functionality to what makes sense for the 2D client.

As an example pitfall, if you were not designing to a restricted functionality set you might create levels in which important information or objects were only visible from specific angles. While that would be fine for 3D clients that have 360 degree viewing freedom unless your 2D client explicitly supported a viewing angle that had visibility on each of those important objects, you would be impairing users of the client.

It would be best to set out a specific number of viewing angles for the 2D client (8 or 16 or such) and develop all content to fit within those constraints. Unfortunately if you have levels and objects that are designed to be viewable only from a specific set of angles, it can look quite odd from within a 3D client.

In my opinion it would be a poor choice attempt a game design allowing for 2D and 3D clients that are intended to have equal capabilities. I think it would be a better use of resources to design asymmetrical gameplay options, and allow each client to play to its strengths. For example if the 2D client were primarily focused on a strategic-level perspective on the game world, with the 3D client being used for tactical-level gameplay.

# Answer
> 0 votes
I think you've pretty much answered your own question:

> To put it in an MVC context: The Controllers are the exact same (pressing the "Up" Key will set the players accelleration at 3.5 units/second), the Views are totally different (2D versus 3D), and the Model is the same except for anything directly related to graphics.

So, by providing an adequate abstraction between input, game logic, etc and graphics, you will have solved the problem.

This is basically the point of the MVC model, especially as it pertains to desktop and web applications: there can be multiple clients accessing and manipulating the same data (a web interface, mobile client, and desktop client for email, for example).

# Answer
> 0 votes
Keep it simple if you want it simple: \- Write the game logic to move the objects. Don't store any data on them that is related to rendering. \- Write renderers that are given a chance to look at the state of the game data and draw it.

You can use more or less complicated programming techniques for this. The only thing you need is a way to get to "extra" data you need to render for each game object. The simplest way is to have zero extra data required! If the game object is a "Wizard", draw a Wizard.

If you need more complicated methods, consider polymorphism, memento pattern, hash tables, void\* pointers, etc. Don't over engineer it (most of these methods are over engineered).

---
Tags: architecture
---


title: Collision and response between sprites?

text:
# Question
Title: Collision and response between sprites?
What is an easy way to have sprites collide and react to the collision? E.g. if I'm writing a game in XNA or with Canvas 2D and need to write the code myself very simply.

# Answer
The XNA collision series is very thorough for 2D collisions, covering collisions between bounding boxes, heightmaps, and per pixel collsion. The sample is for XNA but the concepts can be transferred elsewhere.

http://creators.xna.com/en-US/tutorial/collision2drectangle
> 7 votes

---
Tags: sprites, collision-detection
---


# Question
Title: Game Characters vs Characters in other medias
How do a characters designed for a game differ from characters made for books or movies? When a book or a movie is converted into a game, what are the differences and similarities that have to be addressed? Are there pitfalls in character design when jumping between these different medias?

# Answer
Characters in videogames are strongly defined by what they **do**, particularly player characters. Lara Croft jumps, grabs, swims, and shoots. Mario's original name is "Jumpman." Megaman bosses are defined by their attacks. In other media, other qualities may come to the fore, such as character history, personality, perspective on life, or inner conflict. For visual media (e.g. animation and film), appearance is paramount, and in audio storytelling formats (e.g. radio drama), just the voice can be a defining characteristic.

Games are about verbs, so when you adapt a character from other media into games, think about what kinds of actions are unique to that character and make him or her distinctive. Spider-Man slings webs. James Bond shoots, drives, quips, and seduces. Transformers... well, you know. One pitfall would be to faithfully reproduce a character's appearance, environment, voice, and even personality to a game, while giving him or her an action set that is irrelevant or even antithetical to his or her behavior from the source material. This may not necessarily result in a bad game per se, but it would probably be a poor adaptation.

This is a huge generalization, of course. Certain genres of film, e.g. Asian kung-fu cinema, are hugely based on verbs. Conversely, non-action qualities are still valuable for game character design. Still, "what does this character **do?**" is a very useful question to be asking in pre-production.
> 7 votes

# Answer
One of the major differences is that it is much more critical for a player to develop the attitude towards your character that you want them to. For example, if you are developing a character that will be accompanying the player for an entire level, or the entirety of the game, then it is important that the player like the character. If your character manages to get the player to dislike them, then the game will note be much fun.

This was discussed in the developer commentary for Half Life 2 Episode One. There is a character that accompanies the player for the entirety of the game, and it took several revisions before the player actually learned to like that character. In previous revisions the player would come to find the other character annoying, which made the game experience not very fun.

A second note is that characters in videogames (or movies) must be much more expressive. While in a book you often get a chance to go inside a character's head, this is not as much of an option in a game. Your characters must explicitly say what they are thinking or feeling or you risk the player not getting the information you want them to.
> 4 votes

# Answer
The chief difference between movies & books and games is interactivity. The player of a game has an active involvement in the world and is (usually) not just an observer of events. Other than this a game character is much like a movie character and should be created and thought about in much the same way. For instance, expressiveness like Sean James mentions. There's also creating realistic dialog, good acting (vocal, if present, as well as physical movements), etc.

With that being said, the main problem in such an interactive environment is keeping suspension of disbelief. It's extremely easy to be knocked out of the game world when a character repeats themselves countless times, walks into walls, generally acts stupid. Care should be given to ensuring that the character behaves properly when interacting with the game's world, environment, and characters.

Also, a lot of care should be taken into considering how the player will interact with this character and how the character should react when the player does whatever they do. If you foresee something the player might try to do to the character and the character reacts in a way consistent with their personality then you have a believable character and the player will be that much more sucked into the world you're creating. For instance, if a player whacks an NPC have them yell "Stop it!" and then "I'm warning you!" and then start fighting back.

Of course, if the game is presented in scripted events (like RPGs), it's even easier.
> 2 votes

---
Tags: game-design, character, books
---


# Question
Title: What are good games to "earn your wings" with?
I believe that in order to become a good game developer, you need to make games.

From a *programmer's perspective*, what are some good entry level games to get your hands dirty? What skills and challenges do each of these games teach you?

# Answer
> 240 votes
> The best game to "earn your wings" with? The one you completed.

## The list

This one is based on *some criteria* of increasing difficulty (i.e. it is based on opinion, like many things). Some suggest that anything after Pac-Man, it is really up to you because, by then, you know enough and may want to focus on something specific.

There is also a series of tips in the section *Some words of wisdom* that should be of interests.

### Guess the number" / Hangman / Mastermind

Basic interface, select data from a database.

### Choose-Your-Adventure

Based on choose your adventure books, it is basically a simple text adventure game with an output like this:

```
You are standing in a forest clearing in the middle of the night. You hear
some wolves howl in the distance. Should you:
a) make camp for the night
b) go further north
> _

```

Making such a game should teach you to make a gameloop, basic console input and basic scripting (you can push it and add data structures/make it data-driven instead of hard-coding everything in the program). It is quite simple to implement and easy for a beginner to jump into *since you don't need a graphics engine* to write the game. Advanced beginners would probably write a scripting engine.

### Tic-Tac-Toe / Rock-Paper-Scissors

Turn-based gameplay, simple opponent AI or second player.

### Breakout / Arkanoid / Pong

Easy game since you don't have much state to worry about (it's an array of brick values -- if you only have one brick color, it's an array of flags), there isn't any AI, and you get to do a little bit of physics to get the ball to bounce correctly. No real needs for sounds. Also: input handling, collisions, stable frame rate, score, levels.

### Solitaire / Minesweeper

The rules are a bit more complex than Breakout and the interface to it is a lot different. It forces you to think about different methods of implementing a game. i.e, what works in one game isn't necessarily what you would use in another. They're event based rather than "real time".

### Tetris

The art is colored rectangles, which even a total klutz can draw in Microsoft Paint. You don't need sound. The programming is relatively simple, but still requires a few key things: understanding the difference between the internal game state and what's drawn on the screen; being able to draw on the screen, period (probably involving sprites and blitting); being able to accept user input in realtime rather than just using getch() or scanf() where you have to wait for them. Since it is a very common game, lots of open source clones out there to rip apart if you get stuck. Also: Data structures and how they relate to gaming.

### Asteroids

Bullets, space physics, toroid world.

### 1942 / Space Invaders / Gradius / R-Type / Shoot-em-up

You can probably find some freeware tilesets to make this. Here the background is scrolling, you'll be using techniques for drawing stuff outside the boundaries of the visible screen. You also tend to have dynamic enemy and bullet spawns, so you'll need to learn to clean up after yourself (i.e. get rid of enemies and bullets that leave the screen).

### Simple platformer / pinball game / Super Mario Bros

The scrolling is under player control and not automatic. You also have to deal with gravity and all the fun collision stuff that goes along with it (like not falling through the floor just because you were a few pixels above in the last frame and want to move to a few pixels below in the next frame). Also note that gravity is conditional: it affects the player and some enemies, but typically not the platforms or floating coins or whatever, which is a bit different from the real world. For an extra challenge: add irregular sloped terrain and parallax.

### Bomberman / Pac-Man / Nibbles / Snake

This one is nice because you get to work on a little bit of AI. Having the ghosts follow the player (but not too well - you want the player to have a chance) can be quickly implemented, and you will have a fun little game that you can tweak and show off to friends and family (positive feedback is always a good thing when you are starting out). Also: tile-based movement, complex enemy AI.

### Moonlander

A rocketship affected by gravity, players control direction and thrust, limited fuel when using thrust. Tight tuning of physics, resource management, more advanced math.

### Gauntlet / Zelda

Large map scrolling, interaction with the environment, enemy AI, inventory, health.

### Two-player game

Of any of the types above (two player inputs).

### Roguelike / Diablo

Inventory management, multiple enemy AIs, saving and loading complex game states.

### Faceball / Wolfenstein 3D

Basic 3d movement and rendering.

### Worms

Terrain destruction.

### Network turn-based game

Basic networking.

### Gimmicky 3D third-person platformer

Physics, complex 3d movement.

### Network real-time game

Client-server synchronism, lag.

### MMORPG

Persistent world. (This could go further down the list as it is really difficult.)

## Some words of wisdom

### Get to the finish line

It is strongly recommended that novice programmers should start with the simplest game that **they actually want to write**. A **huge** part of writing a *game* vs. a *demo* is pushing the damn thing through to completion - credits, menus, play testing, high scores, pausing, play testing, difficulty levels, clean game state transitions, play testing, etc. That stuff takes at least half the time you're going to put in (some say it can even go up to 70% of the time) and it just isn't fun. It isn't. So unless you love the concept and are really motivated, you will give up and move on before the game is a *game*.

If you want to write an RPG, figure out the simplest, most manageable RPG concept you can come up with *that you want to do* and do it. Same if you want to do a sci-fi shooter, or a horror-themed platformer, or whatever. Pick something you will finish, that you will still want to finish after everything fun is done but you're still looking at dozens of hours of work before you're really done.

### Focus on something small, don't re-invent (some parts of) the wheel

If you look for inspiration in early video games, you can find tons of ideas that are relatively simple to implement. Plus, you can get away with super simple artwork and sounds because you're copying something so simple anyway. This allows you to focus on the basics first -- getting your game loop up and running, figuring out how to get your pixels to the screen, playing a sound, keeping score, getting the player's input into the game.

### Start with something that seems too-puny to deal with

Pong is a good example.

The goal is: make the game-design and rules-set so brain-dead that you can focus all of your attention on learning the new thing that you're learning (a language, a platform, an API) and not have to constantly take breaks to figure out how the game works.

Once you get going, you'll find that pong is actually slightly more complicated than it seems at first blush.

Once you've done app#1, take on something a little more complicated but, to get started learning a new technology, make the thing that you program brain-dead simple.

The difference between having written ONE app in a language/platform/SDK/engine and having written ZERO apps is **HUGE**. The difference between 1 & 2, or 2 & 5, much less so, so you can take bigger steps, but make the 0 to 1 step be a teeny-tiny one; it'll be bigger than you think!

### Focus on a single aspect of games

One important rule of learning game programming: learning programming is hard. Learning game design is hard. Learning how to make good game art or audio is hard. Trying to do all of these things at the same time is a recipe for failure. And so just like learning multiple programming languages teaches you multiple *paradigms*, tackling different games teaches you different *aspects* of game programming. Try to learn one thing at a time.

This is an example journey: once you've got those done, in order...

1. *Screen control.* Simply render a blue sprite/rectangle.
2. *Input validation.* Change the colour of the sprite/rectangle based on key-presses
3. *Text and sprite rendering.* Since you also have input validation, a tile memory game is not a bad idea.
4. *Timers.* Force the player to do things *faster*.
5. *Sound and music.*

... you're ready to target a platform, and the learning may begin.

The rest is in no particular order, and you may rearrange them as you see fit. For practical reasons, it's good to be proficient in screen rendering and input relatively quickly; you're gonna use them a whole lot. Wait a few games before trying to write abstraction classes; you ***don't*** want to be caught in a naive abstraction.

* *Animation.* Almost anything you do can call for animated sprites. Get an independent animation engine under your belt, even if it's programmer art. Making a simple puzzle game whose tiles throb is enough.
* *Complex scoring.* Get all five enemies in a wing? Bonus. Land three punches in a row? Bonus. Make it through the whole level without missing a bullet? Huge bonus.
* *Pathfinding.* Lots of games need this, but a tower defense game is about the simplest. You can get started with breadth-first and depth-first if you've never done it before, but you're not done until you've implemented A\* from scratch (NOT COPIED CODE) at least once.
* *Enemy behavior.* Dumb automated behaviors will be covered by your mario, but reactive behaviors are important too. This is a good excuse to build a tactics game or a roguelike. (Warning: you will work on the roguelike for the rest of your life.)
* *Dynamic 2d lighting.* This is also a good reason to write a roguelike. Arc-based shadow-casting is an important way to look at banding and separating, which is in turn important for a whole lot of data structures.
* *2d Physics.* This turns up in a whole lot of games, at a whole lot of levels of detail. Try a platformer (mario-ish,) which can be super-simplified; a tank game (scorched-earth-ish,) which can be equally simplified; and eventually, a game like N the Ninja, which makes you cope with running on angles, momentum, et cetera (you can do that with an axis-aligned bounding box collision system pretty straightforwardly.) Physics and collision are pretty intimately related.
* *Collision detection.* There are ridiculously simple cases, like grid Arkanoids and Mario clones, moderately complex cases like N the Ninja and genuinely complex cases like sandbox physics games (the incredible machine, modern arkanoids like BreakQuest, et cetera.) In many cases you can get by with something like AABB, but if you're math inclined, it might be useful to actually implement something complete. At a minimum, get familiar with a complete library, such as APE or Box2D.
* *Risk/reward relationships in game play satisfaction.* Simple dice games (go digging around for something called "Skunk" from the 50s) and risky-path (life, candyland) board games are great examples of simple quick ways to learn this by doing.
* *Expressive variation in mechanics.* Nail yourself down to some small count of rules, then learn to get a whole lot of variation out of them. Custom deck card games are a great way to work with this; take a look into Dvorak decks, and real world games like Mille Bornes, Rage and Uno, then make a few of your own. They don't get to be similar.
* *Generated content.* Simple map-based strategy games, roguelikes and some kinds of puzzle games are great ways to learn to do this. Bonus points if it's a kind of game not generally known for having generated content.
* *Style.* Don't screw around: this is a big deal. Make a game, then skin it to be four completely different games. *Really* different. One a kids' game, even. (Think about it: Mega Man makes perfect sense as a sorcerer adventure into hell, or as Rogue from the X-Men, or ...) Now, get four groups of people to score one each of your games. After that, have them score the next game, counter-clockwise, around the ring, and so on. Notice how radically their scoring changes based on theme and prior expectation.
* *Making the player plan sequences.* Puzzle games are sort of the cleanest ways to go about this.
* *Resource management*.
* *Upgrades*.

### After your first game

So it almost really doesn't matter which game you choose first -- just make sure you pick something simple that you can get quick results with, that way you can move on the next day and make another one. And another. And another -- the more you make, the more you'll push yourself, and eventually you'll be making complex games before you know it.

#### Spice it up

You can take a 2d game and make a 3d version of it.

You can also make another version of your first game. For instance, start with Monopoly. You can use Brett Schuchert's Monopoly "code kata" as the basis of the exercise, and add a lot onto it. The reasons why this is interesting:

1. It teaches good coding practices (design patterns, TDD, SOLID, continuous integration, etc.) and puts a lot of constraints on the developers when they do this exercise.
2. Pretty much everyone knows the rules of Monopoly, and, with the proper preparation (e.g. having the assets available), the entire game can be completed in a single day. This gives new developers a quick win and really gets their engagement up.
3. The initial requirements start off with keyboard controls, but then you can add a requirement for mouse controls later; or you can plug in a more sophisticated AI. This gets developers thinking about several things: how to refactor existing code, programming changing parts of the system to interfaces instead of concrete classes, better/proper abstractions, what to unit test, what not to unit test, WHY to unit test, what makes for GOOD unit tests, give the real-world experience of clients who change the requirements on you after you've already started.

You can get something quick, and see how flexible you can make software when you follow good programming standards. These exercises build confidence very quickly. Sometimes, the more experienced developers like to do these on their own, just to get a break from more complicated projects or to practice a new technique they've just learned (law of demeter?).

---
Tags: software-engineering
---


# Question
Title: What continuous integration technology is used for games?
Which continuous integration technology & software would you recommend for use with games?

Also are there any build technology libraries or specific languages you would recommend to use when a custom part of the game asset pipeline needs to be coded in-house?

Are there any good resources for demonstrating the business case for using continuous and automated build systems for games?

# Answer
> 7 votes
**Hudson** is by far the best continuous integration app ever.

It's free (open source I think), and it comes packaged in a single .war file, or you can opt for the standalone package with a small Tomcat (I think) application server -- either way, super easy install.

The user interface is amazing. The list of plugins goes on and on (it'll be compatible with whatever systems you use - bug trackers, source control systems, etc.). You can have multiple user accounts with different permissions. Adding a project, tweaking settings, or viewing previous runs is all really easy to do through the browser.

You really just have to try it. Don't bother configuring text files like Cruise Control requires; Hudson is a night-and-day difference from that.

# Answer
> 3 votes
CruiseControl.NET is a good choice that we've used in-house a few times; it's free, and it comes with a desktop app that clearly shows you when people are breaking the build.

There's also Pulse, which is extremely well featured and has a spiffy web interface. It's comes with a cost, however, as you need a license to run it per build server.

We use our CI servers to build our code whenever anyone makes a commit, which is the standard use case - but all of our game assets are set up to be built by our CI servers, and we're about to hook up daily disc builds, so that our QA team has an ISO build ready to test every morning.

It saves a lot of programmer time (invariably, it's always a programmer that does this stuff) in having to manually build code/assets/discs all the time.

# Answer
> 0 votes
**Buildbot**
I know several studios in games and visual effects that use Buildbot.

Over the past year I've worked with our build system to implement a continuous integration strategy for the studio. We are a multi-platform studio (win, lin, osx) which Buildbot can handle well. I'm able to fire up slaves on multiple boxes, execute, and report back to the master so it can display the results. I can see box execution logs from the master whenever I want. I can hook into other slaves so when one slave finishes it fires off a signal for other slaves to start.

So far I have really enjoyed using it and still don't really know it's absolute capabilities. I think the biggest pain will be setup. I wasn't involved in setting the one at my studio up, but it sounded like a pain.

# Answer
> 0 votes
**Cruise (Now Renamed Go)**

http://www.thoughtworks-studios.com/go-agile-release-management

Cruise is quite possibly the best CI I've used because it understands a release pipeline, which allows you to set up a set of rules for moving a particular packaged build from stage to stage, and allows people to grab build artifacts at any stage through REST. It also supports distributing jobs across multiple agents in its Pro version.

That said, Cruise is DEFINITELY meant for enterprise developers, and thus it's expensive. I've been meaning to talk to them about changing their pricing plan to get game companies into the fold, but so far, no luck.

---
Tags: assets, pipeline
---


# Question
Title: What happens to a license if both the publisher and the developer are bankrupt?
Is one allowed to make a similar game or even a sequel which would usually require obtaining a license? Who keeps the license in the end, i.e. who is to be asked for permission in such cases?

# Answer
> 8 votes
The basic answer is that in 90% of the cases, it is essentially impossible to figure out who owns the license, due to it possibly being sold to a string of liquidators. This is where the concept of Abandonware originally came from, and there are tons of early PC games with completely unclear ownership. To make any sort official sequel you will have to track down the current rights holder, which may very well be absolutely impossible.

If you put some effort into tracking down an owner and cannot, it is very likely that the current owner is not aware that it owns a certain property or does not care. In this case it may not be "legal" to reuse aspects of the game but there is essentially 0 chance of any legal issues. However, if your clone/sequel manages to become a financial success be prepared for the rights owner to show up one day and demand a huge cut of the profits.

Also, making a similar game, even a spiritual sequel, is unlikely to actually be actionable in court even if they do show up. Reuse of any specific asset (art, music, text) is very easy to prove as illegal infringement, but doing a gameplay clone of an abandoned property is generally safe, based on the thousands of such PC games in existence.

# Answer
> 15 votes
When a company goes bust all assets are sold off to help pay some of their debts. This would include any intellectual property like a game. So no, it's not open season, it's still owned by someone.

# Answer
> 4 votes
In addition to Iain's and Ben's very good answers, an important concept is the differentiation between "what is legal" and "what is enforceable."

Just because no one has a particular interest in enforcing their Intellectual Property rights doesn't mean they don't own them and couldn't suddenly change their mind about where to put their legal focus. It's safest (and most ethical) to make an honest attempt to seek permission from the rightful owner. This may involve cost to you, as to hire someone to find the rightful owner.

Of course, you can choose to "live life on the edge" and just go for it, but the legal/right thing to do is to put in the effort.

Btw, I have some experience with asking for permission to clone what you might think of as abandonware, and the rightful owner telling me "no problem, we're totally done with that IP, now", so don't think it can't happen.

---
Tags: licensing
---


# Question
Title: Display a Message Box over a Full Screen DirectX application
In our custom assertion handler, I'd like to display a message box asking to see whether or not this failure can be ignored. However, when our DirectX game is full screen, I can't get the MessageBox function to display above the full screen.

Note: The first parameter to MessageBox is the the HWND used to create the device, and it still does not work.

Is this even possible?

# Answer
> 3 votes
Yeah, you very well may be out of luck - (although there's a MessageBoxOptions that allows you to specify ServiceNotification, which might do the right thing http://msdn.microsoft.com/en-us/library/system.windows.forms.messageboxoptions.aspx)

Typically I write my own message rendering at that point (to make sure you can use the assert anywhere, on xbox, whatever).

# Answer
> 1 votes
Try writing a WPF GUI instead (start with a prototype).
That should fix your problem.
(Render to a full screen WPF's DirectX surface and not directly to screen.)

# Answer
> 0 votes
As far as I was able to tell last time we tried this, it isn't possible.

---
Tags: software-engineering, windows, directx
---


# Question
Title: Balancing a game about gladiatorial robot combat
Suppose a player can construct a robot built from various parts and each part costs money. How would you balance the cost of a weapon against its capabilities? What about balancing weapons against other parts?

The base case seems pretty easy: imagine the player can only buy weapons and everything else on the robot is the same. A machine gun that fires 1 bullet per second costs $100. A super machine gun that fires twice as fast could cost twice as much. But what about an ultra machine gun that has four times the range?

Now imagine the player can add other capabilities to the robot like better speed or armor. How do you relate the cost of a machine gun against the ability to move very quickly, or to be stealthed against radar?

I understand that there's a later stage of experimentation where costs and capabilities are adjusted, but where do you start from?

# Answer
Here's a rough strategy I've used to balance similar systems in the past:

Decide on a base metric of balance value. A good first pass if you don't have a better idea is "damage done to others". So a power that only does 10 points of damage is worth 10 "balance points". Now, you need to compare armor to damage in usefuless, so see if you can come up with a good metric to convert it. For instance, let's say that the average robot does 10 damage per second and has a total of 100 hit points. So each robot can last an average of 10 seconds under direct fire. An ability that increases your survivability from 10 to 12 seconds is then worth 2 seconds of damage, or 20 "balance points". You then modify these balance points based on the cost it takes to execute, so for instance an ability that does 10 damage with a 5 second recharge can be worth 1/5 as much as an ability that does 10 damage with a 1 second recharge. You can create similar conversions for abilities such as movement (which increases damage given and reduces damage taken) and stealth (that can reduce damage taken) and make up some initial factors.

An important thing to remember is that all of these initial conversions WILL be thrown away eventually. It's very unlikely that 2 seconds of survivability is ACTUALLY worth 2 seconds worth of average damage, and your testing will show which of your base assumptions are incorrect. But, this gives you a system for creating initial values and one for evaluating the results that fall outside your expected balance.
> 10 votes

# Answer
I'd set up a few automated test.

1. Two robots, exactly the same. The win/lose ration should be exactly 50/50. Then give the new item to one of them and see how much the ratio changes.
2. Two robots, one slightly better than the other to guarantee that it always wins, generally taking X seconds to win. Give the item to the better robot and see how much faster (if any) the average kill takes.
3. Same as 2, but giving the item to the weaker robot, see how much longer it lives and/or if it starts winning now.

You now know how much of an improvement an item is in various conditions (even matched opponent, better matched opponent, weaker opponent) and can price the item accordingly based on your intuition. These tests should be run many times (possibly overnight) and the results averaged together for best results.
> 2 votes

# Answer
Pick arbitrary figures and follow a tight test/iterate loop.

Sure you can do some initial math (like you suggested for pure damage based items), but at the end of the day the best thing you can do is put it in front of people constantly and tweak them after the fact.
> 1 votes

# Answer
For very obscure properties, like sprinting or limited stealth, you may have to try random numbers or rough guesses that you tweak.

I'd highly recommend setting up a way to repeat tests with robots of various configurations under AI control. Run numerous trials with a configuration to find out how powerful it compares to some baseline robot, and then you can improve the baseline along established upgrade paths (higher damage, higher fire rate) until the match becomes more even. That helps you figure out the equivalence of stranger abilities that are harder to quantify.

A similar trial set-up with a human player going up against AI could be helpful, by repeating with increasingly improved AI robots. The performance curve will shed some light on the impact of a given upgrade.
> 0 votes

---
Tags: game-design, balance
---


title: Methods for character design

text:
# Question
Title: Methods for character design
When one begins the character design process, what are good starting points? Are there well known methodologies or systems to help in this process? How does the design process work in game industry, and are there big differences between the approaches different game producers use?

# Answer
Imagine writing a book. If you can put together a very short story about your character (1-2 pages), hand it off to somebody and they start to feel for this character, you win...

Your goal is developing a full-blown character that you could see in the real world. That means you are going to want to break down every component of a real world person into bits and pieces and use that model to mold look and behavior of your own character for a game.

When you think about describing yourself, or somebody you see, what do you think about? Well, immediately our attention is drawn to what we can see. This is a good place to start.

* Describe hair, eyes, ears, nose
* Describe body type (skinny, athletic, muscular)
* Describe height and weight
* Describe clothes that your character wears

Don't ignore details... Short fingers? Scars? Tattoos? Missing eyeball? One leg? Tearful body odor?

You can now use those descriptors to assist in bringing your character a personality.

If you're designing a combat game, you can take the fact that you know your character has scars to describe a hard-fought battle the character was in back during Vietnam. Now that we know that, maybe your character has PTSD which will influence certain game mechanics.

If you're developing a puzzle game, maybe your character got those scars from a science experiment gone wrong.

The goal is getting all of the possible creative juice out of you that describes every single detail that you possible can about this character. Give your other designers all of the information that they could possibly need to fit your character into the game world.

If an Artist is modeling your character they can simply look at your descriptors and recognize the look. They can read a short bio and realize that this guy is a thug or an innocent/clumsy scientist.

If a musician needs to compose a piece that focuses on your character, they can discern the mood they need from reading a short bio.
> 8 votes

# Answer
I wholeheartedly recommend **Better game characters by design: a psychological approach** by Katherine Isbister

http://books.google.com/books?id=TGBTzVj47ZcC

It covers the whole design process, from cultural preferences to physical features, in exhaustive details. It also differentiates PC design from NPC design, details the psycho-sociological aspects of each of the design choices, and explains how to evaluate your character design.

An essential read.
> 6 votes

---
Tags: game-design, character, methodology
---


# Question
Title: How do you gather and collate information you need to make a post-mortem?
After the game is done (either shipped or the project was canned), what is the best way to make the post mortem, so that it maximizes the chances to never make the same mistakes again?

1. How do you gather all the needed informations from the team?
2. How do you condense them in the final postmortem?
3. How do you avoid to make the same mistakes in the following project?

# Answer
> 10 votes
You're gaining valuable insight as you work through the process. For any good business man that works on a project it's fairly easy to tear your project to pieces when analyzing what you did wrong. Figuring out want went right is a little harder.

How I would approach a thorough postmortem

**Get All Perspectives in Writing**
Ask each team member to write a few pages on project observations. Instead of randomly laying a trail for them to fulfill I would ask exact questions that you want to know about. You can supplement this with a meeting, but I rather get someones sole attention without distraction.

The most obvious questions would be

* List your top 5 items you feel went right with the project?
* List your top 5 items you feel went wrong with the project?

I would supplement those questions with specific questions relating to the team and project that you personally want to know from a management position.

* How did you feel about working with Box2D instead of Chipmunk? Would you use (x) again?
* Do you feel the project management was able to do x, y, and z for you?

**Fail Early, Fail Often**
Well, it is pretty hard to 'fail early' when your project is out of the door. Hopefully the feedback you gain from the above will shed light on processes that may have been pretty dark to you.

There are problems that you will run against that will sting pretty bad. It'll be pretty difficult to just forget those.

To make sure that you don't forget the problem areas it could be handy to write a 'Core Value' type list that you keep at arms reach. Keep them available for others to see and for you to see. When the your next project starts I might be inclined to bring some of these to the table to get other people's perspectives. If you have new eyes on the project you might get feedback that could shed new light on solving a particular issue.

As long as you're aware, and you keep your problems in the light, you're bound to solve those issues.

**Write It**
Grab all of the writings and bring it all together.

1. Introduction to the project, goals, and anything you feel like sharing about the project process
2. Top 5 - What went right?
3. Top 5 - What went wrong?
4. Conclusion... Bringing it to the end.

# Answer
> 1 votes
Most of the postmortems I've read seem to follow a format of:

* What we did
* What went well
* What could have gone better
* Conclusion (what was learned, and will be applied next time)

I'd get all the people involved on the project to toss in their $0.02 and see what they have to say about those things, then compile everything into one big, exciting to read document.

I guess in answer to your questions: 1. How do you gather all the needed informations from the team? Ask them. Email, sit down and chat with them individually and as a team.

1. How do you condense them in the final postmortem? Lump together common responses. Chances are you will be able to recognize general trends (ie: people having the same issues). Focus on the big/important ones.
2. How do you avoid to make the same mistakes in the following project? That's a bit of a tricky one. Maybe write up a single 8x11" sheet of paper to pin in your cubicle as a reminder to avoid those specific previous mistakes? I've got a few sticky notes like that just below my monitors, and they seem to do a decent job of reminding me to do certain things.

# Answer
> 0 votes
> How do you gather all the needed informations from the team?

I like to have everyone write down their list privately first. On the last project I did a post-mortem for, we had four sections: 1) Things that went right, because we did things in an awesome way 2) Things that went wrong, because we screwed up 3) Things that went right from our partners (outsourcing houses, publishers, etc.) 4) Things that went wrong with our partners because THEY screwed up

The first two help us to adjust our own behavior. The last two help us to pick better partners (or manage our existing ones better) next time.

> How do you condense them in the final postmortem?

Have everyone email their lists to one sucker^H^H^H^H^H^H volunteer, who then condenses and anonymizes the lists. The collated list is then sent to everyone and discussed.

> How do you avoid to make the same mistakes in the following project?

In my experience, you don't :) In seriousness, when I start a job at a new game company, the first thing I take a look at is the previous post-mortems (if they have them on file somewhere). Usually I see common themes throughout all projects, which tells me ahead of time what kinds of challenges to expect on the current one. If I were running my own studio, my first instinct would be to start the kickoff of each new project with a re-reading of previous post-mortems, and a discussion of how not to do the same dumb things a fifth time... and then re-visit the hot-button post-mortem issues at each milestone in the project.

---
Tags: project-management, process
---


# Question
Title: What's the best place to showcase my pixel art?
I recently started learning spriting/pixel art to help propel my game development endeavors and I've gotten to the point where I'd like to start sharing it for comments, critiques and other feedback.

I've got a pretty good awareness of some art sites out there but none of them have really struck me as ideal so I'm looking for suggestions from you guys!

# Answer
You might want to look at Pixel Joint. Good place to showcase your pixel art and gather feedback from other artists. Not as crowded as Deviant Art, though.
> 6 votes

# Answer
There are some really great indies over on tigsource.com (art board). I've seen a lot of those guys pump out some really cool pixel art. I'm sure you'll find a fair amount of people willing to give you advice. You might check out gamedev.net as well. I know Mark Eugn does a LOT of epic pixel art (gd.net journal).

To showcase your work, http://carbonmade.com/ might be the way to go. You can break what you do down into categories so people can find their focus faster. The interface for the site is nice.
> 2 votes

# Answer
The Pixelation forum has lower traffic but, has always been a good place for honest critiques. DeviantArt isn't geared specifically towards pixel art but, it's a great place to showcase and interact with other artists.
> 0 votes

---
Tags: graphics, assets, sprites
---


# Question
Title: How can I get into the educational market?
I believe that my current game project is very well-suited for educational gaming; so well-suited, in fact, that I know of several different schools (one community college and at least one or two high schools) that have used versions of it at some time or another. And that's without any such marketing on my part.

I'd like to expand on this part of the potential user base. But I have absolutely no experience in dealing with school administrations. How can I break into this market enough to be noticed?

And on a side note, could marketing the game as educational kill the gamers market?

# Answer
Although dated (2006), this looks to be a good read: http://genyes.com/programs/supplemental/edgames

**Schools are cheap**: They're on a budget. Why would they want your game X when they could find something similar for free on the internet?

And if you are looking into getting your game into non-school markets, take note how few console games have educational games. You are more likely to see them in handheld or mobile devices. You might want to consider the iPhone or Android markets.
> 4 votes

# Answer
It would be an advantage if you could get with the schools that you know who use your product and get them to write a recommendation about it. Use that when you are out pitching to other schools. If you can find hard numbers / results that would be extremely helpful.

You need to turn yourself into a door-to-door salesman. It'll be a lot of foot work and a lot of convincing revolving around why they should use your product. Call schools and ask if you can get a moment of the deans, assistant dean, principle, etc time to talk about a very useful product you feel would be a very important learning tool. If you can't get them, then someone else that represents the school.

A plus on the university front is that you can approach the separate colleges within the university and pitch to their staff, which is probably what you want to do for a game project. You figure you can approach one University and have 6 or so meetings/potential clients. Not bad.

I've been on this road before but my buddy was selling an application vs. a game product. Games will be a tough sell unless you can really show what it can do. I might market it under a different buzzword instead of purely 'Game.' Simulation? Serious Game Project?
> 2 votes

# Answer
How about attending a conference like this one from the American Association of School Administrators in February? As David mentioned, get references if possible and then set up a booth and sell it.
> 2 votes

# Answer
Some great answers here. All I can add is that if you specifically market your game as "educational" then yes, I think you're pretty much killing the non-edu market. This is not your fault and has to do with the fact that "edutainment" is usually done so horribly wrong that gamers are accustomed to games either being fun OR educational but never both at the same time.

The opposite is not true. I know some educators that routinely use entertainment games (they call them "COTS games" - Commercial Off-The-Shelf) in their classes when they see the educational content buried in there. So if you want to reach both markets, consider selling it on its entertainment value first, and then reach out to educators and schools at conferences.

Another thing to consider, if your game is aimed at K-12, is that there are state standards for the exact subjects that must be covered in each grade, so you should work with some local educators to make sure your game conforms to the standards. Yes, this means making a K-12 game is hard, because the standards vary from state to state, and that's something you'll have to deal with.
> 2 votes

# Answer
Were they your previous versions? If so, can you build a marketing agenda based on them? (Use cases, testimonials, and what not)

If not, then the first step I recommend doing is:

Find a decent sized school, and offer it to them for free. Like Bryan said before me, schools are cheap. The administration already has enough trouble without wondering why they should purchase your product. By removing that, they will be a little bit warmer to a pitch.

You do of course, still have to pitch :1. But in it, you would want to maybe work out an arrangement where you can collect relevant data for future pitches and what not. Impact on Student Education overall :2, student/teacher testimonials.

Why?

Schools seem very receptive to what other schools are doing, students are very social and there always seems to be talk about what other people have. I've noticed that among colleges a good deal of the intranet is shared (same email solution, same billing, same online courses). Or even to use a bigger *and far more broken example*, look at how quickly Facebook took off among college students.

After your foot is in the door, you can refer back to how it helped this school (because if something is beneficial and THEY have it, WE want it too.

---

As for your sidenote. IMO:

It may drive off some 'core' gamers (*The group that commonly considers themselves the majority of gamers.*) but looking at the success of casual games. The numbers seem to say that either the larger part of the market is of a younger / older age. Or they are the only people spending the money :p
> 1 votes

# Answer
Consider contacting a publisher.

Full Disclosure: I work for a place called Attainment Company. We specialize in Special Education products. We sell both software and physical products (books, games, etc.), we distribute catalogs semi-frequently (worldwide) and also do some web sales. A lot of our software is done in house, but we do sell some applications from other companies as well. I don't know 100% how that works because I'm not at all involved with the catalog and all that (Software Engingeer), but I imagine that there are similar companies for the general education market. Though if you feel your product would be applicable to special education I can see if I can find someone to get in touch with.
> 1 votes

---
Tags: marketing, educational-games
---


# Question
Title: How can I get into opensource game development?
## The short and sweet question

I'm new to game programming in general, so how do I go about making GOOD QUALITY opensource games?

## What I have come across

There are a multitude of games that I have played on Linux that are just downright shameful. The graphics are terrible, the AI is lacking, and the replayability is little to none. Don't get me wrong; I have played some good opensource games such as World of Goo, Gish, and Aquaria; but I'm really missing out on good games over here in my Linux hut.

## What I have found

So, I did a little research on how the games mentioned were made. Thus, I have started learning OpenGL and SDL using my C++ programming experience (which is about a year of programming, not much). I also picked up the following books, which were recommended from programmers on stack overflow:

* Focus on SDL (The only let me post one link for now...)
* The OpenGL Super bible
* GEB and CODE

## What I have been recommended

I have also talked to someone who is a fairly experienced programmer who recommends that I take the C++ route to gaming, and that OpenGL and SDL would be a good way to go. He also recommended that I start using versioning control with my programs (Git particularly). What are your opinions on that?

Hope that was clear, guys.
Let me know,
Immanu'el

# Answer
> 4 votes
Plain and simple, the best way to get into opensource gaming is to do it.

Git is a fine choice for version control and you should start using it immediately. It'll be something you use constantly throughout development and so the sooner you're familiar with it the better. As an added bonus you can host your source on a site like GitHub so other people can clone, work on and check code into your repository.

The c++/sdl route is a good one and one that's been relatively well traveled. You should be able to find a good amount of resources on most topics.

When aiming to get an open source project going, keep in mind that there could be any number of contributors from all different cultures, backgrounds, etc. Their ideas may not necessarily mesh with what you have in mind for the project. You need to keep a balance between maintaining contributors and steering the project towards that final goal.

I believe the above is why we see relatively low quality open sources games. You have so many cooks contributing while anyone with a strong drive towards a particular idea (which is something I feel a game needs) may become alienated at some point during development.

I may be wrong here but Gish and Aquaria were only recently open-sourced and were developed by a closed team. I'm also pretty sure that World of Goo source is still closed.

It may be preferential to not let your first foray into gaming be your first foray into open-sourcing a game as well. It won't hurt to throw it on a public repository, but I've found, much like baking, the first one gets 'thrown away'. It's a learning experience - getting the processes, techniques and math needed to get something usable out. Don't expect your first game to trump the likes of 0 A.D., Battle for Wesnoth or FreeCiv.

You may want to look intro contributing towards one of the above games, that would be invaluable experience if you want to run a similar project at some point.

# Answer
> 0 votes
If you are doing *any* sort of software development then version control is essential. You have to be able to track changes and if necessary roll-back to previous, known stable, versions.

This is doubly true (if that's possible) with open source development as you are effectively in a distributed team, possibly in different countries, time zones or continents.

# Answer
> 0 votes
The best way to make quality indie (opensource or not) games is to make a lot of really bad ones first. Don't remake the same game over and over, but just make lots of little games and learn something new each time.

---
Tags: c++, opengl, open-source
---


# Question
Title: How does one go about building Alien Swarm?
Valve just released Alien Swarm on steam, along with all the source code. I would love to build a version of it on my own machine and play a little bit with the code.

Has anyone here tried to build it yet? Is it easy enough to just build and run it?

Thanks.

# Answer
The basic answer is that you first have to grab the Alien Swarm SDK. It should be a choice in the "tools" menu of your steam client. Download it, it's not very big. Then run it.

One of the options is "Create a mod". This extracts the source code to a useful location for you and sets up some config options. The help guide from that menu has info on how to compile and test it. Or you can view the info on the valve developer wiki. It's setup for visual studio 2005, but I was able to build it correctly with my copy of Visual Studio 2008. Seems pretty well set up for immediate modding.
> 5 votes

# Answer
In addition to Ben's answer, a bit of extra work is required to get it building in Visual Studio 2010. For the client project, you need to either change the name of the project from the default "Client (Swarm)" to just "client", or change the Target Name property to "client" from the default "$(ProjectName)". After this, it builds without a hitch.
> 5 votes

---
Tags: open-source, valve
---


# Question
Title: Server related questions and it is available options?
i went thru a lot pages here searching for information about the "server side" of a multiplayer game, while i did found some information they were not exactly what i was looking for.

* What is the best available options for the server communication ?
* Is it worthed to handle a game server with website requests for a mmo or should not even be consider at all ?
* Are you aware of any good material regarding the same in C# for a headstart on the subject ?
* When should i consider creating multiple servers for example "monsters servers, world drop data and the such" or what should i consider for this (i've seen that some very popular games out there use this sort of thing such as a server for monsters, lineage for example) ?

---

> Currently i am developing a 2D game using Tiled and C# for single player but i would like to further turn it into a mmo game but i am very unsure of what a server would look like for this ... Any further knowledge or personal experience you could provide related to the server aspect and options i would appreciate.
>
> As i said above it is a 2D with multiple maps where the user goes around as their level grows, each map which is not a town has monsters spawning and despawning when killed by players, players can move around on the possible spaces, once a player hits the border of the map at defined locations it will take them to the next map...
>
> Since i am doing it on a 800x600 size i guess i will need to limit the players per server (or something like world's or whatever term is used for it..) so it does not over populate the screen with players ...

---

if my question or english at any point is not good please wrap your comment and i will try to rework it to best fit the community of if you can edit it and correct what you feel like should be changed, please go ahead...

# Answer
> 3 votes
Asking "What server should I use for my game?" is far to generic to get a good answer. The server architecture for a game of the scale of an MMO is enormously complicated (I think we have ~3 dozen different server types) and, more importantly, entirely driven by the needs of your game and style.

I think part of your question is "Can I use a webapp for the server component of my game?", to which I would say "Maybe". What are your latency requirements? For something like simple chat or a shared high-score system that would be perfectly acceptable, for something like communicating player movement (high-volume, low-latency) maybe not so much.

---
Tags: c#, multiplayer, server
---


# Question
Title: Synchronizing clients with a server and with each other
What is the best way for keeping all clients synchronized with a server and with each other?

Currently, we have two approaches in mind:

1. When a client sends something to the server, the server immediately sends out messages to all clients, which react immediately.
2. Introducing some time delay, whereby the server sends out messages to all clients, with the directive, "act upon this at time `t`.

The second approach seems like it would more likely keep the clients all in better synchronization (since it caters for some degree of lag); but I wonder whether responsiveness would be lost to too high a degree (i.e. the user clicks 'jump' and there is a noticeable gap between pressing the button and actually jumping).

There is also the possibility of having clients calculate their own position (and not wait for servers to say "you have jumped"); but because of the inevitable lag, clients would get very out-of-sync.

Then there's the whole TCP vs. UDP question; because we want it fast, but I'd also hate for the server to say you're in a completely different location than you thought you were.

With all of these competing demands, it all gets very uncertain how we should approach this issue. Which of these approaches (or any other) would be best for keeping clients and server all in sync? Which ones are actually used in the industry?

# Answer
The quick answer is: there is no best approach.

Games all contain different architecture; every game will choose different sets of data to send in order to synchronize itself with other machines, which will affect the choices that you can make when choosing how to deal with lag.

What you specify in option #2 -- that clients send messages to be acted on at a future time -- is definitely one approach. In fact, the Source engine uses a variant of this approach, where rendering is always 100ms behind local client actions; all machines attempt to operate on the same actions at the same time. This adds an artificial, imperceptible lag to the game in order to hide actual network latency.

If you can't take this approach, you can also choose option #1, simply sending the most up-to-date data and upon receipt, use interpolation and extrapolation (client-side prediction) to try to hide latency. I've used this approach in at least one shipping game -- but again, it all depends on *your* game; there may be other approaches you can take.

Finally, when choosing between TCP and UDP -- you probably want UDP. There are scenarios where TCP *is* a viable option for networking your game, but when you're making an action game, you want the latest data as soon as possible. If you can deal with dropped packets yourself, UDP is the better choice. (There are libraries, such as ENet, that provide a wrapper around UDP to replace functionality from TCP, such as reliable packets.)
> 8 votes

# Answer
Here's a couple of good links which cover an awful lot of game networking.

And this is the first part of the more hands on networking series. http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/

For the history. 'we're sorry, but as a spam prevention mechanism, new users can only post a maximum of one hyperlink. Earn 10 reputation to post more hyperlinks.' Just look around his website, anyway.
> 4 votes

# Answer
Since you mention Clients and Servers, i'm going to assume that you're talking about a Client/Server architecture where the Server is the authority on the state of all objects.

Note: The alternative is a Peer-To-Peer architecture where the owner of an object is the authority for that object.

There is already a well proven method for synchronizing moving objects using Client-Server architecture. It's called Dead Reckoning..

A good way to implement this in a game would be like this:

1. Clients send inputs to the server.
2. Server updates the game objects (accelerations & directions) and sends them back to Clients.
3. Clients use these updated values to simulate the movement of the objects locally.
4. Occasionally, the server sends a position correction to avoid drift.
5. Rinse; repeat.
> 1 votes

---
Tags: architecture, synchronization, server, client
---


# Question
Title: What are good questions for design interns?
I've recently been interviewing design interns and been pitching what I consider fairly easy practical design questions to measure their skill level. I've been shocked by poor quality of answers. Now this may be the quality of the applicants.

What questions do you ask an entry level games designer to probe for their skill level?

# Answer
A classic is to ask them about a game they feel strongly about. Ask them why they think certain design choices were made. IE, why can't you jump in Gears of War? You're not looking for right answers, you just want to prove that a given intern can actually think critically about games. If they can't get pat their blinders and identify a flaw in a great game or a positive in a bad one, they may not be able to understand the tradeoffs that go into actual game design.
> 5 votes

# Answer
I set poorly specified design tasks to see if they ask questions. Skills can be taught. Starting with the impression that you know the answer or that there is a right answer is harder to overcome.

Also, here's an off-the-wall request that taught me the most about how the minds of the designers I've interviewed worked: "Tell me three things that I don't know."
> 1 votes

# Answer
Tell me a game you've enjoyed and tell me what you can do to make it better.

I believe this is a good question for the following reasons:

* they choose the game they want to talk about
* you can tell how passionate they are by how they describe the game.
* you can tell that they actually paid attention to the game's design philosophy if they have insights on the game's mistakes
> 1 votes

# Answer
I like a variant of Ben's question: pick a game they really love, then ask what they would change about it. If the answer is "nothing, it's perfect in every way"... well, that's how you tell the difference between a gamer and a designer :)

For level designers, you could always ask them to, you know, design a level. Or assuming you have them submit level design samples with their application, have them walk through their level explaining the choices they made. Critique their level as you go, to see if they can defend their choices while remaining polite when they know they're right (and to see if they can take constructive criticism when they're actually wrong).
> 0 votes

---
Tags: game-design, hiring
---


# Question
Title: What is dead reckoning and how do you deal with it?
I've come across this problem before and it would be good to know the different ways of solving this problem.

# Answer
Synchronizing clients with a server and with each other has some tips and links.
> 3 votes

# Answer
There are a lot of ways to solve dead reckoning.

One way is to have the server store the latency of each player as well as past game states (up to the maximum time before disconnecting an inactive player). If a packet is received, the server will check the game state in the past when the player is sent the packet and check for events.
> 2 votes

---
Tags: multiplayer
---


title: Realistic Trajectory of a Projectile

text:
# Question
Title: Realistic Trajectory of a Projectile
When simulating an airplane and a missile, to get them moving in the air we apply a force in one direction. Now an airplane has wings that keeps it afloat while a missile can have fins to stabilize it. In both cases when the force is no longer strong enough, the velocity reduces and the projectiles are bound to succumb to gravity. When that happens, the projectiles naturally don't fall directly to the ground disregarding rotation and other spins based on air resistance and whatever momentum there is left.

My question is, to simulate such behavior how would the Bullet, Nvidia PhysX and Havok physics libraries compare against each other especially with emphasis to the following?

1. Gravitational pull and momentum acting on the projectiles.
2. Air resistance acting on the projectiles.
3. Both 1 and 2 above's behavior can be based on varied levels of a central forward force applied on the projectiles.

# Answer
If you want to learn about the actual physics involved, I would recommend this book: Mathematics for 3D Game Programming and Computer Graphics, Second Edition

It describes everything from raycasting to box collisions to realistic trajectories. I have had it for three years now and it has never let me down.
> 2 votes

---
Tags: physics-engine, projectile-physics
---