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…
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…
Yet again, dear reader, it’s time for me to ramble on about all the things that did and didn’t go well in a project I recently worked on: Feeding The Forgotten. The project ran for total of 4 weeks, and I was working entirely on programming. Much like the post-mortem for Arms Race, I’ve elected to write a larger more structured post-mortem, rather than the small showcase style ones, to better convey my ideas.
Hello again, dear reader! I recently had the pleasure of helping out a colleague of mine, Nic Lyness, with his project The Ride – a game about the feeling of sublime freedom experienced when riding a motorbike (it’s a really quick game, I’d highly recommend you give it a try).
Essentially, I came into the project once everything was done and dusted to convert the controls to work with a gamepad controller. Unfortunately, there was one significant issue that I simply wasn’t able to fix in the time I had, so the current version doesn’t actually have any of my code in it. That’s not going to stop me from rambling about it though.
Just making basic first person controls work on a controller is a relatively simple task, and everything was fine and dandy up until I needed to make the bike lean with the player’s joystick, and right itself when it was released. This is where things began to get complex, and that’s what I’m going to be talking about here.
Hey, dear reader! It’s time again for me to ramble on about some programming stuff I did lately and how it all works. This time I’m going to be talking about shaders, or more specifically, a shader I created for Feeding The Forgotten (a game about putting in the effort to help the less fortunate members of our society, you should check it out).
The Complete Shader
The idea behind this shader was that it would outline an object, but also highlight that object through walls and other objects, so it’s always visible. This is why the gentleman in the image above seemingly has no eyes, as they are different objects, so the back of his skull is being highlighted over the top of them. Neat, isn’t it?
Hey there, dear reader! For those of you who are familiar with my blog (I assume there are very few of you), you’ll note that I’m actually taking the time to make my recent game jam game Arms Race its own post-mortem, instead of putting a post-mortem summary of sorts on the end of a Gentlemen’s Showcase post. That’s because this one is probably going to be a fair amount longer than the kind of space I use in a typical summary. But anyway, enough rambling, let’s talk about Arms Race, and how its production went down.
First and foremost, its important to note that the entire development of this game (up to the point of writing this, at least) took place within the span of 48 hours, for the Brisbane Fab48 Game Jam 2016. We (Handsome Dragon Games) were given the words ‘Love’, ‘Power’, and ‘Surprise’ to use as our inspirations for the game, the last of which being the one we focused on primarily.