top of page

Aubrey Rugroden

     Beyond Below is a small game I made in Unity for a class during my DigiPen academic career. The goal of the class was to present an experience with strong challenge mechanics.

I had 12 weeks to produce a full experience from start to finish. Using Unity, one major goal of mine was to plan and execute upon simple and easily-digestible core gameplay, which would allow me to expand outward around it to provide a compelling experience without much work overhead. I was, after all, working alongside a full school course load.

* * * * *

Solo Work  -  3 Months  -  School Project (Year 2)

Beyond Below

        This project was one of my first full video games made entirely by me, from start to finish. I learned a lot, and I created a foundation for a pipeline that I've continued to develop since.

        Despite this project succeeding in its goals, I did spend a lot of time learning how to do certain things, ones which easily could have been worked around rather than through. 

        I also prioritized making all of the assets -- including audio, which I wasn't particularly skilled at -- myself, despite having my school's audio libraries available to me. This ate up a lot of time, and while I think my handcrafting of every asset allowed for more creative control, it used a lot of time and energy that could have been spent on refining the designed gameplay experience.

Synopsis

Week 3 - Challenge

  The first part of this project was to establish the core challenge loop. I wanted something easily expandable, breezily understandable and feasibly deliverable within 13 weeks. My favorite experiences play with the way players navigate through the space, so I created an interesting movement layout that checked all of the boxes.

    I started with a box and all of the metrics needed to move it effectively (vertical and horizontal movement, visibility, and "energy") and set out to make all of these different dimensions of control act and be acted upon in unique ways, all of which straightforward to understand (push the throttle forward to go forward, push the button down to go down).

     Initial feedback was positive. Players were eager to explore their capacity for movement in this strange way, and the core challenge of controlling my box was a big source of engagement. Based on this feedback, I moved forward.

Week 5 - Core Systems

     With a good foundation, I moved forward with a solidification of my core gameplay. The "big picture" involved a player character (the white pawn) controlling what was essentially a much larger player controller (the big submarine), and these layers of control were my main focus. Key aspects, such as visibility, needed to be expanded upon for players to feel confident in their control. 

     I quickly ran into a problem with the fundamental design: the submarine needed to be very large for players to see what their pawn was doing within, but this meant that very little of the screen was dedicated to the submarine's environment, which was crucial for gameplay. My solution was a minimap. This minimap exposed a larger portion of the world without sacrificing readability of the pawn's state. It also played in very nicely with the mood and theming (the bloop of sonar is a staple of submarine gameplay!) However, I was concerned that players would stare at the minimap too much, so this was rigorously tested to determine its impact on gameplay.

The Timeline

Week 8 - Full Experience

     Tutorialization was a necessary element for a full gameplay experience. My core interactions were simple in abstract (move the sub, change its speed, turn on lights, etc.), but getting players into that headspace naturally was going to be a challenge, especially with a personal goal of tutorializing through normal gameplay.

 

     While I could rely on the simplicity of the controls to reinforce players' knowledge, I still needed to have players gain that knowledge initially. I did this by starting the player out with zero submarine controls and hand-delivering them to the player one at a time, starting with the most foundational (the generator, a fuel source for all other controls) and expanding into the one that added the most complexity (horizontal movement). 

    This trickle, served in a small tutorial-like introduction sequence, served to induct the player both into the world and into the gameplay. Testing proved this method effective, as players after this tutorial's implementation eagerly approached each control in order instead of discovering them blindly.

Week 10 - Level Design

     With the core gameplay set, I turned my attention to the supporting components of the project. I had originally designed the project plan around a very simple and powerful core experience (the controls) with the intention of spending less time on the auxiliary parts, such as the level design. 

    

     The submarine's controls got a lot of bang for their buck from very simple design -- a simple dogleg or narrow opening served as compelling encounters in the context of the gameplay. I used this to my advantage, chaining together simple interactions of increasing and varying complexity to flesh out a sequence that supported the project goal of a challenging experience.

     The expansion of interaction diversity included playing with the "flashlight" mechanic of the submarine. Initially, level interactions required three dimensions: fuel, vertical movement, and horizontal movement. Later interactions required the use of the flashlight as a fourth dimension, and the last sections of level completely removed the flashlight in exchange for an environmental lighting mechanic that served as an alternative to the flashlight completely.

Week 12 - Release Candidate

     My project plan worked well in the final weeks, as iteration of the supporting elements proved painless between testing sessions. Any additions to the core gameplay were skeptically analyzed before implementation. 

     One such addition that passed scrutiny was the repair mechanic: functioning outside of the core priorities of fuel --> movement --> flashlight, it both gave a hard quantification of damage (something tested to have been uncomfortably ambiguous for players) and a means to make the experience fairer, especially after stitching separate levels together into one long experience, which removed the natural reset of damage in level transitions.

     The mood of the game was a focus in these later weeks, attempting to inject as much umami into the experience as I could before submission. I knew that the gameplay was solid, so any supporting effects and feedback would add to the experience without the worry of taking time from interactive elements.

bottom of page