Posted by on April 16th, 2015

It’s been awhile since we’ve done a tech blog, so I decided to write about what you can expect from our Phase 2 Multiplayer: Dedicated Server. I’ll even post some super high-definition renders of the advanced console interface that Josh (@JoshuaBrookover) has been working on!

So what do we mean when we say “Dedicated Server”? We already have the ability to host servers now, right? While we do have the ability to host servers now, the person hosting must be a player in the game and also be running the full version of the game in order to allow players to connect. This makes it very problematic to host a stand-alone server on a computer and just have clients connect at their leisure.

When we say “Dedicated Server” we are referring to the game running in a much reduced form (no graphics, gui, sounds, etc) than needed when actually playing the game as a seed in the world. The dedicated server is a stand-alone application that manages only what is necessary to maintain the state of the game, but does not process any systems that only a player would need. One of the biggest things we gain from this is that it will allow player count on a server to increase! This is the dedicated server:


(Figure 1: Server running and ready to be used, work in progress)

The dedicated server does not create a standard window like you’d expect with most of your programs, but runs as a console program. No graphics libraries are loaded or utilized; it doesn’t play any sounds, and there is no server player.

We use a console library called PDCurses to give us a clean-cut interactive console at runtime. It has an input area for the server owner to type commands, as well as some advanced stats across the top so at a glance you see what’s going on with your server. Each statistics box can be changed to show any other stat.


(Figure 2: Shows command input and statistic changes, work in progress)

This console will provide a lot of useful information, showing when a player joins/leaves, viewing the in-game chat, and seeing any useful debugging or warning information from the engine or Lua.

Logging is a large part of running your own server that you aren’t always keeping an eye on. Everything from system information to chat messages that pop up in the console will also be logged to a file that is specified by your configuration file. This log can provide very useful information to server owners allowing them to diagnose problems or view player’s chat logs.

So what does the dedicated server give us? With the dedicated server, a player can run a TUG server with their own hardware or service. This also gives hosting companies the ability to host game servers for the public. The dedicated server is completely configurable from a single file that allows whomever is hosting the TUG server to specify information such as number of players, maximum allowed view distance, networking ports and other useful configuration parameters as seen in the image below:


(Figure 3: Dedicated Server Configuration File, work in progress)

Our hope is that we can give any server host the ability to run TUG servers, and as we continue to improve on the Eternus Engine and TUG, be able to give them more and more capabilities with their game!

Keep in mind that we are still working on the dedicated server and we may choose to add or change some features that are seen here as we develop further. There is still a lot to do! Feel free to follow me on twitter @camfergusondfw or stop by our forums to ask any questions you may have about the dedicated server!



Posted by on January 9th, 2015

TUG Multiplayer is in the works and we are getting really close to testing phase one. Today, Dr. Clark (Doc) explains in detail about our challenges and solutions. Don’t forget to follow him on Twitter @CoreyClarkPhD and nerd out!

One of the things we had to do for the new Multiplayer release of TUG was develop techniques that could be used to synchronize player and object movements across clients and server.  These algorithms must be robust to handle the ever-changing time for transmission (lag) and loss of data that occurs between client and server.  There is not a “one size fit all” technique that can be used, as each game’s environment, objects and genre present their own challenges.  For example in TUG, there are 3 different types of objects that needed to be synchronized (3D Rigid Body Physics Objects, Remote Players and Local Player) and each required a different algorithm.  In this blog series I am going to cover a few of these techniques while discussing some of the pros and cons each technique provided.

Another commonality between all techniques I will discuss is the need for security.  In all cases we have to keep the server authoritative to provide a way to ensure that data being sent from each client is valid to curve cheating.*

*Fun fact:  While we have made sure that the server has the ability to verify any request made by a client (digging, building, crafting, etc), we are not actually enforcing that at the moment, so … hack away.  

3D Rigid Body Physics Objects

All of the physical objects in TUG that a player can interact with are controlled through our 3D Rigid Body Physics Engine.  So when you find yourself in the middle of a pumpkin grove and a spontaneous game of “pumpkin soccer” erupts (true story), all of the pumpkins are physics enabled game objects that must be synchronized between the server and all connected clients.


The challenges for TUG was to find a way that allowed the following:

  • Maintain authoritative server
  • Minimize processing on clients to help with future cross platform development
  • Maintain the game experience by removing jumps/jitters caused by lag or packet loss

We ended up having the server perform all physics calculations for all objects currently being simulated and using common technique in game development called Dead Reckoning to update the objects on each client.  Essentially the server sends a steady stream of updates (position, rotation, velocity, acceleration, etc.) for all currently active* physics enabled objects to each client.  The clients then use this information to update and move all active physics objects.

*After a given amount of time a physic object will be set to “sleep” and no longer be updated until something applies a force to it, this allows us to keep the overall processing of physics objects to a minimum and save precious CPU cycles.

This technique requires two different parts:

  1. Interpolation of objects position and rotation from current position to newly updated position provided by server.
  2. Extrapolation of objects position and rotation to a predicted position.


When the client gets an updated packet from the server, it now needs to correct the clients data to match that of the server.  If we were to just set the values sent by server to those of the clients, you would see the objects on each client snap (teleport) to new values and would give you that oh so sickening feeling of lag induced rage.

To prevent this we calculate the difference of the new object data from server and current object data on client.  We now know how much position and rotation need to be applied to the object to catch it up to current state on the server.  We add a piece of that difference over several frames while also updating the objects velocity and acceleration to that of the server.  The image below gives a visual of how that process looks (only showing a position update)


Extrapolation (Prediction)

Once the client has caught up to the last know state of the server, it continues to move the object on a client with its last know velocity and acceleration.  If the updates from server are quick enough, then the changes in an object’s velocity and acceleration are small enough that continuing to move the object with its last known state will minimize the difference between the client’s state and the new state provided by the server on the next update.

If a users connection gets “laggy”, then the prediction will be incorrect, but the client will still use a smooth interpolation to get client’s objects back to the correct state.

If you have ever lost your connection to an online game and your player continues to move, but you have no control, then that game is using Dead Reckoning as well.  There are issues where people have used this to cheat on a game to pass through walls.  Essentially moving towards an object then cutting your internet connection, the player would continue moving passing right through the wall due to the dead reckoning algorithm since the game is no longer getting updates on position from the server.  TUG will not be susceptible to this, but that leads us into the next algorithm that is used to visualize other players in the world on your local client.  I will get to that in the next post.


Hit me up on the Twitters: CoreyClarkPhD or Forum if you have any questions. You can also join our mutiplayer development thread Q&A here!