Tiny Update (XML Parsing)

In an old post I stated that I wanted to create a content creator script that would allow the generation of levels. I was going to implement it and got a lot of work on it done, but realized that I needed to go a different route. The reason I did this was portability and compatibility.

This lead me to store data as XML and load it into the engine as a per level basis. Then each level was pointed to in the overall world. This allows for level streaming- which was my original intent. It is also significantly faster than what I originally hoped to do.

To achieve this I implemented a wrapper for rapidxml (an xml API using the MIT or Boost liscense.) The purpose of the wrapper was to decouple it from the engine and hopefully build my own one day.

As far as updates, that is about it.

FPS Camera

From my last post I stated that I was going to implement an FPS camera into the game engine. This will be one of many cameras. The various cameras I wish to incorporate are a top down camera, which would be nearly similar to an FPS camera, a third person camera - which follows a user controlled object, and a cinematic camera - an FPS camera with no user input and on rails or static.

Well, today I finished my mouse look WASD controlled FPS camera. The math behind it was pretty simple and only took a couple dozen lines of code from combining my Movement class with my Camera class. Then I put all necessary input translations in regards to the up and right vectors of the camera and the movement of the position vector. Here is a sample of the code:

//sprinting //TODO: remove magic numbers if(keyDown(DIK_LSHIFT)) { mForwardVelocity = 2.0f; mStrafeVelocity = 1.25f; } else { mForwardVelocity = 1.0f; mStrafeVelocity = 0.75f; } //mouse look XMFLOAT2 newPitchHeading( getHeading() + mouseDX() * dt, getPitch() + mouseDY() * dt ); setHeading(newPitchHeading.x); //x rotation is equal to x coordinate mouse movements setRotation(XMFLOAT3( newPitchHeading.x, getRotation().y, getRotation().z )); if(newPitchHeading.y > MINPITCH && newPitchHeading.y < MAXPITCH) { setPitch(newPitchHeading.y); } //keyboard movement if(keyDown(DIK_W)) direction += forward; if(keyDown(DIK_S)) direction -= forward; if(keyDown(DIK_D)) direction += strafe; if(keyDown(DIK_A)) direction -= strafe; direction = XMVector3Normalize(direction); position += direction * mForwardVelocity * dt;

So essentially we take the mouse x coordinates and make that the heading value of the camera. This is essentially the look left and right with the mouse. The y coordinates of the mouse translate to looking up or down in the world. Conveniently, the camera class takes care of calculating the right and up vectors natively, so we omit it from the update method for the FPS player. We then apply the forward and strafe vectors (up and right) to the direction vector of the player and either increment or decrement depending on player input (W,A,S, or D). Finally, we normalize the direction vector and apply it to the position in relation to the forward velocity and delta time scalars.

Here is a video of the working camera:

Default Renderer Completed!

Today I completed my default shader for all static objects within my game world. By static I mean objects that are not animated such as a walk animation. My shader includes a diffuse texture, normal map, and a specular map. Those three textures are what I wished to accomplish at the minimum for my basic 3D models.

With my default shader complete I wish to incorporate a messaging system for all input so I can start creating a user movable camera. The reason I mention messaging systems is because of my current job at EverFire Studios. Recently we have decided to create a headless game engine for our current game in development. Naturally this meant a lot of research in design patterns. This also included patterns with messaging systems.

As to which messaging system to incorporate all input controllable objects... I do not know yet. I will have a detailed post about that at a later date, perhaps.

To recap, I have finished my default static model shader and will move forward with incorporating user input. Until next time, enjoy programming games!

Collision Detection and EverFire Studios!

Busy, busy, busy are my three excuses. It is still within the month and I will still try to update as much as possible in regards to my game engine, but man, I must go on a rant.

So, as mentioned before, I have started a job at EverFire Studios in Milwaukee, WI as a game play programmer. Currently, we are working on developing a new game and it has taken a lot of my attention. Perhaps when it goes alpha I will show some game play videos. On top of school and a second job, I have not had much time to work on my engine.

Well, at least I have something to show you. It is exciting and incredible...
It is two boxes detecting a collision with each other, and don't worry my spheres can do it too. With this I will implement a Rigid body physics system. But, honestly, I don't like programming physics - so I may go back to my renderer and implement a shader for diffuse, normal, and specular mapping as that is the bare minimum I want on my models in the engine.

Speaking of which, I need to think of a name... still!

So, since I wish to have this be somewhat intellegent, the idea behind simple AABB (Axis Aligned Bounding Box) and Sphere Collision is all of but a few simple statements. In order to get the code from this we just need to do the following:

Two spheres collide it the distance between their center points is less than their combined radii.
Two AABB collide when the absolute values of the x, y, and z coordinates of the length vector between the center points of each AABB is less than the cumulative values of the respective coordinate extents.

The sphere was easy, the AABB tests were a mouthfull, so here is the code in its simplest iteration:

bool Intersect(const AABBCollider& pVolume, const AABBCollider& other)
{
XMVECTOR volumeCenter = XMLoadFloat3(&pVolume.getCenter());
XMVECTOR otherCenter = XMLoadFloat3(&other.getCenter());

FXMVECTOR length = otherCenter - volumeCenter;

return fabs(XMVectorGetX(length)) <= (pVolume.getExtents().x + other.getExtents().x) &&
fabs(XMVectorGetY(length)) <= (pVolume.getExtents().y + other.getExtents().y) &&
fabs(XMVectorGetZ(length)) <= (pVolume.getExtents().z + other.getExtents().z);
}

And yes, for right now I am using xnamath for my math library; perhaps that will change too.

Until next time, enjoy game programming!