Heya!

I’d like to share my experience of developing and releasing a chess career simulation game that I started in summer of 2022. It released couple of weeks ago and for such a niche title, the reception has been surprisingly positive.

The background

I’ve been using Godot for almost 10 years! Incredible.

My first ever projects were point and click adventures in AGS engine. When I decided I needed a more versatile engine, Unity seemed like the only option at the time. It felt slow, bloated and unintuitive. I struggled with it for a couple of months, until a friend mentioned a small open-source engine he was using. Soon enough I was dipping my toes into Godot 2!

The engine came a long way, and I grew as a gamedev with it. I wanted to share some things I learned along the way.

The Start

My latest game started as a thought experiment: what would Football Manager for chess look like? This was more than 3 years ago. Godot 4 was still in development and breaking right and left. I didn’t mind it much as I could always find some workaround. My effort to use it while it’s still in beta brough a nice surprise: the game was featured in Godot release blog posts - valuable source of new wishlists.

I pivoted and changed the design of the game a lot in the first year or so. The FM for Chess idea just wouldn’t click and there was nothing to fall back on as the game was discovering some new grounds. It ended up more as a chess career simulation than a manager-like game. But there’s something I stumbled upon that worked brilliantly: the overall architecture of the game.

GDScript or C#? Yes!

Game architecture is an advanced topic that doesn’t get the treatment it should. It’s at the root of your game. It’s also something that’s smart to develop on a case by case basis. If you want my advice: whatever you choose works at the start. Do it. Then be ready to rethink it and adjust it as you understand what your game needs. Generally, something approximating Vertical Slice Architecture works the best with Godot. Look it up!

My situation was peculiar: I like GDScript, but I use C# professionally and successfully in my day job. What to choose? There’s nice chess libraries out there written in C#, but GDScript is so concise and integrated in the engine that I didn’t want to let it go. It didn’t take long for me to start wondering: Why not use both?

I made a small prototype to test that idea and found no reason to back off. As my game is 99% comprised of Control nodes, I use d GDScript for ‘frontend’ part of the game, and kept the world simulation, chess logic, and heavy lifting for C#.

Fun fact: probably my biggest gamedev flex is when Reduz, creator of Godot, called my madness of Control node tree ‘mad skills’. reduz-tweet

If you want to know how to mix GDScript with C# in a same project, I shared a small guide about it on what was Twitter at the time.

Here’s a high-level flow of my architecture:

Godot (GDScript, Control Nodes)
              │
              ▼
       Thin API Layer (C#)
              │
              ▼
Core C# Projects (Godot-agnostic)
    (Simulation, Domain Logic)

This approach naturally enforces some good practices. You’re pushed to separate the view layer from the logic layer. In a UI heavy game it’s a nice way to model things.

It does have disadvantages, both in terms of code and performance. Those problems come from the same source: moving data between C# objects into GDScript Variants. Luckily, in the type of games I’m making it was never an issue and I’d bet majority of games wouldn’t feel it. It also adds the mapping overhead, you need to prepare the classes in C# and (optionally) map them to types in GDScript, which I do recommend.

As much as I liked this approach for my game, there’s only a certain type of project where this is a smart way to architect your game. I’d recommend it for any kind of UI-heavy sim, strategy and data-driven games. I wouldn’t recommend it as a one-size-fits-all solution. As a matter of fact, my next project - Golden Idol inspired detective game, is written in pure GDScript. Not a lot of state to handle there, so no need for this overhead.

As a quick aside, I don’t get why Sports Interactive picked Unity as their engine of the future for Football Manager series. I am not surprised they had to delay it and I won’t be surprised if the game runs poorly. Godot Engine was the right long-term choice there!

The Tooling

Managing 2 languages needs a solid toolchain. VSCode is great for this kind of workflow. It’s easy to search for the GDScript and C# bits. There’s plugin support for both languages and if you’re also dealing with translations/csv files it becomes a real workhorse. I have it opened at all times.

Due to better integration, I still coded GDScript parts from the Godot editor and the C# parts from Visual Studio. Beggining of this year I switched to Mac and this made me switch to Rider - I like it even better than VS on Windows.

Other than that, I use SQLite as the DB and Obsidian for tracking everything about my project - it’s a glorified markdown file editor, like a small, personal wikipedia. I had my design docs, trello boards, moodboards and plans there. Very powerful and free!

The Results

After about a year or so I posted a small trailer of the game on r/chess and it went viral. The excitement this post generated probably fueled me for the next 2 years! Almost 3 hundred comments and 5k upvotes is no small feat.

The conclusion

Was the game a success? It would translate to a minimum wage (somewhere), if looked at only commercially. But it was a huge success in terms of growth: I became a better programmer, designer and even started developing the business side of my gamedev journey. More information about the release of the game can be found on my release blog.

Thanks for reading, Godot was a big part of this journey. I’d like to see more people adapt or at least consider the marriage between C# and GDScript. If you have any questions, shoot!