Niraya

Description:

In this 2D hack and slash platformer, you play as a fierce warrior that has to fight her way through a dangerous forest filled with monsters in order to rescue her pet dog. Core gameplay elements include jumping, attacking, dashing through enemies and death. Should you perish, you get one more chance to get to your dog before having to start over. Once you die, the world changes around you, the forest gets darker, and previously killed enemies come back in the form of skeletons.

Development:

Niraya began development as a group project in my Game Design and Algorithmic Problem Solving II class. I began working on the player class, specifically the player's movement and finite state machines. By the next milestone, I had completed the enemy class, their basic movement, and the ability to give and receive damage. I was particularly proud of the work I did on the method that causes damage to the player. Initially, when the player and enemy hitboxes collided, the player's health would continuously drop. In order to fix this, I added an invincibility timer that would start as soon as the two characters overlapped and would restart if they separated. By the time the semester was finished, I had also worked on the level design and helped iron out the enemy animations.

Challenges:

One of the challenges working on Niraya was getting accustomed to the MonoGame engine. Before this, I only had experience using the Unity game engine which has a lot of features built into it. In MonoGame, these features such as the camera and collision systems had to be programmed into the engine. This was difficult initially, but having to create these systems from scratch was a fun challenge for me. Another challenge was definitely the group's communication. I think that a lack of communication led to our group falling behind on our game at some points and lead to some confusion about who was doing what tasks. Having a group project on top of our regular classes, work, and social commitments could be a challenge. I think this issue is something that could have been remedied by simply utilizing Trello and Discord more often to make a schedule that everyone could agree on.

What went well:

The hardest part was the second milestone which oversaw the addition of collisions, movement, and the scripting of the enemies and the player taking damage. At this point we had figured out the tile switching mechanic and level input/output. After completing this milestone, we had a solid foundation to move forward. Since we had our basic systems in place, we were able to continuously build on that foundation going forward. The scope of our project also went well. From the beginning, we wanted to focus on the movement and the combat, while everything else was a stretch goal. Once we had the basis for the movement figured out, we were able to implement the feedback from playtesting. After we ironed out what we wanted our game to look and feel like we were able to focus on the more difficult tasks at hand. During the final stretch of the semester, I also helped fix any bugs that were left, one of which was the level not changing to the next one even though our end-of-level marker was there. The player was not able to interact with it for some reason. Through well-placed breakpoints, I figured out that although the sprite was there, Y coordinate of the hitbox at the end of the level kept increasing every second causing the hitbox to be at the bottom of the level, meaning that the level would never end. The error ended up being a plus-sign in the update function, when instead the equal sign was needed.