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, 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.
So, for the unaware, I’m currently undertaking a bachelor’s degree in Games Programming to compliment my Bachelor of Game Design. In order to get that, I’ve got to explicitly showcase a whole bunch of stuff I’ve done so that it actually counts towards me passing the course. This is that.
Right, so unlike my other programming blogs as of late, this one’s going to be a bit more reflective than instructive, since I’m not fully deconstructing any particular system I’ve created. Hopefully it’ll still be informative to some extent though.
Anyway, let’s get to the point. This whole blog is about the Singleton, a particular form of programming design pattern designed to create a single unique instance of an object that can be accessed by any part of a game, anywhere, any time. Something which at first glance seems exceptionally convenient. And so far, in my experience, it has been.
Now, if you’re already familiar with Synth Spelunkers, you’ll know that it’s a rhythm-puzzle game where each level takes place on a grid, which is made up of a series of tiles. Each of these tiles may have various types of effects when a Spelunker enters them, or may activate these effects every so many beats of the song. If you’re not already familiar with Synth Spelunkers, hopefully you get at least some of the idea now.
The Old System
Until recently, we had a simple system for making maps implemented that made use of the Tiled Map Editor. These maps were created as a grid that simply specified what type of tile was in what position. This was then output as a simple CSV file (Comma Separated Values), and that file could be used to generate a map in game.
However, none of the attributes for the tiles in the map were set. All of this had to be done manually, which meant that if any changes to the layout of the map had to be changed, the entire thing would have to be re-imported and setup would begin from scratch again. As you’d expect, this was a colossal time-waster. This new system however, resolves that issue.
An Endeavor in Resolving Simultaneous Grid Movement
Synth Spelunkers is a rhythm-puzzle game in which players place small ‘Spelunkers’ onto a grid, which then move one tile every beat of song. When these Spelunkers move, they move based on a predetermined set of logic, which for a single Spelunker is pretty simple to implement. However, we’re not dealing with just a single Spelunker, but a whole group of Spelunkers, all of which must move simultaneously. And what’s more, when Spelunkers move to certain tiles, that may change the states of other tile which can affect where other Spelunkers are able to move, which in turn can have considerable run-on effects.
To put it simply, it’s a bit of a mess to try and work around. Our initially solution didn’t quite hit the mark and had a few issues with the order in which things happened, so I was tasked with reworking the system from the ground up to try and fix it. And goddamnit I did.