Work on the toughest problems first. And if you can’t solve them, then find a way around.
Remember to always keep sight of what’s important. And right now, that’s to finish your game. Don’t get sidetracked with problems. But don’t ignore them either. Listen to the full episode to learn how to identify problems early and some real examples to demonstrate how you can apply this advice to your project. You can also read the full transcript below.
Transcript
I remember a story that I heard a long time ago. I don’t remember the specifics anymore but it went something like this. There were three adventurers on a mission to deliver a message and they came across a strange wall in the middle of the forest that was blocking their path. There was a locked door in the wall. One of the adventurers, tried to pick the lock and gave up. The other one tried to smash the lock but it was too strong and also gave up. The last adventurer realized that the lock and even the door was not the problem and cut some small trees to make a ladder to go over the wall.
Remember to always keep sight of what’s important. And right now, that’s to finish your game. Don’t get sidetracked with problems. But don’t ignore them either.
My advice is to identify the big problems as soon as possible. And then either solve them or find a way around. Unlike the three adventurers, you have a secret weapon that you can use at any time. If you can’t solve the problem and the wall is too high to go over and too long to go around, you have the power to just make the wall disappear.
Getting rid of part of your game might seem drastic, and it probably is. But it’s better to find out and make these types of decisions early. If you skip over something because it seems hard, that doesn’t make the problem go away. All it does is give you time to write more code that will depend on the missing piece. Then when you finally get around to working on it, you still have the same problem. Only now, you’ll be more committed and less able to change your design. You may find that you no longer have the secret weapon of just removing the wall because too much of your project now depends on its existence.
By exploring these unknown parts early when they’re just ideas, you can try to solve them or work around them. In the story, this would be to either pick the lock or smash the door open. If you find a solution like this, then great. But if not, then try to find another way around the problem. This would be like jumping over the wall. And if that also doesn’t work out, then make the decision to remove that part of the game.
How do you find these difficult areas early on? By going wide instead of deep. What I mean is that you should avoid working on some aspect of your game until it’s perfect before moving on to the next part. Instead, work on just the pieces you need to get something running from beginning to end. Then go back and revisit parts to make them each a little better.
Let me make this a little clearer with an example. Let’s say that you start off with an opening and closing. I’m talking very basic. A title screen with the game name and a button to begin play. Follow that up with an empty screen that says “Action”. Even though there’s nothing really happening yet. That’s okay. Then provide some way to end the game. You’re done with this part and ready to move on.
Maybe you decide to work on to the environment of your game next. What kind of setting will your game be in? Buildings? Outdoors? Get just enough of this working so that it exists. Maybe start out with a single room with a floor and four walls. That’s it. This part can replace the empty “Action” screen. Don’t add doors or tables or lamps yet. Okay maybe a single light if you really need one.
Then move on to the controls. How will your character move around.
Then move on to the next part of your game. Remember to add just the bare minimum because you need to find problem areas at this point.
In many ways, this goes back to the idea to focus on the minimum viable product that I talked about in part 5 of this series. But this idea of working on a little bit here and then a little bit there is smaller than an MVP. I mean, a game that says, “Would you like to play?”, followed by “Insert game here.”, then ending with “Game over.”, is not a viable game. There’s no value there to a player.
But there is value in taking this approach to you. Because it lets you explore parts of your game early on while everything else is at a similar level of done. Any difficulties you find at each stage can be dealt with much easier because you have more room to make changes and adapt to a different way of doing things.
In the game that I’m working on, I decided to focus on text only. Some of the early exploration that I needed to do was to figure out if this would be possible and if so, what limitations would I need to work with.
I was working on simple things like how would I display text at all. How would I organize that text into windows? How would I get input from the player? Would the mouse work or would I need to rely on just the keyboard? Could I switch screens so that I could display a title screen followed by the main game followed by an exit screen?
I got just enough of this done before moving on to the definition of the world. How would I define what the game world would look like?
At each step, I’ve had to make design decisions that will affect the rest of the game. But there’s no way to know what these decisions will be until at least some work has been done to discover them in the first place.
You see, writing software is a discovery process. It’s not like designing a bridge or an office building. There might be some civil engineering projects that push the boundaries of what’s been done before. But for the most part, building a new road is just like building any other road.
Software is just the opposite. While there might be some software projects that follow well established procedures, every project that I’ve ever worked on in my career has been unique. And the only software engineers that I’ve known to be able to confidently approach their next project were stuck with skills they had not improved for 10 or 20 years.
This means that software has many more unknown areas that need to be explored and tested. Some will work just fine. Some will cause problems that you’ll only find out about once you begin. You’ll have a higher chance of success if you can identify the problem areas early so you can decide what to do.