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 at 13:09
    
advantage of pure functional is that function prototypes shows all dependencies your program has. –  tp1 Apr 25 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 at 23:07
add comment

2 Answers 2

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
add comment

As you didn't ask about an OOP approach, I will assume you have specific reasons for it not to be one, but it is far easier and more intuitive to create a game in an OOP or mixed paradigm than in others. That's all I'll say on the matter, though.

Look in to building your own data types... It'll keep your code cleaner. In C you can create a 'struct' that is a user defined data type that tracks multiple fields of data as a single data type. Keep one for the player (that includes things like money and other seemingly global information that is appropriate to place on the player), and one for baddies. I can't guarantee that they will be called structs in your language, but this is the term I will use in this answer.

With this you can create a list or an array of baddies that each have their own stats that are defined by the struct you created. This can include position, rotation, or any other information you need. When you need to process a command to place the creature on the screen (including moving it), just pass that specific array entry or list entry in to the function to move them, and he'll be able to change position from there.

This will allow you to avoid a single, huge hashmap that can and likely will just confuse the hell out of you and lead to a much higher probability of bugs. It'll also help a little in automating a save process, if you add one, by treating the structs as single data types. One more important thing it will do is separate entities, thus allowing you to pass much more limited amounts of data to your functions, instead of all of the data for your game, protecting you from yourself. Granted, most combat functions will need both the player struct and one of the enemy structs, but that's far smoother than a hashmap of everything.

Also remember that a struct can have other structs as data fields in them.

If I didn't cover anything well enough, let me know, and I will add more to the answer. I assumed you understand the basics of a finite state machine in order to get initial functionality up.

share|improve this answer
    
I've done programming +20 years now and lots of this time I use OO languages like Java, C++, Ruby and such. So the concepts of structs, composed datatypes, modular code, etc. are not the problem. My questions is about state. In a pure functional language, there is no "outside" state (except for the hazy monad construct). All state are the params for a function, so the result of this is always the same for a given input (no external dependencies). My question was: How can I handle the huge amount of state (player, world, enemys, particles, posisionts, ...) in a pure functional language? –  Fu86 Jun 6 at 7:58
    
-1, you do not give arguments for/against an OOP/functional approach... –  Matthias Jun 6 at 8:52
    
Sorry, I wasn't trying to suggest oop over functional. That's why I stated I was assuming there was a reason for choosing functional and moved on. And @Fu86, I wasn't sure how much experience you had at doing this. Far more than I do, apparently. The best I can say would most likely be 5 hat you can pass by reference or load the info actively from a file, but from what you've stated, you probably have better ideas than I do based on experience. –  Robert Jun 10 at 13:03
add comment

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.