How was your experience with F# and game development?
I like F#'s syntax so much more than C#(plus some stuff like pattern matching are so nice). However I feel like FP isn't effective for gamedev.
> However I feel like FP isn't effective for gamedev.
Oddly, in my limited experience, it is very effective.
I can't say it's the right pattern for every game but for the current roguelike I've been working on in my spare time it's been the best thing since sliced bread. I use the Reader and State Transformer monads in a pattern similar to the Elm Architecture that results in my engine being completely deterministic.
This allows me to dump all of the initial state of the game and all of the serialized inputs to it. I can then take that dump and step through that entire game session. This is great for debugging with friends and stuff: when they encounter an error or something they don't like they can just send me the dump file and I can replay their entire session. It's been pretty cool being able to do that.
Another thing I didn't understand at first was that immutability seemed like an egregious waste of resources. It might still be for some applications but it has much better performance characteristics than my intuition had led me to believe... because structural sharing. You can have this big blob of state that looks like it's being copied every where but it's not -- under the hood you're actually sharing 99% of the previous state and not copying anything.
It's not likely you're going to be writing a bleeding-edge rendering engine in a pure FP language on any current generation hardware platforms but you can get quite far with it.
The biggest gains I saw had to do with the units of measure and state management, with a big emphasis on the latter.
Nearly none of the traditional game-based OOP design patterns map cleanly into F# (or any functional lang for that matter) - I often had to get creative but the results were very interesting.
Take an OOP based game for an example; tracking where your game state is, how it's being mutated, and figuring out exactly what entities have been mutated can be a nightmare. With F# I ended up with a single large data structure to store the game state, and because of F#'s pedantic immutability, it's very easy to find where that game state is modified.
The only issue with the scheme above is that there are some cases where you NEED to store game state as a variable captured by a closure. That might sound really awful, but in practice variables captured by a closure are always read-only, so unless you're replacing that closure, you don't have to worry about some weird mutability sneaking up on you.
You can do imperative and object-oriented programming with F# :-) Here's an example with a Windows Forms button which modifies a string variable on click:
let mutable greeting = ""
let btn_say_hi = new Button(Text = "Say Hi", Parent = frm_main)
btn_say_hi.Click.Add(fun _ -> greeting <- "Hi!")
Curious about this also. Last time I took a peek at F# I wanted to make a simple game, but all the compatible tools seemed like C# tools that allegedly work for F# as well. Wound up using Lua/LOVE instead.
That actually looks really indispensable when you're working with units! I wonder if functional langs without this feature might be able to implement it via macros somehow which only run at build time...
I think you can do it in most reasonable statically-typed languages, with a little care. Scala makes automatic conversions a bit easier because it lets users specify them. Like C# actually. You could probably do UoM in C# too.
the developer experience isn't great, it's complicated to install and to get started with and the ecosystem related to web development is quite poor. That's not the case for F# and I really really hope it picks up steam. ML languages are really great when it comes to data modelling, domain driven design, writing algorithms and stuff like that. they are a nice compromise between pure FP and OOP.
I think the only complicated part of the developer experience is something Javascript developers have become accustomed to: multiple compilers and complicated build tools. But you get over it.
There are some nice tools as well: merlin, utop, and friends.
As to the ecosystem, I beg to differ: the ocsigen suite of tools (lwt, server, js_of_ocaml), Core, Bucklescript, etc. They're all amazing, well documented, and open source.
I think both languages are quite nice honestly. F# has become a lot more attractive now that .NET is more readily available on more platforms. I hope it gains more steam too!
> I think the only complicated part of the developer experience is something Javascript developers have become accustomed to: multiple compilers and complicated build tools. But you get over it.
With Javascript all that bullshit is optional, it's not with Ocaml. The JS asset pipeline is totally irrelevant here, and certainly not a good example of how an ecosystem should be.
> But you get over it.
no you really don't, and you shouldn't.
> As to the ecosystem, I beg to differ: the ocsigen suite of tools (lwt, server, js_of_ocaml), Core, Bucklescript, etc. They're all amazing, well documented, and open source.
Now Compare with .NET ecosysem . I was looking for a good MongoDB driver in Ocaml the other day, didn't any good one.
It's going to be hard for any language to compete with the .NET ecosystem due to the hundreds of millions of dollars of funding it gets from industry compared to OCaml.
There's still room for both and they're still both great languages. That F# is quite similar to OCaml is a good thing... it means there must be some good ideas in there. :)
With BuckleScript available now, you always have the option to reuse any existing JavaScript libraries with some simple bindings. You can even deploy to node.
I did a small video game in F# using unit annotation and was shocked at the number of bugs that unit annotation picks up at compile time.
If you work with a lot of unit conversions (pixels, inches, whatever), I highly recommend giving F# a shot on a small project.
Unit annotation + access to the .NET ecosystem has made this language a personal favorite for any project heavy with numbers.