You can join an actual game development session almost every Saturday. This schedule might change in the future. But until then, you can find me working on a video game almost every Saturday.
I’ve brought together a lot of code that I’ve written over the past five years into a single library that I use in the game development sessions. There’s a lot in it with eight major components so far.
- Testing library. This lets you think about how you intend to use your code before you write it and then make sure it does what you expect.
- Logging library that lets you easily write information to a file as your application runs.
- Google’s Protocol Buffers lets you send and receive messages between different parts of your application.
- File library to manage reading and writing files.
- Configuration library that lets you store structured information in a text file.
- Event publishing and subscribing library that lets you define exactly what information you’ll send whenever something important happens in your application.
- Extension library is where new things can be added to your app or maybe existing things can be changed.
- Curses library lets you write text-based applications and helps hide some of the more difficult aspect of curses.
You can read the full transcript of this episode below.
Transcript
This schedule might change in the future. But until then, you can find me working on a video game almost every Saturday. I actually write code a lot more than just Saturdays. The problem is that I never know in advance when that will be.
For me, programming is relaxing. It’s what I do. I enjoy it and have been programming ever since about 1991. Before then, I was mainly into electronics. It wasn’t until 1991 when I needed to find a job quickly that I switched careers and started programming.
At that time, I knew a little programming already but was still completely unprepared for what it was like to work on a large project. Or at least it seemed large to me then. It really wasn’t a very big project. There’s so many features that software is expected to have these days that even a small utility application to help you keep track of phone numbers would probably be bigger.
Imagine for a moment that if I was unprepared over twenty five years ago, what it must be like today. I’ve yet to find any book or online tutorial that can prepare you. I’ve found that a lot of people even after reading some books and watching online videos for a week or more still have no idea where to begin.
Are you in this situation? Do you have an idea for an application and no idea how to start? Or maybe you feel frustrated because there’s so much to do? What should you focus on first?
One good thing about all the progress we’ve made over the last few decades is that our tools and libraries have also gotten better. Sure, they can seem complicated too. But we don’t have to write as much software as we used to. We can reuse code in libraries.
I’ve brought together a lot of code that I’ve written over the past five years into a single library that I use in the game development sessions. There’s a lot in it with eight major components so far.
• First is a testing library. This lets you think about how you intend to use your code before you write it and then make sure it does what you expect. It’s a single header file that you include and then you write what appear to be methods that use your code and then verify the results. It runs all your tests and prints out an organized summary of everything that passed and failed. You can group tests together and choose to run some or all of your tests each time. All of this fits in about 750 lines of code.
• Next is a logging library that lets you easily write information to a file as your application runs. You can use this to keep track of what’s happening so that you know where to look for bugs. Many times, a log file will let you track down and fix bugs that otherwise would continue because it’s so hard to figure out what the application was doing right before it crashed.
• Third is an implementation of Google’s Protocol Buffers. This lets you send and receive messages between different parts of your application. Or you can also use it to organize information so it can be written to a file and then read back later. It’s extremely fast, efficient, flexible, and easy to use. And that’s a combination you won’t find in many other libraries. Maybe that’s why Google uses it to send information between their computers to find what you’re searching for.
• The next component is a helpful library to manage reading and writing files. It’s a simple task to do yourself. But it’s even more simple to call one of these methods, give it a file name, and let it open the file and return the contents to you.
• Fifth is a configuration library that lets you store structured information in a file. Now, you could use the protocol buffers to do the same thing. But this library keeps the file readable in plain text. That means you can change it by opening it directly in a simple text editor. Your application will then read the changes you made. I’ll be using this in the game to hold maps of the game world.
• Next is an event publishing and subscribing library. It’s small and powerful and modern. It lets you define exactly what information you’ll send whenever something important happens in your application. These are publishers. They wait for something to happen and then look to see if any code is interested to know about the event. These are the subscribers who express a desire to be notified when something happens. Let’s say you want a button in your application that the user can press. The button is a publisher and will let any interested code know when it was pressed by sending a clicked event. Somewhere else in your code, you want to do something whenever the button is pressed so you subscribe to the button’s clicked event. It’s a good way to organize your code and helps you to keep your code simple and easy to maintain.
• Seventh is an extension library. You might have heard of applications and games that can be modded. This is where new things can be added to the app or maybe existing things can be changed. One way to do this is to design your application to use plugins or extensions. This library helps you to load the plugins into your application and communicate with them.
• And the last major component. At least for now, anyway. Is a curses library. This lets you write text-based applications and helps hide some of the more difficult aspect of curses. Curses itself is a very old library. I’m not sure exactly when it was first written but I think it was probably old back when I was first learning how to program.
All of this code that I just described is included in the Take Up Code Utility library. Or TUCUT for short.
And this is the library that I use each week in the game development sessions. You can use it too. Everything is available on GitHub as an open source project. It’s big enough that you get to see how a large project fits together. And small enough that you can understand how it all works.
Now, when I say it’s a big project, that’s really because it was built by one programmer, me, over several years of working in my spare time. It’s nowhere the size of a major blockbuster game or other application. Some projects have teams of hundreds or even thousands of software developers working full time over decades.
If there’s one thing the game development sessions give you though is a sense of how things fit together and where to begin. This will prepare you much better than anything I’ve found. It’s not like a regular class with a specific topic.
I don’t really know what will be discussed each week or what I’ll be working on. What I mean is that there’s no curriculum that I follow in the game development sessions. Of course, I have an idea of what I’m trying to build each week. But it changes. I get new ideas and sometimes change direction. In a way, that resembles what it’s like on an actual job.
You don’t do the same thing in a software job each week. Just think about a school teacher. Every year, they start over with their topic. It can adapt slowly over time but for the most part, it just repeats year after year.
It’s even worse for a factory job where you can end up doing the same thing each day. Or a construction job where the scenery changes but the work is essentially the same.
Writing software is a creative task. It’s like writing a fictional book. You can let it take you different places. One thing I do is work on one feature for a while until it’s good enough and then move to something else. It’s an agile approach that doesn’t let anything get too far ahead because it would likely need to change anyway. A lot of companies follow a similar approach.
Not only are you learning how to approach a problem and how to program, you’re also learning skills that will help you fit in with a team.
You can find out more about the game development sessions by visiting takeupcode.com and clicking on the link at the top that says Classes.
And you can also get a bonus game development session each month by becoming a patron and contributing at least $10 per month to help support Take Up Code.
cript