www.enchantedage.com

A while back, I posted a simple program on the XNA forums that showed how to define a path, and then have objects follow that path. I figured I'd copy the code from there onto this site, for easy reference. The program below is a command-line C# program; you can compile it from the command line with "csc flypath.cs" and run it to test it out. Or you can copy the "follower" class from the middle, and use it in your XNA project. (The additional code, including the declaration of Vector2, is just there to make the test program work stand-alone)

Why is it that seemingly every week-end project ends up in tears and teeth gnashing over broken tools, instead of sweet progress? Why do computer companies keep cramming useless features into bloatware, instead of just making what they have, actually work?

Let's assume you're trying to simulate a car driving on an uneven terrain (perhaps some sort of heightmap). Let's assume you know how to measure the distance from the car's chassis to the heightmap ground at any position (typically, measure the height of the heightmap, and subtract the height of the car at that point in the XZ plane).

There is inheritance, there is interface, and there is configuration. Inheritance (of a base class) is seldom the best or most efficient choice. Sometimes, newbies read the wrong tutorials, and start down the rabbit hole of class inheritance, but in the end, that turns out to be a dead end.

If you're using UDP for your networking, you will typically mark your packets with a "packet ID." That packet ID will be used to detect the case of duplicated UDP packets, and sometimes also dropped packets.

When you send packets over TCP, you have to precede them with a byte count, because TCP just delivers a stream of bytes, with no particular block size. If you don't delimit your packets somehow, they will run into each other, and you won't be able to tell where one ends and the next one starts.

A structure that I find works very well when managing entities in games is the world/entity/component pattern. Entities in the world are nothing more than collections of components, where the components have the responsibility to "do something" with the entity.

This post includes a thread pool class for the XNA Framework that works better on the Xbox than the thread pool class in the Compact CLR. The main thread can choose to get notified about task completion with a callback function, or by waiting on a pre-allocated wait handle, or do fire-and-forget on the thread tasks.

In most games, you'll need to know where everything is.

Here is some code that lets you extract the vertices and indices from a loaded XNA Model. You do not need to use any special processor, such as the JigLibX VertexProcessor or some derivative of the ModelProcessor -- it works straight out of the box!