Last post I mentioned Fractal, the game engine powering Deepfield. In this post I would like to give you a rundown of what Fractal is and our plans with it.
Our goal is to give developers the ability to create extremely large game universes which can support a huge number of concurrent entities. We want to do this while being as developer friendly as possible.
Being developer friendly means different things to different developers. For some it means a simple interface that’s quick to understand and therefore the ability to get started and build quickly. For others it means the option to customise, pick and choose components and have low level control. The list doesn’t end there though, good documentation, debugging tools, compatibility with existing game engines and libraries, there are many many other things.
We’re trying to strike a balance between all of these things. In some cases there are tradeoffs, othertimes if we can figure out a way which you can have your cake and eat it too, we’ll give that a go.
Developer features have we have added so far:
- Compatibility with most game engines like Unity, UnReal and CryEngine. We’ve done this by making the client a DLL library. It’s not as easy as “Install asset from store and automatically configure” but that’s something we can look at doing in the future.
- Self hosted or dedicated; run the server where you want it, how you want it.
- Logs, lotsa logs! All system events and application messages are logged on both the client and server. Server messages are logged to console (and optionally to file). In the case of Unity, client messages are logged directly to Unity’s console.
- Command line debugging tools for the server. Simulate connecting to another server as a client, run network tests, spawn or destroy entities and more; I’m sure we’ll be adding more command line tools as we find a need for them.
- SPY. This is our GUI debugging tool for client and server and it deserves a feature list on it’s own:
- See what the client and server sees in real time: Fog of war, entity pathing, entity vision, size of entity colliders and more.
- Zoom and pan around the map.
- Status bar: Zoom level, number of connected clients, network transfer rates, position of cursor, number of factions, number of active and total entities.
- Entity inspection. Click on an entity to bring up an inspection window; view properties such as the size of the entity, it’s faction and it’s velocity. You can change an entitys faction from here as well.
- View filters. Filter what’s on screen by faction, turn on/off fog of war, entity pathing or vision.
- Spawn or destroy units.
- Add or remove factions.
- Move entities by setting waypoints for them.
- Modules: The ability to pick and choose the components you want. Don’t care for our waypoint and pathfinding system? Get rid of it.
HUGE props to omNomios for designing and implementing all of the above!
Note: They’re working but none of the features mentioned above are anywhere close to being finished; they are all constantly being improved and made more reliable.
Let’s talk about server architecture, game features and limitations.
A simple server is one that looks after the entire instance of a game; the server is the single source of truth and all players connect to, send and receive updates from the same server.
We want Fractal to support extremely large universes with a high number of concurrent entities, this won’t be possible with a single server.
We’re taking a fairly common approach to this problem: Splitting the universe into sectors.
Each of the predefined sectors which will handled by their own server. A sector server does what a simple server does but just for it’s sector; it is the source of truth, processes application logic and sends/receives entity updates.
For a single instance of a game there is one hive server. The hive server is reponsible for a few things:
- Managing client connections and routing them to the appropriate sector server.
- Managing sector servers, spinning them up and down as required.
- Simple sector logic, for example movement of an entity from one sector to another. The greater the distance between the sectors, the longer the travel time is.
- Periodically saving the state of each sector server so that it has a picture of the entire game universe, this is done to work out the state of the sectors and handle inter sector movements.
This is the server architecture plan for Fractal 1.0 (to be used in Deepfield 1.0). I’ve left out a lot of the implementation/tech details, I might go over this in a future post when the engine is in more of a reliable state.
Let’s have a quick look at the features Fractal 1.0 enables:
- Theoretical maximum game universe size of 9.2E18 meters^2. This is limited by the biggest number we can use to define address of a “cell” in the universe, in C++ we can reference the integer limit LLONG_MAX (9,223,372,036,854,775,807).
- Maximum number of sectors isn’t a number I’m going to waste my time on. It’s likely that the size of a sector will be set via game design and any reasonable number we would want to set would be possible. Sectors that are too small won’t be able to support fun gameplay and sectors that are too large will feel too empty.
- Maximum concurrent entities in the game universe is a little harder to estimate. This number is more or less the max active entities per sector multiplied by the number of sectors in the game universe. The theoretical max active entities per sector is roughly 65,000 however, this doesn’t take into account the complexity of the entities, server hardware or the minimum desired performance (server ticks per second, desired latency etc).
- Maximum number of players in the game universe is similar to the maximum concurrent game universe entities; the real bottleneck is the number of entities and the bandwidth required to sync them. Whether there is 1 player controlling 100 entities or 10 players controlling 10, that’s a bandwidth of 100 entities. HOLD UP… yes that means that a single instance of the game could support 100s if not 1000s of players. Don’t hold me to any numbers yet though, we still need to test it; in saying that I can promise you it will be more than your standard 8-12 players.
Next, limitations and how we’re planning to use game design to get around them:
- No cross sector action. If two sectors are next to each other, players will not be able to engage in combat (or anything) across the sector bountry. Deepfield will use design of the universe to get around this. All sectors will be islands with inter sector space between them which takes time to traverse; only certain units will be able to jump from sector to sector.
- The player can only have direct control in one sector at a time. We have a few game design elements which will make this less of a headache. This probably deserves a post on it’s own so I’ll skip the detail for now.
Lastly, the plan moving forward.
I mentioned in the last post that Fractal is our core product, this means that all of our games will be built on it. That’s why we’ve taken the time to completely decouple it from Deepfield. We want it to be as developer friendly as possible so it’s fun and efficient to use because we’re going to be spending a lot of time with it. Future developers who join the team will also benefit from the ground work we’re putting in now too.
I’m probably getting ahead of myself here but if we can prove Fractal as a networking framework, we can start licencing it to 3rd parties without having to modify anything.
I started referring to Fractal as Fractal 1.0 when I started talking features, yes that means we already have 2.0 in mind. The vision for the future is to create an engine capable of handling the scale of 1.0 while dissolving the boundries between sectors and making the entire universe continuous.
We have to learn how to walk before we can run, it’s already feeling like QWOP as it is.