February 2021

There were 3 posts published in February 2021 (this is page 1 of 1).

A Game in Thirty Days: Part Two

I made a game in thirty days! And now I’m writing about it. In part one of this mini-series I talked about the process of getting started: setting my goal, picking my tools, etc. Now, in part two, I’d like to talk about a few things I learned along the way.

As a quick refresher, this is the end product:

It’s a short Zelda-like action game built with GameMaker Studio 2. The game consists of a village, a dungeon, a quest, and “remembered” progression — that is, if you unlock a door or complete a puzzle, the dungeon will remember.

Lesson: Don’t just dive in

More than once, I decided what to do next and started working on it right away. The time this bit me hardest was when I originally implemented elevation changes and pits you could fall into.

Originally the game had just two elevations. Collisions worked with tile layers, one for each elevation, and had multiple tile maps for each elevation. This worked fine, but ended up being a lot more work than it needed to be: code to set depth/z-ordering based on an entity’s current elevation; code and triggers to change elevation; code to reset elevation when certain conditions were met; extra work mapping “portions” of the map; so on.

Then came time to implement pitfalls. In Zelda you can walk over a pit or hole, or knock an enemy into one, and you fall. I tried to do this using objects, collision, and triggers, and eventually got something that worked most of the time, except for if you walked funky or collided without realizing it. This ended up being frustrating if you didn’t take the happy path. I spent a lot of time tuning and tweaking these triggers. It felt like I was banging my head against GameMaker for a while.

I spent an entire day on these pits before scrapping the feature altogether.

Five days later the solution came to me, along with a way to unify both features and simplify the collision system. I spent another day doing this, as well as adding ledge jumping, while also removing large swaths of code and combining everything into a sort of “collision state machine.”

Doing this made it easier to implement all of these features, and more, with less code. The end result was more robust, required less work to build out when creating new maps, and made it easier to extend to add new features. A similar approach was used by the Pokemon games, which is where I got the idea.

Plus, it looks kind of neat.

collision tile map

The collision tile map. Each tile represents a different state or elevation.

The main lesson here? A little bit of planning can save days of work. If I had sat back and thought about this a little while before jumping in, I’d have had at least an extra day to work on other things.

Lesson: Get friendly with graph paper

Pen and paper will always be cheaper and easier to use than writing code or building tilemaps or whatever else. This is, luckily, something I did not have to learn the hard way.

Before placing a single tile in GameMaker, I drew every room of the dungeon on a graph pad. I placed doors, monsters, traps, chests, in little squares on paper, and ran through the dungeon in my imagination. Once I found a tileset to use, it was just a matter of putting the pieces together in GameMaker and running through to make sure it was all right.

Iterating on paper instead of in-game reduced the overall time spent on the project by a considerable amount.

That said, there were still a few changes made in-game once I was able to playtest the dungeon. A puzzle got scrapped, a room was rearranged, and a new room was added.

Still, pen and paper proved invaluable, and for the next steps in the project I’ve been doing almost all the up-front work on my trusty graph pad. If anything can be mapped visually or sketched up, then it’s probably worth doing that before you even think of writing code or building maps or anything of that nature.

Lesson: Waste your time wisely

I’m not an artist. In the beginning of this project I spent a little too much time trying to draw my own sprites and animations. The fourth time I scrapped everything and closed GraphicsGale in frustration, I decided it was time to find some art to use.

There’s almost too much good, free, and open art to use on the internet. You could spend hours looking through everything, which I did. The point is, as usual, just to pick something and stick with it. It’s not worth spending too much time on the visual appearance of your game at the early stages. As long as it’s tolerable, or at least the intent is clear in your presentation, it doesn’t matter how it looks until much, much later.

In the end I paid for some assets and drew some others. It’s probably clear which ones were “mine”: the slimes and the bosses don’t necessarily jive with the rest of the game’s aesthetic. But that’s fine.

Lesson: Play it!

You can’t know if your game is fun unless you play it. Not just the one room you’re working on, or the new feature you’re building and testing in your debug room.

Before releasing the demo, I went through the game beginning to end more than a dozen times. In the process I tweaked hitboxes, changed some behaviors, found some bugs (and left some bugs! for the attentive player to exploit if they want), and adjusted the difficulty.

Me, almost getting wrecked by a simple encounter.

This might have also worked against me. I was worried the game would be too easy, but the first feedback I got was exactly the opposite. One of my first players spent nearly an hour, collecting 12 heart containers and throwing 23 bombs, and still struggled with the final boss.

(This was partially due to the fight difficulty and partially due to the control scheme being a struggle, but the point stands! I added a new control scheme and it became easier for him. )

Details aside, the bottom line is this: if you’re not having fun playing in, then others won’t, either.

Wrapping Up

If nothing else, the thing to take away from all this is, “plan ahead, and plan the right way for what you’re doing.”

Or don’t. Five hours of work can save you twenty whole minutes of planning. 😉

The Game

If you want to view, download, or leave feedback for the game, click here:

A Game in Thirty Days: Part One

Recently, I was struck by that familiar urge: to make a video game. After a few hours of reading and thinking I decided I was going to jump in and do it, but this time it would be different. I would just pick a platform, start working, and make a game in thirty days.

This is the result.

As you can see it’s got a few rough edges, and it’s obviously incomplete (no title screen, no saving, etc.), but for now it’s “done” and it’s time to reflect, take away some key lessons, and move on to the next project. For the curious, I’ll put a link to the download page on Itch.io at the bottom of this post.

I want to talk about this project: how it was formed, what I learned, and what’s next. This post is part one in a series.

The Plan

Obviously, the Zelda games were a huge inspiration for this project. A Link to the Past is my favorite game in the series and in my opinion one of the greatest games of all time. I always thought that, given the rise of nostalgia titles and revivals of older genres, no one had really given ALTTP the same treatment.

(This isn’t entirely true. There have been some. But none that have really captured the essence of the games, like the two I linked above. But that’s probably a topic for another blog post.)

So I thought I should be the change I wanted to see. It was time to dig in.

Picking My Tools

In every past attempt to make a game, I always focused too hard on vague future possibilities. Not picking Tool X because I might want to do XYZ thing in the future. Or picking Tool Y because I wanted better control over ABC thing. This focus on tools, platforms, or languages limited me and doomed my projects from the beginning: by focusing too much on some nebulous definition of quality or maintainability or extensibility, the projects became about the code and not the game.

This is not to say that these things are unimportant! Just that when you’re making a game, the game comes first. If you’re not producing something that can be played, you’re not making a game. And that’s fine if the goal is to learn about specific aspects of game development, because there are a lot. But this time, my goal was to make a game.

So my mantra became make it work; make it right; make it fast.

I closed my eyes, picked an engine, and downloaded the 30 day trial of GameMaker Studio. No further thought or planning went into this, for better or worse. The important thing was to just stick with something and make a game with it.

The first week of my thirty day trial I spent learning about GameMaker Studio and GML, its scripting language. The official resources and Shaun Spalding are excellent, and I could not have done this so quickly without help from his ARPG tutorials.

Picking My Battles

After all that, the next most important thing to focus on was scope. I didn’t want this to balloon out of control and become another thing I wouldn’t finish because I decided I wanted to do more than was possible. So I decided, one dungeon. That was it. If time allowed, maybe a little more, like a village.

If I was going to stick with the Zelda format, one dungeon meant kind of a lot. Secret rooms, special items, chests, a variety of monsters, traps, a boss battle, item drops. The idea was to write out a list of these high-level ideas. Each day I would pick an item from the list and implement it.

This was a huge help even if I wasn’t completely successful at it. There are a few features I implemented that aren’t even really visible in the end product. On top of that, there are a few features I started to implement then scrapped when I realized they were too much work, or not very fun. I probably spent a week total on these things.

A few other features I started to implement, took a break, then came back and restarted with fresh eyes. Sometimes this meant throwing away everything I’d done before, and others it was just a wall I’d hit and I needed a break. Sometimes a feature I thought would take me an hour took me a day.

I wouldn’t consider any of this lost or wasted time. That’s part of making a game: if it isn’t fun, scrap it. So it was important to frequently playtest and make sure even this narrow slice of gameplay was fun and satisfying.

The Process

During the development process I kept a devlog, just kind of raw notes at the end of each day going over everything I did and what I wanted to do the next day. This was helpful for me because I could come back without that “what now?” feeling: I already knew what was next, and Past Me told Present Me exactly what it was.

I also started sharing screenshots and gifs with some friends and family over Discord and Twitter. Feedback, even if it was just “that’s cool, keep it up,” really helped keep my motivation up.

The devlog details my setbacks and triumphs. Originally I kind of wanted to post daily or weekly updates with the devlog but decided it would take too much time to clean up and post and would detract from the energy I needed to make the game. Later, I’ll clean it up and post it. I always enjoy reading other developers talk about their process and it’s always heartening to read about others facing and overcoming their own setbacks. I want to share my own experiences with that.

Next

This post is already longer than I thought it would be, so I’ll cut things short for next time, where I’ll go over some specific lessons I learned, a few techniques I used, and more.

The Game

View the game, download it, etc., below.

How to Teach Yourself to Code

Several times over the past few years I’ve been asked how I learned to code. I didn’t go to school for it, and it wasn’t originally something I aspired to do. So I never really had a good, straightforward answer, and just ended up rambling on for a while. The more I thought about it, the more I realized that my path to becoming a software developer was almost as meandering as my answers, and just as packed with fitful starts and dead ends. So, I figured I would sit down and write it down, though unlike my Teach Yourself SQL post, this post’s scope is much wider, on just how to teach yourself to code in general.

Or, more specifically, how I taught myself. Everyone learns differently, so just because something worked for me this doesn’t mean it will work for someone else. I’ll try to also include “further reading” and other types of resources that I didn’t use, but I know to be useful.

So… how do you teach yourself to code?

0. Get Very Comfortable with Google

Or your search engine of choice.

The point is that part of being a software developer, or working in any capacity with technology, is being able to find and parse information online. You need to be able to form your question in a way someone else can understand, then find the appropriate resource, then understand what you’re reading.

This might be official documentation from a company about its products. It might be a StackOverflow post, or a thread on a forum. You might need to be the one to ask the question, because it hasn’t been asked before. Which leads into the more important point, way more important than just knowing how to google something:

A fundamental part of being any good at any of this is the ability to clearly define your problem.

This will not only make it easier to find answers to your questions, but it will make it easier for you to solve your own problems. The vast majority of the work is taking a nebulously-defined problem, breaking it down into solvable chunks, and then solving those chunks. Remember word problems in your math classes in high school? It’s like that, forever.

1. Pick a Language

I know this seems like a weird first step. How do you pick a programming language if you don’t know anything about programming? In reality it doesn’t matter very much which language you pick; what matters is that you pick a language and stick with it.

This advice I drop with personal experience. The list of languages I picked up and forgot is longer than the list of languages I use today. First was Ruby, when I was 11 or 12 and building games with RPG Maker XP. Then it was C, then C++, then JavaScript… the problem was, every time I started with a new language it was like starting over. This was because I didn’t stick around long enough to master the fundamentals. Once you get the fundamentals down, then moving languages is easy. But you’ve gotta stick around long enough to do that. That’s the hard part.

That said, if I were to start again today, I’d pick one of these and stick with them.

  • C#: Developed by Microsoft. The tools are free, the documentation is extensive and detailed, and you can pretty much choose exactly how deep you want to dive here. The language and the tools have everything built-in to let you get started easily, and learn its inner workings at your own leisure. This is my favorite language, and my default when starting a new project.
  • JavaScript: If you can use a web browser, you can write and run JavaScript. Nothing extra is needed to run this code, making it the easiest to just get up and running. As a bonus, you’ll never be out of a job if you can master this language.
  • Python: Similar to JavaScript in a lot of ways, this still requires some setup before you can use it. Once set up, though, Python is another great language to start with, and perfect for building everything from small tasks to games to big web server applications.

Obviously, you should do your own research, but don’t get too deep in the weeds. Just pick a language, any language, and decide that it’s the language you’ll use to learn how to program. Some do come with a learning curve just because extra tooling might be needed to run them (C#, Python), so decide if you want to fiddle with installers or just get going (JavaScript).

2. Learn Your Fundamentals

Now it’s time to hunker down and start the real learning. I linked to some documentation for each language above, which is a great place to start.

From a bird’s-eye view, your learning path would cover:

  • Data Types: These are the building blocks of programming, and are how your code is represented to you, the coder, and how it’s interpreted by the machine. It’s the difference between an integer (1), a decimal (1.0), and regular text ("1")—and how these can and can’t interact with each other.
  • Operators: These are how you set and update your data. Like mathematical operations, they let you add things together, check for equality, and more.
  • Conditions and Loops: “If-this-then-that” logic, or “for every item in this list” logic.
  • Functions / Methods: Like formulas, or small mini-programs. If data types, operators, and conditions are water, rocks, and paste, then functions and methods are the bricks that make the foundation for a program. You put everything together into a method, then call that method from other code to do a predefined set of work. Like “2+2=4”.

Remember that Google is your friend, and there are countless resources on all of the above out there. The official documentation for the languages I posted above includes info on these terms, or the resources I will link to below will guide you through them in a more structured manner.

3. Dive a Little Deeper

This is where the Computer Science comes in: algorithms and data structures.

This is a big topic. Entire textbooks are written on just this alone. The important thing to remember is that every piece of code you write comes with its own complexity. Some code will perform better than other code, and many problems can be generalized, or abstracted, and solved with algorithms that some other smart people have already figured out. Like, what’s the best way to sort a list of items of a certain type?

Anyway, here are two specific places to start:

  • Look up “Big O Notation” and how it relates to the speed or complexity of an algorithm. You don’t need to know specific algorithms to understand this. It’s a good primer on efficiency, and an important part of describing the complexity of a particular piece of software.
  • You like video games? Look up “binary space partitions” and how they’re used to generate dungeons in roguelikes. Here’s a link to check out, without any code in it. This is a great example of taking a more generalized data structure / algorithm, and applying it to the specific problem of “how do I automatically generate dungeons for my video game?”

4. Make Something

As I stressed in my SQL post, if you don’t use it, you lose it. All this reading is worthless if you don’t do anything with it. It will just fall out of your head in six months and you’ll have to start over again.

Pick a project, any project. Find a small task you do that’s repetitive and might be automated and try to automate it. Go through this list of project ideas and work down it. Build a Pong clone, or a Breakout clone. Find a textbook and do the questions at the end of each chapter.

Start small, and work your way up to bigger things. Don’t overwhelm yourself. But keep going, keep building. It’s okay to just follow tutorials and copy code as long as you’re also thinking critically about what you’re copying and why it works—and better, how you might do things differently on your own. Go past the end of the tutorial. Keep going. It’s okay to get stuck, it’s okay to break things. That’s how you learn.

But keep going. Keep building and learning and growing.

5. Read

Maybe this should have been first. Or maybe it should replace everything above. Textbooks remain the single best method of distributing and acquiring knowledge. The good ones structure themselves in a logical and approachable way so that you can start out as ignorant as the day you were born, and finish as an adept.

The only downside is that technology moves at a fast pace, and textbooks for things like specific languages might be a little outdated by the time you find them. That’s okay, really. Most languages don’t change enough for it to matter, or you could use the book’s structure to set your pace and help you find more modern materials that are available elsewhere.

Or you could focus on books that aren’t about a particular language. Some of the best books on programming are more about how to approach the work, ways to think about code, and the “soft skills” many of us lack in the industry; that is, how to navigate people, culture, and politics. Here’s a good list of these books.

6. Further Resources

Okay, you’ve made it this far, but maybe everything above is still too vague to really get started. Here’s a list of free resources designed to get you going. Most of these are structure learning, like online classes, for you to do at your own pace.

  • Harvard University’s CS50 Course: My advice above kind of contradicts this course in the sense that the course covers multiple programming languages. When in doubt, trust the professionals, because they know better than me. This course covers everything from the very basic on through to some fairly complex projects. Really, you can’t beat this. There are other universities out there like MIT that also post courses online for free.
  • /r/learnprogramming: A friendly little community with good resources and helpful community members. I just linked to the wiki, but the sub itself is great for if you have questions and for finding even more great programming links. Click around in here and you’ll definitely be able to find where to get started on just about anything.
  • The Odin Project: Everything you need to know to become a successful and well-versed web developer. A full curriculum, from start to finish.
  • Project Euler: Not necessarily a tutorial resource, but a great way to flex your math and problem solving skills. This website is a series of math problems that start fairly simple and very quickly escalate. These are a great way to get your bearing on a new language.
  • The RogueBasin Roguelike Tutorial: This is a tutorial for making a roguelike game using Python and a Python library called libtcod. It’s a great tutorial, has pointers on using Python in general, and by the end you have a fully functioning game base which you could extend, or at the very least you’ll learn a great deal about handling user input, graphics, dungeon generation algorithms, and more. It’s fun and the roguelike genre is a great playground for any developer.

That’s all, folks!

This was by no means an exhaustive how-to. Nor did it cover the actual path I took. But I started over this is how I might do it today. Learning new things is a skill all on its own. Sometimes the best thing is to just get a few pointers and go off to explore on your own. That’s how my brain works.