XNA and onward

[MyndFyre]

So I'm working on a little collaborative game with a co-worker as kind of an after-hours thing.  Right now we're not disclosing any details about it, except that I'm going to say we're going to try our hardest to create a game core that will work on both XNA and Silverlight.  Since neither of us has any experience with XNA I wanted to play with it a little bit tonight.  Here's what I made:



Yep!  It's a bouncing ball (notably themed with ASU colors) that follows gravity-like parabolic paths.  You can change the direction of gravity on the fly as well.

Details are on my blog -- more to come soon!

[Blaze]

Right now we're not disclosing any details

Details are on my blog

Wait... what?

[MyndFyre]

Not disclosing details on the game.  I AM disclosing details about the programming. :P

[MyndFyre]

I added collision detection :)  Check out the videos on my blog :)

[Camel]

Tip: If you want your game to resemble reality in the future, start using SI units now (kg, m/s, m/s/s). Obviously, floats aren't typed, but you should document your methods as taking "speed in m/s" for example.

Another thing you may find to make your codebase cleaner: any equation you would know by heart after finishing a physics course should be extracted to a reusable method. Inline it if you want, but it'll make the code readable to a novice, and that's a good thing for open source software.

Also, you should probably take elasticity (float e1, float e2) in to account in your collision class. That way you won't have to re-write it later.

[MyndFyre]

Tip: If you want your game to resemble reality in the future, start using SI units now (kg, m/s, m/s/s). Obviously, floats aren't typed, but you should document your methods as taking "speed in m/s" for example.

Another thing you may find to make your codebase cleaner: any equation you would know by heart after finishing a physics course should be extracted to a reusable method. Inline it if you want, but it'll make the code readable to a novice, and that's a good thing for open source software.

Also, you should probably take elasticity (float e1, float e2) in to account in your collision class. That way you won't have to re-write it later.

For clarity: I've never programmed a game, physics, or anything like this.  I pretty much expect to have to rewrite later, since I don't know what/how to refactor this stuff.

Also, I noted:

it's designed to be simply a perfectly elastic ball

[Camel]

Well, from what I've read so far, it seems like you're doing a pretty good job of organizing the code. The only thing I'd really change, aside from documenting your methods with SI units, is to move all of the physicsy stuff to a physics class.

Some things are so intuitively obvious that you'd never consider extracting to a new function, such as speed = distance/time. Anything that involves more than, say, two operations, or that is otherwise not obvious to someone that isn't "skilled in the art" by its written implementation should get refactored. Try to make these functions as reusable as possible, except when you can see that there would be a performance benefit to overloading. You might have two methods to calculate collsions, where one takes objects, one that takes vectors, and one that takes floats. Ultimately, you should try to make the object method call the vector method, and the vector method call the flat method.

At my college, one of the majors offered is IMGD - interactive media and game design. It's just CS with a concentration in IM/GD. I didn't choose to go this course, but I've taken quite a few physics courses in my day, and I've found myself reviewing game code designed by people who haven't, and this is what I generally find:

People put too much emphasis on what seems right, and not enough on what the reality is. For example, to calculate how a collision occurs, you should use the physics equations, not what makes sense in your head. This may make your physics class a little bulkier, but in the long run will eliminate most hacky code. Furthermore, if you can inline these functions, that overhead will be obliterated by the compiler.

There are few things you should know about collisions (in descending order of importance as I see them):

* Collisions are about momentum, not speed. Convert your speed vectors to momentum vectors (or flat variables) before calculating anything. Total momentum in (per axix) = total momenum out. Write test cases to prove this! You're using floating-point logic, so verify to within 1/10000 of the expected value, or some other constantly defined threshold.

* Conservation of mass. This is obvious, but it is an assumption that needs to be stated. You shouldn't need to document or write code to prove this, since there's no reason mass wouldn't be conserved.

* Both objects in the collision have their own elasticity. If these values are equal, the equation is simpler than if they are not. Do not use the simplified equation.

* The floor always has a low elasticity. Try 0.1 for starters, and lower until you find a value you like. Other objects almost always have an elasticity of 0.25 or higher. Never choose an elasticity higher than 0.95, since that's unrealistic. Especially never try to set elasticity higher than 1.0, since it will make collisions with immovable objects looks stupid.

* Everything has elasticity, but sometimes there are cases when you ignore this. For example, look at any first-person game where you can fall. What happens if you fall very far? If you die, you should hit the ground and bounce a little. If you land on your feet AND survive, you shouldn't bounce, since your legs successfully absorbed the energy.

* Mass is linear inertia. Inertia is resistance to movement. To make an immovable object (floor, walls), use mass=+INF. Your equations should work properly.

You might also make provisions to, in the future, have collision meshes. A collision mesh looks exactly like an object's physical model, except that it has as few points as you can possibly use without making the object behave unrealistically. It's important to keep collision meshes simple because collision detection is an expensive process; the simpler the mesh, the faster it will happen. You may want to have special sub-classes for spheres, since a polygon collision mesh will prevent a ball from rolling along the ground.