Why Construct2?
At this point we were still working on The Far North, but thankfully the requirements for that level editor turned out to be very similar to what we would need for AMPS, namely:
- Simple drag-and-drop placement of 2D assets (position, scale, rotation)
- Layers
- Ability to add custom data to instances
- Not grid-based
- Export in XML format to be parsed and recreated in-game
- Free
XML parsing using TinyXML2
Although TinyXML2 handled the process of parsing the XML file and creating a hierarchical structure to represent it, that structure still had to be traversed and interpreted to actually create a level in-engine. A considerable amount of my time working on AMPS was spent working out how best to represent various behaviours as data such that it was easily understood and editable by designers trying to time the behaviours to music, as well as the parsing and interpretation of that data to actually initialize a level.
Data design
- Checkpoints: act as respawn positions
- Collectables: introduce new musical layers, completionism
- Death zones: contact causes death
- Fast forward zones: aren't used in any of the final levels and consequently don't have nice visuals, but are fully functional; hold down the fast-forward button to lock your position and make the level and song play at double speed
- Fixed platforms: standard building blocks (walls, floors, ceilings)
- Glass blocks: lasers can pass through them but the player can't
- Lasers: fire according to a sequence, contact with the beam causes death (they can also move and rotate over time but this wasn't used in any final levels)
- Level ends: contact triggers the end of the level
- Moving platforms: can move between any number of positions at varying speeds (supports teleporting) and sit at each position for a varying time; sequences can be reversed easily
- Note platforms and switch platforms: toggle between solid and non-solid; have similar behaviour but use different data to express it, making certain timings easier to design with one or the other
- One-way platforms: can be passed through in one direction but not the other
We also support non-Euclidean spaces through the use of a special screen data object. These can be used to teleport to different areas of the level or create looping screen transitions, for example falling off the bottom of screen A to land in screen B then falling off the bottom of screen B to land back in screen A.
Musical Timing
- Beat sequences: there are 16 'beats' per bar, regardless of tempo or time signature. In effect this is the minimal time resolution of the game and all of the music has been created to fit within and line up with this system.
- Loop bars: objects specify both a sequence of timings in beats, and the number of bars that sequence loops over.
Because songs were designed with the 16-beats-per-bar system in mind, we were able to easily refer to song timings using a spreadsheet.