HFFWS Generation System Overview Update

December 5, 2019

HFFWS Generation System

Overview Update

General System Overview

I have updated my thoughts on setting up the overall system to fit the demands for my thesis as well as to keep everything more organized and readable. I am sure as I go through building this I will find ways to cut out levels of inheritance or add scripts for readability, but this is the most recent view on everything. I want the highest level to be very general (DemoManager), the middle level should be where the majority of parameter ranges and interactive placement between objects should be (ScenarioManager’s), and the lowest level will be in charge of putting together the needed objects within the bounds dictated by the higher levels (Create classes).

This image just shows the general idea of the overall hierarchy (the actual number of ScenarioManagers and Create classes is not accurate). The DemoManager holds references to all of the ScenarioManagers, but only chooses one ScenarioManager at a time to develop its scenario. Each ScenarioManager is connected to specific Create classes within a large pool of Create classes, which will be the objects that specific scenario will actually possibly need to create. The Create classes referenced to can overlap as some objects will be used in multiple scenarios.

DemoManager (change to GenerationManager)

The name of GenerationManager was changed to DemoManager to fit its purpose better. Since the system will be mainly used for demonstration purposes, it will focus its functionality on generating any varied number of scenarios and allowing for real time resetting.

Goal:

Passes down highest level information to ScenarioManager level. This will include puzzle type, variation types within that puzzle type, and any other high level information such as overall positioning or how many scenarios in total to generate.

Needs:

• Number of scenarios to generate
• List to hold information on all scenario options
  • Customizable in editor to pin point certain scenarios if wanted
  • ScenarioManager level objects should be same type of object to help with this listing
• Scenario spacing
• Input to reset generation in real time
• Seed information (may be better in scenario manager level)

Notes:

Will have some bool list of scenario types to include in its random generation

For testing, have “GenerateSpecific” bool to allow for creating a single specific scenario

ScenarioManager

I think it makes sense to commit to setting up an internal hierarchy setup within the ScenarioManager level at this point. This allows the DemoManager to just deal with ScenarioManager type objects, but I can break each scenario type down into its own class to help keep the scripts manageable and more organized.

Goal:

Will take DemoManager information and use it to determine which “Create” type classes will need to be used (or have the option of being used), how many times to use each, and what other information needs to be passed on to them (the “Create” type classes) to properly build out the desired scenario.

Needs:

• Hold Parameter Ranges
  • will need to be moved over from current Create classes
• References to Create type classes

Example for Possible Inheritance Pattern

• ScenarioManager
  • PulleyScenarioManager
    • HeaveyDoorPulley
    • PlatformPulley
    • HookPulley
• Information for all general scenarios
  • Information for a general type of scenario
    • Specific information for a specific type of puzzle in a specific type of scenario

This shows the inheritance setup within the ScenarioManager level from the overall system setup.

Create Classes

I have not worked with these enough yet to fully update them, but I am looking at creating a base Create class that holds general data that any of those classes will need. Then each type of object will have its own Create type class that derives from this class detailing all of the specifics for altering the parameters of that overall object.