Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Is there a common technique to handle state (in general) in a functional programming language? There are solutions in every (functional) programming language to handle global state, but I want to avoid this as far as I could.

All state in a pure functional manner are function parameters. So I need to put the whole game state (a gigantic hashmap with the world, players, positions, score, assets, enemies, ...)) as a parameter to all functions which wants to manipulate the world on a given input or trigger. The function itself picks the relevant information from the gamestate blob, do something with it, manipulate the gamestate and return the gamestate. But this looks like a poor mans solution for the problem. If I put the whole gamestate into all functions, there is no benefit for me in contrast to global variables or the imperative approach.

I could put just the relevant information into the functions and return the actions which will be taken for the given input. And one single function apply all the actions to the gamestate. But most functions need a lot of "relevant" information. move() need the object position, the velocity, the map for collision, position of all enemys, current health, ... So this approach does not seem to work either.

So my question is how do I handle the massive amount of state in a functional programming language -- especially for game development?

EDIT: There are some game frameworks for building games in Clojure. There approach to solve this problem partially is to thread all objects in the game as "entities" and put it in a huge bag. A gigant main function is holding the screen and the entities and handle events (:on-key-down, :on-init, ...) for this entities and run the main display loop. But this is not the clean solution I am searching for.

share|improve this question
    
I've been thinking about this kind of thing for a while; to me, it's not input that's the unique problem, as you still have to feed (roughly) the same elements to functions in non-functional programming. No, it's the output (and subsequent related updates) that's the problem. Some of your input parameters should be combined; for move(), you should probably at be passing in the 'current' object (or an identifier for it), plus the world it's moving through, and just derive current position and velocity... output is then the entire physics world, or at least a list of changed objects. –  Clockwork-Muse Apr 25 '14 at 13:09
    
advantage of pure functional is that function prototypes shows all dependencies your program has. –  tp1 Apr 25 '14 at 13:54
2  
IMO, functional languages are poorly suited for writing games. This is one of many problems that you will need to solve. Games require very precise control of performance, and rarely have good concurrency, due to the unpredictable way events naturally occur. (Pure) functional languages are notable for being trivially parallelizable, and hard to optimize. A game is HARD to write, and I recommend just doing it in a typical language, before taking on something just as complex (functional programming). –  darthfett Apr 25 '14 at 23:07

1 Answer 1

Side-effects and state in functional programming languages are a broader problem in computer science. In case you haven't encountered them before, maybe take a look at monads. Be warned, though: they are a fairly advanced concept and most people I know (me included) struggle to grasp them. There are many, many tutorials online, with differing approaches and knowledge requirements. Personally, I liked Eric Lippert's best.

I’m a C# programmer with no “functional programming” background whatsoever. What is this “monad” thing I keep hearing about, and what use is it to me?

Eric Lippert on Monads

Some things to consider, though:

  • Do you insist on using a purely functional language? If you're skilled in both functional programming and game development, maybe you could pull it off. (Even though I'd like to know whether the benefits are worth the effort.)
  • Wouldn't it be better to use functional approach only where necessary? If you're using an object-oriented (or, more likely, a multi-paradigm) language, nothing's stopping you from using functional style to implement sections which profit from it. (Kinda like MapReduce, maybe?)

Some final thoughts:

  • Parallelism: While games do use it heavily, AFAIK most of it already happens on the GPU anyway.
  • Statelessness: Mutations of state are an integral part of games. Trying to get rid of them might just complicate matters unnecessarily.
  • Maybe look at how the functional language F# plays with the object-oriented ecosystem of .NET, if you're interested.

All in all, I think even if it could be interesting academically, I doubt this approach is practical and worth the effort.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.