Maps and Test-Driven Development

Below you can see a video with a series of maps being generated in real-time. The larger maps take longer to render, and you can see that the plants get rendered before the land squares are moved into place.

This feature gives the game a lot of flexibility in generating maps that are non-repetitive and makes the game more re-playable.

The point of this post is actually less about these cool maps and more about how I managed to make this demonstration work. I had tried to set-up this demonstration a while ago but I ran into an error. This error was preventing plants from spawning correctly when the game deleted a map and created a new one. I was unable to resolve the error.

My breakthrough came weeks later on a particularly productive Sunday when I created a series of unit tests for a new feature. These tests happened to isolate the map generation error in a way where I could fix it. The issue was that my lands didn’t have rigid bodies – these are attributes that allow Unity to place an object in a physical simulation. Without the rigid bodies, collision detectors (known as colliders) that were supposed to move with the land squares were being left in strange locations. This prevented the code from being able to place plants correctly.

The “rotational placement” method you see below relies on colliders attached to the land to detect if a tree is in its placement area. Without a rigid body, the colliders were not moving with the land, and the plants were being “misplaced” in weird locations 😋.

Arborlands’ “rotational placement” method relies on colliders to place plants correctly.

This was a great lesson for me. I have shifted much more towards test-driven development, where I write tests for new behaviors, then plug them into the exiting code.

Before, I was breaking my existing code with new functionality, then fixing the issues. This break-to-improve is a very stressful way of development because it makes me feel like I am out on a limb; any interruptions in this state would leave the code broken.

I’m much happier with the way I code now, it is easier to stop, and the increments of progress are small but noticeable. Test-Driven Development requires patience and some foresight, and doesn’t come naturally to me. But I now know the price of doing things the wrong way! 😅

Thanks for reading the blog! To stay tuned with the latest mini-updates, check out @arborlands on Twitter.

Leave a Comment