[Haskell-cafe] Simple game: a monad for each player

Gwern Branwen gwern0 at gmail.com
Thu Apr 8 17:42:28 EDT 2010


On Thu, Apr 8, 2010 at 4:08 PM, Yves Parès <limestrael at gmail.com> wrote:
>
> Hello Cafe,
>
> I have a question about program design.
> Let's say I have a simple sequential game (a TicTacToe for instance, but
> with more than 2 players).
> I have a Player datatype which is like:
>
> data Player m = Player {
>    plName :: String,  -- unique for each player
>    plTurn :: GameGrid -> m Move  -- called whenever the player must play
> }
>
> As you may guess, the 'm' type variable is intended to be a Monad.
> The goal is that every player has his own monad. For instance :
> - a human player needs to interact with the program, so its monad would be
> IO, or an instance of MonadIO.
> - a network player, which transparently sends the game state and receives
> moves through network, must also have access to IO to play.
> - an AI doesn't need to interact with the outside of the program, so its
> monad can be the one we want (e.g. Identity).
>
> First, do you think it is a good way to design the program?
> I want the game to be totally independent of the players who are currently
> playing. They can be humans, AIs, AIs and network players and humans, and so
> on.
>
> But when running the game, the program cannot "switch" from a player's monad
> to another.
> If we want every player to run in his own monad, I think we have to stack
> every players' monad, and lift their actions each time they have to play.
> This is not a problem, the sole condition now is that every player has type:
> (Monad m, MonadTrans m) => Player m.
>
> But I think it's a little bit of overkill, and it may be a little bit
> complicated to implement such a thing.
> What I try to avoid is having every player running in IO monad.
>
> Do you have any suggestion?
>
> -----
> Yves Parès

Your desires remind me of the MonadPrompt package
<http://hackage.haskell.org/package/MonadPrompt>, which IIRC, has been
used in some game demos to provide abstraction from IO/test
harness/pure AI etc.

-- 
gwern


More information about the Haskell-Cafe mailing list