First of all, I will like to thank the players of the community for supporting Stone Shire. This game came out May 21st of last year, and was the first of its kind on this console. It was meant to bring a block-building experience similar to Minecraft to the Wii U. It was also meant to be transformed into something more like Elder Scrolls. Unfortunately, a lot of these features I was unable to include in the game, both due to the limitations of the system (and the Unity engine) and me simply being a one man team, which led to a slow development time. I apologize that I was not able to give you the full experience that you expected. The lag of the game is something I did not want to occur, and it seems introducing the lighting and water mechanics unfortunately brought a lot of bad performance.
Unity is a great engine to work in, but it’s also not optimized for procedural generation. Because the Unity APi is not allowed to be touched both in code and by multithreading, a lot of the optimization I did was mostly C# related, aka based on all the operations I did outside Unity. The way Unity works is that it has a main thread that it processes all its processes through. While beneath the hood it is multithreaded, unfortunately, I as a programmer cannot touch anything there. For instance, in Stone Shire, if I could make mesh construction, the rendering step done by the CPU, be broken up into smaller steps, I could have made the game a whole lot less laggy. It’s not a problem when it’s just one or three chunks of meshes being built up, but when there’s multiple ones constantly being updated due to light and water, unfortunately, there’s a freeze I cannot get pass due to the mesh construction process sharing the same thread as everything else. This had led me to unfortunately passing a lot of inputs into fixed update, which is not a good thing in practice but was necessary to have the game run smoother on the Wii U. Of course, I had the algorithms for light calculations and mesh vertices building done in a different thread, since it was all c# related, so the pre processing step was actually pretty fast. However, to build the mesh, you have to pass the data to the main thread to have the mesh actually applied, and that led to the slowdowns that the game constantly experienced.
In addition, I used the Greedy Meshing technique to reduce the amount of faces on the collision mesh of the chunks, as this was taking a good portion of the mesh building time when the mesh was applied. With this made, the mesh building time became a whole lot faster than it was during alpha builds on the Wii U. Unfortunately, if I did this with the rendering part (the mesh you actually can see that has textures), this would make me have to create a texture material for each type of block in the game, and that would have led to some devious overlord of the game. Therefore, in the worse case scenario where each block is a different object compared to its adjacent neighbor, this would actually be a worse scenario technical wise since now you have to deal with both maximum face count and an abundance of sub materials.
I will strive in the future to bring a better experience to this genre, hopefully on Nintendo’s next console. However, I am bringing a pause to the post development of Stone Shire for the moment as I work on a new smaller project, which I will give details to in the next coming weeks. I enjoy working on Stone Shire, but I must also continue to create more games to put out on the Wii U. I will work on smaller patches to bring the game to a more stable quality, but a lot of features like monsters, animals, and the weather system I wanted to implement would have to wait until a future iteration of the game.
Thank you for following along on my adventure and I hope you stay for the next chapter in Finger Gun Games life.
From,
Cordero