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.
Download the game on itch.io
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.
The game consists of two main sections, drink-making and dialogue. Each day, the player speaks to one of the customers in their shop, and chats with them. Dialogue changes slightly depending on how well the customer’s order was followed.
At the end of 2 weeks, the player selects their “perfect drink,” and all of the memories attached to it will determine the ending CG they receive. There are a total of 6 customers, and 7 endings: 1 for each customer, and 1 for the playable character themselves.
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 a few features and UI sections in Unity.
Art & Production
At the start of pre-production, after I was appointed as Art Director, I sent a questionnaire to the all of the artists, where I asked about their desired tasks, working habits, other classes’ workload, how they would like to receive feedback, and more. Throughout the project, I referred back to this questionnaire as necessary.
During pre-production, to make sure our game was at a reasonable scope, I wrote out every artist’s assigned workload for each week, taking dependencies into account (e.g. assigning the concept art before assigning the asset itself). I also left a 2-week buffer period at the end of production, to compensate for any delays or to allow for us to hit some stretch goals. I am very proud that my department was able to avoid crunch, and during the final week, the artists were able to focus on polish and other classes.
In the end, each artist was able to at least create a character’s concept and visual novel sprites. Other sprites such as drink ingredients, backgrounds, and UI were assigned based on interest and workload.
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, I decided working with what was familiar to me would be best for such a tight timeline. I began the spreadsheet by populating it with the assignments I came up with above, and I adjusted the assignment and timing of various tasks as the situation demanded.
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.
I helped develop the art style and created style guides for various parts of the game. I also regularly sought outside feedback from instructors, TAs, and peers for both our art assets and our overall game and narrative.
In total, I designed 3 characters: our playable character Machi, a rival cafe owner Katiya, and a lepidopterist Parvana.
The process for designing Machi was different than for our NPCs. Unlike our other characters, which were artist-led and came from an archetype or prompt, Machi’s appearance was described in detail by one of our writers. I took this document and sketched out a design for Machi, which he approved.
Originally, our game was about witches and potions, rather than a cafe owner, so naturally Machi was redesigned after the setting of our game changed. Machi also changed from a cat-person native to the city to a human outsider.
I also created Machi’s main in-game assets. While they didn’t have a full size VN sprite, they did have a portrait on the left side of the dialogue box that changed expressions.
I also made and partially implemented their walk cycle, which has 4 facing directions on an isometric axis. I later based the other characters’ oveworld sprites on this base, however Machi is the only character with a full walk animation, due to time constraints.
The first NPC I designed was Katiya, our “rival tsundere” archetype. Katiya became the template for other NPCs’ ingame assets, so she went through the most design iterations, and was referenced frequently throughout the production of our other characters. As a “classy” and “uptight” character, her design has a near-monochrome palette, with red and gold highlights.
The other character I designed was Parvana, a near opposite in both personality and design. For Parvana, I was more inspired by her visual design, as I wanted a lepidopterist wearing something pastel with butterflies. Her eccentric personality came later, from the narrative team.
As mentioned earlier, each artist worked on at least one NPC’s design and VN expression sheets. With one exception, they also worked on that NPC’s ending CG.
In addition to character assets, I also worked on UI layouts and assets, including our game’s logo. This UI work also includes our procedural drink sprites, which is explained in the later Programming section.
Though I was mainly an artist, I was also the only person not on the programming team who was proficient at coding. This meant that I was able to implement assets with scripts, and help out when needed.
During pre-production, our (at the time) only coder was busy with harder engineering classes, so 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. Below are gifs of various features, filmed as they were created. (Uploading gifs is free, unlike uploading videos, sorry!)
After finishing this prototype, I sent out the project to the programmers and included some quick documentation explaining the various scripts’ structures and functions.
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.
As development was finishing up, and art was done, I shifted back to assist programming. One of the final things we had to implement was the screen where the player selected which drink they wanted as their “perfect” drink, which would decide what ending it triggered. The progression functionality was already implemented, so I helped with the UI and text display. I also fixed miscellaneous bugs.