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 unknown areas such as a cave that has yet to be discovered?
Now, I like to think that I’m fairly well versed in the sorts of things that might appear on the game map. I mean, I’ve read more fantasy and adventure books than I can count, I’ve played board games and video games that are similar, and I’ve been planning this game for quite some time already. I thought this should be easy. But for something so easy, why has it already taken more than a week for me to figure out how the game will deal with the map?
That’s because even this one small part of the game is actually a large project and we think of more and more details when we stop thinking of the whole and focus on breaking it into smaller pieces.
To give you an idea, I want the game to be able to zoom the view of the map in and out. How will the zooming work? When will a single tree become visible or fade away?
I started out with just a bunch of ideas for what the map would show and quickly divided this into two lists. One for stationary things like a tree and another list for things that can move around like a wagon.
Then I started thinking about the zooming and how would it allow the view to start from a big picture and zoom into a single square. That suggested odd numbers should be used for the zoom levels. For example if the map is currently zoomed all the way in for the most detail, and the player zooms out one step, then maybe I could collapse all the squares around a square into a single square. That means instead of going from individual 1 by 1 squares to 2 by 2 squares, I would skip the 2 by 2 and go straight to 3 by 3 squares. Zooming out another step would then go to 5 by 5 squares being represented by a single square. I later changed this design but the current design is not far from this.
Another thing I had to decide was what area a single square would represent. I settled on a square meter per square. I liked this because it’s close to a single stride a person takes when walking. And if two characters are standing next to each other, then they can be in adjacent squares. Most things that I can think of in the game will occupy no more than a square meter including things like a door.
I still need to figure out how to handle objects that require more than a single square. Because this game uses text, it can’t just draw a large object such as a ship or even a horse as actual size. Everything needs to be represented with text characters. I might use multiple squares or a single square with a buffer.
The point of all this is for you to understand the level of detail you need to get to when programming. Yet at the same time, you need to understand higher level similarities. For example, the game will have several different kinds of trees. I listed each different kind of tree to be specific. But I also recognized that they’re all trees. So I’m planning to have a single character that can represent all trees in the map. Then there will need to be some way for the player to select a particular tree to get more information such as its type. If this was a graphical game, then each type of tree could be drawn on the screen with a unique style. Taking that same approach with text would mean there needs to be a different letter used for each type of tree. The map would get too full of different letters that it would be hard to visualize.
How do you know when you have enough detail? The way I do it is to list out as many things as I can think of until the design is obviously over complicated. Then I go back and try to simplify things. Look for anything common between ideas that you can use to draw out concepts that your code can use.
For example, I want the map to have some areas covered in snow. And maybe put some fog around the edges of lakes. Does that mean there needs to be a map type for snow or fog? Initially, that was my idea. But then I started asking what would happen when the snow melted or the fog lifted? There needed to be an underlying terrain type that could be exposed. That led to the idea that snow or fog were not really types of terrain. They were attributes that could be applied to other terrain types. So there could be snow covered grass or foggy trees.
Once I thought about it this way, then I no longer needed a terrain type for mud. This could just be wet dirt. Looking back, it’s almost comical. Of course mud is just wet dirt. But it took me a week to arrive at this conclusion.
When your ideas start to fall into place like this, then you can be fairly certain that you have something you can start coding. That doesn’t mean your design won’t change. But you should at least be going in the right direction.
I’ll end with a final thought. Do you think you could learn to be a plumber by studying the pipes in your house? Maybe, but you really should consider working with a plumber to learn the trade. Do you think you could learn how to fix cars by going to car shows and looking at all the engines while the cars have their hoods up for the show? Maybe, but you should again consider working with an auto mechanic to learn the trade. And the same thing applies to programming. If you want to work with a programmer on a real project, then consider supporting the podcast on Patreon and selecting the reward level that allows you to participate each month in a live programming session. Just visit takeupcode.com and click the link at the top to “Become a Patron.” This game project is just getting started and there will be lots of opportunities to figure out details like the map if you join now.