September 19, 2019
Building Prototype
Level Generator
Prototype Frame
The idea of this prototype design is simply to show the general concept of the final hoped for result of my thesis project. It will cover the core concepts of: creating the proper objects for a puzzle type, varying parameters of those objects, communication between objects.
This prototype will be a very simple puzzle. It will simply be an elevated ledge that the player must be able to climb up onto by using a block in the environment. This will demonstrated the concept of tying specific object types to a puzzle type (connected the instantiated block to an elevated ledge puzzle). It will have varied parameters by varying the position of the ledge (most notably the height) and the size of the block. Finally, the system demonstrates communication between objects by using information on the ledge’s position to control the range of the block size.
PROTOTYPE CLASSES
Class: Generator System
This class was created with the purpose of receiving data from all the individual creation classes which would be important for communicating with other creation classes. Information that a class needs to receive from another to inform how it should generate or instantiate objects should all be compiled here for other classes to pull from.
Class: Create Ledge
This is a small example of a creation type class which simply instantiates a ledge. The ledge is just a long box object. A range for its position, most notably its height, can be input by the designer. This class then instantiates the ledge somewhere within this range, and then passes the height information to the GeneratorSystem class.
Class: Create Box
This is another small creation type class, but this one exemplifies receing information from the GeneratorSystem as opposed to passing information to it. Its main function is just instantiating a box object. This class has ranges of inputs for the position of the box in 3D space as well. It also has a range determining what scale the box object should be instantiated at. This scale range however, uses information from the GeneratorSystem to see if it needs adjusted, and adjusts accordingly.
Just to show the general concept, the minimum scale that is given to this class will adjust based on how high the platform is instantiated. This is to ensure that the box is at least big enough to allow the player to reach the ledge, regardless of height (theoretically). There is also a max scale limitation which is just a fixed value to be put into the GeneratorSystem, which is there to make sure the box isn’t so big that the player cannot climb onto it in the first place.
Concept for General Flow
There needs to be a flow where all values that can be determined before instantiation are found and passed into the GeneratorSystem. This then needs to be followed by classes accessing this information (if they need other class information before determining some of their own values). Finally, the creation classes should all have the information they need to proceed and generate the puzzle scenario.
Testing Flow
I initially tried having each of these classes set static references of themselves in Awake in Unity, then pass information to GeneratorSystem in Awake, and finally grab values from GeneratorSystem in Start before instantiating at the end of Start. This however had an issue where the instances weren’t all being set in Awake in time to also pass values within it (between several classes). Basically, the small public GetInstance methods were being called before the instance in GeneratorSystem was actually set.
As a temporary fix, I simply changed the GeneratorSystem references within each seperate class into a public variable so I could just set them in the Unity inspector. This ensures that they are taken care of before anything else. This solved that problem, and could actually be a fine solution avenue as long as separate scenes are not needed.
GENERAL NOTES
This practice was helpful for visualzing the process I want to achieve, as well as getting started on figuring out the basics of how the individual classes should be setup to build this process. I am already starting to see repeated patterns that may be better suited with parent abstract classes or interfaces if I continue this route of just having many creation classes and one general GeneratorSystem class. That may also be helpful in the future for having GeneratorSystem find/store/etc. all these different classes.
This exercise has also helped me start to identify what values and variables may make sense to have the final product system determine on its own. For example, maybe the system could figure out on its own how much shorter the box can be than the ledge while still allowing the player to complete the level. Similarly, maybe it could determine the maximum size the box can be to allow the player to still climb onto it.
With this very quick and simple test, the objects did spawn inside of each other sometimes. This was noted as something I would have to look into at some point previously, so I am just reiterating.
NEXT STEP
Test this prototype out some more to get a feel for how this system works, and what fine tuning I can do to make it work a bit better. This will also help me get a better idea for the general framework of some of the classes I may need to make, and what higher level parent classes or interfaces I can make that can serve as the foundation for some of these creation classes.
This can also help me get a better understanding of how the data flow should work, and whether that should be switched around to any degree. This general framework was made with the intention that individual creation classes would contain the individual methods needed to adjust their personal ranges and needs, but maybe it could make more sense to do more work with the overarching GeneratorSystem class.