Concepting

My first iteration of the possession mechanic centered around story. I'd imagined a fallen gladiator possessing each warrior he had fallen to, in order to become the best in whatever coliseum he presided in. This was problematic because the designs should be iterable, marrying a design to a story defeats that purpose entirely.
Through group iteration we decided to keep the mechanic, but changed the theming to dungeons and monsters. This allowed for greater variation in design because we no longer had to think in human constraints; and by breaking each level into a separate dungeon, we could explore layouts that wouldn't be possible in a more static arena shape.

designing 

The set of monsters I had created with the other designer came with a few problems that showed themselves in the initial phase of programming.
We decided on a grid based system with one action for each turn. This is something I didn't, fully, account for when designing the enemies. In my designs I created too many degrees of freedom, which in turn would require more programming and more buttons pressed before the player could actually do what they want.
Using the goblin as an example, it originally had eight degrees of turning for attacking. I did this to differentiate it from other monsters that only had four degrees of movement.
I designed the controls system based around the differences between the two movement systems. The arrow keys were for movement and the space bar for the action. This would have bogged down game play if it was not changed.
Instead we opted for a controls system that only used arrow keys, consolidating every monster into four degrees of movement/action.
This highlighted the importance of controls when designing any system. Players cannot enjoy something they cannot easily play.
It also highlighted the importance of small mechanical differences that allowed everything to feel unique. As opposed to creating enough complexity for everything to feel unique, which takes much more time in the long run as more and more things get added into a game. 

Bug fixing

I spent the most time trying to figure out why possesion was not working early on in development for the game. This was blocking both programming and level design from testing anything further. We were at a near stand still for too long.
The problem was that a variable was static, so the possession wouldn't change properly.
At one point during my efforts to bug fix I was told to just remake a class because I had been working on the problem for too long. At first I was skeptical, but it led me to realize that the problem, was a static variable.
This has allowed me to see how dangerous static variables can be, and to properly comment when one is being used. As well as, the knowledge to look through all scripts that are being used in a scene because I can never truly know where something is being changed from.

Proctoring

Players surprisingly wanted to be able to completely fail a level. Up to this point I had been worried about certain enemies and objects preventing the levels from being fully completed. It showed me the importance of having open ended questions or suggestions for the player.  
Level Design

Each level can be completed in a minimum number of actions, which gives the player a zero to three star rating. Levels are locked behind star counts, requiring the player to master the mechanics as they move forwards.
Here are the levels that I made:

Level 19

Level 18

Level 15

Level 13

Level 12

Level 11

Level 9

Level 8

Back to Top