(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.

http://gamejolt.com/games/super-displacement/244666

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.

Solasi?!

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.

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.

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.