Basic Terrain Rendering and High Precision Network Timers

Long time since I have done an update and most of this is due to work overload at EverFire Studios as I work dilligently to produce code for our up and coming Bring Out Your Dead: Black Plague TCG. This brings me to my first topic: High Precision Network Timers.

To be honest, this is a field I am not entirely experienced in and had a trouble finding a place to start. The reason that we needed this in the game was to provide the clients accurate timestamps for their turns. The first part was simple - use a standardized time system and send that time to the client. But this brings one consideration to mind - latency. If any of you have ever played any game ever, you know what lag is, more so if the game was an online based such as Battlefield 4, League of Legends, or any MMO.

How did I go about this then? Well, I wasn't sure at first but that is why research exists.

After a few days of research I decided to create a model similar to the ideas of NTP stratum servers. Sounds quite wonky at first - which confused my lead as well. But I was not actually using NTP server, daemons, or anything of that nature. What I pulled from this was the implementation of a modified Marzullo algorithm. This algorithm calculates a best effort confidence level. And, instead of the client receiving multiple time stamps, calculating the values with least difference, and then apply that time, mine is reverse and singular.

What do I mean by this? My latency calculator goes as follows:

Game server thread sends message to event listeners that there is a time update.
The engine calculates the remaining time in a turn.
The server, on this event, sends the remaining time less the latency to the client.
The client receives this message and responds with a packet that sends the server response time as well as it's request time.
I have to take into consideration the time delay used for firing off the time update message.
After collecting X amount of samples the server calculates the new latency using values selected from the calculation of time intervals of client-server requests and client-server responses.
This is then the new latency.

Using this method, I reduce server CPU time by not calculating lag every pass, but maintain a tight interval of the lag. I also ensure that when the time packet the server sends, the client will have synced time with lag put into consideration.

Now to switch gears entirely, so don't think about time now. It is rendering time in regards to my engine. For my simple engine I, as a separate project, I am implementing a heightmap on terrain and mapped texturing. All very well basic methods (I am not a fancy voxel person just yet) to accomplish simple ends.

That blurb was more of an update than anything to prove I am still working on my game engine - albeit slowly now.As you can see from the beginning though, it is on its way to being something tangible!

DX10 Heightmap/Blendmap Terrain

So there you have it!

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!

A Whole New World

Alas, I must admit defeat...

No, I must not,

Aye, I must...

That has been my thought process for the past month as new issues kept arising in my current game engine using the component-entity model. And alas, after realizing I was over-engineering, I admitted defeat.

But I had a secret weapon, and that was re-engineering my existing code to reflect a traditional OOP design architecture.

I know, not as intuitive, but I must digress, I need something to SHOW other than just a cube. And so far it has been successful. What I mean by this is that I have complete integrating a Shader class that is derived from and create any shader. I have a render-able Prop with colliders. And now I am fine tuning the collision system to implement Rigidbody Physics.

Within the month I will have a demo video showing as I still have to work on my projects with EverFire Studios, Inc.

Wish me luck and I promise I will have something to show you and a thorough technical post in regards to it.

And as always, enjoy game programming!

Rendering Architecture Established

For a while I have spent time on getting my DirectX 10 rendering system architecture established, and I am successful in that end of my engine. However, in doing this implementation, I have realized a few setbacks for my system. One such, that I will be swiftly reengineering, is the loss of data as my Entities fall out of scope (this is because I only use pointers after their initialization to do the rest of the work). What also happens is that iterating through each component registered does not match components correctly with 'brother' components (components of the same entity). This causes wrong calculations and issues within the system that are completely unacceptable.

Now, the re-engineering I plan on doing is creating hash values for each Entity within the system, use an Entity Manager, and correctly mapping components to their respective Entities. This will also make debugging entities simpler as that has been and issue.

Now, for the picture proof of my renderer actually working: