This is part 1 of an ongoing postmortem of Train, a conversation-based, narrative-driven art game about journeys, destinations, and reconciling perspectives that I released in March of 2017. You can download Train from GameJolt or IndieDB.

1

The poverty line is located in Cleveland, Ohio. 

It is drawn perpendicular to Lakeshore Boulevard, a worn-down thoroughfare which runs along the Lake Erie shoreline of the city’s near east side.

To the east of this line is North Collinwood, a neighborhood of odd bedfellows - a thin lakefront sliver of modest lower-middle-class houses, home mostly to artists and academics, lines what is otherwise one of the poorest neighborhoods in the city. If you head south and cross a bridge arching over the nearby Collinwood Railyard, you will reach South Collinwood, an even more impoverished neighborhood located along Cleveland’s infamous St. Clair - Superior stretch, as well as East Cleveland, a crumbling inner-ring suburb on the brink of financial collapse.

To the west of the line is Bratenahl, a lushly forested “village” that serves as a tucked-away home for many of Cleveland’s elite. It is completely hidden from view along the nearby I-90 interstate, where Bratenahl police run their speed traps with clockwork efficiency. Many Clevelanders don’t even know that it exists. If you venture down Lakeshore Boulevard into Bratenahl, however, you will find dozens of sprawling old-money mansions, gated communities built around placid marinas, and even wilderness trails that extend out onto an artificial peninsula known as Dike 14.

As is the case with neighborhoods in many of America’s class-divided and segregated cities, North Collinwood is largely black, while Bratenahl is largely white. What is truly unusual is that these two starkly contrasting neighborhoods are separated by feet, not miles. It is perfectly conceivable that one could bike westward on an early summer evening, starting from the intersection of Lakeshore and E. 152nd street in North Collinwood, passing abandoned homes and aging roads, only to cross the line within minutes, wind through the entirety of Bratenahl, and arrive at the peaceful Dike 14 park in time for the sunset.

It is at this line, located just minutes away from my family home of 22 years and burned into hundreds of my childhood memories, that Train’s story began, long before I came to know it.

My name is Max Krieger. I’m 24 years old, and I’m pretty good at pretending to be a video game developer. Every day, I come home from my day job as a Salesforce programmer, sit down in front of my laptop, tell myself that I’m going to work on a game, and, if I’m lucky, open Unity. What happens after that is out of my hands. I repeat this process until I feel comfortable saying “I’m a game developer” to people at parties and the occasional industry event.

I started that daily routine about two years ago, shortly after I graduated from college and started my current job. It continued, with varying degrees of success, until five months ago, when, to my surprise, I actually managed to complete and release a game of my own. That game is called Train; its official elevator pitch is “a narrative-driven, conversation-based art game about journeys, destinations, and reconciling perspectives”. Without the fluff, Train is a “visual novel plus”, a game consisting mostly of dialogue with the occasional minigame to keep the pacing fresh. This piece you’re reading now is officially a “postmortem” of Train, a game industry term for a post-release retrospective and self-critique. To that effect, I’m here today to talk a little bit about Train, what went into it, and what I learned from it. As I started the drafting process for this piece, though, I gradually realized that I had something more important to talk about. 

While Train taught me a fair deal as a programmer, a great deal as a writer, and even a little bit as a producer, it was who I am as a person that underwent the most significant metamorphosis over the course of the project. I use “metamorphosis” instead of “transformation”, because transformation often implies a sense of self-determination and intent. This was not the case - to put it bluntly, I was kind of a piece of shit when I started work on Train, and I only realized that by accident when I found myself in over my head. Ultimately, the game was barely salvaged, and I often wonder if my instinct to scrap the project would have been the right choice to make as a producer. I know for a fact, though, that sticking with it until the end was the right choice to make as a human being trying to become better. As flawed and worse for wear as the finished game turned out to be, I think it ultimately became something much more compassionate and genuine then it was at its outset. I like to think the same of myself.

Postmortems are often written to bestow a personal seal of success or failure on a project. Whether or not Train itself can be considered either of those, through the lens of games critique, is of secondary importance to me. I will share my thoughts on that subject later on, but if you take only one thing away from this postmortem, let it be this: 

Train was born from the stories of real people, whose names I do not know, but who I see every day. Their stability, their health, and their safety are at risk. So much of the world doesn’t seem to care about these people, due to ignorance or hatred or both in various proportions, and the resulting gap of empathy means that these people continue to suffer and die. Train was my most sincere effort to create something, anything, to help bridge that bleeding gap, even a little. I don’t know whether or not what I eventually created can accomplish that. I do know that I had to try, and I hope that reading this story helps you find the strength to try, too.

Winter 2013

Train’s initial concept first began to manifest in early 2013, during my sophomore year at DePaul University’s video game development program. DePaul’s program is notable in that it focuses on often-ignored aspects of game development like production and management, in addition to more typical core programming and design courses. One such offering was an Intro to Video Game Production class, a ten-week course in which I had the distinct privilege of learning from Patrick Dwyer, most recently a producer at the now-dissolved Chicago studio Robomodo. 

I came to admire Pat not because of any impressive pedigree or claims to fame; in fact, one look at his resume quickly informed me that he had seen his fair share of game development war stories. Robomodo, for example, was the developer responsible for the poorly-received Tony Hawk’s Pro Skater 5 and Tony Hawk’s Pro Skater HD. Before Robomodo, Pat was a producer at the long-defunct EA Chicago, where he worked on the similarly received Def Jam: Icon before the studio’s closure.

It would be easy to assume, based on my above description, that Pat worked on a bunch of “bad games”. That’s not Pat would tell you.

What Pat would tell you is that video game development is an unpredictable business, made up of many moving parts, and that final products are just a small part of what defines success or failure for a video game developer. Without revealing sensitive information, all three of the titles I mentioned shared their fate for one reason: making a video game, particularly an IP-licensed project laden with external creative input, often boils down to playing the cards dealt to you as best you can. Pat did so while carrying himself with exceptional grace and professionalism. 

I came to admire Pat because, rise or fall, he never stops moving. Without him and his neverending encouragement, I never would have found the strength to keep myself moving during Train’s roughest patches.

I first presented Train’s original concept to Pat during my finals presentation in his Production course. I worked together with Alice Morrow, one of my bests friend and eventual lead artist on Train, to produce a pitch, mockup trailer, and basic production roadmap for the then-hypothetical game. Looking back at these documents in 2017, I was surprised at how much of the finished product’s spirit and aesthetic were present from day one (for the curious, these documents have been compiled and are available to download from the game’s various download pages as of this writing). 

Train’s first one-line pitch read: “A thought-provoking and genre-melding platformer adventure game that weaves together the lives, worlds, and destinations of the five mysterious passengers riding an eternal train.” According to the original spec, the game was to be divided into three main sections:

From the outset, Train was to be a text-heavy game, only putting it a couple of steps above a visual novel. I decided on this approach in no small part due to my lack of programming knowledge at the time, hoping that I could instead leverage my writing skills to create the meat of the game’s content. Four NPC passengers were proposed: a Mexican-American man named Alexander, an Asian-American woman named Elaine, a middle-aged Eastern European man named Dylan, and a young black girl named Tanya. All four of these passengers would have their own individual storyline, each with a variety of branches and routes. In addition, the player could talk to the train’s conductor, Raymond, who would serve both as a side character and a hint system. Due to the game’s open-ended conversation system (detailed later), vast amounts of non-linear dialogue would be required for each NPC, presenting a challenge that a foolhardy young Max was eager to undertake. 

In order to draw in players who may normally be scared away by something so dialogue-driven, strong attention would have to be paid to the game’s visual design. The presentation and pitch document specified a “sketch-style” look for the game’s characters, consisting of 2D portraits drawn on top of photorealistic paper textures. The hope was to create a “collage” motif which would repeat throughout the game’s different areas and minigames, each of them featuring their own unique art style that best fit the character of their paired NPC. Dialogue portraits and character animations were to be rotoscoped, for both the purpose of saving time and to create animations with more human-like subtlety and uncanniness.

Alice and I managed to cover all of this in about five minutes of presentation, capped off with the hastily-thrown-together concept trailer that I had made the night before with stolen music and stock art Alice had prettied up in Photoshop. 

People clapped. More of them than I expected.

This is the place I first thought Train’s story began - a presentation in a college classroom, in front of a surprisingly interested Pat and surprisingly interested classmates, concluded by surprisingly loud applause. That presentation was the moment where Alice and I both realized that Train had the potential to become an actual, real thing. In the days that followed, we both talked about all of the stupid things that kids talk about when they realize that they no longer have to settle for being daydreamers. We tossed concept after concept back and forth over frozen food from Trader Joe’s as we sat at the tiny kitchen table in our Lakeview apartment. This is one of the actually fun part of game development, and it never lasts for very long.

Concept art of the four passengers from the pitch - Dylan, Alexander, Tanya, and Elaine.

Component 1: The Conversation System

Train’s dialogue system was conceived, in equal parts, by my desire to create something original and by my sheer loathing for Mass Effect. 

Back when the concept that would become Train was still in gestation, Mass Effect 3 was a hot topic in the video game social mediasphere. Most of the discourse around ME3 was focused on its infamously anticlimactic ending, or its disappointing production values, or its relatively rocky queer representation. Amidst the high tempers and somewhat contrived scandals surrounding these criticisms, I found it ironic that my biggest issue with the series seemed to be its only consistent point of praise.

Train’s mechanical backbone, the Conversation Bubble system, was born as an act of heartfelt protest against Mass Effect’s Dialogue Wheel.

For the unacquainted, the Dialogue Wheel consists of a circular menu of dialogue choices, wherein you tilt the analog stick (or your mouse) towards a desired question or remark you want to deliver to an NPC. My distaste for the wheel began with slight misgivings I felt during Mass Effect 1; scenes with tough negotiations seemed too easy, and no matter how fast and loose I played my words, I never felt like I faced any real consequences. This unease continued to grow as I began playing its sequel, Mass Effect 2, and it finally culminated in what I can only describe as accidental sex with a party member named Miranda. I was so insulted, patronized, and unsettled by this particular incident that it led me to drop the series altogether.

When you can have sex with a video game character unintentionally, something is wrong.

The sheer concept of what had happened immediately brought several questions to mind. How was I able to do it? Why was I able to do it? What agency did Miranda have in this particular narrative, and how much of her perceived agency was merely window dressing, delicately placed to create a desirable conquest for players?

As an experiment, I decided to load up an old ME2 save file and take a stab at the game again, paying extra attention to the dialogue choices available from character to character. It quickly became obvious that my approach to interacting with the NPCS was not what the game expected. I had been been treating my crew with the same respect as I would treat real people if I were a starship commander; I was professional, earnest, yet amiable, with the hopes of becoming true friends down the line. My greatest obstacles in that pursuit were the words the game put in my mouth.

The “good cop/bad cop” Paragon and Renegade dialogue choices, color-coded blue and red for easy recognition, are easy to notice and imply a certain outcome - I expected them to be blunt instruments from the beginning. It was the normal dialogue options that truly surprised me on my second playthrough; in the majority of cases, they could easily be grouped into the distinct categories of “I want your help”, “I want to antagonize you”, and “I want to sleep with you”. In particular, for most of the game’s women, there was little distinction between friendly and amorous responses. With this in mind, I concluded that I had reached Miranda’s sex scene so early in the game, unwittingly, because I had simply intended to be friendly to her in the same way I had been with the men on the ship. 

That’s when I realized that what I was doing with Miranda, and all of the NPCs, was not conversing with them. It was using my words to exert agency on them, in what amounted to yet another masked power fantasy. I was able to have sex with Miranda so easily because the game wanted me to do it and feel good about myself; in the process, Miranda had been reduced from a character to a goal. It wasn’t just her. The more I thought, the more I realized that this issue extended far beyond Miranda, or the women of Mass Effect, or Mass Effect itself. In the world of most RPGs we play, characters and goals are one in the same. 

That’s pretty fucked up, when you think about it for a bit.

I wanted my next game to do things differently. I didn’t know it was Train yet, but I was close.

I knew I was on the precipice of a breakthrough, so I set aside a week to physically prototype a handful of experimental NPC conversation systems. From the beginning, I wanted a system more open-ended than a wheel or a list, with the goal of more accurately emulating the broad possibilities of a real conversation. I played with word association charts, autofill text prompts, and even a color-based word modification system. At the end of the week, only one system made the cut: an early version of what would go on to become the Conversation Bubble system used in Train.

The Conversation Bubble system is fairly simple from a mechanical standpoint - rather than presenting the player with several pre-formulated responses, multiple “bubbles” containing pictographic icons are presented instead. The player then must combine two bubbles to form a response. For example, combining a hamburger icon bubble with a car icon bubble may form a question such as “Would you like to go out to eat?;  the player would then be able to preview that question and confirm it in order to pose it to an NPC. My hope was that the nebulous nature of multiple free-floating topics, with no pre-existing associations, would better reflect the role of topics as the true building blocks of conversation, hopefully encouraging exploration and deemphasizing shallow gratification in the process.

The most exciting part of designing this system was discovering an unexpected but exciting quirk in how it scaled with game progression. Players would start the game with only a few bubbles, limiting their initial conversation options; progressing through the game would, predictably, unlock more bubbles and increase the number of potential responses. The glimmer of genius in this system was that the number of new responses per new bubble increased exponentially as the game progressed, due to the bubble-pairing mechanic; increasing from three to four bubbles would add three new potential pairs/responses, while increasing from six to seven would add six. Early tests quickly showed that players were fascinated with the long-term narrative payoff that occurred with such a rear-loaded progression model, and feedback indicated that it created a sense similar to that of “getting to know” an actual person. 

After some glowing initial physical prototype tests re-confirmed this positive feedback, the bubble system was formally adopted. For reasons that may already be apparent to experienced designers, this was the first major mistake in Train’s production history. 

The original paper prototype for what would become the conversation bubble system.

Spring 2014

    After the initial pitch in Pat’s class, Train lay dormant for about a year, due to programming classes consuming most of my free time and mental energy. Nevertheless, Pat continued to prod me about the project at every given opportunity; “How’s Train doing?” had become his greeting for whenever he saw me in the halls. Though I would laugh and handwave his question away, I had been asking myself the same thing for months, searching for an opportunity to actually bring the project into production. I still (rightfully) lacked confidence in my programming abilities, and knew Train was too big of a project for me and Alice to tackle alone. Creating Train as a senior capstone project was a possibility, but Alice and I both worried that leaving the project alone for that long would result in it being forgotten. What we needed was a team of interested students, particularly programmers, who would be willing to work on the game in their spare time.

Such an opportunity was presented to me by Doris Rusch - a DePaul game design faculty member, the founder of DePaul’s “Play For Change” lab for the development of socially-conscious games, and a staunch believer in the power of games as tools for social change. She very well may have seen that potential in Train before I did. I often wish she would have warned me.

Doris just so happened to be my faculty advisor at DePaul. I mentioned Train to her offhand during an advising meeting, and she immediately took interest, checking in on the project’s status regularly. Thanks to her motivating spirit and undying support, we were able to turn a chance set of circumstances - an unexpected free class/credit slot - into an independent study that served as the true jumping off point for Train’s development. 

Doris and I worked together to create a production roadmap for this 10-week class, mainly focused on preproduction and forming the project pipeline in order to continue development over the summer. The very first decision we made was to dramatically reduce scope from the initial pitch; due to the limited time we had to work with, the number of NPC passengers was reduced from four to one. We chose to continue with Tanya, due to the low representation of black women in video games. The rest of the game’s structure - the conversation bubble system, the platforming dreamscape, Raymond, and the minigames - remained unchanged.

I was to serve as the project director, while also focusing on writing the game’s script. With these two roles keeping my hands full, it would be important to hold in-person meetings once a week to keep the rest of the development on track. Preproduction tasks, such as concept art and systems prototyping, would have to happen in parallel, with my creative input being my only participation. Doris would serve as an intermediary, helping to coordinate production tasks with the rest of the team, as well as advising me on what amounted to my very first role as a project lead.

Once a plan was in place, assembling a team proved to be much easier than I had anticipated. Thanks to her contagious enthusiasm, Doris was able to recruit a band of students who expressed interest in the project, and enrolled them all in the independent study to ensure their commitment. Zac Gross and Thomas Bauers, two programmers, joined onto the project, along with Rachelle Jackson, an artist, and Gabriel Garcia, a game audio specialist. With Alice and I rounding out the roster, we finally had enough talent assembled to start working on Train in earnest. Kicking off with a humble team lunch in the Chicago Loop on a chilly April morning, Train’s development formally began in the spring quarter of 2014. 

Our production timeline planned for the team to work on the game through spring quarter and during the summer, with a beta target date of September that very same year.

Train would not see release until March of 2017.

Maybe it’s best that it happened that way.

The link to the next part of this postmortem will be provided here once it has been released. Stay tuned!