In Dyadic, two players find themselves trapped in ancient ruins after discovering a rare and priceless artifact. Both of you want to be the one to escape ruins with the artifact, but you don’t necessarily have enough equipment to do it on your own. Will both of you work together to try and solve the perilous puzzles that stand in your path? Or will you forsake each other to try and keep the treasure for yourselves? There’s only one way to find out…

“The Cold War isn’t thawing; it is burning with a deadly heat.” ~ R. Nixon

Arms Race puts two players in the shoes of rival diplomats – one from Russia, the other: America – and pits them against each other in a diplomatic battle of focus and determination. When only one of them can walk away victorious from this frantic political free-for-all, who will reign supreme?

Four explorers find themselves dragged across the universe to a mysterious and unknown planet. Their only guide (and the reason they’ve ended up here) is a cute and friendly robot named E.H.U. The four players must work together to navigate this strange new world, and its many puzzles and mysteries. Maybe then they’ll be able to find their way back home once more.

So here we are, for the sixth and hopefully final time. It’s the end of the second last trimester of my studies and I need to summarise all the things that I’ve done. And should get marks for. Right, let’s get to it.

Hello once more, reader! It’s time for another blog, this time focusing on a brand new subject I’ve not touched before. Data Security.

It’s no secret that games collect data – all kinds of data. From analytics, to login details, to personal player information, to payment info. And of course, when this data is stored it needs to be protected in one way or another from those who would try to access it without the proper authorisation. In a worst case scenario, if your data is accessed illegally, money or identities could be stolen, and lives harmfully impacted, even ruined. So this is pretty important.

Now, each different type of data will require a different level of security, proportional to how devastating it would be if that data were made public or got into the wrong hands. If your analytics data for the average amount of time players spend browsing through the options menu gets out, it’s going to be far less terrible for everyone than if the credit card data for your users gets stolen. So you’re going to want to protect that second one a fair bit more, to say the least. But how much? And how?

Hey reader! You read that title right, today I’m looking at the rendering systems of the Nintendo Entertainment System. It’s an old system, and one I’m not likely to be developing on in the near future, so it’s an understandably and odd choice to be analysing. However, it’s one of the few consoles that not only has a host of hardware information readily available, but also has an architecture simple enough to get a grasp on with relative ease.

Anyway, the core of what I’m going to be looking at today is the rendering processes and limitations of the console, since I don’t have to break down the entire thing. More importantly, I’m going to be looking at some of the ways these impact how one would design a game for the NES. So let’s get to it.

Hello again, reader! I’m back to talk about shaders again. A number of weeks ago I had the pleasure of working with Jack McClenaghan to create a distortion shader and beat-mapper for an outrun themed project he and some others were working on – Synthracer Maxiumum.

The idea behind the game was that players would drive around a track whilst objects in the world around the them distorted to beat of the music. But this wasn’t any distortion, it had to be glitchy and retro, so as to fit with the game’s 80s outrun aesthetic. All this took some doing, but it turned out pretty damn well.

Well hello there, reader. It’s time to talk about optimisation – the process of realising that what you did the first time was terrible and finding a new way that runs a hundred times better. Fortunately, in the particular example I’m about to go through, I’m not optimising my own code, but a program provided to me.

This idea behind this program is that it renders an image of various 3D shapes by using a series of ray traces. For each and every pixel in the window, the program performs a ray trace that returns the colour of that particular pixel, one by one. Considering there are a few thousand pixels involved, this takes a while. By default, the original took 80.157 seconds to render the entire image on my machine. That’s my time to beat.

So, once more we reach the end of another year, and conveniently, the end of another trimester of my studies. As such, it is time for me to take all of the stuff I’ve been working on as of late, and put it into one big mega-post. Brace yourselves…