next »

[John Nesky]

Actually, who's up for a pure functional competition?

I recently decided I was interested in attempting functional programming in a game.

[increpare]

Actually, who's up for a pure functional competition?

I would totally be.  We could probably pull in some people from random places on the internet as well. (I wouldn't be too precious about the 'pure' bit, though, myself - that restricts things a little).  A 48-hour thing some weekend would be cool, but there would likely be casualties.

The fundamental problems do seem to go when you scrutinize them: No mutability - "copy" the game state every every tick. No input/output -

functions are precisely things that take inputs and produce outputs  

[BorisTheBrave]

functions are precisely things that take inputs and produce outputs  

That's what I'm saying about lack of imagination. That's bloody obvious in retrospect. (you can see how much real experience I've had of these sorts of languages).

(I wouldn't be too precious about the 'pure' bit, though, myself - that restricts things a little).

Aren't non-pure functional languages a dime a dozen nowadays? Am I using different terminology to you?

[increpare]

Aren't non-pure functional languages a dime a dozen nowadays?

Fair point.  The pure ones are...haskell?  (I think clean's fallen by the wayside, alas).

[BorisTheBrave]

Haskell, F#, Clojure (and some other Lisps), OCaml is about all I can dredge from memory. Wikipedia isn't being helpful either. I guess that is a fairly limiting set of languages.

Maybe someone would have the balls to do a game in Excel spreadsheet form, or prolog.

[westquote]

functions are precisely things that take inputs and produce outputs  

This is true, but I/O with hardware like a mouse, keyboard, screen, etc... interactively is not as intuitively modeled in a pure-functional language.  I think this was what Boris was getting at.

The mechanism that is most commonly used to tackle this problem in a pure-functional language is monads.  I don't think it would be pleasant or easy to implement an interactive game in a pure-functional language without them.  That said, they are one of those notoriously-counter-intuitive concepts that people bemoan in school when they are forced to learn them.  There are a few other comparably unintuitive approaches discussed here.

Does anyone have experience writing a game using any of these techniques?

[george]

The thing about functional programming and games is that you're really deliberately using the wrong tool for the job. Games are by their nature imperative and interactive and all that time-dependent stuff.

Something I was thinking about today was process vs. the sampling point. In a game the update ticks are the sampling points; I'm not sure there is a real 'process' in a game that's imperatively written.

It's a similar situation when modeling natural processes. Modeling a river, say (computationally rather than with a physical scale model that is), usually you do it in the same manner as a game. But can you say that the real river acts in the same way? So the question is whether we have no choice to model it the way it's usually done.

I don't mean to get too far out here, but this where I see things going in trying to write games in a functional language.

[increpare]

Haskell, F#, Clojure (and some other Lisps), OCaml is about all I can dredge from memory.

f#, clojure, and ocaml all allow for mutation (though they certainly don't encourage it, it's much more natural to do in them than H).

Does anyone have experience writing a game using any of these techniques?

IO monad stuff is pretty easy to use - though it's not necessarily straight-forward to understand in detail (it has a couple of amusing gotchas).  It looks, and, mostly, behaves just like normal imperative code.  Uniqueness types are actually quite great from what I can tell, and conceptually more straight-forward/less-arbitrary than monadic stuff, but I haven't had much of a chance to try them out properly

This is true, but I/O with hardware like a mouse, keyboard, screen, etc... interactively is not as intuitively modeled in a pure-functional language.  I think this was what Boris was getting at.

yep.

[Average Software]

The thing about functional programming and games is that you're really deliberately using the wrong tool for the job. Games are by their nature imperative and interactive and all that time-dependent stuff.

Something I was thinking about today was process vs. the sampling point. In a game the update ticks are the sampling points; I'm not sure there is a real 'process' in a game that's imperatively written.

It's a similar situation when modeling natural processes. Modeling a river, say (computationally rather than with a physical scale model that is), usually you do it in the same manner as a game. But can you say that the real river acts in the same way? So the question is whether we have no choice to model it the way it's usually done.

I don't mean to get too far out here, but this where I see things going in trying to write games in a functional language.

Maybe the problem is that people are trying to write the wrong kinds of games in a functional language.

Not all games have to be of the event-loop, graphics and input driven model.  Perhaps there are new kinds of games that fit the functional mindset much more naturally that nobody is really exploring.

[increpare]

Not all games have to be of the event-loop, graphics and input driven model.

Any ideas/examples in mind in particular?

[magnum_opus]

Haskell, F#, Clojure (and some other Lisps), OCaml is about all I can dredge from memory. Wikipedia isn't being helpful either. I guess that is a fairly limiting set of languages.

Maybe someone would have the balls to do a game in Excel spreadsheet form, or prolog.

depends on purity.
Haskell, Clean and Mercury are the only ones I know with pure functional IO.
Clojure and Erlang are both very strongly immutable, though it can be done (clojure I think easier than erlang). F#/Ocaml yeah, Scala calls itself function but I don't think it enforces immutability any more the CL or scheme.

[PleasingFungus]

Not all games have to be of the event-loop, graphics and input driven model.

Any ideas/examples in mind in particular?

TBS games, maybe? Conway's Game of Life?

[Kali]

Yeah, I feel like TBS games are good candidates. I used implementing the board game stratego as a means of learning Haskell a while back, and it was pretty easy to keep the code pure and functional. In the end, I had code that was a lot more modular and cleaner-looking (in my opinion) than most of my attempts in imperative languages.

I dunno how well it would scale up to larger projects. Last I checked, it didn't seem like performance would be an issue. I personally find it pretty hard to think outside of the typical imperative mindset though, so I find functional programming more of a fun challenge than a feasible development option.   

[increpare]

I dunno how well it would scale up to larger projects. Last I checked, it didn't seem like performance would be an issue. I personally find it pretty hard to think outside of the typical imperative mindset though, so I find functional programming more of a fun challenge than a feasible development option.  

For haskell, speed (hard real-time performance) is an issue.  Garbage collection is the main issue.  It should also be noted that many of the entries for the shootout are in extremely idiosyncratic haskell.  But the main issue for me on a day-to-day basis is library support (I could help out here, admittedly, but I don't have the time).

[lansing]

For haskell, speed (hard real-time performance) is an issue.  Garbage collection is the main issue.

hello, fellow haskeller here.  I remember that thread and if you look at Luke's reply when asked if he had _really_ had issues, it turned out to be hearsay.   That isn't to say there aren't potential issues, but the majority of GC issues I've seen is just the case of programming error, generating garbage unnecessarily.