This is... just about everything. news - Entropy

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.

Overview:
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 76.189.178.118 (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.