31 Oct 2019
I spent Thursday extracting the world-generation from the simulation for the cloud service. The new world generation produces a world-state; the same state that is saved to storage and transmitted in networked games. To verify the new world generation is producing the same thing I set up a test that constructed a world in both ways and verified their check-sums were identical after each update. While running this test I discovered a bug with the water update where two identical fluids would diverge. I’d been aware that the water checksum was the cause of de-syncs in networked games so I was happy to find a fix for it. Despite having full test-coverage this bug had slipped through because there were no tests that verified identical fluids in two simulations remained identical over time. Shortly after fixing this problem I encountered an intermittent failing test on the fluids; it turns out the ordering of pool updates was also necessary when saving the fluid state. So no, unit tests don’t guarantee perfect code but they sure do find things you overlook.
The new world-generation was largely complete by Saturday morning and I continued with the connect-to-game Lambda function. My initial plan was for separate Lambda functions to create and store worlds, start game-server instances and connect users to them. The user must wait for all of these things to happen before they get into a game so this functionality is all in a single function.
Before getting into the launching of EC2 instances from the Lambda function, I made a server-launcher application that downloads the latest dedicated-server build and the world for the user’s location and launches the server with that world. The instance is made from a template with the server-launcher pre-installed. The AWS .NET SDK is nice to work with because all the major components have interfaces so mocks can be generated by Visual Studio.
On Sunday morning I took a walk with friends to Blackness Castle and enjoyed a Lemon Sole at The Lobster Pot. It was great to get out, enjoy the fresh sea air, the company of real humans and imagine Dwergs storming the castle.
I finished the server-launcher on Monday and was able to launch an instance that started a dedicated-server with a world from S3. There are some open questions about how errors are communicated back to the user from the instance via the Lambda. These will be addressed later. Launching the instance from the Lambda turned out to be a stumbling block and had me trying various methods before realising the Lambda function was on a VPC and I needed to make an endpoint on the VPC to access the EC2 service. I had already done this for the S3 service so it shouldn’t have been a problem. Over the next week I will document the cloud infrastructure to solidify my understanding of it and help me when it comes to replicating it in other AWS regions.
On Tuesday and Wednesday I continued developing the connect-to-game Lambda function and the client-side communication with it. The game now sends the user’s location and connects to the game running the world for that location. Hurrah!
I’ve contracted a musician, Frans Hipponen, to make some music for the game. He made a track that I think works well with the game, I’ll share it with you beautiful patrons in another post shortly.
Looking at the plan I appear to have progressed 10 days of work and reached my second checkpoint. Sweet! It does take about 5 minutes for a server to get started. This is a ludicrous amount of time for a user to wait so I will be looking into making standby servers immediately after release. Over the next week I will implement the dedicated server saving the world state, updating the game database and terminating the instance when all users have disconnected. Once that’s done I will handle error-cases and messaging of errors to the user. Then it’s testing from various cafes, hot-desks and homes.
Enter your email to receive a monthly summary of development progress on Dwerg Saga.