Tallowmere 2: Curse of the Kittens

Networking

Past two months have largely been spent working on networking.

Got to the point where I can have a server sitting in the cloud, then someone starts their game client and goes through the setup to start hosting a game (or create a pre-game lobby anyway), and adjust their game's settings as needed.

But internally, I've come to a decision that I need to have all my game's data be largely stored in a flat relational-database-esque structure, rather than object-oriented hierarchies.

netIDs

Each thing in the game needs a netID number. Sometimes creatures need to know who their parent creature is (if they're a minion). If there's a master creature, it needs to know who their minions are.

Further example, inventory items likely belong to a parent inventory. A creature could have an inventory, or a treasure chest could have an inventory, or a bag inside a bag could have an inventory. So when it comes to a server action such as, "Sell item with netID X" or "Enchant item with netID X", the server and/or clients needs a quick way to find said item when it receives the packet message.

So I have been working on refactoring things into a database-like storage structure, with netIDs as keys, and basic classes as the content. For parents and children, netIDs are stored rather than direct references to each class. Each instance of a class is stored in its own Dictionary, akin to a database table. A netID tracker tracks which netIDs are in use, and frees them up when an object is destroyed.

Client Authority

Further with networking, as Tallowmere 2 aims to allow jolly co-op, I am giving the host and/or servers the option to allow clients to have authority over a lot of actions.

Since the gameplay largely involves using your shield at the correct time, while also wanting to ensure spamming weapon attacks and instantiating fireballs and other projectiles feels as smooth as possible, I'm working towards a model where a lot of combat decision-making is managed by each client, rather than the server. This eliminates the need for everything to be server-authenticated, and means you can play with people even if your pings are very high.

From a cost-effectiveness standpoint, not requiring the server to authorise stuff means I can have one server host multiple games with many players at once, rather than restricting one server to only allow up to 4 players at a time. As I want to support desktop, mobile, and consoles, I do not want to rely on one client being a host if possible (for if the host disconnects, everyone disconnects). By offering simple message-passing servers in the middle that don't do any heavy processing, said servers can easily retain game data in the event that a player disconnects, thus allowing them to reconnect and rejoin their game.

But to retain game data, the data needs to be kept in a simple format, which is why I'm refactoring things off of the heavy MonoBehaviours that Unity uses, and storing data into regular classes instead. It's a fair chunk of time and effort to shift how I'm storing things internally, but will be worth it.