SteadFast

Dive into our movement shooter/hack and slash game SteadFast and traverse through a dangerous abandoned warehouse while surviving a deadly onslaught of enemies whose sole purpose is to stop you. SteadFast aims to provide a thrilling, high octane experience through intuitive and fun movement mechanics combined with satisfying combat to create gameplay reminiscent of Titanfall 2 and Doom (2016).      

Reacquaint yourself with your cybernetic body after awakening with no memories of who or what you are. After proving yourself in the tutorial level, it’s time for the real test as you’re placed in an unknown, hostile environment with nothing to do but advance and survive. Decide between fight or flight as hordes of robots chase after you. Jump over swift melee slashers, outrun the bullets from the riflemen and grapple past the deadly drones with their advanced targeting mechanisms.

Aided with the built-in vital monitor and heat signature module, survive and escape the warehouse without falling prey to the enemies that block your path. Although you only have one life, don’t be afraid to get your hands messy and slash your way through enemies, blasting a few along the way.

You have one life, use it well.

 

SteadFast Early Build:

• A tutorial level and 1 level
• 4 Enemy types
• 2 Weapons
• A slew of movement mechanics
• Short for Replayability.

 

Controls:

•  

 

Post Mortem:

We hit most of our goals in regards to core gameplay mechanics for this game, with some bugs and issues we didn’t have the skillset to fix, but we were able to get an indoor level that allowed for the use of all the movement mechanics. The player combat mechanics were able to be implemented with very little problems and work well with each other. The poolable objects created for bullets and enemies worked perfectly and significantly reduced the load of our game. Enemy attacking also worked as expected with some animation weirdness but the player would take damage from all enemies, whether it be a melee attack, laser bullet, normal bullet or homing rocket. Movement implementation was smooth and almost all mechanics promised in the design document made it into the actual game, with a few exceptions due to game balance. When it came to stitching together all of our individual pieces we had very little errors which indicated that our code was modularized and meshed well.

A lot of our hiccups started early on into the development process as we had problems finding unity assets for the environment and getting the type of environment we had envisioned. The gun originally was supposed to be way more robust and could add way more depth to the movement mechanics. We experienced major problems with Unity’s physics layers for some reason in the beginning of the project, which ended up taking a week to fix. There were problems with the rigging in some of the models we wanted to use so they had to be scrapped. This left us with only characters from mixamo.com since we used their animations. In those animations, there was a lot of animation weirdness that we could not fix without breaking the entire animation. Nobody on the team had experience with Blender or other 3D modeling software to edit animations, so we were stuck with what animations we had. Github and merge conflicts were causing us a lot of headaches as well in the first two thirds of the project which slowed our integration process. We also did not start early enough to solve all of these problems, leading to cramming and cutting features later down the line.

Some problems we weren’t able to fix by the deadline but we managed to fix most of our early development problems. We ended up using two packages for the level design, one we found before from the third Game Jam and the other we found and used for the tutorial level. The gun ended up being way simpler than in the design document but it still serves its purpose and works well. The layer issue was fixed with a dump of an old project’s files into the new project which we were working on which was a last ditch effort but it worked. Some of the animation problems were fixed with some avatar masks and animation blending in the animator controller but the fix was far from perfect. After learning more about the Git bash and a very helpful session with a UGTA, Orion, we were able to fix all of our merge conflicts and prevent future conflicts.

Due to time constraints and a lack of production oversight, the environment went from being a rooftop level to an indoor warehouse level because we did not have the assets to create the environment we had envisioned. The player was split into two separate prefabs one for the camera and the guns with them and another for the actual player and movement. This modularized the player and made implementation extremely simple with little to no errors. We decided to cut the boss from the game since we could not figure out why our mixamo.com animations were broken on the characters they were remapped to. Instead, a new type of enemy was added: The Homing enemy, which shot homing rockets that would arc in the air and make contact with the player and deal damage. The boss room was then replaced by a larger room with enemies continuously spawning on a timer, more akin to a final wave.

Although this game wasn’t all that we had hoped it would be when creating our design document, we still managed to create a playable game with a fun gameplay loop. We realized that depending on what assets you can get you might change certain aspects of the game since the environment is such a large part of the player’s experience. We learned a lot about Unity coding and especially being able to code certain things without the help of a unity tutorial. The Unity library of methods and classes is scarily complicated and confusing, but when after working with Navmesh, coroutines and Ienumerators, we are more dangerous with C# now then when we started this project. In future projects it would be a good idea to assign someone to deal with animations and other model related things so future games don’t get stuck with placeholder art.