212: How To Start Building a Video Game. Part 2.

How do you make your idea more specific? It’s hard to make progress on a vague idea. This reminds me of a popular book called Getting Things Done that says we don’t work on projects, we work on tasks. If you have a lot of unfinished tasks on your do-to list, maybe it’s because they’re not actionable. It causes us more stress and internal struggle when we keep reminding ourselves about these projects but don’t take the time to list out the actual work needed. The same thing applies to programming. Building a game is hard enough. You don’t need to add more problems by continuing to think of it as a single task. Listen to the full episode or read the full transcript below for more examples and some advice for knowing when you’ve reached a level that can be coded. Transcript I like to use game development in a lot of examples because it’s fun and helps keep things interesting. You can use the concepts I’m explaining here for any type of software project. This episode will give you some tips for making your idea concrete. That’s just a way to say an idea is specific. It’s hard to make progress on a vague idea. This reminds me of a popular book called Getting Things Done that says we don’t work on projects, we work on tasks. If you have a lot of unfinished tasks on your do-to list, maybe it’s because they’re not actionable. One example from the book was cleaning the garage. Is there a specific action you can take that will result in a clean garage? If so, then that should be your task. For example, sweeping the floor is something you can do. Most likely, you’ll need to do several things. By being very clear about what those things are, they become actionable. And some actions might depend on others. Maybe you need to buy a broom before you can sweep the floor. It causes us more stress and internal struggle when we keep reminding ourselves about these projects but don’t take the time to list out the actual work needed. The same thing applies to programming. Building a game is hard enough. You don’t need to add more problems by continuing to think of it as a single task. You might hear some people say that you need to create a game design document or GDD for short. My opinion is that’s not very agile. It might work if you’ve built a similar game before. But for most of us, we need to accept that things will change because we don’t have all the answers at the beginning. Spending time writing a document can be valuable but it’s hard to avoid working on a design that will later be thrown away because it’s not needed anymore. If you do create a document, then I recommend keeping to just one or two pages at first. Programming in many ways is more of an art than science. It’s not at all like what a civil engineer goes through when designing a bridge. If you try to enforce a document just because you’ve spent so much time on it, then you’re falling victim to the sunk-cost fallacy. I’ve mentioned the sunk-cost fallacy before. Listen to the QA Friday episode from 2016-Jul-22 for more information. When I started the text-based game, I knew that there would be a map of some kind. It’s a top-down game so the view always needs a map. Now, thinking terms of a map is like thinking about cleaning a garage. Even this is too vague. You can’t program a map. So I started listing out what could appear on the map. At first, this was a jumbled mess of ideas. That’s actually a good way to start. Just get everything written down that you can think of and then start looking for patterns and similarities. This led to questions like: • Is there any difference between a forest and a bunch of trees? • What about between a road and a path? • Should I call something a desert or just show a bunch of sand? • Is there more to a town than just a bunch of buildings? • How will the game deal with unk