# Question
Title: Assets Management, database or versioning system?
While developing the assets for the game, (meshes, textures, sounds, videos) ho do you manage them?

1. Keeping them together with the source code inside the versioning system? (perforce, git, etc…)
2. Or having a central back-upped, database dedicated to the assets and having the editors always work liked to it? (PostgreSQL, MySQL, etc…)
3. Other?

What are the pro and cons of each, and why one should choose it over the other/s?

# Answer
> 21 votes
For many of us - especially working on smaller games - you **absolutely should have assets in the same repository as your source**.

The suggestion that assets belong in a separate repository only makes sense for very large sets of assets, or for somewhat-large sets of assets when there's a clearly defined engine/data boundary. Unless there's a specific technical reason for it - it's bad advice!

You want your version control to *behave like version control*. You want to be able to rewind and fast-forward and branch and merge revisions and still have your game working. And your code and assets *will* depend on each other.

For example: Your code might expect to be able to set a parameter on a shader, and that shader might depend on a texture being there. Or maybe the data format of your levels might depend on a particular version of your game code.

It almost certainly will get messy. And you have better things to do than to try and keep it tidy.

---

Now, as Mike Wagner commented (on this answer) - you don't want or need all the "in progress" versions of your assets under version control! Just the final/working version, as used by your code, will do - often this is what you export from your tool.

(Although if you do want to version-control the in-progress versions of assets - that's fine. And well suited to a separate repository. I personally find that good folder organisation and a proper backup system suffices.)

That being said - it's sometimes nice to have the option to just stick "in progress" assets under version control. Typically this involves having a content pipeline that can handle any 'export' steps for you - for example: flattening a multi-layer image to a single texture.

# Answer
> 9 votes
Versioning system.

With a roll-your-own approach you'd effectively end up rolling a versioning system, so better to use an off the shelf one that's already had years of design/code/test cycles.

Keep the assets in a separate repository from the source, to make it easier to keep checkout / sync times to a minimum and take different decisions on how much history to retain (though disk space is cheap, retain it all whenever feasible. Individual textures don't change that much over the life of a project).

Mark XML files as binary, merge tools tend to be very bad at merging nested markup and artists aren't likely to spot broken markup if the tool thinks there are no conflicts.

If you can, arrange a syntax check or even asset build on every commit and reject the commit with an email back to the person committing if it fails; this will save a great deal of team time.

# Answer
> 8 votes
Everything in one repository, if you can afford it in terms of size. I've heard of Subversion repositories in the vicinity of 1 TB. We are currently a bit below 400 GB.

Also, artists much check in everything, including the 30 rough outlines of a concept; we use separate folder trees for "source assets" and for "exported" - the ones that go into the asset build script. If your artist is hit by a bus tomorrow, you need to be able to have someone continue work on his assets the next day, only looking through the repository (no archeology on his personal machine). Once upon a time when games were 2D and sprites were prerendered from complex animated Max scenes, we had to ship a bunch of units in an RTS game with a bit crappy, and very inconsistent look (vs. the rest of the units), even though it was a matter of re-rendering with slightly different lighting and antialiasing settings - because the original artist had quit, and we didn't have his original Max scenes. Don't let this happen to you.

---
Tags: assets, version-control, asset-management
---


# Question
Title: What in-game user interfaces are available?
I'm wondering what options are available for in-game interface libraries (not OS-level interfaces) and what are your opinions about them?

Please put only one library per answer and follow this template.

* Name
* Link to website
* Cost
* License (if free or open source)
* General summary / Opinion

# Answer
The OGRE3d engine uses CEGUI. It's FOSS, supports scripting from lua, predefined layouts can be created in XML, supports most of the basic widgets you would need *(see cegui.org.uk for more documentation)*.

You can also find lots of UI demos using CEGUI on YouTube.
> 2 votes

# Answer
I've been meaning to try out libRocket.com, though I haven't done so yet. Seems, it allows to lay out the interface using a subset of HTML and CSS, which could be pretty efficient.

It's free for download (and comes with source), but as far as I know they use a custom licence, so not sure about what possible caveats there might be.
> 1 votes

---
Tags: gui
---


title: Rendering performance for Flash games

text:
# Question
Title: Rendering performance for Flash games
I was reading on SO about native flash rendering vs building a custom `BitmapData` frame buffer and some of the answers were a bit conflicting, so I was wondering:

1. Is it generally best practice to go the custom Bitmap buffer route or is it best to leave rendering to the flash engine?
2. If you're using vector animations (`MovieClip`s) as opposed to sprites, does that change the answer to the above?
3. If so is it best practice to use sprite based animations?

(I'm targeting Flash 10 if that makes any difference)

# Answer
**1. There is no general best practice.**

If you got a lot of (complex shaped) elements, particles etc. in your game, the bitmap buffer approach is going to be *much* faster. The bitmap buffer will also scale better with increasing complexity of your sprites. The vector renderer *will* become slower with more complex shapes or tween (shape tween) animations, it has some other benefits though:

* You can freely scale your assets or even zoom into the scene without loss of quality.
* Rotation or other transformations like skewing will be much easier to perform on vector graphics

So in conclusion, it boils down to what kind of game you're building.

**2. Using MovieClips instead of bitmap sprite-sheets**

I guess you meant "bitmap sprite-sheets" and not the AS3 *Sprite* class?

This doesn't make a difference, really. You can always turn your MovieClip based animations into animated bitmaps. Either manually, by exporting the movie to frames and turn them into a sprite-sheet, or dynamically, by rendering a sprite sheet from your MovieClip at runtime. Here's how I would do this:

1. Create an instance of the MovieClip and `stop()` it.
2. Create a `new BitmapData` object with the same width and height as the Movieclip.
3. Use the draw() method, to render the MovieClip to the BitmapData.
4. Store the BitmapData object in an Array or Vector.
5. Go to the next frame of your MovieClip and repeat Steps 2 - 4, do this until you reached the last frame of your MovieClip. It's also a good idea to update two variables with the *max width* and *max height* of your MovieClip frames (since these can change from frame to frame).
6. Now you can combine all the stored BitmapData Objects into a Sprite-Sheet (use BitmapData.copyPixels())

**3. Sprite-based animations**

As mentioned in the answer to your first question, there's no definite answer to that. If you need to perform a lot of transformations with your objects, eg. *scaling* and *rotating* you're probably better off by using the flash native renderer. If you got pre-defined animations that can be baked to sprite-sheets (manually or dynamically), **and** if you need to display hundreds of sprites at the same time, then go for a bitmap-rendering engine.
> 14 votes

# Answer
I would say that if you're building a raster based game using sprites, go with building a custom rendering solution using BitmapData. If you're building a vector based game, go with using the built in animation mechanisms using MovieClips.

If you go with building a custom rendering solution, you pretty much disassociate yourself from Flash using ActionScript alone to accomplish what you need. The flixel engine uses this method and it's quite nice. I prefer writing my own engine from scratch though, but you get the idea.

Going with the built in Flash animation mechanisms works best for vector based games because you can easily create your library assets as MovieClips that you can then instantiate in ActionScript on demand. You use the timeline provided the movie clips to handle animation and move the location of the sprite accordingly. All the BattleOn! games like Adventure Quest Worlds use this method. It looks nice also.

I'm assuming your last question is referring to using the Sprite class instead of the MovieClip class for vector animations. A Sprite is a MovieClip without a timeline, so you would lose the convenience of having the animations managed for you.
> 6 votes

# Answer
Even though it is a commonly held belief that blitting is faster, I have not seen any benchmarks proving this. Some developers just prefer blitting because it allows them to treat Flash as more of a generic virtual machine, and control rendering themselves. However, if you like the built-in display list (which I do), Flash can happily move, scale, rotate and apply nice effects to hundreds of on-screen DisplayObjects (e.g. MovieClips, Sprites, Bitmaps) at high frame rates, so long as they are quite small in dimensions, e.g. less than 200x200 pixels each. You can use MovieClips without using vectors. Most games will use bitmap assets whichever system they use. But it is sometimes useful to layout and animate bitmap assets on the timeline, especially if you are working with a Flash-specialist designer rather than a pixel artist. By setting the stage quality to LOW you will get much better performance at the expense of uglier transforms. Flash will not render any objects that are off screen, so they do not slow you down.

Where Flash can get slow is moving and transforming very large bitmaps - for example if you have a very large scrolling level, or lots of parallax layers. A hybrid approach of using MovieClips for your game objects while blitting the background from an offscreen buffer may be faster, and will allow you to have infinitely large levels, while still allowing the ease-of-use of standard Sprites and MovieClips.
> 3 votes

---
Tags: flash, optimization, sprites, performance
---


# Question
Title: What is the simplest 3D file format to parse?
I want to parse Blender-Made Files directly into my homemade Lisp program. I've been pulling data out of .X3D files manually. Is this the best format to focus on writing a parser for?

Thanks!

# Answer
Write an exporter. No, really.

That way you can output exactly the data you need in the format you want.

When you start from one of the existing plugins, it's actually quite easy.
> 16 votes

# Answer
I've always found OBJ files easiest to parse, but they tend to be large because they're "human readable." However, they're public and standardized.

If you need it, the Obj Specification:

http://paulbourke.net/dataformats/obj/
> 5 votes

# Answer
Milkshape (MS3D) format was quite easy to implement a reader for, in C++ and C#. Here's the spec I used (retrieved from web.archive.org):

```
//
//
//
//                MilkShape 3D 1.8.2 File Format Specification
//
//
//                  This specifcation is written in C style.
//
//
// The data structures are defined in the order as they appear in the .ms3d file.
//
//
//
//
//

//
// max values
//
#define MAX_VERTICES    65534
#define MAX_TRIANGLES   65534
#define MAX_GROUPS      255
#define MAX_MATERIALS   128
#define MAX_JOINTS      128

//
// flags
//
#define SELECTED        1
#define HIDDEN          2
#define SELECTED2       4
#define DIRTY           8

//
// types
//
#ifndef byte
typedef unsigned char byte;
#endif // byte

#ifndef word
typedef unsigned short word;
#endif // word

// force one byte alignment
#include <pshpack1.h>

//
// First comes the header (sizeof(ms3d_header_t) == 14)
//
typedef struct
{
    char    id[10];                                     // always "MS3D000000"
    int     version;                                    // 4
} ms3d_header_t;

//
// Then comes the number of vertices
//
word nNumVertices; // 2 bytes

//
// Then come nNumVertices times ms3d_vertex_t structs (sizeof(ms3d_vertex_t) == 15)
//
typedef struct
{
    byte    flags;                                      // SELECTED | SELECTED2 | HIDDEN
    float   vertex[3];                                  //
    char    boneId;                                     // -1 = no bone
    byte    referenceCount;
} ms3d_vertex_t;

//
// Then comes the number of triangles
//
word nNumTriangles; // 2 bytes

//
// Then come nNumTriangles times ms3d_triangle_t structs (sizeof(ms3d_triangle_t) == 70)
//
typedef struct
{
    word    flags;                                      // SELECTED | SELECTED2 | HIDDEN
    word    vertexIndices[3];                           //
    float   vertexNormals[3][3];                        //
    float   s[3];                                       //
    float   t[3];                                       //
    byte    smoothingGroup;                             // 1 - 32
    byte    groupIndex;                                 //
} ms3d_triangle_t;

//
// Then comes the number of groups
//
word nNumGroups; // 2 bytes

//
// Then come nNumGroups times groups (the sizeof a group is dynamic, because of triangleIndices is numtriangles long)
//
typedef struct
{
    byte            flags;                              // SELECTED | HIDDEN
    char            name[32];                           //
    word            numtriangles;                       //
    word            triangleIndices[numtriangles];      // the groups group the triangles
    char            materialIndex;                      // -1 = no material
} ms3d_group_t;

//
// number of materials
//
word nNumMaterials; // 2 bytes

//
// Then come nNumMaterials times ms3d_material_t structs (sizeof(ms3d_material_t) == 361)
//
typedef struct
{
    char            name[32];                           //
    float           ambient[4];                         //
    float           diffuse[4];                         //
    float           specular[4];                        //
    float           emissive[4];                        //
    float           shininess;                          // 0.0f - 128.0f
    float           transparency;                       // 0.0f - 1.0f
    char            mode;                               // 0, 1, 2 is unused now
    char            texture[128];                        // texture.bmp
    char            alphamap[128];                       // alpha.bmp
} ms3d_material_t;

//
// save some keyframer data
//
float fAnimationFPS; // 4 bytes
float fCurrentTime; // 4 bytes
int iTotalFrames; // 4 bytes

//
// number of joints
//
word nNumJoints; // 2 bytes

//
// Then come nNumJoints joints (the size of joints are dynamic, because each joint has a differnt count of keys
//
typedef struct // 16 bytes
{
    float           time;                               // time in seconds
    float           rotation[3];                        // x, y, z angles
} ms3d_keyframe_rot_t;

typedef struct // 16 bytes
{
    float           time;                               // time in seconds
    float           position[3];                        // local position
} ms3d_keyframe_pos_t;

typedef struct
{
    byte            flags;                              // SELECTED | DIRTY
    char            name[32];                           //
    char            parentName[32];                     //
    float           rotation[3];                        // local reference matrix
    float           position[3];

    word            numKeyFramesRot;                    //
    word            numKeyFramesTrans;                  //

    ms3d_keyframe_rot_t keyFramesRot[numKeyFramesRot];      // local animation matrices
    ms3d_keyframe_pos_t keyFramesTrans[numKeyFramesTrans];  // local animation matrices
} ms3d_joint_t;

//
// Then comes the subVersion of the comments part, which is not available in older files
//
int subVersion; // subVersion is = 1, 4 bytes

// Then comes the numer of group comments
unsigned int nNumGroupComments; // 4 bytes

//
// Then come nNumGroupComments times group comments, which are dynamic, because the comment can be any length
//
typedef struct
{
  int index;                                            // index of group, material or joint
  int commentLength;                                    // length of comment (terminating '\0' is not saved), "MC" has comment length of 2 (not 3)
  char comment[commentLength];                      // comment
} ms3d_comment_t;

// Then comes the number of material comments
int nNumMaterialComments; // 4 bytes

//
// Then come nNumMaterialComments times material comments, which are dynamic, because the comment can be any length
//

// Then comes the number of joint comments
int nNumJointComments; // 4 bytes

//
// Then come nNumJointComments times joint comments, which are dynamic, because the comment can be any length
//

// Then comes the number of model comments, which is always 0 or 1
int nHasModelComment; // 4 bytes

//
// Then come nHasModelComment times model comments, which are dynamic, because the comment can be any length
//

// Then comes the subversion of the vertex extra information like bone weights, extra etc.
int subVersion;     // subVersion is = 2, 4 bytes

// ms3d_vertex_ex_t for subVersion == 1
typedef struct
{
  char boneIds[3];                                  // index of joint or -1, if -1, then that weight is ignored, since subVersion 1
  byte weights[3];                                  // vertex weight ranging from 0 - 255, last weight is computed by 1.0 - sum(all weights), since subVersion 1
  // weight[0] is the weight for boneId in ms3d_vertex_t
  // weight[1] is the weight for boneIds[0]
  // weight[2] is the weight for boneIds[1]
  // 1.0f - weight[0] - weight[1] - weight[2] is the weight for boneIds[2]
} ms3d_vertex_ex_t;

// ms3d_vertex_ex_t for subVersion == 2
typedef struct
{
  char boneIds[3];                                  // index of joint or -1, if -1, then that weight is ignored, since subVersion 1
  byte weights[3];                                  // vertex weight ranging from 0 - 100, last weight is computed by 1.0 - sum(all weights), since subVersion 1
  // weight[0] is the weight for boneId in ms3d_vertex_t
  // weight[1] is the weight for boneIds[0]
  // weight[2] is the weight for boneIds[1]
  // 1.0f - weight[0] - weight[1] - weight[2] is the weight for boneIds[2]
  unsigned int extra;                                   // vertex extra, which can be used as color or anything else, since subVersion 2
} ms3d_vertex_ex_t;

// Then comes nNumVertices times ms3d_vertex_ex_t structs (sizeof(ms3d_vertex_ex_t) == 10)

// Then comes the subversion of the joint extra information like color etc.
int subVersion;     // subVersion is = 2, 4 bytes

// ms3d_joint_ex_t for subVersion == 1
typedef struct
{
  float color[3];   // joint color, since subVersion == 1
} ms3d_joint_ex_t;

// Then comes nNumJoints times ms3d_joint_ex_t structs (sizeof(ms3d_joint_ex_t) == 12)

// Then comes the subversion of the model extra information
int subVersion;     // subVersion is = 1, 4 bytes

// ms3d_model_ex_t for subVersion == 1
typedef struct
{
  float jointSize;  // joint size, since subVersion == 1
  int transparencyMode; // 0 = simple, 1 = depth buffered with alpha ref, 2 = depth sorted triangles, since subVersion == 1
  float alphaRef; // alpha reference value for transparencyMode = 1, since subVersion == 1
} ms3d_model_ex_t;

#include <poppack.h>

//
// Mesh Transformation:
//
// 0. Build the transformation matrices from the rotation and position
// 1. Multiply the vertices by the inverse of local reference matrix (lmatrix0)
// 2. then translate the result by (lmatrix0 * keyFramesTrans)
// 3. then multiply the result by (lmatrix0 * keyFramesRot)
//
// For normals skip step 2.
//
//
//
// NOTE:  this file format may change in future versions!
//
//
// - Mete Ciragan
//

```
> 1 votes

# Answer
The .obj is of course the easiest to to parse, but if you need something a little more powerful (with animations) then get the .md2 file format.

link text

If I can dig up some of my code from high school I might be able to find a md2 loader I wrote.
> 1 votes

# Answer
The easiest to load is OBJ (which is human readable), others are horribly complex.
> -1 votes

---
Tags: 3d
---


# Question
Title: What role does developing with events have in games?
Most application development is based around developing with events, but considering the game-loop style of developing games and the (often) need for high performance/throughput, what role does developing using events have and what are the trade-offs? Does the synchronization/locking that is often involved have a greater impact?

For instance: \- How does the network \[layer\] notify the game-loop of data received? \- How does the physics system notify of collisions

I ask, because I can remember a time when game development using events was a strict no-no. Has this changed?

# Answer
Events system are powerful, and can be made very fast.

They also allow you to modulise sections of code in a very loose coupling structure. They let you job batch things and thread off tasks. The work well with multi-core and asynchronous functions.

Physics - Collision Callbacks, Activate or Rest Objects translate well to events. Networking - As much as possible should be an event (voice chat ect.. the exception) Game Logic - Naturally lends itself to an event model Menus & UI - Work brilliant in an event based system

Also many modern consoles, and middle-ware libraries use events.

The renderer and polling of input devices can be a bit confusing to fit in. Especially if you are using motion controls, as events can introduce a noticeable latency and be counter-intuitive to polling format.
> 5 votes

# Answer
I would say that using the main loop style is still recommended: It is fast, it gives you total control over the order of the actions (this is important in a game) and it is harder to make mistakes coding it. However, if the technology you are using allows you to easily use events, it can be really useful for a lot of things. For instance, I use them to notify when and where the enemies die, when the keyboard keys are pressed...

In conclusion: Use the game loop to control the main logic of the game, but have in mind that events can be useful in other situations.
> 4 votes

---
Tags: architecture, events
---


title: OpenGL: Precompute a texture rotation

text:
# Question
Title: OpenGL: Precompute a texture rotation
I'm trying to speed up particles, and one way to do that is by precomputing the texture rotations. What I want to do is load the texture, rotate it and save it to a handle.

How would I go about doing this?

Thanks in advance.

# Answer
> 5 votes
How does that save any significant amount of time? Presuming you handle the rotation in a vertex shader, that only saves time if you're VS bound.

If you are talking about a fixed-function pipeline, it's much cheaper to precompute the rotated edge vectors for the quads you are using. Rotating the texture is then done by the GPU. The only way that might incur additional cost is if you use a software renderer.

# Answer
> 1 votes
You can use a Framebufer Object (FBO) to draw the transformed texture into another texture, then you can use the generated texture and draw it to screen.

---
Tags: opengl, optimization, particles
---


title: MSG::time is later than timeGetTime

text:
# Question
Title: MSG::time is later than timeGetTime
After noticing some timing descrepencies with events in my code, I boiled the problem all the way down to my Windows Message Loop.

Basically, unless I'm doing something strange, I'm experiencing this behaviour:-

```
MSG message;

while (PeekMessage(&message, _applicationWindow.Handle, 0, 0, PM_REMOVE))
{
    int timestamp = timeGetTime();
    bool strange = message.time > timestamp; //strange == true!!!

    TranslateMessage(&message);
    DispatchMessage(&message);
}

```

The only rational conclusion I can draw is that MSG::time uses a different timing mechanism then timeGetTime() and therefore is free to produce differing results. Is this the case or am i missing something fundamental?

# Answer
Yes, it does use a different source. If you look at the Windows documentation you will see that you should use GetTickCount/GetTickCount64 to compare against the message time.

If you need any kind of precision, I suggest not relying on the message time - GetTickCount has *horrible* resolution. (10-16ms)
> 6 votes

# Answer
I can see two reasons: Either they use different ways of measuring time (as you suggest), or, you have a AMD chip. These can in some cases have timing bugs that you need to either patch through a driver (I think) or handle in your application logic. Google for "AMD timing" and you will probably find something that might be of use.
> 0 votes

---
Tags: c++, windows
---


title: How does Megatexture work?

text:
# Question
Title: How does Megatexture work?
I've been thinking about developing a small engine not only to develop small experimental games, but also to serve as a base to test various rendering techniques and things like that. Right now I've been thinking a lot about how to handle textures and stumbled on megatexture, but this is something that is a bit puzzling. There is a lot of talk of it being better than the traditional approach to having a bunch of textures around and loading them as needed, but how does megatexture avoid this, I've read around that they use streaming and you can just stream bits and pieces of it as opposed to loading each texture individually, but how does that offer better performance, and isn't that just another form of tilling?

How do we sample such a texture when in a shader, do we stream part of it into memory then work on it. I've seen the latest videos of Rage and the texture do look great, but is that just the result of great artists or does the tech come into play.

To sum up, how does it work, why is it great and how could I do something similar.

# Answer
The basic idea of mega textures is the use of a texture atlas where you pack all your different textures into a big one and use UVs to index into this image. Good heuristics are needed to know what part of the texture you need to stream in from disk based on what you see on screen. The upside is that you can have completely unique textures throughout the game world and only keep the visible data in RAM. A good streaming and caching system is needed to make this affordable.

I recommend going through the material on this page for more detailed info on one approach: http://silverspaceship.com/src/svt/
> 16 votes

# Answer
Check up clipmapping for the pre-existing SGI hardware implementation.

More recently Megatexture is being used as a pr name for Sparse Virtual Texturing(SVT)

SVT render a small resolution camera view, noting which texture and mipmap will be needed. Then a CPU routine issues loads to the disk system to bring those texture/mip chunk into memory (if not in memory) and then the loaded texture chunk is placed into a section of a large texture atlas (usually in chunks of say 128x128)

As texture chunks are brought in, a redirection texture (a virtual page map) is updated which take a models required textures and redirects it to the particular part of the large texture where its actually stored.
> 5 votes

# Answer
You can think of Megatexture as a sort "streaming" texture. One massive, fully detailed texture image (put simply) that is read in as sections of it are needed to be displayed. I'm sure there's a hell of a lot more to it than that though, such as LOD/mipmapping, loading and resource management among the obvious things.

Wikipedia has an article on it.
> 1 votes

---
Tags: textures
---


title: Character Animation Architecture

text:
# Question
Title: Character Animation Architecture
Can anyone explain the general architecture typically used for 3D character animation?

Are movements like walking and falling scripted against the skelton, and simply executed on input? If so, is the scripting typically actual script or hard code?

What are common pitfalls or flaws in character animation engines?

# Answer
Yep, an animator creates each animation (falling, walking, idle) in a specialized program, as well as intermediary states between those (idle to combat ready, starting to walk, stopping). A finite state machine is used to describe what animation states can lead to which seamlessly - this can be implemented by the game engine or not.

Modern engines can interpolate between two animations, so there's no need for the intermediary animations and pretty much any animation can lead to any other.

Common problems with this method: Animations need to be tailored to each model (or fatter models will intersect themselves when crossing their arms) and don´t adapt themselves to surrounding terrain (walking up a ramp uses the same animation as walking down one)
> 6 votes

# Answer
Normally when I approach character design I work on the character model first, once I have a good starting point I start to add "bones" and "weighting" for the "skin" of the model.

You mentioned a skeleton, and in this regards I believe that these are the same. The bones act as the handles that you grab to control shaping the model. I start from the head to the center of the neck, two out to the shoulders and one down to the torso.

From the shoulders I go out to the elbow and then to the wrist/hand (the hands can be as simple as one bone or as complicated as three in the center of the hand and three for each finger, two for the thumb - but I rarely go that deep).

From the torso, I do two for the ridged hip and then down to the knee, to the ankle and one for the foot (with shoe or simple, as the hands this can become as complicated as you'd like).

The less bones you have to place in your character the less you have to deal with in terms of data mechanics/control points. If you have a lot of bones then it will take more time to map the weighting for the surface material — add as you need to, but keep it simple.

Depending on what you're doing with the model depends on the next steps. If you're rendering out the animation sequences you can build out a series of animation types. One file per animation from a normalized starting point. Then build out, walking, running, jumping and other animation sequences. Render out and then create keyframes for moving from one point to another.

If you're actually building a model to us in a 3D application then the model must be adjusted within the code. Create a series of animation sequences, much like you would with keyframing, but shorter/in-between steps, and then "tween" the sequences. This will allow you to start a walking sequence and add a look left to the "animation stack" at the same time without having to write a "walk and look left" sequence.

Creating animation mix-ins is handled in code and again, this is another good reason to have as little bones as possible in your model.

You can also create/use motion capture models and attach the model to the keyframe sequence of the bones of your model. This allows you to use the same "action" on various models (and associated bone rigging).

And yes, the standard way (in the past) was to keyframe each animation block (and then render it out) and then change from one state to the next, much like Srekel's suggestion. This goes back to the days of sprite animation where keyframes were used in story boards and the animators just had to fill in the "tweens" or frames in between the two keyframes. As mentioned this is older and not as flexible as current systems allow.

Think of a 3D model like an avatar in World of Warcraft or the like. In the selection screen the model stands there, and at times shifts weight from one foot to the other, or will blink or look in a direction. These are all small fragments of motion (animation blocks) that are just added in realtime so that the character has a more dynamic appearance and not static like those old Mortal Combat games. (^\_^)

I'll see if I can find a couple of links for you and try to remember to post them here for you.

Also, I'm not an expert in this field but I do like to play in it. So, take my comments with a grain, dash, spoon or pillar of salt and good luck in your animating endevors!

Cheers, Kevin
> 6 votes

# Answer
There's quite a bit of information about this in Game Engine Architecture ( http://www.gameenginebook.com/ ).

In general you often have a state machine that specifies which animations can transition into which, and how that transition is done. For special cases like the main character, you also often need to hook the transitions into custom hard coded functions for doing various things - there's generally more logic to the main character player mechanics than to NPCs.
> 3 votes

---
Tags: 3d, character, animation
---


# Question
Title: API agnostic bridges (ie. OpenGL/D3D/Whatever). Do you use them, how you make them. Pro's and Con's
You are making a 3d engine. You want best of multiplatform worlds. Suddenly you realize that if you want to use Direct3D on Windows machines and OpenGL on OSX/Linux, you'll have to sacrifice supported features of both to least common denominator.

Some may use OpenGL across three OS', since it appears to be least common denominator by itself. All is good. Then, you have to port your graphics API backend to Nintendo's GX, you also have to make a PS3 and Xbox360 path.

What do you do? Do you design your own API which is least common denominator in itself and write backend implementations for it for each platform or do you write for each platform it's own branch?

If you opt to design your own API, do you use bridge pattern or your own voodoo? Where does madness stop where you realize everything and kitchen sink approach must stop and you basically have separate engine for each platform as a branch. Or you stick to everything and kitchen sink and keep platform specifics in backend module specializations for each platform.

# Answer
> 10 votes
I'm not a fan of the least-common denominator approach. If you do that, you may end up with crippled features and poor performance.

Instead, what I've done in the past, is to provide slightly higher level functionality in a library. That library is (mostly) API agnostic and can be used anywhere, but the implementation of the library is completely different for different platforms/graphics backends. So for example, instead of having a SetStateX() function, you have higher functions like RenderMesh(), or CreateRenderTarget().

It will be more work than a really thin layer whenever you move to a new platform, but it will be completely worth it because you'll be able to implement things in the optimal way for that platform, and you'll be able to take advantage of native, unique features.

One more thing: Don't be afraid of slightly breaking the encapsulation. There's nothing more frustrating that knowing you're in a platform with certain capabilities and not being able to use them. Leaving a backdoor of some kind so higher-level code can take advantage of the platform is very useful (for example, being able to retrieve the D3D device or OpenGL context).

# Answer
> 6 votes
All I can say is take a look at Ogre3D. It's written in C++, Open source (MIT License now) and runs on every major platform out of the box. It abstracts out the rendering api and can switch from using DirectX to OpenGL with just a couple of settings. However, I do not know enough about the differences between feature sets of DirectX and OpenGL to say that it does or does not support a specific feature.

Torchlight by Runic Games was written using Ogre and I've played that on Mac and PC and it runs very well on both.

# Answer
> 1 votes
I haven't done this for graphics, but I did create a cross-platform audio toolkit (PC/XBOX/PS2). We went the route of creating our own API with a least-common-denominator capability as well as optional platform-specific capabilities. Here are some lessons learned:

The key is to define a processing path that encapsulates the core capabilities of each platform, and allows growth. In order to do this, you need to really understand each platform's low level API so that you can identify the right abstractions. Make sure the chain works for the least capable platform, while providing access to the most capable patform's advanced features. Do the work to get this right and you will save a lot of effort later.

For audio, the chain was something like `SoundSources -> [Decoders] -> Buffers -> [3D Positioner] ->[Effects] -> Players`.

For graphics, it may be `Model -> Shapes -> Positioner -> Texturer -> [Lighting] -> [Particle Effects] -> Renderer`. *(This is probably a completely wrong set, I'm not a graphics guy).*

Write a front-end API which handles your core objects, and a platform-specific back end which maps the API to the low-level capabilities. Provide a best-effort for each capability. For instance, on the PC and XBOX the 3D audio positioning was done using the HRTF capabilities of the sound chips, while PS2 used a simple pan and fade. A graphics engine might do something similar with lighting.

Implement as much of the front end as possible with platform neutral code. The code to attatch a reverb object to a sound object, or a texture asset to a shape object should be completely common, as should the code to iterate through and process active objects. On the other hand, the low level objects can be completely platform specific except for the common interface.

Make sure the API, or configuration files, allow the user to specify platform-specific options. We tried to avoid pushing platform-specific code to the game level by keeping it in configuration files: One platform's config file can specify "effect: SuperDuperParticleGenerator" while another says "effect: SoftGlow"

Definitely develop the platforms in parallel. Make sure that the platform specific interfaces are well defined and testable on their own. This prevents a lot of the "is it the platform level or the API level?" issues when debugging.

# Answer
> 1 votes
I'm writing an open source game engine called YoghurtGum for mobile platforms (Windows Mobile, Android). This was one of my big big problems. First I solved it like this:

```
class RenderMethod
{

public:

  virtual bool Init();
  virtual bool Tick();
  virtual bool Render();

  virtual void* GetSomeData();

}

```

Did you spot the `void*`? That's because `RenderMethodDirectDraw` returns a DirectDraw surface while `RenderMethodDirect3D` returns a vertex pool. Everything else was split as well. I had a `Sprite` class that had either a `SpriteDirectDraw` pointer or a `SpriteDirect3D` pointer. It kind of sucked.

So lately, I've been rewriting things a lot. What I have now is a `RenderMethodDirectDraw.dll` and a `RenderMethodDirect3D.dll`. You can, in fact, try to use Direct3D, fail, and use DirectDraw instead. That's because the API remains the same.

If you want to create a sprite, you don't do it directly but through a factory. The factory then calls the correct function in the DLL and converts it into a parent.

So, this is in the `RenderMethod` API:

```
virtual Sprite* CreateSprite(const char* a_Name) = 0;

```

And this is the definition in `RenderMethodDirectDraw`:

```
Sprite* RenderMethodDirectDraw::CreateSprite(const char* a_Name)
{
    bool found = false;
    uint32 i;
    for (i = 0; i < m_SpriteDataFilled; i++)
    {
        if (!strcmp(m_SpriteData[i].name, a_Name))
        {
            found = true;
            break;
        }
    }

    if (!found)
    {
        ERROR_EXPLAIN("Could not find sprite named '%s'", a_Name);
        return NULL;
    }

    if (m_SpriteList[m_SpriteTotal]) { delete m_SpriteList[m_SpriteTotal]; }
    m_SpriteList[m_SpriteTotal] = new SpriteDirectDraw();

    ((SpriteDirectDraw*)m_SpriteList[m_SpriteTotal])->SetData(&m_SpriteData[i]);

    return (m_SpriteList[m_SpriteTotal++]);
}

```

I hope this makes sense. :)

P.S. I would loved to have used STL for this, but there's no support on Android. :(

Basically:

* Keep every render in its own context. Either a DLL, or a static library or just a bunch of headers. As long as you have a RenderMethodX, SpriteX and StuffX you'r golden.
* Steal as much as you can from the Ogre source.

EDIT: Yes it does make sense to have virtual interfaces like this. If your first attempt fails, you can try another render method. This way you can keep all your code render method agnostic.

# Answer
> 0 votes
I like to use SDL for this. It's got renderer backends for D3D, OpenGl, OpenGL ES, and a handful of other platform-specific backends, and it's available for all sorts of different platforms, and currently under active development, with bindings to many different languages available.

It abstracts away the different renderer concepts and makes creating video (as well as handling sound and input and a few other things) available in a simple, cross-platform API. And it was designed by Sam Lantinga, one of the lead devs at Blizzard, specifically for making porting games and creating cross-platform games easier, so you know you're dealing with a high-quality library.

---
Tags: opengl, directx, patterns
---


# Question
Title: What makes aiming on a PC first person shooter feel good?
I liked this question: What makes aiming in a console first person shooter feel good?

So here it is for PC (and its not a dupe because a mouse is hugely different from an analog stick)

You've probably noticed some games "feel better" than others when it comes to aiming using the mouse. Why is that?

Some of the best engines are the original Half Life 1 engine and the Quake 3 engine.

What is the biggest problem? Laggy input response?

# Answer
> 2 votes
The biggest effect on the PC will be input latency and framerate.

Here is an article on the subject

# Answer
> 2 votes
Field of view (FOV) plays a big part in game feel for first person shooters on all platforms. Standard horizontal FOV in first person shooters tend to range between 90 degrees to 120 degrees. However, PC and console players sit at different distances from their screens. A 90 degree FOV may be fine for a 30" screen 5 feet away from a console player, but may seem horribly cramped on a 24" screen 2 feet away from a PC player. Unless they have multiple monitors or are sitting really close to the screen, players may find FOV more than 120 degrees to be nauseating over time.

A larger FOV gives the player more peripheral vision, and thus greater situational awareness of objects or characters around them. A smaller FOV makes objects seem closer, because they're rendered larger on screen. Character speed also feels different at different FOVs: moving forward seems faster with larger FOVs, and moving side-by-side seems faster with smaller FOVs, even if all the speeds are actually the same.

Note that horizontal and vertical FOV are rarely the same number (unless you have a perfectly square or circular viewport) and both PC and console games need to accommodate players with screens of different aspect ratios, and thus different horizontal and vertical FOV settings.

---
Tags: pc, first-person-shooter, aiming
---


# Question
Title: Player sprite animation in 2D platform game
It's pretty easy to get animations rolling from a sprite sheet. Though which ways there are on combining the animations with player dynamics and motion?

I've figured there's two starting points anyway:

* Player animation contains motion (the animation slab defines how the sprite moves)
* Player animation does not contain motion

Simple state machine might do the stuff, but are there alternatives? How would you write the state machine itself for doing it?

I'm writing a small hack&slash&jump platform game in html5. The player should stay in place when he strikes a sword, perhaps even move a bit (one can accomplish it through a hack), but otherwise move pretty much without limits. I've got couple frames and I'd like it all to mesh together well.

# Answer
I prefer to keep animation and motion separate, since it provides for more flexibility.

In my game engine I have a concept called an Action Matrix, which is basically an array of arrays of integers, which are index references into the sprite sheet. Each sub-array is a list of numbers which define the frames of an animation, and each character is assigned an action matrix.

The movement code is hard-wired to use the first four actions for the animation to be played while the character is moving, (in the four cardinal directions,) and beyond that you can create custom animations which can be invoked by playing a different action from the action matrix. These can be used with or without also moving the sprite's position, which is controlled by a separate command.

Also, by playing one of the first four actions in a loop with no movement, you can get a character who seems to be walking in place, or a flying/floating vehicle that just hovers there, or various other other versions of an "idle" animation.
> 4 votes

# Answer
I like the idea of mimicking the way it is done in 3d games; models, skeletons, and skins. I know of at least one game that made effective use of this idea.

Mommy's Best Games: Weapon of Choice

They released a post mortem afterward and where very happy with their animation editor, Mommy's Best Object Editor.

You'll have to read the one page description to get the complete understanding, but basically instead of models there are sprites. And the skeletons are only 2D, basically nodes and joints. The animation editor is used to get good looking animations, then the engine tweeks the skeletal animation for added smoothness. Like making sure a monster's feet make good contact wit the ground when it's slanted or uneven.
> 3 votes

# Answer
It's a trade-off. If you encode motion into the anim you can ensure that there's no moonwalking going on, however, by preventing moonwalking you also take away the ability to tweak speeds :o\

I'd definitely prefer having them decoupled so you can change speeds when desired. To prevent moonwalking - defer animation until your gameplay has settled down. Blocks are extremely capable of jumping, running and shooting.
> 1 votes

---
Tags: architecture, sprites, animation
---


# Question
Title: For 2D games, is there any reason NOT to use a 3D API like Direct3D or OpenGL?
I've been out of hobby Game Development for quite a while now. Back when I did it, most people used Direct Draw to create 2D games. By the time I stopped people were saying OpenGL or Direct3D with an orthogonal projection is just the way to go.

I'm thinking about getting back into creating 2D games, in particular on mobile phone but maybe on the XNA platform as well. To make something using OpenGL I'd have a (hopefullly) small learning curve to acclimate myself to 3D development.

Is there any reason to skip that and instead work with a 2D framework where I just have a Width x Height frame buffer I need to fill with pixels?

# Answer
> 20 votes
You should definitely be using something that uses a 3D renderer on the backend. But in your higher level code, you shouldn't even see the Z axis. All of that should be abstracted away at the lower levels. If you are manipulating pixels directly, you are probably doing something wrong.

For my own games, I built up a set of classes for dealing with 2D objects. My game logic was only dealing with x and y coordinates. My classes also handled things like rotation, scaling, blend modes, etc, etc.

Of course, there are also existing 2D libraries that you can use as well -- Cocos2D is a popular one on the iPhone. Most, if not all, of these libraries will be built upon the lower level 3D APIs so that they benefit from the acceleration available.

# Answer
> 9 votes
There is a reason to don't use 3D API.

Only computers in NA, North-west EU and Japan support them...

I live in Brazil for example, my sister computer is new, has a multi-core processor, several GB ram, and yet it does not run OpenGL games.

I for example can only play Dwarf Fortress (use OpenGL to render ASCII graphics) on my own computer, on any other computer I find it runs crawling slow.

And this is not a issue only with Brazil, I asked people around, and it is common in several places of the world... The population that actually own OpenGL or Direct3D compatible cards is a minority...

Only that this minority get more attention from companies...

But if you are targeting only these "traditional" markets (NA, Northwest EU, JP), then go for it!

EDIT for those downvoting: Obviously you disagree, so, do you have PROOF that NOONE ships anymore computers with crappy VIA or SIS chips (or even other unknown or worse manufacturers) with none or only OpenGL 1.0 support?

I have TWO machines like that in my house, and they are new (both have more than one core, both have 2GB ram, both have clock frequency above 2GHz...)

My university have 200 machines like that, even some Dell-built ones.

It is plainly simple, GPUs are expensive (even crappy Intel ones), and in poor markets, it is a luxury, people buying machines to run MS Word and read e-mails are not going to buy a machine with a decent graphic chip when they can buy one that is 50 USD cheaper, specially when 50 USD is what most people have to buy food for a entire month.

PLEASE, don't come here saying that I am saying BS, if you never visited a third-world country, and also, don't say that third-world country people don't play games, they do, a lot, Osmos developer post about the Linux version launch of their, pointed that lots of incoming traffic (actually, most of it) was from Russia, plainly because those people are usually ignored.

Here in Brazil, the most popular game is Counter-Strike, running in Software mode... Some Lan-Houses have only 10% of the machines with GPU, even big-ass ones with 200 or even 300 stations...

I should not have posted on this, I knew that it would attract down-votes, I got free loss of points for posting this, every time I explain why my other game uses Allegro 4.4 instead of 5.0 because 5.0 does not support Direct Draw or software mode I get lots of flak from lots of people saying that I am a sort of liar or that I am stupid for saying this truth about the actual availability of OpenGL acceleration.

EDIT 2: To be able to play and develop games that have OpenGL, I had to beg for my parents and other people to buy me a GeForce 8600 (that was the cheapest card that I found that still could ran Mass Effect 1 and other UT3-engine games), they bought me one, but now I am several years without ever getting other gifts again, not even birthday presents, because of how expensive it was, and I hope this card work for more 3 or 4 years...

EDIT 3:
A pratical example: Eletronic Arts made a new client for Ultima Online that uses 3D acceleration for its 2D graphics... Result: Lots of players complaining of ridicously low framerates, and EA backing down in their decision to enforce the use of the new client (now it is allowed to remain using the old one)

EDIT 4 in 2015: This reply will be left here mostly as historical artifact, currently the amount of computers with extremely crappy chips is low even in third world countries, they still do exist, specially in office-aimed computers, but they are not that common anymore, I don't think it is worth working with Software-mode APIs anymore, OpenGL-based APIs are the way to go now.

# Answer
> 3 votes
No, there isn't. You'll get better effects and faster rendering by using a 3d renderer. For example, here is a 2d game I made a few weeks ago (in one weekend) - the orb effects lean heavily on 3d shaders, even though in many ways they're 2d effects. Similarly, I made extensive use of the available rendering technology for this game \- there's three or four different pixel shader effects going on there, all of which let me develop faster and make it prettier.

Embrace the 3d and love it, but love it with one fewer axis.

# Answer
> 2 votes
3D APIs are generally the way to go. Today's GPUs are designed to render 3D graphics, so you're guaranteed pretty solid performance. And as ZorbaTHut said, going the 3D route lets you take advantage of things like pixel shaders.

There really aren't that many 2D APIs out there anymore. DirectDraw has been deprecated, and most of the 2D/vector-based libraries out there use OpenGL or Direct3D to perform their rendering anyway. Even modern UI toolkits are leveraging 3D APIs to do their rendering and compositing. Take WPF (Microsoft's latest UI framework) for example: it uses Direct3D for rendering.

# Answer
> 2 votes
There are still a surprising number of really old machines out there with crappy/non-existent 3d acceleration and drivers that have never been updated, such that using DirectDraw is still going to be way faster than OpenGL or D3D. I experienced this while working on a 2d multiplayer game that is about 10 years old now when I tried to write a new rendering backend in OpenGL to support other platforms. A lot of players reported that the OpenGL mode was unplayable due to low frame rates. I would also agree with the Brazilian poster that this is more common outside of the US and Europe, but it's still true in those places as well.

If you're targeting mobile phones or XNA, then definitely use 3D. But if you want to make a game that runs on any PC, anywhere, I'd say stick with DDraw.

# Answer
> 1 votes
The only thing I can think of is that using a 3D API over a 2D one adds some base complexity. In OpenGL at least, you have to load and manage textures, and when you draw them you need to get the geometry right. A wrapper layer solves these issues.

That said, using a 3D graphics back-end seems to have more upsides than downsides, so if you ask me, it's well worth the effort.

# Answer
> 1 votes
If your game is simple enough, and you want the game to run well on low-end machines, particularly netbooks and older laptops (with no 3D acceleration, or very minimal - older Intel integrated graphics, etc), it's still worth considering a pure 2D framebuffer approach

If you're happy for the game to require at least a low-end ATi/NVidia card/chip, then going using a 3D API will allow you to do a lot of cool stuff (alpha blending, scaling/rotation, etc) that would be tricky to do well/efficiently in a pure software renderer.

Also, be aware that a few things that are very simple in 'pure 2D' become more interesting when 3D hardware (and bilinear filtering/alpha blending) is involved. Understand the concept of premultiplied alpha. And also think about, for example, how you'd handle the seams between tiles in a 2D tilemap if you wanted a zoomable/rotatable view.

Also remember that fillrate is limited. And it's surprisingly easy to reach those limits in 2D. You might not have many polygons, but if you want lots of alpha-blended parallax layers, or particles, or post effects - you can quite easily end up filling as many pixels as a fairly high-end 3D game.

But generally, 3D hardware is awesome, and additive blending is your friend :)

---
Tags: 2d, opengl, directx
---


title: Good 3D Math Theory Books

text:
# Question
Title: Good 3D Math Theory Books
I've been developing a modification for the Source engine for well over a year, but am now facing some troubles with the weapons, gamemovement (player physics) and player feedback from explosives.

This is all because of my weakness in mathematics!!!

What books, tutorials or any other various texts could you recommend (that have helped you).

# Answer
> 10 votes
I faced the same issue some time ago and found those two books which have really good reviews:

The first one seems to be easier to understand for math dummies like myself. I already bought that one, alas I didn't have the time to read it up till now.

# Answer
> 5 votes
You're in luck! I just discovered some Linear Algebra tutorials on Wolfire's blog that I felt were really good. The guy writing the tutorials, David, has such a killer way to explain the stuff. It's extremely handy for those that are weak at math since it is showing more practical application than theory (which is what someone weak could use)

* Part 1 \- Vectors addition, subtraction, scalar-vector multiplication
* Part 2 \- Vectors length, distance, normalization, dot product, cross product
* Part 3 \- Basis vectors, matrices, 3d matricies

Be sure to add this to your RSS reader. He is continually writing new posts. Don't forget to **read the comments**!

# Answer
> 3 votes
I've found "Mathematics for 3D Game Programming and Computer Graphics" to be an excellent resource. http://www.amazon.com/Mathematics-Programming-Computer-Graphics-Development/dp/1584502770/ref=sr\_1\_1?ie=UTF8&s=books&qid=1279832969&sr=8-1

# Answer
> 2 votes
Another good resource in addition to the books listed here is this Linear Algebra course at MIT Open CourseWare.

# Answer
> 0 votes
I was just about to pick up "Tricks of the 3D Game Programming Gurus" (volume II). It seems really good on the 3d theory side and keeps everything simple from what I saw. I tried to pick up Direct3D/OpenGL alone but I'm like you - I had no idea.

---
Tags: 3d, books, mathematics
---


title: Mixing 3D and 2D content on the iPhone?

text:
# Question
Title: Mixing 3D and 2D content on the iPhone?
I am at the design phase of a board game on the iPhone and am considering a couple of options for rendering the view:

* Quartz to render top down views of the board with core animation to do the transitions to close ups etc. Using a 3D library (or GL directly) to render dice rolls on top of the 2D view.
* Full 3D interface to render the board and do the transitions (something like the Monopoly app on the iPhone).

Keeping most of the game in 2D simplifies the implementation and the artwork, but I wonder if the overall finish will suffer. Is it practical to render 3D views (for the dice rolls) on top of a Quartz 2D app?

Should I just bite the bullet and go 3D?

# Answer
> 5 votes
You can render OpenGL views on top anything on the iPhone with no performance loss. However, if you're thinking of just doing the dice on top of other 2D graphics, that will be more costly (you'll have to render them to texture and apply an alpha channel).

When mixing 2D and 3D on the iPhone, I recommend you think of it mostly in terms of the 3D in the background, and some 2D elements on top.

Check out my GDC presentation for all the different cases and details on how to mix UIKit and OpenGL, and make sure to download the sample source code as well.

---
Tags: 2d, 3d, iphone
---


# Question
Title: What makes aiming in a console first person shooter feel good?
I think it's pretty much universally agreed that simply mapping the analog stick to rotational speed of the character is not good enough to make console first person shooter feel good.

So what are some input paradigms that make a modern FPS on the console work well?

# Answer
> 20 votes
I went to a GDC session this year presented by the guys at sucker punch, discussing how they handled assisted aim and movement for inFamous. My understanding is that Halo uses a very similar system for assisted aiming, and here's the basics:

* When you hit a button to fire, the shot should always go directly where the reticle is pointing. Otherwise, players would notice any artificial "snapping" and feel like they are not in control. But, the analog stick of a modern console is NOT accurate enough to be depended on, no matter what the skill of the player is. So, you need to do the assist before the point of pressing fire.
* The game has an idea of plausible targets for you to be adjusting your reticle towards, and can weight them appropriately based on your suitability of target as well as the direction you are moving your analog stick. Then when you push a stick towards a valid target it will adjust the game's perceived input to point towards the likely target. Vitally, these adjustments never change the input past what would be physically possible on the controller.
* When passing directly over a target it slows down the reticle speed, giving you more time to accurately press a shot. Also it keeps track of your recent movement and button presses, and if the reticle EVER passed over the target and it was within a certain time delta it registers a hit on the target, as you could have theoretically pressed the button at that point and the controller missed it.
* Finally if there's no valid target around, the reticle controls completely manually, allowing the player full control.

There are two things that make aiming "feel good": You need to feel like you're in control, and you need to feel like the game is not lying to you. Adjusting the game's perception of input direction and button timing within tolerances is a great way to do this, as it NEVER results in an impossible situation where the auto aiming is actually performing better than a theoretically perfect controller. If you try to solve it ad-hoc after the input processing is complete you're going to end up with some sketchy situations where the player feels like they have lost control.

# Answer
> 10 votes
There are good answers here. I had to figure it out for myself on the project I'm on, but came to the same conclusions as the Sucker Punch guys (and I had thought I came up with something novel. Baww :( ).

I find it useful to consider your entire first person 360x180 degree "panorama" as an "acceleration field". All valid targets create gravity wells which bend the player's input (only subtley) such that macro motion (turning to face targets) feels as though it's a "greased" path. However, this is not affecting the crosshair all of the time - only when the player's turn delta is pointed with the slope of the well (as it were). That's really key though - you're only giving this extra turn speed when the player is turning roughly toward a target. That's about the only inference you can make from the player's input.

Much more, and you get too much of a noticeable "ouija effect". You want the exact opposite of ouija: Where a ouija board is moving unintelligently due to a user, without their conscious knowledge, you want a player's crosshair to move in an intelligent way without the user realizing that it's NOT purely their input. It really is a bit of a magic trick.

Use the dot product of the player's pitch/yaw turning delta vs. the pitch/yaw delta from the crosshair to each target. Clamp the value between 0 and max speed (so you ignore the input while pushing away from the target), then use a function of distance as a falloff modifier.

I found that increasing this "macro movement" bonus when the crosshair vs. target angular delta is large (i.e. when an enemy is behind you) really helps with the classic console controller problem of not being able to turn-to-face quick enough. In terms of "targetting choices", if you're being attacked from behind, and there's no targets infront of you, that panorama ahead of you is "dead space", and you might as well give the player the ability to fly across it at great speed with their cursor. And if there ARE targets ahead, well, they're probably higher in the player's mind and due to dampening/sticky aim, aren't unduely affected by the weak macro force.

There's not much need for you to dampen sensitivity when the player tries to turn *away* from an object (this will result in a feeling of trying to "escape" a target's orbit). Dampening is used more for precision aiming, and also to stop players' aim overshooting when moving from macro to micro precision - It's the darnest thing: players (especially novices) have a tendancy to only use the extremes of a stick's deflection, so you have to do a lot of finessing for them.

Sticky aim is a relative movement compensator. Watch the difference between the angle to your target (from the camera, not from the entity origin), this frame, and last frame. See how closely you are aiming to the target. To avoid the ouija effect when there is no user input, check both sticks' deflection: See if you have physically moved (left stick actuation) OR if there is active aiming "with" the direction of the target. Add the yaw/pitch delta step * aim closeness * Max( move.length , aim.length ) for rudimentary sticky aim.

Where the issue of target confusion comes in (i.e. a target strafes across your view while you were aiming at something behind, "stealing" your focus), simply keep track of your targets, and "heat" a single one while it is being actively aimed at. Then, multiply the dampening and sticky components by this heat parameter so that unheated targets get ignored. If the player WANTS the help on that other target, they'll manually aim toward it, and very quickly, that becomes the most prominently heated target while the previous one is forgotten.

We also create "phantom" aim assitance targets to help you turn away from uninteresting things (i.e. facing a wall - no need to hang around looking at a close up blank surface if it's not usefully interactive), but it's probably more than I can talk about - you can apply this stuff to anything that's interesting for the player to point at, be it explosive barrels, interactive objects (bioshock uses dampening when aiming over interactable objects at close range... but doesn't do sticky aim on them, I don't think). Once you realize that this is all just to compliment the core concept of aiming, you realize it's not just about aiming shots, but a general useability improvement which feeds into any mechanics reliant on aiming. And in an FPS, really, movement and aiming are the fundamental core concepts you need to nail before developing onward.

The improtant thing with all this is tuning. Takes a long time to just get right, and to deal with target interference, and issues with targets being so close range that their "targetting zones" swamp the player's panorama, slowing 60 degrees of rotation down to a crawl.

Oh man, I should get to bed. Sorry if some of the maths is not to clear. It's really late, but I was excited reading this post.

# Answer
> 3 votes
For input to feel good on consoles you will want to have some processing done to it.

First we converted the linear input that comes from the analogue sticks into a curve that gives us more sensitivity around the stick center and less sensitivity at the borders. This can be done with small tools that help you create and visualize these curves and spit out code. (http://www.arachnoid.com/polysolve/)

As a second step we implemented some kind of accelleration. It kicks in after a short amount of time when the stick input is at least 97%, and ramps up the camera rotation over time. We handled the X and Y axis independently. That allows you to somehow artificially enhance the stick input range. The first 97% can be used for relatively fine adjustments, but due to acceleration you can have fast movements too.

If you have different camera FOVs (e.g. when aiming/ zooming) then there needs to be a factor that adjusts the cam rotation speed by the FOV currently in use.

Some other nifty tricks that make the players life easier is "auto centering". This levels the camera pitch slowly back to the horizon when no input is given. It helps to keep oriented.

Another thing to take care of on consoles is the dead zone. When a controller gets older the analogue sticks start to loose precision and tend to give "false" input. To prevent this you have to disregard the first few pct (up to 20%) of stick input.

We also had done some experiments with friction based aiming help as mentioned before (accel input when moving towards enemy on screen, slow down input when moving away) but we had the feeling that this is very noticable to the player. Also the downside is that you dont have smooth cam movement anymore when there is a row of enemies. We opted for a "magnetic bullet" effect, where the bullets itself tend to gravitate towards the enemy within a certain range. However you have to be careful here too.

# Answer
> 0 votes
For console games, you will have to work with an analog stick. While analog sticks feels intuitive for 3D games, it's horrible during intense moments where you need to actually aim. The best solution is to make the stick become accurate during these moments.

Here's a simple solution: As the crosshair moves closer to an enemy, the sensitivity goes down. This would allow the player be more accurate with his shots.

You can also implement a "sticky aim". This becomes very satisfying if there are multiple enemies and the player needs to kill the one immediately in front of them.

# Answer
> 0 votes
I personally like the "lock on" paradigm for console shooters. I.e. hold a button to lock onto an enemy roughly in front of you (press multiple times to cycle through multiple enemies) and then your aim just automatically follows them. The first FPS to use it that I can think of (I'm sure there were others before it) was Metroid Prime on GC. Makes the sluggish inaccuracy of the analogue stick not matter. ...not sure how it would translate to multi-player though.

While we're on Metroid Prime, I also liked the technique they used for platformy bits where the view would automatically angle down slightly when you jumped. It was subtle, but it made the controls feel much more natural.

---
Tags: console, first-person-shooter, aiming
---


title: 3d level creation for small teams

text:
# Question
Title: 3d level creation for small teams
What sort of tools and techniques are available out there for 3D level creation?

In particular for small teams where you might not have the time and resources to make your level creation tools from scratch. I know you could use Blender or any other 3D modeling app for the geometry, but how do you manage the necessary metadata, triggers, game objects, etc?

# Answer
One way to do this is to **add "markers" in the scene geometry file itself**. You would use a specific naming convention on these markers (which are just pieces of geometry) to represent various things.

For example:

* Add a sphere and give it the name "player\_spawn\_0" to represent the starting location of the player. Perhaps more helpful would be to add the player's model itself to mark the player spawn. What you use doesn't matter, as we'll see shortly.
* When you load in your game, you would then check for these markers in the model file itself, note their locations, name, properties, etc then.
* Once loaded, delete them from the model so they don't draw.

Most modeling packages allow you to add data to objects (color, texture, etc) so you can use these properties to your own properties. All of the major modeling packages also support you adding arbitrary data to objects so you wouldn't have to stretch yourself trying to finding ways to encode data on your objects. You also get the benefit of editing right on top of your level instead of making little adjustments to marker positions until they are in the right spot.

Other than that, there are a number of **free or cheap level editors** that output to a neutral scene file, like http://www.getic.net/

Exploiting your modeling software is probably the easiest way other than building your own editor however as you don't have to add another set of tools and file formats to your pipeline.
> 8 votes

---
Tags: 3d, tools, levels
---


# Question
Title: Rotate around a 3d Object (Software Renderer)
I have a simple 3d software renderer (SDL / C++) which can load a 3ds Model and render it (shaded) and rotate it around X Y Z - Axis. Now I would like to rotate / move around the object, meaning, the object itself stands still, and everything in the scene is displayed from the angle of the view. Is that what a camera in 3d engines does, and how would I implement something like this ?

(No OpenGL / DirectX is used, just plain software)

# Answer
> 1 votes
EDIT: What the hell, I completely misinterpreted the question! Saved for posterity (I thought the question was "how do I get an object to spin around another object):

What you need to learn about is something called a scene graph. The basic principle is very simple:

Suppose you have a 2D field. You have an X-axis and a Y-axis. Define a cube with four coordinates:

Now we rotate it 45 degrees. The blue box is the result:

Now we translate it to the left and up:

Let's do this in reverse. First we translate and then we rotate:

The result is completely different!

What you want to do in a scene graph is multiply a node's matrix with its parent. You want to translate the coordinates of a node from local space (hand) to world space (hand -\> arm -\> body -\> world).

Effectively, you want to have a top node (your root node) with a bunch of children. When you want to render, you start at the top node and tell its children to render with the top matrix:

```
void SceneNode::Render(Mat4x4* a_Matrix)
{
    Mat4x4 final = a_Matrix * m_Matrix;

    if (m_Model)
    {
        m_Model->Render(final);
    }

    if (m_Children.size() > 0)
    {
        for (std::vector<SceneNode*>::iterator i = m_Children.begin(); i != m_Children.end(); ++i)
        {
            (*i)->Render(&final);
        }
    }
}

```

I hope this answers your question. :)

EDIT: After you've done this, you now have both the object and the camera in world space. The main thing about rasterization is that you have to transform the world coordinates into screen coordinates somehow.

The easiest way to do this is to ignore z:

```
screen.x = world.x;
screen.y = world.y;

```

If you have a rotating teapot, you will see a rotating teapot on the screen. However this isn't a very good implementation. If you want to do it correctly, you will have to subtract from the world position the camera position (effectively turning world space positions into camera space positions) and use the camera matrix to transform the coordinates.

Here's how I project a triangle in my own software rasterizer:

```
Vec3 camera_space;

for (int i = 0; i < 3; i++)
{
    Vec3 translated = a_Triangle->v[i] - m_Position;

    camera_space.x =
        (translated.x * m_Rotation[Mat4x4::X1]) +
        (translated.y * m_Rotation[Mat4x4::Y1]) +
        (translated.z * m_Rotation[Mat4x4::Z1]);

    camera_space.y =
        (translated.x * m_Rotation[Mat4x4::X2]) +
        (translated.y * m_Rotation[Mat4x4::Y2]) +
        (translated.z * m_Rotation[Mat4x4::Z2]);

    camera_space.z =
        (translated.x * m_Rotation[Mat4x4::X3]) +
        (translated.y * m_Rotation[Mat4x4::Y3]) +
        (translated.z * m_Rotation[Mat4x4::Z3]);

    //#define FOV_ANGLE                 60.f
    //static const float FOV_TAN      = tanf(Math::RadToDeg(FOV_ANGLE) / 2);
    const float distance = m_TargetHeightHalf / (FOV_TAN * camera_space.z);

    a_Triangle->p[i].x = m_TargetWidthHalf  + (camera_space.x *  distance);
    a_Triangle->p[i].y = m_TargetHeightHalf + (camera_space.y * -distance);
    a_Triangle->depth[i] = -distance;
}

```

# Answer
> 0 votes
You could simply add the negative camera matrix to all your transforms, but I think it depends on how you implemented your renderer.

---
Tags: rendering, projection
---


# Question
Title: How do I make connection between entities?
UML diagram + explanations.

Bonus if I can make it happen in Java.
Also killing panda is bad =)

# Answer
> 2 votes
These gameplay features can be broken into several domains:

**Collision checking**

How do you know that the panda's have met? How do you know the evil hero has slain a panda?

**Scene management**

How do you keep track of all the entities in a scene? How do you destroy entities? How do you create new ones?

First, scene management. An easy way to keep track of everything in your scene is just to make a list. Then, when you want to make a new entity or destroy one, it either adds or deletes it from the list. Simple.

Then, because you have your list of entities, you can have very basic collision checking by simply checking every item in your list with the other items. Just calculate the distances and see if they're close enough to collide.

And that should give you a general idea of how to solve these problems. :)

# Answer
> 1 votes
This is honestly kind of ridiculous. You've gone and created an object hierarchy without even considering how instances of the object interact. Where's your infrastructure? Where are the object containers? How do you handle locality? Et cetera.

Get yourself to interacting non-ojects in the world, then do your abstractions after that. You don't make a car by styling the interior then filling in the mechanics afterwards.

---
Tags: architecture
---


title: Could SDL be used to target Xbox 360?

text:
# Question
Title: Could SDL be used to target Xbox 360?
We're looking at developing a 2D game that could target Xbox 360. Ideally, we'd also like to submit the game via the XNA program so that gamers could try out the game over Xbox Live. We really love the fact that SDL is cross-platform.

Is writing a 2D game in SDL and then also targeting Xbox 360 possible, and if so how difficult might it be?

# Answer
To create creator club games on the Xbox 360 you have to use the XNA framework which in strictly C# .NET and even with that it must be managed C#.

Managed code allows .NET to handle all garbage collection and does not allow for use of pointers.

Yet another issues is XNA uses DirectX while SDL uses OpenGL. SDL is written in C which is unmanaged, and even with C# bindings to SDL it will still be considered unmanaged code to a C# project.

There are many reasons that creator club games are limited to managed code, some of the main reasons are for security and stability.

Unfortunately what you want to do just isn't possible.
> 6 votes

# Answer
Assuming you are talking about the Creator Club and/or XBLI games, no. They have to built entirely with XNA (and I think C# specifically, might have relaxed that to include C++ now though).
> 1 votes

---
Tags: 2d, xna, xbox360
---


title: XNA for multiplayer game?

text:
# Question
Title: XNA for multiplayer game?
I've made a few games without using XNA and recently started to see some documents and samples around and took an interest on it but i have a few doubts for going into it or not.

* What limitations do i have if i am planning to create a mmorpg with XNA for distributing it (if it has a item mall or is paid to play for example) ?
* Do i need more accounts to test it (for example to login into my own game 3 players) or XNA does not cost anything at this level (heard something about LIVE Gold Membership plus which is why i am asking this one) ?

# Answer
An MMORPG using XNA over Xbox Live is currently not possible. You can't access servers other than Xbox Live and even then you can't have a dedicated server (although technically you could use another Xbox if you wanted to but even then you would have no external access and would need a really good internet connection) to manage your game state. The marketplace is not available either except for downloading the game itself.

If you develop the game for PC you can have whatever networking code you like, however on Xbox you are very limited as far as multiplayer.
> 4 votes

# Answer
Using XNA to create an MMORPG for the Xbox 360 Creators Club is not possible since you can't have your own backend servers, but using XNA to create a PC MMORPG is possible.

Using XNA on the PC is extremely possible and frees you from a lot of the Xbox 360 Creators Club restraints.
> 3 votes

---
Tags: xna, mmo
---


title: Sprites saved in INA and AN format?

text:
# Question
Title: Sprites saved in INA and AN format?
I'm not sure if this is a suitable question but I found a game that had all it is sprites and stuff saved in INA and AN format and I got curious to know which program is it.

Or is it some sort of compressing or alike and how it is usually done?

Anyone know?

Here is the content of one of the files: http://pastebin.com/EzUsFvdG

Here is a hex dump of the above file: http://pastebin.com/CTErFBcS

The above one is the AN file and the bellow one INA.

Hex dump of a INA file which seems to be some sort of map or data file (I believe because of the layers info, etc?) http://pastebin.com/2fWn8izR

# Answer
As mentioned above, the evidence points towards this being a custom file format specific to that game. Probably not going to be able to open them yourself. However, if it uses OpenGL or DirectX and loads them as textures you might be able to use a GPU memory viewer to dump them to standard format.
> 2 votes

# Answer
It's not necessarily a common program's output at all. It could just be an arbitrary extension chosen by the developer for files that hold data about sprites. You can try opening the file in notepad to see its contents or as suggested above check the first four bytes to see if it is a normal file format saved under a different extensions.
> 1 votes

# Answer
A first thing to do would be to display it in various widths to see if any width shows a somewhat recognizable pattern (and humans are extremely good at detecting patterns, even if they're not there). If you're that lucky you'll have a good starting point as you know the likely width and can see if you see that encoded somewhere. From there you can also find height and so on. Only if there's a discenrable pattern to begin with through. It might be run length encoded or what have you and it'll become pretty tricky pretty fast.
> 0 votes

---
Tags: tools, sprites
---


# Question
Title: Which is the best approach to make a 2D character to be able to use tons of different equipments when in action?
I want to create a 2D game but I'd like to have the character to wear tons of different equipments on different combinations, like a RPG or something.

So let's say the user changes his/her shoulders and pants, this must be shown to the player and all these different equipments must follow the different characters action (hitting, being hit, spelling magic, etc.).

I see a few problems that I'd like to know the best approach/algorithm/architecture to solve.

**1 - Sprites or Animations**

Should I create different sprites for each equipment in each action animation?

Is it better to just have the equipment sprite and animate it directly on code like rotating and translating (using something like tween on Flash)?

Is there any other better option? (I really don't like the ideas above)

**2 - Positions**

Let's say during one of the character's move he starts looking directly in front to the player's view but ends his movement showing his right side to the player (like if he swings his sword from one side to the other).

If we consider one part of the user, like his head for example, it starts in front and then turns left.

It means at least 3 different positions for each head equipment (helmet, cap, whatever).

This surely influence the answer of #1 question. How is the best way to achieve that?

**3 - Layers**

Let's consider a character move where he spins 360 degrees with his arms open. At the beginning of the animation, his right hand is close to the user's view and then, at the middle of the movement, this is probably behind the character's body on the animation.

Whatever is the option on #1 question, you surely needs to use some kind of layer model to make this sprite or animation to starts closer to the player's view and later change to far away from player's view.

Is there any good way to do that?

I know the question is quite long and difficult to understand. Let me know if you think it's better to have some drawings to try to explain which one and I'll try to do that.

# Answer
I think it sounds like you are looking for a 2D skeletal animation system perhaps? I don't know of any off-the-shelf systems for that unfortunately, since it has been mostly superseded by the 3D-gfx-but-2D-game trend.
> 8 votes

# Answer
As Zorba says, most retro games didn't do this specifically because you would need (with sprites) to have multi-frame animations for every single piece of equipment.

Some "lazy" alternatives:

* Palette-swap the gear instead of making totally different sprites.
* Draw the character in such a way that the only parts of their body that animate are parts that aren't attached to gear. Like, if the character can only wear a single suit of armor anyway, make it a Helmet instead, and then you're free to animate the entire body while keeping the head still.
* Use a single sprite for the character in the main game screen, but show the equipment in a subscreen with a static portrait. Then you don't have to worry about animation.
> 8 votes

# Answer
In old games like the Ultima series, they would indeed draw one piece of equipment in every possible character pose. Occlusion would be dealt with either by not drawing the gear (if the left glove is behind the player sprite you don't need to worry about it) or by just drawing the gear in back-to-front order.

Obviously this was very labor-intensive, and as a result there were relatively few pieces of unique gear, with a lot of palette-swapped and palette-modified versions of that gear.

In a modern game, I'd strongly recommend making 3d characters. If you want 2d-looking art or your platform doesn't have the horsepower for actual 3d, you're still likely to be better off modeling everything in 3d, rendering, and then tweaking the final result by hand.

Alternatively, if you decide you don't need tweaking, don't have horsepower for full 3d, but don't want to ship a huge sprite library, you can package the 3d models and render them to a texture in realtime when you know the model is about to show up in-game.
> 2 votes

# Answer
Check James Da Silva's book where he explains how he did The Dishwasher: Dead Samurai. It'll show you how KISS pretty much can solve this. The suggestion of using 3d or 2d skeletal animations are valid, and kinda in the same realm.
> 1 votes

# Answer
This is a great question but I think you've answered it yourself - you need a 2D bones system that supports bones changing layers, so different limbs can go behind and in front of each other as the character rotates. You will also need to draw your sprites from 4 or 8 angles (or however many you need). Depending on what skills are in your team it might be easier to create these assets in 3D and render them out from the angles you need.

Using a 3D engine is also a good solution, although this will bring it's own set of challenges.
> 0 votes

---
Tags: 2d, algorithm, animation
---


# Question
Title: Why the shareware (not demo) model died?
In the early days of the industry, instead of fighting piracy, companies let the users share their games freely, and put some nag screen or something like that on the game.

Then they would sell DLC and expansions (yes, DLC is 20 years old actually :P), hintbooks, cheat codes, swags, etc...

Why this model died?

Note: I am talking about classic shareware, not the crippleware or demo crap.

# Answer
The concept hasn't really died, it's just changed a bit and been given a new name. In fact, if you have an iPhone you can see it in action right now! Many 'free' or 'lite' games offer a sampling of gameplay and allow you to purchase DLC to promote it to the full title.

On the PC use has declined, but I believe part of the reason for this is the lack of a platform to easily distribute semi-secure DLC (the other of course is piracy). As digital distribution platforms grow, I believe we'll see a resurgence in shareware-style software model, perhaps even starting with Valve's recent Alien Swarm, should they choose to provide DLC campaigns.
> 18 votes

# Answer
It's still around. We just no longer call it Shareware. We call it the "freemium" model: free to play but with premium content available for cash. The only difference between now and the old days is that we have better ways of accepting payment today: accepting credit cards over the internet (no more "mail a check to this address and we'll send you the full disks in the mail"), for example.
> 6 votes

# Answer
Because people played the Shareware version of the game and then when it was done. They stopped playing and did not buy it.

So the turnover rate was very low.

The old shareware model you speak of "died" when the internet came to be popular, since a large part of the old shareware model was the shareware distributes and the copy/delivery fee you had to pay to get your free program
> 4 votes

# Answer
One important thing to note is that old-school shareware generally had copy protection that boiled down to 'if(strcmp(reg\_code, "12345ABC")!=0) { nag\_screen(); }'. Given that modern game pirates can effortlessly destroy even some pretty complex network-based DRM systems, this doesn't stand much of a chance.
> 2 votes

# Answer
Ease of piracy did a lot to kill the PC shareware model. It was one thing when downloading the first episode of Wolf3D off a BBS was a big deal. Now you can find a full retail game before it even hits store shelves. It's just too easy to distribute large files.

Places like Steam/iTunes/XBLA/PSN are showing a resurgence in the shareware/demo model as they can keep the full content behind a pay wall from all but the most dedicated pirates.
> 2 votes

# Answer
Another possible factor to consider is the rise of free online games, especially Flash games like those on sites like NewGrounds and PopCap. Why download a free game when you can instantly play it online, without the hassle of installing anything (beyond maybe a browser plugin)?
> 2 votes

---
Tags: marketing, distribution, business-model
---


# Question
Title: Any hints about the average renderstate changes per frame?
While answers will vary depending on the case, I'd love to hear about what people have seen in their past experiences. The question mainly relates to DirectX though if you have some numbers for any other API (OpenGL, consoles etc) I'd be glad to hear them too.

Thanks in advance.

# Answer
It depends what states you're changing; different things cost different amounts. Simple state like blend equations and most other SetRenderState stuff is cheap, and gets batched up till the next draw call so doesn't incur a large penalty for hitting the driver. Shaders and render targets are more expensive and will generally cause issues if you swap them excessively.

Usually though render states are not something you have to worry about overly - draw call overhead will almost always dwarf render state costs.

In terms of numbers I'd suggest aiming for no more than a couple of hundred shader swaps per frame, as few render targets as you can get away with and not worry about the rest. Typical numbers for simple state might be 5-10 state changes per draw call, but it's very variable.
> 2 votes

# Answer
It doesn't matter how much renderstate changes really is, you should always minimize that number, using sorting, etc, as renderstate changes are expensive on most APIs.
> 2 votes

# Answer
Two. Enabling and disabling depth-testing for the UI.

Everything else is handled by shaders.
> -2 votes

---
Tags: directx, performance
---


# Question
Title: Which tools are artists using out there and how for game development to produce the material used by game programmers?
What processes, tools, methods are used by game artists to prepare materials for the programmers?

I am interested in tools (ie: photoshop, pixelmator, etc for drawing) and also how they are used together to produce texture atlases or individual images for the programmers.

Methods or way of working (tool-chains maybe), which can be used by the artist to

* Present ideas (sketches)
* Mesh up game images (photosop: front menu, in-game)
* Cut up images/layers into (ie: copy paste?)
    + smaller individual pieces
    + texture atlases (some other tool)
* Generate coordinates ie: (xywh) for button "Options" on the main screen which is stored as main\_options.png or (uvhw, xywh) for in-game HUD which is in a texture\_atlas.png.
* Any way to automate some of the steps above?

============ before edit ============

The artist(s) might use hand drawings-scanner/sketch pad for illustration. These are then imported and further improved in some other image manipulation tools. The result then can be used to produce both preview of the game (menu, in-game meshups) and final elements which will be used by the programmer(s): individual images or texture atlases.

Which tools are artists using out there and how for game development to produce the material used by game programmers?

I am particularly interested if there are automated tools where a small change at the illustration part can be propagated to produce final production images/textures without the need for the artist to cut/merge them.

# Answer
> 0 votes
Pretty much agree with the above - Max/Maya and Photoshop are the de-facto asset creation standards. What happens after that and how is often custom per engine, or even per game. There's as many pipelines as there's developers I think, ranging from manual labor, via command line tools and editor scripts to completely automated inhouse editors and batch processing tools. Most larger studios do have a custom build tool for the final conversion that can be integrated with the build system so that whenever new source assets get submitted they get automagically converted to the final ingame asset.

As for presenting game ideas, again as many methods as designers. Sketches, photoshops, renderings, moodboards, anything goes as it gets the message across.

Edited to add: Did I misunderstand the question and are you looking for a workflow that would work for *you*?

# Answer
> 1 votes
Not sure if this is what you're looking for, but:

TexPack: http://texpack.sourceforge.net/

takes a bunch of images and packs them into one big image and outputs a file with the coordinates. You can see a sample on the website.

# Answer
> 1 votes
I believe you are looking for this. Creation of a ready to use 3D model for a game engine from start to finish.

# Answer
> 0 votes
Most engines have their own texture compression tools if thats what you mean. As for UV mapping/unmapping, thats usually somewhat specific to a given 3D tool and/or engine. Not 100% sure if either of those are what you are asking about though.

---
Tags: graphics, tools, art
---


title: XNA: Deforming/Destroying a model

text:
# Question
Title: XNA: Deforming/Destroying a model
I want to be able to destroy and deform a car in-game.

For example, I want two cars to crash and a) break the meshes apart (probably applying force to fly them apart) and b) deform the mesh (like bending the side doors).

How would I go about this?

Thank you in advance.

# Answer
I think the best way to deform your car would be with skeletal animation (see this sample and this one).

For example: have a "bone" (or two) for each door, the bonnet, the roof, the front, back, etc. And then you want to weight the vertices for that part of the car, to that bone, in an appropriate pattern (ie: some will have full weight, some might have partial weight). Then when your car gets hit - you move the bone for the section of the car that got hit inwards, towards the center.

It's not as nice as procedurally deforming the model. But it's a *lot* easier and your artist can then get things looking "just so". (And you can use the same system you might use for turning the wheels, etc.)

You probably also want to have two textures - a clean one and a dirty one. Then switch between the two in your pixel shader for different regions. This sample is probably a good place to start.

For breaking apart the model - I would suggest simply having different models for different parts. You could use the same bone structure so a car that breaks apart keeps the same damage deformation. (Or, alternately, have multiple root bones - one for the body, one for each door, etc, so they can be separated.)

For applying forces to make it fly apart (and getting nice matrices you can use to transform your parts) - you probably want to use a 3rd-party physics engine.

Finally: throw in a particle system for good measure.

This method should be pretty simple to implement for basic car damage in, say, a racing game. For something more severe, the same technique should still be viable - just with a lot more thought put into it.

The alternative is to rigging your model for damage is to do something procedural in your shader. This sample might be a good place to start - instead of shattering, you could move the vertices inwards depending on the direction of impact and their original position on the model. Although this is much harder - I wouldn't recommend it.
> 4 votes

# Answer
Most games fake this massively. They will break the car down into components (bumpers, doors, wings, bonnet, etc), and each component will have several versions, each for damage inflicted from different dimensions. With this approach it is also easy to break off parts, and have your doors animate like their hanging off hinges.
> 1 votes

# Answer
If you do not want to precompute or have artist created breakaways, I suggest getting or writing a physics engine that uses a Finite Element Method system. Examples of this are a video of a spaceship being deformed by asteroids and the physics in the commercial game The Force Unleashed, which both use DMM. I am uncertain when AMD will release their free DMM2 and Bullet physics package.

Also, I don't know how DMM2 interacts with XNA.
> 1 votes

---
Tags: xna, physics
---