As usual, my code was getting a bit messy and a bit long. So I ended up spending 2-3 days refactoring the code and splitting it up into more classes. As a general rule, classes and methods should contain as few lines as possible. I'm more of a brute force coder but I'm trying to change the habit of 20+ years' with this project ... hell, I've even added documentation to my code!


Another quirk I discovered in Unity was the way that Textures are instanced and referenced. A cool feature of Unity is that you can declare an object as public and then in the editor's inspector, drag and drop that object from your assets directly into the class. It's brilliant but it can lead to lazy coding. I've certainly been guilty of that. Can't be bothered writing a piece of code to load an asset at runtime? Hell, just create an array of objects and drag'n'drop every asset into the array. It also leads to over-reliance on this lazy method without actually thinking about what goes on under the hood.

A case in point was the way that Unity handles textures. The game relies heavily on pseudo-random numbers to generate and place objects on each level. What should happen is that because a pseudo-random number generator generates the same set of numbers it places the objects in exactly the same place each time the level is loaded. However, what I hadn't realised was that whenever an infected square was added to the texture in-game, it was actually being saved onto the original texture file. What this meant was that each time the texture was loaded, it already contained 'infected' pixels. The pseudo-random generator looks for green tiles to 'infect' at the start of each level. So it couldn't choose these already 'infected' pixels again and therefore chose different pixels, which were then also added to the texture file.

The solution was to create a copy of the texture map. To ensure that it wasn't just creating a reference to the original texture map, I had it create the new working texture map and then copy the original map pixel by pixel. It doesn't create any noticeable slowdown during startup. So now, whenever changes are made to the map during gameplay, it's made to the working map rather than the original that's loaded into the game.


Further progress has also been made to the placing of new land. That's now working 100%. If a player right clicks on sand, it creates grass. If a player clicks on water or an infection, it creates sand. So the basic game control mechanics are now all working on desktop. Now it's time to move onto the energy and timer bars.