Tuesday, 18 September 2018

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!

Wednesday, 12 September 2018

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!

Saturday, 25 August 2018

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!

Sunday, 19 August 2018

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.


Thursday, 16 August 2018

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!