Week 4 Version 0.3

10 Oct 2019

Version 0.3 of Dwerg Saga is now available for $3-tier patrons via itch.io. Changes in this version:

By this point I hoped to have the persistent-universe version of the game available. That hasn’t happened so I’ve taken a bit of time to map out exactly what needs done and investigate areas of uncertainty to come up with a more accurate estimate of when it will be ready. The new estimate is a further 23 days.

Have fun and try not to drown your Dwergs!

Drowning Dwergs


This week I’ve been fixing lots of bugs with the networking code that handles re-syncing the game state with clients when lag causes them to get out of sync. I had previously tested this with a host and a single client but had failed to take into account the complexities introduced by additional clients that don’t necessarily require a full re-sync. I’m tempted to just re-create the host in the same way as the clients and send the same state to all clients regardless of whether they requested the state or not. The trade-off is increased complexity vs increased network traffic. I took a day away from programming to think about this.

I almost managed an entire day of not programming. Pixel-art; I acted on some feedback that the solid terrain was not distinguishable from the floor, got the silhouette of a Fisher-Dwerg, went to Konbo to chat with fellow edindies, fiddled with the water textures but ended up also adjusting water transparency in code. I concluded I would live with the increased complexity for game-syncing over the network but will re-assess if it continues to cause problems.

On Sunday I did a refactor; wrapping the networking library so I can test my use of it and removing the dependency between my server and the world simulation. Sweet, I can now write tests around the server in a tiny solution file, super-fast code-build-test cycle. I completed full test-coverage of the game networking code, improving my understanding, adding better error-handling and removing some pointless code. This area of the app is complex because a peer is both making connections and accepting connections. Peers should now work over the internet as they make direct connections with IP addresses instead of relying on local network discovery, essential for the dedicated server.

I spent some time investigating Amazon EC2 instances and decided I can use these to run the game using an Amazon Machine Image. I’ve run a VirtualBox with Amazon Linux on it locally and verified I can build and run .NET core console applications on it. This is the work I need to do next along with approximate estimates:

There are some caveats to this estimate:

Development Process

When I went to work for a little app development company called Kotikan, I was introduced to the discipline of Test-Driven Development and the brilliant Uncle Bob. Having worked with large code bases in the past and endured the pain of long build times, I wanted to always ensure that Dwerg Saga would have very short build and test cycles. I’m happy to say that I have achieved this.

The core of Dwerg Saga is a library that depends only on .NET Standard and an implementation of Google’s protocol buffers. Development of new features is test-driven and usually involves creating a tiny 3x3x3 world, spawning the required elements, running the update loop a number of times and then asserting something about the world that has changed. This ability to develop features without having to run the full game means I can develop new features quickly and with confidence that they won’t break existing features. After completing the fluid simulation I was able to separate it from the core of the game and it is now independently testable. As the game grows I expect to break out separate libraries to ensure high productivity.

- Jock

Enter your email to receive a monthly summary of development progress on Dwerg Saga.


This website uses cookies to anonymously track traffic.
Privacy Policy