A Slime's Knightmare

Game Genre

Isometric Jumper Minigame

• When I first started on this project, it was for a class on rapid prototype production, where we'd be grouped into multidisciplinary teams with the goal of creating a game to adhere to a theme in 2 weeks

  • This project's theme was simply to create a game that was "fun" with no other direction. After discussing it with the rest of my team, we settled on a concept that was simple to pick up, but somewhat difficult to master

    • We figured the use of both hands simultaneously would be somewhat challenging for casual players, and opted for utilizing the keyboard for movement and the mouse for some arbitrary auxiliary action

    • In addition, the genre of gameplay would have to be something casual to make it more approachable and to ensure we didn't overscope with complicated mechanics; our solution was to go with an isometric jumper game, where the player could only move in 4 directions and jump using the keypad, and dragging rooms to traverse together using the mouse

      
      

Game Engine

Unity 2022.3.0

• Given the incredibly short time we had we chose to use Unity due to me and our programmer having proficiency with C#, allowing us to iterate quickly on our few mechanics in order to create the best gamefeel possible

  • Given we weren't required to make a graphically impressive game, we went with a low-poly art style, allowing us to quickly integrate and fix any issues with the assets from artists as they reached completion

Responsibilities

Technical Designer, Producer

• As a Technical Designer I worked with our team's programmer to script the various mechanics for A Slime's Knightmare

  
  

  • Throughout the project my main area of ownership was the 3 C's:

    • Character

      • While I did not physically model the character, I pitched the idea of a slime that was trying to escape a dungeon after being pursued by the vengeful spirit of a knight that fell victim to it. To give the model a slime-like visual I created a custom material using the Shadergraph Unity plugin, and configured an audio controller with edited sound clips to give it "squishy" sounds as it moved

      • In addition, I created a script with multiple exposed fields in order to easily adjust traits such as jump height, jump speed, ground drag, and turn speed; this allowed us to isolate individual traits and test with multiple variations, finding the preferred average across users during playtests

        

        
        

    • Controller

      • One of the biggest critiques of controlling the character was that there wasn't a easy method of telling where you would land- my solution was to take a small cylinder without collisions, give it an unlit shader, and project it directly underneath the slime, matching the normal of the surface to resemble a shadow

        • My inspiration from this came from the Super Mario Galaxy games, where despite the lighting scenario, Mario would always have a distinct shadow to show what surface we was above (relative to the gravity in a given instance)

    • Camera

      • In order to work with an isometric camera, I needed to convert the WASD movement by 45 degrees to ensure moving horizontally within the engine was represented appropriately within the game view

      • In addition, since we couldn't move the rooms that the player was in without the model constantly recolliding with the floor and bouncing, I instead had the camera move up to the center of each room as the player entered it

        • From the player's perspective, this looked the exact same as if we had descended the stack of rooms into the killing fog, but avoided having to reconfiguring the default physics engine, which would've taken significantly longer

  • In order to provide some production value, I also scripted an audio handler that could be easily utilized by our programmer, allowing us to quickly find small audio clips for things such as the player jumping, rooms appearing out of the fog, and even small voice blurbs for the knight's ghost based off of the win/lose state

    • In addition, it allowed us to easily configure the background music and blend/fade it as needed when transitioning from the main menu to core gameplay

• As a producer, I was responsible for creating and adjusting the timeline for our production process as needed to ensure we reached a completed product by the end of the second week

  • In order to appropriately break down tasks, I spoke with each of the members of my team to gain a better understanding of their workflows, and subdivide the needed tasks to give everyone an appropriate amount of hours

    • Primarily this help us with the creation of the puzzle rooms, as we wanted a larger variety of them to be able to spawn

      • This involved tracking time with our environment artist and seeing how long it took to model and texture our assets to see how many we would have in total

      • Additionally, I worked with our level designer to concept dozens of individual room ideas, and once w had our list, tracked the time required to make a few rooms to estimate how many variations we could have total

    • Through accurate assessments, we not only were able to achieve a completed product, but had 2 extra days to run extra playtesting out of the initial time allotted

Duration

2 Weeks

• For the rapid prototype production class, we were required to demonstrate our progress at the end of the first week, and incorporate as much feedback as we could for final presentations on the second week

  • During our first week, we spent approximately 2 days coming up with our game concept and spent the rest on our character controller, level assets, and individual mechanics for rooms

    • The project was fairly well received in this state, with our only feedback to ensure that we had art assets that we wanted to show off in-engine, rather than static images on a slideshow

  • Our second week was comprised of us finalizing room layouts, completing and integrating art assets, and improving production value through VFX, SFX, and multiple rounds of player feedback

    
    

Lessons Learned

• Given the small size of this team, I would say that the most important lesson I had learned when making A Slime's Knightmare was to adapt and expand beyond my role as needed; as a technical designer I was expecting solely to aid in the grand design and code a feature or two, but given how much needed to be done in order to reach our final vision for the project, I would need to wear multiple hats

  • While I did focus mostly on the 3 C's, I ended up moving a bit into audio engineering with my audio manager script, and often worked collaboratively with our programmer to aid in getting a given feature done, such as the tweening for rooms appearing and disappearing from the fog

  • Moreso, I also gained a greater understanding of how different tracks (especially art-based ones) worked, allowing me to better serve my team as a general producer

    • Additionally, in assigning tasks, I was forced to teach myself how sprint velocities worked and how to calculate them, ensuring we had an adequate amount of work and enough time to complete our goals