With my interest in open-source software, it was only natural that at some point, I would investigate open-source game engines. While the engine environment I am most familiar with at this point is Unity Engine, its software is closed and proprietary. While tools can be developed for it, I couldn't ever go into it to change the software for my needs.
Godot is an open-source game engine that is considered best optimized for two-dimensional games. I had heard of it before, but never had the time to really get into it. I decided that for my first project, I would make some sort of puzzle platformer, as that is a game format most people are familiar with.
The actual direction of my project ended up going slightly differently. When talking with one of my professors (Jonathan Ferguson, who runs the Free and Open Tech Club at Champlain College), I mentioned this project. In talking about what I planned to do, I got asked why a character would have a "look" function-- the ability to look further past the screen to see what puzzles or hazards are ahead, like you can in many popular platformer games of the day, such as Hollow Knight (one of my favorites). I floated the idea of a character who sends a small pet to look ahead for her, and as my planning progressed, this ended up being the main mechanic I focused in on.
The player character is a little plague doctor with a very smart crow friend named Omen, though I did not get to a stage where I could add any story elements to this version of the demo.
The project itself can be found on GitHub here. What I've done in the first three weeks is somewhat rudimentary, due to the amount of research and troubleshooting I ended up needing to familiarize myself with a new game engine. The way data is organized inside the program is simpler than in many other game engines, but that did not make learning is easy for me.
As a whole, Godot Engine is organized as a tree of various nodes. These nodes may represent different levels of the game, objects inside it, or components of those objects. They can be moved, called, and activated or deactivated with function calls. And while any class inside Godot is a node, most things in a game that can be seen are called... scenes.
Here's an example from this demo. My player character (the plague doctor) exists as a Godot scene object in the project hierarchy. I placed her in this level by instancing her in as a child of the Godot scene object that holds this level design.
The crow that the player character summons up is also its own Godot scene, called as a variable when the correct key ("up" button) is hit. The trickiest part of this project, for me, was getting the camera to follow the crow while he is out, and snapping the viewport back to the player when the crow is called back in. The way to do this that was successful for me was to have the crow have its own "Camera2D" node, and deactivate the one attached to the player whenever the bird was summoned. Godot has an event system in which signals can be sent from any node to another object, but it can only connect signals to objects in the same scene. The crow only exists when called, and he is his own scene file, so I could not attach a "revert camera" signal to him that way. The hotfix for this was to have the input command to send the crow back turn off his camera node before deleting him, while the player character's script reads the same command as a sign to reactivate her camera node and allow her to move around the scene again.
Here is a short demonstration of the demo in action:
The game ends in this case because the crow flew far and hit a bounding box meant to kill the player if she falls through a hole in the stage.
Godot engine has support for C and other languages, but also has its own languages. I used the text-based GScript for this project, but they have a visual scripting language as well that resembles the blueprints system used in Unreal Engine.
If you have any interest in the Godot Engine, I highly recommend using their tutorial and documentation page. I started here and worked my way through the early pages until I was comfortable with the general setup, then went through documentation as needed when I needed to know what the systems in place were for more engine-specific things like camera movement and scene loading.
As this project is licensed under the MIT license, it can be used, redistributed, edited, or even sold as the user sees fit, so long as a copy of the license is included with the project. It does not have the property of "copyleft"-- it does not require that iterations by any parties hold the same license, or any attribution to the original creator. I chose this license largely because the Godot project is already under this license, but also because after thinking about it, I decided that if someone really needed my two one-framed 32x64 plague doctor sprites, they can use them. If I felt very strongly about this for a later version, I could always publish another version under a different license.