Agile Board Game Development
I've spent a lot of time in software. If you're interested in writing a board/card game, you can learn a few things about getting things done from software development. Top of the list is creating a mentality/method by which to approach what you're doing. I like to call this "Agile" board game development.
Let's call the time period from internal playtest to playtest a "sprint." In that period, you need to do three things: plan, write, test.
Planning can be the most important stage especially early on. Most folks think the plan is "write the whole game," but that's not realistic. Especially if your game is large/long/complicated. Your mindset for planning should be "the minimum I need to craft so players can interact with each other and the game." It's too easy to get lost with individual mechanics/details; if you try and take all of them at once you'll never get it done. In this mindset, the scope for a first "sprint" should be like: "minimum I need to write so that my players might play one or two turns of the game." Even that might be ambitious.
As mentioned in previous blogs, the human brain can only hang onto so many things at a time. A whole game can be a lot things. Break up those things in as small and as discreet tasks as you can. Pick a number of those things based on what your goal for the sprint is.
Example: Let's say you want to write a euro-style game about mutant agriculture/economics after the apocalypse. You want it to be Agricola-esk but where the peasants might take time to eat each other (peasants are yummy.) For the first sprint, don't take on the mutant peasants fighting each other. Keep it in mind as you plan, but the scope for your first go with playtesters should be the most basic places and resources needed so the players can sit down and help their mutants multiply.
Now that you picked a scope, peel off tasks. You need starting family size. You need places for them to go. You need a turn order mechanic. You need a resource to mutant birthrate relationship (which means you need to spell out types of resources.) You might want different types of mutants, but for the first scope keep to one type of mutant. This way you don't have to do mutant stats yet.
Some tasks can seem trivially small while others might be monumentally huge. The big ones should be broken up if possible. In our example, starting family size is simple/small while writing a number of places with individual mechanics can by huge. You might want to split the task of creating place and place mechanics over a few sprints (basically breaking it down into smaller tasks). Turn order could be either super simple or a critically deep part of a euro style game. Figure out which you might want for your game, but go simple early building the complexity over multiple iterations of your game.
[This post is more about method rather than "how to" so we kept the next two sections short.]
Writing is equal parts creativity and discipline. The golden rule for writing is do what you feel is fun and gets you closer to having something for people to play now. People can feel the fun you had while game-cobbling. While sticking to the plan, look for every opportunity to capture you own imagination. Honestly, if the stats/details/complexity of a game you're writing doesn't captivate you while you're creating it, it will crush someone who hasn't decided if they're interested in your project. When a new idea outside of the goal of this sprint pops up, write it down and save that excitement for the next go. Delayed creative gratification is a thing; it will get you to sit down and do more game stuff sooner.
Playtesting is a beast. It is the goal of every sprint to get your project out there and have people who aren't you to "play" the game the best they can with as little participation from you as possible (which isn't very possible at first). Getting people on board with a concept in process is difficult. It will take some time to forge a group of individuals who are onboard with that kind of experience. Bribery works: offer food and adult beverages. Find others who need you to participate in the same capacity. End the playtest when either the fun is done or you have enough feedback to start the planning process all over again.
The first tasks for your next sprint will be to fix what playtesting found is broken/unfun. After those things, next would to be add other components/complexity (like the different mutant races or mutant combat as in our example).
The entire point of this "Agile Board Game Development" is to create something that is fun and playable as soon as possible. Using playtest sessions to give you deadlines and valuable feedback while taking things in manageable chunks will help your project from getting lost in your head.
If you have questions about Agile Development or why I'm such a nerd, please like us on Facebook.
[This blog goes out to Alex who asked what I spent my time doing.]
