The Future ~ WGD Narrative Game Jam

This term, we’ve had a focus on narrative games. The main outcome has been a slew of Twine games, and I’m not one to swim against the tide, so I tried my hand at one or two. WGD held a game jam in honour of all things that can be classified as a) narrative-driven and b) a game, with a pretty unconventional theme. I chose “every time I go outside, it’s further in the future”.

I used this game as an exercise in descriptive writing mostly. It’s an extremely short adventure, which you can play on my page. Have fun hurtling through space!

I’m President-Elect of Warwick Game Design Society!

I’ve been a member of the society since the first week of university. I remember flicking through all the welcome leaflets sent by the university in the weeks and months before moving here and being elated and excited when I noticed they had a society dedicated to making games. It’s been my passion since this blog started up!

So I’m humbled and honoured that I’ve been elected to lead the society next year as President. I hope to carry on the fantastic work the previous president, Alex Dixon, has done and I have full confidence the new exec can bring out the best in the society and its members.

Here’s to a great year for the society and a great year for making games!

Shader Showcase 2 ~ WGD Lightning Talk 2

Warwick Game Design seems to be making it tradition to hold Lightning Talks not just once a year, but once a term. This time round, we had great talks from one speaker about the mistakes she made during the development of her game, and one from the rarest of beasts in the society – a musician. Well, he wears many hats and one is music, anyway. Both were very informative, varied and interesting. Then there was me, caterwauling about shaders once more.

The Palette Swap shader

I shamelessly took inspiration from a talk from the previous Lightning Talks session and my first shader was my bespoke implementation of a palette swap. The general technique describes the process of mapping from some domain of colour values to another.


Treat this map in a programming sense; a set of keys and the values each maps to – they’re called dictionaries or associative arrays in some languages. Alright, this is too abstract so far. My talk was about a specific problem I was having: I want a fully customisable colour scheme for my player sprite, which features eight different shades of grey.

He’s going grey after doing this job so long.

There’s at least a couple of ways of providing this functionality. One: create a different set of sprites for each colour combination. Now, I plan on having presets for skin colour, hair colour, shirt colour and trouser colour, each with ten different combinations. Dunno about you, but I think I’d get repetitive strain injury from drawing this spritesheet 10,000 times. Not to mention the havoc it would wreak on the build size of the game and the memory needed to hold them all!

The second way (pause this article now to have a guess. Got it? Good) is to implement the colour changes with a palette swap shader. I know, it was so hard to guess, I’m unpredictable like that. To understand what we’ll be doing, I shall introduce a few of the concepts of shading languages.

First off, I’m using a shading language called Nvidia Cg. Unity is really weird in that it uses a wrapper language, ShaderLab, to give Unity-friendly semantics around Cg programs embedded in a bunch of ShaderLab code. It’s pretty flexible and simplifies the whole pipeline to minimise writing boilerplate code. Then Cg is cross-compiled to either GLSL (OpenGL Shading Language) or HLSL (High-Level Shading Language) for OpenGL and DirectX platforms respectively. Cg is useful, in that it only supports features found in both those languages, but it’s limited because… it only supports features common to both those languages. Not to mention, the entire language has been deprecated since 2012. Apparently, it’s still helpful, though.

In Cg, and also in GLSL, a colour is a 4-element vector of floating-point (decimal) numbers between 0 and 1. Those represent the red, blue and green colour channels, plus the alpha channel – transparency. Colours are like a successful relationship, you have to have good transparency.

Greyscale range. Not to be confused with scaling a range; that’s mountain-climbing.
Floating-point numbers keep your shaders ship-shape.

In my implementation of palette swap, I don’t need much information for the keys of my map. In fact, I’m going to do something a bit hacky and use my keys as a sort-of array index (you’ll see shortly what I mean), so I only need to use one of the colour channels of the input pixels; since the input is greyscale, I arbitrarily pick the red channel.

It’s easier to appreciate this visually. Imagine the range of greyscale colours split into eight equally-sized sections. Oh, look, there’s an image above for that! Now, if we were computing things on the CPU side, we’d just go “ahh yeah, stick a bunch of if-statements in there and just set the new colour to, I dunno, pink if it’s between 0 and 32, blue between 32 and 64 and so on”. But STOP! We’re writing a shader! Shaders don’t like if-statements. I asked why, and they said if-statements once called shaders smelly.

Shaders work best if we can re-write our problem as a vector or matrix operation, since they’re vector processors – this is their bread and butter. Control flow in a shader is slower than a snail riding a tortoise because of the way GPUs implement branching. Luckily, we can send over our choice of 8 target colours over to our shader as an 8×4 matrix. Except, no. Cg only supports arbitrary-sized matrices up to size 4×4, so we need to do something a bit different and send over a two-element array of 4×4 matrices.

// Sample the matrix at a point determined by the texture.
fixed4 x = tex2D(_MainTex, i.uv);
float y = x.r * 2;
fixed4 result = fixed4((_ColorMatrix[y])[(y % 1) * 4].rgb, x.a) * i.color;
Shaders: bringing excitement to your life, one pixel at a time.

We can then, as mentioned, use the red channel’s value as an array index. We multiply it by two to make sure we cover the range [0, 2] to access the correct matrix (_ColorMatrix[y]), and inside the matrix we want, we multiply the post-decimal-point part by four to act as a second index; this gets the row of the matrix we’re looking for. All you mathematicians out there are probably screaming at (y modulo 1), but in Cg, this’ll work on a floating-point by preserving only the part of the number after the decimal point. It’s a glorious exploit.

Now, we’ve completed the effect. When this is run in-game, you can switch out the greyscale sections of the sprite with some fancy new colours on the fly. I used this for a neat character customisation screen!




The Mesh Explosion shader

So far, all of the shaders I’ve shown off at the society have operated in the fragment shader. That is, they’ve been messing with the colour values of pixels. But this isn’t the only fancy thing one can achieve with shaders, oh no no no. You can mess with the actual geometry of a mesh in other shaders, such as the vertex shader, beforehand. I’m aiming for an effect that takes a mesh and pushes the triangles along their normals outwards – now, you actually can’t use a vertex shader for this; to calculate the triangle’s normal vector, you need access to all three of the vertices of the triangle. We need a geometry shader.

Directed by Michael Bay.

A geometry shader can operate on more than one vertex during each iteration; we’ll consume three at once to blast through triangles one at a time. For each triangle, we calculate the normal vector – this is a vector perpendicular to the face of the triangle, and it faces away from the front face of the triangle. The convention in computer graphics is that if, from your viewpoint, you can label the vertices of a face anticlockwise, then you are looking at the front face.



Finding the normal vector is a vector cross product away. Once we have that, we can add a multiple of that vector to each vertex of the triangle, so that the triangle packs its bags and departs the rest of the mesh. Furthermore, we can pass in a shader uniform variable to control how far the triangles move – I bound it to the mouse wheel on the CPU side. Here’s the pseudocode for calculating the normal vector:

// Calculate the normal vector in the normal way.
e0 = v0 - v1;
e1 = v2 - v1;
n = normalise(cross(e1, e0));
Just a normal day for a triangle.

The movement code is exactly as you’d imagine – add a fraction of n to each vertex. The rest is some icky convoluted stuff to do with how geometry shaders need to output vertices (after all, a geometry shader can also be used to add geometry at runtime), and I don’t want to blow your minds any further or your screens will get covered in grey matter, so let’s not go into too much detail about that.

I don’t have the source code to hand for this project yet; I thought it would be more productive to get this post written up and release the source code later, when it’s been cleaned up. I’ll update this post when the time comes, but in the meantime I hope you gleaned some succulent shader suggestions. Happy shading everyone!

Patchworks ~ The Fourth-Year Group Project

For the fourth and final year of the undergraduate Computer Science Masters course at The University of Warwick, students team up in groups of around five and work on a thing for the year. That thing can be research-oriented, or it can be a software development project; the latter is the more popular option. It has to be of sufficient technical challenge for a team of that size for the whole year. Our team of five is developing a game about creating and sharing levels in a similar mould to Super Mario Maker, but with our own spin on the concept. Due to the heavy focus on collaboration, we’ve called it Patchworks.


Mobile-Desktop Integration

The first major feature we’re implementing is the ability for Android devices to join in while someone is playing the game. The core of the game runs on a PC, with one ‘desktop player’ controlling the most important aspects of the game, but 1-4 ‘mobile players’ may join in over LAN (Local Area Network). We wanted to capitalise on the appeal of couch co-op games, and having people use the mobile devices they already own in a novel way seemed like the obvious solution.

Early on in development, we thought about what we would want to display on the mobile device. Do we want it to mirror the visuals of the desktop game? This would cause problems in synchronising the state of the game between devices, as every game event needs communicating over the network which could strain the LAN connection. Not only that, but the interface would be crowded on such a small screen if the rest of the visuals needed to take up space. We decided that it would be best to use the mobile devices purely as controllers instead, and our attention turned to what type of controller would work best.


Mobile games often have a controller ‘overlay’, where virtual buttons are superimposed on the game. None of us are a fan of this style, as the buttons are non-tactile and do not feel good to use, especially compared to a conventional gamepad. Nor is this type of controller suited to this type of game, as we don’t have any ‘action’ to display on the mobile screen, so the controller interface is free to take up the entire screen rather than being tucked into a corner. We thought about what kinds of control do work well on mobile, and came to the conclusion that a ‘scroll area’, similar to a mouse, would feel right at home on mobile. Housing this on one side of the screen leaves the other half free to display a range of buttons for different purposes; the buttons act just like any other button would on a mobile device, and while they still lack the satisfying tactile feel of a physical button press, this is the best we can achieve on mobile. Perhaps in the future we’ll add haptic feedback (vibration) on a button press.


Asymmetric Gameplay

The gameplay experience for desktop players is inherently different to that of mobile players due to the limitations and design choices detailed above. The mobile players won’t be controlling a conventional character like the desktop player will; they’ll be moving around a ‘cursor’, similar to how the character Murphy works in Rayman Legends on Wii U. Elements in each level will be interactive for mobile players only – enemies and obstacles can be manipulated to help or hinder the desktop player. Our initial prototype had a UFO being flown round the stage, shooting bullets downwards. We plan to add a range of enemies, some with unique controls, for the mobile characters to control, plus we want to use the accelerometer and/or gyroscope for some gameplay elements, also similar to Rayman Legends. Similarly, ropes can be cut by the mobile players by using some kind of ‘scissor’ tool and swiping through a rope.

Collaborative Creation

The focus of the project is on collaboration, and it is the Level Editor where this shines. A grid-based editor, similar to that of Mario Maker, allows players to place tiles wherever they want in a level. At this early stage in the project, we have implemented simple ‘painting’ of tiles, as well as undo and redo, clear and erase tools, and in the future you will be able to grab/select objects you’ve already placed and customise their behaviour. For example, you’ll be able to set the endpoints of a moving platform, set the length of a piece of rope (solving once and for all how long a piece of string actually is).


Mobile players can join in with editing levels, with most of the abilities of the desktop player, although only the latter can set the level name, save the level, go into Play Mode or move the camera. We turned to games like Ultimate Chicken Horse for inspiration – in that game, players take it in turns adding elements to the level with the goal of completing the level themselves but preventing their friends from doing so. Our goal is collaboration rather than competition, so we opted for complete realtime parallel creation, where anyone can add or remove elements at any point.

Online Interaction

Super Mario Maker worked so well because it encouraged a community of players to upload and share levels with each other. There were YouTube Let’s Plays of levels, there were notoriously difficult levels like the Panga levels, and there were inventive music-oriented levels in which players input nothing and listened to a tune crafted by nothing but enemies falling onto music blocks. All of those levels were only possible to create because of Mario Maker’s tight mechanics and emergent interactions between different level elements. We want to aim for the same sort of thing, with players able to upload their favourite creations once they’ve beaten them.


Using the mobile app, people can browse levels on the go and bookmark levels for later. This is somewhat similar to a system implemented in Mario Maker after it launched that allowed you to bookmark levels from any internet browser. Of course, this is all going to require some kind of unified account system – possibilities include using people’s Google Play accounts, although some players may not have one. Uploaded levels and bookmarks will be tied to a user account, and you’ll likely use the same account on desktop as you will on mobile. We also thought about a notifications system that lets players know when someone liked their level, or when they’ve reached a milestone of plays or likes. This could be baked into the mobile app and use Android notifications, and it can also feature on the desktop game homepage (a prototype for this functionality was already created).


This Start Menu is extremely rough.

So far, the project is on track to complete its objectives by the due date, which is around the end of Term 2 for feature-completeness, and the start of Term 3 for the final presentation. It’ll be interesting to see which features we get time to implement, as there are a number of ‘stretch’ features we might want to include.

Next time I make a post, it’ll be at or after the end of term 2 most likely, so I’ll have some amazing screenshots to show off. Watch this space!

Bomb Blast ~ WGD ‘Spooky 2017’ Jam

For the first two game jams of the year, Warwick Game Design Society usually opts for simple themes to help ease newcomers into the society and get existing members warmed up. The past few years, those themes have been ‘Retro’ and ‘Spooky’, for Halloween, and this year was no different. However, this year not a single game shown off for ‘Spooky’ had a skeleton in sight! Maybe that’s the spookiest thing about it.

Again: ignore the fact I made this game in Term 1. Just ignore it. I post on this blog promptly and suggesting anything contradictory to that is slander.

I didn’t have a lot of time free to make something, but I gave it my best shot and built a competitive 4-player game in about 6 hours on barely any sleep. Ignoring the infinite-jump bug (the game does not check if you are grounded before letting you jump), it worked surprisingly well! To make it a bit more interesting, I hooked up the Joy-cons and Pro Controller from my Nintendo Switch to act as players 1-3, while player 4 is a keyboard/mouse user.

What I found most interesting is that each individual Joy-con is classed as an entirely separate controller, even when both ‘halves’ are connected at the same time. The axis and button numbers somewhat follow those of a conventional Xbox controller, but with the obvious additions of the SL and SR buttons. Unfortunately, Unity has no built-in way to retrieve gyroscope or NFC data and can’t activate HD rumble, and I had no time to perform any hackery to get all that working, else I would’ve at least added some cool rumble effects.


You’re a kid now, you’re a squid n– oh, wait, wrong game…

The game itself is somewhat based on the Crash Bash minigame Space Bash, with four players on a destructible grid trying to blow each other up. However, I only had time to implement players dropping bombs onto their own position and pushing them at others. Bombs will destroy any floor around them and decimate any players in their blast radius. I also twisted things a little so the aim of the game is to paint as much of the floor in your own colour by walking over it, earning a couple of comparisons with Splatoon 2.

The game could do with a bit of a graphical overhaul, as I only had time for Placeholder characters and the most basic 16×16 sprites imaginable. As it stands, the bright green character especially is hard on the eyes. The stage might also be more interesting if it were larger, with a dynamic camera that zooms in and out, with perhaps more verticality, but it also needs to be easier to judge depth when jumping to the higher level.

In all, I think the experiments with using the Joy-cons as controllers were successful, although the game clearly needs more work in the fun department. Some powerups, some sound and a better control scheme would all be welcomed. But most importantly, I did manage to sneak in my guilty pleasure: screenshake.

Verdict: Bombed.

You can find the source code for this game on my Github.

Shader Showcase ~ WGD Lightning Talk

Every now and then, and definitely not when we could find any other speakers to come in, WGD holds Lightning Talks. Any member is free to come along and opine for a few minutes about whatever game-related topic they please. In the past, we’ve had talks on using OpenGL in fancy ways, using fancy DAWs (Digital Audio Workstations) to create funky tunes and “games for people”, for those fancy-pants people who love games involving no equipment except the bodies of you and your friends.

This time round, there were three talks – one was on palette-swapping and different techniques used in the past, and another was about making your own art (it was sorta like the Shia LaBeouf Just Do It talk, but with less shouting and more creepy drawings). Finally (or rather, in the middle of those two), was a talk from someone not at all built for public speech – me. I did an analysis of some of the cool shaders used in Super Mario Odyssey‘s Snapshot Mode, and I’m gonna do it again, right here. It was somewhat refreshing having a whole session of talks about arty subjects, even if they often swayed into technical artistry, given that the society is somewhat programmer-heavy. Never mind that the Lightning Talks took place last term – let’s pretend I’m prompt at blogging.

Anyway, it’s time to jump up in the air, jump up don’t be scared, jump up and make shaders every day!


I’ve set up this demo scene with a few coloured cuboids, one directional light and a boring standard Unity skybox. It’ll do the job for demonstration purposes. In the executable version, you can freely move the camera around.


I took the most saturated environment I could find, just to desaturate it.

First up is a simple colour transformation. To convert an image to greyscale, all we do is take the luminance of each pixel in the scene and use that value for the red, green and blue values of that pixel’s colour.

float lum = tex.r * 0.3 + tex.g * 0.59 + tex.b * 0.11;

The luminance value takes into account the sensitivity of the human eye to each component of colour; your eyes are more sensitive to green, so it is heavily weighted in this calculation. That’s basically all there is to the greyscale shader.


This is pretty much what you’d expect; the effect is very similar to Odyssey’s.


The city environment felt the most appropriate for a sepia-tone shot.

The sepia-tone shader is very similar to the greyscale one, although the transformation is a little more involved. Before, we used the same value for each of the resulting red, blue and green channels to get greyscale values, but this time, each of the resulting red, blue and green are separate functions of the original RGB values.

half3x3 magicNumbers = half3x3 
    0.393 * 1.25, 0.349 * 1.25, 0.272, // Red. 
    0.769 * 1.25, 0.686 * 1.25, 0.534, // Green. 
    0.189 * 1.25, 0.168 * 1.25, 0.131 // Blue. 

half3 sepia = mul(tex.rgb, magicNumbers);

We have to resort to some matrix multiplication to achieve this. The 3×3 matrix represents a bunch of numbers magically pulled out of Microsoft’s rear end – the mapping from the original colours to the new ones. The last line here essentially represents a system of three equations, where, for example:

sepia.r = tex.r * 0.393 * 1.25 + tex.g * 0.349 * 1.25 + tex.b * 0.272

If you’ve never done linear algebra or matrix multiplication before, this might look a bit exotic, but trust me – it works!


We end up with another unsurprising result. You might find this a bit too yellow, in which case just remove all the multiplications by 1.25 I added.


This one is where things get a bit more interesting. Upon seeing this effect, I immediately thought to myself, “Aha! They’re just using the depth buffer values! I’m a goddamn genius”! So, what is the depth buffer I hear you ask?

In computer graphics, you need to render things in the correct order. If you have a crate fully obscured by another crate, you wouldn’t want to render the obscured crate over the other one – it’d look really strange! Whenever a pixel is drawn, its depth – the distance from the camera plane to the object being drawn into this pixel in the z-direction – is recorded in the depth buffer (z-buffer); this is just a big ‘ol 2D array the same size as the program’s on-screen resolution. When you try and draw something, you first check the new object’s z-buffer value against whatever is already recorded at that position, and if it’s a higher value (the distance from the camera is further), that means it’s occluded and we discard that pixel.


This is the same scene from above, but from a different angle. Each pixel is just showing the greyscale z-buffer value of the final rendered image, which means it’s representing how far away the closest thing at that pixel position is. But why does this not look as good as the Odyssey example? Well, first of all, I’m not Nintendo EPD and they have a few more resources than I do. Second, I’ve not coloured the image myself, although as we saw earlier, this would be a fairly trivial change. The main reason is actually because the scene isn’t very large and we need to understand how the z-buffer does things to understand why.

There needs to be a bound on how small or large the z-buffer values are, else the values would be pretty meaningless. A camera has a near clip distance and a far clip distance, which are the minimum and maximum distances from the camera plane an object can be to be rendered. If you’ve ever clipped the camera through part of a wall in a game, that’s because the near clip plane is further away than the wall is, so that section of wall is culled (not rendered). Values in the z-buffer are typically floating point values between 0 and 1, so a small scene (i.e. one where the clip planes are fairly close together) would result in two objects having more different z-buffer values than the same objects in a large scene.

In the scene above, the near plane is very close to the camera and the far plane is just far enough to contain the whole scene. By default in Unity, the far clip plane is 1000 units away, which would result in the entire scene here being black – all z-buffer values would be close to 0. But having a small scene means you don’t really get much variation in colours, because things are really close and there’s nothing in the background – in the Odyssey screenshots above, there are things clearly in the foreground (Mario and the rocks he’s stood on) and the background (the section of island behind the waterfall). One detail that’s kind of hard to make out is that the furthest island actually shows up in very faint green in the snapshot, so it’s real geometry rather than part of a skybox. Also, the water particles don’t show up in this mode, so they’re likely reading from the depth buffer but not writing to it, and are rendered after all the opaque level geometry.


Seaside Kingdom Doggo raised this game’s review average by 19 points.

Next up is a blur effect. I won’t be talking about the radial blur starting from the edge that Super Mario Odyssey uses though; I’ll talk about a simpler blur that I had time to write – a Gaussian blur that operates on the whole image.

This type of blue works by throwing a ‘kernel’ over each pixel in the original image and looking at the neighbouring pixels. The larger the kernel, the more pixels are considered. Then, a weighted average of the pixel values, with the central pixel having most weight, is calculated for the new image. It’s a pretty simple concept, and probably how you’d expect, but is one step more complicated than a box blur which doesn’t bother with weighting the pixels and just does an unweighted average. Commonly, you would do two or three passes with different sized kernels, so the algorithm is run more than once and the resulting blur has more fidelity.


This image is doing three blurring passes, each with a larger and larger kernel. Each blurring pass actually requires two shader passes, one in the x-direction and another in the y-direction. You could reduce the amount of blurring by making the kernels smaller or reducing the number of passes.


TFW you turn up to a formal occasion in casual clothing.

The final algorithm I implemented is an image-space Sobel filter to attempt to detect edges in the image. This also acts in separate x-and y-direction passes; in each direction, a gradient is calculated, where a higher gradient means a more ‘different’ colour. By definition, you can’t do a gradient in both directions simultaneously, hence the need for two passes. This effect wouldn’t be used in a game if you wanted objects to stand out against objects of similar colour, but it’s pretty simple to understand conceptually.


Running the algorithm on our sample scene results in pillars that are pretty cleanly defined, but this is mostly due to their block-colouring. You can also see a couple of spots where pillars seem to ‘blend’ into one another, and all shadows are also edge-detected because they are dark areas right next to light flooring.

For a bit of fun, I ‘converted’ this effect into a cel-shading effect. Again, it’s not exactly Borderlands quality, but it was a fun exercise for me. This effect is also not present in Odyssey, so there is no reference image comparison.


The Sobel edge detection filter from above is inverted and multiplied by the source image, such that ‘edge’ areas become black and all other areas retain their original colouring. The areas where colours are similar clearly lack cel-shading here, such as the red pillars right-of-centre. You can also see on the yellow pillars where the skybox turns lighter that the black lines ‘break’ a little. Of course, because it’s based on the Sobel edge detection filter, you also get cel shading on the shadows, but the effect is less pronounced here because the shadows are dark.

All of the source code and a built executable for Windows can be found over on my Github. It’s really fun to pick apart effects you’ve seen in video games and I wholeheartedly recommend you try the same! If I have time over the holidays, I may try to pick apart some of the other effects, such as the NES/SNES filters which are probably just pixelation filters with a palette swap applied on top.

My Favourite Game of 2017 ~ The Legend of Zelda: Breath of the Wild

This game is incredible. As far as I’m concerned, it deserves every bit of praise it’s gotten. It was risky to uphaul the Zelda formula and translate it to an open-world setting, but Eiji Aonuma, Hidemaro Fujibayashi and their team managed not only that, but they also ‘fixed’ some of the problems with open-world games in general.


BotW impressed me just as much as Link tried to impress Prince Sidon here.

You know that open-world game where you climb a big tower to unlock a section of the map flooded with quest markers, then a million icons show up on the UI? Yes, that one! Well, BotW takes a slightly different approach – you only have 1-4 quest markers on your map at any one time, all pertaining to the same active quest, and you don’t get inundated with extra markers telling you where to initiate side quests, nor do you get told where any shrine is in the game by activating some magic “gimme all the locations” button, as if climbing a Shiekah Tower would give Link magical knowledge of which characters in the vicinity require assistance.

Instead, you garner information in a natural way – Link whips out his binoculars and searches for shrines and other points of interest by eye, which is best done from the top of the tower. Each and every Shiekah Tower is positioned such that it’s visible from another tower, and there’s never any imposing notification on-screen broadcasting the position of the next one – you go to whichever one you want, or to none at all. It’s seamlessly organic. The visual diarrhoea that clutters other games is wiped away here and it’s so refreshing. The most prominent markers on your map will be the ones you place yourself, and they’re only visible in the real world when looking through the scope.


Twink Link riding a bear.

The soundtrack also contrasts itself with other Zelda soundtracks by forgoing the bombastic Hyrule Field themes found in earlier titles and replacing them with relative silence. Standing in the middle of Hyrule Field in the world of Breath of the Wild, your ears fill with the sound of wind rustling through the grass with the occasional soft piano. That or an aggressive piano riff coupled with angry Guardian laser beams, anyway. Games have historically conditioned us to expect music to play at all times, but the audio design of BotW rejects that idea and the relative lack of music reinforces the vastness of the world far better than any of Manaka Kataoka’s fantastically quiet tunes ever could. I want to state it outright: Breath of the Wild has the best audio design of any Zelda game, maybe any game I’ve ever played. From this point on, I want games to embrace silence where appropriate. This isn’t to say the game is completely silent – there’s still combat music, there are still joyful tunes coming out of towns and there are nods everywhere to Zelda’s unmatched musical legacy when you ride a horse, when you approach a stable or even in Hyrule Castle itself.


A completely innocent transaction.

The weapon system is controversial, to say the least. I see the merits of both sides of the argument, but ultimately I think I like it more than I see flaws in it. While I think durabilities of weapons could be just a little bit longer, and there ought to be a more granular way of seeing how long your weapon has left besides “it is brand new” and “it is about to vapourise in your hands”, I also commend it for encouraging you to try out new things. It’s still odd that a game that spends all its time saying “yes” to the player’s every idea then takes weapons away from you so quickly, but I feel like you’d be playing this game wrong somehow if you didn’t explore the unparalleled depth of the combat mechanics. Here’s a non-exhaustive list of ways you can take down an enemy:

  • Hit them at close range with with a sword, spear or club;
  • Shoot them from afar with a bow;
  • Flurry Rush;
  • Critical hit on their weak point;
  • Airborne attack with a bomb, or bullet time with your bow;
  • Percussive force delivered by horse;
  • A motorcycle to the face;
  • Picking up a Stal-enemy’s head and kicking it into water like a football;
  • Using Stasis on a boulder and flinging it at them;
  • Freezing them with Ice Arrows, Ice Chu Jelly or a Frost weapon and then using a Korok Leaf to blow them off a cliff;
  • Using Magnesis to slam a 10ft metal door in their face;
  • Using a humble pot lid to reflect a beam of pure angry laser energy back at them;
  • Throwing a Cuckoo near them while they are taking a swing so they invoke the wrath of the feathered beasts;
  • Tying Octo Balloons to a raft, then using a Korok Leaf to blow it over an enemy camp, leaping off it and slamming your weapon into the ground to make a deadly shockwave that was so badass, it also killed you;
  • Taking them by surprise with a boomerang backswing;
  • Even better than just a boomerang – catching one in midair and using it to cut up enemies like a supercharged blender;
  • Slapstick comedy, courtesy of the Spring-Loaded Hammer;
  • Waiting for the correct moment in a thunderstorm and throwing anything made of metal at them – guaranteed to shock;
  • Literally tearing their skeletal arm off and playing the old lighthearted playground game, “Stop Hitting Yourself”;
  • Pinpoint deforestation;
  • BEES!
  • Cliché videogame explosive barrels;
  • Turf war

The point here is that Breath of the Wild‘s combat system requires creativity and invention to get the most out of what it offers. And boy does it offer a lot. I’ve heard that, at points during development, the entire dev team put down their tools and just played the game, and I’m willing to wager this is where the emergent behaviour of the combat system stems from.

I might also have added some kind of forging mechanic, in the same vein as the cooking system. I loved cooking and I feel like forging your weapons using the gemstones you find throughout the game for repair purposes, or even to decorate your favourite weapon, could have worked.


I can hear the cooking jingle in my head right now.

On the subject of cooking, it’s one of the most novel crafting systems I’ve seen. You just throw a bunch of things in a pot and hope it pans out. I often tested new combinations to see what stuck and worked everything out for myself – better grades of meat give you more health back, adding honey makes lots of meals better and sticking a bunch of ingredients with the same buff strengthens that buff. Adding two different types of buff cancels them both out, so you need to carefully consider each addition to the recipe. You’re punished with Dubious Food if your ingredients make no sense. The system gives the player a lot of freedom in trying out new combinations, which fits with the game’s theme of saying “yes” to the player as much as possible.


You’ll be a big fan of the anxiety-inducing piano riff by the end. I call it Hyrule Syndrome.

If you’ve not played this game yet, discard the idea that the game has dungeons all together. Well, almost. It’s far better if you assume it has none and treat the four Divine Beasts as intricate, oversized Shrines as opposed to small dungeons. That way, you’ll be less disappointed. Not that I think the Divine Beasts are bad at all! Their approach to dungeon puzzle design hinges on a different core mechanic based on the movement of the Beast, a concept I really hope gets spun out, expanded and refined in the next Zelda game. On top of this, the shrines make fantastic use of Link’s Shiekah Slate runes, the replacement of key items. From the time you leave the Plateau, Link has every key ability he needs to do every single Divine Beast and every shrine.

My favourite Shrine, or rather, my favourite Shrine Quest, is Eventide Island, as many veterans of the game will proclaim. This quest strips Link, quite literally, of all his hard-earned gear and tasks him with collecting three orbs hidden around a remote island, which acts as a vertical slice of the whole game. Presuming that you’ve made quite a bit of progress in the game to get here, as you’ll need a lot of stamina to fly all the way, it’s refreshing to return to basics and experience everything you felt in the first couple hours of the game on the Great Plateau. You’ll scavenge weapons and dodge enemy attacks out of necessity, as your defence is near-zero, and you’ll have to find a way to distract a dumbfounded Hinox long enough to sneak away the orb it’s guarding. It’s a welcome breather that reinforces all that you learned at the very beginning.


Twink Link tries his best to sway an unsuspecting young man, and fails.

Now allow me to make a complete 180 on what I just said: Hyrule Castle. Oh my god. So many entrances, so many paths, so many secrets and so much of it is optional, but the whole thing is a treat. It was my favourite area of the entire damn game! The imposing music track blends together Ganondorf’s leitmotif with Zelda’s Lullaby and a healthy dose of the Zelda Overworld Theme, but with a marching beat and a strange 5/4 time signature that dips into 6/4 for some parts. Rarely does a theme set the mood so brilliantly as this one does. There are a couple terrifying moments where you get trapped in a room with a Lynel and your only escape is beating it to death; I used a lot of arrows in these sections. When you do finally reach the top, you’re met with this dude:


I love Calamity Ganon’s spidery, scorpion-y design.

On top of the base game, there’s the Expansion Pass DLC pack. There’s a few goodies in here – a bunch of nostalgic gear, a real neat map extension that tracks your ENTIRE journey and an extra difficulty – but the main two things are the Master Trials and the bonus Divine Beast. I’m too bad at the game so I’ve not got round to actually finishing the Master Trials, but your reward is changing the Master Sword from foam to actual metal. However, the DLC Divine Beast and the amazing boss fight that follows was great fun; I think it’s best played through when you’ve already finished the game and put it down for a couple months, as the second DLC content feels like a victory lap around some of the game’s best aspects.

This is a game where you can ignore the four Divine Beasts and 116 of the shrines and just go and punch Ganon in the face, if you’re not catapulted out of Hyrule Castle by a volley of Guardian lasers in the process. You can glide off the Great Plateau and start the bulk of your adventure in any direction. Moblins will pick up their fellow Bokoblins and throw them at you in the absence of other weaponry and a lightning bolt will down the toughest foe, so launching your weapon into an enemy camp just before a thunder strike is a viable tactic. These are all things that surprised me when I first saw them in game. Rarely has a Nintendo game handed so much freedom to the player; it trusts that you’ll be able to navigate the treacherous path ahead, even if you’ll see the game over screen several times. After all, the narrative of the game is about Link overcoming challenges and preparing for the final fight against Ganon.


A friend who is supportive of Twink Link’s choices.

One of the criticisms levelled at the game is that “it’s empty”. I fully disagree. What Nintendo didn’t do here was whip out the terrain-making software, add a few hills and crevices and them throw down Videogame House Model #2, Videogame NPC #17 etc. They made a world. Look deeply into the game’s locales and get lost in the forests, the lakes, the mountains, the volcano, the wilderness. There’s a section that’s permanently subject to thunderstorms. Did there need to be? Does it serve a purpose? Are there any NPCs there? No. But it’s there! And it’s there because it’s interesting that it’s there – areas like that add flavour and make this world feel like a real, varied landscape. Knowing that no two hills in the game look exactly alike, coupled with the sheer size of the overworld, just blows me away. Finishing all of the game’s main and side quests ensure that you get a look at a decent chunk of the world. And getting all 900 Korok seeds makes you touch every pixel of the Hyrulean landmass.


Twink Link bringing some spice to an ailing honeymoon.

I didn’t intend to write overtwo thousand words about Zelda, but as I thought about how to sum up this game in a paragraph, I realised I couldn’t. A game this vast needs space to breathe and I couldn’t possibly capture my thoughts in such a small space. The first week I played this game filled me with a child-like glee that no game has done in years, and if anything, it’s filled me with hope for gaming’s future. We need more games like this, where the designers throw out the established playbook and go back to basics. THIS is how you reinvent a franchise.


This game is almost as majectic as THIS beast.

Most importantly, as you might have guessed by now, I’m a big fan of the wardrobe they gave Link. Also, Link can fight Ganon in his boxers, so it’s automatic game of the decade.

Verdict: Fuck me, it might be my favourite game ever.