How To Design Minigames

Sometimes when you're working on a cool little video game, you'll come to a point where you're thinking about adding a little minigame to spice up an otherwise boring mechanic.

In my experience and as far as I can tell, usually this happens to bridge a gap in the wider design of your game. For instance, let me give an example using my own game.

In WARP-TEK, the gameplay is basically one really long journey interspersed with boss encounters. This is cool and everything but there is a problem with replayability- if the player is made to replay the first 10% of the game like a thousand times, they're gonna get really bored and run into the same issue that a lot of games, specifically roguelikes, run into- repeating content is not fun, and eventually repeating the same content enough actually becomes a deterrent to be weighed against the promise of something cool happening later on.

So in light of that, I thought a bit about how I would fix this, and I decided that the player would have to be able to skip over areas of the game that they've already played through a gazillion times. Of course I can't give this one to them for free- that'd remove like all of the challenge. So I decided that the perfect thing to fill in this gap would be to add a nice little minigame.

So it took me like two days to actually design and implement this simple minigame- all I ended up doing was making it so that the player can skip to a maximum of 80% of where they left off. There's one of those bars where the fill moves up and down, and the player has to press any key when it's as high as possible. This is still pretty easy but it's simple, quick and feels pretty nice as a little downtime between playthroughs.

If anything, the biggest flaw with this minigame is that it is too easy- with a bit of practice, I'm sure you can reliably hit 80% of where you left off every single time.

For what it's worth at this point - and this is probably a little bit more programmery than you might care about - the fill doesn't move up and down in a perfect sin graph as you might think to implement it. It's actually sin cubed, with a little bias to make it move away from the top values a little bit more quickly than it does the bottom values.

Anyway, back to design. What other considerations were there when making this minigame? Well, it couldn't be too tedious. The whole point of minigames in this context is to break up gameplay and make things a little bit less tedious. I considered doing a continuous "endless runner" type thing initially, where you have to dodge progressively more numerous obstacles until you eventually lose and you're placed into the game at the point that you lost.

This wasn't a bad idea but it could easily become tedious in itself if the player plays it enough. There's really no promise of variety and it would by necessity judge the player based on how long they can survive playing the same thing for maybe 20 or 30 seconds or so. That doesn't sound like much time, but in aggregate it could mean making the player play shitty Flappy Bird for upwards of 5, 10, 20 minutes over the course of beating the game.

There used to be a minigame in WARP-TEK that was such that right before you kill a boss, the camera zoomed in on your ship and you had to run around and activate all 4 power cores to fire a huge laser beam which finishes the big enemy off. If you took too long to do this, the boss would regenerate a little bit of health and you'd have to go again.

It's not a bad idea and I'm still not sure I hate it - I've actually got a switch that just disables it, the code and assets are still in the game just waiting for me to change a boolean value - but it does take a bit of time and it's really just the same damn thing every time. It's not super interesting or varied and while I love minigames conceptually, you have to keep in mind that they have to be either fun in themselves, or so tiny that the player doesn't have a chance to get tired of them.

That's all I've got for this video I guess, I hope you gleaned something interesting from this video. Thanks for watching and stay tuned for more videos about things I'm still despite my best efforts not qualified to talk about. I saw someone do a reddit comment one time saying that all my videos are "weak points" and I beg for subscribers at the end, so I guess fuck that guy and please subscribe to me. Goodbye!

Ludum Dare 43 Post-Mortem

I'm kinda jumping the gun on calling this a post-mortem since at the time of uploading this video, Ludum Dare 43 hasn't even finished yet. But hey, I already finished my submission and based on my schedule of uploading a video every 3 days, this is the best time slot to make this.

So for those of you who don't know, the theme was "Sacrifices must be made". I used a word processor to jot down a few ideas, and soon enough I came up with the idea that the player has to protect a small population of people from a bunch of oncoming enemies, but they can also sacrifice a member of the population to get stronger.

And that's the premise of my submission, you kinda have to balance having citizens to protect - if they all get killed or sacrificed, then the game's over - with your own power. Also, the enemies get progressively stronger as the game goes on.

So how did development go? Well, I originally intended for the art to be a bit more interested and varied than it ended up being, I thought hey I can do medium quality art in a relatively short time, so why not? However, by the time I put pixel to... uh... computer screen, I ended up with some real minimalistic sprites.

This proved to not really be an issue since it looks perfectly respectable, and on top of that took me like an hour to create.

As for code, there was a bunch of algorithmic type programming which is my absolute favourite type of programming. For instance, moving the selection cursor between citizens to determine which one to sacrifice was real fun to program, though I did spend about an hour working through one annoying bug which in retrospect, was way more time than I should have.

Another nice one was determining how the citizens should wander around- I went through a few really complicated solutions until the really simple "generate a random point to walk towards, then once they reach that point just generate a new one" system popped into my head.

Overall I'm really pleased with this Ludum Dare submission I gotta say, it's probably my best one yet in so far as its design goes. It's probably got the most replay value, and miraculously the music turned out sounding pretty decent! For the first time since that one music track from Mushroom: The Ruckus... I can't remember what it's called, but it was pretty good.

I also feel like in this Ludum Dare, I paced it way better- previously, I'd have like almost the whole game finished on Saturday, then on Sunday I'd only have audio and a few tweaks left to do. This time, it was much closer to a 50/50 split- probably on account of how much work I had to put into this one as compared to my previous Ludum Dare games. All in all, I put just under 16 hours of work into this Ludum Dare game.

Thanks for watching and stay tuned for more videos about games that I make, some of which are Ludum Dare games and others which are like real proper big games.

How To Do Pixel Art With Godot

Some of my videos end up getting a bit technical but let me tell you this isn't one of them. Making pixel art look nice and neat and tidy in Godot is like one of the easiest things ever and I'm gonna have a hell of a job stretching this into three minutes, but somebody commented that they wanted to see a video on this so I guess I'm at the mercy of the people.

So to start with, I'd recommend determining the resolution that you want your game to run at. For most desktop games I'd recommend that this is some nice even fraction of 1920x1080, so that could be 920x540, or in WARP-TEK's case 480x270. All I've done to arrive at these numbers is divide 1920x1080 by 2 and 4 respectively, so that each pixel will take up more space on the screen.

So now that you've made the hardest decision that you're gonna make in this long and tiring process, all you have to do is go to Project Settings, Quality, enable "Use Pixel Snap" to make sure you don't get any weird artifacts when you've moving the sprites, then go back to "Display"->"Window", set "Resizeable" to true, set the Test Width and Test Height to 1920x1080(just to make the game the appropriate resolution when it's scaled up) and for good measure I usually enable "Fullscreen" here too.

Lastly, go down to "Stretch" in the same section and set mode to viewport, and set aspect to keep.

And that's it, you've now exactly recreated the same style of pixel art rendering that I use in WARP-TEK. The advantage of doing it this way is that all things like particle effects, Control nodes, etc will all be pixel-lookin and you don't have to do anything about it.

See? Super easy. I told you I wouldn't fill up three minutes with this. Hmm. So what's up with you guys?

..

Hm, interesting stuff. Yeah. I hope that all works out for you, you know, the stuff you just said. Yeah.

...

Well thanks for watching and stay tuned for really short videos that you too can recommend that I make so that it's your fault that the videos are too short and not mine. Goodbye!

Play-Testing WARP-TEK

Recently, I've sent my game WARP-TEK to a few friends for beta testing- so they can help me catch bugs, point out things which are annoying or whether the game is just "missing something".

I'm not really expecting to get unbiased feedback. In fact, I'm almost certain that they all had their expectations a bit unfairly tampered with before they even launched the game. However I do think that their feedback is super valuable- they know the core idea of the game better than random people, so I don't have to own up to the fact that I don't have any tutorial system at all, and I don't have to explain it to them otherwise.

I'm probably not gonna get feedback like "this whole system is broken, ill conceived and I spit upon you and your ancestors". If I get feedback like that at this stage, then fuck me it's a good thing I didn't show anyone this pile of garbage before I fix it. If not, then it's a kind of "go-ahead" to pass it on to the next wave of playtesters at some point who would be people a little more removed from me.

I should note at this point that if you're active in my Discord server, there's a much, much higher chance of you getting a beta key. That's mostly because if you never speak to me, then it's really quite unlikely that I'll even know you exist and I'm not gonna fire some beta keys into the ether quite yet.

But the point is that at the moment, I'm not expecting to get really detailed feedback. One active user in my Discord server - Miles - has given me an extraordinary wealth of things to think about, consider, and tweak. I'm super grateful for this but it's a spell of luck that he did. Fortunately, the overall response seems to be that the game is pretty cool(albeit flawed at this stage) which definitely surprised me for the game being so early on in its life cycle!

The important thing about selecting playtesters is to make sure that they have some kind of analytical and game design oriented mind so as to pick out things that are cool and fun and be able to present them. Even if they don't have the best solutions, if they have anything to say at all then it's your job as a designer to evaluate their feedback and consider whether there is a problem there and whether you can come up with a fix for it.

With less experienced game designers or with completely random people i.e the average consumer, they probably will give you a high amount of garbage advice. They might suggest new features that are incoherent with the rest of the game, they might feel frustrated by something but not realize what it is that is actually frustrating them.

I don't mean to frame it as them being stupid, but it does take a certain level of skill to provide good and useful feedback, and when you're interpreting this feedback you have to also consider the playtester's competence in analysis and design.

Lucky for me, out of the three people who playtested WARP-TEK for me, two of them were analytically-minded game developers. The third was my brother and he didn't give me shit for feedback so I'm going to pour syrup in his bed but the point is, I got some good, trustworthy feedback in the end.

Anyway this video sucks and I guess if you watched this far into it then I kind of feel bad for you but I already missed my last scheduled upload 3 days ago and I can't justify missing another one. YouTube is hard! I gotta think of a cool idea every 3 days? And I got a video game to develop? Yikes!

So yeah thanks for watching and stay tuned for more meandering garbage. Goodbye!

Optimizing Caffeine Intake (+ Other Nootropics)

I'm sure that caffeine use is familiar to pretty much all of my viewers, being the programmers that most of you are- and of course a central tenet of programming is consuming caffeine.

However, if you're drinking caffeine daily over a long period of time, you're probably not using it as efficiently as you could be, as I found out the hard way.

So for some background, I went from drinking about 8 or 9 cups of coffee daily which is known as "fucking heart attack" quantities of caffeine intake- it'd probably work out to 600-700 milligrams of caffeine a day. I woke up every day with a tension headache and constantly had pain in my jaw from muscle tension, and developed some pretty unpleasant anxiety.

However, at some point I got really sick for a week so I couldn't drink caffeine anyway and this had the effect of showing me a level of illness (combined with caffeine withdrawals) that I'd sooner kill myself than try to experience again. But the point is that after this hard caffeine reset(well, it took a couple more weeks to get to actual normal levels) I had lost a lot of the tension and anxiety that caffeine was giving me.

So I decided fuck that I'm never getting caffeine dependence again if that's what the cold turkey withdrawals are like, and I worked out a way to drink coffee occasionally without experiencing dependence or tolerance.

You might be wondering how, and you could probably work it out with a few minutes to think about it because it's not complicated, it's literally just not drinking coffee regularly. I generally limit it to 2 times a week, distributed sporadically so as to not let my body get used to it. This has the effect of making me non caffeine dependent in day to day life, and when I do drink coffee it makes a hell of a difference to my productivity.

Quite often, the amount of work I get done doubles or even triples on days when I drink coffee because I have maximized my sensitivity to it. This also means that on days I don't drink any coffee at all, I can still do an average normal amount of work.

So that's basically my advice, get off caffeine either cold turkey(which I legitimately would not recommend if you drink as much as I used to), or taper off by recording your daily caffeine intake and slowly reducing it- for reference, there's a little under 100mg of caffeine in an average strong cup of coffee, and about 20-30mg in an average cup of black tea.

Once you're off caffeine, just use it periodically- 1 or 2 days a week seems to be a good spot for me, but it depends on how your own brain deals with caffeine. I develop dependence and tolerance remarkably quickly, but I've heard some people drink coffee 3 or even 4 days a week without developing any tolerance at all.

So what about this "other nootropics" bit I put into the title of this video? That's right, your boy's done his research into things that go a bit beyond caffeine.

Now I'm a bit shy so I'm not going to mention microdosing tiny amounts of LSD to enhance flow states and creativity.

However, as I said- I'm too shy to mention that bit, so I'll move onto my next favourite which is l-theanine. This one's a bit niche and I've never taken it in tablet form, but it's a chemical also found in black tea which reduces the jittery side effects of caffeine and increases single-track focus, so your brain's not as all over the place as it would be if you just shotgunned 5 shots of espresso. In my experience, the caffeine experience from black tea compared to coffee is very different. Black tea definitely affords much more focus and clear thought rather than the frantic feeling you can get on a lot of coffee. Plus, black tea naturally has much less caffeine than coffee so that probably plays a role. 

L-theanine is frequently taken on its own as well. A lot of people in nootropic communities consider l-theanine as an obvious frontrunner- it's really hard to build a tolerance, dependence or experience withdrawals with even high amounts of l-theanine daily. It has no real adverse effects compared to caffeine which can cause anxiety, tension, shakiness among other things.

Alright, this one isn't really a nootropic but it's a good idea. Take some damn multivitamins. Caffeine actually drains your brain's magnesium stores, meaning you're more prone to unpleasant muscle tension- which is already an unpleasant side effect of caffeine. Also, if you're not getting enough vitamin B or vitamin D, you might just feel kinda depressed or deflated and not even realize it until you start supplementing them and feeling noticeably better.

This is especially important if you're on a vegan diet, since it's quiet easy to miss out on essential B vitamins or vitamin D3- which is difficult to produce from plant sources. Everyone else feels the effects of animal products generally being supplemented with vitamin B and D before being sold to you, but unfortunately this practice is much rarer in vegan products. 

So that's about all my knowledge on this topic but I've skipped over some details. If you want to know anything else or better yet if you want to share something along these lines with me in the comments, please do! I should also note at this point that you shouldn't expect any nootropic drug to fix your productivity problems- you have to put some brain work and head thinkin into it to get anywhere with it. These should be used IN COMBINATION with other practices, like that pomodoro thing seems useful, project tracking and closing your damn social media channels while you work. Hell, even meditation can prove useful.

Thanks for watching and stay tuned for more videos wherein I, an unqualified 18 year old, gives you advice as to which mind-altering substances to use to help you achieve your goals. Goodbye!

10 Tips For Using The Godot Engine

Fuck me I really am doing a top ten list aren't I? Jesus Christ. Anyway, let's get to it, I guess let's start with number one.

1. Singletons. These are basically scripts that don't really attach themselves to any existing node, which means that they exist outside of the current scene- which makes them perfect for things like saving data, playing music uninterrupted between scenes or preloading a bunch of resources to be used later. I've got 14 singletons in WARP-TEK as we speak, so I can tell you that I really like using them.

2. PhysicsBodies. This is close enough to a tip, right? Let me just run through the three types of 2D PhysicsBody nodes and their usual use-case.

KinematicBody2D nodes are what I use for most things that need to move around, so enemies, the player, other colliding entities, etc. RigidBody2D nodes are good for physics-based movement, so if you wanted some boxes for a puzzle game that move and fall like real boxes would, then you'd want to use RigidBody2D. Or, you COULD use KinematicBody2D but you'd have to program all the physics stuff yourself.

Lastly, StaticBody2Ds are good for anything that should never move like walls or the floor. Easy enough but it's good to know the difference.

3. The ternary operator. Now most programming languages have this one, it's the question mark one in C++ and in Python it's just thing if condition else other_thing. In GDScript, it's the same as in Python(as most things tend to be) and it's super useful. I realize it's much nicer to use this ternary operator on one line rather than dedicating 4 lines to an if/else block.

4. Here's a more functional tip, and it's based off something I actually do in WARP-TEK. Use a Singleton script to preload all of your resources to speed up in-game performance. This way if you want to instance a node, you just refer to its entry in this monolithic resource script and instance it. It has in my experience with preloading over a hundred objects made the game start up maybe half a second slower, but it drastically reduces lag-spikes that stem from repeatedly having to load or preload resources, such as when you're spawning a big blast of 30 or 40 bullets.

5. Specifying neighbours in Control nodes. So have you ever run into the issue where you want a menu to be usable with the arrow keys or a D-pad but Godot just won't direct to the correct buttons in the proper order? Well, I haven't because I haven't really considered keyboard accessibility until really recently but there is a really neat solution to this problem.

Any control node will have the "Focus" category, and you can see there are a few properties like "Neighbour Left", "Neighbour Down", etc which basically determine what happens when this button is focused and a specific key is pressed. In case this explanation wasn't super clear I'd say just play around with it because it's a really simple concept and it's implemented really well.

6. NinePatchRects. This is also related to a Control node, but trust me- this is super useful, and it's actually a new thing that only just appeared in Godot 3. Basically, for Mass O' Kyzt I had to manually size and align all the edges and corners for all the menu panels and stuff. For WARP-TEK, I've specified a 3x3 grid of what each corner, edge and middle piece should look like, loaded it into a NinePatchRect and all you have to do is resize it and it'll automatically scale or tile the corresponding parts of the graphic to fit a size of your choosing.

It's super convenient and while it sometimes takes a moment or two to actually configure it so it scales how you want it to, it's definitely worth looking into.

7. Have you ever had that issue where you're cooking pasta for a while and you stir it but you're kind of impatient and you think "well, this is probably good enough" and you strain it and put it into a bowl and you take a bite and it's really crunchy in the middle and so you put it back into water but you have to heat up the water because you used cold water but by the time the pasta's boiling again the pasta has actually dissolved into the water and you're left with a kind of starchy gloop that you have to turn into a soup but you don't even really like soup so you just pour it out and then it blocks the drain because it's still really thick in places and then your sink overflows and instead of calling a plumber or even turning off the hot water tap you just sit under the table crying and feeling malaiseful about your terribly out-of-control life while you wait for the small puddle of water on the kitchen floor to reach you and force you to either clean it up or deal with soggy clothes but when it does actually reach you you just realize you don't have the energy or motivation to even get up off the floor for another hour and your clothes get completely saturated in warm starchy water and by the time you do get around to cleaning it up you've done permanent water damage to that stack of important envelopes that you've been meaning to pick up off the floor but never got around to?

...No? Alright then, moving on.

8. Autotiling! Of course this one had to be on the list. It's a little tricky to get your head around initially what with the bitmask stuff but it's super useful once you do get the hang of it. I won't try to explain it too much here but trust me- learn it. It'll take you an afternoon at the absolute longest, and potentially even faster if you watch my tutorial video on autotiling (I think I have one, I suppose I should check before publishing this but fuck you I guess)

9. Using an external code editor! I did do this for about a day with Sublime Text before realizing that Godot's built-in code editor is fine for my needs but if I had a strong preference(for instance, if I was a Vim or Emacs fanatic) then I would be in luck, because Godot makes it super easy to use a third party editor. Just go to Editor in the top left, Editor Settings, and under "Text Editor" click "External" and configure to your heart's content.

10. The new Audio Bus system. Okay, I don't think this really counts as a tip but it's just something I really like about the engine and you gotta agree it's a step above whatever the fuck 7 was about. Basically, I generally create two new buses in addition to the master bus, and I call them "music" and "sound". Fairly self-explanatory, but the idea is that you route all the music sound through the music bus and all the sound effects through the sound bus. If you wanted to you could have buses for ambient sounds, voice, etc.

The point is that this makes things easier for you when you're adjusting system volume. You can make a nice volume slider that directly adjusts the volume of the music bus, and another that corresponds to the sound bus. This stops you from having to save another variable like music_volume and refer to it any time you want to play some music.

Anyway, that's about all I've got. If you have any more interesting things about the engine that you think I and the world should know about, for real let me know in the comments- I'm still learning new things about the engine constantly!

Thanks for watching, and stay tuned for more top ten lists... maybe... probably not though because this was a pain and really long to write sooo.. uh.. goodbye.

A HITPIECE On Florian Himsl

Some of you might know that I've been livestreaming with Florian Himsl, the co-creator of The Binding of Isaac with Edmund McMillen. His outwards persona is charming, even soothing- but let me tell you, there lies a dark side beneath the veil.

Florian Himsl. Born to the name Florida Hershey's. The true story of how The Binding of Isaac was developed is, to put it simply, harrowing.

Florian, drunk on his own lust for power, approached Edmund one stormy night.

"Edmund," he began, slurring his speech due to the aforementioned drunkness (on his own lust for power). "Listen to me, we're gonna make a fucking game, and you're gonna like it."

Edmund, taken aback, responded "Who even are you this is the first time you've ever spoken to me?"

"I'm Florian", he responded. "I'm Florian Himsl and we are gonna make a goddamn game."

What followed from these events is a tragic tale of workplace abuse. Florian would constantly chastize, berrate and even physically hit Edmund- an astonishing feat given that they live hundreds of thousands of miles away from each other.

But here's the real dirt on Florian. Florian didn't even program The Binding of Isaac! Florian Himsl is the owner of a small workforce of goblins. Proper goblins too, green skin, pointy ears and each about 3 feet tall.

Florian Himsl naturally delegated all the programming in The Binding of Isaac to the goblins. He sat back in his chair with a whip, while each goblin toiled away in the code mines. Florian had no idea how to do any programming, at least at the time. Why should he even have to learn? He's got a goblin workforce! Unfortunately, this lapse in knowledge led him to adopt some peculiar tendencies. For instance, he refused to allow the goblins to use variable names more than three characters long, among other atrocities.

Now, you might be asking "What does he feed the goblins?" and here's the truth.  The truth is that he's feeding them baby food. Being small and child-like in many ways, goblins can't really eat anything else that isn't baby food. They don't have the digestive tract for it, and after over a decade of being force-fed nothing but baby food- nobody would.

Now, here's the thing. Being a master of goblins does lead to some.. complications. Transformative complications. Have you ever wondered why Florian eats baby food sometimes on his livestreams? Have you ever wondered why he can only name variables with a max of three characters? Have you ever wondered why on the livestreams, he's the one doing the programming?

He's become a monster truly of his own making. All the things he's forced upon his goblin slaves have come back to haunt and manifest themselves in his own being. Soon Florian Himsl as we know him will be gone, and he will be replaced with a three foot tall babbling goblin creature.

Don't support this man's work. Do not subscribe to his YouTube channel called GameSquid (linked in the description), it's a front for something much more sinister. Do not get excited for his game Squid Invaders.

Heed my advice, viewers. It's only a matter of time before the goblin hoarde comes for me too. Thanks for watching, and stay tuned for more videos exposing this absolute goblin of a game developer. Goodbye!

How To Develop Games On Linux

Anyone who's been following my YouTube channel for a little while might realize that I do all of my game development work stuff on my computer which runs Debian Linux rather than Windows.

I thought I'd just outline some of the tools that I use when working on Linux, so here we go.

The biggest component of my gamedev toolkit is probably the Godot Engine. It really nicely handles everything I want to do for 2D games, though I haven't really ventured out into 3D as of yet. If you don't wanna use this engine then you can also use an experimental build of Unity which apparently supports Linux, which is awesome. However in my experience from a couple of years ago, this build of Unity is filled with bugs and from what I've heard isn't MUCH better even today.

However, at least as a transitional step between Windows and Linux, Unity is still there. And it sorta works.

Another engine that works WAY better on Linux is Unreal, since Unreal is able to built on pretty much any machine via way of keeping its source code available(although unavailable for any edits, so I don't think it's technically open source).

I've opened Unreal and while it's a pretty heavy program compared to Godot or even Unity it seems to work perfectly! No bugs, no glitches and no unexpected crashes.

Now unfortunately if you're a big fan of something like GameMaker then this is gonna hurt. No matter how much I try I just cannot get GameMaker to work on Linux- even using WINE which is a compatibility layer specifically designed to make Windows programs work on Linux. I mean your best bet is to get GameMaker running in a virtual machine, but... you know. That's not a great setup.

So in short, I use the Godot Engine for the bulk of my gamedev stuff. There are, however, a few more tools that I use, so I'll just name them off real quick.

Aseprite is great for pixel art, and chances are if you're running Windows you'd be using this one too. I do find that it opens a little faster and runs a little smoother on Linux, but that might just be my own subjective experience, so I won't pass that off as a fact.

Anyway, if you can't or don't want to use Aseprite you can use online editors like Piskel or Pixie- both of which seem pretty good to me. I started off using Piskel, though unfortunately it became a little bit unwieldy for bigger projects- hence why I switched to Aseprite.

However, what if you don't wanna do pixel art? Well, you have some options here. You can either run Photoshop in WINE where I'm told it runs very nicely and efficiently, or you can choose from a few Linux alternatives. The leading one I'd recommend is actually Krita if you're coming from Photoshop because Krita is easy to use, pretty quick, it has a slick and intuitive UI and it's just a really nice program to use in terms of workflow and everything. I generally recommend Krita to anyone who wants a nice digital art program.

The other obvious answer that I have to mention on penalty of Richard Stallman strangling me in my sleep is GIMP- GNU Image Manipulation Tool. It's pretty good and I do use GIMP sometimes if I want to generate a graphic or edit a picture in some way because it's really useful for certain tasks. I'm not sure I'd recommend it as a general digital art tool when being compared with Krita, but it's really powerful at what it does do.

So now let's move onto an area I know a little less about- music. If you want music, I'd probably recommend you something like BeepBox because it's easy, web-based and you can basically just click randomly with your eyes shut and get something that isn't *that* bad. However, if you want a little bit more than a simple chiptune generator can give you, you can move onto something like the much less popular Bosca Ceoil.

Bosca Ceoil is very similar to BeepBox and I'm sure it was based off of it in some way but it allows a much wider variety in instruments, BPMs, etc. It's basically BeepBox+, though in its complexity it does lose out on some of the simplicity that makes BeepBox so easy to create with.

If you're a real music boy then you can go ahead and run a DAW of your choice. Chances are if it isn't natively Linux compatible(which many of them aren't), you'll be able to run it perfectly fine on WINE. I've never had any problems with any of my terrible attempts at using FL Studio.

So anyway, if you want some sound effects synthesis then you can use Audacity which again- if you're on Windows you probably would be using this all the time anyway. Download some samples from freesound.org or your website of choice, edit them to your needs and you're good to go! However, if you're making a chiptune game and you want something a little bit more specialized to help, I can recommend you the tried-and-true sfxr. If you want something a little bit more easy to use or refined lookin, you can go for ChipTone.

Usually for things like Ludum Dare or any game wherein I need a chiptune thing, I'd use ChipTone since I really prefer the intuitive visuals and UI. However, I can understand why somebody would use sfxr for more fine control over the sound. They're different tools, but for a beginner I'd recommend ChipTone.

Lastly, let's get onto some code editors because I realize that even if you're using a proper engine like Godot or Unity or Unreal, you might still want a third party tool to edit code with. My first suggestion is always Sublime Text 3 and again- many Windows people will have heard of this too. VSCode works on Linux, as does Atom but I'd always recommend Sublime Text 3. It runs so damn smoothly, it's so damn nice and I've been just looking for excuses to use it I get so much pleasure out of it.

But I guess failing Sublime, Atom would do just fine too.

So yeah, I think that's pretty much everything. I'll rattle off a few more useful programs- kdenlive is really useful and it's what I used for editing this video, OBS is always the king of video recording software, and LMMS is a Linux native DAW that is surely useful in the hands of someone who knows how to use it.

So thanks for watching, and stay tuned for more videos about Linux and me usin Linux to do Linuxy things in the Year of the Linux Desktop. Goodbye!

(Temporarily) Burned Out :(

Well, I've been working on WARP-TEK almost every day for over 3 months and now I think I'm getting a bit worn down.

My first reaction to even typing such a sentence is to say that "Hey you, people work for WAY longer than that and don't get burned out! Get back to work!"

So rather than just ignore it and run the risk of one of you evil little gremlins commenting something similar, I've got a few responses to that.

The most obvious one is that gamedev is creative work, and yeah I'm sure I could work a lot longer if I was chopping logs or delivering mail. Not that there's anything wrong with those jobs of course but they're more predictable in the way that the energy you need in order to deliver mail is physical and routine rather than the creative and unpredictable energy that you need for gamedev.

Creative energy is more tricky to recharge because you can't just "go through the motions" until you get it back. It's not possible to come up with ideas if you really hate doing it, that feeling will just block the creative flow.

Once the ideas stop flowing, it's really quite tricky to make them start again. I'm sure it's possible with practice and expertise but hell, I'm not the most creative person at the best of times, compared to other people I know who secrete new ideas at every waking moment.cough cough I know you're watching thi-

But the point is, there's a distinction between the traditional 9 to 5 office job which is definitely challenging and stressful in its own ways, but it's also potentially less prone to burnout.

The next thing to note is that my brain is not the same as the most workaholic brains out there- some people do work 11 or 12 hour days on creative works and it absolutely kills them but they're still able to do it, and in some way shouldn't I try to force myself through that to get this game out there? Well, the answer's no, I shouldn't because that's real unhealthy but more importantly does NOT make a good game.

Putting in more hours does not necessarily correlate to putting more work or especially not a higher quality of work. The highest quality work comes when you are well rested and thinking positively about the project, not when you're exhausted and hate working on it.

And again, contrary to what you might think, massive quantities of low quality work - as is the case in the 12 hour work day - does NOT make up for really any amount of high quality work.

So how am I gonna fix all this? Well, the usual plan is to take a little break and focus on something else. I'll still be doing YouTube videos and I suspect this break won't even last particularly long because I do want to work on it, I just can't make myself focus or enjoy it- at the best of my abilities, I'm still putting in low quality work.

Hopefully, I'll be back in under a week or so. I've known that I've been slowly careening towards burning out for a few weeks now, and I've delayed that for as long as possible with caffeine, vitamin supplements and some more experimental things. However, these aren't permanent solutions, they're just that- delays.

Maybe I need to make this video above all to just convince myself that I'm not just being lazy when I take a break from game development, because sometimes it does feel that way- but the brain isn't necessarily a rational machine and sometimes these lessons need to be hammered in a little bit.

But if there's one lesson I can impart to you kind viewer, it would be that burnout - at least temporary burnout - is for many people inevitable, and you don't need to feel the least bit guilty about realizing it and taking steps to fix it once it's happened.

So thanks for watching, and do genuinely stay tuned for more videos because I'm still doing YouTube even if the game development side of things is stalling for a little bit. Goodbye!

How did I get into game development?

A couple of people have actually asked me how I got into game development in the first place, and since I've got a headache and nothing else prepared today- why not?

So probably my earliest attempt at game development took place on an old Windows 98 laptop that my dad let me use periodically. I couldn't work out how to connect it to the Internet and in retrospect I'm not sure that it was possible to even do so since it was pretty decrepit.

However, I still somehow figured out how to make little choose-your-own-adventure games in Windows Batch Script. They were really simple and mostly unfinished since I'd just start a new one whenever I got bored, but it was fun enough for a 6 or 7 year old.

After that, I found Macromedia Flash 2008 wherein I created a bunch of really bad games that basically only utilized buttons since I couldn't quite work out how to use ActionScript at the time. I uploaded many of them to Newgrounds and all of them got banned, but I also uploaded a couple on Kongregate which I guess is stuck there for all eternity. One of which is on the account I use currently, but the other is actually on another account which I can't be bothered to find at the moment.

Unfortunately, after this I kinda got demotivated with making games and resigned to playing them a bunch and I decided that I'd become a physicist, since I thought it'd be a bit more dignified and grown-up than being a silly lil game developer. Over the next few years, I began to want to become a software engineer instead, since physics became really quite tedious and I really enjoyed programming.

At some point a couple of years ago, I kinda started thinking about the fact that years of not using my creative brain had actually damaged and degraded it fairly significantly. I was a bit unhappy about that since I think some part of me still really wanted to be a game developer, so I took a bit of thought and decided that being dignified and grown-up is not actually very useful or cool or fun and it's way more cool to say fuck that and literally follow my life-long aspiration.

So this happened in about 2016 I think when I decided I wanted to get into game development. At around the same time, I also made the decision that I want to be indie. Both of these decisions were helped and inspired in no small part by my friend Magos, who made similarly tough decisions at around this time.

So I did a bit of digging around and I found the Phaser framework for HTML5 games. At this point I was extremely bad at pretty much anything that wasn't programming, and even looking back at my code around that time... YIKES.

But I did it anyway and made a few unfinished games with my boyfriend(who contributed the art assets primarily since he's a proper real artist boy), then I realized that I'm a terrible team-mate and stopped doing that pretty quickly.

The problem with Phaser is that it's not super easy to make standalone executables with it, so this means that distributing on proper marketplaces like Steam becomes quite difficult. At this point I had no hope of actually distributing on Steam of course, since this was around when Greenlight was a thing and even the best moments of my games were not very good.

I wanted to try to learn a proper visual engine like Unity, though I had my doubts about how intuitive it might be and the learning curve kind of made me hesitant. At some point, I bit the bullet and spent like 3 or 4 days trying to learn Unity. However, Unity on Linux is absolute trash so I decided fuck that I'll just use Godot.

From there I made some pretty bad small projects, some less bad small projects, some kinda okay medium projects and now I'm here- makin a pretty cool medium project.

That's pretty much all I've got so far, and I'm still not really "into" game development- I've not really got a product that I consider a proper attempt at a game. Mass O' Kyzt is the closest contender, but since that game has so many issues and silly things that I would not do the same way now, I definitely don't consider it representative of my real abilities.

Anyway, thanks for watching, and feel free to let me know in the comments what kinds of things got you into gamedev! Stay tuned for more videos about my games and things related to my games, goodbye!

Sporadic Godot Tutorials - Contributing on GitHub

I'll go ahead and assume that if you're watching this video, you are aware that the Godot Engine is open source via the MIT license and the source code is able to be downloaded and edited by anyone, and sometimes people will submit pieces of code to be merged with the main engine codebase, which is how most open source software works.

So basically, if you want to submit one of those little pieces of code (known as pull requests), you're gonna have to learn a little bit about how GitHub works. I'll outline basically what you have to do for any GitHub project right here:

• "Fork" the repository.

You can think of this like a "fork in the road" type thing, where half the path leads on to your version of the codebase and the other path is the "official" version of the codebase.

• Create a "branch" in your fork

So your repository already has a few branches. Branches are different versions of the codebase, but on a smaller scale than a fork. You will pretty much always have a "master" branch in your fork, which will usually hold the exact same code as the main repository earlier. This master branch is basically designed as a reference point for the other branches.

For example, you might create a branch called "fix-this-weird-bug". This would be based on your master branch, so most of the code would be exactly the same, but then you'd make changes to the code that fixes whatever weird bug you're chasing. Then you could create another branch that says "add-spiderman" also based on your master branch, then add spiderman... whatever that means. This means that you can create multiple concurrent changes to your codebase, so that when you create a pull request the maintainers of the original repository aren't forced to either take ALL of the changes you've made, or none of them. They can pick and choose which branch to merge.

• Create a "pull request" from your new branch to the master branch of the original repository(not your fork, the real one!)

Basically, a pull request is a request for one of your branches to be merged with a branch in the original repo. This is pretty much the final step, it'll show up on the original repo's "pull request" list and the maintainers of the repo can either merge the pull request or close it without merging.

Phew, so that's that in a nutshell. I don't know if that made much sense to you, but I hope it did. So let's get on to the specifics for the Godot Engine.

In order to fork the repository, go to its GitHub page, and click the button that says "Fork" in the top-right corner.

 This will create a repository called "godot" under your own account name, rather than that of "godotengine". Next, we have to clone the repo. I don't know how to do this with the official GitHub desktop client, but I do know that it's very simple on the command line or with a third party client with GitKraken, so I'll be using the command line for this.

Go to your profile and click the godot repository. Find the "Clone or Download" button, click it and copy the URL.

Now, go to a terminal and type "git clone" and then the URL that you just copied. This will hopefully clone your entire forked repository into a folder named "godot".

Now, you can move into this folder by using cd or something and type "git remote add upstream https://github.com/godotengine/godot" which will make your master branch point to the mainline godot repository. This means that your master branch will keep up to date with the changes that are happening in the real repo, as long as you regularly uses the"git fetch upstream" command.

Next, go back to the original Godot Engine's repository page and look for something to do under "Issues". If you've already got something to do then just continue, but that Issues tab is the tab where all the bug reports go, so it's a nice place to hang out.

Now, create a new branch. You can do this by going to your command line, cd-ing into the folder you cloned the repo into and typing "git checkout -b fix-some-bug-thing". This creates a new branch on your fork named "fix-some-bug-thing", and puts you into that branch. You can check to see a list of existing branches by typing "git branch", and hopefully it'd give you a list of potential branches, one of them being named "fix-some-bug-thing" with a * just before it to indicate that it's selected.

So, now you can get to work doing some of that amazing programming that you're known for. Done? Good! For the sake of completeness, I'll note at this point that you can compile the engine by typing "scons platform=[windows, osx, x11]". In addition, you can add a "-j4" tag to use 4 threads to compile. This will usually make it a little faster to compile, but your computer may slow down as a result because all the processing power is being used.

If you're like me and you don't have gcc-5 installed(I could install it, but I'm afraid that I'll break something) then you can append "use_llvm=yes" to the end of your scons command, and it'll use clang instead of gcc-5, which is usually easier to install.

Anyway, if you want more on that topic there are a lot of very informative doc pages which give you more information than I'm going to here, so in the mean time let's get back to GitHub.

Once you've made all the changes that you want to make to your branch on GitHub, you can run the command "git commit -m "i fixed a bug thing, woo!"" and then "git push origin master", except make the commit message a bit more informative than that to make things easier for the other contributors. Also, if you've made multiple commits and things are looking a bit messy, you might want to rebase. I don't understand this one as much as I do the others, so I'm just going to copy and paste what Remi, one of the project maintainers, asked me to do on GitHub the last time I made a huge mess.

git pull --rebase upstream master
git push --force origin master

Once you've done this, you can go to the original Godot GitHub page, and find the "New Pull Request" button along the top. Press the "compare across forks" button just under the big "Compare changes" header, and make sure that things look pretty much like this:

It should also give you a list of changes below that box. Once you're ready, you can create the pull request with a nice snappy title and description, then it's just a matter of waiting for one of the maintainers to pop in and talk to you about your pull request- even if you've made a horrible mess, they've always been very considerate and patient in my experience. 

Also, make sure that everything is formatted properly, because if it isn't then Travis CI will throw some errors at you. Just hang around for a few minutes with the Travis CI in mind and before you know it, it'll be yelling at you and telling you to put spaces somewhere or remove spaces somewhere else.

If all of that seems a bit daunting, then you're right on track. It's taken me years to even slightly understand Git and even now, I'm not entirely sure about all of it. However, there are other ways to contribute to Godot! You can write documentation if you're not a programmer(you'll still have to use Git though), you can donate on Patreon, or any of the other things it lists on the doc pag about "Ways to contribute".

I think that one of the best ways to contribute is in fact to just make games with the engine. The more examples and support threads there are out there, the higher number of people will feel more comfortable with adopting the Godot Engine as their primary engine and the healthier the eco system will become. Again, this is listed on the actual doc page so I should probably stop talking right now before I straight-up plagiarize that whole website.

Thanks for reading, and I hope that this has been helpful. I'm aware that a lot of this already exists online in several places, but I think that it might be helpful to have a slightly less scary or daunting tutorial somewhere on the Internet, plus I mean tutorials get me a hell of a lot of clicks, am I just gonna ignore that? Yeah, I don't think so, you better believe that I'm MILKING that, baby!

Godot - A Complete Guide To Control Nodes - Buttons

Amazing! We're back, and do I have a tutorial for you. I suspect this one is gonna be pretty popular because I mean- pretty much everyone wants to know about Buttons, so let's go!

I'm sure that pretty much anybody watching this video will use Button nodes at some point in their gamedev experience with Godot. If they don't, then that's strange but they probably should.

So let's move onto the big old Node tree and take a look at what's going on- you might notice that all of the Button nodes are actually children of this unselectable "BaseButton" thing. This is exactly what it sounds like, it's an uninstanceable class which aggregates all of the core behaviour for all of the button Nodes in the engine.

Looking at the documentation, that includes things like some methods like _pressed(), _toggled(), is_hovered(), etc. These are things which every button should have, and you will be able to call on any button. It's pretty easy to figure out what each of these do, so I won't go into much detail on them.

Also, every Button node you encounter will have a few SUPER helpful signals- button_down(), button_up(), pressed() and toggled().

Again- these are very self-explanatory, but they're super helpful. Basically, I would usually put all of the button-press logic into a pressed() callback, and then you can set the "action_mode" to determine whether to emit that signal when the button is pressed down, or when it's released. This just gives you a bit more freedom to make changes later on should you change your mind about the way the button works, so I'd recommend it.

So anyway, let's create a proper Button node and investigate some of this stuff. First, let's take a look at the inspector category known as "BaseButton". The first few properties here are pretty easy to understand, there's "Disabled" which when activated will make the button not clickable and in the case of a normal Button node, it'll also make it greyed out.

There's "Toggle Mode" which basically determines whether or not it's a button that you press once to enable, and press again to disable. Kind of like a check-box kind of thing, if you want that then enable the "toggle mode" property but if not then just ignore it and you're good.

"Pressed" is pretty self-explanatory, but you're probably not gonna be adjusting this one from the Node inspector. Chances are, you'll be using that one in some if statements- like if(button.pressed): do a thing.

I briefly mentioned "action mode" earlier, and it basically determines whether or not the "pressed" action happens when the mouse is pressed down on the button, or whether the mouse is released from the button after pressing it down. This is set to "button release" by default, and for most UI or menus I generally leave it that way. However, you could change it if you feel like it.

"Focus Mode" determines whether or not this button is allowed to grab focus, and if so- how. By default, it's set to "All" which means that you can use the arrow keys or the mouse to select it, much like how we did in the first video in this series when I was demonstrating the "neighbours" stuff under the "Focus" category.

"Click" means that you can't use the arrow keys to select this button and you have to click it manually with the mouse, and "None" means that you just can't focus this button.

Now this one is pretty cool and I'm just waiting for an excuse to use it, but you can set a "Shortcut"- this means a keypress that will automatically press that button. So you could make a new shortcut, create a new InputEventKey and you can look up the scancode to the button of your choosing. This makes keyboard shortcuts SUPER easy to work with.

Also, you can set the "group" of the button. You can't really set this one in the inspector, but in a script you can create a new ButtonGroup object which you can then assign to multiple buttons. This means that at any given time, only one of the buttons in the group can be pressed. It's kind of like radio button selections on a webpage.

So now onto the specifics of this "Button" node, since the things we just covered are applicable to any button- they're all members of the "BaseButton" class.

The first property to notice is "Text", which is pretty easy to deal with, if you want your button to say something then you can type it in here and it'll show up on the button.

There are a few other properties that relate to this text like "Clip Text", which will stop the text from leaving the bounds of the button and "Align" which will designate how the text is aligned.

"Icon" allows you to set a nice little image to appear on the left hand side of the button, or if you don't have any text, you can just shrink the button to make it appear in the middle.

Also, you can set the "Flat" property which just changes the style of the button a little bit, by making it not show up by default.

So, now onto some of these simple button derivatives- first of all the CheckBox. This one is literally just a checkbox and is generally used in combination with some text next to it and some other context.

Next, there's the CheckButton. This is functionally identical to a checkbox, but instead of a literal checkbox it actually has a little switch which you can set as "on" or "off".

Now there's the "ColorPickerButton" which is pretty useful. It basically allows you to select a colour using preset Godot UI stuff just by creating the node. From there, all you have to do is connect the "color_changed" signal, and access the "color" property that it has. This makes things like character selection super easy- if you don't mind Godot's built-in UI too much.

Next, there's the "MenuButton". This is kind of like a dropdown menu type thing, if you click "Scene" at the top it'll produce a bunch of options- at the moment, we haven't really set this up. However, when it clicks it creates a PopupMenu and you can see my last video to get a sense for how to make that work. You can use the "get_popup()" function on it to get the PopupMenu node for all your GDScript customization needs.

There's also the super useful "OptionButton", which is again a node that mostly requires customization via script files. You can add items and link the "item_selected" signal to a script of your choosing in order to determine which one got selected. It's not super complicated to use, but yeah- just play around with it.

Now for the one that I use probably the most(excluding the TextureButton), the ToolButton. It's literally identical to the normal Button node, except it automatically sets itself to flat. That's it.

Now there are only two buttons left, and they're both pretty useful. The first one is called a LinkButton and it's just like when you have a hyperlink on a webpage. This LinkButton is functionally exactly the same as any other button with the signals, etc- it just presents itself as a hyperlink.

Then the last one that I definitely use the most, the TextureButton. Again, it's functionally identical as a button node but it takes in several textures instead of relying on Godot's own user interface style stuff.

It has an "Expand" property which basically determines whether the texture should expand to the full extents of the button size. This is in combination with the "stretch mode", which determines how it expands- whether it tiles, whether it stretches, or whether it keeps itself centered and a bunch more options. Generally speaking, I leave this disabled since I make my textures in something like Aseprite and only load them in via the TextureButton to be displayed at the size I designated in my sprite editor.

But the point is yeah, this is a pretty useful node. You can even set a click mask if you don't want the entire Rect to be able to be clickable. Just load in a bitmap with white as the clickable area and black as the non-clickable area, and then Godot will automatically do the rest. It's super useful for making curved buttons, or buttons that are smaller than your TextureButton Rect for whatever reason.

And there you have it, that's pretty much it for Buttons. As always if you have any further questions then feel free to leave a comment, or join my Discord and ask me there- I'm usually quite happy to be distracted from whatever I'm doing so feel free to make use of that. Anyway, thanks for watching and stay tuned for more tutorial videos because apparently you guys LOVE them, I'm getting so many subscribers it's literally the best thing that's ever happened to me. Anyway, I guess next time I'll do Containers- which is a slightly bigger and significantly more scary topic. I might have to segment that one into two or more videos, come to think of it but whatever. Just enjoy what I've done so far!

Godot - A Complete Guide To Control Nodes - Popups

So, here we are- part 2, which some of you seriously nagged me for you pests.

Anyway, as the title would suggest, let's get into Popup nodes. These are a lot more straight-forward than the messy stuff that I covered in my last video, so let's get going with the base "Popup" node.

You might notice that when you create it, it doesn't actually have any fancy graphics of its own. That's because it really only exists to hold some logic that is utilized by the rest of these popup nodes, but if you want you can add your own logic as children in Sprites, Labels, or whatever you want to put there.

So I'll add a Label as a child of the Popup node just so I can demonstrate some of the behaviour that the Popup node implements. I'll add a built-in script here, too.

I'll also add a simple ToolButton next to our Popup node so that when we press this button, some code will be executed, and we can change this code a few times to demonstrate a few different behaviours.

So by default this Popup node is hidden, unless we call a function specifically to reveal it, which is usually the "popup()" function. If we press the ToolButton with "popup()" in the callback, then as you might expect, it'll reveal the node, with the Label.

There are a few other functions to call here, "popup_centered", "popup_centered_minsize", and "popup_centered_ratio". It'll probably be easier to demonstrate these with some of the other Popup nodes we'll be looking, so I'll wait until then.

The next interesting thing about this node is that it has a VERY useful "about_to_show()" signal that you can connect. This does exactly what it sounds like, and will run the code that you place into the callback right before it shows the popup. This is useful for generating or changing data at the last moment in a nice and clean way, that ensures that you won't open it with old data showing for a moment.

There's also a "popup_hide()" function that is fairly self-explanatory- whenever you hide this popup, it'll emit this signal.

So that's about all for the base Popup node, let's move onto the more interesting ones- starting with WindowDialog. As you can see if you forcibly reveal the WindowDialog node, it has a nice little body, title bar and an "X" to hide it. This is useful if you want to use Godot's default UI, but you can use StyleBoxes to change it up a bit.

So similarly to our base Popup node, this node is hidden by default. Even if you reveal it in the editor and load up the scene, the Popup will still be hidden by default. So we have to call "popup()" on it to make it visible, which we've already got set up using this ToolButton.

So let's look at some of the other functions that I said we'd explore with a more interesting Popup node. First, let's do "popup_centered()". This one will center the node in the middle of the screen, and it's pretty useful. This means that even if we move the Popup node way off-center, it'll still appear in the center when we run this function.

Next, we have "popup_centered_minsize()", and this does the same as above but it takes in a Vector2 quantity for the minimum size of the Popup. I'm not entirely sure why this is useful but in case you wanted to implement that functionality easily, here it is.

Lastly, there's "popup_centered_ratio()", which scales the Popup as a ratio of the size of the screen. This means that it'll appear at the center of the screen, and whatever float you pass via this function will be the proportion of the screen that it'll take up on each axis, relative to the center point. So this means if you input 0.5, every edge will be half-way between the center point and the corresponding edge of the screen. This is very useful too.

So, let's move onto another Popup, and you might in fact notice that there is a child node from the WindowDialog node called AcceptDialog. That's right, we've got another layer to go down! This one is super simple, it basically gives you a pre-defined layout for an "OK" button, a little Alert message and it even gives you a bunch of really helpful signals and methods.

Let's start with the signals, since those are straightforward- "confirmed()" will emit whenever the "OK" button is pressed, and "custom_action()" will emit with the name of the action as an argument whenever we perform a custom action. I'll explain what this means now.

So there's a pretty rad method in the AcceptDialog class called "add_button", which allows you to literally add a button to the AcceptDialog using one line of code- it takes in the text to display on the button, where the button is placed(right or left), and the designated name of the action that you want to bind to this button. So you could bind an action named "explode", and you'd use that "custom_action()" signal that we mentioned earlier to run some code to actually explode something.

But in case that's too annoying for you and you want things to be even easier, there's an even more helpful function called "add_cancel", which just takes in the text to display as an argument and will add a button that hides the AcceptDialog without running the "confirmed()" signal.

So that's pretty nice and I think all you need to know about the AcceptDialog, so let's move onto the next Node.

What's this? AcceptDialog has a child of its own?! That's right, it goes one layer deeper and now we're dealing with ConfirmationDialog. This one is super simple though, as far as I'm aware it doesn't implement any new functionality- it's basically just an AcceptDialog with a "Cancel" button already there.

So let's move on- but wait. Something's not right. You're telling me that there is ANOTHER LAYER to this one?! Yup, I sure am telling you that. We've still got FileDialog to deal with and this one is a little bit more complex. This actually allows you to navigate your hard disk directory stuff and select a file, which is super neat to have already implemented by the engine.

There are a few properties to look at here, the first of which is "Mode". By default, "Mode" is set to  "Save" which means that it'll behave as if it's trying to save a new file. This means that if you select an existing file and click "Save", it'll give you an "are you sure you want to do this?" dialog box.

There are also a bunch of "Open" modes- you can open a folder, you can open a file, many files, or "open any" which I'm pretty sure allows you to select either a folder OR a file.

Next, there's the "Access" property which does do pretty much what it sounds like, it designates what sort of file this FileDialog should be allowed to access. As far as I'm aware, allowing it to access Resources will break it when you try to export, so you can't do that. User data and file system should be fine, so I'd recommend that you use those.

You can add some filters for things like filetypes, if you only want the user to be allowed to select .pngs or something then you can do that super easily.

Similarly, you can opt to show hidden files(though that might be a bit buggy on Windows, weird permission stuff) and you can set the current directory, etc, etc.

None of that is super complicated or unintuitive to use, I'm sure you'll get the hang of it. Likewise, FileDialog implements a few signals- "dir_selected", which passes the path to the directory, "file_selected" and "files_selected" which both pass a String or array of Strings when they're emitted.

Phew, so that's done.

Now we can move onto the next one, PopupDialog. This one is super simple, it's literally just the base Popup node with a panel underneath that corresponds to the size of the Popup. That's genuinely all it is. Easy.

The next one is PopupMenu, which is a little bit more involved. It's basically a context menu, so if you right-click on something and you want the options like copy, paste, select all, etc- that kind of thing, you'd be using the PopupMenu to implement that functionality. The properties are extremely straight-forward, and honestly the signals aren't very complex either- "id_pressed" and "index_pressed" which basically both just exist to point to whichever option was selected here.

There are a bunch of functions here, and a lot of them look pretty confusing at a first glance if you're reading the documentation, but honestly most of these are not complicated or hard to understand. A lot of them are referring to specifics about each entry type, like checkboxes, radio checkboxes(which are the ones where you can only select one option at a time), there's just an item you select and it disappears again, etc. It'd take me way too long for me to step through each function and tell you what it does and you'd probably get bored half way through so I'll leave you to learn what they do on your own. If you have any questions then feel free to ask but I'm confident that you can work it out easily enough.

And lastly, PopupPanel is basically the same as PopupDialog as far as I can tell, so don't stress about that one.

And that is it, I've covered in reasonable detail all of the Popup nodes. You guys asked for it, and I delivered because I'm just that kind. So yeah thanks for watching and stay tuned for more tutorial videos, I guess Part 3 would be on the topic of Buttons- quite a nice topic, I like Buttons, I use them a lot.

Goodbye!

Gamedev Livestreams - Is It Worth It?

I'm sure a lot of you know that I've opted to start livestreaming regularly over the past few weeks. This has kind of been an experiment into whether this is actually a worthwhile endeavour and for me, I can confidently say that it is.

So, here are the advantages to regular livestreaming.

First, it helps to keep your game on the minds of people who follow you. If they see that you're constantly working on a game and they only click it once every week, that's still effectively an ad-spot that you have on their YouTube homepage for free.

Also, for me personally it helps to seperate "casual computer usage" time with "work computer usage" time. Frequently when I'm working I'll get distracted or fail to concentrate and this has been a problem that I've had for kind of a while. However, when I'm livestreaming and actually broadcasting my computer monitor to anyone who is watching, it stops me from just checking Twitter one more time or browsing reddit for a little bit or playing just one more round of Enter The Gungeon- oh wait, it's past 6pm, I guess I'm done working today!

With livestreaming, my brain can easily recognize that this is not the time to start messing around and I actually need to focus and do some work for my lovely viewers.

Another thing is again- personally to me, but I love seeing numbers go up and I love high scores. This means that when I stream, the time I spend streaming is effectively a score that I want to keep high or to beat each day. I don't know how many other people get this but I know that I certainly do feel the need to keep streaming if only to see the number go up, which ultimately means that I put in more hours working each day.

Also, since I am actually working and concentrating, time tends to go by fairly quickly, which gives me a nice dopamine rush if there's a 45 minute difference between the last two times I looked at the clock.

ANOTHER reason why livestreaming is cool is that it gives me a nice excuse to talk to other game developers. Since my throat and jaw tend to start hurting if I do go for 4 hours narrating everything I do, I tend to talk to other people like Florian Himsl of GameSquid or Collin Esplin... also of GameSquid. Either way, it's fun to talk to people and sometimes it keeps them motivated too.

The last big reason why livestreaming is great for me is because I already have a bank of just under 900 subscribers who are alerted every time I livestream so I'm guaranteed a few viewers each time, and as for the big reason-

YouTube algorithms.

YouTube tends to favour content by channels which 1) upload content on a regular schedule, and 2) upload as much as possible and 3) have high watch time. If I create daily content (in the form of a mix of livestreams and actual videos), YouTube will recommend my channel more and more. So far I've been seeing significant success with this, and it's fairly easy to livestream for a couple of hours even on days when I don't really want to.

If I don't want to or am not able to livestream, then I've got a big bank of video scripts just waiting to be recorded and uploaded on that day instead.

Also, due to the very nature of livestreams if like an average of 5 people are watching a 4 hour livestream, that's 20 hours of watch-time just there. If 200 people see a 3 minute video that I release, that's only about 10 hours. This means that livestreams inherently bring in large quantities of watch time.

So ultimately, livestreaming is hugely advantageous for growing my YouTube channel which for me, happens to be my main marketing platform.

So what are the cons?

Well, if you don't have an established viewerbase then you might only get a small number if any viewers. It sounds super difficult to actually make a viewerbase from livestreaming, since usually I pretty much cap out at 10 concurrent viewers and 50-70 total views on the livestream. The truth is that actually gaining a following in livestreaming is really, really difficult and it's much easier to create a few successful YouTube videos to boost your audience and livestream ALONGSIDE a healthy YouTube channel.

Also, it has the potential to distract people who are easily distractable in such an environment. I'm lucky in that most other people don't tend to distract me very easily and I can keep focused even when they're off talking about Tetris or whatever weird topic they decide to start talking about. However, I know that some people really aren't able to do this at all.

It can also eat up a huge quantity of your time. If you have a full-time job, you're well within your right to just be way too exhausted at the end of the day to livestream for another few hours. It is tiring and you need to have a certain baseline of energy to keep your viewers entertained by constantly having somebody talking at any point in time.

Also, some people just don't enjoy narrating what they do. Some people don't like talking. I wouldn't have started a YouTube channel to begin with if I didn't like talking, so again- this is pretty well suited to me, but I don't speak for everyone and I've seen some people on reddit and Twitter actually express disbelief that anybody could livestream such a thought-intensive task as programming or game design in general.

So that's pretty much it, if you've got any questions then feel free to ask me because I'm sure I've not covered everything in this fairly comprehensive topic, but yeah. Thanks for watching and stay tuned for more livestreams for reasons that you can go rewind and listen to all over again. Goodbye!

Godot - A Complete Guide To Control Nodes - Part 1

This is potentially my most ambitious video yet, so hear me out. If you've ever been confused about Control nodes, hopefully this will even things out a little. I'm going to explain Control nodes in as much excruciating detail as I possibly can.

Basically, Control nodes are super useful for all things that are to do with GUI, so things like menus, HUDs, etc.

So, let's start with the base node, just named "Control", and let's talk about how it's different from the much more straight-forward Node2D.

Node2Ds have a category called "Transform" which holds all of the data for where the node is positioned, how it's rotated and how it's scaled. Pretty simple stuff.

Controls however have a category called "Rect" which deals with all of this, and it's a little bit more convoluted. They do have a position property, a rotation and a scale property, but they also have size properties, pivot offset and clip content.

That's because whereas a Node2D is effectively a marker for drawing 2D graphics, a Control node is an organizational thing for UI elements, so it's actually a box. A Node2D behaves like a point with some Transform values, whereas a Control node is a little rectangle with stuff in it.

It's also worth mentioning that you can't position Control nodes at fractional positions, they'll automatically snap to the nearest pixel. I don't know why this is, but that's the way it is, so I guess deal with it.

Now for the really scary stuff and the thing that prompted me to even make this video, Anchors and Margins.

Basically, this whole system ensures that no matter the screen size, GUI elements will always be in the correct positions. Anchors do this by "anchoring" a Control node to its parent object. If the Control node is the tree root node, then its parent should be a Viewport.

So basically, under "Anchor" there are four properties - "Left", "Top", "Right", and "Bottom". These each refer to edges of the Control node's Rect, relative to the parent. They all take in values from 0 to 1, which represent what percentage along the parent rect size to put each edge.

This is relative to the top-left corner, so if you wanted your control node to alway stay in the top left, you could put "Left" to 0 and "Top" to 0. This means that the Left and Top edges are both 0% along the screen at all times. If you wanted to make the bottom-right corner extend exactly to the center of the screen, you could make "Right" and "Bottom" both 0.5, which would place the Right and Bottom edges precisely 50% along the screen at all times.

So this is super useful to make UI elements proportional to the screen, other UI elements, etc. So what does Margin do?

Well, Margin is basically offset. If you want to offset your shape by a factor of 100 in the x axis, all you have to do is set the "Left" and "Right" values to 100 and it'll move those edges away from the left-hand side of the screen by that amount. However, a warning: these values are absolute, so that means if you shrink the screen below the offset value your elements will probably disappear off the side. I would hesitate to over-use Margins, since it can undermine the whole purpose of using Anchors in the first place.

You can also use margin to actually change the size of the Control node that you're using. So if you set the Left margin to -100 and the Right margin to 100, it'll move the Left edge 100 pixels closer to the left-hand side and it'll move the Right edge 100 pixels away from the left-hand side. This is probably useful for something.

So that's arguably the scariest bit explained, now onto another fairly scary bit- Grow Directions.

So basically, as the name would suggest this is to do with the direction your Control node is expected to grow. If you set both the Horizontal property to "Begin" - as it is by default - you might notice that when you attempt to adjust the Right Margin, it stops changing in size once the size gets to whatever its minimum size is.

However, if you adjust the Left margin and try to shrink the shape horizontally as much as you can, you'll notice that rather than just deny any new growth it'll start to just move instead.

This is because the Control node is effectively ready to start "growing" from the left-hand side if you set Horizontal to "Begin". Think in terms of a Label that's holding a line of text. If you start typing, it should expand away from the left-hand side.

I'll be honest here I'm not sure I entirely understand this bit but it doesn't seem essential so I guess my advice to you is just leave this to "Begin" because otherwise demons and evil spirits will haunt you until either you die or you stop worrying about Grow Directions.

Now for something which is awesome but not as terrifying as the previous stuff, the Focus section!

This is to do with stuff like if you press the tab key, or you want to use the keyboard or a gamepad to navigate menus, stuff like that. If you don't want to deal with this then Godot does actually automatically figure out some of this stuff, but it's not perfect and it frequently gets a bit buggy and confusing.

This category is designed to allow you to manually set which button or node to focus if Godot's messing up or you want to move to somewhere that Godot can't really predict. It's super easy, basically if you select a Button you'll get some "Neighbour" properties named "Neighbour Left", "Neighbour Top", etc.

You can set these properties to point to a node that you want to focus on when the player presses the associated direction on either a gamepad, arrow keys, etc. The Next and Preivous ones work in a similar way, if you haven't explicitly defined any Neighbours but you just want a one-dimensional list of buttons to cycle through for example when the player presses the Tab key, then you can set Next to whatever you want to come next if the player has got that button focused but wants to focus another node.

It's super simple, but a super intuitive way to setup keyboard controls for menu systems.

As for the mouse bit, this describes how the given Control node handles the mouse cursor interacting with it. Imagine that you have two buttons on top of each other, so that one is completely blocking the other. Normally, these would both have the mouse filter set to "Stop" which means that if it receives a mouse event, it'll "block" any item below it from actually receiving that event.

However, if you set the button on top's mouse filter to "Ignore", it'll completely ignore the mouse and you'll be able to click on the button below. This might be useful if you want to hide a button from being interacted with temporarily and for whatever reason setting visibility isn't suitable at that time.

Also, you can set the "Default Cursor" that appears when the user is hovering over the button. It's super easy to use but basically you get a big list of potential options which the cursor will turn into when the button is moused over.

Now for the Size Flags, which I've only ever used with respect to BoxContainers or GridContainers so I guess I'll carry on that traditionand only even teach it with respect to Containers.

From what I can tell, it's a little bit buggy and unpredictable but the important things to note are that Fill makes it take up as much room as possible, but sometimes you need to enable Expand too and I don't know why. Sometimes when you enable Expand once, then disable it, then disable Fill, then re-enable Fill it'll also Expand the node to fill up as much space as it can, for some reason.

You can also use Shrink Center which will sometimes center the nodes in the BoxContainer or GridContainer and keep them at their minimum size, but only if they're really feeling like it. If they're having an off day, then they won't.

This explanation sucked but just press them randomly until you get what you want, they're not that important to understand I guess. If you have a better understanding of these, then please let me know.

As for Styles, again, if you have a good understanding or usecase of these then be my guest but custom styles seem remarkably pointless and difficult to use compared to making panels, buttons etc manually in a sprite editor.

So I guess I've explained the essential components of Control nodes, now I'll get into some more specific instances of Control Nodes, starting from the top, which would be the Popup nodes. Thanks for watching and stay tuned for that in Part 2 of this series that apparently I'm doing now. Goodbye!

Godot Is PERFECT For The Ludum Dare

So it's Ludum Dare 42 in about six hours at the time of writing and I've decided that I'd write a little script about why I think that the Godot Engine is perfectly designed for game jams like the Ludum Dare.

Mostly, this is because Godot is just perfect for very small iteration cycles. If you have a solid idea in mind, you can spend probably no more than a few hours to actually get a very basic product up and running.

This means that if you really wanted to, you could run through several different ideas over the course of a day to determine which of them you like the most. Not that I'd strictly recommend doing this, since y'know- time constraints are time constraints, but in case your first idea doesn't pan out so well it's nearly trivial to try out another one.

Also, the engine is super light which means that an average game made in the Godot Engine will only use up about 20 to 30 megabytes. This makes it much easier and convenient for people to actually play your game, although I will admit that the web export system is a little bit hit-or-miss. Usually it'll work great, but sometimes you can run into problems that might warrant encouraging the user to run the downloadable version instead.

Also, here's a personal favourite of mine- particle effects. In short, it's *really easy* to make something look a certain base level of good if you just overload it with particle effects. It's similar to reverb in songs- you might not get very far if you don't know what you're doing, but if you're really clueless or just in a hurry then it'll work out great for you.

Godot is great for particle effects, they run super nicely (even if you're trying to render about 10x more than you should) and the actual particles editor is honestly amazing. If you need proof, then you should know that in my game WARP-TEK which is currently being shown on screen, pretty much all the graphics are based in Godot particle effects in some way or another.

In combination with that, light effects. Creating and adding lights are very trivial and again- they look awesome even if you don't really know what you're doing. These can get a little bit expensive if you have too many so just be careful of that, but as long as you're not creating like 25 of them on the same exact location, you should be good to go.

Also, Godot is excellent for keeping things organized- especially with small projects. In a game jam situation, you're probably not going to want to have spend a lot of time trying to work out what this weird variable does, or where you called this function from. With a combination of signals, multiple distributed script files and the occasional recursive egrep, it's pretty hard to go wrong and get too confused.

Now this last point isn't really in the same category as the others, since I would say that it primarily deals with why game jams are perfect for Godot, rather than the other way around. Godot is a fairly small engine in terms of community and publicity. Unity and Unreal are both backed by astronomical marketing budgets, whereas Godot pretty much only has word of mouth and a Patreon page.

If you really like the Godot Engine and want it to see some extra consideration from other developers, then I'd recommend using it for this upcoming Ludum Dare. Hell, even if you've never used it before- a game jam is a perfect time to try out a new engine in a low-stakes environment. It's good for your skillset and it's good for the engine if more people use it.

Thanks for watching, best of luck in Ludum Dare 42, and stay tuned for more videos about some things which video games are sometimes a part of. Goodbye!

The Dark Side of Rapid Prototyping

As many of my viewers might be aware, my engine of choice (Godot) is very suited to rapid prototyping.

It's very quick and easy to program most types of game logic and usually, actually prototyping something will take anywhere from 1-4 days of full-time work. This is awesome compared to heavier programs like Unity which are a bit more technical and in-detail even when that's not what you're looking for, but that's a topic for a different video.

However, it's also very easy to prototype WAY too much. I know this because a little while ago I temporarily burned myself out prototyping like mad for a month, and then had to take a month off of YouTube and gamedev.

This was partly because I had a bunch of exams, but forcing myself to continue with that stuff even when I hated thinking about it would have put too much strain on my ability to properly revise and prepare for exams.

For context, I made about ten prototypes of games in about 20 days. Needless to say this was just too much and to not make any real progress or not make anything that I can actually say I'm proud of in that time was pretty instrumental to burning me out. I didn't make really any cool graphics or programming tricks or ANYTHING that was actually cool, it was basically just a new layout of buttons and keybinds every time.

That's kind of the problem. I frequently say to people who are looking to avoid burnout that they should maybe not leave graphics right to the end unless graphics are really intensive to create, at which point they probably shouldn't be making the graphics so intensive to begin with. If you don't have something you can look at and feel good for having made, it's going to take a toll on your brain after a while.

That's why with my current game, WARP-TEK, I basically made all the sprites right as I was implementing the entities and even though I had to basically bleach them and apply some cool colour aesthetic, I was still working through the visual aspect at the same time. This keeps me motivated and excited to keep working on this game. Maybe I'm just a particularly visual person, and some people don't value these things as much as I do but I can say from the bottom of my heart that nothing helps me to avoid burnout like creating tangible assets that I'm proud of alongside programming.

Also, it helps with your early marketing if you've got some flashy graphics or a catchy tune to go along with your game from early on, since most consumers also won't care about "woah look at this crazy level generation algorithm".

But either way, what's the point of this video?

If you're making a prototype, you're trying to determine whether the game is worth pursuing. Remember that you're not just trying to make a really rubbish, stripped-down version of a game, you're trying to think about whether or not it's worth even continuing.

Sometimes it's a good idea to create assets alongside prototyping if it helps you to determine the value of the game idea. That's basically the advice.

I didn't create any assets I really liked when I was stuck in prototype hell, but when I came back I made a prototype with a few assets I kind of liked the look of and it motivated me to make the prototype into a full game, which is now known as WARP-TEK. It's better to make sprites too early and have to re-make them than to put off making sprites until your project dies anyway.

Thanks for watching this poorly scripted mess, but if you actually gleaned some useful information from this then I'm simultaneously glad and impressed. Stay tuned for more tightly-scripted videos, in the future, trust me, I promise. Goodbye!

What is and isn't an "Asset Flip"?

Judging by the discussion I've seen on the Internet as of late, I've seen a lot of conflicting definitions of what "asset flips" actually are, and what they are not. Such a seemingly simple and straight-forward concept actually has a lot of nuance and subjectivity built into it.

So first, let's work out where the term "asset flip" comes from. It was coined by Jim Sterling in his Jimquisition video appropriately named, "The Asset Flip". The term is based on the sleazy business practice of "flipping" wares for profit, most commonly houses and cars.

Specifically, flipping, say, a house would involve buying it at a low price from someone who wants to get rid of it, then selling it off again at a higher price almost immediately with little-to-no refurbishment. This kind of practice is actually illegal in some places since it often incorporates some form of fraud, at least from my pretty weak understanding of the situation.

The point is that the concept of "flipping" has existed for kind of a while, and only recently has it been brought into the games industry. When Jim Sterling first used it, Digital Homicide was a prime example, who bought a lot of pre-built assets and "flipped" them with little-to-no changes or thoughtful design to go with it.

However, as with all things there's some grey area. What exactly constitutes "thoughtful design", and what makes a change big or small enough to cross the boundary between "asset flip" and "genuine video game"?

Some people have even gone so far as to declare that Player Unknown's Battlegrounds is an asset flip, since it uses a lot of assets from the Unreal Engine asset store.

I'm not here to set the record straight or anything since I don't really think I'm even slightly influential enough to do that, but I will offer my interpretation of an asset flip. I believe that a game becomes an asset flip when there's reasonable cause to believe that the developer did not put genuine work or effort into the project and rather is attempting to sit on the merits of assets that somebody else made.

This means that I don't consider PUBG an asset flip. While PUBG does use a lot of pre-built assets, I think that the developer has clearly put in effort to make the assets they did use coherent, well-assembled and overall it comes together in a cohesive gameplay experience that a hell of a lot of people enjoy.

Digital Homicide's infamous title The Slaughtering Grounds is something that I would consider an asset flip, since the gameplay experience is far from cohesive, feels cheap and I get the impression that the assets are the only thing the game has going for it and Digital Homicide know it. They're attempting to score a few bucks from people who take a quick look at the competently built assets and decide that they'd buy it.

However, that's not the end of the story for the term "asset flip". There's an effort in some strange part of Twitter to actually re-brand "asset flip" as a neutral or even positive term to describe basically any game that uses pre-built assets. In so far as that goes, I think that's the wrong way to approach things. The fact that "flipping" already exists as its own derogatory term in the real world makes it a thousand times harder to re-brand asset flipping in consumer's eyes.

Also, defining "asset flips" as any game that uses a pre-built asset is kind of crazy and not only de-values the term, it actually shuts out smaller indies who might not be able to afford or otherwise accomodate a full-time artist and opt instead to purchase assets that they like from the Internet. If consumers think that using any pre-built asset is bad(which they pretty much do at this point), then I can't see that ending up as good for really anyone.

So in closing, I've got one more thing to say. I opt to not even say "asset flip" very often since there's a lot of controversy and confusion about what the term even means. I think a more useful and accurate term in most discussions(such as the whole Steam clutter problem thing) is to just say "bad game". Not all bad games are asset flips- in fact a lot of them aren't. Asset flips suck, but they're a subset of the larger issue which is low-effort and dishonest titles getting onto Steam and making things harder for everybody.

Anyway, thanks for watching and stay tuned for more videos that will probably make people mad at me in the comments section because this is a properly controversial topic.