VERZ Online belongs to game genre sometimes known as PPBG, or persistent, browser-based games. This term is not as famous as RTS, cRPG or others but is similarly useful to describe something. In this entry the focus is on persistence.
Requirements of persistence
The game features concurrent access for all players and significant number of autonomous agents. Even when nobody is actively playing in given moment the inhabitants of fictional world move, space stations produce goods, combat rounds proceed, sectors regenerate resources and so on. It is ideal that players moving through disjoint spaces do not impact each other. Likewise many players moving at once should result in minimal impact for any of them. That is, we want low contention at high concurrency.
Second ingredient we need is correct state change. When someone finalises a trade, flies somewhere, accepts a mission or does anything that impacts game world, that change needs to be tracked and it needs to happen in consistent manner. When you want to purchase twenty units of robots priced at 5000 credits/unit and there is someone attempting to buy the same good, it would be best that either you simultaneously succeed at payment and purchase or fail both. Similar requirements holds for flying which costs chrono cycles. Either expenditure and flight succeeds or both fail. Those component actions are treated as parts of integral whole which must remain unbroken.
Finally, there is the question what happens is the game’s server has an outage which inevitably will happen sooner or later. All the player and internal actions that have been performed up to that point should have been saved and not require any special sorts of recovery. The actions that were in middle of execution must be treated as if they had never been started in the first place. Otherwise half-done changes staying half-written may compromise game state. We already had cases where you would be unable to fly because game has registered your ship in two places. Another example would be ship moved somewhere in flight but neither the fuel cost nor chrono cycle cost registered. Not to mention possible ambushes on the way. That is simply not to happen – data needs integrity.
On merging of game spaces
In the past weeks we run through the exercise of merging possible game spaces. By this we mean looking at various groups of “things” we have already and those we plan to add with the intent of seeing shared traits. Some examples below indicate the design questions found when defining database structure anew.
Spacecraft may transport cargo in cargo hold, and that cargo is typically commodities of some kind: water, chemicals, robots, metal. Spacecraft equipment also may be transported between storage sites. This includes missiles, ammunition but also engines, shield systems or anything you can install. Then the equipment may be installed also on building modules which incidentally may carry regular inventory. The result is definition of a chassis which represents set of equipment slots that can be installed into. Both space stations and spacecraft have a chassis to define what you can fit on it. Both also have cargo hold to define how much can be carried. Finally, regular commodities and equipment can be called items collectively, because they have quite much in common.
Similar line of thought was followed for player and non-player characters, which ended being just characters. We know that each player character pilots spacecraft and is free to change between them under certain constraints. There are some NPCs which use faction ships, namely the patrollers. They have some differing statistics but their loadout should be achievable by players since it is technically the same ship class. There are also contacts, namely non-player characters that do not appear in space but you can interact with them on planets and starbases. Continuing this line of thinking, if you allow highly skilled non-player pirate character to pilot a Corsair class corvette you might just get a famous pirate in result.
It also helps design regular organic opponents. If the space fly uses Erratic Flight as action ability of its wings equipment you should be able to target said wings to disrupt use of this ability. Never mind what would space fly need wings in void outer space for.
Benefits expected
The goal behind all the design approach is to keep number of distinct game spaces low. Otherwise we might need to define some behaviours several times. Take docking; you may dock in planets, starbases, stations and other ships. Similarly equipment; installing equipment can be done both on your defensive modules in buildings and on your ships. There is no conflict because you cannot install engine on station defence tower. It does not have necessary engine equipment slot for that to work. Thanks to those decisions the docking code needs to handle that in a single way no matter where you dock and no matter where you install equipment piece. For docking you need enough space and permission, that is all. For installation you need the equipment available on site and a place where it could be installed.
One obvious benefit we gain this way is savings in terms of distinct code paths to maintain. This is very nice but what we look most forward to is having depths of mechanics which will let us enjoy the game for long time in future.
