How I built a game studio from the ground up - lessons on product ownership, development, and creative writing

When I had the idea to develop a video game back in university, I was confident it wouldn’t be difficult. After all, I had the coding chops to deliver. What I didn’t know was that this entire endeavor would force me to wear the hats of product owner, project manager, creative director and writer, business development, marketing, and just about everything else. Imagine my shock when I discovered all these roles beyond coding! So here’s the story of how I wore those hats and survived, shipping the game after 2+ years.

How it all began

I lived in Taiwan from ages 8~18, covering part of elementary school, to completing high school. Now, the school system in Taiwan is pretty typical of East Asia, known for the brutal academic culture. For each exam, grades and rankings are posted publicly for the entire school to see. I was intimidated; I was several years behind everyone, who could read and write already. I had only just learned how to write my own name in Mandarin.

From then on, I somehow managed to do quite well. I scored in the top 1% on the mandatory entry exam to high schools, which are gated by grades. In North America, this sort of pressure (think SATs) can be overwhelming for those in high school, but imagine facing that pressure at the age of 13! I was accepted to the top ranked high school in Taiwan (which only accepted top 1% scorers), and proceeded to score top 4% in the university entrance exams.

Why go into all of this detail? The experience has taught me how to handle pressure like it’s my second nature. I was inspired by the competitive culture, where events at such a young age could drastically affect one’s entire life trajectory. Hence, I wanted to create a game about agency vs. conformity, and how a cutthroat environment could bring out compassion as well as ruthlessness in people.

The thing is, to create a game with such a personal story, I knew I had to do this independently. If I worked in a AAA gaming company, the story elements would likely be of someone else’s creation, with many stakeholders to please. Thus, from the start, it was a given that I would take on the writing and software development roles to execute my vision. So I started planning: designing the fictional world, writing outlines, and drawing diagrams of story flow. And so began my first role - the narrative designer and writer.

Role 1 - Narrative designer and writer

Since the core objective of my vision was to tell a story, designing the world was an essential and core part, and seemed an obvious starting point to the entire game development process. I had experience writing fiction with tens of thousands of words, so I thought this would be easy. However, I was quickly proved wrong - for example, writing dialogue for a game is more like screenplay writing, than novel style writing, which I had to adjust to. Since the visuals and audio are presented on screen, many components of novel style writing are made redundant for game writing, in my case.

I wrote at cafes, the coworking space Gamma Space, while travelling in Asia, and at home, giving me a taste of digital nomadism (without the income…). As a blessing and a curse of having full creative control, after 1 year or so, I went through a complete narrative design rehaul where I scrapped over 30k words.

I wish I had admitted earlier to myself that my first concept design didn’t work, and rehaul it before I wrote those 30k+ words. This was due to my impatience to start writing before I could take a step back and reflect more on just the outline. It was like diving into the trees before I fully saw the forest. On the other hand, I emerged learning that it’s okay to scrap work, and not to linger on it, for scrapped work makes way for better work!

Role 2 - Software developer

I was the most confident in this role throughout the process, despite being the single person to not only code the entire game, but to integrate with Steam API and handle deployment. It was a lot of responsibility, not only to myself, but to any players when the game went live.

On the coding front, I learned the most about good OOP (object oriented programming). Game menus, screens, character types (e.g. playable vs. non-playable) and many other objects, are best implemented with classes and heavily rely on inheritance to avoid duplication and allow for scalability. I spoke about this at PyCon Canada, video link to be updated when available.

I learned a lot about deployment on a huge platform, which has a lot to do with using Git and Steam’s patching system for binary files. I was strict with using Git, since I develop with multiple machines (laptop when remote, desktop at home). I also used a separate Linux machine for testing. One litmus test of my Git expertise was that I launched the game to customers while moving apartments, so I had to set up my desktop on the ground, pull a week’s worth of code changes which I had pushed from my laptop, compile the new build, and deploy the game immediately. Thanks, version control!

The pros of being a solo developer was full control over features and implementation methods. As such, I had a lot of fun implementing anything that came to mind, such as a timer that tracks how long players take to respond in-game, and dynamically generate dialogue in response (I have a Visual;Conference talk about this feature). I could also change the UI as much as I pleased, a luxury that I likely wouldn’t have in a large team of game developers.

Because of this absolute power, there are some parts which I implemented with less structure than if I’d planned to hand over the code to someone else. However, it turns out that these “hacks” are pretty readable, as evidenced by the process of porting to consoles, several months post-launch, involving more remote developers, who didn’t even need to ask me questions! Thanks, habit of detailed code comments… I always think to myself, “I should delete those comments”, but then it came in handy!

Role 3 - Project manager

Project management was one of the hardest roles, up there with creative writing. I completely underestimated how much brain power and attention that outlining tasks and scheduling timelines takes. It requires a different type of focus than coding; it was difficult to constantly switch between the two models of thinking, which, for a long time, dragged down my effectiveness at both tasks.

Come to think of it, a major difficulty was that, I was both the PM and the developer resource that the PM manages! The experience definitely helped me be more empathetic towards PMs, and I do think it helped me become better at communicating approaches and timelines at work.

During the development process, there were often struggles between my PM self and my developer self. As a developer I would set overly aggressive/optimistic timelines, which my PM self would then schedule other dependencies on. When the developer self couldn’t get things done, the PM self learned to add more buffer time, and communicate that to the developer self. The process was like inner dialogue with multiple mindsets. There was nothing better than actually being in the PM’s shoes, to realize what I was doing wrong on the communication front as a developer!

I have many favorite learnings from this experience - Buffer, buffer, buffer, ask good questions of the developer to gauge their effort and timeline, and managing scope creep (shared learning with the optimistic developer me)…

Role 4 - Business development and marketing

Yet another role was to get exposure and coverage that would lead to sales. For example, I had to reach out to reviewers, journalists, and influencers, as well as create contests to generate buzz. I researched gaming journalism, created spreadsheets of emails to reach out to, and gained a huge insight into the influencer channels in the gaming industry.

What I didn’t expect, was that this role also improved my public speaking skills. Through game development I’ve been able to share my technical expertise with large audiences, such as at Python conferences and meetups, as well as being a 3 time speaker at a well regarded conference on the genre. In addition, as an attendee of large gaming conferences, I developed the ability to walk up to any fellow attendee and strike up a conversation. This ability has had infinite dividends, including in my professional career in the machine learning field. I also learned to speak with people all day when I boothed (showcasing demos of the game at conferences). There was no one else in the studio to swap shifts with!

Another role, which I’ll put within business development simply because it was part of my efforts to gain exposure, was marketing. I did market research, and created outreach strategies that my business development self acted on. Thankfully, I game a hell lot, and am an avid collector of games, so I came into this role with existing industry insights. What was new, was learning to pay attention to game design details from the perspective of a creator, in addition to that of the player.

I also had to DIY marketing materials at times, which added amateur graphic designer into this mix. Cropping and resizing logos, creating banners and thumbnails, for my store fronts, website, press communications, promotional graphics, and so on, helped me appreciate, even more, the work of graphics teams that goes into every product launch.

Role 5 - Product owner and creative director

So many roles have been discussed above, but surprise, there are more! I did as much as I could on my own, but to create a shippable software product, I wanted professional quality art and music. Even though I can draw and play several instruments, I decided that attempting to improve those existing skills to professional levels would dilute the efforts of my previous 4 roles. So, as the product owner, I provided priorities, requirements, and vision to those that contributed to the following.

Art

One of the key attributes of a game is the style. Once, in a game developer event I attended, there was a discussion of if programmers’ generally higher pay, compared to artists’, was justified. I initially agreed, and as someone in the audience said, “without a programmer, there is no game”. However, one excellent point was brought up - you don’t buy Nintendo games because you know what their source code looks like. Often, what comes first and foremost to a player’s mind with Nintendo games are the characters and memorable art style. Without artists, Nintendo would not even have a brand. This understanding shaped my vision that my game’s art should be distinct and unique.

I set out to find an artist on online forums. This is where my inexperience showed - I actually had to commission two sets of art. The first artist produced lovely and high quality art, but later on, I happened upon the work of another artist that made me immediately think, “I need to have this as my game’s style”. The second artist came with a much higher price range, but I have no regrets, as her work created the memorable painterly style of A Summer with the Shiba Inu.

Communicating with the artists was another test and growth of me as a product owner - I needed to communicate my vision while leaving the creative expertise in another’s hands. In fact, there were some cases when, after I received the concept art or complete art, I was inspired by some details the artist came up with, and “persuaded” the writer self to rewrite some parts of the story to fit. This is where this project really benefited from me having full creative control - imagine having to wrangle these changes with the PM, and then talk to the writer, in order to make those changes in the story.

User interface

Similarly to the point about artists above, the UI style is a large part of the visual aspect and the “front line” when it comes to a player’s impression of the game. I found a very talented GUI (graphical user interface) designer, who has created UI for many games that I enjoyed playing.

Again, due to my inexperience, I actually had to trouble this designer more than I needed to - as I was coding the UI there were some parts I had to ask to change or add. One cause of this was scope creep, for example, if my developer self wanted to add many features, and my PM self hadn’t really questioned the necessity, it caused some asks to the designer that were seemingly on a whim. Next time I develop a game, I’ll be able to communicate much better with UI and graphic designers, as well as formulate my asks more clearly, helped by what my developer self learned about OOP.

Editing

After my writer self finished writing the game’s script, I did end to end editing myself at least twice. However, I decided to commission an editor and search for proofreaders. It’s hard to look at one’s own work with a fresh eye. Sure enough, the editor found typos that I was surprised existed, but of course, because I was used to reading the text again and again, my mind had built up heuristics and skimmed over typos instinctively. An editor was completely worth it!

Music

While I can write music, and play several instruments, it just wasn’t the right time to be using music as a creative outlet when I was so overloaded with writing and game design. In addition, soundtrack scoring is a very different type of endeavor than writing music only to express my feelings - it needs to capture atmosphere and story in a more holistic way. I looked on a great site called Purple Planet for some placeholder music (they have very high production value, royalty free music which you can purchase a license for commercial use). Luckily, I have a friend that is a producer and musician, who ended up composing for the game, replacing most of the royalty free music. You can listen to several tracks, including one with a fabulous sax solo, on his SoundCloud.

Playtesting and quality assurance

I’m very grateful to my friends, in real life and online, who spent their time playing my game. However, as I’ve learned from many developers before me, playtesters often cannot commit fully. Hence, it’s better to ask more people, and follow up many times. Another thing I was worried about was if people hated the game - would I change it? Thankfully, this did not happen, because I was making a game with the purpose of showcasing my full creative vision; I worry that I might have changed my vision, if my focus was on revenues.

All roles coming together to ship the game

In the end, after much trial and error, I managed to ship the game. In reality, there were many hiatuses I took, and many, many dark moments when I felt that I could not carry on. I worried many nights about if the product really could launch.

For this, I am grateful that with somewhat miraculous, sheer willpower, I was able to shift between all my roles, all requiring different mental models and skills, and get them all to collaborate. I had to be in touch with both my creative self and logical self - much easier said than done. I am grateful that I was able to let life come first at times - I completed a Master’s degree and found a full time job, all the while continuing to work on the game over the course of 2~3 years. I’m consistent, I’d like to say!

I am grateful to many individuals, which I can write another full article about, but for this article, I’d specifically like to point out something Henry Faber said, which felt like the sun had rose again, during a particularly dark period of writer’s block and extreme unmotivation. I can’t find the exact quote now, but my takeaway was that “this game is not going to be [your] life’s work.” In other words, I needed to stop fretting about my huge backlog of ideas to add into the game. This mindset shift broke me out of the paralysis of perfection I had - my product owner self had been suffocating under some of the expectations from just about all of my other selves.

Another nugget of wisdom from the gaming community that helped me was that, sometimes, it’s better to release a game that’s not fully “finished” (but playable, and not broken). It’s just that oftentimes, the writer self wants more story, the developer self wants more features, and many other ideas on the backlog simply cannot be completed. As long as the player can experience it, it’s fine to just release it. This learning really pushed me towards the lean product mindset, and focusing on iteration from an MVP, for any new features I pushed out.

Top learnings list

This is a summary of my favorite learnings from this experience, across all roles. I covered as much as I could in this article, but honestly, I feel I could write multiple pages for each of these roles - it was a lifetime of roles and effort condensed over only 2~3 years!

• Git or some type of version control to work across multiple machines, and to scale up any software development
• Vastly increased empathy and communication across multiple roles - for example, as a PM to a developer, and as a developer to a PM
• Being able to walk up to anyone at a conference and start a conversation
• Being a product owner, managing requirements and helping the team execute the vision
• There will be times where it feels the project has no end; but keep in mind the MVP mindset - this is not going to be your life’s work, a released game is good

You can find the game on Steam here: A Summer with the Shiba Inu

Featured post on Gamasutra.

Featured on Game Career Guide.