This post was initially an issue in my newsletter Wannabe Indie Gamedev in which I try to document my way of learning, creating and publishing video games. I'm a .NET Developer, and try to aim my articles at PRO crastinators, wannabes, dreamers and depressed developers like myself ;-) But if you find this article good, please subscribe :-)
If you’re familiar with Git (or version control systems) you can skip this part.
If not, let me convince you that you actually need one, even if you are working solo.
They say there are multiple phases of maintaining your work.
Phase 1 is not maintaining your work at all.
In Phase 2 you get to the conclusion that you need to do some changes that you might want to reject at some point (if you consider them a waste of time), so you make a copy to have a backup.
In Phase 3 you stop trusting your hardware and decide to copy everything to your cloud storage.
In Phase 4 you are fed up with how time-consuming managing this is and start thinking about how other people are handling this. You learn some buzzwords, try to implement them to what is already there, get it to make it work with your multiple folders on Google Drive ;-) I’m joking, of course, this is the absurd route for not using version control systems.
And yet, some people still think it’s overkill, even if they hear that it’s a basic tool for software teams. And although it’s crucial for people working on one project, as is keeping your work in the cloud, version control has a benefit I want to focus on and that is the ability to re-track your progress.
It sounds trivial, I know. But let me tell you a story.
A year or two ago I tried to learn Game Maker 2. It’s simple, nice to use too, a basic tool I wanted to start with. It also has a lot of tutorials. The problem is, I tried to use Git to document every step of my learning process.
- Create an empty project. Commit.
- Add an element. Commit.
- Prepare an executable. Commit.
- Run game. Commit (if there are my changes made in the process)
This way I could easily take notes for future tutorials, for example. Or just to remind me what I was doing before. When you work on your projects and sometimes have too long breaks you might want to start with a solid recap of what you have already done. The problem with most generators is that they don’t care much about readability. Perhaps I expected too much from an application that aims for making game development easier for non-programmers? Perhaps I did. But it didn’t help me out much and it discouraged me from learning.
My first look at the .gitignore file showed me the following:
# Godot-specific ignores .import/ export.cfg export_presets.cfg # Mono-specific ignores .mono/
Quite promising, given the fact that I won’t be using Mono.
But let’s not stop here.
The project is pretty much text-based, as if it was prepared to modify every file by hand, and not by the editor. The project.godot file, the configuration file of the game is written in a win.ini format. Making it not only easy to read but also not hard to modify.
The tscn files, which are the scene files (more on that on other occasions) also text with communicative names and syntax.
All that is leading me to the conclusion that picking up the Godot engine is a very promising start.