Disorderly Robotics Web game

Disorderly Robotics GMTK 2018 Submission

I did it! I finished my first game jam! And submitted the game! Shear exhaustion and unsatisfaction has never been so rewarding.

I took part in the GMTK Game Jam this year, mainly because I'm an avid fan of Mark Browns online game design series, and it was being held on my last summer weekend. What else would you find me doing on a special weekend like that?

The theme for the game jam was announced at 10pm on Friday evening. We would have 48 hours to complete design, produce and release a game based on the theme. This year the theme was 'Genre without mechanic', which, I'll admit, I was originally pretty daunted by. This theme meant we had to make a action/fps/adventure/platformer game (the genre) without a very core mechanic associated with the genre. So a fighting game without fighting, or a endless runner without jumping, etc... I saw some very creative ideas submitted, you can find and play all of the entries here.

After a couple minutes hours of designing and sketching, I finally came up with the idea for an arena brawler without any player control. Eventually I narrowed this down to a robot wars style arena, where players have to build AI robots that battle it out to the death. The working (and final) title I gave it was 'Disorderly Robotics'.

I wanted to make this game cross-platform, and minimize the time required to start playing. It was these reasons I decided to focus on making it browser-based. It's much easier to distribute across the internet if the game simply plays in your browser, without the need to download. It didn't take long to realize I wanted to use the Unity engine. A combination of familiarity, time restraint and pre-made physics systems swayed me over from just using WebGL with Pixi or something. In all honesty, I had sort of prepared to use Unity anyway, as I made sure to install it on my setup before the jam started.

The first part of the game I made was the menu... Because why not? What, you start with sprites, core gameplay or even basic functionality? Ptfff, tbh you're probably right, but shush. I wanted to make the menu somewhat basic, with just highlighted buttons and a couple images. No point in lavishly setting up a game that doesn't exist yet. I probably spent a full four full hours on the menu, far more then I had anticipated. So what, that's 4/48 hours gone already. So far so good. At least it turned out alright. You can actually use both the mouse and key control on the menu for some reason, I don't really know why.

Right, time to make some gameplay! Or not. Let's draw some pictures. :)
I hadn't had much experience in using spritemaps, so this time-restraint, stress-inducing weekend seemed like the prefect time to pick up a new skill. All the sprites are arranged into a single 100x100px texture, which is then carved up into 10x10px boxes. Each sprite is ripped straight from these boxes and then plastered across objects on-screen to leave something of a resemblance to a robot.

Anyway, where was I? Gameplay, ah yes. No. Time to make a robot editor.
I had attempted something like this before in Unity, but I'd never quite finished it. So I reckoned I could just follow those steps again, but refine them a bit with my slight better grasp on game programming. There is a 2d array that stores all the tiles in the editor. Each tile is simply a Id for the block type, a rotation and an ID for if there is a special block in front of it (The wheel, saw, etc...). Then, as the user edits the robot, the variables are simply swapped out for the selected block type.
When the user saved the robot (after click back or play), the list of objects is stored using Unitys built-in PlayerPrefs. I actually used PlayerPrefs2 to store arrays. I had to convert the 2d array into several 1d arrays, but that was fine. Then, when the robot is loaded again in the editor, it's pretty easy to remap all the tiles. Meanwhile, loading a robot into the game is much more interesting...

Finally, could it be? Is it really time for some actual... Gameplay development? Indeed it is, only maybe 20-25 hours into the jam. Someone seems to have their priorities straight!
When the fight starts, the player's custom built robot has to be generated, along with the enemy robot. This is actually not that difficult, because once the arrays are loaded from the PlayerPrefs, I simply have to read of the tile IDs and the rotations, and loop over the robots data a few times. During the first pass, I instantiate in the relevant blocks in the correct place. These blocks are saved as prefabs, and have the correct physics, colliders and data already assigned to them. During the second pass, all the new blocks are linked up using fixed joints, so the robot doesn't just fall apart. Helpful! Finally, on the third pass, all the special blocks which take another tile in front of them are looped over, and the correct part is attached on. Ta dah! We have a working robot! Of course, there's other parts like wheel joints, sin wave rotations and block health systems behind the scenes as well, but that's all pretty boilerplate...

Now that robots are fully fleshed out and compete, next on the to do list is a couple of enemies. Okay, I'm going to be honest with you. I knew time was limited, so I cut a few corners when implementing enemy robots. No joke, I literally just made some robots in the in-game editor, stole the generated robot from the arena, and simply put it on the other side of the arena and flipped it. Yup. It was that easy. I quickly scraped together several (7) enemies that slightly resembled some sort of difficulty curve, and changed up their corresponding arenas to give the game some variation. And that's the gameplay done!

Of course, drastically cutting corners like this was bound to lead to some problems down the line, but in my mind at that time 'there wasn't going to be any down the line, because the jam ends in 12 hours'. What this meant was if I changed anything, fixed anything, touched anything related to how robots are implemented or generated, I'd have to redo all the premade enemies again. You guessed it, I had to go ahead and touch something, didn't I?
I changed how much power is required by the fan, from 2 to 3, for balancing reasons. That was great and all, but what about the premade robots? Most of them where actually fine... except the last one. At this point, I'm desperately running out of time. Instead of remaking the bot in the game editor, I shaved a couple minutes by directly editing the robots prefab. I duplicated the generators at the back, and reorganised the resulting fixed joints. Problem is, I didn't do a very good job:

Okay, phew. That's pretty much everything. Oh wait, sound. With less then two hours left, I believe it's about time I got started on a major part of the entertainment spectrum.
The theme music was first on the list. Metal. Royalty-free Boom. Done. Stolen successfully Credited in the description successfully. Love you TeknoAXE. Okay, now I needed some obvious menu sound effects, you know, the clicking, switching, whatever. One or two sound effects would do for that, adding them in was just a means of playing the sound whenever a button was clicked. Now for my personal favorite. The robot destruction sound effects, ohhh, they're pretty satisfying. Frank Bry provides great real sounds effects that were absolutely perfect for the job. I can't thank him enough. I used his Mangled Metal SFX video for all the destruction. Anyway, each time a block is destroyed, a new object is instantiated in which just plays one of the 12 or so metal crashing sounds. It actually didn't turn out too bad, with enough variance to pass for uniquish sounds each time.
Now with the sounds done, I can tell you they make a big difference to the games atmosphere. I had had thoughts of releasing without sounds, but, oh, am I glad I didn't. Could've done with some more explosion sound, though... Ah well.

Ted Johnson - 11/09/18