New Skill, No Time? You Might Still Find Ways to Pick Up a New Hobby
As creators, trying new things is a big part of the creative process. Whether it’s experimenting with new tools or techniques or exploring new styles and ideas. Join me as I add game-making to my never-ending list of hobbies!
While the focus of this article is making games, I hope the story of how I made room for my interest in making games can inspire you when you’re thinking about making room for any interest.
I’m a graphic designer by trade. I love creating art and graphics. You can take ideas from your imagination and make them visible to the world. I’m always looking for something new to add to my list of interests. While learning many new things might not be fun for everyone, it sure is for me.
That’s where making games came in. So I’ve been learning in a game engine called Godot. It’s free and open source, and I’ve been having a blast exploring all of its features.
The First Threshold: The BASICS of making games
I’m not a professional programmer by any means, but I’ve dabbled in making computer games before. As a kid, I dabbled in making games using BASIC (Beginners’ All-purpose Symbolic Instruction Code), a learning language that was included with DOS.
My computer came with a huge manual for BASIC that taught the commands. I even took a computer science class in college at Bowie State University where I was studying piano and fine art. It sounds like I was really deep into having a lot of hobbies already at that point.
When I first got an Android phone, I made a trivia app for Android using a tool for making phone apps JavaScript then known as PhoneGap at the time. I did not know JavaScript until then and learned it for that project. I even had it in the Android app store with crowd-sourced trivia questions for a while. Of course, now I don’t know Javascript at all.
At some point, I also paid for and tried using Construct2, a web-based game engine, and development tool, but never really made it past the tutorials. Maybe life got in the way? Or maybe I just forgot I was working on it? I can’t quite remember, but I found it wasn’t quite as powerful as I had hoped.
Call to Adventure: Building Our First Allies
Cut to late 2021. When I first started with Godot, I felt like I was entering a different world. As I dove deeper into the tutorials and documentation, I realized that Godot was my “Call to Adventure” – an opportunity to challenge myself and step out of my comfort zone.
I learned that using you can build using each small task like LEGO bricks that serve different purposes. This concept is communicated through pre-built pieces called “nodes” – visualized as a hierarchy of circles – which each has its specific job.
Some examples of these nodes include a configurable camera, a way to display animation and graphics, and various ways to simulate physics for characters and objects that might appear in a game. Each piece within the game engine has its unique purpose and can be pieced together with others to build a larger structure.
This may sound like a new world to you. And it was for me. Luckily, there was a lot of help to come. Who needs sleep when you can code all night and learn how a video game is made?
The game seen here is written in BASIC (Beginners’ All-purpose Symbolic Instruction Code)
Screenshot by Niels Heidenreich from Hannover, Germany, CC BY-SA 2.0, via Wikimedia Commons
Making a game feels a lot like playing a game, except this time the puzzle is making a game. As you progress through the tutorials and examples, you start to gain new skills and knowledge that help you to overcome obstacles. To help you in solving this puzzle, the engine has a simple but powerful structure built around the concept of these tiny working nodes that combine into “scenes”:
“In Godot, you break down your game in reusable scenes. A scene can be a character, a weapon, a menu in the user interface, a single house, an entire level, or anything you can think of. Godot’s scenes are flexible; they fill the role of both prefabs and scenes in some other game engines.”
“You can also nest scenes. For example, you can put your character in a level, and drag and drop a scene as a child of it.”
“Overview of Godot’s key concepts”, Godot Docs
The built-in nodes do a lot of work, but you’ll still have to do some writing. Every game you could create will contain unique ideas for how it interacts with players. You can use the engine’s easy-to-learn written instructional language (GDScript) to tell the game what to do.
Tutorials: Learn from others who have walked in your shoes
Let’s start with the obvious source of help. I started by following the official tutorials to create a simple game of Pong – the original tennis simulator.
The code portions you start with are simple. They even felt fairly similar to BASIC or JavaScript. Early tutorials teach basic ideas like breaking reusable pieces of code into well-named pieces (“functions”) that you can use again. You want to name these in a way that makes it clear to you what it does. It’s easy to get lost in your code if you’re not careful!
They also teach you about “if” statements which check if a certain condition is true, and if so allow for certain actions. (This is like the gambit system in Final Fantasy XII, which if you haven’t played it, I recommend checking out the Zodiac Age modern re-release).
In any field, some have come before us and have faced similar challenges and obstacles. Think about how much we have in our society that comes from passed-down knowledge and tools. Help from others comes in the forms of roads and signs that lead us in our daily lives, to the tools of our kitchen, and the words and technology on our screens. I’d argue that someone else contributed to most of the knowledge we each have.
It’s helpful to start with a few easy “wins”. I was quickly able to set up the basic game elements that create player movement and the ability to keep you from walking through walls – something you might take for granted. In the case of Pong, the player moves a paddle to reflect a ball that reacts using built-in physics. Using “if” statements, you can quickly simulate a computer-controlled opponent.
I started in late 2021 and even though I don’t have a lot of spare time, with just a few hours a week, I’ve been able to make a lot of progress in learning Godot and game-making.
YouTube remains one of my favorite places to find tutorials. I’ve been particularly impressed with the content from GDQuest, HeartBeast, Game Endeavor, and Godot Tutorials. They break down complex concepts into easy-to-understand chunks and have a way of making the learning process feel like a fun and exciting adventure.
At this point, I realized I can use what I already know to move forward. After Pong, I moved on to experimenting with graphics, using my skills as a graphic designer to create concept art and placeholder animations. I built prototypes for a physics puzzle game where you tried to scare the zombie toward a goal.
Still, I wanted to focus on learning new things and not stay safe by not going beyond my current knowledge. I swear that didn’t want to get distracted by creating beautiful graphics, which is my excuse for how this looks. I already made the zombie graphic months before when playing around with animation and just re-used the character just to have something to look at. This way I could stay focused on learning about code. Graphics can be added later once I have the basic game working
I also pulled ideas from games I like and have played before. Once I was in the realm of physics, I thought maybe a minigolf game could be fun. I’ve enjoyed physics games before and golf is a game that already has its own rules. There’s not as much math as I thought there would be. Godot has a physics engine which helps a lot. And then some simple math can get you through most of your challenges. Anyone, from elementary school students to retirees, can learn Godot and have fun making games without having to spend much beyond having a computer.
Facing Road Blocks: Knowing the State of Your Game
As I added more and more instructions to customize the way my games interacted, I began to have more code written in more places than I could easily keep track of. One of the early ways I’ve learned to try to keep my code organized and easy to read is through the use of “state machines”. I needed a way to break down the different actions the player can take and make it clear what code is running at any given moment. Without having the code organized, it was too easy to forget what I had made and what parts controlled the game.
One of the YouTube authors I mentioned earlier had introduced an intriguing pattern for keeping his code organized, the “state machine. This organizing pattern is called a “state” machine because only allows a certain section of code to run depending on the “state” – the status of a certain element. If a player a character is idle or moving, only that code will run and only one of these states could exist at a time. If you’re running then you’re not walking or standing still.
As part of the learning process, I started working on a side-scrolling strategy or tactics role-playing game concept. For the game mechanics, I imagined a turn-based strategy system like Shining Force or Final Fantasy Tactics, or especially Valkyria Chronicles.
My current enemy AI and steering prototypes aren’t developed very well or fully functioning yet. The enemies have their state machines and they react differently depending on if they see the player. You shoot them, they shoot you, and you take turns and reach the end. There are different types of weapons: ballistic weapons and straight shots. This is pretty basic, but the prototype did what I needed it to do to move from thinking about the idea to seeing how it might work.
Next, I had a prototype of a card game where you do chores and try to get through the day. A card game version of The Sims maybe? I haven’t figured out how to make this fun quite yet. Any ideas?
Break projects down into manageable actions
Use tools and processes to help you focus. One thing that is helpful for me during my journey of making games? Considering the “Next Actions”. I learned this idea from the book Getting Things Done by David Allen.
“Next actions” are the single steps that need to be taken to move a project forward. I started keeping a running log with these game-making tasks so I could quickly jump back into the project when I had even as few as 10-20 minutes. Some of these might be to just review some code, add a feature, or start creating some art. This also helped me find parts of the game that would be fun to work on depending on my mood. This is a hobby for fun after all!
- “Next Actions” are such an impactful productivity tool that I almost included several more paragraphs here. Instead of having a huge side story, I moved those thoughts into an updated version of this article: How to Plan Then Execute Goals with Getting Things Done (GTD) by David Allen: Free Downloadable Poster PDF
The Return: Making Code that You Can Edit
After the end-of-year holidays in 2022 and a new year began in 2023, I learned how important it is for my code to be easy to return to. I had trouble remembering what I did months before.
For inspiration, I turned to adventure games that relied on inventory-based puzzles were popular when I was a kid. There was a series called King’s Quest where you had to solve puzzles using found objects. Programming felt a lot like that for me, where I find out a concept and have to wonder how to use it.
As I’ve continued, I’ve seen that many game ideas I have use dialog, inventory, non-playable characters, and other ways to interact with other characters. These elements were the main feature in King’s Quest and other adventure games and they’re also a given in all kinds of games now. So I’ve figured that I could make bigger reusable pieces that could work in a lot of different prototypes.
I started learning how to pull code from previous prototypes into smaller, specialized, and well-named functions, components, and sections that can be reused in many different types of projects. Sometimes the puzzles in King’s Quest even felt broken and didn’t make logical sense. Coding could feel that way requiring practice and a willingness to try different approaches until you find the one that works. Sometimes I’d spend an hour or two finding a simple solution.
I want certain larger parts of what I make to be reusable as modular code. To create standalone re-useable and modular code, I could build my code that mimics the way the built-in standalone nodes work. Most built-in nodes have a singular function and work together with other nodes – such as managing graphics, animation, or collision detection. Creating my components this way seems like another good approach to breaking down the complexity of a task into smaller, more manageable parts.
As a way to practice creating code that is easier to return to after a break from the hobby, I began creating a simple prototype level inspired by classic inventory-based adventure games.
I pulled the code apart that displays dialog from the earlier prototype into the new Adventure Game code. This time, I was more careful to make it work independently from other parts of the game. And then I went on to build a system for storing and retrieving Quest data and another system for dealing with a character’s Inventory.
This also gives me more small wins as I get each module working and helps make sure that everything is working as it should with few errors. By building separate and reusable parts for dialog, quests, and inventory, I hope to quickly make more prototypes for my ideas and iterate on them more easily. I can just add a dialog or inventory module and adapt it for a new game prototype
I’ve created an inventory system for collecting and using items, and placing interactive objects and NPC characters within the scene. I’ve also implemented a basic dialog system for NPC interactions, and a quest system that allows the player to accept and track objectives.
This way, I can quickly prototype my ideas and even small games could benefit from using these parts without having to rewrite them from scratch. Plus, if I ever need to make changes, it’s designed to be easy to iterate and understand what I’ve created months before. I hope I can have a basic Adventure Game puzzle on the website Itch.io or something like that.
Sharing My Quest
Learning to code is like embarking on a quest. On any good quest, you should mark what you’ve completed and what’s next. Sometimes I just send a video to my Instagram story or send those videos directly to a few people in a private message.
I’ve also learned that a devlog is a diary of the process of a project, such as software or a game, that is shared with others to document progress and share insights. This blog serves as a bit of a devlog and hopefully is one of many. Sharing my progress helps me stay motivated, and maybe it can help others feel more excited about sharing their creative work.
Being transparent and open about the ups and downs of learning something new can make it feel less daunting for you to take the first step and start sharing your hobby.
- If you’re interested in learning more about the benefits of sharing your work early and often, you can check out my other blog post “Sharing Your Work Early and Often (Even When It Feels Scary)“.
The Adventure Keeps Going
In a game, you can work with other characters to achieve a common goal. Often you help the non-playable characters with their goals. In the same way, by attending coding meetups or joining online communities, you can talk to coders and developers to learn from each other. My partner Casey has become involved in many of these meet-ups such as Baltimore Code & Coffee, which has allowed me to talk to other types of programmers. it’s been great to share tips and tricks and to see what others are working on.
I’ve got some fun ideas for the next steps. I’m thinking about making interactive objects and puzzles for my prototypes. I’d love to make a way to create mad libs-style text for descriptions and dialog, which would add an element of surprise and replayability to future projects. I’m also planning to try a mad libs function for character dialog and object interactions. This will add more variety and humor to the game.
I’ve learned how to create basic animations and interactivity, but there’s still a lot to learn about game logic, physics, and all the other complex systems that make up a game.
One day, maybe in a few years at this point, I’ll be polishing and finalizing the demo to make sure everything is working smoothly.
Brian E. Young is a graphic designer and artist in Baltimore, MD.