PuzzleScript+MIS: A tool for co-creating puzzle games!
This is a mixed initiative tool for interactively co-creating puzzle games together with your computer based on Stephen's PuzzleScript.
Download PuzzleScriptMIS (1.5):
PSMIS on Steam
PSMIS on the mac app store
Windows binary (v1.5)
MacOS binary (v1.5)
Check out the collection of puzzle games which used PuzzleScript+MIS in their development process here.
Changelog v1.5 (01.6.2024)
-Added better IDE scrolling when using keyboard to move around.
-Fix: Ctrl+A on Windows in the IDE was fixed.
-Fix: Removed a potential infinite loop leading to rapid memory increase of the app.
Report issues on the github page.
-Added startloop/endloop
-Added IDE keys: Home/PgDown/PgUp/Cmd+Right/Cmd+Left/Alt+Left/Alt+Right
-Added IDE key shift for selecting text properly
-Fix: Ellipsis off-by-one bug:
-Fix: Again command looping infinitely leading to a crash. Now stopping early.
PuzzleScript+MIS contains a level editor, a test mode, a solver and uniquely a transformer for PuzzleScript. The transformer functions as a new way for puzzle designers to find or refine levels for puzzle games. If you prefer video tutorials, watch the video tutorial.
How the transformer works:
Designers can specify transformation rules according to which a current level design is transformed. The transformation rules follow a similar syntax to PuzzleScript and should be very easy to pick up for anyone familiar with PuzzleScript. It extends the language by introducing the keyword choose.
choose 1 [Player | No Obstacle] -> [|Player]
This chooses, with equal probability, any match of [Player | No Obstacle] (provided there is one) and replaces it with [ | Player] according to the normal rules of PuzzleScript.
Notice that this can lead to multiple possible outcoming transformations. For example the following level could be transformed into two different choices:
The final outcomes are then ranked according to their difficulty and presented to the designer. In this very simple example the level where the player is moved to the right is considered slightly more difficult than the level where the player is moved to the right. The difficulty metric is based on the number of states the fastest solver requires in order to find the solution and does not almost match human judgement. The transformer works best if the ratio of interesting levels is high in the search space and the levels need a moderately low number of steps to be solved. For more details on how the transformer works to get the most out of it read the paper. The following are example use cases of using a transformer for designing Sokoban puzzle games but the techniques apply to other puzzle games.
Use case: Inspiration
In the following example the designer restricts the transformer to only create 4x4 Sokoban levels with 4 crates and targets and no walls. The transformer takes as an input an initially empty 4x4 level and transforms it according to the following rule.
choose 1 [] -> [Player]
choose 4 [No Crate][No Target] -> [Crate][Target]
Use case: Make it solvable when stuck
In the user study most designers got stuck at some point when designing a level by introducing or removing an object which made the level unsolvable.
Surprisingly, instead of figuring out a way to make the design solvable again, they posed this as a problem to the transformer.
The transformer did generic operations on the level as follows:
( move players and crates around )
choose 20 [Player | No Obstacle] -> [ | Player]
or [Crate | No Obstacle] -> [ | Crate]
( randomly remove or add 10 walls with prob. 0.4 )
choose 5 option 0.5 [Wall] -> []
choose 5 option 0.5 [No Obstacle] -> [Wall]
( remove one crate/target pair if it exists and add one )
choose 1 [Crate][Target] -> [][]
choose 1 [No Wall No Player No Crate][No Wall No Player No Target] -> [Crate][Target]
Use case: Polish
The transformer can be used to polish certain things at the end, like finding the most difficult starting position of the player in a Sokoban level. Also an often reoccurring problem is to know when to stop designing a level. The transformer can give you a level of confidence if it cannot find any simple transformations that would make the level significantly more interesting.
choose 1 [Player][No Wall No Crate] -> [][Player]
Use case: Backward design
Minotalen first introduced this method to me when they were designing their game Tell me about eights.
Their game had a lot of configurations that were unsolvable so they set up the transformer in a way to only create solvable levels. The idea is to start with a solved level and transform the level using only valid moves (in reverse). For Sokoban you would write transform rules that pulls the boxes instead of pushing them.
[Taylor and Parberry 2011: This assumes that the target positions are fixed and no crates
are in the initial design. The player then pulls the crates away from the goal.
(place crates on all targets)
[Target No Crate] -> [Target Crate]
(move the player around and let him pull crates)
choose 50 [Player | No Obstacle] -> [| Player]
or [No Obstacle | Player | Crate] -> [Player | Crate | ]
Idea based on Kartel et al. 2016: This assumes that the crate positions are fixed and no targets are in the initial design. The player then pushes the crates around and at the end turns them into targets.
(add a placeholder to all crates)
[Crate] -> [Crate Placeholder]
(move the player around and let him push crates)
choose 50 [Player | No Obstacle] -> [ | Player]
or [Player | Crate | No Obstacle] -> [ | Player | Crate]
(replace crates with targets and placeholders with crates)
[Crate] -> [Target]
[Placeholder] -> [Crate]
For more details on the solver and more use cases check out the thesis.
