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:

• implement some degree of procedural generation for the world, civilizations and corporations.
• it will be an UI heavy game, similar to Stellaris
• I will need to implement some AI for the civilizations and corporations to advance the game: making simulations of economic decisions based on relationships, profits and other incentives.
• the graphics will be in a flat style (similar to the Kurzgesagt style) because the purpose of this game is not graphic fidelity or realism, but a fun way to simulate an economy in space, while offering the player a goal/purpose.

First attempt with Godot

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:

• I wasn't able to wrap my head around their class implementation and reusable modules weren't easy to pull off. This hurt me the most, because I wasn't able to implement OOP designs properly and I had to hack a lot of things to work. For example, a clean way to work with class and instance variable/methods and also implement dynamically generated classes was a pain.
• Even though it was inspired by Python, a lot of functionality was missing and classes/methods that did the same thing as in Python had different names, which created more friction than it should have.
• The only IDE/code editor was the one provided by the engine itself which lacks a lot of the functionality I needed. This was probably the biggest turn off for me and the reason I chose to look for an alternative to Godot in the first place. The intellisense was off and not working most of the times, the customization options were poor and there were some bugs that were pissing me off because they disrupted my work flow quite a lot.
• The UI had some very weird design choices implemented and there were some known bugs here and there that were preventing me from achieving the results I wanted to. Achieving responsive designs to accommodate different screen resolutions wasn't intuitive at all. The styling options were limited (I can't even consider it proper styling because the most you could do was either coming up with textures for each state of each UI element, or fall back to colored rectangles, which were very limited options for my ambitions). To not talk about UI animations and transitions, the only option being managing the transitions from code. Dealing with more than two states at the same time for the same element was more trouble than it was worth.

Dealing with all those limitations and issues all the time and it being a UI heavy game I chose to look somewhere else.

Looking at something familiar: web technologies

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.

What about other game engines?

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.

Conclusion

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.

What do you think? Did I make the right call to choose Javascript, React and Electron over traditional game engines?

If you are curious how the game looks like in the current state, here is a screenshot of it: