Comments and suggestions welcome :-) hi Joachim.
i have some suggestions: apache: use fastcgi instead of hacking an own http-server. http://www.cs.chalmers.se/~bringert/darcs/haskell-fastcgi/doc/ http://www.cs.chalmers.se/~bringert/darcs/cgi-compat/doc/ server: there are virtual linux servers out there, free to rent. some of them are even cheaper than the power-usage of one's old pc (at least compared to speed). if you intend to write a game for thousands of users, who play it 24/7, then it may be comfortable to rent one. (friends of me rented one.) software upgrades: use Read/Show classes instead of Foreign.Marshal, and combine them with version counting data-structures: [code] data MyData = V1 String deriving (Show,Read) read_v1 :: MyData -> String --------- data MyData = V1 String | V2 [String] deriving (Show,Read) read_v1 :: MyData -> String read_v2 :: MyData -> [String] --------- data MyData = V1 String | V2 [String] | V3 [(String,Int)] deriving (Show,Read) -- obsolete: read_v1 :: MyData -> String read_v2 :: MyData -> [String] read_v3 :: MyData -> [(String,Int)] [/code] i've thought about writing a browsergame in haskel, too; but atm, i have no time for (writing) games. - marc Am Montag, 18. Dezember 2006 12:30 schrieb Joachim Durchholz:
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
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe