Mega Man Maker

(This project is currently… in a deep slumber.)

A project began at the end of my freshman year in Summer 2016 as a throwaway line between a friend and I: “what if Mario Maker, but for another IP, like Mega Man?” I had a good amount of Unity experience in the bag, and previous years of Java had me feeling pretty familiar with the C# language syntactically. However, nothing could have prepared me for the undertaking I had given myself that Summer, and over the next two years, I would plug away at a project that would grow in size exponentially the further I got into it. To this day, it is my baby, but it has been in a state of neglect for too long, asking to be picked up again and continued. Here is the tale of Mega Man Maker.

The first three or four months of the game saw rapid production. I had successfully created Mega Man in Unity, complete with custom 2D collision written to mimic what the NES was more-or-less capable of achieving (as in, strings of basic arithmetic and condition checks). It plays pretty damn close to the original NES Mega Man, and I’m still proud of that since I had never done anything like that before (or really after). In fact, I had talked about the project at this point in a blog post here.

Next came some pretty fun stuff - blocks and custom levels. The whole aim of the project was to be an NES Mega Man sandbox on PC, so level data had to be free from any sort of presumption except for “blocks exist”. Will a level contain empty pits, ladders that exist beside each other for no reason, or flat expanses of nothing? Answer: yes, to all of it. A good level editor would never restrict the player, but supporting such an endeavor meant covering a lot of use cases.

With that in mind, I had built a small database of block types and accompanying images and ID’s, which after not long ballooned into a long string of hundreds of entries containing every single damn tile out of the first Mega Man game. And I had five more games still to add. And I hadn’t even gotten around to entities yet, like enemies or pickups. Oh, wait, and Mega Man has powers the player can switch between. Yikes.

I decided to sidestep all that complex stuff for later, and instead focus on getting to an MVP (minimum viable product) state. Doing so, in my mind at least, meant being able to save and load level files. I had decided on going the route of “as compressed as humanly possible” with this one, since I had also wanted to support players sharing and downloading hundreds of custom levels with one another. My solution for this problem was to go the route of storing binary level data – reading the level from left-to-right, bottom-to-top, each block ID (ushort) being scanned and written to an MML file (“Mega Man Level”), along with information like stage and author name.

However, this would produce files in the high kilobytes (and even megabytes), and a lot of it was repeating 0’s (no block) or ID’s for floors and ceilings. The solution was to implement a form of RLE compression, a way to losslessly compress hundreds of the same block data to something that reads in binary like, “the block ID ## but N number of times”. This brought level size down to just a handful of kilobytes at most, and that’s for huge levels that could not be as easily compressed. Bingo.

Next came the level editor, and unfortunately, this is where the project still is now. I had spent months toiling over UI designs and theorizing what the best way to format hundreds of blocks for the player to choose from could be. This is where the project ran out of steam for me, about a year ago as I type this (January 2019), as stringing together the level editor to a usable state took an ungodly amount of work and is still incomplete. If I ever return to the project, this is what I will be working on, hopefully with much more insight as a developer who has more years and projects behind their backs than I did before. What is implemented into the game now is technically usable, but it’s in a heavy “under construction” kind of state.

My takeaway from the project? Binary files and compression are really cool and can look pretty impressive when done right, especially as a freshman project. Making a game is easier to do when someone else has done all of the design work for you, so if you ever need a game project, make it “copy this game as close as you can” and you will learn a lot. Oh, and maybe the most important one: overscope responsibly. Never let a solo project balloon in complexity unless you have it under control and were expecting it to happen, and NEVER EVER overscope a group project, because now you’re wasting other people’s time and not just your own!