LoCo Day 16

Today I got starting and ending games working. Each member of a room can signal when they’re ready to begin playing. Once everyone in a room is ready (whether it be because the last non-ready member became ready, or the last non-ready member left), and the room isn’t empty (in which case the first condition would be vacuously true), a new game starts. When it’s over, everyone becomes not-ready and the cycle begins anew.

Granted, the “game” that’s currently implemented amount to “wait five seconds for the game to end”. Woo. Sure, it’s more like a hole where an actual game can be put, which is sort of the point.

Since the game I have in mind is real-time and not turn-based, starting a new game requires starting a new thread, which will be responsible for periodically advancing the game state and sending messages to the room if anything interesting happens. Right now that thread just sleeps for a few seconds before ending the game, but it’s there. During a real game, players would affect the game state by asynchronously POSTing their moves, which the game thread would then be able to read at the next time step.

For a program being written in Haskell, I sure do have an awful lot of code living in the IO monad. I don’t think there’s really a way around this, though, since the multicast channels underlying my long polling implementation are based on TChans (so that requests have something to block on while waiting for messages), and the list of rooms is carried around inside an MVar (so multiple server threads can access it simultaneously). Most of the code I’ve been writing lately is directly tied to sending messages and/or manipulating a room, which pretty much forces IO. The game itself will have a bit of IO when it comes to queueing players’ moves, but it ought to be possible to make most of the game logic pure.

Comments Off