Category: Thesis

October 6, 2019

Pulley Wheel Positioning System

Video Demo of Wheel Positioning System

Demo – Link

By: me

General System Needs

My pulley system needed to create a rope with objects attached to it, as well as objects which act as the pulley wheels which will support the rope. The positioning of these wheel objects must be in line with the rope, but below it. Using the HFF system, the rope gets generated and then falls, draping itself over any objects below it.

Keeping those requirements in mind, I also wanted the system to be able to generate a varied amount of these pulley wheels and place them in varied positions below the generated rope. Having the option for multiple wheels became more important when I noticed that sometimes ropes with heavy objects attached can break through rigid body wheel support objects, but having more (therefore more support) can sometimes alleviate this issue.

So to summarize, I wanted a system that could choose a varied amount of positions along a randomly determined line, with extra rules dictating how far these positions should be from the ends of that line, and how much of a space buffer should be given to each position (so when an object is instantiated at one of these positions, it does not collide with another instantiated object).

Starting Off

To keep the system simpler for now, since the system needs to fall into place anyway, I was specifically randomly generating the rope on the xz plane at some height y. The wheel positions are then generated on basically the same line, but some distance below that line (to ensure the wheels are within the rope line, but below for the rope to fall on them).

Adaptive Range System

The difficult thing with this position range system is that choosing a position for an object removes a specific range around that position to account for the space needed to instantiate an object at that position. Because of this, I needed a system that could update the range options everytime a position was chosen. I came up with a system that could determine how to update the ranges everytime a position was chosen, and could also determine if a range needed split into multiple.

The first range is the easiest to determine. It is just the full range of values between the beginning and the start of the wheel positions, with a buffer at each end factoring in the value for distanceFromEnds that we want to give to keep objects from instantiating too close to the ends.

With this first range created, we choose a random position within this single range. After that is when the adaptive range system comes in. Depending on the position selected, there are several possible options to account for the options that have been removed from the range:

• If the position is sufficiently far away from any other range bounds, a range is effectively split in two.
• If the position is very close to both the min and max bounds of the range, that range is fully removed.
• If the position is very close to either the min or the max bound of the range, that range can just be modified.

Weighting the Ranges

One issue with a system that creates multiple ranges is that these ranges can be different sizes. So if at some point in the process I am randomly selected a range first, to then select values from, each range will inherently have the same chance of being selected, regardless of its size. To remedy this, I used a weighting system.

Each range has a weight in the range (0, 1] (The minimum bound is exclusive, as nothing should ever have a weight of 0, but the maximum bound is inclusive since if there is only 1 range it is the only option) representing how much its individual range covers amongst the total coverage of all the ranges within a list of ranges. This is easiest to explain with an example:
We have 3 ranges: (0, 2] (2, 5] (5, 10]
The total range coverage is: (2 – 0) + (5 – 2) + (10 – 5) = 10
The individual weights for these ranges are then:
Range 1 (0, 2]: Weight = (2 – 0) / 10 = 0.2
Range 2 (2, 5]: Weight = (5 – 2) / 10 = 0.3
Range 3 (5, 10]: Weight = (10 – 5) / 10 = 0.5

So when we go to select a range, we randomly roll a number in the range of (0, 1] and use this to determine which range to pull a value from. This works by checking if the rolled value is less than or equal to the first range’s weight. If this is satisfied, that is the range to choose from. If not, it moves to check the next range’s weight. To fit this within this (0, 1] range, each time a range is not used, its weight is added to a pool to add to the next range’s weight. This helps move the weight check along the range of (0, 1] with many values significantly below 1.

To follow the previous example to show this in action:
Our randomly rolled value to select a range is: 0.75
General Formula:
Check range n: Is rolledValue <= (rangenWeight + weightCheckPool)? No, add rangenWeight to weightCheckPool
Check range 1: Is 0.75 <= (0.2 + 0)? No, add 0.2 to weight check pool and move to next range
Check range 2: Is 0.75 <= (0.3 + 0.2)? No, add 0.3 to weight check pool and move to next range
Check range 3: Is 0.75 <= (0.5 + 0.5)? Yes, use this range to select a value from

September 20, 2019

Furthering Prototype

Level Generator

Prototype Enhancement

Allowing for Multiple Scenarios to Be Created at Once

This started as a thought for just generally helping with testing the classes to see if they were working properly, but then it seemed like it could just be a powerful addition to the system in general so I decided to implement it more properly into the system. The basic idea was simply adding a “Test Counter” which I could adjust to create a number of instances of the generic scenario I was generating.

The idea was that this would let me see more instances of the variance the system has at once, so I could more quickly test if it seemed like the system was working or not. This also helps give me a better picture of the overall variance the system has as well, so it was actually more helpful than I first realized.

I have also dabbled in machine learning (ML) and a key portion of using that is creating several test environments to more quickly train your system or agents. This gave me more motivation to look into changing my variables into array sets to deal with the idea of multiple puzzle scenarios (which could potentially later feed into how to get this setup for multiple testing environments for ML).

At the root of everything, the system is doing very similar work to what it was doing previously. I have just added several for loops and changed some variables instances into arrays to allow the overall system to deal with several puzzle instances at once. Holding all of this information in arrays could also be beneficial for printing out the data somewhere to keep better track of what works and doesn’t work with the system at any given time.

Example Image and Video

Example View of 5 Generated Puzzle Scenarios – By: me

Vimeo – Example Iterations of Scenario with a Test Run with a Character

Link – Test Example with Gameplay

GENERAL NOTES

I just wanted to make sure to note some other factors I ran into with some more testing. The mass of the TestCubes that needed carried around to reach the ledges ended up settling on 120. That was a value I found to be fairly easy to move around, but not so light that the cubes would topple over often (especially the smaller ones).

Currently the GenerationSystem has an array that holds all of the ledge height values passed in from every generation of a ledge, so that can be fed to each properly indexed cube for scaling purposes. However, because I am passing that information on Awake, I was unable to set the size of that array equal to the number of tests (as it should be), because even doing so in Awake was not being done in time. I tried setting the size of the array directly on variable declaration, but I want to be able to control the number of tests to create from the inspector so the array size comes from a serializeable field in Unity. I could not use this to declare my array size in the class’s general declared variables. So for now, it is just hard coded at some decently large array size (like 10) until I find a better solution.

NEXT STEP

I would still like to test this setup with a more complicated puzzle scenario, as this simple one is already helping me see a lot of possibilities and flaws that will need adjusted.

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.

September 12, 2019

HFFWS Prefab Editing and Instantiation

Testing

TESTING

• How does altering prefab directly affect process of creating multiple instances?
• Can altering prefab help set the axis of moving platform?

Can altering prefab help set the axis of moving platform?

Yes, this approach worked. Setting the axis rotation on the prefab directly, THEN instantiating instances of the prefab had the platforms move in the newly set direction.

How does altering prefab directly affect process of creating multiple instances?

This does not appear to have any effect on previously instantiated instances of the prefab. Once an instance is created, changing the parameters of the prefab was NOT changing those parameters for the already instantiated. This gives more support to using this approach

FINAL NOTES

These tests do give this approach more support in being the one to use for now, since it does seem to accomplish all of the goals necessary at this time. It still makes me nervous that the prefab itself gets changed in the editor everytime play is run, and it can impact editor-set prefab instances, so I will continue to check in on different methods for instantiating objects as I move forward.

September 10, 2019

Human Fall Flat Workshop

Conveyor Instantiation

Today we are finally going to try setting the parameters of a conveyor object on instantiation and seeing which we can and cannot, and trying to fix as many that we cannot as possible. We will also use this as a comparison point for the vertical moving platform generator to start designing the foundation of a tool that can instantiate many different types of objects. At the very least, it could potentially lead to the start of an interface or an abstract class that can be used as the base for classes that instantiate objects.

Parameters to Set on Instantiation

• Item Prefab
• Segment Count
• Length
• Radius
• Speed

TESTING

Test #1:

ISSUE: Want to properly set some conveyor prefab parameters on instantiation.

Using a similar start to creating the platform prefabs, my first attempt to instantiate these conveyors began with instantiating the conveyor prefab and casting that as a gameObject. As most of the parameters are found in the Conveyor script in one of the children objects of this prefab, I simply created a Conveyor variable reference that used a GetComponent. I then set all the parameters of this conveyor reference with public variables available in the inspector: segmentCount, lenght, radius, speed.

FAILED: The script was returning an error as soon as it tried to set the first parameter (segment count). This made me think that maybe just using GetComponent to get the Conveyor reference was not working. I thought GetComponent looked through children objects if it didn’t find anything in the initial object, but that may not be the case.

Test #2:

ISSUE: Get prefab reference to actually set conveyor parameters on instantion.

I am changing the GetComponent to GetComponentInChildren to see if specifying that initially helps properly grab the Conveyor reference I need. I am also adding a debug.log to check the name of the reference I am getting in hopes that this will help me check what it is getting (if anything).

SOLUTION: This did fix the problem of getting the reference and actually setting the values, however, this was not creating a conveyor with the proper initialized conditions. The values were being set, but the parameters that need to be set at instantiation to work (like Lenght and Segment Count) were not being received in time.

Test #3:

ISSUE: Parameters being set, but instantiated prefab is not using those set parameters. It is using the default prefab values.

With some very quick checking, I decided to look into issues with changing prefabs and instantiating them and it very simply led me to find that I can just change the prefab parameters itself before instantiating an object. This seemed like a very obvious solution that I hadn’t tried yet apparently, so I simply did just that: I simply had my Conveyor reference variable grab that of the input prefab itself, set all the parameters, and then just instantiate that prefab (without the casting to gameObject addition).

SOLUTION: This immediately worked. The length, radius, and segment count were all set to the inspector values and actually reflected in the instantiated conveyor. It should be noted however that this effect of altering the prefab carries over into the editor AFTER EXITING PLAY MODE.

Images of Prefab Default versus Parameter Altered Instantiation (Conveyor)

Conveyor – Default Prefab

Conveyor – Parameter Set Instantiation

NOTES:

It is very important to note the final effect of editing and instantiating prefabs this way. You are directly modifying the prefab itself, which can have some undesirable effects. At one point, I had an example conveyor in the scene to compare with, and it took on the same parameters of my conveyor spawner after running, ending, and running again, since it must have been using a default prefab reference of some kind. That prefab itself had its values changed (which again, carries over into the editor even when LEAVING PLAY MODE), and my other scene reference to that prefab just took them on as normal prefab changes.

To further test this, I edited the values in the existing prefab instance in the scene slightly, and further play tests did NOT reset this existing prefab reference. I played, closed, played again, and it stayed with the same set values. So it appears any alterations are making it into its own object, where as if you simply drag/drop in a prefab, altering the prefab this way can change how those objects will start up in the future.

Further testing showed that any values directly set to the existing prefab reference in the scene will always stay that set value, but running the game will still cause other parameters that haven’t been altered to change to those dictated by the script. This impact can “lag a play behind” as well. For example, I set the segment count in the existing prefab object to a different value, so playing kept all the parameters the same (even those I had not altered), however, upon playing a second time, those other parameters WERE altered to the values dictated by the script (where the editor set parameter still remained as it was set).

Video of Issue

Vimeo – Video Link

By: Me

The two main ways around using the system this way that I can see are:

• 1: Always setting the parameters of existing prefabs in the editor that will be affected by scripts
• 2: Create two seperate prefabs: One for using pre-made instances in the editor and one that can be taken by a random spawner and altered

All of this shows that editing the prefab before instantiation may not be the best solution, and it may be worth looking into other techniques if available.

NEXT STEP

I want to randomly instantiate a few conveyors to make sure the system of setting up random ranges for values works just as well with this as it did for the moving platforms. I would also like to experiment with replacing the meshes with various other mesh objects (for example, instantiating the conveyor segments randomly from a predetermined list of mesh options).

August 27, 2019

Human Fall Flat Workshop

Instantiating More HFFWS Prefabs

I ended up running into an issue testing the HFFWS. When in Play mode in the Unity editor, my player model was missing.

PROBLEM: Missing Player Model in HFFWS Unity Editor

SOLUTION: I decided to open HFF to see if there was a direct access to the workshop levels from the main menu, and found out there was not. While I was in the main menu, I decided to have some fun and customize my player model. After doing so, I found out that my player model in the HFFWS editor was missing. It turns out that the editor tries to use your in game model, and if you are not using the “Default” as the option for your character’s model, nothing will show up. model

The Prefab scenes seem to work pretty well from interacting with them for a bit. I will look to go through these and grab some interesting objects to run some spawning tests on to make sure I find a nice way to approach this. Setting the parameters for node and non-node objects will be crucial for setting up levels.

NEXT STEP:

A decent looking prefab I will look to work on next time was the GraphHolderConveyorBelt from the PowerPlant prefab scene. It has a good bit of factors for running a large conveyor belt, which could also just be a useful tool for me to work with in the future.