Like anything, the only way for me to get better at blogging is to practice. But I am often hesitant to publish new posts because writing is a challenge for me, and I am self-conscious about my website which also serves as my portfolio.
So as a temporary solution, I present a pinned Directory of Posts! Here is a list of my higher quality stand-alone posts:
Game Design podcasts are a fun way to learn about game design while driving, taking the train, or exercising. Here are some game design podcasts I have really enjoyed (and have taught me a lot) over the past few years:
Another Castle was my first podcast, which I fondly remember listening to on the E and F trains in NYC. It has a wonderful “New York indie” vibe to it, with a each episode focusing on a single game designer and their work. Guests lean either indie or academic, but there is a nice variety of perspectives and the discussion is strong.
Highly Recommended – especially if you are an indie or love the indie universe.
A long-running podcast, The Game Design Round Table is hosted by video game designer Jon Shafter (lead designer for Civilization V) and board game designer Dirk Knemeyer.
Episodes span from discussions around the hosts’ current work, specific topic explorations (eg – “Experience and Replayability”), and interviews. I like that with each topic, Dirk and Jon bring different perspectives from the tabletop and digital worlds, respectively. With their combined experience, the hosts also serve as a strong authority on how to design quality strategy games.
I must admit that I stopped listening toThe Game Design Round Table after a few dozen episodes. The podcast can be meandering at times with tangents, additional hosts all talking at once, and not enough time on the actual specified topic. However it is strong overall, and I intend to return.
Recommended – especially if you are more digital-focused like me, because the lessons from Dirk/tabletop gaming will change the way you think about your work.
Designer Notes stands out because it has such clear focus. In each episode, host Soren Johnson (lead designer of Civilization IV) interviews a single designer, and dives deep into their life experience and journey through game development. There are a few overlapping guests with Another Castle or The Game Design Round Table, but Designer Notes generally goes more in-depth.
It can get very personal at times, such as Amy Hennig’s war stories on crunch, or Chris Avellone’s heartbreak leaving an IP he loved. But it always serves a larger theme of how the road to design is never straightforward.
Very Highly Recommended – especially if you, like most of us, are still figuring out your path in the creative world.
In Drive To Work, Mark Rosewater will riff on a topic, telling stories and giving lots of great examples, all during his roughly 40-min commute to the Wizards office.
I initially avoided Drive To Work, because it’s very intimidating with its 400+ episode count and its focus on Magic: The Gathering. I thought that I would be unable to enjoy it because I’ve only casually played MTG a few times in my life.
But it turns out if you avoid episodes named after sets or blocks (which are the most hardcore), then the remaining episodes are surprisingly accessible, and full of juicy design lessons.
Many of the accessible episodes can be grouped into the following categories:
General Game Design & Psychology (eg – “Randomness”, “Psychographics”)
General Magic Card Types (eg – “Creatures”, “Artifacts”, “Lands”)
General Magic Concepts (eg – “Bad Cards”, “Rarities”, and my favorite three episode trilogy – “The Trading Care Genre”, “The Color Pie”, and “The Mana System”)
Development & Process (eg – “Codenames”, “Development”)
History (usually named after the year, eg – “1995”)
The system isn’t perfect. Every now and then I will start an episode, then realize after a few minutes that it’s too hardcore or just not a topic that interests me. But most episodes are great, and some are enlightening.
It helps that Mark Rosewater is an fun and enthusiastic host, who delivers his content like a storyteller. And because of his experience – leading one of the most successful games of all time – his words carry extra weight.
Highly Recommended – especially if you are interested in systems design. It requires a basic understanding of MTG rules, but you can avoid episodes named after sets/blocks if you are a casual player.
I hope to find some more great game design podcasts. I tend to avoid those that don’t involve at least one experienced game designer, because they often cover very broad topics (like “what is a game”) with little depth.
I’d love to see podcasts that focus on or feature designers from:
Other AAA genres (sports, action, adventure, narrative etc.)
Mobile / F2P game design
If you have any suggestions, please comment below or reach out to me on Twitter!
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:
My game jamming experience is just one of many factors that helped me get started.
Game jamming is not a guaranteed path to success. Like anything, results will vary depending on approach, timing, and luck.
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.
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!
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.
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?
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.
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.
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.
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:
Global Game Jam (biggest jam, once a year – usually in January, sites around the world).
Ludum Dare (online, worldwide from the comfort of your home, once every few months)
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.
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:
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).
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.
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.
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:
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?
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?
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.
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.
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.
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.