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.