You have a vague idea for a new video game. Where do you begin?

I’m not a painter but I have to imagine that this is similar to any creative work of art. Where do you begin? A lot of people get stuck here and never make progress. You have to start somewhere.

It’s got to be a hard thing to paint. What do you do if you make a mistake? I’m sure some things can be covered up. If the paint is still wet, then you might be able to scrape it off the canvas and try again. Like I said, I’m not a painter so I don’t know. These are just my thoughts. And it’s got to be a lot harder to cover up a mistake once the paint has dried.

This is one of the reasons that I like software development. It’s a lot easier to recover from mistakes. And we can start a new project by copying some code from an earlier project. Imagine starting a painting where the basic structure is copied from another painting. You can bring over the best parts and leave out anything that doesn’t apply or was a mistake.

Of course, there’s a lot more to beginning a new video game project than just this. And there’s a lot more than I can include in just one episode. Listen to the full episode or read the full transcript below to learn more and make sure to subscribe to the podcast, so you’ll automatically get a new episode delivered to your podcast app each week.

Transcript

I’m not a painter but I have to imagine that this is similar to any creative work of art. Where do you begin? A lot of people get stuck here and never make progress. You have to start somewhere.

You could begin by researching and learning everything you can. If you want to paint, then maybe you could learn all about colors. Then study all the famous paintings to learn their style. Then take drawing classes. You might find that you end up doing anything except painting. You tell yourself that you’re not ready yet. There’s still more to learn. And after spending months or even years preparing, most people just give up. It’s too hard. Or they lose interest. And for those who do finally squeeze some paint out of the tube and swirl it around and mix it with other colors and then dip the brush and apply that first stroke of paint, the experience can be exhilarating.

Yet strangely, a lot more give up here too. Their first attempt at making a masterpiece looks nothing like the paintings in the museums. Maybe they’re just not cut out to be a painter.

It’s got to be a hard thing to paint. What do you do if you make a mistake? I’m sure some things can be covered up. If the paint is still wet, then you might be able to scrape it off the canvas and try again. Like I said, I’m not a painter so I don’t know. These are just my thoughts. And it’s got to be a lot harder to cover up a mistake once the paint has dried.

This is one of the reasons that I like software development. It’s a lot easier to recover from mistakes. And we can start a new project by copying some code from an earlier project. Imagine starting a painting where the basic structure is copied from another painting. You can bring over the best parts and leave out anything that doesn’t apply or was a mistake.

If you’re just starting programming and this is your first game ever, then my advice is to start out with a simpler game. Go as simple as possible. I’m talking about something like tic-tac-toe or wordguess. Listen to episodes 13, 14, and 15 for more details. You can also get a 5-day email course that shows you how to build a word guessing game by going to takeupcode.com/wordguess or by texting the single word, wordguess, to the short number 44222.

There’s no right answer to how to begin writing a video game or any software project. But you have to get started and break open that tube of paint early on. Let your initial mistakes happen while you still expect them to happen and you’ll be less disappointed in the results. You might even surprise yourself and create something better than you thought.

The important part of this process is that you’ll be building up code that you can reuse on your next project. Each time you start building a new game, it’s like getting a head start that keeps getting bigger each time.

What you need to do is balance your learning with your doing. Too much of either will lead to disappointment and probably cause you to give up. If you spend too much time learning without doing anything, then you’ll develop an inflated sense of what you should be able to do. And if you spend too much time writing code, then as your projects get more elaborate, you’ll find your design is too fragile and hard to understand.

I take things one step at a time even after many years of practice. I recently started building a text-based adventure game because there was too big of a gap between tic-tac-toe and even a 2D graphical side-scroller. I needed an example to use when showing you how to program that was between these. Originally, I thought that a 2D side-scroller would fill this need by bridging the gap between a simple text-based game and a full 3D adventure role-playing game. It turned out that the jump from a simple text game to any type of graphics was a bit too steep.

So how did I begin this new text-based game? Well, I actually copied a lot of the prompting code from the word guessing game. If you get the wordguess email course, then you’ll get the same code that I used to start this new project. I figured that any game needs to ask some questions and the player needs to respond, right? So the first version just printed hello to the screen. It didn’t even make use of any of the prompts. Not very fun, I know. But it compiled. Then I added a reference to the curses library and made sure that the project continued to build.

Then I changed the hello world away from using cout to print the text to the console so that it created a curses window and printed hello there. Each step was deliberate and small. Especially when I was learning how to use curses.

Now, there is one step that did before jumping right into using the curses library. How did I know to use curses in the first place? Well, ignore for a moment that I was already familiar with the library. At least with its purpose. It’s an old library but I’ve also been programming for almost as long. So I already knew it existed. What I didn’t know was if just maybe in all those years something better had been created.

So I did a little research. Just enough to see what other people were using these days to draw more elaborate text on the screen. I was really hoping that there would be something better than curses by now. But there isn’t any other choice available that will allow you to write code that will run on multiple platforms and draw text to a console window. Since I encourage you to start programming on whatever type of computer you have, I wanted something that would run on Windows, and Mac, and Linux. Everybody’s moved on to graphical interfaces and the simple text interface has mostly been forgotten.

That’s understandable. A graphical application sure looks better and can provide a richer experience than just text. There’s just more to learn. More details to manage. And more code to write a graphical application. Sure, a lot of that code will be hidden from you in modern libraries. This is why some languages say they’re easier to write in than C++. I don’t believe that hiding the details is a good way for you to learn what’s really going on. I’ll make another episode along this topic soon.

My research showed that the curses library was the best way to go even after all these years. So I read some examples and watched some videos. I did just enough learning so that I could start coding.

Then I took the coding one step at a time. First was just getting it to build and run with a simple message displayed. Then I thought it would be good to get color working. Could I control the background color? What about the text color? Could I get multiple colors displayed at the same time?

You might think this sounds super easy. But I struggled with it. I tried something and it almost worked but not quite what I wanted. I went back to research what I might need to do differently. And then tried another approach.

I remember one problem that bugged me for a long time was just getting a pure white background. I would tell curses that I wanted black text on a white background and it would give me a grey background. I finally discovered that the original version of curses only supported eight colors, black, red, green, yellow, blue, magenta, cyan, and white. And that these colors were now referred to as the dim colors. There’s another set of the same eight colors but in a bright mode. Well, I thought I had my answer and changed my code to support the new bright colors. I even wrote the code to allow you to be able to specify if your terminal supported the bright colors and it would give you just the dim colors if you said that your terminal only supported the dim colors.

The result, a slightly less grey background. Still nothing resembling a bright white background that I was hoping for. I got a bit frustrated but instead of giving up, I moved on to working on something else. Sometimes, our brains just need a break for a while. At least we think that we’re taking a break. When given a problem like this, our subconscious mind goes to work and while it’s a bit slower than our conscious mind in solving problems, it can lead to insights and breakthroughs. I say the subconscious mind is slower for this but do we really know how it works? It might actually be going through many more solutions than we can think of and presenting the promising ideas for us to consider further.

What I finally discovered was that on a Mac, the actual colors that get displayed on the screen can be controlled in the terminal window preferences. Opening the preferences window shows a section for text with the 8 normal and 8 bright ANSI colors. ANSI is an acronym that stands for the American National Standards Institute. They’re the ones who defined that there should be 8 standard colors and then 8 more bright colors.

I’ll continue more about this project and the steps that I took in next week’s episode. If you’d like to experience what it’s like to work on an actual project like this, then consider supporting the podcast as a patron. You can sign up by going to takeupcode.com and clicking the link at the top to “Become a Patron.” You can choose your reward level. Just one dollar a month goes a long way and I really appreciate it. You also get access to a special podcast episode each month just for patrons. I’m just starting out on Patreon and at the time this episode was recorded, there’s a special episode about something that surprised me about C++ recently. One of the reward levels that I’m talking about allows you to participate directly with me each month in a group programming session. This is uncut and live. And it’s exactly how I program. You’ll get value out of it no matter when you join, but I encourage you to join now so you can get in on the early stages of this project.