First Steps: Lessons from Indie Game Prototyping

In between consulting work, I’m plugging away on a solo project. While I’m not ready to talk about the details of the game itself, the process to date has been educational. Regardless of when I finally deliver it, I’m happy with the approach I’ve taken.

The last time I worked on a solo project, just before my stint at BonusXP, it was a touch too ambitious. I still believe in that product and intend to finish it. But after a few months of prototyping, it became clear I would need funding and a fair bit of help – programming, and art – to drive it to completion.

This time around, the new project is something I can build to a 75% level entirely on my own. It’s a simple narrative game, only one notch more mechanically complex than a visual novel. As I’ve written about previously, I intend to replace my prototype AI-generated art with real stuff done by real humans, but that can come later after the game’s design is proven out.

And, though I don’t want to get into details on the game itself, it’s not too early to highlight some of the development lessons.

The Starting Gate

Ages ago, I got my start in the industry building indie adventure games – purely text-based affairs in the old Infocom style. I enjoyed every part of the process from puzzle creation to crafting the (simple) narratives that would pull the player forward.

Modern narrative games have substantial budgets and better presentation than the classics. Pure text games are rare, but there’s a plethora of diverse, mechanically simple games that deliver compelling stories in fantastic ways. I’m talking about experiences like Disco Elysium, which looks like an old Bioware RPG but plays more like an adventure game, or Doki Doki Literature Club, a brilliant horror game disguised as an anime-tinged visual novel.

Game design can start from a lot of different places. In many cases, mechanics drive the narrative rather than the reverse. Sometimes a clever twist in the mechanics might drive the story, as in Control or Portal.

For designing a game that’s narrative-forward and mechanically light, I began with the story I wanted to tell. The inspirations and the feelings I wanted the player to have were crystal clear out of the gate, though I needed to spend time upfront defining the details.

In purely narrative games, the paper design phase is critical. Focused titles like Disco Elysium and Gone Home don’t happen by accident, and they’re not designed by a committee. I’m a huge believer in iterative development, but in the case of this project, key narrative beats are the stakes in the ground that the rest of the design will rotate around.

Preparing the Ground

I had a few elements I knew I wanted out of the gate. The specific mood and setting would be carried by the art and the style of the prose. I wouldn’t need a fully 3D world; a simple 2D location map, like a player-made location node map for an old Infocom game, would suffice for the exploration element. 

I also knew this would be a turn-based game. I wasn’t interested in adding real-time pressure, or even the illusion of it that narrative-focused games like Gone Home or Firewatch deliver. The player could explore at their own pace, like a traditional adventure game.

While I wanted most of the events to be triggered by the player’s wanderings, I also wanted to mix things up so that the game didn’t just feel like a linear visual novel. Narrative events would sometimes exist just for mood or story depth, but there would be moments of genuine choice and consequence.

To help achieve this goal, I implemented a couple of additional buckets of actions that could trigger narrative events. If you’ve played big sprawling narrative board games, think of the narrative events like a card draw during a player’s turn, something flavorful adding a bit of story to the act of moving a player’s pawn from one space to another.

Visiting a location was the obvious event trigger, but I wanted more. I gave the player a simple inventory – just a traditional list of items. The player could “look” at the items at any time by selecting them.

Just this basic addition opened up the game’s player vocabulary significantly. Items could have context-sensitive events depending on where and when the player looked at them – for instance, a key being examined in a specific spot opening a specific door. Or, alternatively, simply having the key in your inventory and interacting with the location might be enough; now I had options!

I then extended the concept a step further. The player’s “inventory” includes things like “your eyes” and “your ears.” This allowed for location-specific actions akin to listen and look – similar to the basic action buttons in classic point-and-click adventure games like Secret of Monkey Island, all driven through the same event system.

For a touch more mechanical heft, I added three stats. While I don’t show the player raw stat numbers like an RPG would, the UI conveys generally the rough value of the stats at any moment. This created a vector of costs and consequences to narrative events – and also another bucket for the player to interact with.

Selecting an inventory item might yield a different narrative event based on your location or the value of the three stats. Selecting a stat might yield a different event depending on the items in your inventory.

Finally, time and player progression are factors. When locations, inventory items, or stats are selected, different narrative events result depending on the player’s progress through a three-act story structure.

As simplistic as the structure is, these few elements working together create a healthy stew of nonlinear interactions. They’re the perfect building blocks for a flexible narrative structure that respects player agency and feels more like a traditional adventure game than a linear visual novel.

Stocking the Toolbox

I started with familiar tools that I knew would get the job done. Unity is my engine of choice; it’s well-suited to the relatively minimal technical needs of the game, and I could reuse pieces from my earlier narrative project.

Ink was a no-brainer to drive the narrative events. It’s a solid scripting system with a Unity plugin, one that I’d used to great success on my earlier project. 

This time, however, I started with a better technical design. For my previous project, I had only a couple of large Ink files, which quickly became a mess of conditional spaghetti scripting. 

For the new project, the structure of the game helped drive a better model for organizing the Ink content. Everything the player can select – a location, an inventory item, or a stat – has its own Ink file and its own event branching. This lets me isolate individual events in the game and more quickly figure out what bits interact with other bits while keeping each file clean and readable.

This model also helps me scope the game properly. I can put the bulk of my effort into high-priority events, especially items or locations that gate player progression through the story. As development time allows, I can flesh out side content easily – adding bits and pieces to less critical locations and items to add optional moments of color, texture, and mood to the narrative.

Teaching a Game’s Vocabulary

I’ve written before about the power of the traditional text adventure model – how staring at a blinking cursor in Colossal Cave made me feel like I could type anything and the game would figure it out. That illusion is quickly broken, but it’s a fantastic moment.

Modern gamers are immune to such tricks. They want to understand the scope and breadth of a game’s mechanics and quickly get to the fun parts.

For a long stretch, the game industry’s answer was lengthy, scripted tutorials that slowly unveiled one mechanic after another. Some games still follow this model, but it always works better when a game eases you in naturally without feeling like you’re in a tutorial.

The more mechanically simpler a game is, the easier it is to teach players how to play. A game that’s primarily about making narrative text choices in dialogue menus is about as straightforward as it gets. Still, I had a couple of mechanics I felt required explanation. 

Players needed to know there was an inventory. They needed to know that selecting items in the inventory has location-specific consequences. And they needed to know that selecting locations or items multiple times may yield additional narrative results.

Fortunately, the early content in the game proved to be the perfect vector to introduce the game’s mechanics to the player. The first narrative event a player gets is a choice about what to do with the baggage they’ve brought on their trip – leave it behind, bring it with them, or pay someone to carry it for them. 

As the player travels to their destination – linearly in the early stage, before alternate paths are revealed – the location events constantly reference the baggage. If the player brought it along, their pace is slower; if they left it behind, it’s easier going.

Once at the destination, the baggage, whether delivered or carried, must be unpacked. This requires interacting with the inventory item not just once, but multiple times in a row, and it has to be done inside – in specific locations. The narrative text makes the necessary player interactions obvious, as it’s the first time the player will encounter the mechanic.

At this point – maybe five or ten minutes into the game – the player has seen everything they need to interact with the rest of the game. Though I still expect iteration after wider playtesting, the early content is achieving the teaching goals I hoped it would.

Building the Business Case

Narrative games are a tough sell. Any design that leans heavily on text and story, expecting people to read and fully absorb its content, is not a mass-market opportunity in 2024.

I think my expectations are in the right place. I’m not trying to build a complex triple-A title or get rich from this game. I’m aiming for a focused 2-3 hour experience, with content that’s deeply personal, at an appropriately tiny price point on Steam. The only ambitious aspect is aiming for game content that will be genuinely memorable for a certain type of player.

I hope being transparent about my approach to the prototype is helpful. The mechanics and examples are basic, but some of the lessons are applicable to games at any scale.

Successful teams focus on the right things upfront. Depending on the game, that might be the game’s vision, business case, mechanical design, or development process – or more likely, a combination of all of the above.

The key takeaway is this: figure out what the “right things” are for YOUR game – and focus on those first.

New blogs appear on ScreeGames.com every Tuesday, with a repost on Medium on Wednesdays.