Pre-jam post #3 - The tools

Are you excited? Are you? I know I am! The jam officially starts tomorrow, but considering its nature, I might go ahead and not cheat a little by getting started tonight. But first, one more (and last) presentation post, before I can eventually start the “dev” part for this devlog.

What tools I’ll be using?

As mentioned yesterday, I’ll be using a mix of tools I’m comfortable with, and some others that are new to me. After all, I did say I wanted to learn during this jam, so…

Game engine

This one is always the big question, and in the case of this jam, is going to be where I’ll be learning the most, I think. In my last jams and projects, I’ve been using Unity, like a lot of people I suppose. That said, I plan on doing a 2D game, and while it’s possible (and easier than ever) to do so in Unity, that’s still not its forte.

On the other end, my little brother told me about Godot recently, and I’ll admit I was a bit reluctant at first. Why? I honestly don’t know. Probably because I’ve been burned with a couple of promising engines and tools in the past, promising the world and its moon, then dying silently of prolonged inactivity, or changing their business model and/or technology enough to make my project irrelevant. But after reading a bit more about Godot, I decided to give it a spin last week… then decided I would give it a longer spin. It’s lightweight, easy to use, free on all accounts and it seems to have a great community. And I particularly like Python, so GDScript seems like a natural fit for me. All in all, I’m confident.

From what I’ve seen, the code editor in Godot is nice, but if I need to step it up a bit, I’ll certainly use Visual Studio Code.

Assets

As I mentioned in an earlier post, I’m a programmer, not an artist. In the last couple of years, I bought a couple of asset packs, mainly through Humble Bundle bundles. I’ll rummage through them to find assets looking and sounding like what I need.

On the graphics side, I’ll probably use Paint.net if I need to retouch things. If I need to create things, then… I seriously don’t know. I used Hexels in a previous jam, but I’m not sure it will apply well for this project. I guess I’ll see.

For the audio, if I don’t find what I want in the asset packs, I’ll probably experiment with BFRX to create sound effects and the particularly surprising Autotracker-C for its automagic music generation.

Source control and Project management

It’s not because it’s “only a jam” that I should not take this project seriously. And any serious project needs some sort of source control. There’s no way I’m just keeping undocumented backups in a vulnerable folder somewhere on my disk!

While there might be a source control system more adapted to game development, I really like how git works, and what more, it’s even supported as an official plugin in Godot. Now, to decide on a backend…

I considered GitHub and Bitbucket and decided to go with the latter. First, because I’m already using it heavily for work, so I’m aware of some of its features, and it will not be lost time to dig deeper. Also, I compared both’s project management tools, and I prefer how Bitbucket handles things. Considering I’m aiming for a private project while on a free plan, I came with this little comparison table:

While there are a lot more differences between the two, what’s listed above is what is important for me.

What’s next?

Now that I’ve written much about the project, it’s time to start getting down to it. I’ll start by some setup (e.g. create the Godot project and Bitbucket repo), then I’ll probably dig right into the battlefield scene. I’ll keep the UI stuff (shop and garage) for a bit later.

Any thoughts about those tools? Anything you would change? Something I didn’t see or think about?