| 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. Here's my first F# minigame, a mostly-finished breakout clone: https://github.com/bsamuels453/BreakoutFSharp Here's the second game that uses units of measure - it was supposed to be an asteroids clone but is mostly unfinished: https://github.com/bsamuels453/X81-Prototype Type declarations for the units of measure/data structures I used: https://github.com/bsamuels453/X81-Prototype/blob/rts/X-81_P... |