[Haskell-cafe] Browser Game Engine
jeremy at n-heptane.com
Mon Jan 17 18:16:16 CET 2011
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.
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
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
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,
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,
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.
Check out the crash course to get a feel for the API coverage,
the haddock documentation in the darcs code has very good coverage.
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...
More information about the Haskell-Cafe