Thursday, 18 October 2018

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!

Tuesday, 9 October 2018

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 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!

Wednesday, 3 October 2018

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

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