[Haskell-cafe] Getting my feet wet - small browser game

[Marc A. Ziegert]

> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>