Nine Dev Log #2: Design Research

In 2015, I attended a Boston Post Mortem talk by veteran developer Steve Meretzky. It was jam packed with great advice, but one bit that stood out to me was that a good designer strives to be an “overnight expert”.

The concept is fairly straightforward: game designers have to make countless decisions that impact the player experience. The more context a designer has, the more informed those decisions are. And one way to gain this context is to prioritize design research in the early stages of development. I have come to believe that good research can significantly increase your chances of designing a successful game.

NordicResearch
Members of the God of War team on a Nordic Research Trip (photo from “Raising Kratos”)

Designers at large studios may have great resources for doing design research during pre-production. For example, Sony Santa Monica funded a small portion of the God of War team to go on a “Nordic Research Trip”, to countries in the Scandanavian region.

But as an indie, my options look more like:

  1. Play reference games in the space.
  2. Research the subject matter.
  3. Learn from designers in the space.
  4. Learn from the potential audience.

Note that when I say “the space”, I’m referring to the “design space” surrounding the game. This can be very broad, but for the purposes of this post I am going to focus on learning about gameplay systems in the roguelike and platformer genres.

#1. Playing Reference Games

Much of the reason Nine has evolved into a roguelike platformer is because of my past influences. On the platformer side, I grew up playing classics like Sonic, Mario, and Donkey Kong series, and am familiar with some of the modern takes such as Celeste and Hollow Knight. On the roguelike side, I’m a big fan of some strategy games like Into the Breach and Card of Darkness, as well as some action games like Cadence of Hyrule and my primary reference: Spelunky.

But there’s so much more to learn!

In the coming weeks I hope to play:

  • Games that combine roguelike and action platforming elements. This is the core focus area and includes games like Dead Cells, Rogue Legacy, 30XX, Noita, and Catacomb Kids.
  • Popular games with roguelike elements (Crypt of the Necrodancer, Slay the Spire, Roundguard), which can teach me about procedural generation, progression systems, difficulty pacing, and more.
  • Popular action platformers (Ori and the Blind Forest, Cuphead, Guacamelee 2), which can help me make the player feel like an agile warrior cat.
  • Notable flops in the above genres (critically and commercially), so I can learn what mistakes to avoid!

It’s worth mentioning I don’t have the money or time to buy and play all of these games. But I can at least play through the early parts of the best ones, and watch streams and reviews of the rest.

#2. Researching the Subject Matter

The origins of the “cats have nine lives” myth is a bit vague.

There are some direct references such as:

  • An old English proverb: “A cat has nine lives. For three he plays, for three he strays, and for the last three he stays.”
  • From Romeo & Juliet: “Good king of cats, nothing but one of your nine lives.”
  • The Egyptian sun god Ra, who sometimes took the shape of a cat (Mau), gave birth to 8 other gods and thus represented “nine lives in one”.
Bastet-MET
A statuette of Bastet at the MET Museum.

And there are many more stories of cats having “multiple lives” has broader origins, with various cultures referencing 6 or 7 lives instead of 9.

The takeaway was that I had a lot of flexibility, as there was not one specific history or myth that people would associate the game with. I toyed with the idea of an Egyptian theme focused on Bastet vs. Apophis, but decided in the end to settle on a more cartoonish theme of cats vs. mice.

But we can explore the theme further in a future dev log. Let’s move on for now!

#3. Learning from Designers

There is a wealth of knowledge from game developers who have made roguelikes and/or platformers in the past. This information has been dispensed through design blogs, youtube videos, GDC talks, interviews, podcasts, and more. Why should I reinvent the wheel?

SpelunkyBookCover

The biggest and best reference so far would have to be the Spelunky book by Derek Yu, which dives deep into both the personal story of creating Spelunky and the design challenges Derek faced. It surprised and inspired me to learn that relatively simple algorithms could create such rich emergent gameplay. It was also humanizing to see that even a legend like Derek had real struggles dealing with conflicts both personal (like parting ways with Alec) and professional (like dealing with varying player response to Spelunky’s difficulty and randomness).

There are also some great youtube videos on procedurally generated levels by authors like Extra Credits and Mark Brown, but they are mostly a higher level overview of what the Spelunky book covers. Still, it’s handy to see how these authors chunk complex ideas into accessible presentations.

Finally, the podcast The Spelunky Showlike has been a wonderful reference. The show is rooted in pure love for Spelunky, and they use roguelikes as a lens to which to discuss game design. The result makes them feel like a team of allies in my quest to understand the design space. I trust that they “get” Spelunky, which means the discussion can focus on the challenges of making those games shine. They have also interviewed designers of notable roguelike like HoledownCard of Darkness, and Roundguard.

#4. Learning from the Potential Audience

The potential audience is the theoretical group of people who might enjoy the game.

A good place to start is with the audiences that already exist. These might include people who enjoy specific games on my reference list or love the loosely defined genres of roguelike or platformer. It makes sense to try and win them over, since there is clear overlap in gameplay systems. Such audiences may also include people who appreciate lighthearted cartoony aesthetics, themes that don’t take themselves too seriously, and action without excessive violence.

But an existing audience also comes with expectations. A roguelike/roguelite fan might expect the deep progression systems of Dead Cells or the emergent physics of Spelunky. A platformer fan might expect the tightly designed rooms of Celeste or the big roller coaster moments of Sonic. I’d like to win these people over, but there’s also a part of me that needs to accept that Nine is its own unique game that doesn’t fit neatly into those boxes.

To learn from these audiences is to find them, talk to them, and most importantly listen to what they have to say. Even when they’re not articulate, their experiences are just as valid. And the good news is that their expressions of opinion can be found everywhere: in reviews, youtube comments, discords, and more.

Much harder to find is the theoretical person who wants something just like your game but:

  1. Doesn’t know it yet.
  2. Knows it, but doesn’t know how to ask for it.
  3. Asks for it, but is ignored. (<- Actually this is the story of some memorable crowdfunding successes).

I can’t talk to this nonexistent portion of the audience just yet. But I look forward to it very much.

Conclusion

It’s tricky to make time for design research. And it’s hard to prioritize in the early stages especially when you are still rapid prototyping. But I think that if you are trying to maximize the chances of making something great, you really want to immerse yourself in the space and strive to become an “overnight expert”.

I’d hardly call myself an expert of course, but the research I’ve done has already helped frame my iterative goals. I have a better idea of what kinds of problems I’m likely to run into, as well as a larger toolbox for solving this problems. And the immersion has reinforced that I love living in this design space.

I’ll be back soon to report what I’ve learned. Thanks for reading!

Nine Dev Log #1: How Nine became a Roguelike Platformer

I did not set out to create a roguelike platformer. Nor would I advise any indie to make one.

Nine started with me pondering how the “cats have nine lives” myth could translate into a game.

I eventually came up with the following concept: “You have 9 lives to beat 9 levels in 9 minutes”. I liked the simplicity of it and that the “9” was universal across three properties. It also didn’t feel like anything groundbreaking, so I decided to shelve it in favor of other prototypes.

And yet… even as I explored other prototypes, I found myself coming back to Nine. With each revisit I’d come up with secondary features ideas like:

  • What if as you lost lives, you became stronger? This would create a rubberbanding effect that could make later lives more exciting.
  • What if you had a SUPER move that let you sacrifice a life to deal heavy damage? This could create interesting risk/reward tension and potentially satisfying payoff moments.

I started to think of lives as a dynamic resource. There was something here.

Becoming a 2D Platformer

I liked the concept, but I still didn’t know what kind of game it was going to be. I knew that the focus was action, and I knew that I wanted to make a 2D game, but wasn’t sure about the game’s perspective or moment-to-moment gameplay.

Then I remembered that it wasn’t just about “9” the number. It also mattered that you were a cat, as that was the reason you had 9 lives. This tiny bit of extra thematic information could help me narrow down the design space.

cat jumping
Cats are the ninjas of nature.

Cats are known for their agility and reflexes. Even my beloved fat cat Kit could suddenly switch into ninja mode on a dime and swat her “enemies” (read: toys and q-tips) with lightning speed. When I imagine a cat in an action experience, I imagine it jumping around and showing off its movement prowess.

And thus, Nine became a platformer.

Becoming a Roguelike

How did I get from platformer to roguelike? Honestly, I’m still in the process of deciding.

Nine had permadeath from the start. The concept of “9 lives, 9 levels, 9 minutes” sounds like a short term action thrill, and I didn’t think it would work broken up by save progress points. I imagined the player taking multiple attempts to learn the mechanics and finally complete all 9 levels.

But this led to an issue of repetition and rote memorization. Even when platformers have bite-sized challenges (like N Game or Super Meatboy), a very natural outcome is for players to grind through the same path over and over. Nine needed some dynamic elements to help players focus on building skills over grindy trial-and-error.

This issue was confirmed by an early prototype I dubbed “6 in 6” (6 lives, 6 challenges). The players who succeeded (including myself) did so through memorization. And many players found repeating early levels to be a chore, opting instead to skip to their current level using debug-cheats.

Spelunky solves this problem via procedural generation. Because the layout is different each time, you are forced to learn high level patterns, such as how enemies behave and how the physics system works. This systemic learning is informed by each run, and empowers you to perform better on average as you improve. It’s a very satisfying loop once you get the hang of it.

Spelunky Level
Procedural generation can break rote memorization.

But procedural generation is also a massive risk. On top of the heavy technical and production load, it’s a challenging design task to algorithmically generate layouts that feel unique, familiar, and fun all at the same time. Platformer fans are especially sensitive to the feeling of flow in level design thanks to decades of shared experience and built up genre expectations.

It’s not a perfect answer, but it’s a good starting point.

Moving Forward

My early playtests are promising, but I need a little more time before I can start getting external playtesters to try out the first draft of proc gen levels. I should have a clear answer by the end of the month on whether I need to start shifting direction.

One possible fall back could be a dynamic Mega Man style model: 8 hand-designed levels/bosses, but you can choose the order and the remaining levels get dynamically harder, followed by a 9th final boss.

megaman select screen
Megaman lets you play levels in any order.

One other thing I ditched along the way was the “9 minutes” hard constraint. The whole point of the rubberbanding lives system is to create meaningful tension throughout the run. But if the player is mid-run and realizes they will run out 9-minute clock, they are likely to just give up instead. So instead I will explore some softer time pressures, and maybe offer a bonus reward (like an alternate boss/ending) for players who can get to the final battle in under 9 minutes.

So that’s the story how Nine became a roguelike! Or at least, why it is currently a roguelike. Time and iteration will tell.

Announcing: Nine

It’s official: I’m working on a new side project!

Nine is a roguelite action platformer about a cat who has nine lives to stop nine evil mice from stealing the moon. Nine was recently accepted into RIT’s MAGIC Community Incubator Program, and has been funded for development through Summer 2020.

I will be sharing more information both here and on twitter as the project takes shape. I am currently focused on core gameplay iteration and have begun the process of building a team.

Since this is my first major independent endeavor in a long time, I’d like to try to try and be more transparent with the development process than I am able to with my professional work. There are some meaty design problems to chew on, and I think the journey might translate into some interesting Dev Log style blog posts.

I hope you will follow along Nine’s development and enjoy the content to come.

 

Gaming Goals for 2020

As a designer, I put a lot of pressure on myself to play games. I want to be in on the real-time conversations centered around new releases (like Death Stranding). I want to be well-versed in recent high-impact games that are shaping the industry through popularity and/or innovations (like Fortnite). And I want to be familiar with as many classics and genre-defining games as I can through our medium’s evolution (like Myst).

But there are just too many important games out there. It’s not realistic for me to play them all, let alone complete or master them. With limited time/money/energy, I need to carefully prioritize to get the highest ROI.

Knowing this, and adjusting for the missteps in the 2010s (aka my twenties), here are my Gaming Goals for 2020.

Goal #1: Play Lots of Games

This might sound silly or obvious, but it’s really about trusting the process.

I’ve already put systems in place to vet and prioritize what games I should be playing sooner, as well as what games I hope to play on release. So if I just push myself to keep going, these methods will force me to play a bunch of games that meet my personal criteria of important. I have also come to terms with not finishing every game; I just need to play enough of it to “get it” (subjective), and then I can choose to move on.

According to my logs I played about 37 new games in 2018 and 38 new games in 2019. With a little extra dedication I think I can hit 50 new games in 2020. This is nearly 1 game per week on average, though in practice I expect it to happen in spurts.

Goal #2: Step Outside My Comfort Zone

This goal is about variety of play experience. Left to my own unconscious devices, I’ll just crawl back into my shell. This means playing games in the genres and by the developers I already enjoy.

It’s a particularly hard goal because the goal post keeps moving. For example at the end of 2019, playing a tactics game (Into the Breach) fit this goal, since I’ve historically struggled to get into tactics game. But now that I’ve done multiple runs of the game and love it, I have to weigh the value of diving deeper against moving to new experiences.

A new genre I’d like to try in 2020 is the Auto Battler. Some genres I’d like to revisit are first person shooters and open world RPGs.

Goal #3: Immerse Myself in a Big World

In my twenties, I spent a lot of time trying to figure my life and career out. Which I did! But to do so I actively avoided open-world games because of their huge time-commitment, with very few exceptions (such as Breath of the Wild).

While I was able to find immersive experiences in smaller games, there is something uniquely special about a massive world full of life and character and things to do. So in 2020 I’d like to climb into 1-2 massive worlds. This will help bring me up-to-date with modern advances in world design, and give me the kind of immersive experiences that only gaming can offer.

Existing candidates that intrigue me are Horizon: Zero Dawn and Assassin’s Creed Odyssey, and 2020 release candidates are Cyberpunk 2077 and Gods & Monsters.

Goal #4: Deep Dive into a Multiplayer Game

It’s one thing to play a multiplayer game. It’s another thing attempt play it competitively. I still remember obsessing over every detail in Super Smash Bros. Melee like it was yesterday. I put in over 1000 hours, practiced advanced techniques, participated in forum discussions, and watched tournament matches on YouTube. So in 2020 I’d like to pick a competitive multiplayer game and dedicate some time to improving.

This not about some external goal like placing at a tournament. It’s about that feeling of pushing yourself to your limit; of being so comfortable with technique that you are operating on a higher level of strategy. That feeling when you’re in the zone and connecting with your opponent… there’s nothing like it.

Top candidates are Super Smash Bros. Ultimate and Rocket League.

The Meta Game

Developing a strategy for how to approach playing games is game-like in and of itself. But winning this meta game is only worth it if it does not detract from other parts of my life, including my personal game development goals. And once you are playing a game out of obligation, it begins to feel like work.

I think success here will require a delicate balancing act, but I also think it’s okay to fall short of some of these metrics. In any case, I imagine I will come out of 2020 a more experienced gamer, and by extension a stronger designer.

 

 

Teaching Tabletop Games

Have you ever struggled to explain a new game to a group of friends? Or have you ever been totally lost listening to someone else explain tabletop rules to you?

It is extremely tough to teach new games to a group. Every game, group, and individual is different, so there is no one-size-fits-all approach. And I’m no expert either – I’ve had some spectacular teaching failures myself!

But by seeing (and making) a lot of mistakes, I have begun to notice some techniques that appear to help along the process. I hope that you will find them useful!

Goals

When you are explaining rules, there are two basic goals you are trying to achieve:

1. Get started as quickly as possible.
People just wanna play! It’s boring and frustrating to listen to rules being read. But on the other hand, it’s also frustrating to play a game and not understand what you’re doing. Which is why I say as quickly as possible, because the right approach is a delicate balance.

2. Give the game its best shot at a good first impression.
Unfortunately, it’s unlikely for a tabletop game to be at its best on the first go. Some players just won’t like this game – no matter what! Maybe it’s just not a great fit for them.

But the good news is that if you teach the rules effectively, you will increase the players’ chances of a good first time experience. And that is all you can really do! Don’t set yourself up for disappointment by expecting everyone to fall in love on the first go.

Tips for Effective Teaching

Assuming the game you’ve picked is a reasonable fit for the majority of your group (that’s a whole other topic…) here are some tips and techniques that have worked for me.

1) Learn the rules ahead of time.

plan-2372176_1920

I understand that for some tabletop enthusiasts, there is a satisfying feeling of discovery that comes with learning a new board game for the very first time.

But for many players… listening to the rules read out loud is the worst.

Even the best-designed rulesets have to serve multiple masters. They need to be concise, thorough, scannable, and unambiguous all at the same time. Reading rules out loud will often come off dry and doubtful. Why should your teaching adhere to those same constraints?

Instead, if you take the time to study the rules ahead of time (or even better, try it first with a willing gamer friend), you can speak confidently, and you will have the flexibility to customize your explanation in real-time to fit the needs of the players.

Think of yourself as a salesman trying to convince the players that this game is worth playing. You should be iterating on your approach with each successive explanation.

2) Give only the minimum necessary rules. No more or less.

Less Is More

How do we know what is and is not necessary?

Your explanation should focus on:

  • WHY (goals): What is the object or goals of the game? Usually it’s best stated alongside a very-generic summary of action.
    • Example (Monopoly): “Eliminate the opponents by bankrupting them.”
    • Example (Carcassonne): “Earn the most points by the time the tiles run out.”
  • HOW (actions): What are the core actions I can take on my turn? How do those actions connect back to my goals?
    • Example (Monopoly): Roll & move, buy properties/buildings, pay rent.
    • Example (Carcassonne): Place tiles, claim features, score features.
  • WHAT (objects): What are the core types of objects and resources that I will interact with?
    • Example (Monopoly): Tokens, Money, Properties, Houses, Hotels.
    • Example (Carcassonne): Meeples, Roads, Cities, Cloisters, Fields.

Your explanation should avoid (or be wary of):

  • Rare edge-cases: If it’s relatively rare, does not punish the player, and can be easily explained on the fly, then there’s no reason to spend precious time on it up front.
    • Example (Monopoly): If a card sends a player past GO, they can collect $200 (unless it says otherwise).
    • Example (Carcassonne): If a player draws a tile that cannot be placed, they discard that tile and draw another one.
  • Overly Specific Details: Whenever you can, let general knowledge inform specific applications. That might mean letting players figure out slight variations of a card type as they are drawn, or discover combo possibilities as they emerge.
    • Example (Monopoly): The specific instructions on each Chance/Community card can be figured out in real-time.
    • Example (Carcassonne): The different shapes or iterations of each tile type can be discovered in real-time (or an individual player can reference the “cheat sheet” in the box if they like).
  • Strategy: Strategies will emerge naturally during play as the rules start to click. Advanced players may choose to help by lightly explaining their actions on their own turns.
    • Example (Monopoly): Defensive purchases, bidding value, build timing.
    • Example (Carcassonne): Blocking, stealing.
  • Highly Complex Mechanics: In some cases, a mechanic is sufficiently advanced that you could gloss over it or leave it out altogether. This can be a great way to simplify the game so players can learn the simpler core mechanics. However, this only works if the game is still playable without that mechanic, and if the experienced players are willing to play the simpler version of the game.
    • Example (Monopoly): If playing with kids – you might leave out Auctions.
    • Example (Carcassonne): Claiming and scoring fields.

3) Keep repeating the goal.

arrow-2889040_1920.jpg

It is critical that players understand the goal, above all else. Starting with the goal is obvious. But it can also help to reiterate the goal between other mechanics, to give each mechanic context. Then one more time, at the end of the game, just to hammer it in.

It’s a balance, but extra repeats might be worth the slightly increased speaking time.

4) Make use of visual aids by giving examples

Playing Cards Beside Poker Chips and Dice

Whenever possible, your explanation should be reinforced with visual aids.

For example in a card game, you can explain a card by showing how it might be played from an open example hand. An example setup can give extra context to possible player actions, in a way a verbal explanation cannot.

Tip: Try and get the necessary card types up front. It can break the flow of your explanation to suddenly have to dig through the deck for the specific card you need.

5) Try a “throwaway” round.

litter signage

For many gamers, things won’t click until you start playing.

If it doesn’t take too much effort to break down and redo the setup, consider a lightning quick “throwaway” round, where everyone gets to practice going through the motions and seeing the cards in context. For example, I have used a quick throwaway hand to teach people the “drafting” mechanic in a clean way.

“Don’t worry about the cards – I’ll explain them in a moment. Just pick any card from your hand, and hold it out in front of you on the table, face down. When everyone is holding out their cards, I will say “3-2-1-FLIP” and we will all reveal our choices. Then, you place your card down (you now own it) and pass your entire hand to your LEFT.”

Also, be willing to restart a “real” round if things are clicking and some players are regretting their initial moves. For a quick casual game, they’ll get another chance in the next game, so regret can just be part of the learning. But if it’s still early in a longer game, players might appreciate a fresh start now that they get it!

6) Refer to similar mechanics in other games known by the audience.

Monopoly Board Game on Brown Wooden Tabletop

When appropriate, consider referencing a similar mechanic in another game. For example, recently I introduced Sushi Go to players when we had just played 7 wonders earlier that night.

“Sushi Go is like a quick casual version of 7 wonders. Just like 7 wonders, there are 3 rounds of drafting, except instead of buying cards with resources, you’re picking sushi for sets….”

But be careful: If at least one person has not played one of the reference games, then this tool may just isolate certain players and confuse the overall explanation. I have seen many teachers gloss over important details because they lean too heavily on references.

7) Respond appropriately to questions

woman sitting raising her hand beside woman

One of the hardest parts of teaching board games is responding to different kinds of confusion in the form of questions.

Maybe it’s a new player fixating on a specific detail. Other times it’s an experienced player who is wondering why you “left out” or haven’t gotten to X. Sometimes it’s just totally out of left field.

The first and more important thing is to stay positive, by responding with something like “Great question!”. Confusion is expected, and being dismissive of a question will just sour the experience.

After that, the best response is highly situational. There are a few options:

  1. Answer the question: A question can nag at the player’s head, distracting them from further rule explanation. So sometimes, it’s worth breaking your flow to directly address the confusion.
  2. Delay it: Other times, you feel that the answer is easier understood in a different context. In this case you might say “I’ll get to that in a moment” or “I’ll cover that when we get there in the game.”
  3. Push it on the game: In some cases, the answer is just not relevant for reasons the players don’t yet understand. In this case you can try “I know it sounds weird, but I promise it’ll make sense once we start playing”.

An Imperfect Process

The best teachers and mentors are always flexible. They have a personalized style, but they are comfortable enough to suddenly break their own flow for unique situations, then pick it back up again.

So my final piece of advice is: Do not mistake any of these techniques for silver bullets.

Instead, just give them a try, see what works, and adjust your approach as needed. See if you can get really good at explaining your favorite games. Try explaining new games to your parents, or to little kids. Try and see if you can take on a new game every game night!

And if you learn anything useful, please let me know!

2017 in Review

At the start of 2017, I came up with some professional development goals in this blog post: Goals for 2017. Specifically, these were “off-the-clock” goals (outside the scope of my Funkitron work and goals).

Now that 2017 is over, it’s time to reflect. How did I do?

1. Level Up My Game Design Toolbox

“Success here looks like a vastly improved toolbox by 2018; one that lets me quickly and effectively solve game design challenges.”

This year, I managed to consolidate and organize my existing notes. I also added some great new tools from Daniel Cook’s Lost Garden, Ian Schreiber’s Game Balance Concepts, and I am currently soaking in the many wisdoms of Kobold’s Guide to Board Game Design. I feel like I have a pretty solid framework for how my game design knowledge all fits together, and can confidently and efficiently draw tools from my toolbox.

However, it is a drop in the water compared to the ocean of knowledge and reference I need to amass. I need to find more tools by playing more games, reading more books, and just overall having more experiences.

Grade: B. Useful progress, but I need to do much more.

2. Shrink My Games Backlog

“Success here looks like an smaller and more sustainable backlog by 2018. I hope to be well-versed in 2017 hits, and get a few major classics under my belt too.”

I only made a small dent on my backlog this year, playing only a fraction of the games I hoped to play. However in the second half of the year (since moving back to Rochester), I have managed to play a bunch of tabletop games, both new and classic. These experiences have opened my mind to new kinds of play, have inspired me, and helped me deal with some of my inhibitions around learning new games. Best of all, they were a ton of fun.

Some other good news is that I recently purchased a gaming desktop and a Steam Link, so I am in a great position to shrink my backlog in 2018.

Grade: B. Not enough digital games, but way more tabletop gaming than I expected.

3. Tinker

“Success here looks like a personal collection of microscopic digital and paper prototypes, spanning a range of genres and taking interesting risks.”

On the “personal collection” side, this has been a failure. I spent most of my free time in 2017 vegging, socializing, or dealing with major life changes such as the move to Rochester and getting to know my new baby nephew.

The silver lining is that I did manage to take some time to rapidly prototype some casual game variants for work, which I developed on my own in HTML5 then pitched to my boss as possible new projects to take on. This hyper-focused creative brainstorming and problem-solving was extremely satisfying, reaffirming my desire to specialize in this area. And the reception was positive enough that my boss let me take a full work week to iterate on one of the prototypes with his guidance, which was a blast.

Grade: D-. No personal tinkering, but some rewarding work-inspired tinkering.

4. Get Involved With The Community

“Success here looks like a strengthened bond with the Boston community, improved presentation skills, and a positive impact on some younger aspiring game developers.”

I’m gonna give myself a bit of a pass here. Moving to Rochester mid-year made it near-impossible to strengthen my bond with the Boston community. I did however manage to:

  1. Cement some important relationships so they could continue in long distance.
  2. Give two lightning talks for Boston Indies, one of which I am very proud of.
  3. Serve as a judge for the Mass DIGI Game Challenge.
  4. Dive headfirst into Roc Game Dev and meet a ton of new people.

Grade: B. Given the circumstances, I am very proud of my 2017 community contributions.

The Verdict

Overall, 2017 was mostly productive… just not in the ways I expected. The big move to Rochester definitely disrupted some goals and shifted the targets of others. However, I am proud of my progress in spite of those hiccups, and feel positioned for success in 2018.

Here’s to a new year of game development!

How Game Jams Jumpstarted My Career

I am a huge advocate for game jams. Whether you are a fresh novice still finding your way in games or a seasoned AAA veteran, there is a ton of value in participating in a game jam.

However, there are already plenty of articles and resources detailing the potential benefits of game jamming. So instead, I want to discuss how game jams served as a turning point for me personally. When I was at a scary low point in my life, I did 4 game jams in 4 months, and it jumpstarted my career.

Now, I know that is a strong claim. So to ground it in reality, here are some important disclaimers:

  1. My game jamming experience is just one of many factors that helped me get started.
  2. Game jamming is not a guaranteed path to success. Like anything, results will vary depending on approach, timing, and luck.
  3. Game jams are not a replacement for personal projects. Rather, they are something you can do in addition to (or to take a break from) your personal projects.

Getting those out of the way, I stand by my claim. Today I am a happy game designer/programmer hybrid on a healthy career path, and I truly believe that I wouldn’t be here without game jams. Game jams gave me the confidence, skills, and portfolio to jumpstart my career.

Post-Grad Blues

In 2013, I graduated from RIT with a B.S. in Game Design & Development. But due to my poor performance as a student (the details of which I can cover in another blog post), I returned home to Long Island with a sparse portfolio and zero job prospects. Meanwhile, some of my fellow RIT graduates were getting hired by the likes of Bungie, Zynga, and Microsoft.

It was a tough time for me, and I questioned whether or not I was on the right path. Slowly I began to realize how many opportunities I passed on at RIT, and how many great resources (professors, game lab, etc.) I no longer had access to. How could I turn things around on my own?

The Turning Point

One night, at the height of my frustration, I decided to try and make one of my simplest game ideas: a top-down puzzle game where you control two characters simultaneously with arrow keys. I described the idea to my gamer friend Marco, and asked him to design a level on graph paper while I set the code up.

Once I had the absolute basics – a red and blue dot moving simultaneously with the arrow keys – I asked Marco show me his level. I must have described it poorly, because he misunderstood and thought the characters were supposed to keep sliding until they hit something (like a sliding ice block level in Pokemon or Zelda). Instead of ignoring or correcting his design, I ran with his interpretation, and the result was a fun spatial reasoning puzzle!

An early prototype of Brain and Brawn

Though not officially a game jam, this mini jam-like experience gave me a fun, playable prototype in just one evening. It was an incredibly empowering experience, and I found myself compelled to keep iterating on the prototype (that would later go on to become Brain and Brawn).

With this boost of confidence, I decided to try some game jams in NYC.

4 Game Jams in 4 Months

In a period of about 4 months (October 2013-January 2014) I participated in 4 different game jams.

Purgatory (NYC Gamecraft 2013)

First there was the New York Gamecraft, where we were asked to make a game about “Lost Doorways” by the end of the day (7.5 hours). I planned to team up with a friend but he did not show so I was forced to improvise and meet people. Somehow we managed to build Purgatory: a simple arcade-style game where you must avoid enemies/obstacles and get to the door in a rotating room.

The whole experience was a blur, and I couldn’t believe it when we won “Best of Show”! This was my first hint… maybe I could be good at this after all?

Face the Music (Indie Speed Run 2.0)

High on the success from Gamecraft, I asked my Purgatory teammates Andrew Kelley and Anthony Nguyen to join me again for Indie Speed Run, an online game jam that generated a unique theme for each participating team. For this we built an action platformer called Face the Music, which attempted to convey “procrastination” (our assigned theme) via its mechanics.

However, sloppy platforming physics and a mismatched rock & roll theme (which came from the required element “microphone”) got in the way of our mechanics-driven metaphor. It was an early lesson in unification: the different parts of your game should all be working towards a common goal.

Corporate Pie (Indie Speed Run 2.0)

I managed to do Indie Speed Run a second time, this time with my artist friend, David Wallin. We made a puzzle game called Corporate Pie, where players attempt a “corporate takeover” of a literal pizza pie by strategically placing and removing toppings with different abilities. We were never quite able to solidify the core mechanic, so we were making huge changes all the way to the last minute, and the result was a bit sloppy.

I learned from this how important it is to find the fun in your core mechanics as early as you can. Otherwise, if you try and make everything click only at the last second, you run into the risk of never finding that fun at all.

Negative Space (Global Game Jam 2014)

For Global Game Jam 2014, I teamed up with David again and with another programmer Altay Murray, and we built an art game called Negative Space based on the theme “We don’t see things as they are we see them as we are”.

Once again I was making a game using mechanics as metaphor, but this time we did everything right. Our team had great chemistry, we had a fun prototype by Saturday afternoon, and I even had some opportunities to run around with my laptop and get feedback from external playtesters.

Our success in this game jam reinforced the hard lessons from earlier jams. Unlike Face the Music, everything from gameplay to aesthetics were all working towards clear goal of how different the world seems to an introvert and an extrovert. And unlike Corporate Pie, we found a fun core less than halfway through the jam, which gave us plenty of time to iterate on the delivery.

What I Gained

In addition to the lessons I learned from game jam individually, what did I gain from the overall experience of doing 4 game jams in 4 months?

First and foremost, game jamming gave me an incredible amount of confidence and validation. I went from feeling like a failure in September to a legitimate aspiring developer in January. It’s hard to quantify these qualities, but they absolutely contributed to my overall drive and willingness to take creative risks in 2014 and beyond.

Second, game jamming quickly set me up with a portfolio of several 1-3 minute web games. It was hardly ideal, but it was great starting point that I could improve on over time. And it turns out that short web-playable games gave me an edge, even over some large scope games that took many months or years to make, because employers are starved for time and do not want to download software of any kind.

Third, through game jamming I discovered that I had an affinity for level design. I was responsible for designing the levels for 3/4 of my game jams, and each time I had a blast and felt like I made a meaningful contribution.

Last, but not least, I discovered that I can code! I had a mixed relationship with programming at RIT, because I had a naïve understanding of what game design was, and it felt more like a graduation requirement than anything. But through game jamming it became crystal clear: programming enables iteration. And rapid iteration is integral to the game design process. So while on some level coding will always be a “means to an end” for me, I am fully capable of delivering production quality code, and I am happy to do so for the sake of improving a game.

Takeaways

What should readers take away from my experience?

Quite simply, game jams have incredible potential to jumpstart your career. When I go to meetups, I keep hearing aspiring indies and fresh graduates looking to break in complain about this catch-22: you need experience to get a game job, but you need a game job to get experience.

But game jams are, in part, a solution to that issue. Game jams require zero experience to participate and contribute. And they are probably the quickest method for an individual to build confidence, skills, and a portfolio of game prototypes. It may not be equivalent to industry experience to an employer, but it is very productive use of your unemployed time.

So if you are looking to turn things around and jumpstart your career, there is nothing stopping you. Go participate in a game jam!

Game Jam Resources

Regularly scheduled game jams:

  1. Global Game Jam (biggest jam, once a year – usually in January, sites around the world).
  2. Ludum Dare (online, worldwide from the comfort of your home, once every few months)

GGJ also has an amazing list of tools and resources to help you prepare for a jam. (Not that preparation is required).

 

Update: Moving to Rochester

It’s now official: my wife and I are moving back to Rochester, NY in late June.

This is bittersweet news for me.

Over the past 3 years I’ve made some amazing friends in the Boston game dev community, and I’ve had the honor of working with some incredibly talented people. It’s going to be difficult to leave such a thriving community full of passion and diversity. I don’t know if can get any better than Boston Indies, Boston Post Mortem, Boston Unity Group, and Mass DIGI.

And yet, this news is also incredibly exciting. In addition to meaning so much to my wife and me personally – Rochester is where we went to school, made lifelong friends, met, and fell in love – as a game developer I am thrilled to be entering the Roc Game Dev community.

Despite still being in Boston for another 2 months, I have been welcomed into Roc Game Dev’s Facebook/Discord with open arms. Active community members are warm, intelligent, and passionate about their work and about Rochester. There is real potential here for a game development hub, with the community, industry, academia, and even the state all aligned in this goal.

The transition has gotten me thinking a lot about what makes communities tick. Why and how is the Boston community so healthy? What are some of the unique challenges Rochester faces? What will it take to build out its industry?

It has also gotten me thinking: what role can I play? With a few years of game dev experience under my belt (and away from the community spotlight), I feel refreshed and ready to get involved. What skills and advice do I have to offer? How can I bring a little Boston with me back to Rochester?

I should mention that I am extremely fortunate to be keeping my job at Funkitron as a telecommuting game designer/programmer. I love my work and my team, and I intend to stay! But I can’t help but also think longterm about Rochester’s growth and my role in it. I’m ready to start giving back.

Scoping Smart

Whether you are a designer, producer, artist, or programmer, scope dominates game development. It drives decision-making on every scale, makes or breaks production, and defines the relationships between team members.

I find scope, and how we deal with it, fascinating. For the purposes of this post, lets call an the act of dealing with scope “scoping”, and someone who pays attention to scope “scope-minded”.

Scope and Timing

Attention to scope is primarily dictated by production schedule.

Being too scope-minded in the early stages or a project can be stifling to creativity. It can lead you towards safe decisions and prevent you from thinking outside the box. This is why a common rule in brainstorming is “no ideas are bad”.

Yet as we all know, it only takes the blink of an eye for optimistic blue sky dreaming to turn into nightmarish overscoping. It’s an easy trap to think “the more we can stuff in for the deadline, the better”, but refusing to trim down often results in a lower quality product that lacks focus. In addition, poor scoping can lead to crunch and taking shortcuts, creating new design and technical problems down the road that end up costing more time than you saved.

The key here is to not stress out from constant changes, and to recognize that scoping is a reality of game development.

That’s not to say consistent underplanning shouldn’t be addressed, but attempts to force-fit a waterfall production into what is by nature an iterative task, misses the point. The better solution is to facilitate the iterative process. (“Facilitating iteration” is a massive topic on its own, so I won’t go there today.)

In healthy teams, what emerges from this reality is a rhythmic ebb and flow that feels a little like breathing. The ideal is to breath in, absorbing all the ideas and possibilities, keep what is essential, then breath out the excess. It’s never perfect but you keep at it and improve with practice. This rhythm is happening on every scale – for the full project, for each major milestone, and for each sprint.

Scope and Roles

Attention to scope is also dictated by your role in a team.

Designers lean on the side of pushing scope. They want the best game possible, so they are incentivized to push scope to the edge of possibility. But this is a delicate dance, because an overscoped design will just result in a worse overall product. I imagine that many creative directors (or other stakeholders with creative input) have very little grasp of scope, and rely on producers and programmers to rein their vision in. But the most effective and versatile designers are constantly balancing an open mind with an eye on scope.

Programmers tend to be be the most scope-minded on a task-to-task basis. They are the most invested in keeping the foundation solid, and will most directly dictate the production timeline for a feature. Programmers may still be ambitious and may get excited by designs (after all if they’re here, they love games), but the best ones seem to always push for doing things the right way.

On larger scales, designers and programmers can only advocate for changes to scope. Someone has to make the tough decisions, which brings us to production.

In a small company, production wears multiple hats. A single person can be CEO, producer, creative director, and manager all at the same time. With so many responsibilities to juggle, all they can do is listen to the different opinions from the team, take into account their own instincts, and make decisions on a case-by-case basis. Key to success is being an all-rounder that lives in all aspects of development.

But as a company grows, production roles become more specific, and eventually someone’s primary role becomes “scope police”. In the worst cases, this can result in fiery battles between teammates and disastrous stalemates. But if the team members in these roles have chemistry, you can get a healthy role-driven push and pull.

For example: Suppose a Lead Designer identifies an issue with the design and pushes for a big change, only to get a no from the Producer. At this point the LD can choose to push for a compromise, or harder for his/her way. Meanwhile the Producer can choose to continue pushing back, or give-in after some time.

With trust and respect, both parties will pick and choose their battles carefully, resulting in a much higher quality game that neither balloons out of scope nor corners itself into major design issues. The process might sound exhausting but it can actually be liberating; the LD is free to be more creative and trust the Producer to rein things in, and the Producer can be more conservative and trust the Lead Designer to push for what really matters.

For me personally – as a designer/programmer hybrid in a small company – I find myself juggling hats. The programmer in me always wants to scope down, while the designer in me wants to consider every avenue. And while I don’t have decision making power on the very high level, I find that this dual mindset is invaluable to bridging gaps between team members, some of who live on extreme opposite ends of the scope-mindedness spectrum. Fortunately, I enjoy the challenge.

Applying Scope to My Life

As I am constantly immersed in scoping, I can’t help but be scope-minded in my life outside work.

Some ways I am scoping down right now:

  1. I will steer away from large scope blog post ideas (like the “Feedback Loops” series), and focus on off-hand thoughts for the time-being. Occasionally I might write a long post organically (like this one).
  2. I almost started a side game project with a friend, but realized very quickly that it was drawing time and energy from my main work, so I am shelving it.
  3. I will focus my research and learning a bit. In addition to critically playing games, and my daily habit of reading articles/listening to podcasts, I want focus on developing my systems design toolbox.

Soon enough, it will be time again to reevaluate my goals and start dreaming up the big blue sky for my free time. But perhaps – like in game development – this is all part of a natural ebb and flow, and I just need to let myself breathe.

My Fascination with Feedback Loops

On Monday, February 20th, I will be giving a short 8 minute presentation on Feedback Loops for Boston Indies’s February Lightning Talks. The presentation will be titled Fantastic Feedback Loops and Where To Find Them, and will focus on identifying feedback loops in games.

Feedback Loops can have a massive impact on a game experience. Yet they are frequently misunderstood by game designers, or worse, missed altogether. I hope to use this opportunity to help demystify this important topic, and give game designers some tools to deal with them.

But the complexity of this topic goes far beyond the scope of an 8 minute presentation. So I had the idea: what if I created a companion blog post to go further in-depth? With my blog carrying the crunchy systemic details, I can focus my presentation on being a fun introduction to the topic. This lets me serve multiple audiences (and my own curiosity) simultaneously.

I will be covering Feedback Loops in a three-part series:

  1. Part 1: Identification
    What are feedback loops? Where can they be found both in and out of games? What are the different types? How can you identify a feedback loop in your game?
  2. Part 2: Impact
    How do different types of feedback loops affect the player experience? Are they good or bad? How can they affect pacing, decision-making, and learning?
  3. Part 3: Dealing with Feedback Loops
    What do we do once we’ve identified a feedback loop? How can we effectively create, destroy, strengthen, and weaken feedback loops?

UPDATE 3/11/16: The lightning talk went really well! But the sibling blog post series is taking longer than expected. I have shelved it for now and will pick it back up down the road.