My Pet Kingdom Post-Mortem

Background

As I've mentioned in a few other posts, My Pet Kingdom was originally designed for #Lowrezjam 2016 which asked developers to make a game that was 64x64 pixels. The game itself could be about anything, as long as it remained within those confines.

I participated because I wanted to make something small, and I had an idea for a game that was more like a toy than an outright game. I wanted to make a Tamagotchi-style game, but instead of a small creature, you would be taking care of a small kingdom. I didn't want it to be a complicated 4X where you had to manage resources, attack enemies, and otherwise try to stay alive. I just wanted it to be a chill experience, where the kingdom would provide resources you could feed back into it in different ways and watch it grow.

The end result is a little different from my original vision, but that's mostly due to my limited scripting knowledge.

An important thing for me to do, whenever I make a game, is to try something new. With My Pet Kingdom, it was data structures: dynamic lists that get created and edited in the code. I used them to keep track of everything, which, in the end, wasn't strictly necessary but still worked out pretty well.

The end product was fine. The game ran okay but if you played for long enough it would eventually crash, plus the peasants sometimes behaved in strange ways. For a game jam product, though, it was pretty well-received.

Some user comments stood out to me. One person liked the game but wished it had sound and music, two things which completely hadn't occurred to me while making the game. Another use pointed out how the game wasn't true 64x64 by the way the smoke pixels moved, but that was due to a limitation in the way gamemaker handles sprites more than any conscious decision on my part.

The "Art"

One of the most affected aspects of making a game that size is going to be the graphics. Regardless of the game you're making, it's going to have to be simple.

I had never done pixel art before, and the art in My Pet Kingdom only qualifies as "pixel art" because there is no other way to define it. Peasants are literally just two pixels: one light beige above a dark brown (I know, this means there's no coloured representation in MPK).

Still, the trees came out surprisingly nice, and I was able to animate water flowing down-river.

The challenge was making things tiny but also understandable. A 6x6 log was easy enough, but how do you represent a bale of hay? Or how do you represent a length of road? A lot of what I decided was placeholder art ended up in the final product simply because I wasn't able to make anything better.

The feedback I got from most people that played was they didn't always understand what something was. In a game where the only explanation as to what something does depends on a player's assumption about the item, it's important that they know what the item even is, otherwise they're just mashing pixels against pixels to make more pixels.

This was something I was able to solve when I started developing a proper build. No longer being limited by having to make the game 64x64, I added a strip at the bottom of the screen that would show the names of whatever it was the mouse hovered over.

Of course, this introduced a new challenge: making a font small enough to fit the screen, but big enough to be legible. What I got in the end works, mostly, except anytime an r is next to an n, it looks like an m. So you can build a "Bam" instead of a "Barn".

Acceptable.

The Design

There was no documentation at the beginning.

The first step was to build the foundation, which was: the game will choose randomly from a list of instances which instance will produce a resource, and then that resource will appear. I forget how long I spent trying to script that functionality, but once I got it working it was a huge relief. It meant everything after that was gravy.

All of this, of course, was made for the game jam, so even though it contained elements of things I had only just learned, the code itself was pretty haphazard. There were a lot of instances of: "I don't understand why this works, but it does, so I'm not going to touch it," when really, I should have been going, "I don't understand why this works so I better take the time to figure out, otherwise I'll be getting some major headaches later." Alas, the notion of "later" was alien to me at the time since I didn't even know if the game would work.

Anyway, so once I got the basics going, I could add structures and resources to my heart's content. The design process became a series of tiny challenges, like: how to make it so that all the trees count as a single entity to prevent them from flooding the production list, or, what happens when the player has consumed all the resources on the map, or, how does one build an orchard, etc., etc.

Fast-forward a couple of years, I decide to make the game a full game. The game jam version just launches right into the action when you start it, and no data gets saved so you have to restart from scratch with every launch.

I decide I want to add the following features:

• More structures and resources;
• A saving and loading feature;
• An Options menu;
• Music and sound.

The extra structures and resources are the easiest to add because I just have to code them on top of the existing foundation. It's was a great feeling to have ideas come to me and then be able to implement them almost immediately.

What I didn't realize at them time was that I should have been documenting not just the new in-game objects, but also the code I was using to make them.

Save Me

I wanted the game to save the player's progress dynamically so that they could resume playing whenever they wanted. You could quit or exit at any time and then just continue from where you left off. This meant a save system that saved constantly, as the player made changes.

My first attempt was a colossal failure. I tried to update the save file each time an object was created or updated its image index, which meant the game was constantly opening and closing the save file from all sorts of places in the code. It quickly became a mess as I tried to remember what needed saving and updating and what would be fine left alone.

After much despair, I scrapped that system and went a different route. With this new system, the game would just take a look at what was currently in the game and then save the coordinates, image index, and other significant variables of everything there. That way, when loading the game, it would just have to see how many of each thing it would have to load and then use the listed coordinates for each.

This was not without its problems.

The original code had not been written with a save functionality in mind, so a lot of what happened in the game was coded with assumptions on certain circumstances. Basing your code on assumptions is bad. So many bugs had me mystified and utterly flummoxed. I would stare at the code without understanding why it wasn't behaving as it was typed until I found the wayward typo, or the leap of logic, or the completely wrong assumption.

The end result works with 95% efficiency. By that, I mean that it almost works exactly the way that I want, but the ways in which it doesn't work are, in my opinion, still acceptable.

Whatever my next project, I am going to be keeping track of everything.

Sound Out

The music and sound effects were a much more pleasurable experience.

I had never made sound effects before, so I got some recommendations from friends. Audacity was mentioned quite a few times, which I already had installed and, quite honestly, had totally forgotten about, but the thing I eventually went with was Bfxr. It's a great program for making royalty-free sound effects with a retro feel, which is exactly what I was going for. The program looks complicated at first, but after a bit of tinkering around I was able to get the hang of it and produce the sounds that I wanted.

For the music, I asked my friend if he was willing to make me some SNES-style tracks, which he was more than happy to. I had worked with him previously on The Hollow, where he made an absolutely amazing soundtrack, so I was quite looking forward to what he would make now.

The title track is a perfect "the fantasy begins"-style track, which was ideal for the main menu. For the gameplay portion, I needed something a little simpler. What ended up happening, however, was a little strange in the way it worked out.

While testing how the music worked, I threw in a random track I found on my computer. The name of the track was literally just a string of numbers with .mp3 at the end. It turned out to be one of his very early tracks.

What's more, the track fit very nicely! After a quick discussion with him, he was more than happy to let me use it, so the placeholder, once again, became the final product!

There's Options

With music and sound effects, I wanted to give the player the option to turn them on or off. Making an options menu for the sound wasn't too complicated, but I should definitely have done it before implementing all the sound and music.

Because of the wacky order in which I did it, I had to hunt down all the sound effects in my code and wrap them in a few lines of extra code. Luckily, the game is small enough that this wasn't too big an issue, but I can imagine this happening in a bigger game and it being a nightmare.

Why Gamemaker?

Gamemaker: Studio is, currently, the engine I'm most used to using. I'm still on version 1.4, not having upgraded to version 2 yet, but it still serves very well.

For the kinds of games I'm making, it's an engine that works. Since the games are 2D, I don't really need too many bells and whistles. I have an idea for a 3D game, but when I feel confident enough to tackle that I'll switch over to Unity.

The Lessons

The biggest things I learned while making My Pet Kingdom are this:

• Document everything: code annotation is your bestest friend ever.
• Plan your save files in advance. 
• Code logically, not based on assumptions.
• Create the sound options before implementing all the sounds.

All-in-all, I'm pleased with the final product. The fact that I was able to make it so that you can load your game from where you left off just blows my mind. The game itself sells for a dollar, but I'm not really interested in making money; that's just there so I have something to give my musician and QA.

With all this new knowledge, I'm now super-excited about my next project! And if you want to see updates on my current and future projects, you can follow me on Patreon and Twitter where I go into a lot more detail!