Friday, 10 November 2017

I'm back!

That's right, after like a month and a half of not doing anything game or YouTube related I've decided that I can come back now and not have a mental breakdown.

I've still got a lot of schoolwork coming up and that's not going away any time soon, but I've finally cleared my current backlog of work and I'm feeling a bit more confident now.

Anyway, yeah, I'm back. How do I do this YouTube thing again? Videos. Something about videos? I don't know. Let's get a few things clear because I did some stuff over the past month that I want to advertise in a mainline video, so here we go.

First off, I made a Discord server for Mass O' Kyzt, that game that apparently I'm working on. If you want to join it you can, I made it primarily because it sounds fun. Don't go there expecting any serious events, formal announcements or particularly well-enforced rules.

I will however be posting a checklist of things I do with regard to my game. You'll get a (potentially boring) list of small changes constantly being drip-fed to you through the #dev-diary channel. I'll post these just as I do them(or plan to do them) and just sift back through them to make sure I cover everything in my Devlog videos.

This means that anyone on my Discord channel will be kept slightly ahead of the curve, able to see what's going on in my game before I tidy it up into a nice clean format. Also, if this proves to be too annoying for you, there is a mute channel option if you right click on it.

So yeah, all around a fun time. I said there wouldn't be any serious events but hey- maybe I'll organize something if there's enough interest in it. Who knows, currently there's like nobody in the server so I'd appreciate it filling up a bit before I propose something like that.

There's a never-expiring Discord invite link in the description of this video, and it's also linked in my channel header. Both of these will grant you access to the esteemed Mass O' Kyzt Discord Server.

Anyway, let's move onto the other thing.

I made a small arcade-y game called "This Game Is Not An RPG"! I only spent about a week of on-and-off working on it, but it's been received fairly well and I'm personally quite proud of it. From a self-analysis point of view, I think it's quite polished compared to my previous work and it holds up with a simple and intuitive premise- "hit the squares".

It's got a nice scoreboard integrated into it, and as usual almost everyone beat my high score of 144 already. Again, the link to this is in the description, I hope you enjoy it. Oh yeah, there's an easter egg somewhere in this game. I won't tell you where but someone found it within like 5 minutes of the game being published so maybe it's easier to find than I thought.

Anyway, thanks for watching and stay tuned for more videos now... that's right, I have to make more of these. Exciting.

Thursday, 28 September 2017

Preparing for the DreamHack Jam

Since all I do is procrastinate and then do game jams I've decided that I would participate in the DreamHack Jam.

For those of you who don't know, DreamHack is an e-sports event where a bunch of amateur and professional gamers alike go to play some video games. It's somewhere in America and consequently there's no way in hell I could ever actually attend it, but I can still participate in the game jam!

GameJolt (the indie game website, I'm sure you know the one) are hosting a game jam specifically for DreamHack. I've been unproductive lately, so this is a great opportunity for me to stop being so lazy and actually get something done. This video should go out on the evening before the jam actually starts, at 5AM GMT on Friday.

So how am I going to prepare this time?

Well, I'm going to make sure I sleep for an appropriate amount of time, I'm going to make sure I eat healthy enough so I don't feel like I'm dead the whole time, etc. The biggest change I'll make from Ludum Dare 39 is that I'll spend a lot more time on the planning phase. In Ludum Dare 39, I spent most of my time actually making something without being sure what it was that I was making.

The fact I was time constrained had gone to my head and something that didn't directly result in an actual game in my hands was for some reason registering as superfluous. This time I'll have to plan a lot more carefully. Besides, I'll have more time. The DreamHack Jam lasts for 72 hours or 3 days, whereas the Ludum Dare Compo only lasts for 48.

Additionally, in the past two Ludum Dares my time has been divided into planning, programming and creating most of the art all on Saturday and then getting burned out on Sunday and just barely managing to create UI and sound.

Hopefully this Jam will make me manage my time a lot better, since as described just prior- my time management leaves a lot to be desired. I'll have 3 days so I definitely can't do what I just described. I'm not going to go with any rigid schedule, but I'll hopefully have a very solid idea of what my game will be before too late on Friday, the first day of the Jam.

This Jam almost fits perfectly with my school schedule, since it runs through the 3 days on which I don't have any lessons- Friday, Saturday and Sunday. Only problem is that I have a lot of schoolwork that I'm forgoing in order to do this, but hey, I'll get to that eventually.

The DreamHack Jam is a great way for me to redeem myself after my particularly underwhelming Ludum Dare 39 submission. Also, it'll be a nice break from my main project. As much as I enjoy the game, the universe and working on it- it can be a pain. Even as I write this I'm absolutely exhausted from schoolwork alone, having done nothing productive to my game in days.

Again, this might not have been the most well written, well presented or well delivered script in the world but I hope you enjoyed. Thanks for watching and stay tuned for more videos about the DreamHack Jam, but as usual probably not since I don't know if there will be another one. Even then, who knows whether I'd want to take part in it, let alone make an entire video on it. These are some verbose closing lines, aren't they?

Friday, 22 September 2017


Almost a year ago, I wrote a text post on my website titled "Creativity". While it was one of my more interesting text posts from the time period, it doesn't carry much in the 200 words I spent complaining about not being creative enough.

However, there are some things I expressed in that post which no longer reflect what I believe today, and some more things which I feel I need to expand upon. Consider this video (or for those of you who still follow my text posts, one of those) a re-make of that old post from December, 2016.

Creativity is something which I don't believe is possible to pin down as a single, definite attribute. A so-called "creative person" is not necessarily a person who is inherently creative, but rather someone who believes themselves to be creative. Maybe you'd disagree with this quasi-post-modernist view of creativeness, but just bear with me.

Creativity is ultimately a function of familiarity with your chosen medium and how much you're willing to come up with a hundred awful ideas before you get anything good.

In order to be really creative, you have to know the exact limitations and boundaries of your tools. Your tools might be the Godot Engine, FL Studio, Sony Vegas or some bizarre combination of all 3. This means you'll have to spent a lot of hours learning how to use them. It's taken me six hundred hours on Godot and I'm still learning new things about the engine even now as I work on Mass O' Kyzt.

Once you know how to use them, it's a lot easier to allow your mind to wander into territories that you might otherwise never have thought to even approach. Certain media such as game development are particularly obtuse in that regard, which bit do you work on first? The bare-bones mechanics? The art direction? The codebase? The story?

After creating a game or two, it gets easier to see exactly what you can do and where you can go from each starting point. If you want to create a game where mechanics take the lead, you can write out the mechanics first. It gets easier to recognize what kind of idea each idea you have is- "something involving glowing blue mushrooms" is an idea where the art direction and style takes the lead. "A game wherein you upgrade your enemies" is an idea where the mechanics takes the lead.

Imagination and creative thought does need to be trained, but I don't believe it's in the same way as a muscle needs to be exercised. I think that a lot of people will get better imaginations the more they try, but not because their imagination somehow "became bigger", but rather because they're more comfortable with the process as a whole.

Here's an exercise in imagination: pick a random word(preferably a noun, verb or adjective, don't be a dork and pick a preposition) and think about literally the next thing that comes into your head. Even if it's not related whatsoever to your initial word or its a random fleeting thought, grab it and do the same again. If I'm making any sense, you'll be led along a random path of neural connections and associations and maybe come up with some ideas.

Don't get frustrated if you don't come up with anything, that's part of creativity. Coming up with like a billion bad ideas is almost required in order to come up with one or two good ideas.

Spending your time pursuing a bad idea is usually not wasted time, since you're practising your "making-the-thing" skills so that you can become more confident coming up with a better thing to make.

This is getting really quite rambly, which is impressive because it started off rambly but I'm going to cut it here. I have a cold, so my script-writing is pretty rubbish. Anyway, thanks for watching and stay tuned for more illness-induced rambling about something which a lot of people either realize already or don't care about.

Monday, 18 September 2017

The State of Steam

Anyone watching my videos is presumably already familiar enough with the current state and reputation of Steam. Steam is often described as a dumping ground with little-to-no curation or care as to what gets shoved to the storefront.

This comes as no surprise since let's face it- that's exactly what Steam is and has been for the past few years.

For context to what I'm about to say, I'll give a brief background into Steam.

Steam launched in 2003, and it was pretty humble. Initially only sporting Valve's own titles, the platform carried on for a while and gradually accrued more and more games. The submission process was manual and personal. A developer would have to speak to a real representative of a real company in order to get their game considered for release on Steam.

Getting something on Steam was a serious mark of prestige, where it would have been sold alongside Valve's own titles as well as the best the industry had to offer.

However, in 2012 Steam made a radical change to how their store worked. They introduced Greenlight. A year later, Steam's prestigious status on the industry had all but disappeared and getting a game on Steam was practically commonplace for any realistically competitive product.

The reason that I explain all this is because Steam has greatly changed as a service. The Steam that was a prestigious place for reliably high-quality games is gone, and little trace of it remains today. The Steam that has taken its place is what some people would call a dumpster fire full of snakes and vomit.

So why on earth did they do that? They ruined their own service and reputation, right?

In February 2013 - or about 7 months after Greenlight launched - Gabe Newell expressed his desire to make Steam a "networking API" rather than a "curated process". He spoke of his boredom with the Steam store, calling it a "middle-ground marketing thing".

Clearly, Gabe Newell's vision for Steam has evolved since 2003. Steam appears to be going in the direction of a kind of open marketplace for games. A massively more popular and consumer-friendly version of, if you like.

Steam is moving away from being its own ecosystem for games to be sold, bought, discussed and critiqued. It has become a centralized platform for the distribution and purchase of games and little more. Marketing today is primarily done outside of Steam, whereas in 2010 having your game on Steam was marketing in itself.

Communities are primarily built on external forums, chatrooms, or in my case a YouTube channel.

Steam no longer wants to be a one-stop shop for all things developer-related. Steam wants to be a smaller part in a larger and more varied toolkit.

Of course, the motivation for this change is very likely because they want money. They're definitely making a lot more money as a distribution middle-man than they would have been as a prestigious curator.

However, this makes being an indie developer a lot harder in the process. The advent of the asset flipper and associated low effort or low quality games on Steam makes getting noticed a lot harder than it was in previous years.

Independent developers are in a tricky spot right now. We have Steam and Google Play which are both great for distribution, but we're at a loss for a curated platform. Getting a game noticed is hard and only getting harder, both due to market saturation and large players in the field taking a back seat.

Currently, sites such as GOG need to be successful in order for indies to be successful. GOG is currently what Steam was 7 years ago, minus a whole lot of DRM.

The Humble Store is also making good progress to shutting out the gutter-trash masquerading as video games that pollutes the Steam store.

In short, yeah, Steam isn't what it was and has ceased to make things easy for indie developers. Now, they're something entirely different but useful in its own right, for the limited scope of problem they're intent on solving. It's been a long, gruelling gauntlet of a changeover but Valve are closer than ever to making it a reality with Steam Direct.

Thanks for watching, and stay tuned for more videos, either scripted, unscripted, whatever, I don't know. I even scripted this last little bit at the end, that's how scripted this video is. God, script-writing is a pain.

Sunday, 10 September 2017

The (Short) Story of One Almond Games

Some of you might recently be aware that I am in the process of dissolving One Almond Games, a limited company that I created for the purposes of distributing my games.

This video will explain why.

So about a month ago, I decided to get the Steam Direct paperwork done early so I could concentrate on making my game.

I paid the fee, went through the "Onboarding" process when I came to a fork in the path. I could either be a Limited Liability Company(known as an LTD or in the US, an LLC) or I could be a Sole Tradership.

I'll briefly explain the differences between them.

A sole tradership is easier to set up, slightly less formal, but it's much less safe in that if I get sued or go into debt then the UK government will come for my  kneecaps. That sucks, since I need my kneecaps to walk around and such so I looked into the advantages of an LTD.

A Limited Company is safer in that it's its own legal entity. My kneecaps are safe, but the corporation would be forced to give up its non-corporeal kneecaps should I incur any debt on the company's behalf. However, a Limited Company is much harder to set up and keep records on. Jeez, I wish I knew how much harder it was because if I did, I wouldn't be making this video.

For whatever reason, I thought that it wouldn't be too much harder to create a Limited Company so I chose that one. Besides, I'd probably want to create a company like that in the future, so why delay the inevitable?

I fucked around a while and eventually came up with the name "One Almond Games", a reference to popular webshow Jake and Amir. Shortly afterwards, I decided to register the company "One Almond Games".

After a short time spent researching the next step, the step after that, and the next 43 steps, I realized that I'd gotten myself into perhaps a bit more than I realized. There are a lot of caveats and hidden costs to creating a company, you know. A PSC register, shareholding, a business bank account, a Universal Tax Reference, and more things of varying degrees of complexity. Due to the bizarre way that the website is set up, almost none of these things were made clear enough from the beginning.

After enough stumbling, I got over most of this stuff and I was beginning to believe I was seeing the light at the end of the tunnel. That was, of course, until I got to registering a business bank account. In the United Kingdom, we're required by law to keep a separate and special type of bank account for a Limited Company. This is known as a business bank account. Being under 18, I was outright denied by many companies save for Barclay's. Barclay's had a route for under-18s to register a business bank account, but they needed to see me in person to do so. I couldn't do it online.

Well, that should be fine, right?

Not quite, and I'll explain why.

I phoned up, booked an appointment with them, did everything I needed to do. The day before the appointment, I received a phone call from Barclay's asking about my identification documents.

No problem, I'd already applied for and received a provisional driver's license. The easiest form of photo ID since it's cheap and doesn't involve months of lessons to acquire. I just have to fill out a form, pay a fee and get a licence.

However, this form of ID was - for whatever bizarre reason - not accepted by the bank. The person on the other end of the phone was very sympathetic and I don't anything against her, but come on- really? A full driver's licence is fine, but a provisional licence isn't. The only difference between those two documents is how much time I put into it.

So, being blocked from creating a business bank account, I reevaluated the whole situation. Yes, I could continue with the Limited Company, pay more tax, have infinitely more hassle and with little in the way of reward, or I could shut down this company and just go back to a sole tradership.

Fortunately, I'd already registered for self-assessment with HMRC(the UK equivalent of the IRS in the US), so I don't believe I need to do anything else to be registered as a sole trader. Even then, I don't even make any taxable income for a while.

When combined with the already high workload of school, the actual game in question, a YouTube channel, and somehow fitting family and leisure time into all of that, I realized that a Limited Company is neither feasible for me at the moment, nor is it even worth it if it was.

I mean hey, at least I've got some experience with the process as a whole. Should I come back to the idea of a Limited Company in future, it'll be easier and more familiar. I suppose that's worthwhile, if nothing else.

And that, ladies and gentleman, was the story of One Almond Games Ltd.

Either way, thanks for watching and stay tuned for more videos, eventually. Workload is decreasing a little bit since no more Limited Company, but also increasing a lot since school now.

For those of you who don't know how the UK school system works, I've been working through a qualification known as A-levels. Last year, I was dealing with the AS course and this year I'm dealing with the A2 course. The A2 course is significantly more difficult and heavyweight, so I'm not looking forward to this. Wish me luck!

Tuesday, 22 August 2017

Even more design changes

I'm aware this isn't one of my standard devlog videos, but it's easier if I just explain this now since it's still in progress, I haven't uploaded in 5 days and I need to make a video on something.

A few days ago, I came to the realization that for some reason, the game wasn't fun. It had what I consider to be a somewhat cool idea, but beyond that it was pretty vacuous.

After a bit of experimentation playing other games, I realized that it's because there is no actual gratification from the player defeating an enemy, and they're spending a lot of time doing that per wave.

So, I decided I'd have to create a smaller scale gameplay loop within the larger  "shoot enemies->destroy core->upgrade->repeat" loop. I'll cut out the other intermediary ideas I had because they're not relevant and frankly not very good.

The player must now collect "special energy"(name pending) from defeated enemies. This energy powers the alternate fire for the gun, which shoots lasers which can damage the core directly through the shield.

There's no longer an "enemies defeated" prerequisite for the core to be exposed. The reason this existed in the first place was so that the player didn't run to the end of the level and immediately end it before the game could actually play out, but finally there's now something to actually play.

This is the best iteration of the design yet, but then again- so was the last iteration, and then the one before that. At least it's an upward trend.

Even so, it's getting increasingly difficult to actually determine whether my game's fun. It's got to the point where changes are fairly subtle and it really doesn't stimulate me after the 500th playthrough. It'll probably turn out fine in the end but Jesus Christ- it's a pain.

I won't even go into the hell that is filling out paperwork and tax info to start a limited company in the UK. In fact, that's the main reason I haven't put out a video in the past 5 days- I've been struggling with that.

Either way, thanks for watching and stay tuned for devlog videos maybe, or another video about a different topic. Who knows? 

Sunday, 13 August 2017

The case for a demo

I recently revealed to the world that yes, there is going to be a demo for Mass O' Kyzt.

I'll give a brief explanation of exactly what this will involve. The demo will, as a demo should, be free of charge. Its feature set will be severely limited, only allowing the player to play up to three consecutive waves and only unlocking about half of the upgrades in the final game. In addition, the player will not actually be given any choice over what upgrade they unlock.

Wednesday, 9 August 2017

Devlog #11 - Gameplay changes, Augments and More

I let this place go to hell, didn't I?

It's been quite the adventure on this page. However, for the purposes of having a site I've decided to revitalize it. This will hopefully be a general all-purpose landing page for those unfamiliar with my work, or if nothing else something for me to link back to which isn't my Youtube channel. I'll have to do some light restructuring, but that's not a huge deal.

Also, you might not have noticed but it's on a real domain now:! Exciting!

Friday, 4 August 2017

Making something "for everyone"

When making a video game, you're not making something that's going to be fun for everyone. In fact, I'm confident in saying that no medium has ever produced something that literally everyone likes.

Thursday, 20 July 2017

Maintaining Productivity

Creating a game can take anywhere from a few weeks to several years. Needless to say, it's a marathon and not a sprint.

Saturday, 1 July 2017

Mass O' Kyzt - Pondering Modes of Revenue

Over the past few days, I've been thinking (perhaps preemptively) about the mode by which I'll distribute Mass O' Kyzt. Of course, I'd love to make the game free with no caveats, but at some point I'll have to start pulling an income from game development since it's hopefully what I'll be doing for a living one day.

Sunday, 25 June 2017

Mass O' Kyzt - Lore #2

Apparently this is a series I'm doing and I have to do something to procrastinate for Devlog #6, so let's get on with the lore!

In the "Lore Overview" video I made, I already discussed how the Kyzt are all connected via a hivemind. However, I failed to mention the fact that it is indeed centralized, with the controller being carefully protected by each of the small creatures it manages.

The controller of the Kyzt has been dubbed the "Brain" by previous human or allied expeditions to planet Ky. Successful communication has been briefly established with the brain on occasion, though current psychic translation technologies are primitive at best. Psychic translators can rarely hold a sustained connection for more than a few seconds without breaking either the device itself or the mind of the participant.
Despite the fact that the Kyzt themselves will expend exorbitant amounts of energy to prevent any perceived combatant from getting near the Brain, the Brain itself will prioritize non-violent communication. It will often attempt several psychic frequencies before becoming frustrated and forcing itself into the mind of the approaching combatant, usually killing them in the process.

However, even after the individual has died, the Brain can still probe for stored memories and any thoughts conceived in the last 5 minutes. Once the relevant information has been scanned and interpreted, the body is destroyed and stored beneath the Brain to be used at a later date as an energy reserve.

Like the creatures they control, the Brains can also change their physical form. However, they tend to be less flexible in doing so, often retaining the shape of a large blob, sometimes with external appendages.

On planet Ky, there are multiple Brains controlling multiple sects of the Kyzt. Generally speaking, they all possess the same or similar amounts of power and expendable energy stores.

These sects have had disagreements - either regarding the trade and allocation of domestic resources or one of them just got confused and started hitting the other - but these have never escalated to a full-scale war. Were it to ever escalate that far, it could be catastrophic for the planet as a whole due to their respective power.

Either way, stay tuned for Devlog #6 at some point in the future, hopefully within a few days!

How to play video games

I'm back, baby! It's no longer a million degrees Celsius so I can finally return to making videos and working on Mass O' Kyzt. I expect that Devlog #6 will be somewhat delayed since I've effectively dropped 3 days doing nothing, but hey- you're getting this. Enjoy it.

To put it simply, your time is valuable. You should always be minimizing the amount of time you're wasting. If you're like me, you might want to try dividing your time into either creating content or consuming content. If you're doing neither of those two, you're usually wasting your time.

Thursday, 15 June 2017

Mass O' Kyzt - Lore Overview

In the far future, humanity has inhabited the furthest reaches of space. Finally, mankind lives alongside alien species on distant planets.

Unfortunately, this man is stranded on an unfamiliar planet and the native species have no plans to live alongside him. He finds himself on the planet PSR J1841-0500 b, colloquially known as Ky. The inhabitants, the Kyzt, are small beings with powerful psychic and shape-shifting abilities. They are able to determine their victim's weaknesses with razor-sharp precision, and due to their hivemind-like behaviour they have no qualms about sacrificing their own in the process.

So, what's the plan?

Well, the first step is to defend him from the oncoming Kyzt.The second step is to sound a distress call and hope for the best. Good luck!

So that's the current lore-oriented pitch that I'm working with. I'm still in the process of adjusting it a little to make it flow more comfortably, and pending design changes I might end up totally re-writing it.

In the meantime, let's explain the Kyzt.

The Kyzt are a psychic hivemind of small, cuddly creatures. Think the Adipose from Doctor Who mixed with the Ood. Through their collective psychic power, they can probe the mind of their target and figure out what its biggest weakness is. Due to the malleable nature of their bodies, the Kyzt are able to adapt their physical form to their needs.

Also, they don't particularly enjoy getting invaded by creatures without psychic capabilities. The Kyzt take refusal to enter their psychic network as a haughty show of dominance, regardless of whether you're actually able to do so. Think of it as jumping into a wolf den and simultaneously making strong eye contact with every other wolf, or chasing down a gorilla in the jungle.

To fend you off of their planet, each of these aliens will summon a small burst of psychic energy to shock you. However, if you don't respond to this they may get stronger. Perhaps this small burst of psychic energy will become a larger burst of psychic energy, or perhaps they'll strengthen their legs to run faster.

They might even begin to strategize their approach- turning some of them into larger, slower but tougher creatures while others may be able to fire on you from a distance.

Of course, you're not defenseless amidst the Kyzt. You are a space traveller. Obviously, you have a lazer gun. While the Kyzt don't get massively harmed by lazers due to their psychic shielding abilities, it will cause them to absorb the energy through the eye-like structure on their body and be forced to release it in the form of a short-range teleport. Don't worry, they'll be back soon enough.

Generally, members of the Kyzt don't die. They all share the same consciousness, so the death of any single body is felt the same as losing a finger would feel to you or me. It hurts, but you still have 9 more fingers. Plus, pending the procurement of a very particular resource they are able to regenerate their fallen comrades. Unfortunately, this very same resource is the only known material which can fully destroy the Kyzt if wielded properly, dispersing their psychic energy into the void and leaving their corporeal forms as lifeless husks.

Everything which I just typed out is open to a lot of change and adaptation as time goes on, but this is the first revision. Maybe I'll do more of these posts if they're well received or if I think of more ideas for the Kyzt, their planet, or other associated species.

Tuesday, 6 June 2017

Let's try this again - Godot vs Unity

About 3 months ago, I made a video titled "Godot Is The Best Engine - Godot vs Unity". It's currently my most popular video, sitting at over 8k views. Unfortunately, this is also the video which I'm the least proud of. In fact, I'm decidedly unhappy with this video, even going so far as to re-make it. This re-make is what you're reading now.

Sunday, 4 June 2017

Devlog #3 - Combat, Knockback, Title

Welcome to the third update post on my project, now named "Mass O' Kyzt". You can thank the Youtube commenter SmallsMalone, who gave me a very similar idea for the title.

Wednesday, 31 May 2017

How to make games as well as run a Youtube channel

As some of you are aware, I've decided to make a Youtube channel. Though I was going to make it purely promotional material for my games, over time I've grown to appreciate it as its own productive outlet.

Tuesday, 30 May 2017

Who the hell is Missy?

This is a Doctor Who post. You don't have to read it if you don't want to, but I encourage it regardless.

Monday, 29 May 2017

Devlog #2 - Bullets, Collision and Upgrades

Before anything else, I have a new microphone so those of you watching the video format of this post are going to have a great listening experience.

Since the last update video, I've made a few changes. Enemies no longer collide with each other, for a start. I genuinely don't know why I ever even considered allowing them to collide, because it doesn't really make any sense at all. In addition, it bogged down the pathfinding algorithm with unnecessary checks and requirements.

Sunday, 28 May 2017

All creative process is valuable

Since I am quite literally the most motivational guy despite having no real achievements of my own, I'm here to talk to you about the merits of every creative venture you try.

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.