• Register
Post news RSS This is... just about everything.

In this update, we give a brief overview of how the networking system will work as well as a play-by-play of a hypothetical game session.

Posted by on

Last week we explored the proposed development environment for Entropy (which I have in fact started to work on!). Today we're going to talk about something way more important: how does this thing work? How the hell can we get such a big game to run, and build it in a year?

Well, I actually can't answer the last question (but I've got an idea: join us!), but the first two I can get into with this article.

At the core of Entropy will be a system much like how the Internet itself works: We have a core server (hopefully not our poor little O-G, though) that acts as a base of operations for all logins (like a top-level domain). From here, we can keep track of where all the planets in the system are by connecting either directly to them or through a (much more preferred) "solar system server". The core actually runs two different servers: UserServ and UniServ. UserServ, as its name suggests, handles logins and manages your profile. It's basically a connection between the Entropy world and a massive MySQL server. UniServ keeps track of all the planets in our universe and manages your connection to them.

Next up on the tree are SolServs, which handle clusters of planets and do some small grunt work. SolServs are meant to be smaller and take a lot less power to manage, as they simply handle the locations of planets and the aspects of a system's star (color, size, and mass).

Below the SolServ is of course the PlanServ, the biggest and most stressed area of networking in Entropy. PlanServs handle every aspect of a planet, dish out terrain data through TCP connections, manage player locations, object physics - everything. The best way to look at how a PlanServ works is to think of Google Earth. As you move around, your connection to the Google servers gives you terrain data and textures, and even downloads building models. Entropy works the same way, but with significantly smaller planets (and a bit more detail). On top of the terrain services, you can think of a PlanServ as also being a typical game server (or actually multiple game servers), handling the interactions between players and checking physics. For this reason, PlanServs will need powerful hardware to handle up to 100 players (or more, we have no way of knowing how big our userbase will be).

So that's basically how things work in a nutshell. Let's a get bit more into it, shall we?
Let's take a look at how a simple connection from an Entropy client will be handled:

1. Start the client. You'll be asked to login or register a new account. We'll talk about profiles later, so we'll just skip to logging in.
2. Your credentials are passed through a secured connection to UserServ. Everything checks out.
3. We now connect to UniServ to find out where we are and how to get there, and to update our global cache.
4. UniServ directs us to SolServ "basis" which it knows by the IP (that's us, if you're wondering) It also sends us timestamps for cache data (models, materials, and other important information we need)
a) Assuming our cache is indeed outdated, we start downloading in the background through a TCP connection
b) The "Global Cache" contains models and textures for players, vehicles, building blocks (for buildings and ships), and foliage (trees and bushes).
c) The Global Cache may span multiple servers. We don't know how much data will be in it.
5. While maintaining a connection to UniServ, we start up another connection to the SolServ. This will only be for a brief handshake.
6. SolServ responds, verifies our connection, and directs us to "adria.basis", which in this example we'll say is on the same IP.
7. We disconnect from the SolServ and head off to the PlanServ "Adria". We first initiate a communication TCP stream to send a handshake.
8. Adria sends us some basic information: Our coordinates in space and on the surface, some general information on the planet, and some cache timestamps.
9. Let's assume our cache of Adria is out of date: The timestamps don't match up. We now request a connection to download a massive set of files.
10. On our communication line, we request the set of files we need to download.
11. A file-transfer TCP connection is establish and the server starts sending files to update our cache. Since we know where we are, we get localized data:
a) First we get the planet's base heightmap, a 512x512 24-bit grayscale image of the planet's surface.
b) Next we get our local region in smaller and smaller increments, each 512x512 24-bit grayscale images.
c) Once that's done, we transfer an SVG-like data file that contains region and foliage information.
d) Next up is to update our texture cache. Textures should be mostly 512x512 and can contain multiple layers for things like normal maps and specular occlusion.
f) Last up are blueprints - CAD-like files that describe building and ship plans.
12. Let's assume that's it for now, we've got an updated cache of what we can get from the server.
13. Our client will now generate model data from the terrain information, which is a fairly simple process:
a) We start with a geodesic sphere with a radius defined by the PlanServ, and we start piling on terrain heighmaps at different detail levels.
b) As we get further in, we break apart a single sector into a new surface.
c) Each detail map transforms the model created by the previous one, so just because our local heightmap is flat doesn't mean we won't be looking at mountains.
d) The final step is where we are, which is fully localized so we're flat with the "world" as we walk around (it also helps with physics).
14. We actually start rendering during this process, just like Google Earth, as it gets us into the game as quick as possible.
15. The game loops through input and physics and continually talks to the server, sending the typical FPS netcode you'd expect to see (position, velocity, direction, whether and what we're shooting, etc.)
16. As we approach buildings, we create and render models for them from their blueprints, which define what blocks and textures to use.
17. As we move between different areas on the planet, we actively collect terrain information and start processing it (again, think Google Earth)
18. Now let's leave the atmosphere. Our ship has been rendered much like a building (using a blueprint and building blocks)
19. As we get further away from the planet, we're still connected to it. Drifting in space we'll take days (so, unless you're looking to reenact an episode of Star Trek, we strongly caution against it, and you'll always be able to repair your FTL drives to keep the game moving), so we make a jump, in true sci-fi style, through another dimension, traveling faster than light.
20. Our connection in slipspace (that's the term we're using it, call it what you want), you connect to a specialized SolServ that handles the deeper parts of space, until you finally get to your destination, at which point you connect to their SolServ and PlanServ, and the process repeats from #6.

So, I think that covers everything in a basic game.
To wrap it up, the planetary system works like Google Earth, but with multiple planets are considerably smaller. The game itself runs like any other game in localized blocks, say each city is its own server actively calculated physics. Side note: if a tree falls and no one is around to hear it, the tree won't actually fall.

Next week we'll be talking about the development project itself, how we're setting things up, and how you can help out, so be sure to check back for that. See you then!

Discuss this news post here.


Very informative post, thank you! Sounds like it's gonna be an awesome game, looking forward to it!

Reply Good karma Bad karma+1 vote

Wow. Very detailed indeed. But I can't help but need to ask a few questions on the architecture...?

First, where is all the model data saved? I know model and texture files can get lengthy. Won't that pile up pretty quickly?
Unless it wasn't saved on the computer but was transferred somehow through the server directly and consistently. (In that case explain.)

Second, you mentioned Planservs will support up to 100 players.
So planets then will support up to 100 players each?
What if the 101th player decides to enter the Planserv?

Third, When disconnecting from a Planserv into a Solserv, constant connection is maintained to the Userserv?
Whats being transferred exactly?

This is a nice server plan. Reminds me of some similar style ones.
Sounds like you'll need a insane Server to manage something of this scale though.

Reply Good karma Bad karma+1 vote
AdmiralBacon Author

Most model data is stored in the cache, and we don't plan on changing model data very often (and we'll try and keep everything available and up-to-date in distro package archives). You will store a cache on your own computer, and it's not that much of an overhead considering the system (there are only so many Lego bricks, and filling your bucket with one of each won't make it overflow).

The 100 player "limit" isn't a real limit, but rather, we'll do our bests to maintain speed and efficiency up to around 100 players, adding another player (or another hundred players) won't break things, but they may run slow. Some planets may even be split up into multiple servers if the need arises.

I assume you meant UniServ? The UserServ isn't part of this equation ;)
You're breaking a TCP connection to the Plan(et)Serv(er) you were originally connected to (because you're no longer communicating with it, and we need to free up connection space), and connecting to the "slipspace" SolServ that's available (slipspace won't be navigable as it is in some TV shows, so what SolServ you're on won't matter).

We're always looking for volunteers to offer their hardware up, especially if they're looking for something more hardcore than folding ;)

Thanks for the comments.

Reply Good karma+1 vote

I sort of see what you mean.
Though the big issue seems to be setting up servers. ;)

Good luck on that.

Reply Good karma Bad karma+1 vote

Thank god, it's still alive.

Reply Good karma Bad karma+1 vote
Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.