Chemical Chaos ~ Ludum Dare 37 (One Room)

It’s been over a week since the last Ludum Dare competition ended. This time round, the theme was ‘One Room’, so naturally I made a game about a bunch of chemistry experiments that you have to run around and keep going. This decision was somewhat motivated by the fact that everyone I’ve ever talked to loved chemistry at school and would do anything to do a titration again. After all, knowing your market is half of the battle in game development.

The idea I was going for was a game where the player would be constantly running around, getting one experiment in working order, to find that another couple are starting to fail. It’d ideally be a very hectic game made up of several really easy minigames. For maximum effect, I’d need to create quite a few different experiments; however, I only had enough time to make three to a decent level of completion. I’d also have liked more time to polish some of the game’s aspects, mainly some smaller details like particle effects and other signposting to make it easier to see the status of experiments from afar.


Don’t ask why it turns from blue to red.

The first experiment was a distillation – in real life, you do this experiment to separate some liquid from a solution (you probably used it to purify water in school). The controls are simple – just mash the mouse buttons or controller shoulder buttons to turn down the temperature, as shown by the thermometer. When this experiment fails – when the thermometer is full – there’s a large explosion for no apparent reason.


The most important part of development – particle effects.

There’s a couple things I’d like to improve about this minigame. First of all, the apparatus should probably start to smoke and rattle around a bit as it’s getting close to exploding. And on the subject of explosions, I think the explosion needs to have more impact – sure, all the equipment goes flying and there’s a bit of fire, but I might add more flames that stay alight for a while on the table, and possibly violent screenshake when the explosion actually happens. On the plus side, I was very happy with the ‘reaction cam’ that pops up in the corner when an experiment fails.


John is the best video game character this year.

The second experiment was the good old sodium-in-water one, which as we all know, causes fire. The gameplay for this one involves pressing left click/LB to decrease the amount of sodium and potassium that materialises above John, the water tank, and right click/RB to spawn more. If he gets too little metal, he’ll get bored and will fall to sleep and if he gets too much, he’ll get scared then eventually die. Please try not to kill John.

There are a couple of problems in this screenshot – first of all, the sodium blocks sort of clip through the bottom of John instead of bursting into flames on the surface of the water, something I didn’t catch happening before submission. I’m also confused what may have caused it as I touched none of the relevant code for this between getting the feature working and submission. Secondly, the instructions for this experiment are incorrect, as I seem to have put up the instructions for experiment 1 instead; this was probably just an oversight. They’re both easy-to-fix problems, but they could have easily been avoided.


I’ve left my mixtape in all three of these Bunsen burners.

The third and final experiment is the Flame Test, which tasks you with carrying different elements into three flames. Each flame expects the element that makes it burn in a particular colour, as dictated by the chart next to the Bunsen burners and the base of each burner. All other elements go in the bin; if you’re too slow trashing elements, you’ll fail the game, and if you put the incorrect element in a flame, that flame will go out and losing all flames results in failure too.

In hindsight, I should have made the Bunsen burners explode when you get things wrong. It’s basically the only thing wrong with this minigame.


For the flame test minigame, I invented new elements so I could make more interesting flame colours. There’s a line of posters along the wall with short descriptions of them all. Given how long it took me to think up the new element types and make posters and models for each of them, I would have liked to make more games that utilise them all, but unfortunately I didn’t have enough time. One game idea I had was a solution-mixing table, which had a bunch of coloured solutions and you had to make the requested colour. However, it’s not really an experiment that’s easy to make hectic and if you’ve ever dealt with transition metal ions yourself, you’d know that this type of colour change chemistry can be a little complex. For the two people that got that tortured chemistry pun, I’ll see myself out.

I was, however, pleased with how the game came out graphically. The only issue I had was trying to make a roof and windows; doing that messed up the lighting, and any amount of time trying to work out Unity’s area lights and baked global illumination seemed to be wasted in the end.

You can give the game a go by visiting the Ludum Dare page, where you can vote if you took part in the competition, or directly on my Google Drive.

Ghost Party ~ WGD ‘Spooky (2016)’ Three-Week Competition

It’s been a while since I’ve properly sat down and made a game, apart from the Zero Hour Game Jam, which I entered with an entirely broken game about shooting ghosts with a flashlight. Today, after having three weeks to work on a game, I decided to start one the day it was due to be shown.


My Zero Hour Game Jam entry, the lesser of my two games about flashing ghosts.

I decided that my Zero Hour Game Jam entry had a few flaws, the main one being that you magically die after about 30 seconds every time without being visibly hit by anything. You hit ghosts by aiming straight at them; unfortunately, this means you have to aim the centre of the screen at them as the game uses a raycast, but there is no crosshair so it’s almost impossible to tell if you’re hitting the mark except that the ghosts turn red.

I did like the idea of hitting ghosts with a flashlight though, so I kept it and made a brand new game today with a different art style: crayons. You might think I’m crazy, but when you’re time-constrained, it always helps to think of quick hacks to make things easy. I could have just as easily used normal coloured pencil to draw everything, but a bad artist (or in this case, a rushed one, although I’m not exactly Picasso to start with) will always make coloured pencil look crap. On the contrary, when someone thinks of wax crayons, you think of a 5-year-old’s drawing tacked onto the fridge. Essentially, wax crayons have a very low skill ceiling and I exploited the heck out of that. It made for a very consistent style and I actually really like it! It’s similar to the style I used for Tappy Dev, but I think it’s possibly better.


Yellow ghost is far too happy.

The general idea is that ghosts spawn from left and right, and it’s your job to shoot them down with your flashlight by clicking on them. It’s better than 3DSpooky5Me (my 0h game jam game), in that you can see the mouse cursor to indicate where you’re aiming. The ghosts are also much cuter.

Given more time, I’d go back and make sure the proportions of all the objects in the game were consistent. As you can see, the ground’s outline is very thick compared to that of the ghosts, despite being drawn using the same crayons. I’d also change the design of the gravestones and the large tombstones, since my friend said they look like printers. While the thought of a haunted Konica Minolta fills me with glee, I might save that idea for when I’m in a real jam.

I also need to change the mechanics a bit. Similar to the 0h Game Jam, I didn’t make the flashlight affect an area, but stuck with a raycast; having the flashlight hit all ghosts in its range when flashed would open up the possibility of combos and make the mechanic feel more satisfying when you line up 5 ghosts in the same flash. Currently, the score increments by a strange formula I devised based on the speed, sine-waviness and z-distance of the ghosts, but I feel this should be better communicated to the player, as it’s difficult to even notice how many points you got for hitting one. Furthermore, one thing the game lacks entirely is a lose condition, which I was minutes away from getting in the game, but was hindered at the last moment by having to go to the WGD event in which I showed the game.

But the biggest and funniest problem in this build is the unintentional and bewilderingly fast escalation in difficulty. Above was a screenshot from about 30 seconds in, but the following one is from a couple minutes in:


Points for spotting the cameo appearance.

At the start, the difficulty increases in a linear fashion. Every 5 seconds (although I’d planned to change it to every 20 or 30 seconds and forgot), the time interval between ghost spawns goes down by a fixed amount. It does this 10 times, then it starts going down in a geometric progression. You can see where this is going. Every 5 seconds, the time between spawns is divided by 1.2. Then you end up with a ghost party. It’s a classic example of “oh I’m sure this arbitrarily-picked number will be fine”.

At the early stages of development (read: while zoning out in a lecture this morning, thinking about spooky ghosts), I considered adding some element of a rhythm game into this, but as you’ll find out there is no sound whatsoever. It’s somewhat inspired by the Sneaky Spirits game from Rhythm Paradise (or Rhythm Heaven, for you Americans). I wanted each ghost type to have their own behaviour, but this didn’t come to fruition and they instead all follow sine waves of varying frequency and magnitude.

I wanted the spiky green ones to zig-zag, the puffy white ones to flutter upwards and fall back down a bit constantly, and the blue ones were going to have Pacman-style grid movement. The pale ones were going to have an animated tail that wiggled around and the rare Drifloon (please don’t sue me, Nintendo) would’ve occasionally grabbed a headstone with its tassels and flown off with it. Maybe next build!

All things considered, the most important lesson I’ve learned today is that I should drawn with crayons more often. It’s really easy and looks pretty nice, especially with the Paper Mario-style aesthetic. It’s also not really apt to keep referencing ‘today’, but I’m not a clock so it’s fine. You can download the game here.

Game Design Tips #14 – [Unity + C#] Persistent Data

Today I’m gonna talk about how you can save data to disk and read it back later. Unity has a utility built-in for this – they’re called PlayerPrefs – but for anything more than perhaps options and preferences, you’re going to want a more robust system for saving data between scenes within your game or separate game sessions. This is where I jump in and throw a bunch of fancy C# things at you! Note – this system should work on standalone platforms such as Windows, Mac and Linux and mobile platforms, but it won’t work on Web Player builds or platforms such as Samsung TV. I’m not sure if it works on console platforms since I don’t have the resources to develop for any of them and the internet has been unhelpful in this regard, but oh well. Time to get started!

There is a lot of motivation for wanting to save data to disk; high scores, player progress, and player-customised assets are all types of data we want to make persistent. I’ll be showing you how to achieve this in Unity using C#. To do this, we need to package up the data we’re going to save into its own class.


We’re going to put this portion of code right below the SaveStuff script, which we’ll be writing next. For the SavableObject class, we’ve made a bunch of variables that we want saving to disk. In this example, imagine there’s a guy named Bob, and that he wants to remember his own name, how many bananas he’s holding, how long he’s been dancing (measured in hours – he’s an active bloke) and whether he’s made of wood. From this, we can only assume the following: he’s forgetful, probably a fan of potassium, potentially flexible, and doesn’t remember if he’s a real boy. But my game doesn’t know that! That’s why I’m going to save all this crucial information to disk.


THIS is my all-knowing, all-powerful SaveStuff script. Let’s gloss over all the important things this script is doing – I’m sure you’ll be able to fill in the rest. It may get a tad boring, but bear with me, because saving things is actually really fun. Honest.

First of all, you can see a small snippet of the SavableObject class at the bottom of the file to show you where I’d place it. It has a [Serializable] attribute (line 36) – in order to use this, we need to import the System namespace (line 2). In the Start() method, we make our new SavableObject and specify Bob’s name as “John” (turns out he’s really forgetful) and his body’s wood status to “true”. The constructor for SavableObject already specified default values for numberOfBananas and danceTimer, so we won’t have to worry about those. Oh, and System.IO is imported for use of FileStream and File, whereas System.Every.Bloody.Word.In.The.English.Language is used for BinaryFormatter. Now let’s save Bob’s status.

Here’s the part where I attempt to make C# exciting! SaveMyStuff() is now going to do a bunch of fabulous things. We make a fun little BinaryFormatter we’ll be using shortly and then create a wonderful, happy file called “myThings.dat”. One thing to note here – I was dumb when writing this example, so it should actually be “/myThings.dat” to ensure the file goes inside the folder at Application.persistentDataPath. We serialise the data from the SavableObject we made earlier (using rainbows), turning it into a binary string that an ordinary user wouldn’t be able to comprehend if they opened the file manually. We then close the file up and wait a second before calling LoadMyStuff() on our loader object (in practice, this second’s worth of waiting may be replaced by an arbitrary amount of time, perhaps even including closing the game and reopening it). Closing the file is a very important step, since C# places a ‘lock’ on the file while it’s being accessed, and trying to access it from elsewhere at the same time – while it’s locked – would be reeeeally bad. Got all that? Good! I told you C# was fun! Now let’s introduce the LoadStuff class and go over its features.

Oh, by the way, Application.persistentDataPath is a ‘default’ filepath that varies by export platform. Most games that use Unity will probably use this default path plus a bit of extra filename appended to it (as I have here). The filepath also contains the company name and game name, both determined in the PlayerSettings in the Editor (found at Edit/Project Settings/Player).


This script happens to be pretty similar to SaveStuff, but does things backwards. In LoadMyStuff(), which happened to be called by SaveStuff (it doesn’t matter what called this method in practice, I just did that for convenience), I first check if the file “myThings.dat” exist. If it does, I create all the necessary things, as with SaveMyStuff(), but this time I’m opening the file instead of creating it. That’s why it was necessary to check that the file exists, because trying to open it if it didn’t would make things cry/crash/explode. Now that the file’s open, I can deserialise its contents, un-binary format it and stick it back into a SavableObject. Then all there is to do is grab the variables out of that object, plonk them all into a horrible example of how not to concatenate strings together, and watch the Console output all our data with no errors whatsoever.


Congratulations, you’ve just saved to disk and loaded up that data back from disk! It’s a very useful feature you’ll find yourself using in a variety of places; from remembering player’s preferred options to keeping track of game progress, the possible uses of saving to disk are endless.


Game Design Tips #13 – [Unity] ScriptableObjects and Custom Project Gizmos

It’s been a while since my last Game Design Tip, but I’m back and ready to show off some cool things I started using very recently. Ever wanted to save data as an asset in Unity? Turns out, there’s a dead easy way to do that. I’d heard of ScriptableObjects before, but not used them; they’re a godsend for any task where you just care about keeping hold of static data for something – weapons, enemies, item drops, you name it.

I’ll take an example I was working on the other day. I have a load of guns that the player may own, each with their own cooldown rates, damage, clip size and whatnot. My strategy at the time would have been to create a MonoBehaviour script that holds a bunch of public variables, stick that script on a bunch of GameObjects and tweak their variables individually, then save them all as prefabs. Upon needing to read the data, I’d instantiate one of those objects (or have them all instantiated at level start), then read off all the variables. In doing so, I’d waste a bunch of memory loading up GameObjects whose sole purpose was to hold data, clogging up the RAM with redundant data and making the garbage collector mad.


That was dumb.

Instead, I should have used ScriptableObjects, something Unity provides for this exact purpose. Instead of extending MonoBehaviour, we’re first of all going to extend ScriptableObject. That’s going to tell Unity that this script is special, just like every one of my readers. That’s my flattery quota for the day met!


You’ll also notice we gave the entire class the [Serializable] attribute. This is provided by the System namespace (hence, that’s included on line 2) and tells Unity we’ll want it to do stuff to it to make it visible in the Inspector. In reality, it’s a lot more complex than that, but we don’t care for now, do we? We just want our data saved. Oh, and I’ve stuck this class in the WeaponClasses namespace for the hell of it, but you can ignore that if you so wish. In my example, WeaponType is just an enum to deduce which class the weapon falls under.

Now that we’ve gone about making our data serializable, we need a way to make these new Weapon objects. There’s probably many ways to do this, but I’ve used a bit of Editor scripting to get the job done. It might look a bit alien at first, but it’ll all start to come together soon.


This is a brand-new script which doesn’t extend Monobehaviour, ScriptableObject etc. It just needs to import UnityEngine and UnityEditor, and the script must be placed under Assets/Editor. We use the [MenuItem] attribute to add a lovely menu entry for making new weapons – now, we’ll be able to click ‘Assets’ on the toolbar, hover over ‘Create’ and find ‘Weapon’ listed underneath all the usual entries. Clicking this places a brand-spanking-new Weapon under the path defined in the script (line 14) and focuses Unity on the new Weapon in the Project Window (lines 16 and 17). Just a word of warning – it’ll replace anything called NewWeapon.asset in that directory, so I’d rename it straight away! Now you’ll have an awesome new Weapon instance you can reference in your scripts without having to attach it to some empty GameObject.


Not a typo, just a really fun thing for gunning people down.

I did a little more processing with mine using an additional, more complex Editor script to hide certain variables based on the type of weapon, but this is basically what you get when you click on one of your Weapon instances in the Project window. We’re done with ScriptableObjects now, but let’s go one step further and make a cool gizmo for our Weapons.

Weapon icon

This is the icon I’ll be using. It’s dead easy to tell Unity to use this for our Weapons; just save this under the exact name “Weapon icon.png” or “Weapon icon.tif” – only .png and .tif files are allowed. The syntax is [Class Name] [single space] [the word “icon”] [.png/.tif]. Super simple stuff!


Now we have pretty-looking icons for our Weapons and a clean way to save data for each Weapon. Unfortunately, it doesn’t make them look different in the Inspector, but at least they have an icon in the Project view that makes them easier to find. I hope this has been helpful, and I’ll be back soon with more tips.

A Game Design Tip a Day #10 – [Unity Editor] Preferences

This fledgling little series of mine has reached 10 tips already! I’ve still got heaps more to throw at you, so stay tuned! If you’re liking the series so far, then go tell your friends, tell your neighbours, tell your cat. If Mr. Snuggles doesn’t start reading these tips, I’ll be mad! Today’s tip is a bit on the short side, but covers a few useful options you’ll likely end up using.

For some people that like to customise everything to their liking, this menu is the first place you’ll go as soon as you’ve downloaded Unity. But others probably don’t realise how useful some of the features are, or don’t know where to find the goddamn thing (hint: it’s buried in Edit -> Preferences…). I’ll now go over the various tabs on the left-hand side, ignoring General, GI Cache and Cache Server because they’re not where the juicy stuff hides.

External Tools


One thing I completely neglected to mention in the previous tip (the one where I called MonoDevelop terrible a lot) was how to set a different IDE as your preferred one. This is where you can do so – in the External Script Editor drop-down, by default you’ll see MonoDevelop and Browse; the latter allows you to check for a real IDE. Editor Attaching sets whether the external IDE is responsible for debugging, so you’ll want to check this box if you’re using Visual Studio. You can also set which application opens up images – it may be helpful to set this as Photoshop or GIMP to allow for quick image editing, since the default program on your system for opening images is probably just a photo viewer of some kind. Finally, this is where you point Unity to your system’s Android SDK if you’re developing for mobile.



You can safely ignore most of the colours on here, unless you really want to customise everything. What I want to highlight here is the topmost colour option – Playmode tint. Often while working in the editor, you’ll forget that you’re currently in play mode and modify a bunch of variables on all your components, only to realise you’re not in edit mode and those changes will be reverted. Then you’ll curse loudly, grumble and tweak them all over again. If you changed Playmode tint to something strikingly obvious, like red, then you’ll definitely notice much more often when you’re in play mode, because the entire editor changes to that colour. It’s much more obvious than the slightly different grey used by default. It’s only a shame you can’t also change the spelling of the header to “Colours”, the correct way of spelling it. Sigh.



The last thing doesn’t require much of an explanation, but you can rebind all the keys used to navigate the editor. It’s very handy if there’s a specific key you’d rather use for a given task.

A Game Design Tip a Day #9 – [Unity C#] Ditching MonoDevelop for Visual Studio

Unity ships with MonoDevelop, an IDE which does the job fine for the most part. Until it crashes, which is all the time. Or until it runs slowly, which is all the time. Or until it forgets to autocomplete my code, which is all the time. Or until— okay, you get the point, I’m not MonoDevelop’s greatest fan. It’s slow, prone to memory leaks and lacks in features. Plus it’s deleted all of my project’s code on more than one occasion for some inexplicable reason. But it’s fine, because we have a saving grace! Many Unity developers (well, many developers full stop) prefer to use Microsoft Visual Studio. And why wouldn’t they? Microsoft has a solid developer network, very good code documentation and an extremely reliable IDE. Plus they literally invented C#, so there’s that too.

As far as IDEs go, this is the sexiest. Well, maybe after Sublime Text with the Monokai theme.

Visual Studio now has a free Community Edition, so you poor saps out there who don’t have enough dosh for the Professional Edition (or haven’t had it thrown at you by your university) can go grab it for the same price as going outside for some air. Given that you’re looking up game design tips, going outside is probably something you should go do after reading this. We all know that ‘free’ is the best number, so there’s really no excuse to not get it.

The biggest aspect that Visual Studio trumps many MonoDevelop alternatives in is interoperability with Unity’s features. There’s a fantastic plugin called ‘Visual Studio Tools for Unity’ which allows you to debug your Unity project in Visual Studio as easily as you would do using MonoDevelop, plus it has code completion for Unity-specific code that’s better that MonoDevelop (it doesn’t have any more code completion features, it’s just that VS is infinitely faster at it than MD).

One thing that did throw me at the beginning was that Visual Studio very much sits in the “open curly braces on a new line” camp; so much so, that it will try enforcing the practice upon you. To begin with, I was fiercely opposed to this oppressive conduct like a Lincolnshire village opposing a new wind turbine being built within a 10-mile radius, but now I’m kind of glad I went along with it because my code is actually much neater. It’s great if you’re already in the (superior) new-line crew, but it might be strange for you “open curly braces on the same line” slobs.

The eternal struggle. Courtesy of Shutterstock and some dodgy GIMP work.

For all you Unity developers, I cannot recommend Visual Studio enough, especially when compared with MonoDevelop. At least Visual Studio has never somehow deleted everything I’ve been working on.

A Game Design Tip a Day #8 – [Unity C#] Coroutines (Part 1)

Unity has a cool feature (I’m not a nerd at all) that lets you run a function over various frames without using some clunky method that’s difficult to write and long as hell. Coroutines are special kinds of method that, together with the yield keyword, can be used to suspend the execution of one call to a function temporarily – this allows it to run over several frames. Well, they’re much more complex than that, but I’ll be going into more detail in another tip at some later date. One great thing about coroutines is that they’re run in the same thread as all your other MonoBehaviour stuff (like Start or Update), so there’s no problems to worry about with regards to messing with the same variable in both Update and a coroutine, for example. They also have minimal overhead while providing huge amounts of functionality.

Coroutines in C# have a return type of IEnumerator:


This coroutine does… absolutely nothing at all, but it’s just here to show you the basic structure of one. Firstly, every coroutine needs a yield statement somewhere in it, or else it will fail to run. In this example, yield return null will cause the coroutine to wait until just after the next Update() method is called. Coroutines also need to be called in a special way – we use the StartCoroutine() method, which has many overloads:


The three uses of StartCoroutine in the Start method are all valid ways of calling a coroutine. For coroutines that have more than one parameter, you’ll want to use the third version. There’s also a StopCoroutine(“MyCoroutineName”) method that can be used on any coroutine that was called using one of the string-based StartCoroutine functions, which will tell a coroutine to cease execution forever. Like coroutine murder, with less blood. Unfortunately, that does mean that any coroutines that have more than one parameter can’t be stopped in this way.

There are many other kinds of yield statements you can use, too. Rather than always using yield return null and just waiting for the next Update frame to finish, there’s tons of other yield statements in your coroutine goodie bag:


Some of these are very interesting (to reiterate, I’m definitely not a nerd). I’ve listed many of their effects above, and they’re all pretty straightforward. I’ve never really used WWW before, so I can’t claim to know how they work in much detail, but it seems they wait until some WWW download has finished before doing what yield return null does. The next one, yield return StartCoroutine(SomeCoroutine(someParameter)) is an extremely useful coroutine feature that suspends this current coroutine until another one has finished execution. I can even put a similar statement in the second one to wait for a third coroutine – this is called coroutine chaining. Just be careful that you don’t create a circular chain of coroutines that call each other, or things will get very ugly very quickly. You’ll want to be careful when some of these because they run in a specific order – for example, a WaitForSeconds always runs before a WWW. Consult Unity’s Execution Order of Event Functions manual page for more info – the diagram at the bottom of the page should be ingrained in your memory by now.

I’ll be wrapping up some other coroutine features in another tip some day, but for now I’ll leave you guys to play around with these ones.