HFFWS Thesis Project – Theory for General Generation System Architecture

November 6, 2019

HFFWS Puzzle Generation System

General System Architecture

General Notes

Pulley Varieties

I wanted to start with sketching out the general structure of a single puzzle type to help me get a better idea of what a useful general structure might look like for the overall puzzle generating system I want to make.

  • Hook on an end to latch onto other objects
  • Object to move can be used as a platform
  • Open heavy door
  • Focus on rotation of wheel
  • Build a pulley
  • (Rope puzzle) Move two rope conjoined objects somewhere to accomplish a goal

Breakdown of what I can currently alter/generate in rope/pulley tool

  • Objects (at ends of rope)
  • Objects (for wheels)
  • Length (of rope)
  • Position (of rope)
  • Position(s) (of wheel(s))

I then quickly sketched out what I could change with the current controllable parameters to match the various puzzle variations (I only did the first three for now just to work it into testing quicker).

Hook on end

  • Objects at ends
    • Hook
    • Grabbing Mass (i.e. small sphere)
  • Outside objects
    • Objects that need pulled by hook

Objects attached can be used as platforms

  • Objects at ends
    • Platform type objects
  • Outside objects
    • Mass objects to influence pulley movement

Open heavy door

  • Objects at ends
    • Heavy Door
  • Outside objects
    • Mass objects to influence pulley movement

Architecture Design (1st Pass)

The overall flow of information is:
GenerationManager -> ScenarioManager -> “Create” type classes

GenerationManager

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

ScenarioManager

Will take that 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.

“Create” type Class

Use the information passed down to them from the ScenarioManager to create objects that satisfy the needs of the desired scenario. Within these bounds, in then adds variation to what it creates to vary its creations while still meeting the requirements given by the ScenarioManager

All the “Create” type classes will need an interface or inheritance of some kind to make them all similar types of objects to make grouping them and using them a bit easier.