Available here
A big part of Glitchspace is puzzles. Without them, the programming experience would just be incomplete. Therefore, for this post, I wanted to take the opportunity to talk about some of the processes that we went through in designing the puzzles for 2.0 (note that I won't be showing the programming interface here as I don't want to give the solutions away!).
With Alpha 2.0 we have put a lot of focus and attention to detail on their design. The update will have 30 different puzzles, broken down into the following concepts:
Level 1 - Translation (also acts as the tutorial level).
Level 2 - Collisions.
Level 3 - Forces.
Each level has around 10 puzzles each, breaking down their respective concepts. Choosing these three as the initial programming ideas to be introduced to the player were deliberate choices on our part and were chosen for the following reasons:
- These are some of the more simpler concepts to introduce.
- The concepts are very kinetic, allowing us to create less static environments from the get go.
- They flow into each other seamlessly i.e. collisions can't be introduced without translations, forces can't be introduced without collisions.
One of the issues that we have with current 1.x versions is that there was either just too much of the same concept being thrown at you, or alternatively a concept was introduced, dropped for x amounts of time, before being suddenly reintroduced at point y of the game that just didn't make sense. And x + y didn't even add up in the first place! The result was players getting bored before a concept was even over, with the game's flow and pacing feeling disjointed. The balance of the mechanics just wasn't there.
Therefore, in making these levels, a unifying goal that we had throughout was to make each puzzle feel unique. This would allow the player to explore the possible applications of a programming concept in a multitude of ways, whilst at the same time seeing the game's programming logic from a variety of angles. We also wanted to have a sense of interplay or connectivity with the environment around you, something that the current version lacks.
To do this, we went back to the machines that were built:
As a platforming element they were cool, but we knew that we could do so much more with them. So... what else? Well previous posts have mentioned how we have data flow as a navigational tool, but that it also acts as another obstacle for the player. So in this case, contact will result in your death (or some sort of tron-esque "dematerialization," thingy):
There's several others that you'll see in 2.0, but one of the more complex obstacle ideas was in doing this with them:
Robin and I also talked about having animated stairways; think of the seats that you'd see in an indoor gym that contract into the wall when not in use:
Another area that we wanted to push for in the puzzle designs was for an extra layer of challenge by having multi-step puzzles. That is, puzzles that require more than one piece of programmable geometry to be solved. The result is that it also allows us to recapitulate previously introduced programming concepts in a way that feels fresh and different to the player. 2.0 won't see anything too taxing here, but we'll be building on this as we release subsequent updates (can you figure out how the one below could be solved?):
As we go towards the full release the concepts will increase and the number of puzzles to go with it. With this the complexity of the programs that you make will increase too in a much more consistent manner. We'll likely be reintroducing all of the concepts that were used in current 1.x versions; we just need to figure out how they'll be reintroduce, where and why they should have a place in the overall game experience.
Over and out,
Ronan.