Minecraft and the BBC News Room

Well, after taking about 5 days to do nothing over Christmas, I've got back into things by creating a pretty nice Minecraft-themed background/room, as well as making some finishing touches to the news room. I'm actually pretty proud of what I've done with the Minecraft-themed one so far, though I hesitate to call it "complete". It's pictured below, in case you're curious.

Right now, I'm working on a kind of remote fallout bunker, but that's way too unfinished for public consumption, so you're going to have to check in next time for that one!

There is some rhyme and reason as to why I've decided to recreate this seemingly arbitrary set of rooms, I promise.

As I've mentioned in a previous blog post, this game is based off of a podcast that myself and a friend (slowly) produce. In the first episode(or "track"), we discuss things such as Minecraft and Neath Port Talbot's local news, among other things. This game should hopefully reflect the surrealist adventure that is the Spiderman in the Rhineland podcast.

Either way, this is yet another snapshot into what I've been doing. If you have any feedback, don't hesitate to let me know.

And if you have done, thanks for reading!

Devblogging

I'm back from my break over Christmas, baby! Woo!

Since I started this blog, I've been considerably more productive. I've noticed that this is apparently a trend with fairly large number of other developers, who also find blogging to be a beneficial outlet, so I've decided I'm going to write a blog post about blog posting, in the same vein as what I briefly touched on in my previous post on how to prevent burnout.

First and foremost, I find that seeing a number ticking by helps a lot. Game development isn't always the most instantly gratifying process, as it requires you to actually complete a project before you get anything at all. A development blog helps that by giving you a number that you can raise. People want to see or read about things you've done? Put it on your blog! Instant gratification -> acquired.

Secondly, devblogging can gauge public interest to some degree. If you aren't sure how marketable or interesting a mechanic is, make a blog post with some title like "New mechanic!" and watch as people come in to read what you've come up with and maybe just write a comment back. Additionally, it practices your ability to create a short "blurb" to publicize your game with. It's often cited that the best game concepts are those that can be easily or succinctly summarized, and I believe that's true in a lot of cases.

Thirdly, it can be similar to "rubber ducky debugging". This is a fairly well-known practice where developers would place a literal rubber ducky on their desk and verbally explain the bug. I think that making a blog post about a tentative mechanic can help the developer to see clear problems in it that they might not have realized otherwise.

Also, running a development blog does generate some publicity for your project. When it's released and done, you get to easily reach all the repeat viewers of your blog with a single post, as well as gain some new ones if you hint that your project is almost done.

Of course, the real reason to make and maintain a development blog is to gain enough power and enough of a following to enforce social and political influence on an international scale by use of the Internet. I hope that this was obvious from the start, if it wasn't.. sorry.

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

Preventing Burnout

This is a legitimately useful post that I'm making, rather than highly subjective musings. Enjoy!

I am very prone to what is called "burnout", a term referring to a developer getting tired or otherwise dissuaded from continuing to work on their project. This has been problematic, considering that it's caused me to kinda abandon two other projects in the past, so I've decided to share some tips that I've either come up with or seen somewhere else online.

One of the most useful things I've noticed is that it's important to pace yourself - even if you don't want to. This means that you shouldn't try to work more than 4-6 hours on your project per day. Of course, this is coming from the perspective of someone who has to go to school regularly, so perhaps 6-8 would be a more appropriate number for someone who otherwise has no other preoccupations.

The feeling of "I want to work on this project but I can't" in my own experience helps to keep the enjoyment of working on it fresh and lively in my own mind, which means I'm less likely to experience burnout.

Another thing that helps more than I would have expected is keeping an hour count. I use the Godot editor on Steam, which automatically records your hours spent "playing" any particular application and by now I have about 90 hours on record. This helps just for the sake of a number ticking up being somewhat satisfying. Maybe this won't work for you, but it's worth a go.

A pretty useful tip that I use a lot is that if I discover a bug or something that I really don't want to do, I schedule it for either tomorrow or the day after. The most important thing is that I do it then, procrastinating sets a bad precedent for the future. This can be difficult, but it's very useful. If you can suppress thoughts like "ugh I don't want to do this" or "grr this is going to be so much trouble" in lieu of thoughts like "I can make this bit blue" or "where can I add dithering", it helps a lot.

Something that helps quite a bit is making a post on your devblog - provided you have one. If you don't have one, make one and post it to /r/devblogs or something similar. There's another whole post to be made to talk about devblogs and how they're helpful, but just trust me, seeing the "All time views" number tick up slowly is tremendously satisfying.

This is something that I've seen is commonly suggested but somewhat underrated. If you're stuck on something, shut your eyes for a few moments and picture it in your mind in as much excruciating detail as you can. Besides the beneficial side effects of exercising your imagination, this helps you with design, as well as allowing you to recognize the potential of what your game could be if you do everything exactly right.

One last thing that is tremendously useful; if you're not feeling motivated, think of one very small thing that you can do to your game. Bonus points if its very menial or repetitive and doesn't require creative effort, because while interacting with your game in any way you might start being able to think of ways to tackle other problems, whether they're how to recreate something graphically or how to tackle a tricky bug.

Even if you plan on working for 5 minutes, you will often work for much longer once you start. Sometimes the hardest part of something is to start it, and then the rest becomes quite enjoyable.

Anyway, that concludes my list of (hopefully) helpful tips, and if you have done, thanks for reading!

Another two rooms done!

It only took about 2 weeks of work, but I can finally stop trying to recreate rooms from a certain video game involving bonfires, which is good because it's pretty damn difficult.

One of the rooms is this one:

It's admittedly not the best piece of pixel art ever created, but this took me literally 3 days. I'll come back to it at a later date because I'm certainly not satisfied with the end product, the rock in the bottom right is a bit.. strange and the borders are too lopsided for my liking.

Fortunately for me, I can put the amendments on the proverbial back-burner while I do something slightly more interesting. Also, at some point I need to fix a frustrating bug where a "fade out -> change scene -> fade in" will occasionally cause a strange flicker.

My best bet is to try and set up the mask which handles the fade in/fade out/visual snow/static effect as a singleton node. The only worry is that this would kind of reduce the amount of control that I have over the mask in each scene, seeing as it wouldn't be able to be keyframed in Godot's AnimationPlayer node.

That bit kind of runs contrary to my previous task of setting up the intensity and alpha channel to be uniforms explicitly so that they can be keyframed as necessary. Maybe a mixture of both is what I'm going to have to do, just initializing a singleton in the scene prior to the fade out, and deleting it after the fade in.


This is my favourite part of game development; the problem solving and thinking about a problem. Definitely not the creation of art assets, at any rate. At this point I'm almost glad I have a bug to fix...



And if you have done, thanks for reading.

Annoyed about Unity

Disclaimer: This post is what I call a "weighted opinion" post, where I can choose to subjectively value certain shortcomings of Unity over areas where it excels, because the areas where Unity excels do not align with my own skills and beliefs.

The Unity editor is one of the most popular visual editors in use in the indie game industry. I've even seen some (unconfirmed) reports that No Man's Sky uses the Unity engine.

Unfortunately, despite its somewhat misleading nomenclature, Unity is anything but unifying when it comes to multiple operating systems.

I've tried to use the Unity editor on Linux, but unfortunately it crashed every 3 minutes or if I right clicked on a drop down menu(I'm not even joking, this happened constantly). Not to mention the problems that Windows developers have when compiling for Unity, half the time it doesn't work despite the fact that it claims to have functionality for cross-compiling.

Also, Unity2D is awful, as someone who has tried, it's just awful. I spent about 3 hours one day and a couple more hours the next trying to get it to do really anything that I wanted it to do, and with minimal luck. Of course it didn't help that it crashed so often. Did I mention the crashing?

Godot is the natural successor to Unity. I've seen nothing that Unity can do that Godot can't. Unless you're doing something hyper-experimental which somehow can't be accomplished in Godot, there really is no reason to use Unity over Godot apart from the fact that Unity is the "industry standard".

It doesn't help that Unity is proprietary software (which I'm sure is why it's so awful on Linux) so modifying it is considerably harder than it could be. Godot is free software(MIT license), so modifying this isn't so bad(if you know how, at least).

Also, Unity is considerably heavier, has even sloppier built-in assets(ragdoll physics, UI presets, etc) and is just overall awful to work with. It has an ugly UI, too.

Unfortunately, Unity still dominates the indie market even still. So many people haven't bothered to learn Godot because they know Unity already, and all the employers know Unity. This results in it being kinda difficult to get employed using Godot because it has such a tiny market share.

Oh well, I suppose that the option of trying to become a one-man development team is also open. Wish me luck, it's only getting harder and harder to compete in such an overfilled market.