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.

Specifications:

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

Awesome Subtitle

My first pre-alpha blockout level, took direct inspiration from Diablo. Mirroring Diablo’s procedural nature, featuring multiple rooms and corridors that all intermingled and connected into each other. Enemy placements consisted mostly of various blobs haphazardly scattered around the different rooms.

This iteration showed multiple issues. The levels lacked direction, and since there was no loot from the enemies, getting to a dead end didn’t feel good. Most encounters also felt too similiar, which again went against the core goal of creating more interesting moment to moment gameplay.

Awesome Subtitle
 

For the second pre-alpha iteration i went with a fully linear approach. I wanted to taylor it’s room to even out the difficulty curve and make each encounter more interesting. It also helps that way less of the content was skippable, which is definitely a plus given the project's scope.

Being much more linear it was way easier to pace out the gameplay, and it overall felt alot better. However i did discover that having single enemies scattered around the levels felt very bad, as it didn’t really give the player any opportunity to be efficient with their cards. And wasting one to two aoe ability cards on a single enemy just felt inefficient and unfun. It became clear that enemies should always come in packs, and that i would more enemy and encounter variations to keep the game interesting. While the linear design felt a lot stronger, the level itself was designed somewhat unintersting, with the player basically just moving in a straight line through most of the level. So i knew for the next iteration i would need to feel less linear.

Awesome Subtitle
 

The first Beta Iteration, and thereby the first full build of the game, had levels that followed this linear structure, but contained way more twists and turns to mask this fact. This also kept the levels more visually interesting as not only did the environments change, but so did the directional perspective of things. I also knew i had to pace out all my different enemy and encounter mechanics to ensure that each segment felt fresh and had a sense of purpose.

Understanding the goals

When it came to designing the abilities it was clear that each of them needed to have distinct strengths and weakness, this was needed in order to achieve our goal of encouraging interesting moment to moment decisions. For instance, if all abilities boiled down to an projectile that exploded on first enemy impact, the real depth of the moment to moment decision making would be gone.

On the flipside the differences couldn’t be too strong, if for instance the game had enemies that were immune to fire damage, any fire ability on the players hand would be a dead card. A dead card would, in the best case scenario, result in the removal of all choice, as the two other cards would be a straight up given. In the worst case scenario multiple dead cards would force the player to simply waste and throw away cards to draw something actually useful. Therefore it was important that each card always had use regardless of the situation.

In found that all well designed cards could, roughly be split into two inherent categories; Finishers and Enablers.

Finishers

Finishers are cards that does not really change or alter the effectiveness of other cards after their use. Instead they derive their core value from conditions purely found in the environment. A straight forward example would be an card the creates a Explosive Nova around the player, damaging all enemies close to the player. An ability like this has a clear use case, but it does not really affect the value proposition of any other card in the players hand, outside of maybe eliminating some targets for the other cards to kill. Another example would be a boomerang, that flies straight out and back, which is more useful in scenarios where enemies are lining up, than when they are surrounding the player.

Enablers

Enablers are cards, whose core value are determined by which other cards the player has access to. An example would be the “Blink Dagger” an projectile which teleports the player behind the first enemy hit. Such ability is a lot more useful when the player has an Nova on hand, as opposed to a boomerang. This dynamic is almost universally true regardless the environment surrounding the player.

///A Cool Subtitle\\\

By categorizing all abilities like this, it became a lot of easier to design and balance the various cards. It also helped me better contextualize their use cases, which is helpful when trying to determined which niches each ability represents and fulfills.

In hindsight though i wish i had looked out more out for this balance, as currently the game features way more finishers than enablers, which definitely skews the balance.

//AWESOME SUBTITLE\\

In order to fully fulfill our design goal of having abilities that excel in different type of scenarios, there need to be different scenarios in the first place. A lot of this is derived from the level-design, which dictates the flow of encounters through the map layout and enemy spawns.In this context It is useful to think of the different enemy variants as tools in the level designers arsenal, each one giving the designer more knobs and levers to tune the experience. Given the limited nature of this project, it was important to me, that each enemy variant felt different and solved different issues, as i couldn’t afford to spend time developing multiple solutions to the same problems, when others were still unanswered.

//AWESOME SUBTITLE\\

When it came to the individual design of each enemy, i found that the most important question ask myself when designing each one was, “What will this Enemy Asks the player to do?”. Each enemy behaviour will naturally, encourage og push the player towards certain responses,  and by designing each enemy around which response a player ideally should have to them, helped me outline a smaller subset of enemies, that each felt more distinct from each other.

The Basic Melee Enemy

The Melee Enemy can be seens as the default and simple enemy type. It dosn’t ask the player to do alot, all the player has to do is keep distance to the enemy and kite it around.

The Slow Strong Melee

This enemy is a slower and harder hitting variant of the basic melee enemy. It’s main function is to disrupt the pace at which the enemies die. Without it all the melee enemy groups basically feel the same, regardless of size, as they all die at the same time due to the AOE abilities of the player. By having a higher health enemy, the player is encouraged to focus the bigger on, while trying to make sure the attacks also hits the smaller enemies.

Lightning Skeleton

The Lightning Skeleton is the first ranged enemy introduced in the game. It’s main goal is to prevent ranged and kite centric playstyles from being to dormant. It Creates and Aoe around the players current position that strikes after a short delay. Asking the player to keep moving regularily. This is naturally a bigger hindrance for ranged playstyles, as their abilities tend to have longer cast times, which leaves them stationary for longer. Melee playstyles would most often be equipped with faster abilities and more rapid movement options. The lightning Strikes also hurt other enemies, which again is a boon to a playstyle that stays close to other enemies.