The game concept

One of the first questions we were presented with in the development of Under Maintenance was: What kind of game did we want it to be? The otome genre features a lot of titles built on drama, angst, and the darker sides of the human condition where it pertains to romance; as the team are fans of this type of material, it would have been a natural direction for us to take with our game. But, perhaps as a product of the time in which we started discussing the project – after two years of a global pandemic and in the early months of the invasion of Ukraine – the team agreed that we would try to do something a little bit different with our effort. We wanted to do something real and relatable, but we wanted it to be light. A comfort game in a true sense of the word. That’s how the team settled on the idea of “let’s do a rom-com/dramedy.” And so it began. 

In working out the concept details, we started at a place we were all very familiar with – otome games. Or one otome game in particular. The team bonded and became friends over the otome gacha game Mr. Love: Queen’s Choice for years before the development of Under Maintenance began, and over the course of those years there became things about the game that became part of our collective consciousness. The dreaded update maintenance was one of those things.  So when we were kicking around ideas for a game concept that could tie back to this shared love of ours, we started joking around “What if the MC played a game like MLQC and then one day it goes down for extended maintenance so she has to go out and get a real date.” And it turned out it wasn’t a joke, it was the foundation of our game, and one we felt could resonate not just with players who played the same game we did but players of all stripes of mobile games could relate to this problem of having their favorite game go down for maintenance. 

This overarching concept never really changed from the initial conception, but the details of how MC decides to get a date and what happens after has undergone some revision over the course of development. Originally, the dating app wasn’t so much of a traditional dating app as it was a social media game based on “Two Truths and a Lie” (though the characters playing the game itself survived into some of the routes). This didn’t really leave a natural avenue for the characters to meet, so eventually it moved towards a more standard dating app experience, and that also opened up the concept more to the general condition of life and dating in your 30’s – though as the writing team consists of women all in long-term relationships of many years, hilarity ensued as they tried to figure out what people put in their profiles these days, and how people communicate through these types of apps, having no personal experience themselves. 

On the flip side of that, the bar route – the path where MC ditches the dating app in favor of going directly to a bar to try and meet someone the old-fashioned way – was pitched as a way to create an “illusion of choice” for the player, the idea that you’re picking the option that anything could happen since you’re not presented with the love interests ahead of time, but the reality is it’s just a slight different version of events leading to the same choice of bachelors. One lesson we learned from the initial release is that we found we did not make it clear enough during the bar route that the drink choice at the end of it is the love interest selection and subsequent versions of the game have additional dialogue added to hopefully make this choice more transparent. 

The other biggest change over the course of development is the level of thirst implied in MC’s quest to find a date and how that plays out in the routes. In earlier iterations of the concept we intended it to be more explicit that MC is looking for a low-stakes hookup from the dating app/bar and our initial storyboards included a hookup between MC and every LI almost immediately. We drifted away from this for a couple of reasons – for example, in Tristan’s route it was originally planned for MC and Tristan’s night at the bar to end in a very drunken attempt at a hookup, but this was scrapped when we realized we didn’t want to force the player to have to drink alcohol/be drunk – and in this vein ultimately all of the reasons boiled down to an attempt to make the game as accessible to as wide of an audience as possible. Our MC retained her sex-positive attitude, but we scaled back some of the more explicit aspects of earlier plans. These revisions had some unintended consequences, however. One of the rare pieces of criticism we received from our initial release of the game was that some players were uncomfortable with aspects of MC’s actions towards Theo in the section of his route that was originally contextualized as their initial hookup. This scene has been edited in subsequent versions of the game. 

Character Concepts

In the beginning, we asked anyone in our otome social group with an interest in working on the project to submit a character concept. We ended up with five. Knowing workload would be have to be balanced carefully with such a tight timeframe for development, we decided we would only proceed with three. One of the five initial character concepts was withdrawn by the creator when they decided not to continue with the project, and from the remaining four emerged Luca and Theo, with the other two characters remixed into Tristan. Mark would not join the cast until a bit later in development, along with Mr. Steal Your Girl, who was also a development-inspired addition. 

As we were sketching out the details of these characters, it was important to us that they skewed a little bit older than your average otome love interest (the vast majority, anyway). As a team of women in our 30’s, we’ve all bemoaned the over-representation of love interests aged 18-24 in the mainstream genre and the basic absence of characters over 30. Luca, the baby of the cast at 28, would be considered an old man in a mass market otome title. 

Main Character (MC)

We wanted our MC to be someone we ourselves could relate to. Snarky but sweet by nature, she’s not shy about her wants and needs, even if it can come across as (or actually *be*) a bit problematic and red-flaggy at times. She’s not an angel or a damsel in distress – she’s a little angry, a little annoying, but full of genuine, fun-loving heart.

As the writers have all had some type of experience in retail and/or customer service work, we concluded that MC would be in a retail management position, something we all had experiences to draw from. She went through varying stages of development - her personality was mostly set by how we wanted her to be a bit less “happy-go-lucky” and a bit more “burned-out”, something that we hadn’t really experienced in our otome journies.

We had numerous discussions regarding self-inserting during development and considered MC not having her own sprite / fixed appearance during gameplay, but after seeing the incredible design from our artist we couldn’t not put her in the game. In order to *enhance* self-inserting and increase representation for players, we hatched the idea of having her hair and skin tone be customizable. 

Luca

A pretty boy with serious insecurities lying just beneath the surface, Luca’s initial concept called for him to be a more pronounced playboy who would go on to find true love with MC. But during the development process, Luca’s writer drew from her own life experiences to imbue the handsome bartender with the anxiety one can only have as a child with an overbearing parent who means well and refined him into the handsome, smooth, yet somehow totally clueless Luca that exists in the game today. The one with a severe fear of the future and of taking a big leap of faith. The swan who still thinks of himself as an ugly little duckling. 

Besides dealing with the concepts of pursuing a career in the arts when you’re not sure it will pay the bills, Luca’s route focuses on the idea of an MC breaking the mold of traditionally agreeably otome heroines by presenting an intelligent woman who’s a little jaded and a bit of a tsundere herself.  

Tristan

Manic Pixie Dream Man. Space Cadet. T-Baby (even though he’s the oldest in the cast). Tristan went by a lot of names during development, but he got his start as a combination of two characters that were sketched out during the initial planning – Alan, a dark, handsome, yandere-flavored, divorced academic and Proto-Tristan, a fair-haired, neurotic mystery-box man with too many hobbies and no particular direction in life. The Tristan you see in the game took a pinch from them both – he retained Alan’s (lack of) marital status, inherited his complexion, glasses, and beauty mark, and from Proto-Tristan took his name, a pile of hobbies and a love of games, and general casual demeanour and unfocused world view.

Tristan’s route was designed to be a derivative of the traditional otome setup that the player’s actions decide the ultimate behavior of the love interest. Regardless of how the player treats him, Tristan’s personality remains fairly consistent throughout the narrative, with the endings being more a reflection of the player's behavior towards Tristan than anything he says/does.

Theo

Theo was first created as a reactionary character. At the planning stage, we had another writer on board planning up the ultimate bad-boy - always on the edge, promiscuous and committing credit card fraud. Theo seemed like the ultimate balance to it - down to earth, cautious towards intimacy and bad with technology. His emphasis on family was soon added as reactionary to other otome games, where there either exists very unhealthy family dynamics or parents/siblings are killed off or disowned for dramatic effect.

From that his main themes arose as the importance of communicated consent and voluntary simplicity.

Mark

In the early stages of planning the routes for the three main love interests, a member of the team made a request to the writer of Tristan’s route for a reference to Tristan and Isolde. As a result, a snarky heckler named Mark was born to bother Tristan at the bar. As development continued, his role expanded to a side character that filled the role of obnoxious foil to the main characters in various capacities, but it didn’t take very long before the team – and Mark’s writer, in particular – were swept up in the idea of the “hot undateable” and leading to us expanding his role to various endings in the initial release, and later developing his own standalone route after the initial release of the game.

Mark's route develops from his interactions with the MC and the love interested from the base game and digging into the origins of his dim world-view and boisterous persona and exploring his inner angst - both figuratively and literally.

Mr. Steal Your Girl

As several of the members of the development team are servants to a variety of spoiled felines, it seemed very natural to add a fluffy cat to our game, and Mr. Steal Your Girl actually appears in the most endings out of any character. His meowing and purring sound effects are by far some of the biggest fan favorites in the game.

Side Characters

Bestie - The MC’s best friend. Originally, they were going to have a default name or have the character labeled “Bestie,” but to give the game a bit more of a personal touch, we decided to make Bestie name-able and without specified gender. They serve as the player's best friend that MC texts about her journey of love. While playing the voice of reason and being number one supporter of MC’s choices, Bestie also serves a function for the gameplay, as the player will receive different texts depending on their choices up to that point in the story. 

Writing

Planning

We started with a shared Google Doc to jot down ideas, but as visual learners we soon realized it didn't give an easy-to-see overview. So for high-level script planning we discovered a web-app called Milanote that had some nice templates for storyboarding and collaboration options. We mapped out the approximate chapters we would like to have for each character, what choices we would like to have in them and how they fit together. This landed us on five chapters for each character. It was at this stage we conceptualized the main character texting their best friend in-between chapters as an alternative to having a visual indicator of whether choices were “positive” or “negative”-- instead, the bestie texts created a break between chapters and also gives the player an indication of whether their choices are leading in a positive or negative direction. 

Draft

The draft writing process was split between four of us, with KitsunePlush heading Luca’s route, Bryth*Writes taking on Tristan’s, and Eishelin and Tsukasa Yuki working on Theo’s, with the prologue being a joint effort. After some deliberation about the writing medium to choose, we settled on Twine, since it offered an option to “play” the game with all the menus and an option to export the scripts to Ren’Py later on.

Since Twine doesn’t have a co-working feature, we were sending the files back and forth via Google Drive and versioning them ourselves.

The drafts were already written Ren’Py style with specifying some of the character impressions. A note here is that some of the default Twine formats (Harlowe and Chapbook) don’t play well with things containing underscores, so we quickly migrated to Snowman instead.

Edits

As the draft process came to an end, Eishelin started importing all of the scripts to Ren’Py via Twine to Renpy to see how they looked and played. While we had standardized a writing system beforehand, there were still some issues with that.

As this was our first VN development, we soon realized that there were some issues with our writing styles that all stemmed from all of us only having written long-form fiction before, namely:

• Too wordy descriptions and exposition;
• Lots of monologues that did not transform well to the visual novel format;
• Pacing issues;
• Tense consistency issues.

The normalized scripts were back ported to Twine (there’s no nifty process for that, you have to do it by hand) and we did our second round of edits there as well.

After that we were very strapped for time and moved all of the editing only to Ren’Py to be able to play through it instantly and see how it felt and read.

The main issue with this writing/editing approach is definitely a lack of a consistent spell-checker and the lack of the ability to comment things. If you have a larger writing team, are familiar with the visual novel writing style, and can figure out how to organize everything, something like using shared Google Docs files might be a better approach.

Art

Inspiration/planning

Each of the guys had a rough appearance card, describing how their writers imagined the characters to look.

Some members of the team also did some rough sketches and we made some mock-up figures in RPG Maker, before...

An artist joins the team

The true designs were born when our amazing artist centibel joined the team. She took our concept designs and truly made them her own, giving the LIs the looks you know and love today.

The biggest discussions we had were over MC's design - what sort of a hairstyle and more importantly - what outfit colors she should have, taking into consideration they would need to compliment a variety of skin tones and hair colors.

Voice Acting

English voice acting is something our team really enjoys in the games we play, so we knew it was something we wanted for our own game. Due to time (jam scope) and budget (basically zero) constraints, we asked for volunteers and settled for doing partial voice acting to limit the amount of time the cast had to devote to the project - each character had approximately 15% of their lines voiced in the first version (30% in the 2.0 one) and has around 10 additional expressions (laugh, cough, single word, etc.) scattered through and repeated.

Auditions

We posted our audition document early and held the audition open for a month, advertising on a lot on different mediums, including Casting Call Club’s and Voice Actor Club’s Discord. We also made sure to post the casting call to our twitter account.  It definitely helped that our VA Director is a voice artist herself. In the end, we received a startling number of auditions, over 20 per main character, and we are extremely grateful to everyone who auditioned.

One of the things we noticed during the audition process is that while many people auditioned for all four of the characters, one character received quite a few more and one character received quite a few less. In discussing the reasons to explain this, we concluded that the reason was likely to be that the audition lines for the character who received the most auditions were fairly simple and neutral in subject material, while the character who received less auditions had one line that mentioned a sexual topic that, while directed to be delivered in a non-suggestive way, may still have discouraged some interested parties from auditioning for that character. If you're looking at making a voiced game, this is something you might want to consider in laying out your audition guidelines. 

Evaluation

Once the casting call had passed the deadline, the team set up a listening session over discord to listen to all of the submissions. We narrowed down each character to a short list of three choices of voice actors and reached out to the first choice of each. We were grateful that all of our first choices accepted our offer. Prior to the beginning of the record, we did ask them to sign a generic NDA/working agreement to outline the scope of the project. For one particular character, it came down to the 11th hour before the writer decided on a voice, and it was an audition that came into the inbox at the very end of the deadline. 

Scripts

There was a lot of anxiety when it came to script writing, because we weren’t sure what we needed outside of the lines the actors would say. When we agreed upon self-directed sessions, we had to ensure the context of the lines were clear and since the director only had a hand in developing one character (most of the time, directors are brought in separately or the project lead who had a hand in all characters would direct it), we needed details to be written out. We eventually found a template to use for the script and the director came up with a guideline on how best to write context. Those resources are linked below. 

• https://katy133.itch.io/last-meal-at-cafe-mori/devlog/204065/behind-the-scenes-of-last-meal-at-cafe-mori
• https://docs.google.com/document/d/1b_VFKzAl2QCWsvcY3gYGbXf5EvFYShNmPD8HYnZV2es/edit

Recording

There are two ways one can go about with the recording process. The first option is a live directed session and the second one is having the actors record on their own time with a guideline of how many number of takes needed to be recorded, and in what format we wanted them to submit the recording. When the script was ready, we offered both options and all four VAs were gracious enough to leave the live directed sessions on the table but chose to record themselves for the first 2 chapters. Towards the end, we were able to find time for a live session for some VAs that were conducted through Discord. 

Editing and programming

For the first version of the game, we chose to use voice tags exclusively due to expression use and the fact that we were still editing our script heavily while the voice files were being processed, which would have required a lot of file renaming for the auto-voicing feature.

However, for the 2.0 version of Under Maintenance, we had the script finalized before sending it out to the VAs, so we were able to utilize Ren'Py's auto-voicing feature, which made the process of adding voice lines much more streamlined. 

Lessons learned

All of the recording was done during the editing process. Ideally, this is something you want to avoid and have a finalised script ready before starting the recording.

Another issue was selecting which lines we'd like to have voiced. Each writer was given a certain number of lines we had the time to have voiced, so there are some inconsistencies with some chapters having voiced scenes, while others have voiced lines scattered through them.

We also ended up editing some lines because our voice artists or VA director thought they sounded unnatural when spoken.

Programming/GUI

Engine choice

We looked at several engine choices - Ren’Py, Naninovel plugin for Unity, Visual Novel Maker. Licensing and pricing options made us reject Naninovel, bad reviews brought us away from Visual Novel Maker. A plus for Ren’Py was that everyone on the writing team tried it out beforehand and found it easy enough to use even if they did not have previous programming knowledge. Our programmer had encountered Ren'Py before and knows Python, so that was another plus. 

Component overview

For most part we utilised Ren'Py's inbuilt functions and screens with relevant GUI changes. The biggest hurdle with GUI configuration was definitely the custom say boxes and name tags for each character in both dark and light modes and matching up the quick-menu buttons with their colours.

Some custom screens we were required to make - everything phone-based (the name inputs, character customization, dating app, Heavenly Love, texting) and the extras (ending list - utilising Ren'Py's gallery function, gallery (with persistent MC configuration options), credit and attribution screens). 

One thing we're not entirely happy about is the mismatch in our GUI between the say screen and everything else. The say screen was made early on, while the rest of the GUI was made after finalising the main menu art. In hindsight, we would have done much better with a dedicated GUI artist on-board, instead of having our programmer wing it.

Images

We used layered images for all of the sprites for two main reasons - build size and ease of mix-and-matching. There were several instances where we went “hey, these eyebrows and this mouth would make a fun new expression, let's add that in” and that could be done without touching the sprite images themselves. Also this made the configurable skin tones and hair colors of the main character possible - she's made up of around 100 possible layers and if we needed to import all of them as separate files, we'd be looking at thousands of sprites for MC alone.

To keep the build size down, we converted most of the images to .webp format (lossless for the sprites, 95% lossy for the CGs) to reduce their size, while retaining quality. This reduced the build size by around 40% for sprites, backgrounds, CGs, emojis and splashscreens. 

Preferences

Pretty much all of the extra preferences we included in the game were due to issues we encountered with readability while editing.

Several font sizes were requested by a team member who found the default font size quite difficult to read.

We initially had the textbox only in light mode to fit the overall aesthetic, but some teammates have an unhealthy attachment to dark mode, so we also implemented a dark textbox option quite early on. Same with textbox transparency - we initially had it saved as a transparent picture for aesthetic reasons, but found that impaired the readability for some of the teammates. Thanks to Renpy Accessibility Add-on for the idea on the implementation of the transparency.

Toggling the main character sprite on and off was a last-minute addition thanks to our friends on Otome Development Discord mentioning it being done a lot in Japanese indie games to help self-insert players. While we were reluctant about it at first due to wanting to showcase MC's art as much as possible, we're glad that we included this option - we have received positive reviews about that.

The dating app

Our initial plan for the dating app was swiping or pressing a button in-app to match with a guy, but the issue here was not giving the player the chance to review all the profiles first. So we settled on simple ADV-mode style buttons instead.

While we had the dating app profiles as pictures initially, we transformed them to text-based in-game script. The reason for this was threefold - being self-voicing compatible without needing to write alt-texts, to make it easier to fix any issues we find and to facilitate translations, if we decide to have those down the line.

The phone/texting system

We looked at different options provided by the Ren’Py community, especially the phone systems by Nighten and Nadia, but found that none of them matched our needs exactly - main issue being, compatibility with ADV mode (so that we can have ADV conversations happening in the background) and a text message log. 

So we decided to roll our own - we wrote a nifty Python function that handles putting messages in an array, showing typing animations and sounds, and refreshing screens. It took some fiddling around to get self-voicing to work properly with the screen refresh approach.

A minor thing that was changed between version was the background of phone messages - we had initially assigned each character a phone message background, but after some review we decided to switch it to a border instead for a better text contrast.

The Android build

Our initial plan for an Android build was to release it sometime in the future with a completely new, highly mobile friendly GUI. However the timeline shifted due to an unforeseen circumstance - an unauthorised Android port of the game appeared on a downloading site within days of our initial release  (this happened to all Otome Jam participants who hadn’t included an Android build in their release or soon after, and more than likely happens to all free Ren’Py games out there). So in the first week after the release, we both researched how to write a DMCA notice and started work on adjusting the GUI for usage on phones. In the end, that involved mostly tweaking the accessibility features to permit different font sizes on touch screens, drawing and coding a bigger textbox and remaking all of the quickmenu icons to bigger ones.

This, however, turned to be a blessing in disguise - as of writing this, more than 15% of itch.io downloads have come from the Android build, so it's definitely something to consider when making a game. Since the Android build is visually a bit different from the PC one, we have also seen screenshots from it pop up in reviews and socials.

Things we would have liked more of

Background animations. There’s currently one animated scene and that’s when rain starts falling in Theo’s route. We’d definitely like to explore more of that in future games, but didn’t feel like it would fit the theme of the game in any of the other scenes.

Ren'Py not supporting animated files (like .apng) really puts a wrench in these plans, because animations have to be done via ATL or videos.

We also would have liked to have done a chapter replay system for players who have gotten the good ending for a character.

Sound design

After the majority of the writing was done and editing was underway, we turned our attention to the sound of the game. No one on our team is a composer and at the stage of the project we began to consider the sound, there was no longer time to try and find one to join the team, so Bryth*Writes, at least having some experience playing an instrument, took charge of the arrangement of the soundtrack. 

Finding music that is truly royalty-free and can be used without substantial licensing fees is challenging. Many sites that offer royalty-free music for a small fee have licences that do not cover video games/ programs for distribution whether they are commercial or not. After reviewing many websites, most of the music for the game was sourced from chosic.com and all of the sound effects were sourced from freesound.org, which both offer a library of music/sound effects licensed under Public Domain / Creative Commons. 

This did limit the choices for background music, but we still feel the “soundtrack” of Under Maintenance offers a good variety. Each of the love interests has two tracks specific to their routes, one uptempo and one slower, and one flex track and may or may not appear in other routes throughout the game. 

All of the sound/music files were converted to .ogg. One of the other challenges we faced in the sound design of the game was how to normalize the volume levels of sounds across various devices – during testing, we would find that one member of the dev team found the sound oppressively loud, while another thought it was too quiet, and another thought it was fine. While the sound levels of the finished game are okay,  this is an area of improvement for us in future development projects. 

Marketing

As we were new to the indie game space, we weren’t sure where and who to market to, or how. So we started by researching other similar titles in the genre. We also found these resources helpful to reference as a starting point: 

• https://arimiadev.com/how-to-market-visual-novels/
• https://arimiadev.com/social-media-marketing-for-indie-games-2021-guide/

We joined the #DevTalk server on Discord to get some insight of how other people were marketing their games. We decided that Twitter was still the most used social media site to market indie games (aside from TikTok, which none of the devs were prepared to join and learn) and proceeded to find, and follow fellow indie otome devs (most were also participating in the 2022 OtomeJam).

Most of the dev team also joined other otome-related servers that allowed promotion of their own work, such as “Otomepeach” “Blerdyotome” and the “BloomingPanic” fan server that had a dedicated #otomeJam channel. We were regularly interacting with our fellow indie devs there, as well. 

Every day was a “marketing brainstorm” day on our private Discord server’s “marketing” channel. Since this is new to all of us and we all use social media very differently, there were a lot of discussions on how to properly promote the game, how frequently our game account should post, and how much information should we post without giving too much away. 

What brought us a lot of joy was the level of engagement with other indie otome devs. Whether it was talking about their work, their process, retweeting their progress, commiserating on the creeping deadline, and generally the positive relationships we cultivated that resulted in 500 followers in less than 3 months. Some of those relationships continue today. 

When we dropped our game one day earlier  than the deadline (June 29th, 2022) our hard work in marketing paid off. We saw 431 views on our itch.io page and 131 downloads on that first day. And on the actual day that OtomeJam ended (June 30th, 2022), it jumped to 819 views and 259 downloads. Over the course of the following months, this has grown to more than 36 thousand views and 11 thousand downloads on itch.io alone.

A couple of days prior to launch, when the itch.io page was live, we reached out to BlerdyOtome (@BlerdyOtome on twitter) who is known for her otome playthrus on her Twitch channel and to the VNgameden, who covers indie games pretty extensively to review our game. Blerdy replied and agreed to feature us in her OtomeJam stream where she did played thru a couple of different entries (and then decided that she would feature our game exclusively on “Thirsty Thursdays” where she would complete all three routes). We were also fortunate to have @PeachTheOtome and @otomeaddicted (both traditionally only review commercial otomes) add us to their #OtomeJam playthrus.

Final thoughts on teamwork, communication and leveling expectations

Although the members of the dev team are friends and this bond was to our advantage, the development cycle of Under Maintenance did not come without its challenges for us on an interpersonal level. Here are some of the lessons we learned as a group over the course of our journey:

- Agreeing on a timeline of work and being very strict with deadlines is important, and something that we had to learn and are still learning the hard way. Project management is important and having a clear division of responsibilities and ongoing check ins to discuss progress and obstacles is key. Establishing milestones and meeting them means everyone is on the same page.

- Life happens and things can get lost in the shuffle, particularly in a medium where a team may be doing the majority of their collaboration through text, so it is necessary to be honest about you are in your process and to advocate for your needs to ensure your teammates can support you.

- Be prepared to wear multiple hats in a small development team, even if you don't necessarily love all of them. The fewer people you have on your team, the more likely it is you'll have to roll up your sleeves and learn how to do something new.

- You can have differences of an opinion as a team and it will be okay if you treat each other with respect in the process of finding a compromise.

-  Drink water and get a healthy amount of sleep!

- If we could do it, you, (yes, YOU) can do it, too. And if you decide to embark on your own otome jam or other game development journey, take time to enjoy the process. It really is a special experience and one we would not trade for anything.