[Haskell-cafe] Browser Game Engine

[Jeremy Shaw]

On Jan 16, 2011, at 9:26 PM, Tom Hawkins wrote:

> I want to create a simple browser game using Haskell.  It would be
> nothing complicated: basic 2D graphics, limited sound, and minimal
> network traffic.
>
> What is the recommended medium?  Flash or JavaScript+SVG?

I think your options are: flash or html5+canvas+javascript.

The must be at least a million flash games, so clearly it can be used  
for that. If you create a flash game, nobody gets excited. But if you  
create an html5 based game, then people still get excited about that.  
So, I assume it must be hard :)

For flash, you can use the free flex SDK. Flash supports bitmap and  
vector graphics, network IO and realtime audio. The runtime it  
supported almost everywhere except iOS and you pretty much only have  
to worry about supporting one version of flash.

HTML5 is trendy and cool, and can be made to do what you want. It has  
less support than flash since you need to be running a modern browser  
-- which many people are not. And you have to deal with trying to  
support multiple browsers.

So you need to decide:

  1. what technology do you want to invest in learning
  2. how important is it that people can run your game with out having  
to install a new browser
  3. how much hackery are you willing to do

> Any recommended Haskell libraries for the server-side logic or client
> code generation?

I have not found any way to satisfyingly generate the client-side  
code. Ultimately, it has just turned out to be easiest to write the  
client-side code in javascript/actionscript by hand.

For the server-side, it would be useful to know what sort of game  
logic is going to be run in the server itself. For many browser based  
games, the server just needs to serve static files, and apache would  
be sufficient.

In other games some of the game logic does reside on the server.

The nice way to do that would be to have some nice Haskell datatypes  
to represent the game state and then functions that get called to  
update the game state and return values to the client.

The tricky party is that you don't really want to lose the whole game  
state every time you restart the server. You could try checkpointing  
the state now and then, but that still leaves things open to data  
loss. If someone finally defeats the big boss and then you lose the  
last few minutes of the game state, they are not going to be happy.

You could keep all your state stored in a SQL database. But that just  
does not sound like a good match for game logic ?

Personally, I would recommend checking out happstack-state.

happstack-state (also known as MACID), allows you to use normal  
haskell datatypes and functions for your game state and game logic.  
But it also uses write ahead logging to ensure that every update to  
the state is logged so that you can restart the server with the state  
intact (even if the server crashed). It also provides support for  
replication across multiple servers.

There is a short tutorial here that will help you get a feel for it,

http://www.kuliniewicz.org/blog/archives/2009/04/05/happstackstate-the-basics/


You also need an API for talking to the server from the client.

You can probably make just about any of the Haskell web servers do the  
trick. But I think happstack-server is a fine choice. The darcs  
version of happstack-server is well documented, and provides a rich,  
complete API.

For example, let's say that an api call requires you to pass three key/ 
value pairs in via the QUERY_STRING. All the web frameworks have calls  
for looking up the key/value pairs. But happstack goes beyond that and  
provides an environment which can accumulate and report all the  
missing or incorrect query parameters at once, not just the first one.  
This makes it much easier to debug your client-side code since you get  
all the errors at once -- instead of just one at a time.

(http://happstack.com/docs/crashcourse/RqData.html#rqdataerror)

Check out the crash course to get a feel for the API coverage,

http://happstack.com/docs/crashcourse/index.html

the haddock documentation in the darcs code has very good coverage.

- jeremy

p.s. The darcs code is quite stable. The main holdup is just making  
the haddock docs even better.



  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20110117/312b55af/attachment.htm>