CYBERNATION
June 2019 development progress
Bodum
06/16/2019 at 14:32
It has been a while since I published our last development update. Developing an MMO game with a small indie team is an exciting adventure! Unfortunately posting development updates competes with all the other work we have to do, hence the multi-month silence. Luckily we've built a bunch of very important core systems and I'm going to share the progress with you right now!
I will go into some technical details a bit later, and first I’d like to give a short overview of what our release plans are, as it will justify some of the technical decisions we made. Cybernation Online will ultimately be an open world sandbox MMO game with a lot of game systems: world exploration, space and planetary combats, resource mining, information wars, quest lines, procedural history generation and many more. Should we have a decent budget, we would build everything immediately and presented you the full experience from day one. The reality is that we need to build a relatively small but fun game, launch it, and then incrementally open up new features. The more successful the first part will be, the faster the development will happen.
We decided that our first release will be a multiplayer online battle arena (MOBA) with exactly the same core mechanics that will be in the future MMO, namely bot assembly mode and the bot combats. It won’t be an MMO yet, but later we’ll connect it to the wider world by opening new locations, introducing player to player trading, individual assaults, robberies, clans, guilds, wars, PvE encounters and other attributes of an MMO game.
Now what it means for the development. Building a MOBA is a much simpler project than building an MMO, but given the fact that it needs to undergo the conversion at some point, a lot of MMO subsystems have to be implemented from the beginning. For example, consider a combat. In a regular MOBA, a map is loaded from a file or a database, then the game runs, and the memory is freed at the end. When the next game starts on the same map, it’s loaded from the same file again. In an MMO world there must be persistency in place. For example, if I build a watchtower, it has to stay around even if I come back tomorrow or in a month or in a year. Of course it’s not needed for our MOBA mode, but the location engine must have this persistency capabilities built in, so it can be utilized later. And such examples are myriads. I’ll give a short overview of what we’ve built already, and as you can imagine, all of those subsystems will find its place in the MMO world.
Single sign-on and security
That’s the very first system that our players face when they interact with the game. Right now you can sign up for future updates on the website, and the same account is used for posting on the forum. Needless to say, the same authentication system will power the game too. This system includes: sign-up, sign-in, password recovery, changing the password, fine-grained bans (full ban, inability to post to the forum, etc), admin panel for seeing the history of security events, etc.
As this system is used to authenticate the players, all future improvements to the security system (such as second-factor authentication or automated security violation detection) will be automatically applied to the entire security perimeter, making sure that all the game entry points are equally protected.
Text content rendering
The game itself is a client-side application built with Unity. It renders UI with the tools available in the engine. The game website employs a completely different technology stack — it has to produce HTML pages which are then rendered in a browser. In the future, when the game gets its own mobile applications, it will be a third completely different surface. When you, our future players, access game data through the game API, you’ll also need to present the same information in the tools you build, and that will be just another different media.
Despite that all the surfaces are very different, they have to present the same information from the game engine: character names (with all their clan icons pointing to their profile pages when clicked, other status icons, levels), items and the item properties (an image of an item, it’s stats, description, all formatted in a way defined by the game), chat messages (that may contain embedded media, highlighted character names, clickable names of the locations, items, planets, etc) — each item is a fairly complex piece of data that however needs to be displayed on different platforms.
We’ve designed a special structured data format based on protobuffers that allows the servers to always serve their data in the same format regardless of the rendering surface, and then the client, website, forum, library and clan-sites may adapt and display them as they see fit. All our internal systems operate on those data structures, and that’s important to build it at the beginning to make sure that the future development of new surfaces will be easy and straightforward.
Game state synchronization
In order to minimize the risk of cheating, our game always runs on the server, and the clients receive only the information they are allowed to see at each given moment of time. That implies certain restrictions on the implementation. As game units have their limited range of sight and each player may control a handful of units (robots, bathyscaphes, spaceships, buildings), each character may have a very sophisticated range of sight — it’s a union of ranges of all their units. Add to this the fact that when some characters are allies, they may exchange the visibility data and see everything other characters see. Also all of that is very dynamic — as units move, their ranges change accordingly. We need to dynamically recalculate who sees what and send respective events to the game clients to show or remove certain objects.
There is another layer of complexity due to the fact that the units may have various parameters (such as HP, energy levels, shield integrity, battery capacity and many more) and not of them are accessible to everyone. If I own a robot, I see all its parameters. If I’m an enemy and see the same robot, I see its position, orientation, but not the internal parameters, unless I have a detector which reveals a subset of the hidden parameters, which may have their own detection ranges, and so on and so forth. The system we’ve built is performant enough to solve those dynamic constraints in massive combats in real-time.
Another aspect of the game state synchronization is how we handle network latency and system lag. What if a robot moves a few tiles left in 1.3 seconds, stops at the shooting position and fires a few missiles, so each of them takes 0.6 seconds to reach the target? We can’t predict the future to plan all the interactions at t=0, because any of them may be affected by other players’ actions or other events. We need to execute each operation in sequence: at t=0 we are at the initial position, at t=1.3 we need to stop at the target position, and at t=1.9 we need to incur the damage. However, what happens if the server was busy doing something else at t=1.3 and couldn’t start shooting? Cybernation Online server goes “back in time” and executes the actions at the time they were supposed to be executed, thus compensating for the server lag, and then it sends the events to the clients with exact timestamps of when the events were supposed to happen. The clients take those timestamps into account and show the events as precise as possible, hopefully giving you the smoothest game experience possible.
World persistency
Although we won’t strictly need world persistency from day one, the necessary support is already implemented in the engine. World positions and other parameters of the units (energy levels, hitpoints, etc), all buildings built by the players, all destroyed walls — everything is saved in the database. Regardless of what happens — the server restarts, or all the players leave the location and it gets unloaded, the state is preserved, and next time when the players come back to the location, they see exactly the same location.
The technically interesting part is how we save locations in the background. Our location is a unit of consistency. That means that all game interactions between game objects (shooting, construction, entering or leaving the location, etc) are always contained within one location and are executed atomically. When the engine needs to save a location, it stops the world, take a snapshot of all modified objects (that’s very fast), unpauses the world and saves the objects in the single database transaction in the background. If the saving success and the objects haven’t been modified since the snapshot time, the objects are not considered modified anymore.
Doing that system properly is critically important for seamless operation of the online world (minimum of server lag and a little dependency on the hardware performance as possible) and the best player experience.
Game simulation
That’s the core part of the entire game. The game simulation module defines what the game rules are: which units can be controlled by whom, how they perform the actions, what happens when, and so on. We’ve implemented basic actions that can be performed by a character: moving robots and shooting each other in 2 different ways: with single shot bullets and with continuous laser beams.
Separately we’ve built an internal scripting engine that allows to run game script in response to events, and extensibility of this system allows us not only to define complex object interactions at game development time, but also have things like procedurally generated quests that we promised to deliver.
Currently this is the system that gets the most attention from me personally. I want to make it as flexible and performant as we need for such a complex game that we are developing.
Chat
Cybernation Online chat system is capable of handling multiple chat channels with different access restrictions: local city chats, clan chats, raid chats, combat chats, private chats, etc. Some of them will be created and removed automatically (when you move across locations or enter/exit combats), while some of them will be persistent (such as private chats with friends).
Remember the section about content rendering? The chat fully supports it! It will be possible to send entity references to the chat, for example links to the planets you discovered or new weapons you crafted, and the recipients will see a nice info block about those objects and a link to get more information right in the chat.
Items and inventory
(These are the test items, they won’t appear in the game, of course).
The game has all necessary backend support to perform operations on the items: owning them, passing to other characters, loading on the ships, mounting on the robots, trading, etc. To minimize the chances of item loss or duplication, all the operations are transactional. For example, if an object is moved from object ship to another, it is guaranteed that either both operations will complete or both of them won’t complete, so the object will neither disappear (which will cause frustration of the players) nor duped (which will cause frustration of their enemies). We are doing our best to make the game logic as correct as possible.
Client deployment
The last aspect of the MMO game development but not the least is how to deliver the game to the players’ computers. It involves a few steps: the continuous deployment system builds the release candidates, they are signed with the Microsoft Authenticode signatures and deployed on the staging servers. Then the release is tested by the team and released to the players. On the players’ computers everything starts with a launcher that maintains the index of what components are already installed, checks the integrity of the game files, downloads missing or corrupted components and finally launches the game.
Although currently the game is always downloaded in full, with all its assets, we’ve made it possible to stream the game assets (models, textures, sounds, etc) on demand. For the desktop version of the game it is less of a problem, but for mobile applications it will be important to reduce the initial download size.
Future plans
We are heading full steam towards the minimum playable version of the game to validate our core concepts and invite our first alpha testers. As we see it today, the game will include: the lobby (a few city locations where the players walk around, meet other players, chat with them, access the bot assembly interface and the shop), the matchmaking system and the combat itself.
I hope it was interesting, and if you have any questions feel free to ask them in the comments or start new topics on the forum!
I will go into some technical details a bit later, and first I’d like to give a short overview of what our release plans are, as it will justify some of the technical decisions we made. Cybernation Online will ultimately be an open world sandbox MMO game with a lot of game systems: world exploration, space and planetary combats, resource mining, information wars, quest lines, procedural history generation and many more. Should we have a decent budget, we would build everything immediately and presented you the full experience from day one. The reality is that we need to build a relatively small but fun game, launch it, and then incrementally open up new features. The more successful the first part will be, the faster the development will happen.
We decided that our first release will be a multiplayer online battle arena (MOBA) with exactly the same core mechanics that will be in the future MMO, namely bot assembly mode and the bot combats. It won’t be an MMO yet, but later we’ll connect it to the wider world by opening new locations, introducing player to player trading, individual assaults, robberies, clans, guilds, wars, PvE encounters and other attributes of an MMO game.
Now what it means for the development. Building a MOBA is a much simpler project than building an MMO, but given the fact that it needs to undergo the conversion at some point, a lot of MMO subsystems have to be implemented from the beginning. For example, consider a combat. In a regular MOBA, a map is loaded from a file or a database, then the game runs, and the memory is freed at the end. When the next game starts on the same map, it’s loaded from the same file again. In an MMO world there must be persistency in place. For example, if I build a watchtower, it has to stay around even if I come back tomorrow or in a month or in a year. Of course it’s not needed for our MOBA mode, but the location engine must have this persistency capabilities built in, so it can be utilized later. And such examples are myriads. I’ll give a short overview of what we’ve built already, and as you can imagine, all of those subsystems will find its place in the MMO world.
Single sign-on and security
That’s the very first system that our players face when they interact with the game. Right now you can sign up for future updates on the website, and the same account is used for posting on the forum. Needless to say, the same authentication system will power the game too. This system includes: sign-up, sign-in, password recovery, changing the password, fine-grained bans (full ban, inability to post to the forum, etc), admin panel for seeing the history of security events, etc.
As this system is used to authenticate the players, all future improvements to the security system (such as second-factor authentication or automated security violation detection) will be automatically applied to the entire security perimeter, making sure that all the game entry points are equally protected.
Text content rendering
The game itself is a client-side application built with Unity. It renders UI with the tools available in the engine. The game website employs a completely different technology stack — it has to produce HTML pages which are then rendered in a browser. In the future, when the game gets its own mobile applications, it will be a third completely different surface. When you, our future players, access game data through the game API, you’ll also need to present the same information in the tools you build, and that will be just another different media.
Despite that all the surfaces are very different, they have to present the same information from the game engine: character names (with all their clan icons pointing to their profile pages when clicked, other status icons, levels), items and the item properties (an image of an item, it’s stats, description, all formatted in a way defined by the game), chat messages (that may contain embedded media, highlighted character names, clickable names of the locations, items, planets, etc) — each item is a fairly complex piece of data that however needs to be displayed on different platforms.
We’ve designed a special structured data format based on protobuffers that allows the servers to always serve their data in the same format regardless of the rendering surface, and then the client, website, forum, library and clan-sites may adapt and display them as they see fit. All our internal systems operate on those data structures, and that’s important to build it at the beginning to make sure that the future development of new surfaces will be easy and straightforward.
Game state synchronization
In order to minimize the risk of cheating, our game always runs on the server, and the clients receive only the information they are allowed to see at each given moment of time. That implies certain restrictions on the implementation. As game units have their limited range of sight and each player may control a handful of units (robots, bathyscaphes, spaceships, buildings), each character may have a very sophisticated range of sight — it’s a union of ranges of all their units. Add to this the fact that when some characters are allies, they may exchange the visibility data and see everything other characters see. Also all of that is very dynamic — as units move, their ranges change accordingly. We need to dynamically recalculate who sees what and send respective events to the game clients to show or remove certain objects.
There is another layer of complexity due to the fact that the units may have various parameters (such as HP, energy levels, shield integrity, battery capacity and many more) and not of them are accessible to everyone. If I own a robot, I see all its parameters. If I’m an enemy and see the same robot, I see its position, orientation, but not the internal parameters, unless I have a detector which reveals a subset of the hidden parameters, which may have their own detection ranges, and so on and so forth. The system we’ve built is performant enough to solve those dynamic constraints in massive combats in real-time.
Another aspect of the game state synchronization is how we handle network latency and system lag. What if a robot moves a few tiles left in 1.3 seconds, stops at the shooting position and fires a few missiles, so each of them takes 0.6 seconds to reach the target? We can’t predict the future to plan all the interactions at t=0, because any of them may be affected by other players’ actions or other events. We need to execute each operation in sequence: at t=0 we are at the initial position, at t=1.3 we need to stop at the target position, and at t=1.9 we need to incur the damage. However, what happens if the server was busy doing something else at t=1.3 and couldn’t start shooting? Cybernation Online server goes “back in time” and executes the actions at the time they were supposed to be executed, thus compensating for the server lag, and then it sends the events to the clients with exact timestamps of when the events were supposed to happen. The clients take those timestamps into account and show the events as precise as possible, hopefully giving you the smoothest game experience possible.
World persistency
Although we won’t strictly need world persistency from day one, the necessary support is already implemented in the engine. World positions and other parameters of the units (energy levels, hitpoints, etc), all buildings built by the players, all destroyed walls — everything is saved in the database. Regardless of what happens — the server restarts, or all the players leave the location and it gets unloaded, the state is preserved, and next time when the players come back to the location, they see exactly the same location.
The technically interesting part is how we save locations in the background. Our location is a unit of consistency. That means that all game interactions between game objects (shooting, construction, entering or leaving the location, etc) are always contained within one location and are executed atomically. When the engine needs to save a location, it stops the world, take a snapshot of all modified objects (that’s very fast), unpauses the world and saves the objects in the single database transaction in the background. If the saving success and the objects haven’t been modified since the snapshot time, the objects are not considered modified anymore.
Doing that system properly is critically important for seamless operation of the online world (minimum of server lag and a little dependency on the hardware performance as possible) and the best player experience.
Game simulation
That’s the core part of the entire game. The game simulation module defines what the game rules are: which units can be controlled by whom, how they perform the actions, what happens when, and so on. We’ve implemented basic actions that can be performed by a character: moving robots and shooting each other in 2 different ways: with single shot bullets and with continuous laser beams.
Separately we’ve built an internal scripting engine that allows to run game script in response to events, and extensibility of this system allows us not only to define complex object interactions at game development time, but also have things like procedurally generated quests that we promised to deliver.
Currently this is the system that gets the most attention from me personally. I want to make it as flexible and performant as we need for such a complex game that we are developing.
Chat
Cybernation Online chat system is capable of handling multiple chat channels with different access restrictions: local city chats, clan chats, raid chats, combat chats, private chats, etc. Some of them will be created and removed automatically (when you move across locations or enter/exit combats), while some of them will be persistent (such as private chats with friends).
Remember the section about content rendering? The chat fully supports it! It will be possible to send entity references to the chat, for example links to the planets you discovered or new weapons you crafted, and the recipients will see a nice info block about those objects and a link to get more information right in the chat.
Items and inventory
(These are the test items, they won’t appear in the game, of course).
The game has all necessary backend support to perform operations on the items: owning them, passing to other characters, loading on the ships, mounting on the robots, trading, etc. To minimize the chances of item loss or duplication, all the operations are transactional. For example, if an object is moved from object ship to another, it is guaranteed that either both operations will complete or both of them won’t complete, so the object will neither disappear (which will cause frustration of the players) nor duped (which will cause frustration of their enemies). We are doing our best to make the game logic as correct as possible.
Client deployment
The last aspect of the MMO game development but not the least is how to deliver the game to the players’ computers. It involves a few steps: the continuous deployment system builds the release candidates, they are signed with the Microsoft Authenticode signatures and deployed on the staging servers. Then the release is tested by the team and released to the players. On the players’ computers everything starts with a launcher that maintains the index of what components are already installed, checks the integrity of the game files, downloads missing or corrupted components and finally launches the game.
Although currently the game is always downloaded in full, with all its assets, we’ve made it possible to stream the game assets (models, textures, sounds, etc) on demand. For the desktop version of the game it is less of a problem, but for mobile applications it will be important to reduce the initial download size.
Future plans
We are heading full steam towards the minimum playable version of the game to validate our core concepts and invite our first alpha testers. As we see it today, the game will include: the lobby (a few city locations where the players walk around, meet other players, chat with them, access the bot assembly interface and the shop), the matchmaking system and the combat itself.
I hope it was interesting, and if you have any questions feel free to ask them in the comments or start new topics on the forum!
storm
08/31/2019 at 13:51
Lekan
10/03/2019 at 12:35
Bodum
10/03/2019 at 16:50
success
10/08/2019 at 11:22
derek
10/25/2019 at 08:17
xxx
12/04/2019 at 11:10
Algia Athene
12/17/2019 at 10:44
Batang Dragon
07/17/2020 at 05:17
n0ta1k
02/28/2021 at 03:05
Bodum
02/28/2021 at 11:47
