Vania

VANIA

A 2D metroidvania where you explore a series of rooms, avoid deadly traps and enemies, and collect many platforming abilities.

Solo Project

Dev Time: 3 Months

My Tasks

Adapting an existing platforming system to make it extensible.
Designing the core gameplay, including conceptualizing and prototyping various platforming abilities.
Designing a world map full of platforming challenges that make use of a variety of mechanics.
Designing, rendering, and animating all the art assets.
Play-testing and bug fixing.
Design evaluation and iteration.
Sourcing SFX and music.

Try the game for yourself! Playable in browser on itch.io

https://team-quest.itch.io/vania

Retrospective

Concept

This project came from a desire to make a challenging platformer with many abilities, requires the player to learn them well, and eventually use them very precisely and in quick succession, taking inspiration from games such as Mega Man, Celeste, Cup Head, and Super Meat Boy. I had originally intended to make a linear game, but then I realized that the best way to allow the player to learn so many mechanics was to introduce them gradually, at which point I saw the opportunity to turn the game into a metroidvania.

Collision Physics

My first major task was prototyping the platforming controller. Any time I had made a platformer in the past, I had used Unity's built in physics system, but for this project, I wanted to try and create a proper kinematic collision system, which meant coding it from scratch, something I had never done before. I spent a couple of weeks on my own solution and got quite far with it, however it did have some edge case problems that made me feel uncomfortable with using it for the project. Ultimately, I ended up scrapping it in favor of an asset I found on the Unity Asset Store called Kinematic 2D, which provided the base code I needed for kinematic collision, as well as a built-in platforming controller. I then heavily modified that controller in order to make it control how I wanted it to, and to make it possible to add additional platforming mechanics, so whilst the collision code is not my own, most of the platforming code is.

Abilities and Progression

Once I had the platforming controller, I had to come up with as many ideas as I could for abilities, and for this, I thought about two things. Firstly, I thought about the game-feel I wanted to create by the end of the game, specifically, the way in which I wanted the player to be moving around the screen while using these abilities. Secondly, I thought about what kind of gates I could create to stop the player accessing certain areas until they had the required ability. For that purpose, I did research into the metroidvania genre to see how it's usually done, and came to the conclusion that metroidvania abilities usually come in two forms. The first is "movement abilities", which allow the player to traverse the environment in a way they previously could not. The second is "key abilities", which allow the player to interact with and change the environment in a way that allows them to traverse it with their existing move-set. I decided that to achieve my goal, I wanted to focus mostly on movement abilities.

With all of this in mind, I eventually settled on a list of nine abilities, and with those in place, I then had to create a progression path, the order in which abilities would be collected. I decided early on that I wanted this progression to have branching paths, allowing the player to complete the game in different routes. This wasn't necessary, I just thought it was more fun that way, as it gives the player choices. I put a lot of consideration into the order in which abilities were collected and which progression paths they belonged to, for example, one of the abilities was being able to run very fast, and I had designed some screens where the player would need to use this to traverse long gaps, but then there's another ability that allows the player to glide in the air, and I realized that this ability could be used to complete those same challenges, and for that reason, I ensured that the glide ability could only be collected after the player already had the run ability.

A basic diagram I made to depict the order in which abilities may be acquired. You'll notice that the arrows leading into the Blink ability all merge into a single arrow, which means that all the prior abilities must be collected before you can access the Blink.

The map design upon which the game is based. Some of these rooms had to be re-designed, some in small ways, others completely overhauled, though as a whole it largely remained the same.

Designing the Map

The first ability you get in the game is the ability to jump, so to start with, you would only be able to walk left and right or fall downwards, so I started the map design with a tower, where the player starts at the top and receives the jump at the bottom. From there, I created branches stretching out and eventually looping back to the tower, allowing the player to pick a direction to explore and then easily come back and explore new areas without too much backtracking. In the design pictured here, the layout is depicted in basic colors. White represents normal ground and walls, black is hazards that kill the player, and the other colors depict various level elements such as enemies, trampolines, climbable walls, doors and switches, etc. Though it was not intended when I made this design, the colors used here would end up informing the design of these elements in-game to help differentiate them.

I decided early on that, since the game would be made up of many isolated platforming segments, there was no real need to program camera movement if I designed each challenge to take place on a single static screen, and this informed how I designed the map, as every room is small enough that it can be contained within a single camera shot. In engine, the rooms actually vary in size depending on how much space was needed, but they are all made to be one of three sizes, which made it easier to fit rooms together and reconnect paths back to the central tower.

Gameplay Pacing

As I mentioned before, my goal was to make a game that was fairly challenging, requiring players to truly master the mechanics, and so I decided early on that there would be no health system in this game, instead it would be a one-hit-kill system. This meant having to carefully consider how frequently to save the players progress. I had originally thought it would checkpoint the player each time they entered a room, but found this to easy. I then thought I would checkpoint them each time they collect a new power up, but realized this was not frequent enough. In the end, I implemented in-world checkpoint gates, similar to those in the Metroid series, allowing me to manually decide how difficult each section of the game should be.

Pictured in this segment is the map as it appears in the final game. As you might be able to see, there are some rooms in the previous map that never made it into the final game. These rooms were made to house optional collectables, not necessary to beat the game. I eventually decided to remove these rooms as I couldn't come up with a good idea for what these optional collectables would be. I had already decided that there would be no health, and I didn't want to unnecessarily bloat the game with even more mechanics just for the sake of adding this optional content.

Visuals

Art is not my strong suit, and this project was made to be a short game to demonstrate my design skills, and not a commercial release. For these reasons, I had intended to use only very basic shapes and solid colors for the art in this game, and did so for a lot of development. All of the level elements were literally solid blocks with different colors to denote their purpose, looking very similar to the map design I had created. Eventually, I convinced myself to spend some time improving the visuals and I'm glad I did, because while the game was perfectly playable in it's previous look, the small improvements made in the final game definitely make it a more pleasant experience. When making these improvements, I decided to keep the color of each level element the same. This was no longer necessary as the various level elements now had enough detail that you could tell them apart regardless of color, but I figured that the colors would still help.

Another tricky aspect was the background. Originally is was a solid color and then I decided to use a gradient to create the effect of a sunset. The tricky part was ensuring that the colors used in the background were never to close to the colors used on level elements, otherwise it became difficult to see parts of the level.

End Game

I had designed the final section of the map to be especially long, difficult, and require the player to utilize all the skills they had acquired so far, but even still I felt that it was not climactic enough, so I decided to add a Boss at the end of the game, allowing the player to test their skills in a very fast-paced combat scenario. The flow of this fight was designed to imitate those in the game Cup Head, requiring the player to perfectly dodge quick and frequent attacks while constantly barraging the boss with their own projectiles.

Feedback and Polish

In the final stages of development, I was iterating on the game a lot as I played through the it many times, and got other to play it too. Based on my experience and their feedback, I made changes to mechanics to make them more intuitive, including but not limited to:

General adjustments to the platforming controls.
Adding a little bit of forward momentum to the player when they reach the top of a climbable wall to push them onto it, so they they wouldn't fall back down.
Stopping the player from being able to wall jump off of a climbable wall unless they're already climbing it, thereby preventing the player from wall jumping when they wanted to grab the wall instead.
Making a clear distinction between doors that open permanently and doors that are open for a set time.
Changing the blink mechanic to teleport the player in the direction they are inputting, rather than the direction of their current velocity.
For the sake of players on controller, locking the players facing direction while firing projectiles, allowing you to fire in a set direction without impeding your movement.
Experimenting the different input configurations to ensure that it is possible to use any movement ability without having to take your finger of the fire button, mostly for the sake of the boss fight at the end.

While playtesting, I was also searching for ways in which I could sequence break, i.e. play the game via a route that was not intended to be possible, and then changing the design of certain rooms to eliminate the break. That said, there was actually one sequence break that I found and I decided to leave in, as I know that some players of metroidvania games actually enjoy looking for and exploiting obscure sequence breaks, and this particular one I found was somewhat obscure. It requires you to already have all the abilities available to you at that point in the game, and even then is still very difficult to pull off, enough so that it's not immediately obvious that it is even possible. Also, even if someone did find it, they would only skip one section of the game.

Criticism

There are some changes I would have liked to make but were not feasible to do so. Most significant of all, it occurred to me during playtesting late in development that the glide mechanic makes a lot of the platforming challenges much easier. It doesn't necessarily break the game, but it does reduce the aspect of challenge that I had intended at the start. I unfortunately couldn't really change this without completely reconstructing the design of various sections of the game, but were I to start over, I would make sure the glide ability came much later in the progression path.

Conclusion

I enjoyed making this game. I do think it ended up straying quite a bit from the initial concept, but I am still happy with the final result. The metroidvania aspect of the game, while not intended at the start, was something I'd never made before and was very fun to develop, and I still achieved the challenging platformer experience I set out to make, at least for part of the game. While it worked in this case, in the future I will be more mindful of keeping my game in line with the original concept and not letting them get sidetracked or bloated.

One of the biggest detriments to progress during development of this game was frequently having to bug fix changes to the core platforming controller that came with the pre-made asset. The base version of it was very good, but the process of overhauling it to accommodate for changes and new features was very difficult, as it was, in my opinion, an overly complicated system and not very extensible. Sometimes making very small changes to it meant having to spend a long time debugging various other scripts. It ended up working out in the end, but in the future I will be more mindful of the risks involved when basing a game off of pre-existing code, especially when the author of said code is not available to help fix it when it inevitably breaks. In all honesty, I'll likely stay away from code assets from now on and just figure it out myself.

Page updated

Google Sites

Report abuse