3 Thing Game 2017 Entry

Every year the University Of Hull’s Computer Science department host a game where teams get assigned three random words and then have to create a game around those words. This year team Error 303 (a holdover name from our first year) created Mine of Aether, which Kristian has made available here.

Mine of Aether 1  Mine of Aether 2

Why Mine of Ather? The three words we got were: miner, ethereal, and caution. Since the point of the contest is to base the game around the words the overall concept was as follows: you play as a miner navigating his way through tunnels in an attempt to find jewels (or treasure chests in this case), all the while avoiding the enemies present in the mines and using the temporary ghost mode to reach areas that would be otherwise inaccessible.

The entire thing was created in Unity, which, thankfully, the other members of the team have far more experience with, and, miraculously, has its own kind of source-control mechanism so you can work across machines.

Unlike our usual 3 Thing Game performance where we stay up most of the night and get too tired to make much progress at about 8 or 9am, this year we managed to last the full 24 hours. It would be fair to say that the game still needs work and we didn’t get to put in everything we wanted, but its definitely worth a play through.

Android’s Gyroscope

Learning to use the sensor’s in an Android machine is something I should have done a while back. One of the things I’m liking about the Android system is that it seems to provide access to what I assume is pretty complex technology with simple sensor classes (even if Android Studio still bugs me to a great extent).

The application I’ve made uses the change in the gyroscope’s angle in order to draw onto the canvas. Basically, a tilt of the tablet changes the direction in which the controller on screen moves and consequently the direction in which the line is painted.

Building this involved a couple of interesting little tricks: inheriting from the android view class, overriding the onDraw method, and learning to register and unregister android services. Actually figuring out how to stick a compiled application directly onto a device was a bit of a pain; that tap the model number 7 times to get the developer mode trick is very strange.

The main goal of this was to learn how to use the built in android sensors, so the drawing implementation is not exactly efficient. In order to correctly draw the line, the view I’ve implemented stores a list of previous positions and draws a circle the same size of the character at that point; at the moment there’s no limit on the size of the list so it will inevitably cause a crash if there are too many changes in the screen’s orientation.

One of the things I didn’t consider when making this program was that I’ve set the speed of the character based upon the change in rotations (with the addition of some threshold values to make sure it can continue one direction and doesn’t just travel forward and back), but because of differences in the screen size I can turn on one axis a lot quicker. That’s something to consider for the future, should I ever put this to use.

The gyroscope sensor code I’ve used in this code can be found in the below videos (neither of which are my own content). The first targets the gyroscope sensor explicitly, the second is targeting an accelerometer, but I think it gives a better insight into the event values array that the sensor events provide. These are the X, Y, and Z rotations in the case of the gyroscope, and that took a while to wrap my head around.

Video 1 – Last accessed 21/05/2017

Video 2 – Last accessed 20/05/2017

As an afterthought, it wouldn’t be a bad idea to monitor the change in angle to calculate acceleration. This is more physics work than anything sensor-based, but it’d be a cool way to improve the app.


It probably isn’t a great idea to rely on Visual Studio and WPF for everything. That’s what I decided at the beginning of the week as a thin excuse to take another crack at trying GTK#. I’d considered using this as part of my final year project, but ultimately decided that it was too unfamiliar and that I could get a lot more done a lot sooner by using something I knew.

Now I’ve decided to take another look at it because I want to write something for the Linux OS I have on my computer. I’ve took a crack at some little, console-based things before, but I knew that eventually I’d like to make something with a GUI (I should probably take a look at installing Java on there sooner or later). Apparently you can run anything you make on the Windows OS on a Linux or Mac installation if you run it through the Mono Project software; it’d be nice to have some familiar libraries available when I get back to it.

It’ll be interesting if it works. Still, new framework, so baby steps. I’ve been writing everything in a new editor (Xamarin Studio) for a new framework so it’s not the most technically impressive thing I’ve ever made; so far I’ve got a simple box to store a list of strings.


Seems simple enough, but GTK# (a wrapping of GTK according to the website) doesn’t seem to have the same kind of simple layout as other frameworks. I spent a good while yesterday trying to figure out how to programmatically add data to and from the combobox; you can insert text, but try to get the text back and you find a CellView object (as I say, early days).

In fact I think it would be fair to say that most of the time it took me to build this (far longer than I expected for something that I could knock together in any framework I’m familiar with) was spent trying to puzzle out which of the strangely named features accessed the data I wanted. I’m a little disheartened at my progress to tell the truth. Still, I do intend to get it running on my Ubuntu installation, that was the point after all.

This is hardly the most interesting of posts, but, like with my recurring project, my reasoning (if that’s what were calling it) is that I should try and document as much of what I do as I can; it’ll stop me repeating the same projects over again. From this I think the take-home is that new frameworks will bug you if you don’t take the time to learn them properly (or if all the documentation for them is written in another language from a couple of versions back).

Simple Route Traversal

So a while ago, during a university module, we all had to make a design data structures that could support bi-directional travel. It was a fairly interesting task, and I’m happy to say I did very well.

The problem with this was that the implementation wasn’t very fun to look at; the purpose of the task was to build efficient data structures in C++. I’ve decided to build a similar sort of thing, but instead of just re-uploading my old code (which feels a bit like cheating) I’ve built a new system complete with a GUI.


Figure 1. My program displaying a simple network

The system currently works as follows. Add a node, create a link between two nodes, and find a path between the two.


Figure 2. A highlighted route in my program based upon input criteria

The data object

One of the reasons I decided to do build this is that I’ve recently being writing C programs with data structures. Since these only had to be tiny things to demonstrate functionality I kept finding myself writing a simple list implementation that can be searched by recursively checking each node and accessing its ‘Next’ node. This project finally puts this structure to some use.

Each ‘node’ in this project contains an identifier, X and Y coordinates, and a list of other nodes that connect to it. Algorithms in this project work by recursively calling each connected node from the current. The root node is accessed first.

Infinite loops

Creating this the first time was infuriating! Create a system in which you can only visited a place once and you’re fine, but add the ability to travel backwards and you have to start keeping track of where your going.


Figure 3. A simple recursive loop that would cause a stack overflow if previously visited nodes were not taken into account

Take the above example. You’d think that a simple square route wouldn’t be too much of a hassle, but trust simple logic to outfox the lazy programmer. You start at Route, which goes to 1, then to 2, 3 follows, and then since you don’t remember that you went to Route already you visit again. This continues until your program throws a scary exception, chastising you for not thinking ahead.

Which isn’t to say that this is a particularly difficult problem to solve once you put some thought into it, but it does mean you have to pass another list of nodes to whatever function you want to make sure you don’t visit them again. In the past coursework when I did this I created route objects and node objects; the route objects would hold the node objects it connected. This might be a better way to do this; have each route object have a flag denoting whether its been traversed yet. It would be more complicated (something I’d rather avoid when an overly-complex spec isn’t provided), but it would be more elegant, and would stop me iterating through the entire list of past nodes every time a new node is checked.

Drawing the network

WPF doesn’t have a HTML like canvas, but if you inherit from a ‘UserControl’ it will let you override the OnRender method you can access the basic visual methods: DrawLine, DrawRectangle, etc. Apparently this doesn’t do particularly well when the visual element has to refresh quickly, so my hope of making this scroll-able might have to wait a while (I’m sure I’ll try it, though I’ll feel a tad less proud if I wind up with a sluggish mess).

Saving and loading

It never occurred to me that this would be so time-consuming. As with all other software I want to be able to save what I’ve made so I don’t feel like the 2 hours I’ve spent looking at a screen could have been spent lazing around on the couch for all the effect it’d have on my productivity.

The problem with saving the state of this program was that you have to create load in links between nodes that might not have been loaded yet; you can save out a node with its list of connections, but when you load it in you can’t recreate that connection until you recreate the necessary nodes. My solution: create a simple structure to store the node and its list in string format and then evaluate each once they’ve all been created. I know, hardly splitting the atom is it? Nonetheless, I’m pretty happy that I’ve got an extensible solution that could be applied regardless of the size or structure of the route put in.

Improving the program

Right now the route that the program suggests when prompted is based upon the order in which the nodes were attached to each other. This was all I wanted for the time being, but it’s not the best way of finding a route. There are many different algorithms, and I want my program to tout at least some variety. What would make this really great would be the ability to calculate the shortest path between nodes, or fewest individual routes.