I made a game
As someone with no significant programming or game design experience going into this, I learned a shit-ton. Afterward, I also got questions about making my first game from friends and fans.
So it’s my pleasure to dissect my baby (just a little bit), and share some stories and peeks-behind-the-curtain about the whole process - from inspiration, to execution, to a mysterious third thing.
Fortunately (or unfortunately, depending on your inclination), this piece contains no spoilers for PARTS OF THE ELEPHANT.
Let’s start.
Inspiration
One Friday night a few winters ago, I was spiraling in my living room, feeling both restless and paralyzed, and craving something new but comforting - something to yank me out of that spiral.
As I often did when in that state, I browsed digital game storefronts, hoping to come across Exactly What I Need Right Now.
Instead, I found a weird little game called MILK INSIDE A BAG OF MILK INSIDE A BAG OF MILK… (initially released as ПОМОГИ МНЕ КУПИТЬ МОЛОКО!, i.e. “Help me buy milk!”).
MILK is a short-but-memorable visual novel about a girl struggling to buy milk. She imagines the medications she’s taking to be the player controlling her in a visual novel, and the gameplay consists of you participating in her self-talk - either putting her down, or encouraging her - as you find out more about her. For its brevity, it’s very thoughtful and well-written.
And that winter night, one particular thought crystallized from the syrup of my malaise that had coated the experience:
“I could do that.”
Not because I thought MILK was bad, but because the component parts felt doable.
MILK contains no mechanics more complex than clicking a button or typing the word “Yes”. The whole game includes fewer than a dozen background images, all of which have exactly 3 colors in them. I finished the game in about 15 minutes.
And I paid money to buy it on the Nintendo Switch store, and enjoyed it.
If the developer of MILK could put themselves out there like that, then I could too.
So, this became my primary goal: To see if I could make a game of similar scale to MILK.
The next day, I downloaded the free game engine that was used by MILK (and also DOKI DOKI LITERATURE CLUB, another excellent solo dev project) - Ren’Py - and started figuring out how I was going to approach this.
But, technically, I was jumping the gun a bit already by picking an engine so early. I could’ve researched other options, like Twine or GameMaker or Godot (specifically with the Dialogic plugin), or more industry-standard engines like Unity or Unreal.
In practice, though, I struggle so much with motivation on projects (more on that later) that this precious momentum I’d found by installing and clicking around in Ren’Py was water in the desert, and I wasn’t going to waste it looking for a better oasis.
I did, however, still need to pick what my game was going to be about.
My goal was “to make a game of similar scale to MILK”, which I defined as “a visual novel where a single playthrough lasts less than 30 minutes”. These constraints provided useful bearings: since I was trying to make a pretty short game, my focus was less on coming up with stories and more on coming up with experiences - individual moments, set pieces, and moods.
That initially led me to structure my game like Emily Carroll’s experimental webcomic The Worthington, where the reader/player visits different hotel rooms full of creepy stuff in whatever order they want.
As I brainstormed freaky things to fill my hotel with, I was reminded of one of my favorite stories set in a hotel: SLEEP NO MORE. In that show, performers move throughout a huge stage full of different rooms, and wandering audiences have to choose who to try to follow from scene to scene.
I decided to incorporate some of that into my game’s structure: some of my characters would be moving through the hotel at the same time as the player, and be in different places at different times. So, by choosing which door to open, the player is also choosing which narrative threads to follow or ignore.
I hammered out characters, places, and events next in a fit of manic brainstorming. Because my structure was essentially “sampler platter of freaky shit”, I focused on what made each experience unique - or, put another way, what each encounter contributed to the overall palette of the game.
I didn’t worry too much up front about how to tie them all together, since I knew that would come more easily later. I do a lot of figuring out while writing - when I’m actually staring at the page and trying to figure out how to turn my idea into a tangible arrangement of people and actions that feels “real”.
Plus, the “sampler platter” approach meant I could start writing each scene separately, which made things easier and meant that the order I wrote them in didn’t matter.
What was important, though, was finishing a full first draft of the script, first.
Execution
Halfway through my project (when the script was done, but little else) I spoke with Tristan Barona - developer of DON’T GIVE UP and KINDFOLX - for some advice. A big chunk of the conversation was around the importance of sticking to your scope, staying within the boundaries of what you set out to do. Otherwise, you can end up constantly opening up new rabbit holes instead of ever finishing.
As Tris told me: “For a visual novel, your script is your scope.”
That said, I was very much fiddling with the script throughout the whole project.
When I talk about “nailing down the script first”, I don’t mean “having it totally finished” - I’m talking about having enough of it finished that you can commit to estimates for what you’ll have to do later. Writing some new dialog or a couple lines of descriptions is free. The commitments that those words might incur won’t be free.
So at a minimum, you have to nail down the number of characters and settings - which then determines how much character art and background art I needed, how many pieces of soundtrack (and how long they needed to be), etc.
Once I loaded my full first draft into a prototype, I could get a feel for pacing and tone: How many facial expressions did this character need over the course of the scene to feel “animated”/believable enough? When did I want a change of scenery to break up a long text-heavy segment? How many different moods did I want to emphasize with specific soundtracks?
The relationship between the script and the rest of the game was not one-way, though. Often, I found my goals and limitations informing my writing:
In SLEEP NO MORE, the finale of the play is always the same - what differentiates each performance is who you follow and what you examine along the way (since you can’t see everything in one go), and that’s the overall experience I wanted to recreate in my game.
Then, while brainstorming the script, I came up with the idea of having the game’s menu screen feature an electric sign for the game’s fictional hotel, and having different parts of that sign light up after you discovered certain details in the game. Because you wouldn’t be able to discover all the details in a single playthrough, this would hint to the players that there’s more to discover.
But by doing this, I was also implicitly giving the players a goal: find everything. And by giving them a goal, I was also implying there would be a reward for completing it.
Would that reward be additional “lore”? A unique mini-game? Maybe “just” a fully-animated scene?
I circled the drain on this for months (the first version of the game that I sent out to playtesters just had some prose over a black screen for this part).
The real, lasting breakthroughs would come later in the project, as everything started becoming more concrete. At that point, I could start trading the vague questions (“What would be a satisfying payoff?”) for more specific ones (“Is it feasible to commission a fully-animated scene from my character artist?”) - and answer them. The narrative payoff I finally settled on was as much a result of practical problem-solving as it was a product of brainstorming and writing.
The process that led to me figuring out the game’s culminating themes and messages began with this early idea on how to make a menu screen more useful.
Learning how to actually code the game was varyingly easy and frustrating, full of excitement and false starts, just like learning anything else. At one point, I asked my boyfriend to help me program a bespoke system for tracking data across save files, only to later learn that Ren’Py already has a built-in way to do that, which only requires a single word of code. (Sorry babe!) That’s just how it goes sometimes.
Ren’Py in particular was a great choice.
Ren’Py is tailor-made for visual novels (as opposed to Godot or Unity, which are designed to be able to make anything), which greatly limited what I needed to learn - both because I wouldn’t need to worry about things like “gravity” or “light sources”, and because Ren’Py came with loads of basic functionality built in (like the little window for text that appears when a character is talking).
From there, learning what I needed to make my game was roughly similar to doing some reasonably rigorous online troubleshooting: I’d type my questions into Google and start clicking links.
And if that sounds too intimidating, here’s a rundown of what you might expect to find:
Ren’Py’s documentation is pretty good (though like all technical manuals it will leave newcomers in the dust from time to time) - I didn’t start with it, but pretty soon I was searching there first. It was also important for me to learn some of the fundamental technical terms for Ren’Py (like what “screen” or “transform” mean in this program specifically), so I could ask the right questions when I was stuck. Also, it’s worth mentioning that Ren’Py is still being actively maintained and updated as of this writing (2024).
Ren’Py’s creator and lead developer, PyTom, also started a forum and a Discord server dedicated to making Ren’Py games. Threads from those forums often turned up in my search results and were usually very helpful, even if they were years old. I’m really impressed by the Ren’Py community here.
There is also a separate Ren’Py subreddit, but I found it to be relatively inactive, and the responses were pretty hit-or-miss. Sometimes I found a helpful answer to exactly my question, but more often I found an abandoned thread - or a couple of responses that were just vague spitballing.
Matthew Vimislik (a.k.a. Vimi) is an experienced indie dev whose YouTube channel about designing visual novels stood out to me. His videos range from short & specific tutorials, to longer discussions on how to make your games stand out - all of which were snappy, clear, and approachable. The video on how to plan out your soundtrack was especially instrumental (ha) for me.
Shawna (a.k.a. Fen) is another indie dev who made some great tutorials (this time in text form), many of which are frequently referenced in the Ren’Py Discord. They’re also made for beginners, covering topics as basic as “What is a variable?” (which, for the record, is about the level of programming/coding experience you need to get started in Ren’Py - i.e. almost none).
Despite how they’re marketed, tools like ChatGPT (and even Copilot) are useless for beginners. Every now and then, I see someone in the Ren’Py Discord post something like “I asked ChatGPT to write me some code, but when I put it into my game, I got a bunch of errors I don’t understand…” And then they end up spending the same amount of time learning “the hard way” as they would’ve without ChatGPT.
I thought about writing a play-by-play of how, exactly, I made the game - and maybe some day I will - but having just finished my first rodeo, I don’t think I’m in a great position to tell a prospective game designer How You Should Do It. All I can speak to is How I Did It.
Which brings us to the evergreen enigma of long-form projects…
Motivation
Motivation is fucking magic.
I don’t know how to catch and tame that rare bird (or if it even is a bird, and not a song, or a thunderstorm…), and I don’t trust anyone saying they’ve figured it out.
When I hear a fellow gamer with ADHD ask me “How did you keep motivated during the less interesting bits?”, though, what I think they’re actually asking me is “How did you actually finish this project?”
And I think that’s a different, and more answerable, question.
I didn’t stay motivated during the boring parts (and some of them definitely dragged on for weeks longer than they “should” have) - but that ultimately doesn’t matter, cos did finish it.
Requiem, another experienced indie visual novel dev, gave some incredibly helpful advice about this in the Ren’Py Discord recently that I was lucky enough to catch - which involves figuring out four things:
What you are able and willing to do
What you Are able to do, but only if you really must
What you are unable to do, and unwilling (or don’t have the time) to learn
What you are unable to do, but willing to learn
You don’t need help doing the stuff that you are able and willing to do. Working on this stuff usually feels good, and the accomplishment you get from doing it can help you power through the rougher stuff - whether that’s learning something you’re really stuck on, or getting through something you don’t want to do as much.
Meanwhile, the stuff you can’t do and won’t learn is stuff you need to either get someone else to do, buy some pre-made stuff to use, or figure out how to cut out of your game.
I didn’t have Requiem’s advice while I was actually working on this game, but it does fit with my experience working on it. Hell, one of the reasons I decided to make a visual novel in the first place is because writing prose fits squarely in the “willing and able to do” bucket for me - so I knew I would begin this new project by doing something familiar and energizing.
And some of the most relieving moments came when I decided that something fell into the “unable to do and unfeasible to learn” bucket.
For the first several months, I had been planning to do all the character art myself.
The truth is that although I wanted to learn how to draw better (so I guess the “motivation” was there), I was spending full afternoons redrawing my placeholder stick figures to make sure they looked “right” to me - there was no chance I was going to be able to finish the game this way.
Deciding to instead save up and commission an artist got rid of a major problem (“How am I going to draw all these characters well enough?”), and replaced it with something in the “willing to learn” category (art direction).
And as an added plus, the final art kicks ass.
Looking back on everything, one of the most surprising observations I’ve made is how many stories like that I have: times when creative decisions flowed from structural constraints or implementation details.
Here’s just one more:
I initially had a plan for a certain character to only appear in a specific set of circumstances that was a huge pain in the ass to figure out how to code, and would’ve made me have to implement a bunch of logic throughout the entire game just to enable that one scene. After putting that off for long enough, I ended up ditching the initial plan to instead place the character in a part of the script where I didn’t have much other interesting stuff going on yet - a decision that improved the narrative flow, but that I made entirely as a result of saying “fuck it” to a bit of annoying programming.
And then I came up with an idea for a new scene that could give a hint how to find that character, and I could put that scene in another relatively empty part of the script, which helped players out while also fleshing out the context around that character a bit more. And then…
So much of the process went like this.
I’m used to having stories knocking around inside me, and I’m used to thinking about them and tinkering with them - but usually in the frictionless mental space of a notebook page, where my pen is unconstrained.
Having to use a new set of instruments - ones that you have to tell precisely where each image should appear, and for how long, and what happens if a player should press this button - forces you to ask a whole new set of questions about your story, and thus see parts of it you never would’ve.
And now that I’ve learned how to ask some of those questions, I’m excited to figure out what other stories I can learn with them. I’m brainstorming stories in a whole new way. It turns out that “How can I tell a story in a way that reads well on a mobile device?” can be just as rich a seedbed for narrative as “How can I tell a story about loneliness?”, once you’ve started to learn just enough to be dangerous.
Hopefully, PARTS OF THE ELEPHANT will just be the first.
Indie game development rocks.
(If you write a review for my game on either of these storefronts, you’ll be the coolest person on the planet.)
