Dumb Coders be Dumb

Today I have learned a very important lesson. This lesson is that in life, spelling, is of the utmost importance. Think about it, if you can't spell your own name, how will people know who you are? If we spelled cities differently each time, how would we navigate to Palo Alto or Aplo Aito? Well, even though computers are logical creatures, they definitely need you - the user, programmer, engineer - to know how to spell.

One of my issues, one of many of my issues, was caused by a simple misspelling. The stack trace told me where the error is. I thought I changed it, but when I uploaded it, I misspelled the directory, therefore leading me down the rabbit hole of "I swear I fixed that" and "I don't know why my code doesn't work."

I may have posted about this twice, but it is a stupid thing to do, misspell words. I really hope it does not befall you on your adventures in game programming.

Now for some real updates. I have finally fixed the code in the Client application to properly display names of users in a game that the player joins. This issues was brought on by how Unity loads levels and some shuffling of code.

If anybody has taken a look at the source code they would know that when a player joins a room, the game manager is prepped with a queue of players who are already in the room, or are joining the room. It supplies the script with both the player's name and the player's id on the network. If the queue is filled, it will copy this data to a new dictionary and iterate over this to put the relevant data in an instantiated object in the game and put it in the player dictionary.

This method worked fine, until player names were not showing up and they had to be added in the update method when the client received a foreign transform message. The instantiation turned out to be happening before a level fully loaded and so was creating players in the previous scene in Unity, and destroying them. This meant they existed, but then didn't exist at the proper moment.

I fixed this by only allowing the queue to be emptied in the multi player or single player scenes. Now the player names and ids are displayed properly and data is passed back and forth without incident. I also set the labels for names to clamp to the view port. This will prevent players from seeing a name of a player who is actually in the opposite direction. It will also now act as sort of a radar on the HUD. I like it, but I need to see if other players enjoy it as well.

Next I will be fixing one last server issue in which multiple death notices go out when a player dies, leading to a whole flood of errors.

Until next time, enjoy game programming and check out the revised version on my google drive.

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!