During the creation of the previous post, I have started creating the Wave Function Collapse project. For this post I'll be going over the basis of the code and the implementation of the algorithm I have chosen to pursue.
The foundation starts with the structure of the code. I have used POCO (Which I consider as Plain Old C# Objects ) or the Humble Object Pattern for multiple classes including the cells and the overall grid. These allow me to Unit Test in the future without too much trouble, unlike using Monobehaviours since they need an instance on a GameObject which is hard to do in unit testing. An example of POCOs were seen previously in the random number generation blog pos. The cells contain information like their X and Y positions, possible tiles and the current tile selected. Tiles themselves are Scriptable Objects. Which include a prefab for the tile itself, the adjacency rules and the frequency of the tile from the Input Model.
The Monobehaviour which runs the algorithm itself is called "WaveFunction". In it, I'm using nested Coroutines to step through the algorithm, due to the capability to run over time instead of instantly. Using nested coroutines will allow me to test that each step of the algorithm separately whilst also being able to return true or false. This helps create an incremental visualisation of the algorithm whilst it's running. Each cell prefab will have a cell visualizer Monobehaviour on it, which will get updated when functions that change the cells are ran. This will also aid visualisation and help me debug as I make the code.
The overall structure has 3 connections to the Unity Editor:
The algorithm running script
The cells' visualisers
The input model editor
This means that I can section off what public to the classes, and reduce the amount of objects to view when changing the composition of the project. This is especially helpful due to the amount of objects which may be created by making the tilesets. Due to the object orientated nature of the class structure, there's no monolithic architecture to contend with. I believe this is the correct direction to head with the codebase, the lack of abstraction may mean that the algorithm will be only used for this project and will be less robust. Currently that is a disadvantage that I'm willing to accept to be able to spend more time on other aspects of the project.
Hopefully that makes the idea behind the projects' code more clear and in the future when I discuss the individual aspects of the code it can be more concise. I plan to talk about the input model more specifically in a different post, since that's a main part of setting up the algorithm to work. Also since it's a part that in the future, there's a potential plan for users to be able to edit the input model as part of the user experience. There will also be a post about Shannon's entropy which is how the propagation chooses which cell to choose the tile of next.
Comments