TYPESTROID is my latest project - an asteroid-avoiding game where you type words in order to avoid the asteroids. You can check it out at https://lukehut.itch.io/typestroid.

When I first got the idea to build a typing game, I did some research on typing games to try and see what was out there - overwhelmingly, the landscape seemed to be "type the word on the object to destroy it". I wanted to build a typing game that played a little differently, so instead I made TYPESTROID - where you type a word to move your ship, but can't actually interact with the objects coming at you (other than avoiding them).

What went well:

Focused genre

TYPESTROID is a typing game. You see words, you type them, things happen. Having something that's so well-established and not unique at all to work from meant that I was able to build the core pretty quickly (type word, see result) and spend more time iterating on making the game intuitive and playable. It was pretty worth it - the game originally started out in first person view, and was kind of obtuse to play:

Music and sound

This project was the time to apply what I learned working on sound for Vinny's; I hired Liam Sauvé to do the music and sound work for me. This was fantastic - Liam did what he's best at, and I got to focus on other parts of the game instead of spending a day making terrible sounds (and as a bonus, I got to remove a bunch of dread from the project).

What didn't go well:

Closing thoughts:

I set out to build a typing game, and while I was building a typing game I also realized that building typing games is pretty easy (but that doesn't mean not satisfying). This project was pretty well within my comfort zone, which gave me some good opportunities to experiment with other areas, which I can apply to new projects going forward (for example - this project has the clearest on-screen text out of anything I've built in Flash, using techniques I plan to bring to all new work).

That's a wrap! On to the next one.

Vinny’s Snack Shack is a time trial match three game that I just wrapped up. You can check it out on itch.io at https://lukehut.itch.io/vinnys-snack-shack.

What went well:

Art

I've been working on getting better at making programmer art, but I am definitely not an artist. For this project I got to collaborate with my friend Katie Sheedy, who is much better at art than I am. This is what the game started off looking like:

And then came the programmer art:

And then the actual artist art:

Finding a tutorial

Sound effects

I'm terrible for making silent games, and this project was no exception. When I realized that there were no sounds for anything that happened while you were playing, I decided to fix the problem and recorded my own sound. I've got this filed under both "what went well" and "what didn't go well" because even though I have sound now, I wouldn't say that it's very good or great. Something to improve for next time.

What didn’t go well:

Scope management

The game evolved a lot over time as I tried to figure out exactly what to do with it:

This led to a pretty protracted development period, because each time the theme or mechanics shifted I'd need to rework bits of the game (and even now, there is an entirely unused name entry screen sitting in the project files..). The problem was that most of them weren't fun or bite-sized enough to be doable, so I spent a lot of time iterating because my scope wasn't constrained enough or I wasn't sure which pieces of the game were "must haves" vs. "nice to have". It worked out (I finished the game), but as someone who builds games in their spare time scope management is an ongoing problem for me.

Next time maybe I'll just use a game generator and commit to building whatever comes out.

Sound

Closing thoughts:

I'm pretty happy with how this project turned out - it was an opportunity to learn some new things (sound), collaborate with someone (art), and also build in a genre I've never built before. I also found at the end of the project that I was beginning to generate a lot of interesting ideas on ways to explore the match three genre a little further, or mash it up with others - it might be a little while before I come back to building match three again, but I'm glad that I've got this one under my belt now.

Perfidia Pass is a short RPG that I've spent the last few months working on (ever since Spacefight wrapped up); it has two endings, so I didn't want to spoil anything by going into too much detail here.

You can check it out on itch.io here: https://lukehut.itch.io/perfidia-pass.

What went well:

Reducing scope

I'm not great at controlling scope. The original idea that Perfidia Pass grew out of involved two large towns that were fully fleshed out, a merchant system, a battle system, and a weird shadow economy where you traded valuables between the two villages. I might still come back to that idea, but the scope was way way too large for me to make something that was at a quality level I was happy with in the time I had available. There was a lot of iteration involved in working towards Perfidia Pass's story and structure that it has now and I could have reduced the scope a little earlier, but overall I'm pretty happy with how it worked out.

RPG Maker

RPG Maker MV is the first version of RPG Maker that worked on a Mac; I actually started this project because I remembered having so much fun working with RPG Maker 2k that when it came to OS X I knew that I had to build something with it. There is a brief bit of a learning curve and you definitely get out what you put into it time-wise (for example - Perfidia Pass took 65 hours total, and each room and area was probably at least an hour each to design and flesh out), but it's a great tool for quickly putting together a fairly complete RPG. I even stripped out a lot of the regular RPG trappings in order to just get the systems I wanted, and the tool didn't stop me or hinder me from doing that, which was nice.

Using default assets

I pre-ordered RPG Maker MV in my excitement over it coming to OS X - because of the pre-order, I got a couple of asset packs which were what I used for all of the art in Perfidia Pass (other than Jennifer - I generated her using the built-in character generator). An easy way to not run into art problems is to lock yourself into using one set of art and just never deviate (although it does mean that sometimes you have to create a fairy signpost because you don't have a signpost sprite).

Tooling

Because I was using a single IDE that was designed for one thing only, it was trivial for me to generate builds whenever I wanted, as well as put the game into different states I needed it in in order to debug. I was also able to export a mobile version of the game so that I could take it out on a phone for playtesting, along with exporting for windows machines whenever a windows friend wanted to try it out. The fact that RPG Maker MV is building nw-js apps helped too; you could easily pop open a webkit debugger and poke around at what was happening at each step when you needed to. Which brings me to...

What didn't go well:

RPG Maker MV's plugin system

RPG Maker MV has a plugin system, where you can attach arbitrary JS plugins to your project. This is a really good idea in theory! In practice it's basically undocumented; most of my customization work came from reading through the source code for their systems and then forcing my code overtop of them. I mostly developed my plugins by reverse engineering other plugins or doing a lot of trial and error work with the IDE's built-in reload functionality (which was a godsend once I realized it existed).

The fact that RPG Maker MV supports plugins is great, but the way that you write and work with them could be a lot smoother and better documented.

Writing

I am not the best at writing, and this project was text heavy and really drove that point home. I spent a little bit of time looking for writer collaborators at the start of the project, but when I didn't find any I decided to just roll up my sleeves and do it myself. This worked, but it took a lot of iterating in order to find something that plausibly made sense - I could have moved much faster on the project if I'd had something who was a decent writer helping out from the get-go. I'm chalking this up to an opportunity to skill build, though.

Finding time

Around hour 40 (month 2), my interest in the project started to drop off and I knew I needed to finish it fast. Unfortunately - when you're losing interest in something, you're not typically the most motivated to spend a lot of time on that thing in order to get it out of the door. The polishing phase is huge and takes a lot of time! I'd almost argue that it's where you get the most bang for your buck, so it's pretty important to be able to put a lot of time into it. I ultimately had to buckle down and say "I don't care if I'm happy with it at the end, I am locking this down to what it is and finishing it". This worked, but ideally the project would have been short enough to not run into any feelings of "this is taking too long.."

Closing thoughts:

Overall I'm pretty happy with how Perfidia Pass turned out (and it was cool that Steam tracked how long I'd used RPG Maker for; I can say this project took 64 hours!). It was a good exercise in writing and level and world design, while also absolving any art anxiety by providing enough assets for me to work with (usually without too many speedbumps, other than the fairy signpost). 

I was also pretty happy with RPG Maker; now that I've sunk some time into wrapping my head around the plugin system, I feel confident that writing plugins for my next project will go much more smoothly (and I have some reference implementations now). While my next project might not be an RPG Maker project, it's definitely something I'm happy to add to my toolbelt for the next project that it makes sense for.

On to the next one!

(but if you want to play this one, it's at https://lukehut.itch.io/perfidia-pass.)

Spacefight is done - even though there's maybe still some better art on the way, it's as feature complete as I'd like it to be in order for me to wrap it up and move on to other projects. Time to think about it!

What went well:

Doing my own art

I'm still focused on doing my own art until I hit the point where something is done and I'd like to see about getting better art - that worked out well this time. I'm getting faster at making art, and because of the space setting I didn't need to spend a lot of time on backgrounds or making anything super intricate. I spent a little more time than I should have on some of it, but I'm counting that as skills practice. Overall I'm pretty happy with how my art turned out for this - even if my new art doesn't come through, I'm fine with wrapping this up as-is.

Automated tooling

I know I called this out in my last postmortem as well, but staying focused on automating and keeping my builds as simple as possible has continued to pay dividends. This was the first project where I generated a build for Windows, so I got to spend some time setting up a VM and making my Makefile cross-platform. I can generate a build on OS X or Windows (under Powershell) by just getting to the project directory and running `make package`, which has been pretty great. There are still some kinks to work out when it comes to packaging up the files and getting them onto Dropbox, but overall the process is fast and pretty efficient.

Controller support

This was my first game that supported a controller - I started out using KeyActionBinder, but ran into problems with it not recognizing the Logitech F-310 under OS X. That was a snag, and I ended up having to sit down and bang out my own simple controller class, but overall it worked out - I now have a small library that gives me good support for the PS3/4 controller, Xbox 360/One controller, and the F-310 on OS X and windows (or at least, the windows machine I tested on). I'm looking forward to being able to use this to give myself a headstart on my next project that involves a controller.

Music

Adding music to the game made it feel a lot more real, and only took maybe half an hour of searching Incompetech's royalty free section. There's a huge collection of music available there, and it's still growing - I'll definitely be using it on my next project as well. Bfxr was also great for getting good sound effects I could move forward with quickly - they also made the game sound a lot more like a real game, vs. just being a silent experience.

Trimming down screens

When I circled back to polish the UI, I also realized that certain screens didn't need to exist - so I removed them. Not only was that a good opportunity to remove some code - it also made the screens flow better in general, because there aren't any screens that aren't 100% necessary now. This is something that I'm going to be doing with everything else I make too, because the streamlined experience feels a lot better.

What didn't go so well:

Scope control

I ended up having to cut out a lot of what I had planned for Spacefight in order to get it finished before I ran out of attention to spend on it. I rationalized it by saying "I can put that in spacefight 2" (and if I ever make that, I will) - but I definitely had a much much larger scope planned than what I ended up finishing with. If I'd honed my scope a little better going in, I think I wouldn't have felt quite so overwhelmed in the early stages.

Time management

Spacefight was supposed to take three months, and if I'd focused on it and given it the time it needed - it probably would have (albeit at the reduced scope I mentioned earlier). Instead if took something closer to 9 months because I got distracted by other things a lot - I'm not super choked up about this, but I think I could have enjoyed both building Spacefight and the fun distractions a little more if I had just buckled down and finished the job a little faster vs. letting it languish.

Idea too complex

"Local multiplayer split screen space dogfighting game" is how I described Spacefight when I first sat down to plan it out; that's a lot of adjectives that each need implementation time. I'd never done local multiplayer, split screen, or dogfighting - which meant that instead of being able to focus in on one small mechanic and hone it into something super polished, I had to spend time learning and implementing all of the supporting systems (like controller support). While overall the code is a net gain because I can use it for other projects, this definitely blew out the implementation time because before I could build a space game, I needed to first invent the universe.

Closing thoughts

Overall I'm pretty happy with how Spacefight turned out - this project taught me that the budget I need to manage on the things I'm building is made of attention, not money. Going forward I'd like to experiment with focusing on smaller, more polished games with a little less complexity - but we'll see how that goes in practice.