Quadrophobia: Level Design and Constraints (on Design and Play)

I’m at the point, with walls, now, where I’m trying to imagine the “puzzle” aspect of the game.  And this part is a bit harder than I expected.  Because walls, by themselves, only offer minor challenges.  Without any way to alter what you do as a player, all you can do is move the amounts you’re given on your piece.  The one feature that walls, as they currently provide, is a stop point to help a player move fewer places than they would in that direction.  One way I intuit it might be feasible is to allow a wall to impede movement in the short term to get you to your path quicker in the long term.  That is – the path seems blocked compared to taking the non-blocked path, but I might be able to design a puzzle with this concept where you WANT to bump into a wall to get somewhere in the short term.

But now that it’s there, I’m having a hard time seeing walls as anything other than a limit.

Right now, all the game exists as is an “order of operations” puzzle.  Because the player has a piece that tells you where you can go, and the walls limit that (reduce the scope) but there is nothing the player can do but move around the walls.  I had been hoping that by putting some walls in I might have some good design options, but I realize upon reflection that such is not the case.  It can help towards a better design when I add more, but currently it doesn’t offer me much to go with, besides a tutorial level or two to teach players how to think outside a direct route.

One of my main goals with the design is to start with simple level mechanics, and add more each new set of levels, teaching players how to go along.  This is obvious, really, but instead of having one big tutorial in the front of the game, where players have to remember a whole shit-ton of rules/options/abilities, I figure it’s best to slowly integrate them as levels.  Then after the core mechanics have all been introduced combine them in unique ways.  And this is where I get to the main point of adding more mechanics.

1) Moving walls

The movement of these walls wouldn’t be random, of course, but rather a sequence of walls that would go on and off in a pattern.  Whether it be some sort of clockwise/counterclockwise switching on of walls or alternating sides (i.e. mirroring) or something of that nature.  This would require more programming and mathiness.  But if it’s what it takes to make the game more fun/challenging then it’s worth it, but… I think there are simpler options to create some design capabilities that would require less programming as part of the level design.

2) Keys. 

You would have colored triangles that acted as keys to bring to the portal(s).

With this concept you could do it two ways:

A) Have more than one portal. It would be up to the player to determine the best path to get the keys to the portals in the shortest number of moves.  There would be no specific order for the keys to go to the doors.


B) Have one portal, but it changes color.  The first color is the first key you need to obtain, once you do that, the next color appears.

I feel that option A has the best utility for design fun.  While option 2 does place constraints on it and ensures a more tightened experience, I think it also limits outside the box thinking, because, once more the player has a constrained set of paths open to them.

C) An in-between option might be to have one portal at a time, but once you land on a portal, a new portal opens in another location with another key in another spot, as well, basically it would be 3 mini-puzzles on one board.  The same board layout, but just the starting point, goal location and key locations would be different.  That might work as an intro to the concept, perhaps, and then open it to the full concept of 3 portals and 3 keys at a time.

3) Rotation/Mirroring of playing piece. 

This option would allow players to rotate a piece in certain ways or “flip” it either vertically or horizontally.  This would let them think of new ways to move the piece.  There may be some constraints given to the players so they can’t continually just move the piece.  They might have a limited number of such rotations/mirrorings that they can perform total.  Or they are given a specific set of possible alterations that they can choose (a la Chu Chu Rocket).  Question – does rotating/mirroring count as “a move”?

4) Altering the Move Number

One could give players a certain set of values and/or plus/minus signs that would allow them to alter the move values on their pieces.  The question here is whether using these alterations would count as a move in themselves?  My initial tendency would be to keep it simple and not have it count towards their total moves. KISS.  I’m actually thinking maybe a simple set of +/- signs that they could drag/drop onto a given “face” of the square to increase or decrease the move options.

5) Breakable Walls

This feature has a few interesting options as well.

A) A wall could be marked “breakable”, and all it means is that the first “hit” when you run up against a wall then breaks it and it no longer exists.  That is, the wall would cost 2 moves to move through it, vs 3 moves to move around to the adjacent side, for example.  This, however, seems to be too constrained to the players and doesn’t really add much in the way of options or choice.

B) Walls could have “hit points” and the move amount on a players side could determine how much damage (that is to say, the “move” amount acts as the “attack points” against the walls “hit points”).  The further question is – would the players move/attack points be reduced in some manner?  Like – would the walls “hit points” act as “attack points” against the players “move points”?

I am leaning towards that latter element – player’s move points act as attack points against a wall’s hit points and the wall’s hit points act as attack points against the player’s move points.  Adding this in with rotating/flipping the piece adds some nice multi-leveled complexity in terms of game play options.

6) Warp Gates

I was going to call these portals, but since portal is the main exit object of a level, I figure I should have a different name.  The idea here is that you have “walls” that are different colored from the normal walls (probably different in appearance, too).  These act as warps that bring you to a similar colored gate in the level.  So I might be on an edge and it could bring me to a location in another area once I step through it, and appear out of the corresponding colored gate.  Once could play with the concept of changing the colors of gates as you go through the level.  Perhaps you have 3 gates, one of which is a sort of “wild” gate that you can change color of, via some method.  Then as you play, you can choose which color you need it to be (and affect it somehow – whether that be via a “paint” action that takes up a move point) or some other way.  I don’t know if that’s the best thing to add in, I think that might bring too much complexity with not enough benefit.  Designing a level with gates in it alone should open up some interesting potential.


So what do I work on next?

Given that I have walls already up and running, I think Breakable Walls is ideal, since it would just add some more code to an already existing feature and it’s just “adding”/”subtracting” values (there’s that word again… “just”)

After that, Gates might be the best, as they’re similar in appearance to walls, so much of the same code can be used for them, too, just altering what happens when a player touches a gate)

Quadrophobia: Wall Detection and movement collision done

Well, I have been majorly slacking the past, month(?)  Aside from TDay, in general, I’ve just not been in a very code-y mood.  That’s both the advantage and the curse of hobbyist development.  There’s no incentive of money to forge ahead, so it has to be self driven.  If one hits that low point in the cycle, they can just “turn it off” for a bit.  The curse, of course, is that it means you MUST be self-driven and if you aren’t able to pick up and go again, you’ll just never get it done (not that I would know about such things).

Anyways, this weekend I sat down, got wall detection/stopping on rightward movement.  Then to do left, I had to dick around, finally figured out that really all I had to do was “reverse the polarities” (change a few negative/positive signs) and it works for left, and then just transpose x/y and the assorted signs for up/down and I’m good. YAY!

Now to design some walled levels.