Continuing Game Server networking, loading and saving data.

Continuing Game Server networking, loading and saving data.

Today I hope to have the networking between the Client, Login and Game Servers all worked out and the client transferred over to the Game Server after logging in. Then I will make a basic test apartment and start working on loading player data and player slime data on the Game Server, then transferring what is needed to the Client.

The client needs to be able to download the slime sprites from the API, I may write a pass-through on the game server to handle that but I suspect that might not be wise. I could directly connect to the object store and pull the data that way but I suspect that would be easier said than done with how the data is transferred.

I would like to do some experiments with my pre-composited sprites vs sprites assembled in-engine. If I can have a load of sprites just assembled by the client itself without a large hit to performance I would like to explore that avenue as I could add even more parts, particle emitters, shaders, etc. The reason for the compositor is to save resources in the client for other things, but also to allow web-based front-end stuff later on down the line.

Anyway, all of this is pointless until I get the network code sorted. Better get back to it. I will pass the token and the player's user ID from the login server over to the Game Server, then lookup their character and slimes. I will store the player and their slimes as nodes with a hash-table lookup to hopefully make retrieval quicker.

I would also like to set up an endpoint for tracking the servers, their locations, their IPs and their ports. It could be useful for tracking server population later on, for now though I think it will help me with deployment. Not high priority at the moment, worth noting though.

Game server->API Connection Established.
Data Transferred to Game Server on Login.

Next I need to set that data up properly so when the client is handed over it will have the data ready to assign to it's connection.

Player Data Instanced in Game Server
Contents of Player Data
Game Server Log on client Connection.

Now the login server is handing off the client to the game server. Next the game server has to gather all the player data, characters, slimes, apartment, whatever else it will need to send to the client to load in.

Before that I need to make sure the Login Server is handling loss of connection to the Game Server correctly and that the Game Server knows when a Login Server is disconnected and removes it from the list.

Likewise I need to make sure failed transfers from the Login to the Game server are cleared up when things go awry. Don't need no memory leaks.

Beaker from the mupets quivering in fear
Mimimi mi mimi mi.

I've written a wrapper for the HTTPRequest node in order to clean up the connections made afterward. There was a memory leak caused by the HTTPRequest nodes sticking around after API calls. Now they will self-destruct after 32 seconds.

Nice and clean.

No more instances of HTTPRequest hanging around.

The login server is now able to clean up after all it's connections, failed or successful. Next is the game server, which will be a little more complicated. Before I get on to that though I want to write a reconnect function in the login server to retry connecting to the game server whenever connection is lost. I will be restarting the game server a whole lot and having to restart both every time will be... time consuming.

Automatic reconnect implemented.

Alright, now to start cleaning up on the Game Server connection handlers.

That handles cleaning up the Player data.

I need to clean up any half-finished connections in the player transfer into game server.

There, now any broken logins will be cleared after a few seconds.

With that I should probably get on to loading actual player data into the server. I will use my HTTPRequest wrapper to gather the data from the API, though I may need to write another endpoint.

Player and Slime data loaded.

Took a bit of messing around with DRF's documentation but I eventually found a way to load them as part of the serialized API.

I'll have to write a pagination handler to lessen the load on the slime API, there's a lot of data coming out of there. Every 100 slimes is a page.

On second thought, let's not load hundreds of slimes on player login. That's not a smart choice. Let's only load the ones that are not Frozen, therefor active. We can load the rest, paginated... later. With the freezer system.

Now to process that data on the server and send what is relevant to the client. Then tomorrow I can work on loading all this in the client.

An interesting bug, I can not put/patch to save the slimes from the game server UNLESS I go into the API tester and run a PUT on the slime from there at least once beforehand. I did so on three of the slimes...


I think I might understand it, I noticed that the ones I did update that way have lost some data, their sprite URLs. So, perhaps it has something to do with an attempt to overwrite the sprite URLs from the save function in the Game Server? Let's see...

That's it.

Bug fixed.

Player data saving as well;

Now I just want to write a timer that will automatically fire these save functions every 10 minutes.

Save every 10*60 seconds.

Now that I can load and save players and slimes on the game server it is time for me to make some dinner. Finished just in time at 5pm.