At the time of writing, Millie's Weird World is almost three years old. Let's have a postmortem because "postmortem" is a cool-sounding word! Oh, and learning from experience. That's important too.

The L's

For all intents, purposes, and intensive purposes, Millie's Weird World was my first foray into really making big medium games. And naturally, the first time you do something, you fail a bunch. Wow, that's brand-new information!

I Did Too Much Arduous Stuff Manually

I kept a personal changelog, which was great, but every item in it had to get manually written in. So I had to worry about forgetting to keep track of every change I made. And when I did write the changelog, the entries were funny and free-flowing. Somehow, that's not a great thing when it takes time to come up with funny and free-flowing changelog entries (especially when I'm the only one who reads them!).

But a billion times worse was the level design workflow. This was before Unity's SpriteShape, so how was I supposed to do organic and funky wall geometry? I settled on plopping in a collision shape with a big old PNG to match. Ugh. The workflow went something like this:

• Sketch out a level in Affinity Photo.
• Once I'm happy with the sketch, draw out the vector geometry and export it as a PNG image.
• Auto-generate the hitbox in Unity.
• Fix the terrible auto-generation it does.

Also, creating new Unity scenes to put levels in was very boring. Unfortunately, the levels' metadata were disconnected from their scenes and put in a big old GameController instead. Thus, despite the fact I had a template scene to start with, a bunch of time was spent reconfiguring the janky connection between scenes and their settings. So I powered through near the end to fill in the rest of the empty level slots with blank new scenes. That can't be a good sign!

I learned that computers have got to do some things for you, or the repetition gets ya!

I Overengineered a Bunch of Garbage

I was bound and determined not to use FMOD for some dang reason. Probably since it was big and unfamiliar, among other things. So I wrote a Looping Audio Clip system. This way, I could write music that played a starting bit and then looped within the clip. That's in the game, but I also wrote a system to stack these clips on top of each other and fade them in and out. Spoiler alert: this never happens.

To be fair, I may have been planning to reuse this code later for cooler stuff. But here are some more unused features that still live in the game code:

• Checkpoints!
• Toggleable switches!
• Complex event systems? (My memory's foggy...)

A while back, I heard Martin Molin of Wintergatan talk about making your design requirements less dumb, which might be relevant. There's also the old saying, you ain't gonna need it, which is definitely relevant. Et cetera, et cetera.

I learned that it might be a good idea to make just what you need for now. There's always refactoring!

I Spent Too Much Time Posting on Twitter

I should have done a simple cost-benefit analysis– was it worth the time to tweet development progress that negative four people were following? Clearly not. But I was too enamored with the concept of #screenshotsaturday.

There's got to be a reason professional marketing teams don't highlight progress on the new character sprites we made today. Were people really going to see this and go, "Wow, those are some cool sprites. I wanna play this game now"? It's all an indie-dev fantasy.

I spent too much time recording and editing videos, as well as thinking of mildly clever things to tweet. And all I got was a few Internet points from people who have probably never played the game. I should have focused on the hot dog.

All those tweets are deleted now, but I archived each one before I deleted it. I have them all in a folder named "In case of pride, break seal", since frankly... they're kinda embarrassing.

I learned that I suck as a social media marketer. And that I don't have time for it. It takes away from me actually making stuff.

I was Terrible at Git

I did not upload to GitHub. To be fair, as a solo developer, I didn't know what problem was being solved by uploading your codebase to some server (other than the issue of backups?). Even today, I'd rather self-host my code than put it on GitHub. But I was left without a Git server, which now I realize is not entirely how Git is supposed to be used. Having all your development progress locked to one machine is kinda sad.

But more importantly, my commits were huge and packed with garbage. Every day I was living life on the edge– I would only commit when changing the version number. Bleh. Is it a miracle that I didn't totally lose the whole game?

I learned Git commits should be as small as possible and be descriptive of what changed. Also you need a Git server. Even if it's not GitHub.

The W's

Alright, enough about my failures. Let's get indulgent on Super Development Wins! Does it matter that this part is less than half the length of the one about the L's? Nah, I think it's natural that you learn more from your mistakes.

I Didn't Write No Cringy Narrative

I almost added a story to this game. Long story short, I wanted to subvert the "Evil Narrator is Doing Lab Tests on You or Something" trope (you know how Portal and a bunch of old Flash games do that). There would have been two competing narrators: one the evil mean guy, and the other the cool nice guy who's trying to get you out of there. That was the original intention behind the Cat Lab area and Millie's sudden escape: she's getting broken out of an indie game cliche!

In the end, I scrapped that whole idea because good writing is hard. Not that it's a bad idea for a story, I feel the game's just better without it.

I Had a Web-Game Scope

Well, I initially started out with some form of scope overload. Tons of levels with a Mario Galaxy-like mission structure? That's fun! But after barely getting past the basic gameplay, I switched gears and set out to make 30 tiny levels. And it still took me eleven months. Dang!

Big scope isn't bad. It's just, as ten thousand other indie developers will tell you, highly not recommended (lowly recommended?) for those just starting out. I've got very little to add to this topic.

Oh, wait, I just thought of something. Maybe making tiny games allows you to keep moving on and starting fresh with your gradually growing experience. Just think if Millie were in its fourth year of development and I had to keep ripping out terribly structured amateur code. Oh no!

I Finished Something

This is a fact. Insert some flowery speech here.

Conclusion

Millie's Weird World may not have been a huge hit (or even a small hit), but it was a win for me. Why? I learned stuff. The end. Thanks for reading.