MAXIMON'S CURSE


Summary

Follow Maximon the cursed Aztec on his journey to expell the evil within an ancient temple. This 2D platformer was produced over 8 weeks half-time by a team of 10.

Responsibilities:

  • Level Layout and Design
  • Map implementation and propping through "Tiled"
  • Gameplay Balance and mechanical design.
  • Main Level Designer on Level Two "The Attic"

 

Design:

We took our main gameplay reference from "Ori and the blind forest", where we burrowed the "Bash" mechanic and build the gameplay around that one focal point. All enviromental mechanics were build around this one ability, some of which we burrowed directly from Ori, and some original. 

Ori and the blind forest, is also a metroidvania, and while metroidvania's where wastly out of scope for these kinds of short projects, we still wanted to recreate a metroidvania feel. So we made "Jump" and "Double Jump" abilities the player would unlock later in the game. This also helped emphasise the Bash as the main ability, as that, besides walking, was the only interaction the player started with. We then build the first to levels so they display unreachable paths, that the player would later loop back into once the unlocked their new ability, in true metroidvania fasion. 

We split up the level into sections, and dedicated a player or enviromental mechanic to that section. So each area just explored all the possible quirks and interaction with their main mechanic, only using previously introduced mechanics, to build upon. 


Thoughts and Reflections

One of the stregnths of the Bash ability, was that is allowed us to create a strong and diverse suit of enviromental mechanics and hazards. Without any extra code or scripts we managed to create traditional puzzles, chase/speed segments, fast flowing platforming sections and even a rudimentary boss fight. So whilst the bash mechanic itself was quite expensive, time wise, to make, the following mechanics were so diverse that it ended up being really cost effictive for a project of this scope. 

A piece of feedback that we repeatedly got after the game was completed that we should have realised and acted upon, was that our high speed platforming segments were really enjoyable but untilised. We had a tiny segment that alot of people reacted very positively too, and in turn reacted negatively that the rest of the game hadn't used the same pacing. Whilst the game certainly had a slower puzzle feel by design, more of those segments would have greatly improved the experience, and allowed a even better pacing of different types of game feel.


 

Group Acomplishments

Throughought this project the Level Design team had a quite unique process compared to the other projects. Instead of imeadiatly dividing the game into levels and fields of resposinbility for each level design to work on, we first listed out all the enviromental mechanics in which order we wanted to introduce them. We figured this out by looking at two key metrics, Inherent Complexity and their level of dependcy on other mechanics, it's silly to introduce a projectile teleporter, before you introduce the projectile. After we had set out this pacing, we then began just creating as many cool rooms and challenges based on showcasing all the cool aspect of one particular mechanic, using only mechanics introduced prior. Then once we had built and selected the rooms we liked, we began combining them into actual segments and levels. 

The result of this process was that the gameplay was quite well paced and none of the room really rehashed already explored ideas. The enviromental layout probably suffered somewhat because of this, as the layouts didn't really resemble cohesive places. Lukily this was mitigated by the inherent abtract nature of Platforming Levels. All of this also meant that their was a clear priority of which mechanics to build first, and which were easiest to cut, as later introduced mechanics rarely had any depency on them and were easier to cut.


Group Obstacles

Given that this was the first project were we had to deal with simplyfied gravity and colision. The bash ability proved to be rather hard to implement, and took longer than inititially expected. To mitigate this and help us playtest earliere, the initial prototype of the bash ability teleported the player instead of dynamically moving him through the air. Whilst not perfect, this allowed us to playtest and rough out most metrics in regards to the enviromental puzzles. We however knew that this had to be changed, as it also allowed for a whole suit of unintended behaviours, like teleporting through or into terrain. 

As the project neared it's end, and the bash implementation wasn't finalised, we prepared the best we could, by listing out all challenges in order for how likely they were to break once the new behaviour and metrics arrived. This meant that when the upgrade arrived, just a few days short of deadline, we could quickly run through and fix all the major outliers immediately, without having to discover them first. This meant that outside of a few edge cases, the final game was largely unaffected.

 

 

Team : "Team Kill" 

Level Design

  • Adam Weith

  • Joshua Christiansen

Graphics

  • Nina Sas

  • Rasmus Björk

  • Hedda Peterson

Programming

  • Jacob Reimer

  • Hannes Elofsson

  • Nikal Uttebäck

  • Sebastian Szymanski

  • Gabriels Eriksson Cic