Thursday, 25 May 2017

The dirt texture that could have been

So, since starting my newest project, I've been making some textures. The first texture I made was a dirt texture which turned out pretty damn well. It's pictured below.

Monday, 22 May 2017

A rundown of my newest project

This is as good a place as any to explain my failed attempt at dealing with exams.

You see, I was planning on burning out after Ludum Dare. I would start a daily tutorial series almost immediately afterwards, overwork myself and burn out so revising for exams would be a pleasant way to "procrastinate".

Friday, 19 May 2017

Damn it, Doctor Who

Watch the video version of this post here:

Alright, this is super out of step with what I usually post on here, obviously. However, this is something which I've been meaning to do for a very, very long time.

Let's start at the beginning.

Thursday, 18 May 2017

Gitting Gud At Godot - Part 9 - Sound Effects and Music

In this tutorial, we're going to get into sound effects and music. Unfortunately, since Godot doesn't package any sample sound effects with a new project, I'm going to be using a few of my own files. You can download them from Mediafire below, or use your own.

In Godot 2.1, there are two separate ways to play sound effects. One is by using "samples", and one is by using "streams". Samples are designed to be played quickly, a lot of times and often. This might include things like bullet shots, jumping sound effects, footsteps, or anything in between. Streams are the opposite. They are designed to be played less frequently, but for longer. Usually, the StreamPlayer is used for playing music.

Now, let's get started.

Wednesday, 17 May 2017

Gitting Gud At Godot - Part 8 - The AnimationPlayer

Watch the video version of this tutorial here:

In this tutorial, we're going to delve into the exciting world of the AnimationPlayer, the node which (unsurprisingly) handles animations.

Tuesday, 16 May 2017

Gitting Gud At Godot - Part 7 - Instancing

Watch the video version of this tutorial here:

In this tutorial, I'm going to explain instancing. This topic isn't super hard, so prepare for a little break from the more intensive stuff!

Monday, 15 May 2017

Gitting Gud At Godot - Part 6 - Intersections and Signals

Watch the video version of this tutorial here:

In this tutorial, we're going to deal with intersections and signals. I'm sorry to let you down, but we're going to have to put off instancing until later since it's actually a lot bigger than I thought. I hope you can forgive me for the most egregious form of deceit.

Friday, 12 May 2017

Why am I not making games right now?

Well, the short answer is exams.

The long answer is god damned exams.

The longest answer is that failing my exams will cause me a lot more undue stress and anguish that could be avoided by putting in a little more effort to pass them.

Thursday, 11 May 2017

Gitting Gud At Godot - Part 5 - Basic Physics and Collision

Watch the video version of this tutorial here:

In this tutorial, I'm going to be explaining the topic of collision. However, before we can get into collision, I'm going to need to show you some physics bodies and how they work.

Wednesday, 10 May 2017

Gitting Gud At Godot - Part 4 - Input

Watch the video version of this tutorial here:

In this tutorial, I'm going to explain how to add some input handling to your game. I think it's safe to say that most of you will want to know about this one!

Tuesday, 9 May 2017

Gitting Gud At Godot - Part 3 - Scripts

Watch the video version of this tutorial here:

In this tutorial, things are about to get interesting. We're going to use GDScript to add some functionality to the nodes from Part 2. Also, I'm going to assume that you have some knowledge of how a programming language works, though I'm still going to explain how to use GDScript.

Sunday, 7 May 2017

Gitting Gud At Godot - Part 2 - Nodes

Watch the video version of this tutorial here:

In this tutorial, I'm going to cover the concept of nodes and what you can do with them in a bit more detail than in part 1.

Saturday, 6 May 2017

Gitting Gud At Godot - Part 1 - Introduction to Godot

You can find the video version of this post below:

In this post, I'm going to help get you into the basic thought processes that are vital to understanding the engine.

Thursday, 4 May 2017

Why non-constructive criticism is stupid

Criticism can be one of the most powerful forces in the artistic world. When it's being used without giving the opportunity for the creator to improve, it can prevent beginners from developing their rookie skills for fear of being needlessly put down.

Sunday, 30 April 2017

Why Ludum Dare is important

Find the video version of this post here:

The tri-annual Ludum Dare event is a very useful (and hopefully, fun) resource for almost all developers, indie or otherwise.

Tuesday, 25 April 2017

Ludum Dare 38 - How Polar Protector came to be

Ludum Dare 38 was my first experience with a game jam, and overall it was a damn good one. As expected, I found myself under a lot of pressure to avoid over-scoping, and I think I did so successfully. I ended up finishing the game about 10 hours before the deadline for the compo.

Thursday, 20 April 2017

You are in dire need of new perspectives

If you're making games, you're making experiences. Each element of your game in some way contributes to the overall experience, whether it's graphics, story or a certain sound effect.

It subsequently comes as no surprise that in order to understand how to effectively craft an experience for the player, you need to understand how a specific element makes a player feel. Whether you realize it or not, game development is a game of empathy.

As the developer of your game, you are the worst critic of your game. Your perspective is the most likely to be warped from hundreds of hours spent thinking about or playing with it, as well as the knowledge of all the past iterations and even the original vision for the game. These all contribute to making your opinion of your game nearly useless. I'm not saying that you shouldn't play-test your game, because you definitely should. Some things are universally recognizable. The point I'm making is that there are innate biases in a developer's perspective.

Simply put, you need new perspectives.

You need players to tell you what is wrong with your game as well as what is right. You need players to tell you what the game makes them feel. You need players to tell you what other games make them feel. You need to read what other developers are saying. You need to listen to stories from other developers.

Without all of this, it's going to make developing a game very hard. The worst thing you can do is fail to empathize with the people who will be playing your game.

Of course, it's not just the players. You need to be able to empathize with the stories of other developers, especially if you're just starting out. Without being able to get a comprehensive view of the industry and how it treats people, you're in for a rough ride. The next time you're listening to a talk at GDC and the developer spends the first 15 minutes introducing themselves, stick with it and listen to them. Chances are that by watching this, you're understanding the biases and path through the industry by which the developer came to be.

No two people live the exact same life. Even if they did, it would be exceedingly rare. Making a game for yourself is great and I don't mean to say I discourage it, but if you're expecting other people to listen you have to make a game for them too. This applies doubly if you're selling your game.

Next time you're drawing a sprite, writing a plot twist or composing a soundtrack, try to find someone who you can ask about it. Ideally, don't have this be friends or family, though if you're in dire need of a new perspective they'll do. Do this as often as possible for as many iterations of your game as you can. It will help.

I hope you found this informative or otherwise enjoyable. Thanks for reading!

...and good luck with Ludum Dare 38!

Monday, 17 April 2017

Shoehunt is now released!

Check it out on Gamejolt here:

Shoehunt is a game I made in about 2 and a half days to test the boundaries of what I can do in a similar timespan to the upcoming Ludum Dare event. It's not exactly a complex game, but I thought it's worth releasing into the wild regardless.


Composing music for your game is not an impenetrable, monolithic task

I've seen a lot of developers take music composition to be nigh impossible. This is, of course, not the case. With the sheer quantity of online resources at your disposal, it's difficult to justify not being able to at least attempt to make your own music.

I'll preface this by saying that I'm not actually trying to ruin the lives of professional musicians. What I'm describing below is how to achieve the bare minimum in order for your game's soundtrack to not actively bottleneck the rest of the experience. I'm not explaining how to recreate the same amount of emotion in the OST to FTL: Faster Than Light, nor the same amount of energy in Super Hexagon. I am only describing how to just about get to this level, possibly with better mixing.


The first preconception you may have is that you need to either invest or pirate some expensive software like FL Studio. This is certainly untrue. In fact, LMMS is a relatively simple piece of software which allows you to synthesize sounds, sample sounds, add a myriad of effects and install plugins. It's got a bit of a learning curve, but it's reportedly less steep than FL Studio's so hey- maybe LMMS is better for beginners after all*!
*I have no experience nor authority regarding FL Studio

At this point, it's quite likely that you will install LMMS, turn 360 degrees and walk away. If you don't, great! I'm glad! LMMS can be very powerful if you're willing to put in the time and effort to learn it.

However, if you were part of the former crowd, there are easier options. At this point, I'm going to focus on chiptunes in particular. LMMS can make chiptunes, but it's also used for making many other kinds of music.

2. Famitracker

Famitracker is a wonderful piece of software. It's incredibly powerful for making chiptunes, and a lot of people who make chiptunes professionally still use this software. Depending on how closely you follow this blog, you may be asking at this point "Alex, how do you run this program if it's Windows-only and you're running Linux?". The answer to this is that it runs remarkably well under Wine. It runs almost as if it's native. I've encountered no bugs nor crashes in my time using it. Even if you're running Linux, I would recommend giving it a try.

If you install Famitracker and freak out even more than you did with LMMS, don't worry. It's a very intimidating program, but when you get to know it it's very easy to use. There are a few core principles which are outside of the scope of this project that make it a million times easier. I would personally recommend watching some of Ben Burnes' "How to use Famitracker" series in order to get you started.

Failing that, not all is lost. There is one final level of simplicity to drop down to. It's what I used for Super Displacement, and I'm fairly proud of what I did with it.

3. BeepBox

Rather than being an application, this is a website- BeepBox.

BeepBox is probably the easiest thing to use in the world. It's not very flexible, but compared to its simplicity it's more than permissible. If you are at your wit's end and don't want to spend more than 2 minutes to learn how to use a program, then BeepBox is where you should go.

Even if you are a die-hard Famitracker fan, BeepBox is good for sketching out some simple songs which can be more powerfully adjusted in Famitracker, or even LMMS.

Regardless of your preference of software, I hope you found this post informative or otherwise enjoyable. Thanks for reading!

Saturday, 15 April 2017

Why Godot 3.0 is something to be excited about

With Godot 3.0 soon reaching stable builds, it's time to get excited. A number of improvements and new features are on the horizon.

In particular, a new audio engine is on its way. Anyone with experience of Godot 2.1's audio engine knows that this alone is some incredible news.

Godot 2.1 currently uses samples and streams as two separate concepts. This gets a bit messy sometimes, given that some things such as music, dialogue or other "one-off" effects benefit from being set as streams while other things may benefit from being samples. Keeping track of both a SamplePlayer and a StreamPlayer can get confusing.

Godot 3.0 is simplifying this process by only supporting streams. This isn't as detrimental to performance as it sounds, as the appropriate optimizations for each are still being made.

Additionally, Godot 3.0 is adding functionality for much easier integration with C++ modules. This is coming by way of GDNative(formerly known as DLScript), a kind of bridge between external libraries and the Godot engine itself. This is also huge, given that now recompiling the engine is no longer necessary for the sake of integrating with things like Steamworks.

Image courtesy of AlisterCat

On top, they are re-writing the rendering engine to be both faster and more versatile. Particles can now be GPU accelerated! For those of you who don't know- this is another incredible feat. This means that particles are now very cheap to render en masse!

There is even some experimental functionality to export to WebAssembly. This is the feature that I am most excited for in Godot 3.0.

Right now, Godot can export to HTML5 in Javascript. As it is now, it's pretty rubbish. It's not particularly well optimized compared to other games made in such frameworks as Phaser, though that is to be expected- transcompilation is not always the most effective task. With WebAssembly, these layers of interpretation are removed, making webgames built in Godot faster and hopefully less buggy.

Of course, that's not to say that Godot 2's HTML5 export option is unusable. It's not. I ported my game, Super Displacement, to HTML5. While it does work, it is notably slower than the desktop edition and sometimes the scoreboard inexplicably doesn't work. You can check this for yourself below.

Shameless self-promotion aside, I've been using Godot 3.0 straight from Github. It's a little bit buggy sometimes but damn, it feels good to be able to make use of the above features! If you want to, it's fairly simple to compile it from source. You can find the instructions here!


The instructions to compile Godot 3.0 on Linux/BSD are wrong if you are using openssl version >= 1.0.0. Trying to compile using a simple scons platform=x11 will result in an error. In fact, you need to use scons platform=x11 builtin_openssl=yes use_llvm=yes.

All in all, Godot 3.0 is going to bring with it an up-tick of popularity, which means an up-tick of documentation and community, which helps to alleviate one of Godot's largest criticisms at the moment- that it has a small userbase.

If there ever was a time to get excited about the Godot engine's success and getting it popularly counted alongside Unity and Unreal, this is that time.

Either way, thanks for reading! Check back in 2-3 days' time for a post on why composing music for your game is not an impenetrable, monolithic task.

Tuesday, 11 April 2017

How to accept criticism of your game

Accepting criticism of your product is hard, and if you're reading this you probably don't need me to tell you that. Every artist - regardless of whether they're a painter, game developer or musician - will eventually have to take criticism of their product, and it's important to know how to take it properly. Hell, even if you don't consider yourself an artist at all I'm sure this post would probably still be helpful if you have trouble taking criticism.

Understanding the difference between "you are bad" and "your game is bad"

One of the most important things to realize is that as the developer of a game, you are not the target of criticism. It's very easy to take critique too personally, or take it to mean that you are "bad at making games", where in reality what a critic might mean is just that "this game you made is bad".

One of these two interpretations involves an attack on your person. It suggests that you are incompetent at doing the thing you are so passionate about, and that really sucks to think about. The other interpretation involves accepting that you simply made something that wasn't good enough, and to leave it at that. Extrapolating this basic concept to imply that actually you're a terrible artist, a terrible programmer, a terrible mathematician, a terrible composer, or the myriad of other things which you can be terrible at is actually tremendously harmful to your willingness to work.

Of course, taking a simple criticism as what it is at face value is much easier said than done. It takes active effort to keep yourself from continuing the spiral of rapidly diminishing self-esteem, but you have to take my word for it that it's worthwhile to do.

Now, don't misunderstand. I'm not telling you to ignore criticism just because it makes you feel bad. Feeling bad sucks, but it's important for the learning experience. Without a disincentive to keep making rubbish, you would hardly improve at a reasonable rate.

What I am saying is rather that you should never view your own skills as being absolute. In Western culture, there is a lot of worship of the innately talented musician, a repressed "hidden talent", or even that of the noble savant. The truth is that the first two are all but non-existent and the third is exceedingly rare(and its usefulness is questionable at best).

Your skills are fully malleable and constantly evolving balls of amorphous goo. They will never be stable for very long, perhaps a year or two at most. From there, you're bound to either improve or become unfamiliar with them. The point I'm making is that if you think you are innately not good at something, you are wrong. It might be more difficult for you to improve or to learn than it is for others, but it is certainly never "gated" beyond your capabilities.

As stated, your skills are malleable and they usually do not define your character. It's important to understand and admit that you're bad at something if you're bad at something, and separating yourself from your skills is a large component of that.

Criticisms do not exist in a vacuum

Criticism is full of bias, and could be argued to not exist without bias. It quite easily follows that what one player perceives to be true about your game(unsatisfying controls, unappealing graphical style) might not be true to many others, or vice versa.

The important thing to realize here is that if you are receiving a criticism that you believe to be unfair, it is possible that it is unfair. Whatever you do, do not go crazy with this idea. It's something to keep in mind, but it's to be used incredibly sparingly.

On the other side of the coin, you as the developer may also be biased. I'm not talking just about the idea that the developer may be so highly protective of their game to the point of ignoring criticism, I'm also talking about the developer genuinely believing that their game is good because it aligns perfectly with what they want out of a game in that genre. However, it's also possible that what you want out of a game in a given genre is simply not what many other people want out of a game.

It's no secret that some developers want to make or have made games which are almost entirely inaccessible to the audience. Even among games with cult followings such as Dwarf Fortress, this is a common criticism.

Every piece of criticism is an opportunity

Every time someone suggests an improvement or tells you something about your game which you didn't want to hear, you gain a little bit of insight. Even the most benign "This game sucks 0/10" comment can help you to understand a perspective which you could never otherwise begin to comprehend.

This sounds very flimsy, but it is tremendously important. So much conflict is based off of simple misunderstanding of each other's views. Any opportunity to gain insight into another person's perspective is a valuable one.

If you truly want your game to be the best it can be, then you have to consider as many perspectives as you can. You have to take in every piece of criticism and evaluate it as fairly as you can. Of course, this isn't easy. It's both cognitively and emotionally strenuous to accept and work out flaws in your game.

Then again, no one says that making a good game is easy!

As usual, if you have done, thanks for reading! Stay tuned for more semi-regular posts.

Saturday, 8 April 2017

Preparing for Ludum Dare 38!

At the time of writing, it is precisely 13 days and 2 hours until Ludum Dare 38 starts.

This is also going to be the first Ludum Dare which I actually participate in! I'm making a post here as a kind of "promise" to my kind readers so that I don't back out like I did for LD36...

As expected, I have little idea what to expect. I have no idea as to how well I'll perform over such a tight deadline. Obviously, the scope of the project would be considerably smaller than anything I've done before(well, I say that, but...) while on the other hand I'd be working a lot harder and faster.

Also, as of right now the theme selection should have started 24 hours ago at the latest. This is good.

Amidst the tremendous amount of uncertainty, I have a schedule for how I'm going to split my time over the weekend. Rather, I have a plan to make a schedule. I'm still evaluating the advantages and disadvantages of staying up until 2AM local time to find out the theme, or wake up at 8AM and find out the theme.

Additionally, by now my experience with the Godot engine has made it very easy to set up a simple top-down or sidescrolling base, on top of which I can put any necessary theme-specific developments.

I've also come up with a vague formula for the format of the game. Once the theme is released, I'll take it and try to make a scenario out of it. From this scenario, I can take a simple goal out of it and make that the overall goal of the game.

Since what I'm trying to say is coming out horribly unclear, I'll provide an example. The developer Pixel Prophecy made a game called "6210 B.C.". This game was a very simple slice out of the relationship of two competing tribes of cavemen. The details on the game can be found by either watching his post-mortem on 6210 B.C. or by visiting the game's page itself, linked in the description.

Of course, what is life without some form of substance abuse? Having eroded(if not totally shed) my caffeine addiction, I should be more susceptible to the focus-enhancing and fatigue-eliminating qualities of large quantities of coffee.

As usual, thanks for reading!

Thursday, 6 April 2017

Quick and easy ways to add "game juice"

If you're in a hurry, I'll just give you a list of the things I'm going to cover in this post.
  • Use screenshake
  • Use particles
  • Add bass to your sound effects
Okay, so for those of you who are not in a hurry, I'm going to take this a bit more slowly.

There are some methods of "juicing" a game which are so common and versatile that they can be applied to most arcade-y or action-oriented games.

Tip #1: Use screenshake

Screenshake can be incredibly effective if used correctly. Randomizing the camera offset every frame for even a tenth of a second makes explosions and high impacts feel considerably more powerful.

However, one thing to be wary of is that it can cause motion sickness if overused. I've never experienced this, but I've heard several anecdotal reports that excessively shaky screens can make some people a bit unwell. The easy solution to this is to either add an option to disable screenshake, or to limit it to only during certain explosions and only for very short(less than 0.2 second) periods.

Tip #2: Use particles

Fewer things make a game feel more flat than killing an enemy only for it to unceremoniously disappear. If you are graphically limited(as I was in the development of Super Displacement), particles are incredibly useful. If you're going for a lo-fi art style, large and blocky particles can be tremendously helpful. They can be used (conservatively) for a collision, for an enemy death, or anything that you think looks kinda bland (provided that you choose the right colours and speed for the particles to travel at).

Again, there's a catch to using copious amounts of particles. It can seriously lag older computers.

Warning: Don't try to turn down the number of particles for the sake of larger particles, because more often than not this doesn't work. In most systems, the GPU makes a calculation on each pixel that is occupied rendering a particle. This means that if you're balancing the same number of pixels that are being rendered as particles by just increasing the size of each particle, you're not really saving the user any performance. Instead of this, I would recommend a button to turn all non-essential particles off entirely.

Tip #3: Don't be afraid to add bass to your sound effects

This is applicable to a lot of games, and it's something that I've seen a lot of beginning hobby/indie developers fail at. If your sound effect sounds a bit toss, chances are it just doesn't have enough bass in it. Go to audacity, open your sound effect and apply a bass boost. Even if this doesn't immediately make your sound effect amazing, it'll help most of the time. Of course, if you're an audio engineer then you already know that what I'm saying is mostly rubbish.

If your sound effect doesn't fit the game, just don't use it. This isn't really about "game juice", but sound effects make a massive difference to how a game feels.

Rami Ishmael, the public half of Dutch independent studio Vlambeer, often recounts how in SuperCrateBox players would be more inclined to play aggressively, get higher scores and proceed to enjoy the game more if the sound effect to the gun was more powerful, keeping the graphics and the gameplay identical each time. This is a perfect example of sound effects affecting the game in more ways than can often be predicted.

Regardless, I hope you found this post useful. This is probably going to all seem very obvious to the seasoned veterans of indie development, but personally, I would have loved to see this post about a year ago.

If you disagree with anything on this list, or if you think that I've missed out on something super obvious, leave a comment. Otherwise, if you have been- thanks for reading!

Monday, 3 April 2017

Lessons Learned from Super Displacement

Super Displacement is a hectic, arcade shooter where the player must shoot an onslaught of aggressive quadrilaterals and avoid being bounced into the walls.

In the past two or three weeks spent working on this game, I've learned some valuable lessons on how to produce a suitable working project- the first project that I can confidently say I'm proud of.

The key point to Super Displacement is that the scope is very small, even for a one-man project. When I started it, I intended it to be a remake of a previous project, "Don't Be Still". Of course, over time this changed to the point where I had to change the name given that the central mechanic was no longer needed for the game to be a fun experience.

The reason that I removed the "don't stand still or you lose" mechanic was not exactly born of great design principles, it was actually due to the fact that moving fast made the collision detection go a bit... iffy. The easy fix(before realizing that using Godot's _fixed_process function made collision detection easier) was simply to make it so that the player only hits the wall once per gameplay, i.e they lose when they touch the wall. At this point, forcing the player to keep moving seemed tacky. It would have overloaded what is designed to be a very simple game.

After adding a copious amount of particles and screenshake(both of which seem to be very effective for some easy-to-apply "game juice"), I decided that a similarly easy way to apply some extrinsic reward is by adding a high score system.

As many of you may be aware, I used the GameJolt API to add a public, synchronized high score system. I think that this was a large help in terms of replayability, otherwise the game gets somewhat repetitive. As someone who has spent about 20 hours testing the game over and over again- dear god does it get repetitive, and I've only been working on it for a couple of weeks.

In a similar vein to Super Hexagon(though the comparison seems egotistical), Super Displacement encourages the player to keep retrying to beat either their own high score, or to earn a place on the leaderboard. I believe that this could be aided had I made it easier to lose more quickly, as currently individual matches can last several minutes.

Also, graphically the game wasn't particularly impressive. However, I believe that it looked just acceptable enough for the graphics to not bottleneck the overall experience. This was a large part of why I feel this game was - if nothing else - a personal success. I've successfully achieved a semi-minimalistic art style without it looking too rubbish. Having said that, the background started a placeholder and (sadly) evolved into a defining piece of the game's identity.

Either way, I hope that you can take some lessons from what I've succeeded and failed at doing in Super Displacement.

You can download and play Super Displacement at the link below:

Since I'm unlikely to continue to update this project, get hyped for my new one- and if you have done, thanks for reading!

Wednesday, 29 March 2017

How to Implement Scoreboards in Godot with the GameJolt API

GameJolt is not the largest gaming platform, nor is Godot the most popular editor. Despite this, a kind user known as "ackens" has created a plugin for Godot, which allows super easy integration with the GameJolt API.

This plugin can be downloaded at this link:

Since the Internet failed me for quite a while on how to install this plugin- I will enlighten the kind readers of my blog. Inside your project folder, (res://), you need to make a folder called "addons". Place the "gamejolt_api" folder inside that folder(res://addons/).

If you have done this correctly, you can return to the editor and press "Scene" in the top-left, down to "Project Settings" and select the "Plugins" tab. The API should show up as an entry called "Game Jolt API". Simply set its status on the right hand side from "Inactive" to "Active", and you're good to go.

From here, there are a number of things to tackle. I'm going to be primarily explaining how to submit guest scores to a scoreboard since this is what I used the API for in my game, Super Displacement.

The assumptions that I will be making from here on are that:
  1. You're using a scene that isn't your main gameplay loop to do this(though if you are, I'm sure this can be adjusted)
  2. You can make a better UI for this than I can.
  3. You have a given score to submit.
If all of these 3 apply, then we can get started.

Before you can do anything, you must add a GameJoltAPI node to your scene. Each API command you make will be a method on this node, i.e it will be of the form:


Before making any of these calls, it's important to set two properties of the node: your game's Private Key and its ID. These are used to identify to the GameJolt servers as to which game is being edited.

Both of these variables can be found by going to your game's page on GameJolt, clicking "Manage Game", "Game API" and selecting "API Settings" on the left hand side.

Once you have entered these values, you're ready to start making some API calls.

For Super Displacement, the need to log into GameJolt was never present, so I did not need to use .auth_user("token", "username"). Fortunately for me, the GameJolt API has a function called "add_score_for_guest". This - as the name would suggest - allows a score to be submitted as a guest, where the user never has to log in or input anything other than a display name. This makes things very easy.

I used a LineEdit object for the user to input their desired display name, and on pressing either the enter key(using the "text_entered" signal on the LineEdit) or the "Submit Score" button, the text in the LineEdit(get_node("../LineEdit").get_text()) is returned to a script which then submits the request.

However, that's not quite my implementation of it.

One. For some reason, either GameJolt or the implementation of it in Godot freaks out if there are spaces in the display name. This is a super simple fix, as the only way around this (beyond rejecting the user's input if they input a name with spaces) is to simply remove the spaces from the name, using:

    guest_name.replace(" ", "")

This command quite simply moves through the string, replacing any instances of the space character with an empty string. In effect, this removes the spaces. "The Best" becomes "TheBest", etc.

Two. What if the user doesn't input a name? While this doesn't stop the request from happening(as far as I know), it may be helpful to put a stock username in its place.  For this, I did a simple check:

    if(guest_name == ""):
     get_node("../../GameJoltAPI").add_score_for_guest( .. , .. , "Guest" + str(randi()%10000000))

Though it makes my inner PEP8 fanatic weep, it does the job. If the user has not entered a name into the LineEdit, it generates a random string of 7 numbers and appends it to the word "Guest".

At this point(and probably a bit earlier) I should explain how this method works.

The first argument (called the "score" in the plugin's documentation on Github) is a string which is displayed on the "Scores" section of your game's page. This might be "23 Castles Destroyed", "381 Enemies Slain", or whatever quantifier you want to add. In my case, I simply set this to "str(latest_score)", since there isn't much of a quantifier beyond "Points" to add to an arcade score.

The second argument (called the "sort value") is an integer value which tells GameJolt how to order the scores in the table. Assuming you have the score table in "Ascending" mode - big means good - a higher sort value will mean a higher placement on the scoreboard. In my case, this is "int(latest_score)"(since latest_score is originally a float value).

After that, that's really all there is to it. If you wanted to add scores for a logged in user, you would have to .auth_user("token", "username") and then .add_score_for_user(visible_score, sort_value).

Displaying scores is also very simple, though it requires some playing with JSON files first.

Again, assuming you have a GameJolt API node in your scene, you're ready to make some API calls.

For my HighScores.tscn scene, I put a standalone call for 30 scores into the _ready(): function:


Your immediate reaction might be confusion as to why this isn't being printed, assigned to a variable or anything else- it's because the plugin responds with a signal that carries the scores in a string. This signal is called "api_score_fetched(var scores)".

You might also be confused as to why the "30" is a string and not an integer and to be quite honest I have no idea, but it has to be a string for some reason.

Connect this signal to a node of your choice, and try to print(scores) - you'll get something that looks an awful lot like JSON. The explanation for this is that this is JSON, but it's encoded in a string, and we have to parse it into a dictionary.

Do something like this:

    var scores_dictionary = {}

This creates an empty dictionary, and parses "scores" into a nice dictionary format, where it can be indexed. There is a list of dictionaries contained at the ["response"]["scores"] indices.

I implemented the "table" in the screenshot above by creating 6 separate labels, for 2 sets of 3 labels. The first label consists of the numbers, which I added manually. This could very easily be automated, but that is an exercise left to the reader.

The second field consists of the names of the users who have submitted scores. This can be obtained by creating a variable named "names", iterating through "scores_dictionary" and concatenating each guest name to "names" along with a \n for the linebreak.

The code I used for this part is as follows: 

    var names = ""
    var names2 = ""
    for i in range(visible_scores.size()):
            names += visible_scores[i]["guest"] + "\n"
            names2 += visible_scores[i]["guest"] + "\n"
Assuming the line spacing and Y coordinate is the same, this will line up with the numbers.

The variable and node called "names2" is the second instance of each list of names, as shown in the screenshot above.

The exact same process can be used for the score, all you have to do is reference [i]["score"] instead of [i]["guest"].

If you have implemented these correctly, you should get a nice, basic scoreboard for further extension and development. Also, I'm sure there's something better than Labels to use for this kind of thing, but this technique can be adapted suitably.

If you have any further queries, you can leave a comment below and I am very likely to answer it. In any case, thanks for reading, and good luck!

If you want to download my game "Super Displacement", you can at the link below:

Sunday, 26 March 2017

(Tentative) Release day for Super Displacement!

Super Displacement is a hectic, fast-paced shooter where the player's job is to shoot enemies and avoid getting bounced into the walls.

Sounds fun? If it does, this game is for you. If it doesn't, then this game is probably still for you. If you're on the fence about your decision to play this game, the game is absolutely for you. If you categorically hate fun- this game is not for you, I'm sorry.

Still play it, though.

It's currently being kept in Early Access, because I think I'm going to keep updating it with new functionality. Regardless, thanks for reading, and you can either download straight from this page or visit the page on Gamejolt.

Or, the page on Gamejolt is linked here.

Saturday, 25 March 2017

Super Displacement

Super Displacement is a hectic game in which you bounce around and avoid touching the walls.

If you like the sound of that, feel free to continue reading.

As some of you who keep up-to-date on my work may know, I recently dropped another project to remake "Don't Be Still". After starting work on "Don't Be Still", I realized that the initial mechanic had no place in the rest of the game, and I renamed it "Super Displacement".

The premise of "Super Displacement" is very simple - don't touch the walls, and shoot the rectangles that are trying to bounce you into the walls.

Playing it myself(I may be biased) and receiving feedback from friends(also biased), it seems to feel pretty good. I feel confident in saying that this is my best work yet, though that doesn't mean much given my portfolio of abject failures.

Unfortunately, screenshots do not do the frenzied nature of the game any justice. If you like screenshaking, explosions and lots of bouncing around, then this game is probably going to be enjoyable for you.

I've spent a lot of time in this post just "selling" this (free and unreleased) game to you, so now I'm going to talk about something which no one online seems to tell you. Also, if you're not programmatically inclined or don't use the Godot engine, this might be of limited usefulness for you.

Handling Save Data in Godot

So, Super Displacement uses save data to store highscores and a couple of other statistics. Unfortunately for me, due to Godot's rather limited documentation no one told me that Godot fucks up when you try to save the file as a resource("res://...") rather than as a user file("user://...").

In short, files referenced as a resource("res://...") are contained within the executable while files referenced as a user file("user://...") are contained within something like $HOME/.godot/Super Displacement/

Apparently, resources can't be written to in the same way that user files can.

If there's a takeaway from this short segment, it'd be "Don't be afraid of using user files because resource files have annoyed me and taken an hour of my life from me and I hate them forever".

In any case, thanks for reading.

Tuesday, 21 March 2017


To cut a long story short, I set out to work outside of my own realistic capabilities with Solasi and I am effectively forced to cancel it. Sorry.

A Post-Mortem Of Solasi

For those who don't know, Solasi is a game in which you control a guy stuck in an underground bunker, who has to deal with his nightmares and his descent into insanity. It's kind of like a survival game.

It is fine in concept- though I find it abrasive to think about for too long given the amount of time I've spent hitting my head against the most basic components of it.

So my first mistake was coming up with a story or narrative-based idea when there is so much restriction on how I can convey this narrative. My only real option was to either hide messages on the map itself and change them each day, or to present the player with a pop-up window at the start of each day. Of course, the former is preferable. Unfortunately, neither of these options are quite enough to make the game worthwhile playing.

What I should have done was go into the game with a clear understanding of its strengths and weaknesses. What I did instead was come up with a large yet fun idea in my head and throw my face against it. Lesson #1: Don't underestimate a comprehensive design document.

When I came to making the game, I made some good use of placeholder assets. I'm quite happy with the fact that I did wait until the "end" to start adding some visual sparkle, because otherwise I never would have gotten as far as I did.

However, I didn't clearly define the environment itself and ended up semi-overhauling the visual design to a more monochromatic and dull look only to realize that I could never finish this project. I had set out with no clear ideas for the enemies, so I had no cohesive ideas as to what they should look like as a collective and this only served to build what would become an insurmountable challenge.

Lesson #2: Plan things out before you start programming. I'm at massive risk of damaging my reputation as a programmer and game developer here, but holy hell the straw that broke the camel's back was a peculiar bug I was having where the game would just freeze. Nothing in the debug log, nothing anomalous in the stack trace- just a freeze. At first I wondered if it was randomly pausing somehow, so I set it to unpause every frame. Sadly, there was no improvement. The only possible link to it was that it was caused by the enemy type that shoots a bullet- but not linked to the bullet firing activity. Nor whenever it spawned.

After struggling with this bug for some lengthy hours, I called it on Solasi. Together with the design flaws, terrible workload and this god damn Shroedinger's Bug, I was not prepared to deal with this project anymore.

Don't Be Still

Light At The End Of The Tunnel

Solasi(apart from honing my skills for about 50 hours of work), served to provide a suitable jumping point away from larger projects back to a more comfortable arcade-y project. To be precise, the project I'm working on now is a remake of the game "Don't Be Still" that kick-started my adventures into game development in the first place.

It's small and I have a few tentative ideas for it, but so far it's feeling pretty damn fun. Pictured just above is a screenshot I took from the prototype.

In a sentence, Don't Be Still is a fast-paced shooter where the player's job is to shoot enemies, keep moving, and avoid the walls of the arena.

Touching the walls of the arena results in an instant "Game Over", while touching the enemies just bounce you around a bit. The real crux of the game - as is eponymous - is to keep moving. Staying still for too long will drain your health(not pictured) and eventually cause you to lose.

It's not a complicated concept, but so far I'm fairly happy with it. Stay tuned for more updates and hopefully within the next few weeks, a full release!

As per usual, if you have done- thanks for reading.

Sunday, 19 March 2017

Well-Executed Derivative Ideas Are Better Than Poorly Executed Unique Ideas

Take two.

So look, before anything else I want to say that by no means am I saying that totally unique ideas are bad, or should even be discouraged. Games such as “Papers, Please” would likely not exist if the developers had not put thought and effort into creating an innovative game mechanic.

However, much more importantly to “Papers, Please"'s success was the strong art style and the emotional impact it makes on the player. These were instrumental- without them, I find it hard to believe that the game would have made it very far at all. If you don’t believe me, you can verify this by looking at two or three reviews for the game. The majority of them hardly praise the passport-checking mechanic at all, especially given that the rest of the article is usually focused on the art style.

This brings me to the main point of this post: unique ideas are cool and often helpful, but it’s a lot more important to execute a given idea well. Any poorly executed idea is not likely to perform well. I have first hand experience in this, as I once created a very poorly executed game called “Don’t Be Still”.

The unique idea at the core of this game was that you had a “stillness meter”, and any time you spent being still or taking damage from enemies would deplete this meter. I think I can safely self-assess here to say that this idea was fine and a suitable game could be built on this mechanic. Unfortunately, I did the exact opposite of build a suitable game. With about 3 seconds of graphical design and no more than a day or so of programming, I threw together something which I cringe to call any more than a prototype. This idea was executed dreadfully, and as such it suffered at launch.

Ultimately, the execution of an idea comes down to a mixture of skill, effort and personal tendencies.

Don’t Be Still” was primarily gated by the first two, as I can’t speak much to personal tendencies for an engine I was just beginning with. This engine was the Phaser engine. Phaser is a Javascript framework which easily integrates with either WebGL or the HTML5 Canvas. Point is- “Don’t Be Still” was the first project that I’d ever made in Phaser, and I was still getting to grips with how it worked.

Needless to say, I effectively had no idea how Phaser worked even after completing Don’t Be Still, hence why the game is the actual dumpster that it is today. Partly because of the aforementioned and partly just because I was enamoured with the idea that hey- I could make games now, I only spent about a week on it in total before uploading it online.

The take-away from this post (assuming you’ve read up to this point) is that if you’re a newer game developer or if you’re struggling, don’t chase a single unique idea, because in all likelihood it won’t make a bad game good. Take a small idea and polish the hell out of it until it’s something that you’re proud of.

If you have done, thanks for reading.

Also, holy shit I have been lazy for the past week two weeks three weeks. If you're a repeat reader, thank you but more importantly, be sure to keep an eye out. I have something to say about the fate of Solasi, and it isn't good.

Friday, 3 March 2017

Godot Is The Best Engine - Godot vs Unity

This is a video I made to compare these two engines. The transcript is below, enjoy!

So, this is a new series I’m doing where I’ve decided I’m gonna be an unpaid shill for the Godot engine, and compare it to some other engines. This first episode is going to compare Godot to its obvious competitor, the Unity engine.

At a first glance, Godot and Unity are not so different from each other. Having said that, Unity puts a massive emphasis on its 3D editor, while Godot is primarily made for 2D development. That’s a pretty big difference right off the bat, I mean they are primarily designed for two completely different jobs. However, given that they both have support for 3D and 2D editing, they can be suitably compared.

While Godot’s 3D renderer isn’t the best thing in the world, Unity’s 2D renderer is literally just the 3D renderer locked into an orthographic viewport.

The fact that Godot at least uses a separate dedicated renderer for 2D is an advantage in itself, seeing as that minimizes the amount of performance overhead that may otherwise be detrimental to applications that rely on a high frame-rate- which just about all games do.

Another thing that Godot has over Unity is that Godot is totally free. While Unity is proprietary and closed source, Godot is maintained by around a hundred developers on Github under the MIT license. This means that Godot is free as in free speech, not as in free beer. Stallman would be proud.

Leading on from this, Unity forces users of the free version to have a “Made with Unity” splash screen at the beginning of their game. Godot has no such limitation. Though it is there by default, it can be either changed or totally disabled as the user wants.

I will give Unity some credit, in that it does not use its own constructed programming language for the programmatic side of things. This is a genuine advantage that Unity has over Godot. However, having said that, Godot’s GodotScript can be made to integrate with precompiled C++ modules very easily, for more performance-sensitive tasks.

A massive thing that Godot has above Unity is the fact that Godot is cross-platform, and available on Windows, Mac, and Linux. This is very important for myself, considering that I use Linux as my primary operating system and Unity crashes usually within about 5 minutes of work. Last time I checked, right clicking on a drop-down menu forced it to close as of about 6 months ago.

Also, Godot exports to BSD running X11. Just consider that for a moment- what other engine even acknowledges BSD exists? I don’t think anyone developing the Unity engine knows what BSD is, but that’s speculation more than a criticism of their product.

Regardless, Godot’s user interface is a lot more intuitive, at least in my opinion. It makes efficient use of space and colours, something which I do not feel Unity does as well. A petty complaint, but if there ever was a time to say it then hey, here it is.

Also, Godot’s mascot is better than Unity’s so fu

Now look, obviously I’m not saying that Unity is a bad engine. Objectively speaking, it’s powerful and has been used for a number of very high-profile cases. Having said that, Godot beats Unity at every level in so far as 2D is concerned. I haven’t used Godot’s 3D options so I can’t speak much to that, but I’m confident in saying that it’s a worthy contender.

Either way, thanks for watching. Stay tuned for the next episode in the series on… I dunno a different engine probably.

Friday, 24 February 2017

A Symbolic Analysis of "Monotony"

I hope you enjoy this, for those of you who are interested, the script I had in front of me is printed below.
So the extent of the feedback I’ve had on this one is that it didn’t work on one guy’s computer running 64-bit Windows, so if anyone watching this is running this so-called operating system, I would appreciate if you would try to run it and see if it works.

Also, regardless of what operating system you’re running, I would recommend that you play Homogeny and Monotony, the prequels to this game, and if you’re especially interested take a look at their associated symbolic analyses.

The game does open with the word “regret”, which directly follows on from the ending scene of Banality, which ends with the final title card “regret”. This is in reference to the central theme of Monotony, which is the character trying to reconnect with their estranged peers.

If you watched the symbolic analysis of Banality, you might recall that the bed represented the character’s comfort zone, which it still does in this game. The character is pressed against their bed, sort of symbolizing that they are trying to get back into their comfort zone – again referencing the idea of reconnecting and becoming “normal” again.

The character’s opening line is “If nothing else, Sisyphus was happy”. For those of you who don’t know who Sisyphus is, he was a mythological greek guy who was cursed to roll a boulder up a hill, only for it to roll back down, leading to the fairly popular phrase, “One must imagine Sisyphus happy”. The implication here is that despite the otherwise lack of real substantial content behind social activities, it’s easy to indulge in.

To be honest, I regret not making this area more clear in terms of direction- you are actually meant to touch the people in this one. Touching the people plays the reverse of the sequence in Banality, where the metaphorical representation of you is being raised up on a platform rather than descending. However, this time it breaks when you get to the top, and you fall down. This represents the idea that it’s impossible for the character to ever return to normalcy, and they fall back down despite their best efforts.

The term “desperation” as shown on the screen should be fairly straight-forward, it makes reference to the idea that the character is desperate to re-connect with the aforementioned estranged peers. Something I probably should have pointed out a bit of time ago- the character is intended to have strange or otherwise awkward speaking patterns, to sort of exemplify how they are so different from other people that they literally cannot relate to them even on the most basic terms of language. To be quite honest, “what a terrible purgatory” is totally flavour text.

This scene shows the character getting up from the platform, so obviously it’s implied that the player is now controlling the metaphorical representation of the character from the broken platform beforehand.

The character is then confronted with a button and door puzzle, like in Banality and Yet Another Puzzle Game. It’s meant to create the idea that the character is able to look at the things separating him from the other people, solve them easily, but still finds himself inexplicably distant from them when they start running after the door opens.

At this point, the other person has escaped and the character is left to find another route around the same obstacle, which in this case is over this building here. Also, the music at this point becomes somewhat glitchy and distorted, which again is mainly to convey the aesthetic that the character’s mental state isn’t good or orderly.

This next sequence is fairly dense in terms of meaning in that you have the title card with the word “quickly” repeated on it, the shaking screen and if you don’t pause then you will eventually come to the end of the background. The title card “quickly” is designed to create a sense of urgency that the character must continue to try to re-connect with people, the shaking screen represents the character’s unsteady or ineffectual effort to keep trying, and the short peak of the end of the background represents the idea that the character, in the process of their efforts, has seen things which do not make sense to them in the same sense that a three dimensional object doesn’t make sense to a two dimensional creature.

The character is not present at all in the bedroom sequence, which represents the idea that they have abandoned their comfort zone totally.

The title card “broken brilliance” is a term that has become so removed from its origin in my mind that there is no point trying to explain its origin, but it is in itself a fairly poetic concept. This will be left as an exercise to the viewer.

The colourful glitchy artifacts around the screen again represent things and concepts which don’t make sense to the character, and were never apparent or visible in their own “world”. The things they interact with would have never contained things like this, as demonstrated in the previous games being entirely monochromatic. This is linked with the term “broken brilliance”- the “game” is broken, but it’s worth it for the sake of its visual appeal.

The term “keep moving” is fairly direct in terms of meaning, it’s a direct instruction for the player to continue moving towards the end of the level.

The ending text is similarly very straight-forward in its meaning.

Wednesday, 22 February 2017

Replacing Placeholder Assets - Pixel Art Timelapse

I made a silly time lapse video where I make some much better replacements for some of the placeholder assets I was using beforehand.

I hope you enjoy!

Tuesday, 21 February 2017

A Symbolic Analysis of "Banality"

To the loyal readers of my blog, this post was originally created in video form. If you want to read the script to the video, you've come to the right place.

Watch the video here, but read the script below.


After another long while of either procrastinating, working on my latest project or doing literally anything else, I’ve finally put together a suitable analysis post for my game, Banality.

If you haven’t already, I would recommend taking a look at my previous post on Homogeny for some context on this one, though it isn’t necessarily vital. Additionally, you can download and play Banality for free, link is in the description.

The game opens with the character in their bedroom, but unlike as in Homogeny, they are not sitting on their bed. Where the bed represents the character’s comfort zone, the opening line “What now?” creates the idea that they are beginning to question things outside of their comfort zone.

The opening level bears a remarkable resemblance to my previous project, Yet Another Puzzle Game, which could be considered a prequel to the formative sequence displayed in the main trilogy. “Yet Another Puzzle Game” draws attention to the ephemeral and simplistic nature of things commonly heralded as “the standard” - the standard in this case being an incredibly simple puzzle. The same soundclip of me saying [puzzle] gets cut off and launches the character into the second level.

This is intended to symbolize the fact that after the events of Homogeny, the character can now realize that a button and a door laid side-by-side does not in fact constitute a challenging puzzle, and similarly, the things previously taken as entertaining are being outed as trivial.

The building in the second level is actually just to symbolize a social institution – perhaps a school would be fitting, as the other characters visible in the building represent two states of being. The first two are lethargically laying down as the player passes, while the last is standing up, but has their back turned to the exit and is looking down – they have no aspirations.

Pressing the “A” button to speak to any of these characters plays a short sequence of the main character on a platform being lowered into a kind of grave. They become less “alive” and more like the zombies that surround them, as shown by the greying of the character’s eyes. The sound effect – distorted noise – is designed to symbolize the total lack of meaning in anything being spoken between them.

The third level is somewhat more difficult. Even being near the other characters at this time will cause the grave sequence. This is to symbolize that as time goes on and the character moves further away from other people, becoming more stoic, they become more aware of the faults and imperfections and become even more repulsed by them.

There are three non-player characters in this level, each symbolizing three more states of being. The first one is stuck in a hole, to symbolize people who can’t – through no fault of their own – escape where they are now and achieve what they wan to achieve. The next most egregious form of bloody normie is, as detailed in the last level, those who are too lazy or unmotivated to achieve what they want to achieve.

The final character is laying prone under the ground, who has become too used to inactivity and sheer lack of creativity that they have lost the ability to achieve at all.

The word “regret” appears on the screen before the game exits. “Regret” in fact refers to the themes of the third game in the trilogy, Monotony. 


If you have done, thanks for reading. Only time will tell whether or not the symbolic analysis of Monotony is a video or in text. Stay tuned!

Monday, 20 February 2017


Hello! As some of you may be aware, I immediately started work on a new project, Solasi, after finishing Monotony.

I'll outline what my project actually is for the lovely readers of my blog.

Solasi is a survival semi-horror game. The player is trapped in a surreal underground bunker, where food and water are not rare resources. The most valuable resource is instead your own sanity -- being trapped in total isolation only to grapple with your own horrifying nightmares is bound to be harmful.

There will be two phases to gameplay. The first of which is the "daytime", where the player may perform menial tasks to increase their statistics. These statistics come in useful come "nighttime", where the player must
fight monsters - be it either to protect themselves, for the sake of slaughter itself or to acquire a Nightmare Charm simple trinket.

I am currently totally infatuated with this concept - if I can successfully translate between my mind and this computer, I will have created something truly wonderful. So far, this translation is going exceptionally well.

Unfortunately, since I'm using almost exclusively place-holder assets(except for that sick bed), it's more difficult to visually show off the game.

Either way, definitely stay tuned.

Also, follow me to help my self-esteem. Thanks.

Thursday, 16 February 2017

The final instalment in the trilogy, "Monotony", is released!

Hooray! After about a week of work, Monotony has been released. If you're interested in avant-garde art-y games, appreciative of some good atmosphere or just want a 5-minute experience to kill time - this game is for you.

You can download it below.

If you haven't already, I highly recommend you look into Monotony's predecessors for some fairly useful context.

You can download the first in the series, Homogeny, below.

And of course, the second game in the series can be downloaded below.

If you have done, thanks for following the development cycle of these games, and I hope you enjoy! Stay tuned.

Monday, 13 February 2017

Discussing the themes of "Homogeny"

After a lot of actual game development/other writing/other things, the analysis post is here!

If you haven't already, you can download and play Homogeny for free right here.

A fairly notable focus of discussion is actually as to why I even decided to create this game. The answer is split between because I liked the art style after having created Yet Another Puzzle Game, and because I wanted to create a very art-centric game.

The latter was actually prompted by a few very "avant-garde" YouTube videos, and I got jealous of the fact that the medium of a YouTube video can be used in such a way. It was shortly afterwards that I realized I could probably do something pretty similar in a game, so I tried to do just that(minus the "horror" aspect, which was incidentally very present in the two I linked).

The themes in Homogeny are, as you may have guessed, not intended to be frivolous.

To sum it up in a single word, the game as a whole represents "realization", as I retroactively fit it into a three-part story centred around misanthropy -- but we'll come to that in a few posts' time.

The full script - i.e the correct answers - can be found here.

The first presentation wasn't particularly special in that the first few sentences were a little bit clunky, entirely unguided and not really intended to mean anything. The first sentence I put some thought into was "The future of this convention is concerning", which serves to set up what comes next.

I mentioned that this trilogy - and by extension, this game - is ultimately about misanthropy. This is manifested in the character's fairly inelegant suggestion to totally disband the convention -  the character is callous either to the possibility that others may take offence to this statement, or totally callous to it altogether.

The next presentation immediately starts immediately with a continuation the first presentation - a year ago in the game's universe. The lack of new material to discuss enforces the idea that the character, despite their arguably gauche attitude, is correct in what they are saying. They do not offer an apology, but instead passive-aggressively chastises the attendants for not following an instruction which he did not actually deliver.

A common trait of people living with Narcissistic Personality Disorder is to claim that they did say or do something which they did not, or vice versa. This is known as "gaslighting", and gaslighting is exactly what the character is doing here. Additionally, at no point does the character actually apologize, and in fact goes so far as to shift the blame by implying that their "intention" is something separate from themselves - but immediately claiming a much more amiable position of wanting to "inspire innovation".

The third and final presentation is fairly short. It consists of only a few sentences, in which the character does almost directly chastise the audience for not innovating, nor heeding his advice.

Though it's fairly insignificant, this is the place to mention it: In this paragraph, the character creates an excuse to scold the audience twice, by rephrasing their first sentence despite its almost identical meaning.

The character claims that they will not be attending any more conventions. The term "convention" in itself implies that it is normal or "conventional"heh to attend them. The character ends the first game with a perfect lead-in to the themes of the second game.

The penultimate thing to notice is the final sentence of each presentation - "Thank you for your time". It was intended to be perfectly carbon-copied between presentations to imply that the character does not find it easy to abide by social norms/pleasantries, but manages by way of rote memorization.

Perhaps that was a bit of a stretch. A lot of what I put into this game was never intended to be picked up on or realized, because simply put - people don't (and shouldn't) put in enough time to try to scrape this much meaning out of what is a fairly short body of text.

Either way, I hope you enjoyed reading this! If you have any alternate interpretations, even if they starkly contrast with what I've written here, I'd be interested to hear them.

If you have done, thank you for reading! Stay tuned for a similar post on "Banality" in a week or so!

Saturday, 11 February 2017

It's release day for Banality!

The second game in the trilogy, Banality is the sequel to my prior game, Homogeny.

Banality is slightly more of a "walking simulator" than Homogeny, but it shares the same art style and central themes, as will my next project, named Monotony.

Banality is a very short game, with a grand total of 3 "levels".

Download it below, but more importantly, stay tuned for Monotony, the final instalment.

Wednesday, 8 February 2017


It's been a while(approximately 5 days) since my last one of these!

I've been continuing to work on Banality. It's going to be very slightly longer than Homogeny, and I expect the third in the series is going to be longer still.

Here's a screenshot!

To give the fine readers of my blog a small hint, this is not a screen that you want to see.

Either way, I'm slowly getting better at using GIMP to create assets, as shown by the sick-as-hell little pulley thing in the screenshot above.

I'm more happy with the way that this game is going than I was with Homogeny. Homogeny was fine for what it was, though the UI could have done with some improvement, and I think it could have been a little bit more visually interesting.

While Banality isn't much more visually interesting, it is somewhat more polished, and does not suffer from the same UI issue as its predecessor. This is because there isn't actually any UI. Sorry.

Regardless, stay tuned for more soon. The whole game should be done in about a week. It is not a large project.

In any case, if you have done, thanks for reading!

P.S. I'm in the process of writing the explanation post for Homogeny's existence. I'm not sure how long it will take me, I need to make sure this expresses why I made it as accurately as possible.

Thursday, 2 February 2017

The sequel to "Homogeny"

Some of you may be aware that I recently released the game "Homogeny", which a few people seemed to enjoy. Seeing as I have an inability to not constantly have a project running, I've got a sequel in progress, named "Banality".

Unsurprisingly, this is in the same vein and art style as its predecessor. Devoid of particularly interesting mechanics, but saturated in analytical value and artistic expression.


I was going to continue this post with an explanation of Homogeny's themes, maybe detailing some of my influences, maybe even an early screenshot of Banality.

I'll leave that for another day.

This post is now about my view on artistic expression in video games.

"Artistic Expression" in Video Games

Followers of my work might have realized by now that I am one of the strongest subscribers to the idea that video games are art, perhaps to a fault. 

I say "to a fault" because the games I have produced so far have been primarily walking simulators - not very marketable to most. Of course, games like Proteus or even Dear Esther have been successful, and to varying degrees have earned their successes. 

The games I have and will continue to create are saturated in cryptic interpretations and messages, some more obscure than others, as anyone who has played Homogeny or Yet Another Puzzle Game can attest to.

The question most worthy of debate, "How much of this avant-garde bullshit artistic saturation is too much?"

First, let's explore the term "artistic saturation" and what I mean by this. I am referring specifically to the kind of avant-garde bullshit cryptic messages and implications that are placed in certain video games.

A fairly popular example is that of Bloodborne, which is highly inspired by H.P Lovecraft's work, and unsurprisingly shares the theme of demonization of humanity. 

In Bloodborne, this is conveyed by the ways the beasthood curse is explored -- exact examples of this are left as an exercise to the reader, in part because I don't want to spend half of this post talking about Bloodborne and in part because I believe the game is best interpreted by the individual on a very personal basis.

The most interesting part of the question are the words "too much".

What exactly defines "too much" artistic saturation? Is it when the mechanics of the game are compromised for the art's sake?

Surely, the reverse situation is just as unacceptable - this leads us into a terrible paradox, where neither can coexist. 

Maybe it's not about compromise of other components of the game. Maybe it's instead about its accessibility to the players?

This comes down to the game's purpose. If the game is designed to be mass-marketable and should be accessible to its players, then this becomes a consideration. However, if the game is made by a small hobby indie team, it has no obligation to be mass-marketable, assuming they are not financially dependant on it. 

Ultimately, it seems that there is no such thing as "too much". What a pleasant result, given that the way I develop games is nearly Souls-like in the way it tells a story or narrative while rarely directly divulging information. It requires analytical thought and some imagination to create a story that can be truly enjoyed.

I suppose that what I'm trying to say is quite simply that I'm developing the Dark Souls of walking simulators.
^this is sarcastic

In any case, if you have done, thanks for reading. Stay tuned for more avant-garde bullshit interesting content.