Category Archives: Devblog

Journey Home Dev Update #2: Back to the Drawing Board. Literally.

I promised I would write a blog update once a month on Journey Home (previously). I lied. LIED. I’m a total liar.

Something went terribly wrong, creatively, so I don’t have much to show for my last few months. I took a little time recently to unpack what happened before trying to figure out how to fix it.

What went wrong:

  • I spent too much time in the planning stage, and not enough time in the implementation stage. Normally my side projects have a one-page design doc to work off of and I go right into development. This time I have pages and pages of brainstorms and action items, an excel doc with so many unique tabs, and even a trello schedule I tried setting up. Instead of making the game clearer in my head, it became this massive, unwieldy thing I couldn’t keep track of.
  • I still didn’t know if the game was going to be fun, and whether whole systems I was designing were going to be thrown out. I was afraid to spend the time it would take to prototype these systems (since it required coding knowledge I still don’t have) so I took even more time in planning to try to figure out which of those systems to keep or toss.
  • I attempted to prototype a whole game, rather than make a manageable ‘vertical slice’. All my systems were too integrated that I couldn’t identify the core to create. I couldn’t figure out how to strip it down to something manageable.
  • The game is still not playable. Even now I do not have a working prototype. To be fair, I have a Ren’Py project and a decent amount of coding with something you can click through, but it’s not representative of the gameplay at all.

The longer I went without making a playable version of the game, the bigger the task weighed on me and the less interest I had in the project. This is like a standard list of advice for newbie game designers on what not to do. It kind of goes to show you that even when you have plenty of experience making games you can still fall into the standard traps. My design was completely derailed.

I’m writing about this now because I figured out a way to get back on track.

A few weeks ago I played Eldritch for the first time. It’s a cooperative board game with a lot of pieces, cards and complex systems where players travel the world, discover clues, collect allies and items, and try to prevent the awakening of an Elder One. It took a good five hours before we lost.

I realized something during that game: Journey Home would work really well in that medium since it shares a lot of similar mechanics. Eldritch isn’t the first board game like this that I’ve played, but for some reason I didn’t connect the dots until now. Maybe because I took a long enough break from Journey Home that I could look at it with fresh eyes. Maybe I needed a game as good as Eldritch (it’s really good!) that is always wonderfully complex (lots of if-then statements in cards) to get the ideas rolling in my head.

So I am changing direction a bit and going to adapt my work as a board game – for now. This will help me identify systems more clearly and how they interact with one another and prototype them rapidly in a playable medium. My documentation has shrunk back down to one page again and I can skip the coding that tripped me up in favor of some paper rules a human can follow. I’ve never built a board game before (with one awful exception that shall go unnamed), so in some ways this is new enough territory that I am not falling back on bad habits.

Here’s a bit of progress I’ve made on the board game version. I am keeping it simple right now by making my cards out of the backs of old business cards, and will migrate to better supplies once I run out.

devupdateJourney Home, version 0.1

Some of the pieces I’ve made:

  • Player tokens to represent movement through the jungles
  • Tiles players pull as they explore, representing Jungle, River, or Cave environments
  • Explore Deck, high risk/reward for discovering new environments
  • Forage Deck, low risk/reward for exploring within a previously discovered environment
  • Event Deck, which is probably best called “Catastrophes”. These are new events each round that stack up against the players. They can try to resolve them to get rid of the negative effect, or ignore them, but the longer you play the more catastrophes stack up.
  • Conditions Deck, issues that can effect allies such as poisoned or cannibal
  • Item Deck, low-medium quality items that give bonuses, such as a gun to combat
  • Artifact Deck, high quality items that require skill checks to ‘unlock’ with high risk/reward
  • Character Sheets, with rough ideas on what skills or stats I want in the game (Strength, Survival, Speed, Influence, Lore, Faith, and Health)

Balancing is non-existent. I’m just curious right now about the cadence of play, and am inventing the skill checks and pass/fail scenarios in my head as I step through it. My next goal is to start penciling in those stats onto the cards. Just doing this barebones board game has helped identify a lot of problems – What does it mean to “move” through a space? How long does a catastrophe last? How does the player win or lose? Is it compelling to play in the long run, or does it just get harder and harder until you fail?

I’ve never really done paper prototyping before since I don’t think it’s very useful in the kind of games I normally make – either interactive fiction with minimal systems, or large AAA games that can’t really be distilled into a board game. I don’t think it’s a coincidence that Journey Home is my attempt at a system-centric game and it translates so well to the board game medium.

With that said, I’m going to link to one of my favorite GDC talks, Soren Johnson’s “A Study in Transparency: How Board Games Matter“.

Journey Home Dev Update #1

I promised myself I would post updates, and even though I missed my deadline of one post a month (the first and last time I mentioned this was in January), I am still continuing with it. Since I spent most of January travelling, and most of February preparing for my GDC talks, and March was GDC and the epic GDC flu, Journey Home has taken a bit of a back seat. I’ve mostly focused on organizing data, creating documentation, and planning ahead rather than implementation.

With that in mind, today’s update is going to be about the MOST EXCITING part of game development. That’s right! I’m talking about scope!

 

SCOPE

It’s really hard to judge scope. When I planned out my game, it was with the intention to finish it in one year. When IFComp announced that they’d allow entries that were already talked about prior to the competition (i.e. devblogs allowed) I wanted to shift the data up to the end of September, cutting off three whole months of development. Three months of what is essentially a nine month project is a huge deal! That means… compromises and cuts. It also means I really risk not hitting my deadline.

When defining scope, there’s a few questions I try to answer:

  • How long does your game take to play and see all content?
  • How long is an ideal game session?
  • What percentage of your content is replay?
  • How much content do you need to make to create that ideal play session?
  • How much time does it take to create that much content?

So, since Journey Home is a piece of interactive fiction, I actually have a pretty good baseline for judging length of time to play (reading speed + choice speed), how much content I would need to make (words written), and how much time it takes to create that content (writing speed).

I’ll use IFComp for my first pass at this, but my scope will change if I change my mind and continue working through January instead of September.

 

How long does your game take to play and see all content?

IFComp judging guidelines say to play for two hours or less, and the nicer judges really do attempt to play for the full two hours, including replay in order to get to branching paths. So we will say that it takes two hours to see the bulk of the content.

Since Journey Home is a roguelike, I am not actually concerned about one-hundred-percenting the game. I am more concerned with majority of content rather than all of it.

 

How long is an ideal game session?

The roguelike nature implies really short sessions that get longer and longer as the player gets better at the game. I think I am going a slightly different route – but won’t really know until I get a chance to playtest it. I suspect that the average session will be closer to 30 minutes, and for the rare person that wins the game you would need to play for longer than an hour.

So the answer is that the ideal game session that I should plan for is 30 minutes of content.

 

What percentage of your content is replay?

Based on that 30 minute session, in that two-hour judging time a judge should ideally replay the game four times.

But that doesn’t mean all the content should be the same. I want replay to feel unique and while continued replay should provide familiarity to the player, I expect new content almost every time a player engages.

So we’ll spitball  a number here – I am comfortable with 10% of content seen again on replay from one session to the next. So the second time someone plays Journey Home, 90% of the content should be unique.

Again, this is a roguelike with elements of randomization so I can’t ever be certain that these numbers hold true, but I can make it statistically likely.

 

How much content do you need to make to create that ideal play session?

Oh boy, this is the exciting bit! First we need to gather data about the player:

  • I know that the average persons reads at 250 words/minute.
  • I know that choices will slow players down, as will reviewing their resources and stats. I will make a guess and say that it takes 2 minutes to make a choice.

Alright, now for data about the game itself:

  • 100% of scenes have the following in common:
    • Introduction – 125 words
    • First Choice – 125 words
    • Second Choice – 125 words
    • Third Choice – 125 words
    • Follow-up – 125 words

Those consequences are the game’s responses to your three choices – all scenes have three choices. However, this really just means that you get a scene, make a choice, read the direct consequence, and then the follow-up, and you are done. But I want my game to have more going on! I want some percentage of multi-step scenes!

  • 66% of Scenes have a second round of choices
    • First Choice – 125 words
    • Second Choice – 125 words
    • Third Choice – 125 words
  • 33% of Scenes have a third round of choices
    • First Choice – 125 words
    • Second Choice – 125 words
    • Third Choice – 125 words

But wait! That’s not all! One of my goals in this project is to have scenes remember and react to previous events in the story. These scenes need to have slight variations in their text that acknowledge the player’s other decisions. This might mean something as simple as describing the group of survivors as “hungry” or “tense” depending on recent events. That means we need words in each scene to vary.

  • The number of words in a Scene is increased by 20% to take into account context-sensitive events.

What about replay? What did I say about how much content can the player see again when replaying between sessions?

  • 10% of content can be seen again on replay between sessions

Last bit! You really do need to account for all variables or else you are doing yourself a disservice. Since this game is a roguelike, and community (and players telling their unique stories) are important in those games, I don’t actually want all the players to experience the same content (unlike, say, a linear game like Last of Us). I want to create enough content so that each player has something unique to talk about, even while sharing experiences with each other. This is really hard to gauge, though, and is going to be another one of my guesses.

  • Any given player should only experience 25% of the total game content. That means that for a single player, I have to create four times the content. (This is like extending your 2 hour game to 8 hours worth of content).

Okay, this is really starting to add up to a scary amount of words. And that’s really what I am looking for. “Content” in a piece of interactive fiction mostly consists of “words”, so since I group my words into discrete scenes, I need to know how many scenes to make for that 2 hour experience.

I’ve done my calculations in excel, but here’s the raw data and what it looks like:

SceneCal_1

Once I know how long they spend on average in a single scene (six minutes!), I can calculate how many scenes I need to create for a 2 hour experience:

SceneCal_2

Okay! I need 74 scenes created, tested, and implemented for October. That’s not too bad, right? Maybe? I don’t know. This is why we are calculating scope!

 

How much time does it take to create that much content?

This is the home stretch really, but we have some more calculations. For one thing, a player goes through a scene and only takes one choice out of three… but I still have to write all three! So there’s a lot of content that players aren’t actually going to see. There’s also that 20% bump to everything written to take into account previous events.

So to figure out how much time it takes to make this game, I first need to find out how many words are in an average scene:

SceneCal_3

Almost 1200 words! That’s actually not bad at all. When I do my weekend Twine jams, like Her Pound of Flesh, I average about 10,000 words. I could do 8-10 of these scenes! Except I would want them to be better quality, and they have more programming involved, and more polish, and I can’t sustain crunch like that, so it would still take longer. I don’t want to be overly optimistic so I will put myself down for 1,000 words per day. (Real writers will know that this is still overly optimistic.)

SceneCal_4

It will take me more than 12 weeks – 3 months! – solid of just writing text in order to complete this game. I have about six months so that might actually be doable. Keep in mind that I am not factoring in programming, design, art, sound, playtesting, polish, fx, accessibility, localization, and so on, so that easily fills in the rest of development.

To put it in perspective, 88,000 words is the average length of a novel. It’s a really big task. Realistically speaking, you don’t write a novel in only three months – not unless it’s a pretty badly written novel.

 

So why calculate scope like this?

In my case I use words, and in others it will be chunks of work like art assets, levels, systems, and so on. I personally calculated this out because I needed to know if it was manageable. The answer is that it’s barely manageable.

There’s another reason though. I have a game full of scenes, and there’s many different “types” of scenes. As I was brainstorming scenes, I realized I wanted to make sure that I wasn’t making too many scenes of one type or another, and that all the different resources and game states had a good amount of coverage.

For example, for my prototype game I am just concentrating on scenes dealing with the food resource – hunting, gathering, hunger, starvation, spoiled food, poisoned food, and so on. I wanted to have events tied to the food resource stat depending on if it’s high or low, but also events that reflect party moral. Imagine this: what if  you are low on moral, low on trust, and low on food? You get hording and stealing behavior.

But to do good coverage for a single stat like food, I created a total of 31 scenes. This is just for my prototype! Now that I’ve done my calculations, I know that this is half of the scenes I need in the final 2-hour game, and that this is 37,000 words! That’s almost 6 weeks of writing! And we’ve only covered food – we haven’t even touched on all the other survival elements and cool story opportunities in the game. This is how I know that my planning phase has a severe disconnect with the actual scope of Journey Home.

 

Update your scope calculations!

One last bit before I finish this update. It’s important to do scope like this in excel (if you can chunk up your game like this) because things change as you get better information. For example, what if players only take 1 minute on average to make a choice? What if it’s 3 minutes? That means anywhere from 55 to 111 scenes, and anywhere from 2 to 5 months of writing time!

The good thing about something like excel, if created right, is that I can just change key figures and all the calculations will  update.

 

One Year, One Game

One of my New Years Resolutions was to put aside game jams and instead focus my energy on a single game. So this year rather than make half a dozen small games pumped out in a scattering of weekends, I am going to spend all that time on only ONE game.

To keep me on track, I’m starting a devblog. Once a month, I will show what I’ve accomplished since my last post and discuss some of the design challenges I’ve been facing. Hopefully, this keeps me accountable to some kind of schedule, where I’m forced to make regular progress throughout the year. (This won’t interfere with my other project of reading and reviewing game design books). If you’re into narrative in games, you might even find these posts kinda of interesting,

With that said… I’d like to introduce Journey Home, the game I’ll be spending 2015 working on.

Journey Home is an interactive fiction roguelike, where the player and their party must trek through a hostile, fantastical jungle in search of their home on the far side. It’s inspired by books like The Drowned World by J. G. Ballard and The Scar by China Mieville – both excellent science fiction fantasy hybrids with amazing prose. The gameplay probably has the most in common with Inkle’s games like 80 Days and Sorcery!, but there’s a bit of A Dark Room and The Yawgh in there.

I originally started making Journey Home almost a year ago in Twine, and it was shaping up nicely until I decided to divorce it from Twine’s restrictions (flowchart based decision tree) and port it to Ren’Py, taking advantage of python scripting flexibility, existing UI, and support for visuals and sound fx.

Capture_JourneyHome_Twine

On the top, the original prototype in Twine. (Remember, text is a rough draft). On the bottom, the current wireframe in Ren’Py as I start to organize content. As you can see, I started working on it before the new year, but it’s in very rough form.

Capture_JourneyHome_RenPy

Journey Home was originally a testbed for a particular narrative structure I have wanted to try in a game. The gameplay is focused on a collection of scenes, each with their own choices and consequences, strung together to create an overarching narrative. These scenes are obstacles the player must resolve before continuing their journey – heat, humidity, roaring rains and floods, dangerous creatures, insect swarms and disease, and even the doubts and desires of their party of NPCs. Its gameplay systems focus around stats like health, inventory items, food and water, number of people in the party, and shifting attitudes like fear, faith, and dissent. I am not sure that semi-random events quite fill in for procedural generation, a hallmark of the roguelike genre, but it’s close enough for me.

The player’s goal, of course, is to survive as long as possible and make their way home.

My own goals, as a game designer, are harder to pin down. They are currently outrageously out of scope – as in, I really don’t think I’ll succeed in all accounts, but I’ll be damned if I don’t try. I’ve narrowed down my design philosophy for Journey Home to the following:

  • Narrative takes priority. This is my main design pillar: the narrative cannot be sacrificed in favor of gameplay elements (inventory, player stats). Though the game is built around dynamic systems, these systems must still deliver a narrative that feels seamless and intentional. The text is hand-authored, not generated.
  • Stacking consequences. Future scenes must at minimum acknowledge previous experiences the player has had, and at most radically change the choices and context of the scene.
  • Controlled pacing. I need to oscillate the intensity of the game, moving between low risk/reward to high risk/reward scenes. When the player suffers a major setback, they should get a breather. If players are achieving their goals too easily, they need to encounter more difficult choices.
  • Character development. Characters who remain from scene to scene need to react, remember, and evolve based on their experiences, driven by the player’s decisions. Over the course of many scenes, players need to see their protagonist character grow and change.
  • Replayability. Players should be able to play the game several times and reach substantially new content, even if they make many of the same choices or play with similar strategies.  The risks they take replaying the same scene should still be meaningful. The game is not deterministic: it should be possible to write a strategy guide, but not a walkthrough.

I’m probably more optimistic about hitting somewhere in the ballpark of these goals than I should be, but this is something I’ve been knocking around solutions to in my head for a couple years now.

I have some other goals I want to integrate into the game as part of a year-long effort:

  • Visuals. While the focus is always on the text and narrative, the game should be fully styled, with appropriate illustrations to match the various scenes the player encounters.
  • Visual effects, sound effects, and music. This is all about making the game “juicy”. The effect should be an animated, multimedia wrapping that fully supports the key focus of interactive fiction.
  • Accessibility. The game should integrate as many accessibility features as possible, focusing on hearing, sight, and mobility.
  • A full packaged product. An appropriate splash screen, settings interface, tutorial, saving system, and similar elements that make it a more polished product. Achievements may or may not be on the table.

All these goals have one important thing in common: polish. This is something I’m intimately familiar with at my job, but is absent from most of my game jam projects (since the time limit on jams specifically precludes polish). This means that from the very beginning of development, I am prototyping and integrating the above goals into the game. Instead of adding sound effects and music last in a rush to complete the game, they will be added early and iterated on with each milestone – just like in proper game development. I’ve also put aside some money to possibly hire audio and art support, but that won’t come up for a quite a while.

Now, I don’t actually think I’ll hit all my milestones in one year and produce a fully polished, complete game. (Like any piece of art, I don’t believe games are EVER done). My only real deadline I am giving myself is that by the end of 2015, I HAVE to have a complete demo released to the public.

That’s it for this month. Next month I should have some updates on the design of how scenes are shuffled and chosen dynamically as the player progresses through the game.