It's not just about making a game. It's about showing the world that F# (and by extension any other functional language) can be used for other things than just "financial applications", total programs and command line utilities.
"Just a StarCraft Ripoff"
Yes. I love StarCraft. I wish I had the opportunity to work on it. Sadly, it's no longer actively developed . But I have my own ideas as to what could be done with the classic RTS formula (especially in the single player department). So while I intend to keep the controls and the feel of units as close as possible to SC/WarCraft/DOTA/League, I intend to throw in some rogue-like ideas to shake things up a bit.
Version 0.1.0 alpha - December 2020
The Tech Demo
I'm not entirely happy with the quality (I've thrown the UI together in less than a month). But I really like feedback, and working on something in secrecy doesn't really feel all that great, so here we are.
I'll keep working on it in my spare time - it's pretty fun. There are many things I want to do (some more obvious than others), but I'd rather not promise anything here.
F#, Monogame, zero C#... so far
I start functional but sometimes performance dictates my choices. And so I use algebraic data types, immutable records, monads, options (there are no nulls), new types, units of measure, abuse tail-call recursion, lazy sequences and so on. But the rendering is completely imperative because all other approaches carry a hefty performance penalty.
As a result, unit behavior (gameplay logic) is almost completely unit tested. It took me a while to set this up, but at least I don't have to worry about breaking functionality every time I add a new feature.
Entity-Component-System - not everything
I'm using data oriented design whenever it starts to make sense for performance reasons (rendering, particles, not-triggering GC). But every time I use it, it increases the complexity of said part, so I'll keep its spread to the minimum.
Why not Haskell
Rendering is the main part where the ability to write imperative code really helps and I'm not sure whether I could do the same in Haskell (but I have to admit I don't know it that well, so if someone can send me an e-mail telling me how to efficiently process 40'000 rendering instructions without tripping up the GC, that'd be great). Also, I'm really happy with F#'s compilation times - 30 sec for the whole project and just around 3-5 seconds for one file change, which keeps development enjoyable.
Also, let us not forget about the C# libraries.. And in a distant future, it'd be nice to throw this into Unity.
Why not C#
Infinite recursion and coroutines. The ability to write suspendable functions (game scripts) without having to worry about the cost of lambdas is what the entire AI code is based on. I don't have to run a Lua interpreter and write class bindings. I can work in the same codebase regardless of what I might be doing. Units of measure help quite a bit with my lackluster math skills.
# Make sure you have SDL installed sudo apt-get install libsdl2-2.0 # Unpack unzip ./marine-king-0.1.0-ubuntu18.zip -d marine-king # Make the game executable chmod +x ./marine-king/Mark3 # Run ./marine-king/Mark3
At this state, I want feedback and ideas, so the alpha is free. If you want to complain or tell me I'm a man of a weak constitution because I didn't use Haskell or that I'll fail because I didn't use Go, feel free to do so via e-mail: email@example.com.
Windows Linux Mac*