Monday Musings: The Work Must Flow

    Welcome to TwistedSpoon Studio! This is the first article in a series I'm calling Monday Musings, where I ramble about whatever game design topic is on my mind and, hopefully, turn it into practical advice for you. This week, the topic is work flow. When you're approaching a new project, it can be daunting to figure out where to start. Every designer has their own methods, but there are some best practices that apply to any project. Below I'm going to outline my own process, but don't take it as set in stone-- feel free to adjust it for your own needs and the needs of your game.

Time Sieve by Franz Vohwinkel

Pre-Design

    Pre-design is exactly what it sounds like-- it's all the stuff you have to do before you start designing proper. For my money, this process has three broad steps: Exploration, Research, and Planning.

    The order of the first two steps will vary depending on whether your project is top-down or bottom-up. For a top-down design (starting with flavor), you want to start with Research. For bottom-up (mechanics first), you want to start with Exploration.

    Research is often overlooked as an element of game design, but it's a powerful tool. Let's say that you want to make a game about spiders. You know what spiders are, but you'll probably find that you run out of things to design around pretty quickly. Sure, they have eight legs and eight eyes and they spin webs, but how much content are you going to get out of that? Once you start looking into it, you'll find out all sorts of things that you didn't know-- like the fact that orb-weaver spiders spin their webs in the morning, tend them all day, and then eat the entire thing every night. On the other hand, spiders like the infamous black widow do not, allowing detritus and debris to build up over time. This kind of information can contribute to your mechanics, like resource systems. You can base your balance off of real-world data-- in a game about trees, maybe you use rainfall data for a real-world region. In a fantasy tactics game, you might research what weapons and armor were available in a specific era. (6th century AD, anyone?) This might inform your flavor, mechanics, or both. It's also just really fun to dive into a topic that interests you. 

    You can also treat research as a form of "scouting" mechanics for your projects. If you're building a map-based game, you look into play Risk, Ticket-to-Ride, and Pandemic to find different approaches to building your engine. If you're making a casual card game, you might analyze games like Ramen Fury and Mashup to find different perspectives on cards as components. If you're making a digital game for PC, console, or Mobile, you might research other games to figure out how to structure your code. Resources like tutorials and GDC talks are invaluable for this type of research. It also helps to have a list of designers whose games you admire, because that makes it much easier to find interviews and other content where they discuss the inner workings of their games.

    Exploration, on the other hand, is all about experimentation. If you have a cool idea for a mechanic or a game engine, the only way to know if it's any good is to test it. Start with the minimum viable product-- the smallest possible version of the thing that you're making that still feels like the thing that you're trying to make. For a platformer, this might be the basics of platforms, jumping, and maybe an enemy. For a card game, this might be just a few cards of each type (in Magic, for example, you might make some creatures, sorceries, and lands). If you have components from other games, those make for a great testing ground-- whether it's using a checkers board and DnD minis to test a tactics game, playing cards with index cards in penny sleeves for a card game, or a Risk board and dice for a war game, anything goes. Glass beads and toy soldiers from the dollar store are your best friends here. Don't get hung up on production value or complex mechanics-- visuals take a lot of time to polish, but they can easily be obsoleted by mechanical changes. When I first prototyped Quantum Reflections (there will definitely be an article about it in the future), it was made of poster board, marker doodles, and toothpicks. If you're working digitally, don't be afraid to take advantage of other people's code-- for example, Unity comes with templates for a basic shooter game that you can tweak for your FPS concept. If you can, get other people to play it too-- it can be hard to judge your babies, but seeing your friends play it will give you a great deal of insight into the fun of your game.

Once you've figured out what your game is about and whether it's any good, it's time to start planning. The first step to achieving a goal is to set a timeline. You never really know how long it's going to take, but if you take into account the amount of time that you have to work on it, you can set reasonable goals to complete it. If you only have an hour a week to work on your project, your game is going to take a lot longer than it would if you were working on it full time. If you're working with a team, you can cut down your dev time by delegating tasks. Here's a tip from the Computer Science world-- take your estimate, and multiply it by 1.5. If you think your game will take a year to make, plan for it to take a year and a half. You don't know what you don't know, and Murphy knows a thing or two about delays.

With your research, prototype, and plan in hand, it's time to move on to design!

Design

    Design is the meat of the process. During this stage, you want to iterate on your design and playtest it as frequently as possible. Early on, your focus will be on the core engine-- the base rules that apply to every piece of the game. A common pitfall is to go too complex, too fast. The problem therein is that every part of your game interacts with every other part-- so small changes can ripple out into unintended consequences that send your game toppling down. (If you're designing a Jenga variant, that might be the desired outcome. In that case, go ahead?) The key is to playtest, collect feedback, and tweak. 

    Once you're happy with the core engine, you can start designing content. Content is any part of your game that can functionally be replaced by another object. Think of the weapons in a shooter-- a pistol and a shotgun work very differently, but functionally speaking, they're both guns. The have ammo and they deal damage to a target or targets in range; every variation on that formula is content. The same is true for things like enemies, rooms in a dungeon, cards in an event deck, et cetera. If the specific qualities of the object are not inherent to its role in the game, it's content.

    This is what I mean by too complex, too fast. If you have sixteen variations of swords, each designed with different damage types and special effects, you're going to be very sad when you get feedback that combat isn't fun and you have to retool the combat system. It also muddies your feedback-- is it the system that's busted, or some of the items? If you change the health of an enemy, you've suddenly altered the balance of every weapon, because the ratio of damage to health is different. 

    While you're iterating, it's also important to keep track of changes. If you make tweaks and the feedback from the next playtest is that it's less fun, you'll want to be able to revert to the previous version. For digital games, this means using tools like GitHub to save multiple builds. For tabletop, this means keeping good documentation on every iteration. One of my first games, a sci-fi deckbuilder called StarPG, is literally unplayable despite having a full prototype because I never wrote down the full rules. Don't make the same mistake.

Development

    The difference between design and development is like the difference between a blueprint and a house. Design is coming up with the rules, the content, the mechanical framework that makes the game run. Development is taking that body and putting some paint on it. This is where you want to add some pizzazz-- creating final templates for your cards, adding flashy animations, prettying up your tokens and components, all that jazz. During design, you were using bare-minimum mockups-- just enough sauce to get the flavor across. During development, you're adding juice. Gameplay generally trumps aesthetics, but a pretty game will catch more eyes. Plus, pleasant pieces can help immerse players in the experience. Sure, I can accept that these glass beads are money, but if they were printed cardboard coins, I wouldn't have to. They would just be money. 

    A great way to practice polish without having to complete an entire project is to participate in game jams. Whether its tabletop or digital, game jams are a great opportunity to get experience without spending months on a project. You can innovate in a low-stakes environment, or you can build something more familiar and put a ton of effort into making look and feel appealing. There's no failing as long as you finish-- you're always going to learn something, whether it's coding, design, art, or even just project management.

    Keep in mind that the sky may be well above the limit here. If you're producing your game commercially, components are the primary factor in determining the price. A card game is much cheaper to produce than a board game; cardboard is cheaper than plastic is cheaper than wood or metal; and the more that the stuff in the box weighs, the more it's going to cost to ship them. For digital projects, you're constrained by the graphical capabilities of your target demographic, and the ability of your tools to implement those features. Particle effects can consume a lot of processing power, and online functionality depends on your player base. And that's without taking into account the amount of time and effort it takes to create and animate models for your game. There are tons of GDC talks about getting the most bang for your buck with limited graphical capabilities or artistic manpower. 

    I can't offer any advice on getting a game published, but the internet is full of resources.

    That's all for today. What does your design process look like? How do you plan your projects? Let us know by messaging me at u/DefyKnowing on Reddit, commenting below, or using the Contact Us box at the bottom of the blog!

    Coming up this Friday is our first look at FUR in the new year, introducing a familiar new mechanic to the world of Urbestia and a new focus for the setting. Next Monday, we'll be looking at ways to use math to create an objective basis for balance in your games. Until then, check out my interview with one of the designers of Bioshock and more here, or find out why I decided to soft reset my current project, Festival of Urbestia, here.

See you soon!