Hey there! It has been a bit of a slow week for us.

We were finishing up some stuff from last week, mainly the map system, and reworked our automated tests, which check the functionality of the core.

Finalizing the Map System

As mentioned last week, we implemented a new Map System for our 3D switch. At the time of writing, it’s very close to being done. The Map is done, Tests are written and passing, and we even have the first version of our pathfinding working again.

However, we did some small changes. Mainly that we are now using 32 bit instead of 16 for each voxel. This means that we now have (2^16)-1 concurrent IDs in the game. The other 16 bits are used for metadata, like type identifiers, collider information and more.

Automated Testing

We spend most of the week with writing automated tests. As a non-developer (or maybe a young dev), you might now know what these are. So let’s take a quick look at it.

Tests are small pieces of code that confirm the functionality of other code. This is done by setting up a certain scenario, feeding in data to the code which is tested, and then comparing the results with the expected values. If the results are equal, we can know fairly certain that our code works. If the values differentiate, we know that something’s fishy.

Of course, this is extra work. But in most cases, it’s worth it. Whenever we make changes to our code, all tests are executed automatically by our CI system and we can immediately see if we broke something. A small change in code can easily break something somewhere else. These bugs can be hard to track down, especially when it’s been there for a while and nobody encountered it.

Some companies like to test every single functionality, however, we think that in the case of Game Development, it doesn’t make sense. Especially for simple methods like the addition of two vectors. It’s just a single line of code. It would take much longer to write a test than to quickly check it yourself.

Our current Test Suite in the Visual Studio Test Runner
Our current Test Suite in the Visual Studio Test Runner

In the image, you can see that we’re currently running +230 tests across our codebase. We’re using the great XUnit Framework for this. This week we removed most of our old tests and completely rewritten them. Some of them had questionable usefulness and broke easily due to internal code changes. The new tests are working very well and cover more cases. We will still add a few more tests in the next weeks for the systems not covered yet.

Stabilizing Double

As mentioned in this post, we have implemented a custom solution to keep floating point values accurate and synchronized across different devices. This week we finally removed the old implementation and are now using the new one in the Core. This meant reimplementing the vector classes and changing all referenced to the correct type.

Additionally, we are now using a special struct called Position. As we’re using a hexagonal grid, we have two different spaces to work in. Hexagonal Space, which works directly with the grid where every voxel is on an integer position, and World Space, which is the grid converted into x and y scene positions, which are decimal values due to how hexagons work. (If you want to read more about that topic, you can check out this excellent blog post by Red Blob Games, which helped us immensely)

Position can work with both. It dynamically converts between them when needed and caches the results.

Next Steps

Next week we’re going to take a look at Pathfinding and we’ll start the work on rendering our new 3D world.

Be sure to follow us on Twitter and subscribe to our newsletter.
Until next week!