1st December 2012
Turing Turns, handcrafted design and combinatorial limits
I was very pleased to get sponsorship for this game, as this means I can finally show it off.
A quick list of features :
- 40 hand-designed levels
- varied and hopefully interesting designs
- progressive difficulty
- programmatically generated 'random' levels
- created at varying map sizes and difficulties
- guaranteed solvable
- give-up & show a solution option
- no trivial single-turn solutions
- colourblind mode
- level complete 'energy bulge' effect
- plasma background
- colour desaturation menu transition
- casual style of play
- No time pressure
- No punishment for missing target
I put a lot of work into this; while I did include a few interesting graphical effects I think most
of the effort actually went into designing the levels.
Now, you may already know that I'm interested in procedural content, and indeed I also included a random level generator. So why spend the time to manually create anything beyond tutorial levels? (Obligatory link)
Well, the answer is clear if you play a few levels in both of these modes: Hand crafted content is for this purpose massively better.
In this level-set I have designed levels with several different high-level approaches. These can't easily be replicated in a procedural manner - the best one could do would be to write something which approximated each method in turn. This would take enormously longer than manually creating as much content in the style as to saturate most player's interest, and probably wouldn't be as good.
In the case of puzzle games, hand-crafting lets you add enormously more variety to a level-set than is feasible with generated content. Puzzle games can have the advantage that their data is quite far along the value scale - the time required to create content (and hence cost) is a relatively low multiple of the time a player will spend on it.
Each of the designed levels has only one route to the finish block. I guarantee that, because one function of the level editor was to test it. As it was for internal use I didn't heavily optimise the code; nevertheless it didn't take very long to run.
While I was designing levels, after the game engine was essentially complete,
I started to worry about this lack of combinatorial depth. At most there are seven colours of
block, each with three options, and there are four potential directions in which to initially
send the ray. Therefore there are 37*4=8748 possible settings.
That's a maximum - many levels have fewer colours, and/or have the starting block
in an obstructed position.
My concern was that this would make it too easy, although since release feedback has been that the game is very tricky. Nevertheless it is clearly close to the lower boundary of combinations needed to prevent trivial enumeration.
Enough time has passed that I've forgotten most of the solutions, and have been playing the game myself. I've been pleasantly surprised by how they hold up as logical puzzles which can be interesting even when it is in theory straightforward to enumerate every possibility. But then, maybe it's not so surprising. People still play Sudoku, even though there are computer programs which will solve them in less than a second.