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.

Radicool Trip ~ WGD ‘Retro’ Two-Week Competition

It’s been a couple of weeks since the start of term, and with that came the return of Warwick Game Design’s Two-Week Competitions. I managed to cram a game into the past two weeks, and the result is Radicool Trip, a game where you’re an edgy 90’s kid with a slight addiction to a popular branded cola, Popsee.

radicool_01It’s exactly as dumb as it sounds.

It’s a short game, involving a trip from your bedroom to the shops. It was originally to be a sort-of puzzle platformer, but I spent so goddamn long on the text engine, it turned into a goofy text option-based… thing? I’m not even sure. It’s certainly not the most polished thing I’ve ever made, but it was enjoyable – the stupid 90’s references and jokes were fun to write. I like how the text engine worked out too; there’s room for improvement for sure, but I’ll most likely use it in future projects. Currently, the text system supports 6 rows of text with 14 mono-spaced characters each, but I’d like to add the ability to tweak the number of characters per row and switch from a purely mono-space font to variable-width fonts. I also hope to make the character controller feel better to control, as it’s currently a bit of a potato when it comes to jumping.

radicool_02Welcome to WGD.

The text engine also supported player choices in the form of small replies. The biggest pitfall of this is that each text box only supported one line of text – 14 characters – so replies were short. Plus, they obscured the actual text behind them. However, the concept of having different dialogue options and witty replies is something I’d like to build on, perhaps as part of an RPG.


Everyone loves options. Well, everyone has the option of liking options or not.

It’s an extremely short game (well, it’s basically just a tech demo of a text box), but I hope to take ideas from this into the next project. Speaking of which, the next WGD two-week competition is ‘Broken’ (with a side theme ‘Spooky’, for all the Halloween spookiness). I have plenty of ideas for it – I’ll most likely be going with a puzzle game I’ve wanted to make for a while, in which you have a world that can only be viewed from one side at a time using an orthographic camera. You’ll be able to view the world from different sides and rotate the world, but gravity will always act downwards so you’ll have to make sure the player doesn’t fall out of the world.

If you want to play Radicool Trip, you can try it out by clicking the flashy-looking button below. It’s short and there’s not much to do in it, but hey, it’s free!


Dare to be Digital – How Not to Give Feedback

Dare to be Digital is an annual competition held at Abertay University, Dundee, in which fifteen teams of between five and eight students work together to produce a working video game prototype over the summer. It began in 2000 and has since grown from there, accepting a wider range of participants including international teams, and has become the sole route for the “Ones to Watch” video game BAFTA. It is open to undergraduates and those who have graduated since the previous competition, but only people with less than 6 months’ experience in industry can enter.

Over the nine weeks of the competition, teams are provided with support from key industry figures – this yeah, the competition boasts big names such as Sega and Ubisoft’s Reflections studio. Teams then present their entries at the Dare ProtoPlay event, and the top three teams are nominated for the BAFTA and receive £2500 for each member, with extra prizes often distributed by sponsors. Naturally, many budding teams of developers, artists and designers leap at the chance and start hammering away at a concept or prototype to send to the judges, hoping for a chance to work with the industry’s elite. But that’s where the “mister nice guy” part of Dare ends. As a disclaimer, the views in this blog post are that of myself and not of my team, Something Afoot.


The only student game design competition with a BAFTA at the end of the tunnel.

Our team comprises of seven members of our university’s Game Design society. As part of a group that has made countless games of all sizes and genres, we believe we have our fair share of experience. Since many of us had upcoming exams, we opted to polish the concept of our game and forego a prototype – nowhere in the terms and conditions or application advice does it require one. Since the pitch video requires us to talk about the concept, as well as relevant experience, that’s exactly what we talked about – our experience, our game’s concept, the research we did into our target audience and into the mechanics, as well as Japanese ukiyo-e art, which our game was poised to focus on. Here’s our pitch video right here:

As we didn’t have a prototype, and assumed many other teams would, we had accepted the possibility of not being accepted from the start. We apply, they don’t pick us, we take their helpful feedback and move on, all is okay. Except that’s not what happened at all. Instead, we find ourselves waiting longer and longer to find out our fate, the application process was plagued by submission errors and the terms and conditions changed more times than I changed clothes. One area of frustration amongst entrants was the initial step – the feedback form – that reportedly broke and didn’t let people submit their entries. I can forgive this, as it’s a large competition, so things are likely to go wrong a bit, but I still found it surprising from a competition that has been running this long. Luckily our team avoided this error.

During the application process, our team believed we would receive a weekly stipend of about £75 each and be provided with free accommodation at Abertay University for the entire 9-week period, as stated by the terms and conditions midway through the application process. Evidently they had left last year’s T+Cs up, as our team was left disappointed when they abruptly changed to no weekly stipend and only 10 days’ accommodation. We (and many other teams) would have found it far more productive to house the entire development team under one roof, rather than being spread across the country. While this was annoying, and a clear lack of communication due to the silent nature of the change (no-one was informed, they just sorta… changed), the competition was still enticing to us, despite now having no promise of monetary support had we secured a place.


Dare ProtoPlay, where the 15 finished products are showcased.

Personally, my concerns over the competency of the organisers started after we had applied. The interview stage was scheduled to run at the end of May, but we had to wait until June 5th to learn our fate. I can’t help but notice that June is not in May. Running up to the end of May, the competition felt disorganised and, frankly, not up to scratch for the biggest student game design competition in the UK. But I can live with all the above – all competitions, large and small, have sticking points that, while annoying, are easily outweighed by the benefits of entering. All the above points may seem like I’m nitpicking, and mostly I am, but that’s not the most unprofessional part of the process.

Then came the feedback.

These guys utterly failed on this front and it’s the reason I won’t ever be applying for any Dare to be Digital competition again, at least not before they clean up their disgusting act. I make no apology for commenting that whoever the heck decided the following ‘feedback’ was worthy of being shoved down our throats shouldn’t hold any position as a judge of anything, especially when handling such a diverse industry for which people from across the globe should be free to creatively express themselves without being completely lambasted like this. Brace yourselves.


Now comes the fun bit – deconstructing this monstrosity and picking out the key points that proves these judges (I’m unsure at this point whether it’s two or three people commenting) are clearly unable to write feedback for small indie student teams who are supposed to have little experience.

We’ll kick off with the first paragraph, keeping in mind the sentence I just said in bold. It’s worth noting that a prerequisite – yes, an actual requirement – of the competition, is that all participants must have less than 6 months experience in the industry, that is, they must be inherently inexperienced (note the spelling), as I’ve mentioned before. So when the first judge calls our team “unexperienced” (aha really? This is hilarious), all logic goes out the window. Of course we are, we’re students. We’re expected to not have made a commercial game before or to have worked in industry. But contrary to that point anyway, each member in our team introduced themselves and listed all their previous accomplishments, in order to prove exactly the opposite. *sigh*.

This judge opens up the feedback with the line “They didn’t really explain what they were doing”. Now I’m not sure whose pitch video they watched, but we spent literally half the video talking about what we were doing. Already I’ve lost faith in humanity. This ‘judge’ then wraps things up nicely with the snide comment that “to get onto Dare, you need to put more than 2 hour’s work in”.

What the fuck kind of underhand bullshit am I reading?

I’m sorry, I lost my cool when I read this line initially. This is supposed to be a friendly student competition and a gentle leap into the industry. Why the heck did this person feel it necessary to degrade me and the rest of my team like this? Luckily we’re thick-skinned enough to disregard this kind of comment as illegitimate tosh, but my worry is that many other teams could be irreparably damaged by this kind of comment. They appear instead to have some five-year-old’s mentality of slinging shit for no apparent reason. Nonetheless, it’s my favourite sentence in the the whole feedback document, because it’s so hilariously misguided and it amazes me how stupid people can be and still be trusted by others to judge something.


Two of the judges are clearly Simon Cowell wannabes.

Now for paragraph numero dos. I can only assume this is a separate person’s comments, because it wouldn’t make sense attached to either the first or last paragraph. However, you could probably forgive me for thinking it’s supposed to be part of another paragraph, since it’s only one fucking line. Jeez, they took more than a week longer than advertised with writing this feedback, could they not have pulled some other rubbish out of the air? Anyway, it simply reads “Without a prototype, I think no.” Um, thanks for your in-depth, all-knowing feedback on the CONCEPT we pitched to you. The terms and conditions did not require a prototype, so this sentence just does not make sense at all. You’ve been in industry for a long while apparently, so your ideas on our CONCEPT would have been nice.

I firmly believe the first two (or one) judges’ (or judge’s) attempt at what they call ‘feedback’ is some of the laziest and rushed writing I’ve ever seen. You can find more insightful words in a Nickleback song.nickelback-4de8dc6b3304d

I have the lyrics to their next song right here in a handy email.

The third judge is the only one with anything insightful to say. He unfortunately then voids it all. But he starts off saying he’s sensitive to the need not discourage students from this industry, given some of the baggage that comes with it. This is fair, as jobs in the game industry are often riddled with long work hours and little job security when projects fail to sell, as he mentions. Clearly it’s not a sentiment all the judges share though. He congratulates our team on the effort we put into researching the marketability of our game, praising the ‘long hours’ we’ve sunk into our concept. There we are, some sanity! This completely contradicts and writes off what the first judge said, but these are fair comments – I see a lot of teams these days that blindly make games without keeping the end user in mind at all stages of development.

Towards the end of his feedback, he says our game is a “fairly standard take on the genre” and that our game isn’t really anything new. Unfortunately, I do agree with him here. Our game, despite the research we’d put into the marketability, was essentially the same as many other things you can already find on mobile. So he gives some insightful comments into our pitfalls and strengths, two things neither of the other judges really did well (or at all – I’m looking at you, number two).

One of my problems, then, with the third judge’s feedback is that it doesn’t really give any direction to improve on. Sure, he gave a lot of useful insight into our pitch and I appreciate it’s difficult to come up with ways to improve for every entrant to the competition, but a little more would have been welcome, even if I’m nitpicking a bit here. But my main problem is the middle of the paragraph. “Do you, the designers, feel your game is respectful toward Japanese culture?” This is a tough one, since there’s always the risk of misrepresenting another people. However, it’s extremely difficult to tell from the video which way this will go, and I’m sure the industry help provided by the competition would assist us in making our game as tasteful as possible.


Okami, one of the sources of art inspiration for our game.

That said, in our video we did talk a lot about our inspirations, for example Okami, which are representative of the cultures we are targeting as the base for our game. This suggests that the judge was just finding lazy reasons to reject our idea, as bringing up the cultural argument then providing no evidence to suggest we’d unfaithfully represent such a different culture doesn’t really give any insight at all, it’s just open speculation. So to give this as a reason to not put us through to the interview stage is void and lazy.

The other comment from the third judge is pure gold. “Furthermore – and I must be direct here – do all of you have legs?”. Our game is based on a hero with no legs – indeed, it is called Legless Sorcerer – but this comment and the words that follow seem like the judge is trying to call us disrespectful to people with disabilities or paralysis. This is not the case. Nowadays, almost every game I see is biased towards straight, white males with no obvious health problems (usually in a terrible first-person shooter environment), particularly AAA titles. These kinds of game often do the opposite – they depict the protagonist as some kind of super-being, with skills above that of the average person, which makes sense as it panders to people’s desire to have all kinds of powers and skills.

What we were going for was an approach where we could have someone who had a disability without affecting gameplay, and without having to be asked questions. People of all minority groups are tired of being treated as ‘different’ – that’s a fact – and by having a game that doesn’t place heavy stereotype on one of those groups, we believe we could silently demonstrate how more games ought to tear down barriers in traditional games that cause grossly unrepresentative characters. But nope, the judges instead seem to want more of the same, which is highly ironic given them criticising our “standard take” on the genre.


Judge number one.

The main thing I take from this is that Dare to be Digital, while marketed towards small student teams and with a supposed aim to seek out innovation and marketable ideas for games, seem to actively discourage people from the industry. Our team wasn’t the only one who was rejected with poor feedback (I’ve seen even worse, but I won’t post it here) and my concern is that legitimately talented people will be completely discouraged and decide not to make games at all. Games are a wonderful fabric that tie together people in some of the most fantastic ways, and I firmly believe any person should have the chance to become part of this amazing industry.

It’s fine to criticise a bad idea – I’ll honestly admit our idea had tons of holes which we had intended to look closely at during development – but to provide nothing but derogatory comments about the ability of the team and empty reasons in place of genuine concerns and places to improve is not something anyone should have to face from a student competition. I’m not angry at the fact we were rejected from the interview stage, because our game was quite generic in places and of course there are many talented developers entering these kinds of competitions – we took a chance, and failed. It’s life. However, had they just analysed our ideas and suggested ways to improve, I’d be happy. Unfortunately they took the easier route and wrote something they wrongfully label as ‘feedback’. Our team hasn’t been discouraged from the industry – I plan to make as many games as I can possibly manage over the Summer – but I’m terrified that genuine talent has been lost forever at the hands of these monsters.

Two-week Competitions: ‘Spooky’ and ‘Growth’

That’s right, today’s going to be a special two-game bonanza! Well, really it’ll just be one game and a pretty cool tech demo, but it’s generous nonetheless. Both the following games were made for two-week competitions for Warwick Game Design society, and made by the same two guys that made this.

Lavender Town, theme: Spooky

As the name suggests, it’s based on Lavender Town from the original Pokemon Red and Blue. The general atmosphere of the town is such a creepy experience, how could we not make a game based on the creepypastas spawned by the games? Obviously we wouldn’t completely rip off a completely-true, legit story such as this, so we did our own spin on it.



It’s a relatively short game (it’ll probably take you no more than 5 minutes), but it took a lot of work to pull off. We used a lot of resources for this one, such as a lovely glitch shader for sprites in Unity, plus of course all of the original music and sprites (which, because we’re idiots, we decided to copy out entirely by hand. At least we’re better at pixel art now).


The really cool glitch shader, mid-glitch.

If you’d like to give it a go, then you’ll find it in various places – either on IndieDB, on my Dropbox, or on the Warwick Game Design website, where you can also see everyone else’s entries.

Fractal Mountain Generator, theme: Growth

This game doesn’t really have much game in it at all, but it is pretty cool – it’s a random generator that subdivides a mesh over a number of iterations, and moves around the vertices a little to produce a fractal mountain. In an attempt to put some actual game inside it, there’s a red cube that spawns in a random place and drops down somewhere on the mountain, and you have to find it.


Only the highest quality textures.

There really isn’t much to do, except appreciate the fact that this game might not have existed, had we not found all the hidden bugs in time. Seriously, Tom and I probably crashed Unity more times for this project that we have for everything before this combined. If you want to give it a go, you can go grab it from my Dropbox.

fract-02Actual games are overrated; tech demos are where it’s at.

I’m also working on the next project by myself (although I’ll help Tom when he gets an idea, because I’m obviously such a nice person). The theme is Micro, so my idea is a little guy called Sam who inhabits a computer, and has the ability to change size and gravity to navigate through to the end of a few levels. Here’s a teaser image:


*Hop* *Bounce* *Boing*

Hopefully this time it won’t take me forever to get around to posting about the game!


Epilepsy Simulator 2014 – Post-Competition Tweaks

First of all, the game’s now going to be called Strobe Simulator 2014, because that’s less likely to offend people, something that was overlooked for the competition entry. There’s only a handful of notable changes for this version.


So, so red. Pretty.

Firstly, the music used is now ‘Trippy Claws and Glitchy Eye’ by AsteroidBlues, a fantastic piece I found on NewgroundsSecondly, there’s lots of screen-shake when the spheres hit you, or when they explode. I managed to get this working thanks to a great library of code called iTween, which is made specifically for Unity and is completely free (which means there’s literally zero reasons for a Unity developer to not grab it).

There’s a working high score saving system, which can hold the ten best scores. Those scores are shown on the start menu, and get automatically saved whenever you die in the game. On top of that, the particle effect that plays when spheres explode can have a variety of colour to them, and the floor will turn the same colour to match the last particle explosion. It’s just a small change, but it’s a little less monotonous that just having red particles every time.

The pause menu’s much improved too (the camera gets frozen in place while paused, and the cursor locking works much more effectively), and when the player gets damaged by a sphere, the screen flashes red for a bit, to emphasize the damage the player has taken.

This will be the last version released for the game, and it’s on to another project!



Epilepsy Simulator 2014

After staving off sleep for the past couple days, me and my friend Tom finished (well, sort of) our entry for the Warwick Game Design society’s two-week challenge, which had a theme of ‘reflect’. I showed a screenshot of it in my last post, but it’s come very far since then. It’s now got a name, Epilepsy Simulator 2014, which is only half a joke, because it will probably give you epilepsy (disclaimer: if you have epilepsy and play it, please don’t sue, we’re too nice to go to jail). So without further waffling, here’s a short video!

The basic premise of the game is: you have a laser gun. Black spheres drop down and try to kill you by touching you. Stave off said spheres using the laser gun. The laser will reflect off the walls, and when a sphere crashes into the wall, it has a chance of activating a strobe light on that tile of the wall (this is where the epilepsy starts). The lights get all colourful sometimes, and the more lights going, the easier it is to see the enemy spheres. The laser was ripped straight from one of my old projects, and was one of the easier bits to add.


It looks so pretty when everything’s lit up like this.

Tom (the other guy who was making this with me. Lives in the same flat as me. Cool guy.) had never used Unity before, so a lot of the programming for this project was me showing him how to do stuff with Unity, but he’s learning very quickly, much quicker than I did in the beginning. He also made the textures for the walls, which are about three times better than what I would’ve come up with, so have a gold star, Tom!


Dem textures, yo.

The next competition, which started yesterday has a theme of ‘Spooky’, which we’re currently in the process of thinking up ideas for. We didn’t win this first competition (sadface), but this game was so fun to make (because it’s completely bonkers), so here’s to another two weeks of game design. You can download it from the downloads page on IndieDB, my Dropbox, or the Warwick Game Design games page. Also, the music isn’t ours (it’s Savant – Snake Eyes), but we’ll change it if we ever do anything with this project that isn’t purely for fun.