As I’ve previously discussed, in 2017 I have set myself the goal of developing 50 videogames. I’ve played around with Unity here and there in the past, but never really committed to actually just doing the hard yards and learn how to make videogames. The best way to get good at something is to do it a lot while you’re still bad at it. You need to play a lot of bad piano before you’re good at playing the piano. You need to write a lot of bad poetry and stories before you’re a good writer. You need to make a lot of bad videogames before you are good at making videogames. The goal of 50 games in a year is an attempt to force me to do just that: to prioritise quantity over quality and make a lot of bad videogames in order to get better at making videogames.

It’s something I regularly tell my game design students: no one really cares if you have a degree in game design, they care if you can make videogames. Or, flipped the other way: don’t wait until you have a degree in game design before you start making stuff. Just… make stuff.

I chose ’50’ so I could more-or-less make a game a week with a fortnight of breathing room. At the time of writing, we’re at the end of the 16th week of the year and I’ve released 14 games, so I’m going well! I also meant to blog about the games as I released them, and I’ve been less good at that. This post thus serves as a summary and reflection on the quarter-and-a-bit of this experiment.

All the games listed here are available on my itch.io page, here.

1. Headbutt
I wanted to keep my first game of the year very simple so that I wouldn’t demoralise myself by coming up against an insurmountable challenge too early. ‘Just hitting a ball on your head for as long as possible’ seemed like a pretty easy way to do that. I still managed to overcomplicate it, though. I had this idea for extending a bird’s neck to hit the ball, so I put this rectangle neck between a head and body sprite and had to rotate and scale it between these two. It was practically uncontrollable but it sort of worked in the end.

Looking back at it now, I screwed up quit a few things in Headbutt. For the character’s movement, I used a number of pixels per frame instead of Unity’s physics code. So this means if you play at a higher resolution, the bird moves at a different speed and it becomes practically unplayable. I also hadn’t actually figured out how to do 2D properly in 3D yet, so I’ve got sprites sitting on 3D objects, which created all sorts of problems, such as not being able to use the ‘forward’ vector without a whole heap of mucking around. My sprites are also all blurry because I didn’t know how to import sprites properly.

But overall this was a good first project! I made a game where you hit a ball on your head and it dd that. Cool!

2. Fetch

If Headbutt was a good start at keeping my projects well scaled, Fetch was a good learning experience in just how easily a seemingly simply idea can be way bigger than you expect.

‘Play fetch with a dog’ seemed simple enough on paper. I had these different ideas for the things the dog might do after you threw the ball: it could bring the ball back; it could just go to the ball and sit down; it could bring it back and refuse to drop it; it could just do nothing. The idea was it would be a similarly frustrating and random experience as playing with my dog in real life. After a lot of time spent on some of the most simple bits of the game, I stripped this back to simply the dog bringing the ball back or sitting at the ball.

This time I tried to do 2D properly. I learned how to actually display a sprite in Unity with a SpriteRenderer, and I revisited the Unity 2D Roguelike tutorial to figure out how to wire-up animations. One of the main challenges here was really just making the sprites. I’d encountered Photoshop a little bit in my failed multimedia degree a decade ago, so when I opened Aseprite the general idea of layers and frames made sense to me, but I made a lot of mistakes. Drawing to the wrong layer then having to fix it on every frame and stuff like that.

I was particularly happy with my sprite of my dog Harry. In fact, the game started with this sprite. I made him to practice pixel art, liked it, and decided to make the game for it. It was here though that the game’s biggest headache emerged. Harry has a black spot on his left side, so I’d produced different sprites for Harry facing left and Harry facing right. This isn’t how you usually do things with 2D games, I don’t think. Normally, you’d just create the sprites for facing one direction, then just flip them horizontally for facing the other direction. When I animated Harry, I couldn’t do this because his ‘facing right’ was a completely different set of sprites. I probably could’ve redone the sprites, but the thought of rewiring all the animations again was too much to bear, so instead I made this convoluted and hacky code to change the position of the tennis ball in his mouth, pending on what way he is facing. It doesn’t always work and sometimes he still brings the ball back in his butt.

The thing I’m most happy with in this project is the camera. I’d stolen some code from the Unity forums during Headbutt to make the camera keep both the character and the ball in focus, no matter how far apart they are. I repurposed this code so that at different stages of the game it focuses on different objects: the player and the dog when the player is holding the ball, the dog and the ball after it is thrown, etc. I’m really happy with how it turned out.

I’m also just happy with the general experience of the game, and my ability to communicate a simple real-world experience into a game.

3. Parachute

Something far simpler than Fetch. That game helped me understand what scale of game was not going to be sustainable for this project. So for my next game, I cloned an old game I remember playing on my early iPod I owned back in 2004. You know, the type with the spin wheel.

I played this game a lot when I was living in Japan and got really into it. The idea is you shoot down planes and the men they drop and don’t let too many land. You get a point for each thing you destroy, and you lose a point for each shot fired, so you need to accurate and aim for combos, such as taking out multiple targets with plane debris, or shooting a parachute to drop a man into one that has already landed.

The game is very unpolished. I just used basic 3D objects from Unity (and a plane model from the asset store) and didn’t bother with any lighting. It’s not very balanced, either, but all the bits are there and functioning so there wasn’t much reason to continue with it. Main things I learned: rotating objects is complicated, and how to use coroutines to spawn enemies as per the Unity space shooter tutorial.

4. Skull Shakes

Between each trimester, some of the lecturers at the college I teach at hold a game jam for any students that wish to participate. It’s called Make-A-Thing and the general idea is to just give students a chance to make something without the pressure of assessments and the such. Crucially, it takes place over a week, rather than an uninterrupted 40-hour block. I’d taken part in the jam previously to make this preliminary experiment in learning Unity.

I wasn’t fully committed to taking part in this jam as I had a bunch of work to do to prepare for the new trimester, but it was a good opportunity to make a small thing. The three prompt words were vermillion, remedy, and parallel. The idea of controlling two things with the mouse at once came to me straightaway, in part influenced by this game my brother made. I can’t recall where I got the idea for flashing colours and screenshake. I think I was just very aware by this point that the games I had been making were nothing at all like the videogames I most appreciate: overwhelmingly audiovisual and sensorial. So this was probably a crude preliminary attempt (or at least impatience) at this.

I was mostly happy with my mathematics in this one. I set a maximum amount of screenshake, a maximum size of the score font, a maximum speed of the colour flashing. Then, each frame, the game calculates based on a hidden timer what percentage towards ‘maximum’ each of these effects should be, while collection the potions subtracts from this timer back towards zero, thus decreasing the screenshake and flashing. I planned it all out on paper before I started coding, and that really paid off.

5. Beat

 When that neo-Nazi guy got punched in the head on inauguration day, I wanted to make a game about it. I thought of making some more mechanically meaningful stuff, like a conversation system where you try to convince a neo-Nazi with words that maybe racism is bad, but it achieves nothing. But then I realised that the meme that Richard Spencer became wasn’t really one about proving points but more one of simple humiliation, so the game I settled on tried to lean into the meme rather than build on it.

I’d also wanted to make a more audiovisual game that was less goal-orientated and more expressive. Just press buttons and have audiovisual sounds happen. So I put the two together. I got some free drum sounds, got the video of Spencer being punched, and put them together as a simple drum machine. When I designed it, it seemed like I should have a different frame for each input, but in hindsight I could’ve just used one image of the punch with the buttons doing the different effects. I might return to this in the future and fix it up.

I also put quotes that Spencer has said in the game. The point of this was to try to say that this isn’t just glorifying violence against those you have a political disagreement, but a justifiable response to someone who uses words as a form of violence. Though, now seeing the quotes makes me uncomfortable. I’m glad I included an option to turn them off.

My thanks to my co-worked Adrian Forest for helping me figure out how to get the video into Unity. Instead of using a movie file, we ripped each frame of the video as a separate PNG, and then imported this into Unity as an animation. This made everything far easier.

6. Flightboy

Another clone. This one for an old game we had on the Tandy 1000 as a kid called Flightmare. This game required you to line up enemies in both top- and side-views to kill them, while avoiding the same happening to you.

At the same time, I’d been replaying some of my Gameboy games. I was amazed at just how expressive they were with four colours and 160×144 pixels. I wanted to use these same restrictions myself to see what I could do with them. In doing so, I think I learned something about just why retro pixel art styles are so attractive to a range of indie developers. They’re not ‘easy’ by any shot, but they feel more… surmountable, perhaps.

Originally, I thought about making this as a real 3D game with two cameras, but instead I thought I’d learn more having to code it as a 2D game. I ripped my enemy-spawning coroutine from my Parachute game (which in turn was ripped from the Unity space shooter tutorial) and used that to spawn the enemy ships. But then I came across a hurdle: the ‘top view’ planes had to be linked with the ‘side view’ planes once they were spawned; same with the bullets. I ended up doing this with about ten different tags: Plane1, Plane2, Plane3, etc and cycling through these as each was instantiated, and then linking each Plane2 to the other Plane2. And then I just made sure the game never spawned more planes than there were tags to avoid duplications. It was pretty hacky, and I think using tags like that uses a bunch of memory, but it worked in the end.

One thing I finally learned how to do properly with this game was to use physics for movement, so that the speed of my game doesn’t change for different resolutions. To use Unity’s inbuilt physics engine, you need to attack a Rigidbody to an object. Previously, the only way I knew how to make a Rigidbody move was with the AddForce() function, which often felt like the equivalent of pushing a heavy shopping trolley. With this game, however, I finally figured out (someone probably told me) that I could just directly modify the object’s velocity, creating a much more immediate and snappy movement, and scaling with different screen resolutions.

The clouds in the side-view were a late addition but I’m so happy with them. I used the same script for the planes for the clouds, and just randomly altered their size, rotation, and speed at spawn so it looks like there are far more types of clouds than there actually are.

7. Countryside

Possibly the game I am most happy with so far. I created this game alongside our students’ Game Studio 1 brief to recreate the game Berzerk in the style of an assigned artist. I was assigned the artist Grandma Moses, and the videogame I made ended up consisting of walking around a procedurally generated countryside, waving hello to people. Also Harry is in there somewhere.

I wrote a proper postmortem of this game with more details here. There was a lot to figure out before I made it, and understanding how the original game worked helped a whole lot. The game also required me to make a lot of assets, so I borrowed and stole from previous games. All the people are reskins of the player-sprite I made for Fetch, with an updated walk cycle that took me far too long. The clouds, meanwhile, are the exact same as in Flightboy, just a different colour and transparency so they seem like shadows.

I spent about a fortnight on this one, and I’m tremendously happy with how it came together.

8. Edge

Another game created alongside a student brief, this time for a brief I set my own students in Game Studio 2. After visiting the Gallery of Modern Art, students were to make a videogame adaptation of an artwork over a single week. I was incredibly happy with the results, which are all available here. I also wrote about this game’s idea and development in more detail here.

This was my first real attempt at working in 3D this year. That along with the willynilly using of the Asset Store blew out the size of my project real quickly. I still have a lot to learn there about how that works. It also helped to convince me to stick to 2D games for most of my projects.

I didn’t learn too much technically while making this game. The script I used to invert the meshes was found online, as was the code to convert the terrain into a mesh so i could then invert it as well. But it felt like I actually made a game that explored an idea, rather than just a game that taught me a particular tool or skill, so for that reason alone I’m very happy with it.

9. Train

After Edge, I went to GDC and, after that, I had a whole heap of deadlines to frantically catch up on. I went about three weeks without releasing any games. I needed to make something real simple and small just to get my momentum back.

Train provided that opportunity. I wanted to toy around with a couple of aspects of Unity I’d not yet looked at: lighting and animation curves. In Train the player just sits still, looking around on a train carriage as streetlights and other trains pass. There’s no real logical reason why the train would be pitch black, but it provided an exaggerated opportunity to see what different sorts of lights do. I then used animation curves to swing the handlebars and the whole carriage. There’s not a lot more to it than that, but it was just the small project I needed to work on to get back into making stuff after a drought.

10./11. Sports

To further help me catch up after my weeks off, I cheated a bit with this entry. I made two slightly different game modes and counted them as two different games. This is cheating, but that hardly matters. The point of the goal of 50 games was solely to motivate myself, but the risk with such goals is once you begin to fall behind, you just give up. So making that goal more achievable again was more important than just sticking to arbitrary rules.

So I wanted to make a game with good-feeling platformer controls. Something like Slime Time or Super Crate Box. I thought about a game where you have to keep boosting or jumping, like constantly doing the second jump of a double-jump in Super Smash Bros. The character controls I ended up with aren’t quite what I wanted; I struggled with tweaking the values to be what I wanted, but I think they turned out alright all the same.

To use these character controls, a simple two-player game seemed easier to deal with than actually making levels and systems for a single player game. The original idea was inspired by just trying to keep a balloon in the air. I thought making it so the last person who touched the ball wins would create some interesting situations, and that seemed to work.

While testing it, I got sick of restarting the game over and over again each time the ball went out of bounds, so I added a fourth wall to the bottom of the playing field so the ball could just keep bouncing around. It was from this testing that the second game mode, where you have to paint the walls, came from.

Making a two-player game came with the obvious challenge of needing two people to test it. My solution to this was, uh, to just not really test it! A couple of weeks later, I watched two other people play it, and it worked exactly how I wanted. This was probably the most exciting moment of this whole game-making experiment so far.

12. Dressage

An ugly little prototype made on a Friday night. I was thinking about I was yet to make a game that really explored an ‘idea’. I hadn’t really made a game that was about anything yet. Which is sort of a silly anxiety, really, since the whole point of the games I was making for this project was to just get better at the tools, not to really say anything. But it seemed like a decent challenge to set myself all the same.

So I got thinking: what are some ideas I’m interested in exploring? My academic work on videogames is all about bodies and, in part, how we become attuned to videogame input systems so that the gestures we use to interface with videogames become meaningful in themselves: the flick from one button to another to attack in mid-air, or the precise amount of pressure we put on a trigger to drift a car. Boil this down: I’m interested in how through repetition, different movements of the body come to possess their own meanings and rhythms.

So I made a simple game where you have ten seconds to memorise a pattern of keys, and then you must continue that patten for a further twenty seconds. It’s less about memorising the letters and more about quickly ingraining a rhythm in your body. Something that Henri Lefebvre refers to in his book Rhythmanalysisas a form of dressage or ‘breaking in’ of the human body by culture.

Almost the entire game is UI elements, with the exception of the shrinking bar at the bottom of the screen. It’s incredibly ugly and functional, and not immediately graspable. But as an exploration of an idea, I’m really happy with it.

13. Pond

At a local dev meetup, Erika Verkaaik told me about the ‘Slow Game Jam’ that was happening on itch.io. I’ve really appreciated during the project the power of external prompts to give me ideas for games I never would have made otherwise, as happened with Countryside. I tried thinking of relaxing activities to make a slow game about, and skimming rocks on a pond came to mind.

I wanted to keep the game real simple. Just click and the rock skims in that direction. No determining how powerful a throw would be or the likelihood of how ‘good’ the throw would be. I think for most people, skimming rocks is mostly down to luck, and each bounce is hugely satisfying as you half expect it to sink this time. So I think the unknown randomness in Pond achieves that.

This is another game I made at a Gameboy resolution, as I was working on a different project that I’m still working on that is going to ape the style of the Gameboy Color Legend of Zelda titles.

The whole game is incredibly simple and, I think, somewhat elegantly put together in the way different elements instantiate other elements. I also learned a lot about how normalised vectors work, thanks to one of the programming lecturers at work. I felt pretty happy with the general efficiency of how the game was functioning, even though it doesn’t really matter on the surface. I’m also really chuffed with my pixel-art. Especially the ripples.

14. Paint Kart

When I was a kid, I was always one console generation behind. I mean, the vast majority of kids probably were, but it the time it felt like I was the only one. I had one friend with a Super Nintendo, and I used to sit at home and just really want to return to those colourful worlds I would see at his house. In particular, I was enamoured by Super Mario Kart. So much so that, at home, I would open Paintbrush in Windows, draw tracks, and then race a yellow line around them so as to pretend I was playing Super Mario Kart.

This seemed like an amusing experience to try to reproduce, but also to do something interesting with. Not just drawing a line but driving it, blending together the actual and imaginary experience of pretending to play Super Mario Kart.

The initial challenge was figuring out how the heck to draw a trail in a believable fashion, other than by spawning sprites every other frame. I ended up going with a simple and hacky solution: not clearing the camera. Usually, a virtual camera clears itself before drawing the next frame. Sometimes this doesn’t happen when a computer is running slow or whatever, which is what creates that effect on older computers where you could drag a window around and paint everything with it. So long as my car was the only thing moving, I could just set Unity to not clear the screen each frame, and it would draw a line for the car. Easy!

The next challenge was getting the line to feel like a car. My first iteration felt like a snake. You just turned and slithered around. I had to sit with my eyes closed and think about what a car (or at least, a Mario kart) ‘really’ does when it drifts. Eventually I figured it out: a drifting car doesn’t always move ‘forward’ but moves in a direction approaching forward. So if you turn too fast at a high speed, it takes a while for the direction the car is travelling to catch up to the direction the car is facing. So I implemented a secondary, invisible object that rotates to face the direction the car is facing, but slowly. So it takes a while to catch up. Then I added this object’s forward velocity to the car, thus simulating a drift effect. It’s not perfect, and figuring out rotation stuff took a long time and a bunch of googling, but I figured out the logic of what I wanted it to do all by myself, and that was incredibly fulfilling.

I could have done more with this game. Actual lap timers and music and menus. Increasingly, I’m feeling anxious about the quality of the games I’m putting out. That I could spend more time on them. I’m worried I’m being lazy with them. But then I remind myself why I am doing this: quantity first. Quality came come late. For now, just pump stuff out of just-enough-quality to learn from them what I can learn, and then move on. But I think it’s promising that I’m starting to feel like I could have more quality in my games now. Like my skills with the tools is progressing enough that it feels like after this project I could maybe actually plan and produce something a bit more complex and robust.

A Note on the Tools I Use

This might be a full blog post one day, but I wanted to touch on just how I go about making these games. One of the big things holding me back in the past from actually committing to making games is that I hate sitting at desktop computers. Absolutely hate it. I do practically all my work on a macbook air. Usually at a desk, sure, but not always. The time I would commit to making games was going to be in the evenings, and I refuse to go sit in the study, where I do all my work, beyond 5pm. If making games was going to be a leisure activity, not a job, it would have to be possible in leisure spaces. That meant I would have to be able to do everything on a macbook air. So here is the software I’m using that has made this possible:

• Unity: I was concerned with how usable Unity would be on a macbook, but it runs fine. When I don’t have a mouse and just use a trackpad, this can be annoying in 3D games, but is fine in 2D. The main issue with Unity is it is immediately intimidating to look at. I can’t stress enough the first few official Unity tutorials (Roll-a-ball, Space Shooter, and 2D Roguelike) for teaching you everything you need to know about the Editor environment and C# as a coding language to put together simple games. In terms of coding, I had the advantage of 12-months of an IT degree I ultimately dropped out of a decade ago to help make the logic and syntax of C# make sense, but these tutorials do such a terrific job for complete newcomers, too.
• VS Code: A free and I think open-source equivalent of Microsoft’s Visual Studio. Much cleaner and more efficient than Unity’s native MonoDevelop, but a lot of the autofill functionality is missing and really difficult to implement. But it’s very simple and no-frills and easy to use.
• Aseprite: The only software I’ve paid for. Aseprite is a pixel art editor, which I got to make up for OSX’s lack of native paint apps. There might be better and cheaper tools to use, but I’ve found this to offer me everything I need to produce simple sprites and materials for my games.
• Bfxr: Super simple sound-generator. I’m no good at music or sound so I just open this up, press some buttons until I get something similar to what I need, and go ‘that’ll do’ and shove it in. Sometimes I also use freesound.org if there are specific sounds I want, downloading them and then trim them in Quicktime.
• GIPHY Capture: The only decent gif-capturing software I’ve found for OSX. Super simple and easy to use to capture gifs to use in tweets or on your itch.io page.
• Don’t forget Zoë Quinn’s excellent Sorting Hat tool, too, for finding different tools that are right for you.