[Haskell-cafe] Getting my feet wet - small browser game
Joachim Durchholz
jo at durchholz.org
Mon Dec 18 06:30:44 EST 2006
OK, after years of looking and discussing and doing HSoE exercises, I
have finally decided that Haskell is far enough into practical
usefulness that I should give it a try in a "real" project.
The basic idea is a browser game - this touches all the potentially hard
issues without miring me too deeply in target platform details.
I'd like to lay out my plans here and ask how they are going to work
out, and take advice.
THE PLAN
I'll start with
http://haskell.org/haskellwiki/How_to_write_a_Haskell_program and get a
toolchain together. I haven't decides which compiler (interpreter?) to
choose; I'll probably go for the one that give the least amount of trouble.
Next would be library selection. I'm willing to undergo some modest
amount of hassle here, since I don't expect all libraries that I need to
be mature yet.
My preliminary plan is to split the application into a central world
simulation process, and satellite processes that accept HTTP requests,
feed them into the simulation, read back the results, and generate the
response HTML.
The interface between simulation and satellite is:
* Satellites can read a snapshot of the game data.
* Satellites cannot directly write game data.
What they can do is to post commands to a blackboard, which are marked
as "no more updatable" as soon as the simulation starts executing
them.
I expect the simulation and the satellites to be separate OS processes,
so I'll need a way to marshall command and game data between processes.
The simulation will have to store its entire state to disk, too - in
theory, it could run forever and never write to disk (and I don't need a
database, too), but in practice, I have to plan for the occasional reboot.
Since the server will be running Apache for other purposes anyway, and I
don't want to force the players to use a URL with a port number, I think
I'll set up Apache so that it proxies game-related URLs to the Haskell
software. I just hope that Apache doesn't incur much overhead in that mode.
I have no idea how to organize software upgrades. The satellites are
easy, but how do I make sure that revision N+1 of the simulation can
read the marshalled data from revision N?
The final software should be efficient. Ideally, the satellites are able
to saturate the network card of today's typical cheap rootserver if the
simulation is a no-op.
I have two data points for a "typical cheap rootserver":
* 100 MBit/s Ethernet, 256 MB RAM, 1.2 GHz Celeron (~3 years old)
* 1 GBit/s Ethernet, 1 GB RAM, 2.2 GHz Athlon (current)
Of course, not needing an RDBMS will give the system a head start
efficiency-wise.
Comments and suggestions welcome :-)
Regards,
Jo
More information about the Haskell-Cafe
mailing list