I'm rather "shooting from the hip" here (that is, I haven't really thought this through).. I wonder if the "Scrap your boilerplate" [1] approach might apply here. I'm thinking that it might allow you to separate the behaviour ("Response to being hit") from the thing that responds ("orc"), so that you can, for example, collect the various behaviours in a module that defines "orc", and different behavours for "troll", "wizard", etc. Then I would imagine the action "hit X" would be applied as a generic function traversing the game state, or part of the game state. Components of the state that don't understand the concept would not respond. Adding a new behaviour or stimulus should mean no change to the components that don't need to recognize that behaviour. Just a thought. #g -- [1] http://www.cs.vu.nl/Strafunski/gmap/ At 09:21 30/01/04 -0700, nickgrey@softhome.net wrote:
Hi, I'm writing a game in Haskell. The game state includes a lot of closures. For example, if a game object wants to trigger an event at a particular time, it adds a function (WorldState -> WorldState) to a queue. Similarly there are queues which contain lists of functions which respond to events. (CreatureAttackEvent -> WorldState -> WorldState) I'd like to be able to save the game state to disk so that it can be reloaded. Obviously, these closures are now a problem, as they can't be stored. I could obviously, replace all the functional values with non-functional ones, and have a big case statement specifying the behaviour associated with each constant. However, I don't really like this solution. It means that for each type of function which was in the game state (there are lots) I will need a type which lists all the possible behaviours (again, there are lots) that could occur. First of all, these types are likely to be very large. Secondly, I'd rather the behaviours were defined in different modules. For example, I want to have an "Orc" module which defines functions such as "Response to orc being hit", "Response to orc picking something up", etc. This implementation would force me to have a "Monster reponse to being hit" MODULE, containing an orcs response, a goblins response etc. I.e., the modules would be grouped by type of behaviour, rather than type of monster, meaning that adding a new monster type would require modifications accross many modules. (This example is obviously something of a simplification, but hopefully it shows the point.) Obviously, none of this is fatal. I could make it work. But going through my program and replacing all the functions with values and then doing big pattern matches against the values to find the functions seems like a very non-functional way of doing things. Can anyone suggest a neater design? _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
------------ Graham Klyne For email: http://www.ninebynine.org/#Contact