Reflections of a novice videogame developer
I released my first videogame Machine Gods a few weeks ago. You can play it here.
A little about the game — it’s a 2D sidescrolling platformer game with some shooting based combat. The game was made with GDevelop, and I hand drew the art for the game. Here are my final reflections on the game, both the finished product and the process of making it.
Expectation vs Reality
In my first devlog I detailed the inspirations I had for Machine Gods. If you read over it, you’ll find that my original intention was to make Machine Gods a roguelite platformer akin to Risk of Rain. Looking at the final product, how well did my vision transfer to reality?
Gameplay wise, Machine Gods handles much like Risk of Rain. The platformer action and shooting mechanics are simpler, but roughly the same in principle. However, to finish the game, I had to cut a lot of planned features. For one, Machine Gods (the finished product) isn’t a roguelike. The game’s structured with pre-designed levels; more like a traditional platformer (a la Super Mario Bros) — you progress from one level to the next, with a bit of narrative sprinkled in. With the roguelike elements of the game gone, the RPG elements were cut as well. There are no items to collect and no attributes to level.
In short, the final product was very different from what I had originally planned. Why were these cuts made?
The first reason is that there was a large gap in the development of the game. I laid the groundwork for the RPG/Roguelite features of the game over the summer. When first semester started, I found myself pulled too thin between school, college applications, and extracurricular activities, and took a break from working on Machine Gods. When I returned, I found that I simply couldn’t understand much of the code I had written.
If that sounds like my negligence or stupidity to you, you’re right — I didn’t document any of my code since it was a solo project — but there were also legitimate engine limitations inherent to GDevelop that caused this, which brings me to my second reason: GDevelop has no true object oriented features. In fact, it barely has any data structures at all; the platform barely supports arrays.
Consider the following development obstacle. I wanted to add items to the game that the player would be able to equip, and would perform an action when the player used them. A typical implementation would be to create an interface representing the properties of all items, and then have child classes representing specific items. These child classes could then have methods detailing what they do when they’re used by the player.
GDevelop has no such OOP features, so I ended up implementing several arrays detailing each item, it’s name, it’s cost in the in-game store, etc. For the actions that the items performed, I had to settle for an incredibly unelegant implementation — the game loop would check to see which item was equipped when the player pressed the use key, and then it would execute a predetermined script that would execute the item’s action. Basically, a giant switch statement with hard-coded scripts for each item. GDevelop doesn’t let you pass in arguments to functions either, which limits the effectiveness of this approach even further.
To make all of this worse, GDevelop’s documentation is basically nonexistent. The developer is some French college student, and half the posts on the support forum are in French.
This was my first videogame. When I started developing it, I figured using a drag and drop interface would save me time and headaches. My intuition now tells me that using a code based engine would have been easier — I haven’t tried both ways, obviously, but I’m in the process of learning Unity right now and it seems like a far better platform in every regard — the C# scripts it uses allow for object oriented design, and the amount of forums and documentation that Unity has dwarves GDevelop’s.
Final Takeaways
1. Use the right tool for the job. If you’re building an RPG or Roguelite, you’ll probably need OOP features — plan accordingly.
2. Document your code! You never know when there might be a gap in development.
3. Do your research on a platform before you begin a project using it — specifically, check to see that it has good documentation because you’re definitely going to need it.
