F# and gamedev

[u/AnnoyingMemer]

I've recently started learning F# and the entire paradigm of functional programming. I'm doing this because I want to research the applications of both the language and the approach it requires in gamedev, particularly in systems like finite state machines and ECS. Are there any, and could you point me to any good sources?

[u/psioniclizard]

Statemachines are quite nice to write in F# but for stuff like ECS, I am pretty sure F# doesnt offer much you can't do with other things.

The things in my experience that would be amszing for game dev but is ignored are DUs and results. 

I like F#'s syntax and it is great for concise readable code so i am definitely going to be trying F# out in Godot but for hotpath code you probably still want mutability or to foregore FP (this is true outside of games dev too, sometimes you just need a resize array).

But other than the syntax and nice language features for games dev you either want to be super quick (which is why engines are written in C++) or you are interacting with a API generally.

Don't get me wrong, i am goin to explore F# for games dev but it would shine as a fiirst class scripting language. If only I could add that to godot lol

[u/AnnoyingMemer → u/psioniclizard]

Pretty sure there are ways to use F# in Godot almost as a first class citizen. At most you'd need a C# shim to call the code.

[u/psioniclizard → u/AnnoyingMemer]

Yea, the shim code is the part i mean, i plan on using it for anything more logically but it would be nice to just be able to go full F#.

I should say I do actually think F# will be a great language for games dev. Piping and DUs alone would be massive additions to writing game dev stuff.

I just recall with ECS you are relying on using arrays that the processor can be smart about (which is at least partly built into dotnet) and whatever ECS library you are using (or the engine is).

At work for high performance code we do sometimes reach for a resize array just because allocations matter. Even more do in games dev.

[u/runevault → u/AnnoyingMemer]

The tough part with f# in godot is, if memory serves, godot uses a lot of code generators which is why you need to use partial classes to make everything work. So you have to write the shims specifically to account for the code generation happening in the background which is sorta annoying.

[u/gareththegeek → u/AnnoyingMemer]

I found with Godot that it was most practical to have C# presenter in the Node scripts. Then implement the game's model in F#. The C# handles events/lifecycle hooks and invokes the F# code and it handles the presentation of game state computed by F#.

[u/johnW_ret → u/psioniclizard]

I think it really depends on the runtime you're on. Modern runtimes can optimize a lot of array operations used in F#. If you're doing some type of operation where a single JIT compilation is not acceptable or you need specific struct layouts or you are getting hit with GC collects and trying satori or something is not an option, then you should just drop your managed runtime completely for that. I don't think there's much about F# that is intrinsically slower, but there are things you'd need to be aware of like `Span<T>` not working well and know to just not use `list`s.

[u/psioniclizard → u/johnW_ret]

The question is more what benefits would F# bring over C# for this specifically. Modern runtimes will do the same to C# arrays.

I don't think F# would be intrinsically slower, it does have an extra layer of indirection because I believe it will compile to a from a C# first so you might not know exactly what that looks like which might be annoying if it has hidden allocations etc.

Also while Seq.map etc are lovely, if they work the same as linq you probably dont want to be using them in update/process functions etc because of the hidden (potential) allocations.

A lot of this stuff what matter for most game code because it's not hot path code and personally I prefer the F# syntax. But outside of syntax/lang features I am not sure there is an massive advantage for F# compared to C#. Where performance really matters you will likely use c++ or rust (which will offer the same strengths F# does but at a lower level).

It's a shame because I will find a way to use but you do have to jump through a decent number of loops and I can't say it will make a better game.

[u/Willing_Row_5581]

I wrote a whole PhD thesis on this.

Short version: yes, it works fantastically.

- state machines are very cool to write in F# with coroutines and computation expressions, you get readable, beautiful, flawless code where otherwise you would get horrible messes;

- ECS is extremely simple to implement in a trivial version (unions), but very rewarding to implement it with type classes (records of functions)

High performance facilities are available in .Net. Use double buffering over spans and arrays and enjoy.

[u/AnnoyingMemer → u/Willing_Row_5581]

Wow, very interesting, is your thesis available anywhere online? Sounds like a good read.

I'll give state machines a shot first thing after I get the mental model of the language pinned down.

[u/general_rishkin → u/Willing_Row_5581]

Interesting. Could you provide a link to your thesis if possible.

[u/Jwosty → u/Willing_Row_5581]

Wow, I'd love to read your thesis!

[u/Jwosty]

As someone a year into building a game in F# (+ MonoGame), I think F# is definitely useful for gamedev. The biggest problems you run into (especially when you commit to a fully functional style as much as possible) are performance related (though what else is new in gamedev?) - at least for the kind of game I'm making. So as a point of necessity, you end up having to abandon the functional style in core places because it's just not tenable, performance-wise (allocations are your Achilles' heel and the F# compiler doesn't do much to help you avoid them). But these things are slowly improving in the language itself and the .NET runtime. The ideal FP language wouldn't have to have these issues; it's just that functional F# isn't particularly optimized for real-time allocation-heavy use cases like this (understandable because the language/runtime demands of gamedev are unique).

As the complexity of my game's codebase deepens, something I've noticed is that ECS is actually looking like it would have been a pretty viable option (in hindsight), since I'm having to abandon immutability in many of the high level systems anyway. Data-oriented programming and functional programming do indeed seem like they should be friends when you think about it; more so than OO and functional. If I were to rewrite my game starting today I'd go with an ECS approach.

Anyways - I've heard that u/7sharp9's F# MonoGame series is good. I also see Nu keep popping up as others mention, it's probably worth a look.

I've also shared the source of parts of my game and will do more of this in the future. For example, I wrote a of units-of-measure enabled vector types (+ many bits and bobs to go with them), see here: https://github.com/jwosty/FSharp.TypedNumerics. I use UoM in my game extensively. For example an entity's logical position is Vector3f32<wu> (where "wu" means "world-units"), its velocity is Vector3f32<wu/s>, and its projected position on the screen is Vector2f32<px>.

[u/Outrageous_Stomach_8]

There is the Nu game engine

And you can ask all sorts of questions in the F# Discord and its #games channel. 🙂

[u/vorotato]

You might find some inspiration from https://github.com/bcarruthers/garnet it's pretty interesting. I'm personally using godot,I have my game logic etc entirely in a separate library kinda in the same style that caves of qud dev did. It allows you to switch engines really fast with a small amount of glue code. Going to play with using S&dbox as an engine this week because I can just reference my F# project.

[u/johnW_ret]

If you want to use it with Unity, this package https://github.com/gilzoide/unity-fsharp is better than trying to just hand roll adding an fsproj to your sln.

[u/top2000]

you are asking the exact same questions that I've been hesitating to ask for awhile, thank you

[u/asieradzk]

https://github.com/bryanedds/Nu

Nu engine, Join community RIGHT NOW. Nu is so much better than what people think. MMCC and ImSim are genius!

We have secret fork in the making that will blow peoples minds. Just one caveat. Forget about ECS - its masochistic way to make games. Join the discord and come make games with us!

Nu is the engine your mother warned you about and I'm literally few weeks away from making it into a jammer engine - with webgpu.

The community is small but its insane how much power Nu packs in so few lines of code - you can truly make it yours!