A bog is normally thought of as the mess that accumulates along riverbanks, at the edges of lakes and other waterways that are more muddy mess than anything else, but in this case the BoG is a way through the mess that is the game industry. \u00a0Welcome to the Business of Gaming, a regular column for aspiring designers that are looking at self-publishing an idea through kickstarter or other crowd funding solution. \u00a0The goal of the BoG is to inform designers on the best practices in the industry as well as common pitfalls that Gamer Nation Studios may or may not have suffered along the road to publishing our first three titles.<\/p>\n
You have a big idea, now what?<\/strong><\/p>\n Well, first things first. \u00a0Don’t get ahead of yourself. \u00a0If you have a concept for a game, the first thing you do is research to see if anyone else has done it before. \u00a0Say you have a great idea for a board game that relies on a card drawing mechanic to create a network of distribution for trucks. \u00a0Each player also draws delivery routes to connect their trucking network that are worth different dollar amounts, and at the end of the game, the person with the most valuable route wins. \u00a0It’s a good idea! \u00a0In fact, it is so good that Days of Wonder called it Ticket to Ride, and instead of trucks, it uses trains. \u00a0Boardgamegeek.com is a great research tool for researching game mechanics and themes, and I know this is a simple premise and almost insulting to say, but there is a reason why technical support always asks if the computer is turned on and plugged in before they begin to help callers.<\/p>\n Work on a playable copy – and keep it simple.<\/strong><\/p>\n Assuming the idea is not a reproduction of another game already in production, this is where the rubber begins to meet the road. \u00a0First things first, know the rules to your own game! \u00a0There is no way to accurately begin testing a game if the designer is not 100% solid on the rules. \u00a0Unless you are a board game savant, your first test will not go the way you planned or envisioned when you wrote the rules to the game. \u00a0Resist the urge to change any elements midstream, as any variable changes just invalidates the test case. \u00a0If you apply a quality assurance methodology where a single test case is applied at one time and no more than one variable is changed, this helps understand what changes are making the most impact but it also takes the most time.<\/p>\n Another approach is to take a more iterative approach and run a test, make several changes, run more tests, make some changes, and reevaluate as the title begins to take shape. \u00a0Remember, this method requires very accurate record keeping and feedback tracking from playtesters. \u00a0Over time, the game will either prove to be a great idea, or it will prove to be a good idea that does not quite have the steam to make it.<\/p>\n Never throw good money after bad.<\/strong><\/p>\n If your game turns out to be a bit of a dud, do not fear, many designers before you have abandoned projects and many more will. If there is a time that the game does not feel like it will take off, take a step back, have someone give you honest feedback, get a second and third opinion, put your emotion aside and don’t be afraid to walk away before you sink more time into a project that is not getting favorable reviews. \u00a0At this stage, consider time equal to money, and the more time you spend chasing a bad idea, the more time you waste before you get to the good idea that is rattling around up there in that noggin.<\/p>\n Next time, we will explore how to write rules, create prototypes and formulate a test plan.<\/p>\n","protected":false},"excerpt":{"rendered":"