Introduction

Maze Burrow is a labor of love that I spent 1 and a half years working on solo before its release last year on March 31, 2020. Maze Burrow is a Sokoban-inspired puzzle game with simple gameplay: move the patterned blocks into tiles with matching patterns to activate the level portal, then enter the portal to complete the level. Players must push and pull blocks and interact with many obstacles to solve increasingly complex puzzles.

In this postmortem, I will be discussing Maze Burrow’s development history along with challenges I faced, a reflection on the game’s release, and improvements I feel I could’ve made throughout the process.

Maze Burrow v1.0.4 Title Screen

History

I have always wanted to develop my own indie game. Ever since I was young, I had ideas for various types of games as well as ways to improve my personal favorites. When I learned how to code in college, I took it upon myself to create my own game. And of course, all the games I tried to create failed because they were far too ambitious for me to complete in any reasonable amount of time.

In September 2018, I decided I wanted to finally fulfill my dream and work on a smaller scoped game that I can actually complete in a reasonable amount of time. I decided to build a puzzle game since I could focus more on the content than developing the gameplay system. Plus, I loved designing levels, so this was a great opportunity for me to work within my own boundaries rather than another game’s.

I drew inspiration from two of my favorite puzzle games: Toki Tori and Mole Mania, both for the Game Boy/Game Boy Color. They have very simple gameplay but a lot of variety in their level designs. Some of the later levels are very complex puzzles, and I found them very enjoyable to solve.

I set out to create a similar type of game: one that’s easy to pick up and play, but hard to master. I decided I’d add puzzle elements that work with the gameplay to let me focus on the puzzles themselves, similar to those two games.

I also wanted appealing characters to give the game some charm. I chose two animals that have some similarities with each other. The first is the protagonist, an echidna. Echidnas are cute animals with many unique traits, and they happen to be very rare in the gaming world. The second is the antagonists, the moles. Moles are also cute, yet they’re more familiar since they’re featured in more games. Both animals are excellent diggers, so I found potential in having them be against each other for Maze Burrow. I liked how Muddy Mole, the protagonist of Mole Mania, was wearing glasses, and I followed a similar aesthetic for the moles in Maze Burrow since it gives them a unique appearance and visually cemented them as the villains.

Before I even began, there were several things I wanted out of Maze Burrow’s development:

1. I wanted full control over the project, down to the last line of engine code. I wanted to write Maze Burrow how I wanted and make it available in the future, with the ability to update and/or port it if I want to. Think of a game like Doom, which is on almost every platform out there. To this end, I used the MonoGame framework, as I was familiar with it, it’s lightweight, and it gave me autonomy in developing and releasing the game how I wanted to.
2. Cross-platform - I wanted Maze Burrow to be available on all major desktop operating systems, including Windows, GNU/Linux, and macOS, with potential to port to consoles. As MonoGame is cross-platform and supports consoles, this was simple to achieve.
3. More focus. In my failed past projects, I worked without a goal in mind and kept adding new features I thought would be cool or fun without considering how they’d fit into the greater vision. For Maze Burrow, I disciplined myself and set up a Trello board for the task list. Every time I thought of an idea for the game, I wrote it down in a file, but I did not create a task for it unless I thought it was essential for the current point in development. Post-release, that text file is 1000+ lines long.
4. Source control. Ever since I first started working with source control years before I started Maze Burrow, I could not live without it. The ability to see the exact changes I make, revert files, and quickly set up the project on new machines is simply invaluable. I used Git throughout the entirety of Maze Burrow’s development.

First Iteration

First iteration of Maze Burrow

My first iteration of the game was, to put it bluntly, a 90% carbon-copy of Toki Tori. The story was that the echidna is hungry and needs to feed its family. You accomplished this by collecting all the insects in each level.

You had a limited set of abilities at the start of each level, and you can sometimes obtain more uses of an ability based on the type of insect you collect. Movement was tile-based, with most ability uses equating to 1 tile. The abilities included a cloud that lets you hover in the air, “Sharpened Spines”, which allows climbing walls, “Claw”, which lets you destroy obstacles, “Spine Ball”, which lets you roll over hazards unharmed, and finally, “Form Rock”, which lets you create a climbable rock in front of you.

I designed a few levels for this iteration and ran it through a closed playtest with several friends and family members, collecting feedback through forms. Generally, reception was mixed, with many players believing that the game is too rigid, the abilities are too simple, and ultimately there isn’t much variance for creatively solving the puzzles. I also found it difficult to design puzzles within these constraints.

On top of all that, the game was far too similar to Toki Tori and was not utilizing the traits of an echidna. The “Sharpened Spines” ability was by far the most interesting one out of the bunch, so I decided to redesign the game around that mechanic.

Second Iteration

Maze Burrow’s second iteration

Before starting on this iteration, I did a lot of research on echidnas to draw inspiration on what they do. I eventually decided to make this iteration focus on wall-climbing and digging, as I felt there was a lot of unexplored potential there.

By entering “climb mode” and moving towards a wall, the echidna will climb on it; this includes ceilings. You can dig up soil and place it somewhere else to climb on, allowing you to get to previously unreachable areas. There was some exploration involved: dig away to find insects hiding within. You can also place soil on other objects, such as a bean that then grows into a beanstalk, which you can climb. In short, the objective in this iteration was to dig, build, and climb your way to each insect.

In the end, I had a lot of issues creating compelling puzzles with this design. I didn’t even know what a basic level would look like or how I’d add more mechanics while keeping the game interesting. It couldn’t possibly be fun to just stack long towers of soil through 50+ levels. As a result, this iteration was scrapped.

I eventually thought up another idea - something completely different than the past two iterations. What if the echidna instead had to protect its own burrow from moles by covering the entrances with blocks? That way, the gameplay would be very simple yet hard to master through the puzzles - which is what my original intention was all along and what I had failed to do with these two iterations.

Ultimately, I scrapped the burrow protection concept since I was picturing the blocks on the edges of each level, and I wanted something more flexible. I also wanted something more concise with a clear focus. This led me to the third and final iteration, a Sokoban-inspired puzzle game.

Final Iteration

In this section, I’ll be mixing in development history with my thought process behind several aspects of Maze Burrow.

Level 7-6, Muddy Ordeal

Pre-Alpha

On October 27, 2018, I had finalized my new design and scrapped everything in the project prior to start on the Maze Burrow that was released last year. I switched the game to a top-down perspective, using placeholder art from Mole Mania and my own hand-drawn tiles, which were nothing more than different colors. The first thing I focused on was getting the core gameplay in: running around and moving blocks. I always envisioned being able to pull blocks, which I noticed was very rare in the Sokoban genre. To this day, I’m still not sure why pulling isn’t more common, as I feel it’s a simple feature that increases the genre’s depth.

The addition of pulling required a change to the controls of the traditional Sokoban. Walking into a block to move it is no longer an option, as the player now has a choice in how they want to move it. I made it simple: move up to a block, press a button to grab it, push/pull it to your desired location, then press the button again to release it. While the blocks were constrained to tiles, the player was able to move freely - I figured this would make traversing levels easier.

To design levels, I decided to use a dedicated tool to make my life easier. I had my eye on the Tiled map editor for some time beforehand and was excited to finally put it to use for this project. I imported a library called MonoGame.Extended to load the Tiled maps from within MonoGame. Long-story short, there were some hiccups getting this to run on GNU/Linux and macOS, as I was using Mono’s mkbundle tool to cross-compile and it had trouble resolving different versions of the same dependency - MonoGame.Extended was targeting a different version of MonoGame than I was. Ultimately, I built both MonoGame and MonoGame.Extended from source to version-lock them so I can upgrade whenever I want to. This proved to be invaluable down the road when I had to trace down regressions in newer versions.

Level 1-1, Start, in the Tiled map editor

I designed several levels and implemented a few obstacles I had in mind for the first prototype of Maze Burrow, 0.1, the pre-alpha. This prototype had 7 levels along with switches, large blocks, and warps. Block movement was tile-based, but the player had free movement unconstrained by the grid. I sent Maze Burrow 0.1 out to friends and family, using forms to gather feedback like I had for past iterations. The reception was overall much more positive than prior versions, but I noticed common complaints among playtesters. The most common one was that, due to the player’s free movement, it’s necessary to make sure there’s absolutely nothing in your way when pulling a block, otherwise you wouldn’t be able to pull it - and it’s often not clear why. Another complaint was the speed of the player; levels took too long to complete simply because the player moved too slow and the levels were too large. There were also bugs with clipping into collision and blocks, and lastly, the game didn’t look so great. With the echidna having the only interesting sprites in the entire game, Maze Burrow simply wasn’t appealing to players.

I took this feedback into account and addressed several of the issues, including the bug reports and player speed. However, the free movement remained as I wasn’t convinced it needed to go yet. In the meantime, I looked for royalty-free art all over and couldn’t find anything I thought would fit the game. I hadn’t even decided on an art style and had no character designs whatsoever. I ended up contacting an excellent pixel artist by the name of zaicuch on Fiverr to get better art for the echidna, given it’s the main character. After several iterations, we arrived at the echidna sprites that exist in the final game now.

Regarding the music, I wanted something that players can listen to for long periods of time without getting annoyed or tired of. It needed to be “in the background” rather than “in your face”, with some light percussion to keep it upbeat. I came across the excellent SoundImage catalog, which consists of royalty-free music, all by the talented Eric Matyas. Some tracks I listened to had this “active dreamy” vibe - they were relaxing and soft on the ears, but no so much that you’d fall asleep to them. In short, this is exactly the type of music I was looking for. To test out each music track, I designed the level the track was intended for while listening to the track. If I got tired of it or I felt it didn’t match, it was scrapped. Fortunately, I found most of the level music I’d end up using in the final game without much hassle through this process.

I continued developing Maze Burrow and brought prototypes to monthly local game developer meetups, writing down any and all feedback they gave and considered implementing it to improve the game. One of the greatest outcomes of these playtests is a player convincing me to make the levels more concise and implementing tile-based movement for the player. For some reason, I had held onto the belief that free player movement was beneficial for so long, but after this playtesting session I couldn’t deny any longer that it was a hindrance to the game. It makes pulling so much harder, and there was no real reason for the levels to be as large as they were. Suffice to say, after that day, I redesigned all the existing levels to make them more concise and ensured that future levels wouldn’t fall victim to my mistakes of the past. I have that playtester to thank for the great improvements to the game so early on.

I kept moving on with development, making sure to spend at least 1-2 hours on Maze Burrow each day, even after a long day of work. It was difficult, but I looked forward to working on the game. Since I was able to see Maze Burrow progress over time and share it with people regularly, I found it easier to stay motivated. There were times I was doubtful about the game and I had low motivation to work on it, so I took a day or two off so I can get back to it with a fresh mindset. For the most part, this worked out well for me.

Early demos had all levels in a menu on the title screen. For the final game, I was planning to have over 50 levels, thus a menu wouldn’t cut it. I also wanted to allow players more choice in progression, and I didn’t think a menu was the best way to present these options. I was always fond of Super Mario World’s map with its many branching paths, and I decided on a similar approach with Maze Burrow. This would allow players to try out a different level or skip one entirely if they’re stuck.

World 1 in the Tiled map editor

Next, I was looking for something to spice up the gameplay every now and then - some type of “boss” level at the end of each world for players to look forward to. I wanted to still utilize the core Sokoban gameplay but add a minor action element. This action element needed to be deterministic, as players don’t like when something random hinders their play, especially in a puzzle game. I figured with the moles being the villains, why not have the player fight them? I had many ideas for how to achieve this: defending yourself against thrown rocks with blocks, a Whack-A-Mole-like game, solving a series of puzzles, and a doppleganger concept where a mole mimicks your actions in the opposite direction (Ex. if you move up, the mole moves down). Some of these ideas were complex and strayed too far from the original gameplay, so I looked at other puzzle games for more inspiration. Some time later, I watched gameplay footage of Pipeline (1988) and thought that using pipes to redirect the moles’ attacks would be a lot of fun. After the first playtest build with this new boss level, most players told me that the boss level is their favorite, so I continued in this direction.

Level 1-10, the first boss level

Development progressed rapidly, and no matter how much feedback I seeked, it didn’t seem like enough. I constantly needed more to see how effective my changes were and how players would react to the new obstacles I introduced. At this point, I had implemented the remaining obstacles, including Paired Blocks, and was working on the UI, along with still refining the first world to ease players into the game. Take Two, 1-9 in the final game, was 1-3 in early demos and was where most players got stuck. 1-2 introduced pulling, but I had not introduced the concept of moving blocks backwards to progress, and on top of that, players were still learning the ropes this early on. I learned that the /r/gamedev subreddit had Feedback Fridays, in which you can post a demo of your game for feedback, and in return give feedback to those who reviewed your game. I posted on many Fridays to see how I was doing each week. One player suggested to have each world focus on a new mechanic, as they felt I was introducing new mechanics too rapidly. After reviewing the build again, I thought they were correct: even though this was a prototype, I felt I had to freshen things up by throwing in new obstacles instead of familiarizing players with the core gameplay. It took a lot of consideration, but as evident from the final game, I ended up having each world focus on its own unique mechanic. As a result, I also modified the boss levels to utilize the mechanics for the worlds their in.

Players complained that whenever they made a big mistake, they would have to restart the entire level over again. While I enjoyed Toki Tori, it had the same issue, which is more pronounced in the significantly longer later levels. I sought out to improve this. Playtesters referred me to games such as Stephen’s Sausage Roll, which handled this by allowing the player to undo their moves. I decided this was the best choice of action, but I was stuck: I hadn’t coded anything like this before and didn’t know where to start. On the surface, Maze Burrow looks like a simple game, but there is a lot of internal state to various objects that needs to be carried over, whether it’s a Pipe Block with a rock in it, a mole that was already defeated, or a block that is midway through teleporting via a Warp. After much time, I ended up going with a system that allowed me to selectively record the values I needed for every object whenever the player moves a block, reverting to those values when it’s time to undo. I have a dedicated post that explains the system in depth, so feel free to give that a read if you’d like to learn more.

Undo in action on Level 6-9, Bumpy Road

Beta

Fast-forward to September 2019, a year after I started development on Maze Burrow. I was posting frequently on Twitter and itch.io with updates to the game without much success. Everyone else’s games looked so awesome and Maze Burrow paled in comparison; it wasn’t even a contest. Despite all the work I’ve done up to this point, I still didn’t have a tileset for the game! Furthermore, the title screen was dull and played a repetitive tune, and the wide font I was using supported only capital letters, making it hard to read text. The clock was ticking, and I wanted to release the game sometime in early 2020. I spent the next few weeks focusing heavily on refining the visuals, finding a better font, brushing up the UI, and contracting artists to get a tileset. I had no clue what I was looking for regarding the tileset, but I wanted something that looked like a burrow or cave that wasn’t intimidating. After a few attempts, I had no luck, but I didn’t give up quite yet. I eventually contacted an artist by the name of jeimansutrisman on Fiverr, and he nailed the tileset I was looking for on the first attempt! I was insanely happy with this new art and began implementing it right away.

My first real attempt at marketing Maze Burrow involved releasing a public demo of the first world. Maze Burrow was approaching version 0.7, 2020 was also approaching, and I needed to focus my efforts on getting the word out so players can look forward to the final release. I did more polish work, adding an intro cutscene, menu transitions, and overall making everything look more presentable. The demo had 10 levels, including a boss level, with the final cutscene linking them to my Twitter and promotional material. To further promote the game, I hosted a Twitch Plays using TRBot, software I wrote that can play games through text. This allowed many people to play the game at once, as well as learn about it. The reception to this experience was positive.

After the 0.7 demo was released on January 23, 2020, I worked straight towards the 1.0 release. I needed to iron out all the bugs, refine levels, polish the game’s visuals, and support gamepad input, as requested from players. Some of the early levels I designed were hardly revised over time. Since the level design is the core part of this game, I felt needed to perform some quality checks to see how I can further improve the puzzles. I played through every single level in the game starting from a blank save file several times during this development period until the final release, noting how long and the number of moves it takes to complete each one. I also noted additional details, such as whether the level was too long, and parts that just didn’t feel right or interrupted the flow. Some of the later levels went through so many revisions as I was frequently clueless what to even do for them. I often asked myself questions like “Is the level too hard?”, “Is this concept too obscure?”, and “How can I make this level not take so long?”. Some levels, including “Solved” and “Ice Mud Clash”, were completely redesigned many times before I actually had fun solving them. I also had to work within the constraints of the game and prevent every way the player can exploit the game’s mechanics; for example, skipping an entire section of a level.

I wanted to introduce new mechanics through gameplay rather than text. I found this approach more effective for me personally in the various games I’ve played. To accomplish this, I made the first level of each world have the simplest possible puzzle for the mechanic. For the following 2 levels, I gradually added more complexity to further demonstrate how the mechanic can be used.

Many of my favorite levels resulted from me designing puzzles I thought were completely impossible and ultimately ending up solving them. I found this worked out especially well for the bonus levels, as they utilize what you already know but throw in tricky moves you need to spot at the right times. Other levels were more volatile: either the level was too easy or completely impossible. In these scenarios, I either redesigned the level or focused on making it interesting. After all, if players aren’t having fun, what’s the point? “Warp Bridge” is one of the extreme levels in this camp, in so far as moving one of the warps just one tile would make the puzzle unsolvable; however, “Warp Bridge” is still different enough from the rest of the levels and manages to put a little twist on what you know about Warps. Furthermore, I emphasized keeping all levels short and sweet so players don’t get burnt out as easily. If a player knows exactly what they’re doing - for instance, replaying a level - it should take roughly a minute or two maximum for them to execute the puzzle based on how far into the game said level is. I gave boss levels more leeway for this since they naturally have more variance due to the timing of the rocks. I found this makes it so that the real challenge is in solving the puzzle than executing it.

1.0 Release

Between the 0.7 demo on January 23, 2020, and the final 1.0 release candidate build on March 28, 2020, I made 154 commits to the repository. As you might imagine, these commits contained an incredible number changes. To name a few: fullscreen and gamepad support, additional cutscenes, optimization, the credits sequence, a brand new title screen, testing on all platforms, accessibility options, and final, minor tweaks to levels. In addition to the technical work, I also wrote up the game manual and contracted professionals to create the trailer and logo, both of which I think turned out great.

The accessibility options were requested by playtesters throughout many prototypes of Maze Burrow. One included an “Auto” block grab option: move into the block to grab it, and wait to release it. Maze Burrow already had “Press” and “Hold” options, but this one was more similar to traditional Sokoban controls and thus more familiar to veterans. Another option was an input buffer to give players more leniency on their inputs; I was frequently told that the echidna pushed blocks when the player wanted to pull them. This took lots of tweaking to get feeling right.

Maze Burrow was missing replay value, and I wanted to add more through a level ranking common in other games. The rank would be determined by the number of moves and amount of time spent completing the level. Get a high enough rank for each level in a world, and you may unlock a bonus level! Ultimately, I figured this would alienate some players and removed the ranking requirement - this turned out to be a good decision, as players liked that the level stats were only cosmetic.

Finally, March 31 approaches, and Maze Burrow is released to the world!

Release

Maze Burrow was released on March 31, 2020 on itch.io and Steam, with plans for GOG and Humble Bundle, both of which rejected my application for the game. I’m glad I set up my Steam developer account a month early, as it took longer than I expected to get it approved.

Maze Burrow’s release was rough to say the least. Half-Life: Alyx came out just the week before, and everyone was still playing and talking about it. Other games released the same week as Maze Burrow simply looked more polished and appealing. On the marketing side, I still didn’t have much of a following, and I ran some giveaways on Twitter and other channels and reached out to friends and curators, giving out free copies in exchange for reviews. Perhaps I didn’t reach out to the right curators, as many of them didn’t write a review after receiving the copy. I also reached out to YouTubers but had a very low response rate. Sales-wise, though I didn’t have high expectations for Maze Burrow, it sold less than my already-low prediction, which I attribute to my lack of reach and marketing combined with the game’s relatively higher price point.

As the reviews came in, I was happy to see that players overall enjoyed Maze Burrow and had fun playing it. I wanted to create a fun, simple, and enjoyable experience, and I looked to have delivered that. Players commended the level design, which reassures me that I did a good job on the many decisions I made throughout development. Sokoban veterans who played the game told me Maze Burrow was different enough from other Sokobans to keep it interesting. The boss levels were similarly praised by players and are what I perceive to be a highlight of the game.

Did I achieve my goals? Absolutely! To me, this great reception is what I had primarily worked towards, and despite the game’s low sales, I’m very proud of Maze Burrow and consider it a success.

Patches

I originally didn’t intend to release any patches for Maze Burrow, but there were issues that players raised or I felt were just too important to ignore.

v1.01 & v1.0.2

The first major issue was keyboard remapping - it was possible to remap gamepads, but not keyboards; considering both the gamepad and keyboard control screens are nearly identical, I saw no validation to exclude this before release. Versions 1.01, followed by the prompt 1.0.2, addressed this on May 5, 2020.

v1.0.3

The second issue was audio crackling on non-Windows platforms due to the compression used on each audio track. By reducing the compression, I fixed the issue at the cost of increasing the size of each audio file; the overall net gain was worth it. I also took this opportunity to make a minor revision to improve one of the bonus levels. Version 1.0.3 was released with these fixes on August 8, 2020.

v1.0.4

While hosting another Twitch Plays stream for Maze Burrow sometime in October 2020, I discovered a minor issue with the Ice and Mud entries of the puzzle glossary, which is a menu the player can reference all the obstacles encountered in action, such as switches and so on. Twitch was all the way up to the last world in the game, but somehow Ice and Mud weren’t in the puzzle glossary! I looked into this and found out the fix was an unfortunate one-liner! I released version 1.0.4, the final revision as of this post, on October 28, 2020.

License

Maze Burrow’s source code is licensed under the Mozilla Public License 2.0, a free software license, with source code included in each purchase. The decision to release the source code from the start might strike many game developers as odd, since games are often released under restrictive proprietary licenses to maximize profits. I had originally planned to release Maze Burrow under a proprietary license, but midway into development I had a revelation about the state of the software industry and its future implications on our now-predominantly-digital society. There were also other factors weighing in on my decision:

1. I oppose DRM and did not want to release Maze Burrow with any packed inside. Even without source code, players can redistribute the game as they wish since there’s no DRM encumbering them. Interestingly, I found “cracked” versions of Maze Burrow on the web even though there’s nothing to “crack”.
2. The game is written in .NET, which is trivial to decompile these days; they would have the source code whether I liked it or not. Obfuscating the code would only make it impossible for me to debug crashes and other issues with the game on release.
3. I want Maze Burrow to live on, and there’s no better way to do so than providing the recipe to build it with. In contrast to many modern games, the majority of 20+ year old games on physical media can still be played. Since these games aren’t encumbered by DRM and server kill switches, we can look back at gaming history and preserve it for future generations.
4. Source code allows for unlimited modding potential! Players can add all sorts of new features to the game, including those I couldn’t get to during development. With a copyleft license like the MPL, I have confidence that I’d receive attribution as the original creator of Maze Burrow despite how different the derivatives may be.
5. At the end of the day, it’s the user’s computer. They own it, not me. With some software employing dishonest practices, such as installing third-party programs behind people’s backs, I wanted take the opposite approach and be transparent about what my game is doing to users’ machines. I want players to trust me as game developer, and part of that involves them being able to keep me accountable for my actions.

On top of all that, a free software license encourages players interested in game development to study how a released game like Maze Burrow works - tutorials just don’t cut it for some people when it comes to learning the more advanced concepts. When you give people power and autonomy, they can do great things; look no further than VVVVVV’s source code release!

Many of the game assets are under different licenses, and the source assets are not included, as I do not have full ownership over all of them.

Improvements

I absolutely could have improved upon Maze Burrow in many ways. In this section I’ll take a dive into how I think I could’ve done this.

Marketing & Reach

I’m going to address this one first since I believe it’s the biggest improvement I could’ve made. Simply put, my marketing was subpar! I had only a few people on my mailing list, and I didn’t reach out to nearly enough content creators, bloggers, and players. With someone with limited experience in marketing such as myself, what could I have done differently?

For starters, I could have consulted a professional to get advice on marketing this kind of game to my target audience. Sokoban games are a dime a dozen, and I should have emphasized Maze Burrow’s unique traits to appeal to Sokoban and puzzle enthusiasts alike. This game was one that broke the mold, if only slightly, while still being familiar, so those players should know about it! It would’ve also helped immensely to have a decent-looking tileset early on, even if placeholder.

I also believe I would have at least been better off with a short description that captures people’s attention: “Tired of traditional Sokoban? Introducing Maze Burrow! Fight moles, pull blocks, enter warps, and skid on ice through more than 60 puzzles to help the echidna escape its burrow!” Cheesy? Maybe so, but it’s still better than nothing! I could have posted the description on forums, IRC/Slack/Discord/Matrix channels, and all over to raise awareness of Maze Burrow’s release.

Something else I could’ve done was set up a regular blog during development, or even stream my development live. My Twitter posts were a mixed bag, showing off features or describing technical challenges, and I didn’t post consistently. Basically, it would’ve been nice to have a place players can follow me and see how the game evolves over time.

Another option I thought of post-release was donating to popular Twitch streamers and mentioning that I would like to see them play Maze Burrow in the donation message. Some streamers will say or show the donation message on stream, so if there were thousands of viewers, those viewers would learn about Maze Burrow from the streamer. The problem with this approach is people are focused on the streamer, so they may quickly forget about the game after seeing the message, especially since there’s no link for more information. Plus, it’s not realistic to expect a big streamer to play an unpopular newly released game from an unknown developer. Finally, there’s a chance you will get kicked/banned from the stream for advertising if you do it incorrectly! Could this have been worth a try? I think so, but I’m very curious to know if anyone has attempted this and what their net gain was.

Lastly, I personally believe the game was priced fairly at $9.99, but considering the expectation of game prices these days, I should have taken the price down a notch.

Overall, there was much more I could have done on the marketing side, which I learned only after releasing Maze Burrow.

Technical & Artistic

There were lots of things on the technical and artistic sides I felt I could have improved on, so I’ll briefly describe the important ones.

Technical

• If I were to rewrite the game now, I would use something like the Nez framework on top of MonoGame for an Entity Component System, albeit with the same level of control over game logic as I do now. My level structure made it difficult to add new types of objects to levels, and the generic interface I had for each object was not very flexible.
• macOS is, put simply, a pain in the neck to develop for, doubly so since I don’t have a machine with macOS handy. To test Maze Burrow on macOS, I remoted into a friend’s computer, and I ran into numerous issues that took time out of development to fix. mkbundle wasn’t properly setting the current working directory when running macOS app bundles for some reason, so I had to resort to MonoKickstart. While not completely out of the question, I don’t see myself dedicating development time to macOS in the foreseeable future.
• While the player character, the echidna, has its own finite state machine, there was no abstraction for handling input within each state. This made it more difficult than necessary to develop cutscenes, demonstrations in the puzzle glossary, and the like, as input should have no effect on the echidna in those cases. Instead of overriding actions with a blank action that takes no input - like I do now - I should have developed a common interface for input and fed in a dummy one controllable by the cutscenes.
• I decided to write my own UI system since I didn’t initially plan for much UI in the game. This proved to be a problem with screens such as the puzzle glossary and world select, which are two of the more complex UI screens in the game. I would have been better off using an existing UI library from the start. A library would enable me to make snappier and better-looking animations, transitions, and screens overall, thus helping give the game more appeal. The main menu is often the first interactable state in a game, so it’s especially important to make it look good!

Artistic

• I should have had separate sprites for the different types of rocks the moles throw. Everyone that plays the boss levels for the first time thinks that the rocks are dangerous, but it’s actually the opposite! The vast majority of rocks are harmless and simply stun the player, and I should have indicated this more clearly.
• Character designs!! The artist I worked with who drew the echidna sprites had no references to go by aside from a few pictures of real echidnas I sent him. Late into development, I wanted a brand new set of echidna sprites more in line with the rest of the game’s art. After many iterations, I still wasn’t happy with the new designs, but it was my fault, not the artist’s. If I had a character design for the echidna, I could have had the new sprites! As a result of this mishap, a few players mentioned to me that the echidna and moles don’t fit in with the rest of the game visually.
• The way I did the credits is simply not appealing, as I had trouble fitting everything. In hindsight, I could’ve kept the attribution notes in the license and mentioned where to find them. I should’ve also used a better font, as it’s difficult to read the text.
• Speaking of fonts, the primary one I chose, FFF Forward, is very old, and I couldn’t modify it to fix some minor issues with characters without the entire thing producing artifacts. The original authors were also out of reach. I tried all combinations of output settings, programs, and even operating systems with no success. In the future, I will take how recent the font is into consideration before committing to it.

Unfulfilled Plans

• Custom levels! At one point in development, I had support for loading custom levels from a menu. However, it didn’t work well across all platforms due to how MonoGame’s content pipeline loaded paths on the version I was using. Furthermore, I wanted custom overworld maps as well, but I didn’t have the infrastructure in the code to support it at the time. Finally, I wanted to host a server where you can download levels from, but I didn’t want to deal with people uploading levels with vulgar names and all the headaches surrounding it. There was still plenty of work for me to do in the base game, and I ultimately decided custom levels were out of scope.
• Placing subsequent blocks in their correct tiles would increase the sound by an octave, sort of like a “Do-Re-Mi”. In practice this didn’t sound good, at least with the sound effect I used for correct block placements.
• Dust/floor particles when the echidna walked. I added this when moving blocks, but there was too much work on my plate already and this wasn’t a priority. It could’ve brought more life into the game, especially in levels with mud.
• Locked portals show a faint icon of a mole, while unlocked ones switch to a faint icon of the echidna. This would’ve been a nice touch, reminding the player that the moles created these puzzles. Like the rest, I had to prioritize my work as there was already a lot to do, plus I was on a limited budget for art.
• Blocks that only the echidna can move through, and blocks that only other blocks can move through. I couldn’t think of any good puzzles to use them for and favored Paired Blocks and other ideas instead. Even though the blocks would go partially transparent when an object moves into them, it was sometimes unclear what was there. These are still present in the depths of the final game, but they’d likely be buggy considering they were gutted in pre-alpha.

Closing

This wraps up my postmortem for Maze Burrow. It was a long and difficult, but ultimately fulfilling, journey I learned immensely from. I definitely couldn’t have completed it without the support of my family, friends, and playtesters, all of whom encouraged me along the way. I have more game ideas in mind, but whether they come to fruition is anyone’s guess - after all, who knows what the future holds? If you want to support my work, the best way to do so is buy a copy of Maze Burrow!

I hope this postmortem has inspired you as a budding game developer, or encouraged you if you have a project in progress! Just remember to keep moving forward and you’ll get there eventually. Thank you very much for reading, and best of luck fellow game devs!

• Thomas “Kimimaru” Deeb