Mechjam II - EMR Postmortem

Well, that has to be one of the most enjoyable and engaging gamesjams I've done, and I was barely even active for much of it!

I initially joined Mechjam II on a whim, as I'd always wanted to make a deep mech simulation game but have too many projects to commit to one as a serious endeavour. With that mindset, the first thing I felt like doing (to really scratch my Doing It Different This Time itch), was the music. So when the jam kicked off (after I'd finished the dayjob, at least), I set about making the music for --what in my mind was still-- a game that would be my own pet Mechwarrior 2. I'm not a fan of taking genre-defining games, just changing their setting a bit and calling that a game design; but I knew I would organically find the twist that would make it something new.

Game, What Game?

The first week passed and I still just had a Jeehun Hwang inspired music track and a rough-as-heck Blender model of a mech. No gameplay prototypes, no ui mockups. Not even a Unity project at this point.

I almost considered just throwing in the music and/or mech (if I could finish it) into a collab with anyone that could make use of them. Then a discussion on the discord reminded me how I'd always enjoyed the more industrial, civilian angle to mechs and hey- why not make some kind of emergency rescue vehicle thing? I've also been wanting to make a game based on the original Thunderbirds for goodness knows how long now. And thus inspired, I started honing the mech design; considering attachments and utility and aiming to make it look like a thing that actually could be built and driven. Originally intended to be more like coast guard than fire service, the setting shifted further into an urban surrounding as I also got inspired (this time by the LAPD Future Cop soundtrack) to make the menu music.

Priorities

With just three days to go, I needed to make a call. Am I actually going to push something out the door here? I still had no project, an (almost) finished (unrigged) 3D model and a bunch of music tracks. And a picture in my head of exactly what the title screen would look like. It's pretty much textbook how-to-dev-a-game-like-an-idiot, but I was having fun so I carried on doing so! That's what it's for, after all. But yes... not a recommended workflow.

Luckily I had the last 2 days off work and was free to get stuck in for most of them. I spent the whole of Monday morning rigging up the mech in Blender and animating it... then completely hit a wall getting that into Unity (having not done IK since my 3D Studio Max days). So I redid it again in Unity with that life-saving IK plugin (thanks Dogzerx!) and thankfully it pulled through. By the end of the evening, I had a walk cycle! And my mech could throttle up and down to walk around an empty box in the sky. It still didn't do anything, though. And there was nothing to do it in.

Dawn of the Final Day

The last day ended up being a bit reminiscent of my old-school Ludum Dare days -- back before I was a supposedly responsible parent and could abuse my liver and my eyeballs to five in the morning. I decided I only had time to implement one of the mech's tools, so I went with the fire hose, as I could clearly envisage how the fire-fighting mechanic could work. If I had time, I would also implement the grapple winch to pull things out the way (physics never gets old) and then finally the excavator arm... maybe.

Dev on the fire/water system went pretty smoothly. Why? I've done it before-- at least, systems using all the same components. If you're ever trying to scope unknown timescales on a tight time budget, the best way to know if something will take as long as you think it should is not how complex it is, but how much you've done it before.

I'd earmarked a bunch of assets to build a quick background city, and Fukuoka by ZENRIN turned out to be a pretty perfect match. It felt like a real city (because it is; it's based on part of real-life Fukuoka, here: https://www.google.co.uk/maps/@33.5865859,130.4071314,438a,35y,302.77h,55.56t/da... ) but had a sort of semi-toon style that didn't clash too much with the toon renderer I was using (and, of course, it was Japan). Unfortunately, the asset was split up and meshed in a really odd way, which made adding colliders to the meshes a little inflexible... but it got me out of the time-consuming task of making a city, so I could go back to focusing too much on the mech.

Incidentally, those markings on the mech? Not actually part of its texture; they're TextMeshPro objects sitting on the surface. There were some disadvantages to this approach, but the main thing was it was quick and easy, and it was dynamic so I could number the mechs without a lot of texture duplication or faffy uv layers (I'd originally imagined having multiple mechs that you can spawn out and being able to switch between them or something).

This thing is comprised of dozens of separate objects, each with pivots set so that they could translate back and forth with servos under player inputs. That I never got around to implementing :/

Roboteers.... CEASE!

When midnight hit (and with the knowledge that I had work the next day), I knew I had to wrap things up. A few quick features like the foot stomping sound and the siren were worth that last minute rush... but I did finish rather later than I'd intended. I'm on UK time here, so the deadline at 8am was pretty much the start of my next day at work.

Overall, I was pretty happy with how it turned out. Thanks must go out again to the free assets that got me over the line and ensured it was at least fairly presentable for you guys to play, despite my slouching and constant procrastination on other things (like parenting). Also, a big shout-out of course to the friendly discord community that were always there to keep motivations up.

It's been a blast, and I hope to join the next one!