Project Office - 3D Level Design | Character Design | 3D Modelling & Animation
I HATE MY JOB !!!!
Project Office (Unreal 5) - A game where you take a spring powered boxing glove across the office rooftops and PUNCH your BOSS in the FACE because he deserves it and this job sucks!
This game was a 4-week class project by a team of 3. My main roles in this project were level design, character design, and 3D modelling (character and some environment) and animation.
Keep reading to see my full writeup of contributions to this game.
Map Sketch (Partial)
After a lot of brainstorming, we settled on the idea of the player using a boxing glove to hit enemies off of roofs, and they try to hit the player back. Importantly, we didn't want to make the game a platformer, so the player is not able to jump. The player is also not able to control the camera.
In order to make the full map sketches, we split up the level into 3 sections: 1) the introduction inside the beginning of the office, 2) the tutorial section, where the player learned mechanics, and 3) the rest of the level, where mechanics were layered, leading up to the boss room. We then each separately came up with our own section 1, 2, and 3 sketches.
Below are my sections 2 and the ending of section 3, which were largely preserved in the final game. The blue triangles with a purple arrow point in the general direction the camera would face.
Final Map
Afterwards, we combined our ideas, moving rooms from each of our sketches to create an order that made sense for learning new mechanics, or combining elements from multiple sketches.
I then redrew our map to the correct scale, using the metrics from the metric gym one of my teammates made, and clarified the different levels of elevation that the player was moving up and down between.
Level Design Document (Partial)
While laying out the map shown above, I also translated all of our designs into a verbal walkthrough in the Level Design Document. Below is a portion of the walkthrough for Section 2 which aligns with the part of the level I showed in the first Map Sketch screenshot.
The Level Design Document also included key game information, such as genre, mechanics, and metrics.
Character Models
All three characters were designed, modelled (using Blender), and textured very simply by me. The final Boss is a recolor of the playable character. I also animated the playable character's walk, but some extra bounce was added in engine by my teammates.
I also modelled some of the more complex geometry in the environment, and the cubicles in the opening section. (The large buildings were edited from a free asset pack.)
A card game and visual novel about magic and love.
Ludyrin's Mystics Academy (Unity) - A card game and visual novel about a team of boys in a magic school, where your deck is flipped over and combat cards become your conversation tools with your teammates. A 2-month game jam.
Keep reading to see a few images from development, including a systems chart, prototype screenshots, and documentation excerpts.
Systems Chart
This is the preliminary systems design chart that I plotted in Google Drawings to track how systems interacted, and data would be shared and stored between those systems. This outline was used to inform the structure of the initial Unity prototype.
The colored boxes represented different design aspects that we knew we wanted to include (from our paper playtest on Tabletop Simulator). The longer notes on the sides had additional technical notes for how these would be implemented into Unity.
Early Prototype
The two images show the Combat and Conversation screens. The cards used in Combat would determine what actions were available to you in Conversation.
Inspecting a card would allow you to view its other side.
Documentation
While creating the prototype, I also kept in mind how to best facilitate the game designer and narrative designer. Though the game jam was short, I created a few methods for which they could add or modify content easily without having to go through me.
For example, I wanted the designers to be able to add cards with a minimal amount of coding. Below are some excerpts of my documentation explaining how to use the Scriptable Objects I had set up.
Mocha Magic - Art | Production | Programming | Prototype Design
Create the perfect drink and make friends along the way.
Mocha Magic (Unity) - A drink-making visual novel in which the owner of a new cafe discovers that the real “perfect drink”—was the friends we made along the way.
Mocha Magic is my team’s senior capstone project for the UCSC: Games and Playable Media major (full credits on itch.io). The game was developed over the course of a school year; pre-production began in October 2020, production began in January 2021, and the game released in June 2021. Our entire development cycle took place remotely through the COVID-19 lockdown. I was the Art Director, and also helped with programming.
Mocha Magic was one of the winners for the UCSC Games Showcase Sammy Awards in the Visual Art category.
My main roles in this project were art direction (including production, concept art, and 2D character asset creation), character design, programming, and prototype design (including a playable prototype Unity build).
Keep reading to see my full writeup of contributions to this game.
As Art Director, my main responsibilities were to manage and delegate tasks to other members, coordinate with other departments, and create art assets myself. In addition, because I had programming experience, I also helped code the prototype/proof-of-concept, and implemented assets and a few features in Unity.
Prototype Design
We started out with paper prototyping; due to everything being remote throughout the 2020-2021 school year, our prototype was done over Tabletop Simulator, using various tokens and normal playing cards.
Our original concept contained the same core as the final game, but was about witches and potions instead of a cafe and drinks. The main difference was that the player had to gather resources for potions, which would depend on the phases of the moon. Potions could then be crafted to give to NPCs, which would advance their narrative depending on what potions they liked.
This paper prototype was then used to inform the Unity proof-of-concept prototype. Though I was mainly an artist, I was also the only person not on the programming team who was proficient at coding. Since our only programmer at the time was busy with classes, I was responsible for creating the Unity proof-of-concept/prototype.
None of this code is used in our final game, as I made it quickly and knowing it would be thrown out, and several features were added or removed. However, this prototype let us determine what was technically possible/in-scope, and helped us picture our final game.
The prototype took about 2 weeks to complete. After finishing this prototype, I sent out the project to the programmers and included some quick documentation explaining the various scripts’ structures and functions.
Below is some footage of the prototype, demonstrating ingredient gathering, potion making, and potion delivering. The moon phase, illustrated with cute cats, is visible in the top left of the second clip below.
(Note: the framerate on this gif was lowered to reduce flashing. I can only upload one video, so this second one is a gif)
Programming - Dynamic Drink Display
In addition to the prototype, I also helped implement assets and code various UI sections. As an example, in our final game, our drink sprites are displayed with procedurally. Since I had the concept for this system, I initially coded it and then assisted the programming team with its final touches.
Our drinks have 1 “base” tag and 1 or 2 “ingredient” tags. After learning from the programmers that this information was passed around as a string, I created a script that would display different combinations of sprites depending on these tags. This way, we didn’t have to draw dozens of different drink sprites for each recipe to feel different.
Below is a gif of a video I sent the team showing the successful implementation of the proof-of-concept.
Art & Production
Each week, I planned and facilitated the art department meeting, where all of the artists gave feedback to each other, and I assigned them their tasks for the following week. When our build was playable, I also started each meeting going through the content that had been added or changed, so everyone was up to date on how our game played and looked. Between meetings, I checked in with artists individually to check on their progress, workload, and mental health. I also gave feedback and paintovers when needed or requested.
Most of my task tracking work was done through spreadsheets, rather than a program such as Jira. Though our team experimented with various options during pre-production, such as ClickUp, team members struggled with keeping their own task progress updated. I decided working with what was familiar would be best for such a tight timeline, and moved the art department’s tasks to a spreadsheet that I kept updated through frequent checkins.
2 weeks’ worth of tasks on our task tracking spreadsheet. Names other than mine have been blocked out for privacy.
In addition to production, I designed and made the assets for 3 characters, including the playable character Machi. The three characters below are Machi, Katiya (the "rival"), and Parvana (the "tired scientist").
Machi is the only character with a full walk animation, due to time constraints.
In addition to character assets, I also worked on UI layouts and assets. I also designed the logo for both the game and our team's studio logo.
A magical girl tabletop game about saving the world, magic, hope, and hopelessness.
Kindled Souls (魔法焼女 Mahou Shoujo) is a tabletop RPG dice-based system about magical girls who find themselves. Inspired by the tone of Puella Magi Madoka Magica, sacrifices, losses, and possibly deaths, are to be expected. This system is intended for longer oneshots, around 4-6 hours (including character creation).
(Players: 3-6 + 1 GM)
Featuring:
Light and Magic
Pairs of teammates are Bonded, becoming each other's greatest strength, and also their weakness
90's-magazine-style quiz as part of the character sheet
A cute team familiar/mascot
Kindled Souls is a TTRPG system I solo designed for a class. Keep reading to read some sections of my post-mortem for this game.
(This is an edited-down excerpt of my post-mortem assignment.)
My aesthetic goals for this game were to have a game somewhere in the middle of the serious-silly spectrum and to have an interesting combat system for a longer oneshot game. I wanted to make something fun, yet also tragic, with moments of both lightheartedness and brutality, and with a focus on cooperation and character relationships. I also wanted to create an interesting and relatively "crunchy" combat system, because numbers and stats are fun.
For character relationships and teamwork, RPG's usually have some degree of teamwork within a party by nature, but I wanted to go beyond that. While the game had an assist system, I remembered that in Lasers & Feelings, the action of helping each other was quickly forgotten.
So, I created the Bond system to force players to hopefully care about, at minimum, one other character, by increasing both rewards and consequences. Perhaps players might forget to help the rest of their team, but they should remember to save and protect their Bond. In terms of combat, I liked the risk-reward of using the resource used for health as a way to empower and use magic, and I hope it leads to some interesting decision-making.
I also liked the personality quiz I came up with for character creation. Despite obvious issues with how many times people get ties, I enjoyed the process of creating it and I think it fits well with the game; its existence has a nice "old magazine personality quiz" feeling. It was an idea I sort of came up with on a whim after seeing some things online, but players and I really liked it.
I think the main thing I would change, if I could do this project again, would be to playtest more. The strike [which cancelled classes] and the [beginning of the COVID-19 lockdown] made it much more difficult to try to get playtest data. I only got one good playtest, and that was sometime around the first prototype turnin.
