Advice in the Games Industry

A lot of you might recognize that I tend to make informative or almost "instructional" videos to express my opinions and help other people in the games industry accomplish whatever they want to accomplish, or at least give them something to think about.
I like to think that some of my videos (such as my recent video on game developing at home) could help someone else in my position. However, I realize that most people aren't in my position. My circumstances are very specific, and not particularly common. This means that it's difficult for my perspective to have a directly helpful effect on the viewer.

This doesn't just apply to me, this is something that's industry-wide. The nature of video games means that people from all kinds of backgrounds can make at least something. It only takes a mid-range computer to get started with graphics, sound, programming and anything else that you can think of. Though this is a very terrible generalization that I really shouldn't be making, this is different to film and music which both require certain equipment which can produce drastically different results based on what camera or amplifier you're using.

The Godot Engine will run on pretty much any computer built in the last 5 years. If you upgrade to a newer computer, the Godot Engine will produce the exact same results regardless of where you compile it. You could argue that different engines would be a more suitable analogy for physical equipment in film and music, but there are many free engines whereas I wish you luck trying to find a free guitar or effect pedal.

The point that I'm making is that I believe game development is innately more accessible to get started in than other similar creative fields. Because of this, my advice is of limited value. Rami Ismail, half of independent game studio Vlambeer, commonly talks about how the steps he took to become successful in 2011 only worked for him in 2011. Applying the same steps might lead to getting into a fight on a public bus or worse still, failing entirely.

Now a smart viewer of my YouTube channel would 1) subscribe and 2) go and watch pretty much any of Rami Ismail's talks, because they're all a lot better than this. If you're still here, I'll continue with the video.

I haven't gotten successful, and I may not ever be successful. I'm slowly creating a mid to low rate indie game in a moderately niche engine, and when it's released who knows how it'll do. I'm still trying to figure out how to get going in the independent games industry as it is, by all logical means I should have no right to tell you people how to get successful.

If you get successful and have something to say about how you did it, write a blog post or make a video about it. If you failed, still do those things. If you've not even gotten the chance to try yet but you still feel you have something to say, go ahead. Worst case scenario, no one reads it. Post it to reddit and chances are, at least I'll read it because I read or watch a lot of things on /r/devblogs.

Best case scenario, it gets shared, you get cited and your name gets a little bit more on the radar than it was before. Or better yet, you inspire someone else to start making their own games or you help someone crack a puzzle that they have been deliberating over for the past month. The best part about the Internet is that this stuff sticks around- every video you upload and blog post you make lingers for the children of the future to look at.

This might be daunting, but who cares? I've really gone off topic at this point. This is a strange, strange video that mixes the topic of the industry moving fast and something motivational, but hey- it's something and I think I've said something useful so I'm recording this and uploading it as soon as I'm done with the script, which I'm writing right now. Except I'm not writing it right now, I'm recording it right now, but I'm only reading that in the future, and even then by the time you're watching this I will have finished recording it and have uploaded it.

Thanks for watching, and stay tuned for more strange videos that meander around for a while then end in a meta joke. I'm sure you're used to the formula by now if you're a long-term viewer. Goodbye!

Mass O' Kyzt: What's left?

I've spent the past seven months or so working on this game and I feel that I'm nearing the finish line. It's a good feeling, since as much as I love working on it, I'll be glad to have something that I can present and say "Hey, I made this!"

So the point of this video is to discuss what I think is left to do at the present moment in time. As it has done countless times before I'm sure my final product will differ somewhat from my working specification, but I'm feeling confident that it won't change too much now.

So what is left to do? I've completed what I believe to be the core gameplay loop, so I think pretty much everything with regard to the actual gameplay is going to stay pretty consistent from now until release. At most, I'll make some balance tweaks and I still have to draw some UI elements which are looking a bit dodgy at the moment.

The big task is going to be drawing a bunch of unlockable items. Things like player skins, enemy skins, maps, and tilesets. I think this is most likely what's going to take up the bulk of the remaining time, since I need to create enough to give the player something to work towards.

I don't know how many "skins" I'll add, though I'll probably add at least two for the player and at least one for each enemy type. If I need to, I can always update the game with more content later on- as long as there's a solid baseline so that the game feels sufficiently complete, and so that the player can feel as though there's something that they want to play the game to get to.

I've currently got an icey environment which I'm pretty happy with, and I'm just about to experiment with some slippery "ice" tiles, though I don't know if I'll keep them. I'm planning a nice lava-filled environment, which I think will look nice and be a welcome contrast to the aforementioned icey environment.

I've also got some vague idea for a "bizarro" environment which I'm imagining would have some bright checkerboard textures, vibrant colours, etc- I'm aware that it's a bit silly but it's not necessarily lore-breaking. The Kyzt are able to 1. fuck with your perception of your environment and 2. build complex structures- it all makes sense. Trust me.

On the topic of complex structures, it was recently suggested to me that I could make a kind of technological "space-ship" design of environment. I'm thinking that it would take place inside a human ship that the Kyzt have invaded and are trying to take down from the inside.

That's quite a lot and it still doesn't even include the skins that I have to create, though I imagine those would be simpler on account of not being an entire screen's worth of data at a time. At the rate of about one environment per week, plus doing all the skins in one week, plus giving myself two weeks for final changes, accounting for the fact I can't estimate timelines to save my life and Steam's "final review"- the game should be ready for release by the end of January.

I'm gonna take this opportunity to say that despite the fact I'm talking about six weeks from now, that is a frighteningly close release date.

I've been working on Mass O' Kyzt for around 7 months now and I'm pretty ready for it to be done, but I really can't overstate how strange it is to actually imagine it being finished.

So here we are, I guess that's my schedule. If I can finish the lava-type map by next Sunday, I'll be right on schedule. Realistically who knows if I'll be able to do that but that's become my goal during the writing of this video.

Thanks for watching and stay tuned for more of the video equivalent of someone laying awake at night, thinking to themselves in their head about what they're gonna do tomorrow and how they're going to do it. Goodbye!

Game Development From Home

I do all of my game development from home, as I'm sure many people do, at least when starting out. This is because for one, I'm 17 so I legally couldn't move out if I wanted to and two, I don't have any money anyway, so yeah- whatever.

The point is that I've spent enough time trying to be productive in a fairly chaotic and uncontrolled environment to hopefully offer some helpful tips to anyone in the same or a similar position.

I think it's quite important to avoid thought-based traps. Things like "I'll work on my game when it's peaceful" or worse still, "I'll work on my game when these damned kids have grown up". For context, yeah, I'm the oldest of a lot of much younger siblings.

Both of these sentences are shifting responsibility away from your present self, which is unfortunately the most important version of your self to motivate. If your situation is anything like mine, it really isn't feasible to work on your game late at night. In my experience, working late at night is generally less productive and of a poorer quality than getting something done in the morning or mid-day.

After a full day of keeping up with household demands as well as school or work, I find that getting something done is a much more grueling task. I have two solutions to this. The first of such solutions is to push such thoughts out of my head entirely, or to realize that it's not going to be any easier to work on my game in the evening because I'll be tired by then. It balances out and I just have to actually get the work done.

The second solution which may not be possible depending on who you are or what your responsibilities are is to go to sleep at 9pm almost every night and wake up by 5:30am. This nets me 8 or so hours of sleep while still having a few hours in the morning to wake up and get into working on my game with minimal distractions.

I could probably fill another entire video with tips on how to get to sleep so early in a noisy household, but I'll keep it simple here since my YouTube channel is actually still about game development. Ear plugs are your friend, as are noise generators, as is making peace with the fact that people might wake you up while they probably don't mean to. Be cool, calm and let your mind wander a bit. Drink lots of non-caffeinated fluids. Last but not least, ease into a significantly earlier sleep schedule by going to sleep at say 10pm and waking up at 6:30am for a few nights, and then you can get into sleeping at 9pm and waking up at 5:30am. Of course, your times may vary.

Another general tip for game development from home is to avoid the tendency to go make a drink to buy time so you don't have to work for a few minutes longer. I'm quite guilty of this and as a result I drink like seven cups of tea a day. To avoid this, it helps to open up your game, poke around and see what you need to get done before getting up. In my experience, once I get up my mind has left the gamedev zone and is now thinking about whatever other miscellaneous rubbish wanders in instead.

The idea is that if you make a mental note of what you're about to do when you get back, you'll put your beverage of choice on your desk and be easily able to get back to work without being inclined to spent another moment to finish your tea while you figure out what to do.

Plus, it can provide an extra incentive to the thinking bit since your ability to go get a nice hot cup of something depends on your ability to figure out your next task.

Though I don't do this, some people set themselves rigid hours between which they will or won't work on their game. For instance, between 8am and 4pm, I'll close everything else on my computer and only allow myself to work on my game. You can experiment with whatever works for you in particular, such as a five-minute break every hour, a fifteen minute break every two hours, an hour as a "lunch break"- the point is that it can be helpful to not have a super liquid schedule. I would give myself a more rigid schedule, but that's difficult given the fact that I have to go to school and that sort of throws a spanner in the works for a few reasons.

Lastly, don't overwork yourself. This isn't to say be lazy and slack off because obviously that's not gonna help anyone but make sure to recognize from as reasonable a view as possible whether you need a break or not. The unfortunate truth is the the universe will not be kind to you if you take too much time off. I hate to be the "tough love" guy, but indie game development is really very hard and you need to recognize that your job is to make the best game you can in order to have a chance at staying afloat in the industry, let alone getting anywhere truly successful.

If you overwork yourself, I believe that you will almost always make a worse product. Spreading yourself too thin too fast usually means that you won't have enough butter on your toast and you ripped the bread in the process. In order to make a good product and to be at maximum efficiency, creativity and productivity you need to take some breaks. Be reasonable and allocate time to take a step back and have a potentially brutally honest look at what you're doing, where you're going and what you're going to do about it.

Thanks for watching, and stay tuned for more videos that are very tangentially about game development, but applicable to most fields of creative work where the creator is sufficiently independent. It's kind of like a cheat for YouTube. Brand as a gamedev channel and then go off and make some random stuff, all the while keeping your audience sufficiently fooled so as to not have everyone unsubscribe.

Ludum Dare 40: An Evaluation

I recently participated in the latest Ludum Dare event which took place just under a week ago. My submission was called "Bring Your Own Bullets", wherein the player has to play a small minigame to fire bullets which they collect from the surrounding arena. Let's get the self-promotion out of the way, if you haven't played this game already then I recommend you do so- it's legitimately one of the better games I've created.

So why am I recording this video? Well, I decided that I'd document some of my thought process during the planning and development of Bring Your Own Bullets.

At the start of the jam, I wrote out maybe 7 or 8 semi-developed ideas for what my submission could be. The idea that I chose was a game wherein you collect bullets around the arena, and each bullet you collect makes you weaker in some way.

I initially though I'd make the player deal less damage for every bullet they collect, though at some point I reasoned that the player should want to feel as powerful as reasonably possible so I decided I'd find a different way of making something worse, as per the theme.

Next, I tried out making the player have less health. However, I quickly realized that each match was taking forever to complete and rather than making the enemies deal more damage(which would effectively nullify the core gameplay hook in the first place), I decided to make the player die in a single hit and find a different way for them to get weaker with the more bullets they collect.

Finally, I decided I'd make the player slower. I didn't really expect to keep this one since I realized a problem before I even started- the player eventually got so slow that they physically could not dodge the enemy projectiles and they would lose immediately after getting to a certain threshold.

I decided that the player would only be slowed down based on the number of bullets that they currently hold, rather than the total number of bullets they collected. This helped a lot and created something bordering on interesting gameplay.

Somehow, I came up with the idea of a quick reflex-based minigame to make it a little bit more interesting for the player. I don't know exactly how it popped into my head, but I think I made some connection from the idea of a physical pool of bullets possessed by the player and a revolver being difficult to quickly reload.

I was pretty happy with this system, so I kept it. I promised myself that I wouldn't change the mechanics any more after that since I was approaching the upper boundary of how much I can program in a day and still remember how to breathe and blink. I spent the rest of the day coming up with ideas to juice up my game, or making it more satisfying and pleasant to play.

I added some very light screenshake, some particle effects and a nice pulsating background for good measure. Also, several things work off of the same hue value- I did something similar in Super Displacement, where the enemies' red hue was mixed with the current colour of the background grid. Nothing too complicated, but it helped everything feel a bit more unified by more than you'd expect.

As an aside, the sound effects were actually the easiest part of the whole experience. Godot 3.0 uses a new bus-based system for audio processing and once I figured out how to make raw wav files loop since I couldn't import them as proper samples, it was a breeze and really satisfying to use. Plus it comes with some nice stock effects like delay, reverb, etc. What's not to love?

Also, I named the soundtrack "doesn't this bell pepper taste morose?" which is legitimately one of my favourite titles just because it's such a silly premise for a vegetable to taste like a mood but that's just my weird sense of humour. I'll stop now before I get into the etymology of some of the song names from Super Displacement's soundtrack.

Thanks for watching and stay tuned for something a bit less Ludum Dare flavoured. I told you I wouldnt' make another Ludum Dare video and I guess I lied because here I am, making another Ludum Dare video.

Practice

The sad truth of game development and a lot of creative pursuits is that practically nobody is born good at what they do. It can take years for somebody to get good at something, let alone great, let alone significant in the field as a whole.

This can be discouraging, since in the worst cases it can be years and years of work before you see any kind of improvement. I have some experience with this, since two years ago I was truly terrible at pretty much anything related to drawing, including sprite work and especially animation. I wasn't good at it so up until I started making games, I never really tried that hard. I was good at coding, so why bother?

Ultimately, I got to a point where I had to make placeholder graphics for my games and so, I got into pixel art. Two years later, I'm approaching being competent in pixel art- it's still nothing to write home about, but I've clearly improved from only being able to poorly re-colour Terraria sprites.

Similarly, my first game (excluding the one I made when I was like 8 years old) was released August 10th, 2016. It was called "Don't Be Still" and the idea was just that you couldn't stay still too long or you'd lose, and you'd maneuver some levels populated with enemies that I think would shoot at you. It was pretty bad, buggy, unfinished, unpolished, pointless and honestly pretty horrible to play.

Looking back on it, it's incredible that I made that game only about a year ago. However, with what I believe to be fairly high amounts of practice and dedication to becoming good at making video games, I've improved by several orders of magnitude.

The point of this video is probably a bit hazy at this point. I'm just rambling on about my experiences with improving in artistic fields and I think it's all getting a bit disjointed, so I'll just assert something now.

I believe that practice is pretty much the only way you can get better at game development. Reading old design documents from Nintendo and watching Extra Credits videos will get you to some degree of knowledge, but knowledge isn't skill. Knowledge is knowing what to do whereas skill is being able to actually do it.

It can be difficult for someone to step back and view their own creation as something that they're not working on. By creating something, you have a preconception of what your creation should be in your mind. This preconception can muddy your actual perception of what your game is really like. Other people won't have the initial spark that inspired your game, nor will they have knowledge of the thousands of builds that you tested just prior. Your audience will only ever know what is in front of them and I think it's impossible to fully view your game from an outside perspective.

This is relevant because knowledge allows you to think of something that should be fun on an intellectual level. Something that should extract the correct amount of dopamine from a potential player at all the right times and something that on paper would be a best-selling game.

Skill is a persons ability to execute on this knowledge and actually be able to deal with it. Taking my recent Ludum Dare submission as an example, I know only from experience how much screen-shake is fun and how much makes the player feel shaken and nauseous. The minimalistic "growing circle" effect when a bullet hits the boundary was one of the first things I thought of when planning out my game because I had experimented with that effect in a previous game.

It didn't fit in that game, but I tried it and from having tried it I have a better understanding of under what circumstances that specific effect would be nice to have.

So by having practiced game development, I became a more able and competent game developer.

You just wasted 3 or so minutes of your life watching someone tell you that practice makes perfect. Well done.

Thanks for watching and stay tuned for videos like "water is wet", "the sky is blue" and "games are objectively bad in every sense of the word"- goodbye!

Regarding the Demo for Mass O' Kyzt

As with every video I have to mention my upload schedule- this is the first video in a while that's actually been on time. If you're watching this, I appreciate your patience with me straight-up not doing what you subscribed for. Anyway, let's just get on with it.

The demo for Mass O' Kyzt will very likely be released alongside the full game. This is due to the fact that it's a much better idea to start with a complete product and cut bits off rather than to built a small version of something, release it to the wild and then try to build on top of that.

The fact that I've revamped large elements of the game like three times now should be proof enough of that- it's very difficult to gauge when the game is actually done and whether the game is what I want it to be. It's probably not the best idea to just start making something and mutating it until it's acceptable, but my experience with design documents have been disappointing at best.

So far, all the projects I've tried to start that involved a design document have failed and I've given up on them before long. Of course this is entirely on me, I'm not trying to tell you that design documents are useless but I would have to change the way that I approach creative design to be able to access the full potential of a design document.

For some reason, my brain just doesn't work in a way that facilitates design documents. Maybe they're too rigid or I'm just bad at writing them but something's awry. I'm probably not going to return to design documents until it's more suitable, for instance if I were to become part of a team.

I'll stop rambling on about design documents for a moment and get back to the point. Mass O' Kyzt is a difficult game to trim, since it's not particularly big to begin with. It's got a nice core gameplay loop which is only just rearing its head after months of work and re-working. Naturally, the big question is "How am I going to make this demo both fun in its own right as well as able to incentivize further purchase of the game?"

The most likely scenario is that the demo will limit the number of consecutive waves that the player can play, and also will gate off a lot of the unlockable stuff that I've got planned. This means that the player can get a feeling for the core gameplay without being able to just play the entire game straight through.

As to when the game will be released, the current estimate is some time in January. Maybe around Christmas, but since I need to create a bunch of new maps, environments, player skins maybe and I'm sure a lot of other stuff I'm forgetting right now- I have my work cut out for me. I can probably implement some of this stuff in updates after the fact once I've established a sufficient baseline of unlockable content, but that could take a while.

We're already almost over with November and I'm just barely finishing what I believe to be the core loop. Sprite work is what takes me the longest and unfortunately it's what I need to do the most of at this point. As I'm sure you have been able to tell if you've seen the current iteration of the boss sprite that comes in five waves, I'm not exactly the best at it.

This video has really been quite rambly and it could get a lot more rambly so I'll cut it short now. I'm not quite ready to create the next Devlog video and I didn't have quite enough content to fill up an entire video just talking about the demo when I really just needed to get across a few key points, so yeah I allowed myself to go off on a tangent a bit more.

One more thing, if you want my hot take on something that I can make a video about- please let me know, it's not easy to come up with video ideas all the time. I've got a few more video ideas, but it would help to have something fresh.

Anyway, thanks for watching and stay tuned for the next video I make probably being Devlog #16, but no promises because everything I say is incredibly volatile and open to change. Goodbye!

How to use the Steam API with Godot

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.

A Temporary Hiatus

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?

Creativity

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.

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 itch.io, 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.

Devlog #14 - Steam, Blobs and Fireflies

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 gov.uk 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!

Devlog #13 - Special Energy, Flowers and Level Design

Burned out?

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? 

Devlog #12 - Sound Effects, Core Redesign, and Polish

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.

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: alexhoratio.co.uk! Exciting!

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.

Devlog #10 - Story, Tiles and Background

The Narrative of Mass O' Kyzt

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.

Devlog #9 - Core, Rogues, and now everything is fixed(temporarily)

Devlog #8 - Story, UI and now everything is broken (temporarily)

Devlog #7 - UI, Tanks and Upgrades

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Damn it, Doctor Who

Watch the video version of this post here: https://www.youtube.com/watch?v=wBVJ7VILPm4

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.

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.

https://www.mediafire.com/?g3d0sqnpt48s12b

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.

Gitting Gud At Godot - Part 8 - The AnimationPlayer

Watch the video version of this tutorial here: https://www.youtube.com/watch?v=7DzrL1P_7J4

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

Gitting Gud At Godot - Part 7 - Instancing

Watch the video version of this tutorial here: https://www.youtube.com/watch?v=05eMjKLua9Y

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!

Gitting Gud At Godot - Part 6 - Intersections and Signals

Watch the video version of this tutorial here: https://www.youtube.com/watch?v=AbIlI-XFKjs

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.

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.

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

Watch the video version of this tutorial here: https://www.youtube.com/watch?v=1Z77N4Gomtk

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.

Gitting Gud At Godot - Part 4 - Input

Watch the video version of this tutorial here: https://www.youtube.com/watch?v=LMUYtfJ6x4k

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!

Gitting Gud At Godot - Part 3 - Scripts

Watch the video version of this tutorial here: https://www.youtube.com/watch?v=CouU0HDWeFo

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.

Gitting Gud At Godot - Part 2 - Nodes

Watch the video version of this tutorial here: https://www.youtube.com/watch?v=CvbkoaH9Ayg

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.

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.

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.

Why Ludum Dare is important

Find the video version of this post here: https://www.youtube.com/watch?v=IfhstX9kUHY


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

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.

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!

Shoehunt is now released!

Check it out on Gamejolt here:
http://gamejolt.com/games/shoehunt/250195

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.

Enjoy!

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.

1. LMMS

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!

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.

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

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!

http://docs.godotengine.org/en/stable/reference/_compiling.html

Warning!

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.

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.

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!

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!

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:

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

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

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: https://github.com/ackens/-godot-gj-api

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:

    get_node("../GameJoltAPI").method(argument)

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:

    get_node("../../GameJoltAPI").fetch_scores("30")

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 = {}
    scores_dictionary.parse_json(scores)

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()):
        if(i<15):
            names += visible_scores[i]["guest"] + "\n"
        elif(i<30):
            names2 += visible_scores[i]["guest"] + "\n"
    get_node("../names").set_text(names)
    get_node("../names2").set_text(names2)
  
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:

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