next »

[increpare]

the majority of GC issues I've seen is just the case of programming error, generating garbage unnecessarily.

That's a fair point.  However, if I were to say instead, 'space/time leaks are a major issue (even if they can be put down to 'human error', they're still problems)', I imagine you would nod your head in agreement?  I've personally been affected by them lots of times (and other times not at all). 

[HP Sauce]

Sorry to dredge this topic form the depths but I'm currently learning F# (and creating a very simple game as a first project). As such I Googled upon this thread while trying to soak up as much "Functional code meets Gaming" info as possible.

I have to say I'm having a lot of fun using functional programming to write a game (or game-like project, as it may never reach the stage of being playable, due to my limited attention span and spare time).

So far my only mutation is the setting of the game windows title!.
I'm using the F# mailbox-processor as a state machine for player and enemy state changes; which I believe is a dressed-up "state monad". Now I'm used to it I am very happy with the results and usability of the system.
In another case I use a function based on time to give the illusion of a value mutating between a and b.

F# is also very succinct:
My Path-finding is modelled on the A* algorithm and is only about 28 lines of code,
My tile engine is 8 lines,
With character code weighing in  ataround 18 lines...

By way of contrast I've seen C# path-finding code posted on the web that's a couple of hundred lines on it's own

I've still got a couple of OO hangovers so there are a few places where an object-null exception might be thrown or that I could wander off the end of an array into an index-out-of-bounds.

But apart from those exceptions I'm finding F# code wonderfully bug free thanks to: Immutability, the fact the only way you can get a null reference (without going out of your way to do so) is by using an "option" and that most collections are enumerated over.

I would recommend making games with functional languages to anyone; (from what I can tell thus far) it's very much just a change in the way you think/code than it is a round-peg-square-hole issue.

[increpare]

I would recommend making games with functional languages to anyone; (from what I can tell thus far) it's very much just a change in the way you think/code than it is a round-peg-square-hole issue.

I would hold off making such a recommendation until you've finished one yourself.

[HP Sauce]

  If people waited until their personal game projects where finished before commenting on the subject game development forums would be very quiet places.

I feel I've pretty much addressed most of the usual concerns I've run into in other (finished and, mostly, unfinished) projects.

I have pathing, collision, input, rendering, damage, scoring.. etc.
I would say I'm an XML to scene graph parser and script engine away from having a pretty complete project. (Though they are not small things).

And like I said I've hit a LOT less bugs in a language I'm just learning (F#) than languages I've been using for ages (C++, C#). That's enough for me to recommend it, I feel.

[increpare]

What sort of game are you trying to make?  (I hear 'very simple' on one hand, and 'scene graph parser and script engine' on the other).

[HP Sauce]

The game will be (if it ever sees light of day) 2D, top down, tile based: you play as a little guy running around collecting treasure and avoiding monsters. Simple

Plugging IronPython or Luainterface into a .NET project is fairly easy and I can't see parsing XML into a series of singularly liked lists to be enough effort for me to claim the game is more than something simple.

Though I get where you're coming from, for my last toy-project I combined Ogre for rendering and scene management, Mono as a script engine with C++ code and that was not an overly trivial task.

With regards functional programming I feel I've done the majority of risk assessment that I needed to do on it.
For me the biggest risk (and mind bender) was immutability... Before I got into FP the thought of not being able to assign values blew my mind.
But also the biggest pull of FP was immutability, immutability = less bugs, easier parallelism(this project doesn't need that, but its a tool in my coder utility-belt if I can  master it). Plus the other things I mentioned like greatly reduced opportunity for null reference, etc.

Another risk, though I suppose its a sub-section of immutability, is the assumed speed hit that constantly creating new instances of objects brings. But this seems to be minimal, I've even seen anecdotal evidence of the Zipper pattern beating out mutable tree structures for speed. Also if I should find my self developing for a platform where the GC is diabolical (compact framework?) F# allows me to fall back on mutable data structures.

Obviously if this where a commercial endeavour risk #1 would be: Where the hell do I hire F# devs from.

On top of all that It's been really fun using FP. I'm less focused on trying to create objects to solve problems and more focused on just solving problems with logical code.   

For those reasons I recommend it.

Obviously the flip side of that coin is If your looking to start a new and serious project then you have to consider the time you will need to spend learning FP and the fact you , probably, wont find many people with the skills to be able to help you out, etc, etc.

[george]

I'd really like to hear a straight explanation of programming a game with immutable data structures. Whenever this comes up people seem to say vague things, like 'oh you just copy the world over every tick'...is that all there is to it?

[HP Sauce]

george, in very broad terms: yes and the compiler will optimise the code so that when you copy "the world" the only values that don't directly reference the old ones are the ones that have changed. Making it a lot faster than you (or I; when I first started out) would imagine.

It is worth noting that this is not the reason you use FP but rather the how you use it.
A lot of stuff in FP is very alien to the OO developer... Which is what drew me to it:
I sat there in OO-land looking at FP and thinking "what the hell are those nutters doing over there" and decided to give it bash.

Coming from OO, the immutable state of FP was the thing I had to over come to get my head into it. Though I still don't feel I'm the guy to explain it in-depth as my FP learning is only in its infancy. Hopefully some FP pro will step in and answer this one for you.

Having played a lot, in the past 2-3 weeks, with immutable data it's highlighted how much I and every other C#,C++,Java,etc developer I've worked with abuses the ability to assign values and what pit-falls could be avoided if people were more careful when assigning values  and/or referencing mutable vales.

I would recommend a play with FP to every OO developer.. even if it's just as a learning experience.

[bvanevery]

Sorry to dredge this topic form the depths but I'm currently learning F# (and creating a very simple game as a first project).

What are you using for display?  WPF?  Silverlight?  XNA?  Straight DirectX?  Legacy Managed DirectX?  SlimDX?  Text adventure console?  I'm currently going up the F# learning curve myself and choking on the lack of decent example code.  The open source landscape for F# is pretty poor right now.  Almost nothing builds cleanly.

[HP Sauce]

Hi bvanevery,

I'm currently using SDL.NET.
Only because SDL was the first thing that sprang to mind as I had used it with C++ in the past.

So I can't endorse it any more than to say: "It works OK with F# for the simple things I'm using it for."

Check out the first entry on my blog (currently a bit of a rush job, due to the fact I'm applying for jobs at the moment): http://jdoig.net/blog/?p=49
It covers how to get started with SDL.NET and F# (it's very simple and quick to get up and running).

That project in it self is not aimed at being highly functional or immutable but the following posts go onto cover path finding in a totally immutable fashion and later posts will cover state, characters, etc, etc.

[bvanevery]

I'm going to slog through the Windows API Code Pack and see if it's any use.  Version 1.1 has been a lot of changes to the DirectX interfaces, so maybe some energy at actually making it work is being spent.  Cross fingers.