This was a fun game idea that came from, sort of, an opposite game type. Really light and happy with a structure ready for updating - this project took a bunch of brain power to get right. Also, I tend to build my personal games in a bit of a closed off black box not letting anyone see it until I'm ready for critique/shipping. With this game the learning points were delegation, playtesting, and a bit of OpenGL. Special thanks goes to Jennifer Molloy for getting me out of my comfort zone and helping to make a great game, and also to James Warburton for composing the music.
The original idea for Mazewood actually came through Hypotenuse. Although Hypotenuse is a small fighting game, it was concepted in early stages as a full game with levels. It's also been brought up quite a few times for a possible extension (see Sword of Hypotenuse). Within thinking of Hypotenuse levels, I had an idea for a forest maze area where the sections of forest would shift depending on switches and enemies involved. It soon spiralled out into something much larger than a simple level, so the idea just branched out into it's own game, originally to be a Logger Lady. Mazewood eventually formed out of this idea.
In getting an early prototype going to see how it would play and what would be involved, the meadow rotations was a big thing to figure out. Did the meadows actually rotate around 360 degrees? That might require 3D. How does the Player actually rotate to a specifc direction? The levels would also need to be built fairly easily and able to make edits. Amoung many other concerns was the memory issue of holding a certain amount of meadow images.
Ultimately I ended up going with single-frame rotation animations setup within a preset meadow type. This allows me to use, for example, the A-type meadow as a single path gate. It rotates at right angles clockwise only. There's only four images it needs. I can create any number of meadow types with different shift rotations. Starting small was a smart option, but it is built to expand as desired. File naming conventions are also setup to be able to load a specific A-type meadow under a different theme, if future updates need different terrain like frozen ground, arid, overly populated with foliage, etc. This way allows for growth while keeping down the file/memory footprint.
The clock/degree method was also chosen for obvious reasons of uniformity. Currently, various 90 degree angles are used and implemented, but the meadow types could have more paths with shift rotations at 30, 15, etc., or completely open meadows.
If you've ever seen any of my work in context, you should know that I love a good transition. An experience of a game usually has two or three usability states: In-game/actual gameplay, some selection screen, possibly cinematic scenes. Of course there can be more and there's not a line drawn, but those are the main separations of User Experience in games for me. With that, I like to not pull the Player out of the experience by having them too detached from each other. If there is a need to have them separated then a good transition is needed.
I chose to use the forest itself as the transition, like a curtain. This also implies it's a forest even though there are no trees in-game. The Player touches the options they want then when going into the game the trees part, and they are brought into the game seamlessly.
The art I drew in pencil, scanned in, then painted digitally. When the art went too far polished into a vector art feel, it needed to come back and show the brush strokes. The feel of the world matched better with a visible hand at work. I did play with the mixture of hand-drawn to vector, but I tried to use it to denote the world I've created to the game environment. This is a bit hard to explain but the fictional world needs to be consistent itself, and the fact that it is a game means some info that might break that consistency needs to be handled appropriately (ex. Like a character's healthbar floating in space that the character's themselves don't know about and can't see.). Some of the HUD elements are done in vector to purposely feel detached. This way they demand attention, but it doesn't pull the Player out of the world. Just enough to let the Player know \"this is a button you need to press in order to proceed\" without breaking the Player's experience of the fictional world.
The animations were also done by hand, although some parts were drawn with a wacom directly instead of pencil first. The game can run at 60fps, but the animations don't need to be that smooth with this style. Some are run on twos. I'm mainly not taking advantage of the 60fps because it simply doesn't need it. The non-100% fluidity on the animations play a similar role to the brush strokes versus the vector art. The animations are simple and read well.
With the levels, I wanted there to be an easy flow from designing the level to having it playable. The process was to draw a bunch of mazes in paper form with direction from Jennifer Molloy (shown in the below image from left to right, the second image). In paper form you have to imagine the shifts and keep them in your head while doing the maze, but it gives a first line of testing that's very quick to play with and make changes.
The level is then typed into code form which looks similar to data entry, by listing the meadow type with the initial rotation at the row/col position it needs to be in. Objects are also listed in a similar fashion. The angled tilt of the game is purely aesthetic. The row/column is a simple two-dimensional grid. Selecting a nearby meadow just needs to check whether the in/out gates (the connecting pathways) are open to each other for traveling.
After the level is typed in, it then needed to be playtested along with all the previous levels to see if it fit well with the pacing and difficulty arc. Discussing with Jennifer, we wanted a nice balance of increasing difficulty that would slope back down after a particular hard set. Not slope all the way back down to \"too easy\", but enough to give the Player a since of relief after such a steep challenge. This difficulty roller coaster then builds up the difficulty but at a pace the Player feels is smooth.
There are currently 65 levels as of writting this, but elements and mechanics to be added in future updates will increase that number greatly. With this being the goal, level 50 couldn't be impossible but still needed to be greater than level 5. Level 60 is a natural end to the set, but there is an extra 5 levels to give the Player a bit more with a higher difficulty spike (except for level 62 which is more of the design within the level). With this in mind, it gives the Player something fun to play that has challenges here and there.
Another note on gameplay and early prototyping. Early on when the game was playable there was a bit of time spent researching where the fun factor was exactly. Anyone can know if a game is fun or not, and it's highly subjective, but we needed to know why exactly it was fun. I recommend always doing this and spend the time to find the real reason. With it, you can expand on it and really focus everything to enhance it.
We went and played simple and complex paper mazes to compare it with. The thing we noticed playing these games was that there was three ways people usually played these mazes: A. They draw a line down the initial path blindly randomly choosing directions. Then when stuck, they would just backtrack to the last branch and continue the other way. B. This person would do the exact same as the first, except mentally draw the line in their head. Then when they found the correct path, they'd draw the line straight to it quickly without any misdirection. C. This person would do the exact same as either A or B, but would start from the end goal and work their way to the start position.
What this meant to us was that the maze was fun because you didn't know where to go. If you did a bunch of mazes the first run through each and never needed to backtrack ever, chances are you did not have fun. Part of the fun for us was being able to remember the path we took and work in our heads how to get to the end with the most efficient route. How fast you got there? Did you need to go the complete opposite direction? Was it luck picking the correct directions in a maze that had many branches?
The next stage in finding the fun was to block out some of the maze. Would the paper mazes still be fun if you didn't know where the goal was? This to our surprise was more fun. We used various sized cutouts to be able to see more or less of the maze. In the above example of the different types of people playing mazes, this put everyone on the same playing field. The more of the maze you could see, the more planning you did. We designed the levels with this in mind and used the zoom level as the reveal for the mazes. It is planned in an update to allow temporary zoom-outs to be able to plan ahead further. This is mainly, in effect, to help with a new obstacle character that will be introduced.