Dennis Piatkowski

Both game veterans and newbies start with the very same blank page. Even for me, a veteran developer, starting a new project is a daunting task. The difference is that I have the experience to realize what to focus on first.

Except I was completely wrong. I’m building a simple board game, based on a really neat article on simple ways of calculating things in a hex grid. So my first instinct was to start implementing that knowledge as a utility class. Which, in itself, is perfectly reasonable. But then I realized I was writing and testing utilities I’d probably never use!

This is a very common issue at any point during development. You have this idea you want to convey to the computer, but don’t really have a firm design in mind. Writing some code just to fill a page is still a useful tool, so use it. The problem is that many people get stuck far too long in this phase and not step back to re-examine what you really need. In my case, I spent an evening on that utility class. When I stepped away, I realized that was further than I needed to go. (Reminder, there is a strong case here for taking breaks often. You never know what will occur to you when you step away for a minute.)

So now what? You’ve written one utility class. It’s time to sit down and think about how you plan on designing the code for actual game. You may have already worked out the rules of the game, but there is a huge difference between knowing the rules in a human understandable way and coding those rules into a game.

It is here that you should now be focused on. Design the rules of the game and design the code that will implement the rules of that game.

Recently I was approached by a small group who are at the nascent stage: they have an idea. Better, they put together a top level view of what the game should be. By this alone they have already surpassed most people’s aspirations toward game dev.

Their background was in business software, not games. Why is it so different? In business, if you’ve worked out what the “customer” wants and deliver even close to it, you will succeed. In games however, the “customer” does not tell you anything about what they want until after you’ve built and shipped it and hoped that the “customer” likes it. The developer must guess every part of the design on their own. This can be informed by many means, but it doesn’t change the fact that at the end of the day, you only have your best guess to go on.

So began my involvement. I quickly learned that this group had never done game dev before. They had a few broad strokes down, choosing a game engine and beginning to learn it. It occurred to me that they were starting from (almost) zero and shooting for a AAA title on the first try. I was reminded of a different group the year before who had attempted exactly this. We haven’t heard from them since.

It’s amazing how comic artwork operates. It’s simplicity takes our greyscale, muddled color world and simplifies it into a shining example of a single concept. It was this bit of brilliance from @BaconAndGames that flashed through my mind.

Based on this, I offered them a game plan. Don’t shoot for the moon on your very first try. Instead, break down the game into component pieces and make games from each piece. The eventual goal is that by the time you have make the full game, you have learned what works and what doesn’t for each of the component parts.

The first step is to create the complete game design. Definitely shoot for the moon. Then break it down into component parts. Some parts will be technical abilities, like communicating with a server for profile information. Most parts will be features of the final game, for example a time-based recharge system. For each part, you build a completely separate game. Each game must be completely separate branding from your final game. This way if one of the separate games fail somehow, it does not tarnish the reputation of the final game.

Another golden piece of advice is this: shipping something is always more useful than spending 5 years and having no product to show for it. It would appear that breaking up your game you would be going farther away from your goal. But in fact you are accomplishing these goals:

• Learning about game development
• Learning about your audience
• Shipping something
• Making investors happy
• Building a reputation as a developer
• Building your game

Yes, you really are building your game in this process. Because as you write these secondary games, you write the code in a reusable fashion. When it’s time to build the full game, the code is already (mostly) there.

By the time you are ready to build the full game, you won’t be looking at a mountain. You’ll be looking across a short bridge to the game that used to look like the moon.