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.

Posted in Updates | Tagged , , , , | Leave a comment

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 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. And luckily for me, 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.

 

Posted in Development | Tagged , , , , , | Leave a comment

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.

Posted in Design Theory | Tagged , , | Leave a comment

Goals for 2017

My primary focus through 2017 will continue to be Funkitron and Cascade. But it’s important to me that even when I am off the clock, I do as much as I can to keep growing as a game designer.

So to kick off the new year, here are some of my game development goals for 2017:

1. Level Up My Game Design Toolbox

When I first started formally studying game design, I fell into the trap of obsessing over critical language. I searched for and asked community leaders to point me to a “Game Design Dictionary”, and offered to organizations like the IGDA Game Design SIG to help build one. At least one experienced designer said I should slow down, explaining to me that critical language is an organic Darwinian process that cannot be forced. But at the time I was frustrated at what seemed like a lack of tools, so I ignored the advice.

As it turns out, overthinking highly subjective semantics is a very inefficient way to learn. I should have taken that advice. Like designing games itself, it makes much more sense for me to jump into the creation process, borrow any tools available, and rapidly iterate on my own personal Game Design Toolbox as I go. I consider a toolbox a set of handy design concepts that I can apply direct to my work. Unlike a dictionary, the primary focus is on function over meaning.

One clear method to level up my toolbox is to expand it. I will continue my search for new tools by trying new games, reading articles/books on the subject, and in general exposing myself to everything life has to offer.

But the bigger the toolbox gets, the more it needs to be organized. So as I iterate, one of my goals will be to put the weaker tools on the bottom, the handy tools on top, and my trustiest tools on my tool belt. In practice, this looks like a curated collection of notes in google docs and spreadsheets, with links to more detailed sources. As it evolves, it may become more of a tree or web, and I may explore new ways to access the information.

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

2. Shrink My Games Backlog

It’s very important to me to as a designer and gamer to play a wide variety of games. I want to try classics that have shaped today’s landscape, to play innovative games that took risks, and to keep up-to-date with modern games and trends. And I do not want to be tunnel visioned by my natural preference towards certain types of games.

But to really make a dent on my backlog, I need to accept that cutting games from my list is always good, and that it’s never too early to move on from a game that isn’t giving me anything useful.

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.

3. Tinker

As a healthy creative outlet and to keep my rapid prototyping skills fresh, I hope to spend some of my off-time this year creating mini concept prototypes in HTML5 and Unity.

Tinkering is important to me, because it lets me take weird creative risks that I cannot easily get away with in the constraints of my professional work. It lets me answer lingering questions, and introduce me to even better ones. It helps me clear my head and kill my darlings.

And on the physical side, tinkering lets me practice my rapid prototyping skills and stay fresh with game making tools. Which never hurts!

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

4. Get Involved With The Community

Since leaving Playcrafting in late 2014, I have spent the last two years with my head down, focusing entirely on my work. As a result, I have become relatively recluse, missing out on many Boston game community events.

But now that I feel that I am hitting a comfortable rhythm in my career work, I want to get involved again. I am starting to see that even as a young designer, I may have valuable things to offer to others such as advice and encouragement to recent grads and indies trying to break in, and maybe a fresh optimistic perspective to the vets.

I don’t know what form this will take exactly, but it could include speaking engagements, teaching, event planning, and more. To start, I will be giving a short 5 minute presentation for Boston Indies February Lightning Talks.

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

Leaving 2017

These are some meaty 2017 goals for the year to accomplish on top of my career work (and on top of a social life and marriage), but they are all crucial to my growth as a person and as a game designer.

At the same time, although I’ve defined success individually for each goal, overall success is much more flexible. These goals won’t change me overnight, but help shape the kind of designer I will be long term. So even if I land below the 50% mark, I will consider that an overall success. And I expect all four of these goals to come back in 2018 regardless.

Cheers to a great 2017!

Posted in Updates | Tagged , , , , | Leave a comment

Really Bad Theming

reallybadchess_01

I’ve been playing a lot of Zach Gage’s Really Bad Chess in the past week, and I find myself very fascinated by its use of theming.

Gage goes to great lengths to reinforce the “Really Bad” theme. Some examples:

  1. The Title
  2. Marketing text like “A definitely balanced game.” and “For everyone who quit playing chess”
  3. Quotes from Gage ranging from “This could be perceived as an affront to chess” to “It’s a stupid game”.
  4. An art style that goes beyond minimalistic; it looks like placeholder art that never got replaced.
  5. Somewhat awkward UI layout (examples: awkward line breaks in the title, no visual priority in coloring/shading)

It’s sort of sneaky and unassuming, but I think this theming accomplishes a few key things for the game.

The Impact of “Really Bad” Theming

1. It’s Inviting to “Really Bad” Players

To start with, the theme lends a helping hand to anyone who feels like they are “really bad” at chess. Chess is so embedded in our culture that it’s hard to make it to adulthood without playing a few games. And since Chess skill is often perceived as an indicator of intelligence, it follows that players who struggle might feel bad about their ability on a personal level.

…which is a bit sad, because who can blame anyone for stopping at one of Chess’s huge learning spikes, particularly the ones that involve lots of memorization? Or for being discouraged by crippling defeats, which is common with such potentially wide skill gaps? Players have no reason to feel bad, because their struggle often stems from inherent flaws in Chess itself rather than incompetence.

But the frustration is there, and Gage’s theming capitalizes on it to great effect to create an “us vs. them” feeling.

2. Players Are More Forgiving of “Really Bad” Flaws

Like any Chess variant, it’s impossible not to compare and contrast to the original subject matter. How could anyone compete with such a monumental game? But here the “Really Bad” theme offers a bit of humility – which in turn makes players more forgiving of the game’s flaws. Compare that to David Sirlin’s naming of Chess 2, which I wouldn’t call arrogant but certainly elicits a different emotional response.

A little more subtly, the “Really Bad” theme calls attention to its randomness as a direct counter to Chess’s near-perfect balance. In an era where many gamers still see luck as the opposite of skill, and designers regularly underestimate and misuse randomness (see: No Man’s Sky), it’s no wonder that randomness gets a bad rep.

The designer in me hates this misconception, but I can’t help but be impressed at how Really Bad Chess leverages it. It seems to apply imply “randomness indeed makes this game worse than the original chess, but that’s okay because we’re all in on the joke”.

3. It’s Not Bad At All!

Underneath it all, perhaps what makes the “Really Bad” theme so clever is that ironically, there is nothing really bad about the game at all. It’s not without flaws: the AI is painfully slow, the blue bar is confusing, and there could be better messaging for your turn state. But counter to the theme’s suggestion, the use of randomness in Really Bad Chess is exactly what makes it so damn good.

Really Bad Chess’s randomness does a great job of eliminating the reliance on book learning and putting the focus back on emergent strategy. But what really makes it shine is the rubberbanding system in Ranked mode, which determines your piece distribution. For example since I am hovering around Rank 75, I can expect lots of horses, a few bishops and/or Rooks, and maybe 1 Queen (and I can expect my AI opponent to have at least 2 Queens). It’s just enough of a constraint to prevent the game from feeling too random. And when combined with the promise of a static AI level, the result is a systemic learning that does for my Chess fatigue what Spelunky did for my platformer fatigue.

Of course none of that systemic depth comes from the theming. But when the press says things like “Who knows, that’s the point of Really Bad Chess, it throws out the balance in the game for random chaos!”, I get the impression that maybe the depth is sneakily slipping its way in for some players… just under the cover of its “Really Bad” Theming.

Takeaways

I think the major takeaway here for designers is to not underestimate the power of theming.

Really Bad Chess is not the first Chess variant to randomize pieces. It may not even be the first to combine randomization with rubberband ranking. But its unique theming invites players of all skill levels, highlights its randomization in a fun lighthearted way, and cleverly hides a strong focused design with satisfying depth.

It’s the combination of strong gameplay and intelligent theming that makes it worthy of some extra attention in my opinion, regardless of how much of its success might be attributed to outside factors (such as Gage’s existing reputation and network).

And nothing makes me happier than a great design getting love. So I wish it the best!

References:

  1. Really Bad Chess Press Kit 
  2. How Zach Gage breaks all of the rules in Really Bad Chess” (Gamasutra)
  3. Zach Gage’s ‘Really Bad Chess’ Will Shake up Chess on October 13th” (touch arcade)
  4. Really Bad Chess makes chess fun even if you’re really bad” (The Verge)
Posted in design analysis | Tagged , , , , , | Leave a comment

Fall 2016 Status

I’d like to get this blog going again. It feels appropriate to start with some professional updates. Who am I today professionally, and how do I intend to use this blog?

Career Status

As of this writing…

  1. I am a Technical Game Designer at funkitron, inc. I am currently working on the casual match-3 slots game Cascade.
  2. I have a couple of years of game design and game programming experience under my belt. I have also shipped a few games.
  3. For a mixture of personal and professional reasons, I have moved on from the indie project Brain & Brawn. I still have a strong friendship with my ex-partner David Wallin, who will be continuing the project on his own. And I wish him the best!
  4. I am based in Boston, and am mildly active in the local game dev community. I try to attend meetups at least once a month so I can stay in touch, but am no longer running events like I was in my Playcrafting days.

Overall I’ve had some great fortune in my early career, and things are looking bright for the future.

This Blog

The primary goal of this blog is to explore my thoughts on game design.

I’m very fortunate that my work lets me flex my creative muscles on a regular basis. But there’s a huge mass of questions and ideas in my brain that don’t get answered in the scope of my work. My hope is that in writing, I can process some of those thoughts.

I expect future blog posts to span a wide variety of topics. I may want to do postmortems on past projects, break down one-off experiments, speculate on theory, or even dissect a specific feature or system in a game.

It’s hard to say how things will evolve, since I’m depending on my brain to unravel and respond to both the changing industry and my own growth in realtime. But what I can say with certainty is that I’m looking forward to the journey.

Thank you for reading!

Posted in Updates | Tagged , , , , | Leave a comment

Brain and Brawn – Dev Log #2: Catching Up

After a 6-month hiatus to do game design for Demiurge Studios, I have returned to Brain and Brawn to finish the game.

During my absence, David was able to make two major updates. The first is a graphical overhaul! The result is a clean look with a slightly angled perspective that gives depth to the world. The improved graphics also do a better job of communicating the workings of different mechanics.

Before and After

Before (left) and After (right)

The second major update that was a long time coming was the switch from a physics-based system to grid-based system. This change is huge because it allows us to easily separate game logic and visuals, which opens the door for dynamic tweens, animations, and particle effects. The difference is outlined below:

Old System (physics-based): New System (grid-based):
  1. Did the player do input? (swipe/arrow keys)
  2. Accelerate player sprites in that direction
  3. Every frame, check to see if brainy or brawny sprites are colliding with another game object
  4. If a collision occurs, resolve the collision.
  1. Did the player do input? (swipe/arrow keys)
  2. Based on the grid layout and desired direction, what should happen? (cell collision)
  3. Animate all of the things that are supposed to happen?

The only down side is that we lost some features in the transition that will have to be reimplemented. These features include the HUD (with move counter), sound effects, dynamic level centering, and some pretty cool debug cheats, but they will be back and better than ever in no time.

Tomorrow, Brain and Brawn will be casually demoed at the Boston Indies Demo Night, where I hope to get feedback on 4 brand new mechanics and a Level Editor I created. Check back soon for more info on those new features!

Posted in Brain and Brawn | Tagged , , , , , | Leave a comment