Posted on 2020-10-02 byVlad Călin
Reading time of 1 minutes
Being passionate about programming, playing video games from time to time and having interest in certain topics (space, economy and indie games), it came naturally at at some point in my life I'd try my hand at developing an indie game.
My idea was to combine space and economy in a simulation game where you play as person at the board of a ship, that has to participate in the economy of a procedurally generated galaxy populated by alien and robot civilizations (with galactic corporations that do various work such as extraction, manufacture, tourism, transportation, banking, etc).
After some planning and deliberation the requirements I ended up with for this game would be:
As an introduction, Godot is an open source game engine that is currently gaining a lot of pupularity in the indie game development space. There are no big hits using this game engine, but it's only a matter of time until there will be.
I picked up Godot a while back, and learned to work with it and it's hierarchical node system in different experimental games I made in the past year. The engine itself was good, and I was able to implement some of the game, the procedural generation module for star systems and planets. But the more code I was writing, the harder it became to manage the whole system and the code writing experience was deteriorating with each script I was creating.
Even if it offers support for C#, it's primary (and recommended) language is it's custom GDScript language which is a Python inspired language that implements some of the language features I love: dynamic typing, introspection, it is interpreted, can use type hints when needed.
But even though at the beginning it seemed like a good idea, the more GDScript code I was writing, the more I ended up fighting it because:
Dealing with all those limitations and issues all the time and it being a UI heavy game I chose to look somewhere else.
Being a web developer at core, I am very familiar with the ecosystem of the web development world and I started wondering if I implementing my game as a web applications would be a good option. After all, web UIs were pretty familiar to me and my focus wasn't going to be elements very specific to game development and features that are heavily relied in regular game development such as physics, shaders and complex animations, but numerical calculations and displaying them in an UI in a way that makes sense.
For web development, I usually spend my days coding React components and interfaces and I became pretty familiar with the tooling, language and architecture in that area. For styling, I could opt for the usual styling for web, SCSS and for graphics, I could use some SVGs because they were offering me the aesthetic I was looking for.
It took me a while to figure out the best way to combine React and Electron in a project so that I can share code
effortlessly between the "backend" Electron code and the "frontend" React code. The main issue here was that
the React code was using ES6 syntax and features and before running it gets transpiled by
babel to browser compatible
code, while the Electron code was written with
commonjs. This made importing the same file from both
projects cumbersome and harder than it should've been.
But after some deep diving in webpack, babel, typescript and some other tools, I managed to make them play together well. The only part I'm concerned about is building for Windows, but when the time comes most probably I'll just spin up a Windows VM and build everything in there.
I tried other game engines as well. I gave Unity a go but I found it too heavyweight for my needs and its 2D and UI elements hard to use. Other engines I tried to fiddle with were Cocos2D, Defold, Game Maker and even PyGame.
But in the end, learning from scratch another tool for this project wasn't an option, at least an option I was not comfortable choosing because my priority at this moment was building, not learning a new technology from scratch.
And learning a tool that is only good for game development isn't something that sits well with me because I don't plan to switch my career to game development anytime soon or rather anytime at all. So I would be better off choosing a tool that I can use in future at my job is way better than learning a singular tool for a specific purpose, more the less if that tool is not the best tool for the job.
I looked around to see if game development in Electron is a more common idea than I thought but I haven't found anything in that aspect. When people start working on building a game, they go for the standard tools in the industry: the popular game engines.
But sometimes we need to step back, gather the requirements, assess our needs in order to choose the best tool. And sometimes, counterintuitively, the best tool isn't the more specialized one or the one with the most advanced features, but the tool we can move faster in.
We also need to make our current choices based on the direction we want to pursue and try not to spend too much time and too many resources on something that doesn't benefit us in the long term.
If you are curious how the game looks like in the current state, here is a screenshot of it: