Friday, October 09, 2009

What client for an Haskell Multi Player Game?

I've been thinking again, in between working on eclipsefp, about writing a multi player role-playing game in Haskell. OK, I'm not going to write something the size of WoW by myself in my free time (unfortunately my day job doesn't involve any game programming nor any Haskell hacking :-(), but since I enjoyed writing Mazes of Monad, I figured that a game is a good way to learn things. A MMORPG should get me into concurrency, persistence, graphics, performance etc...

What I'm trying to figure out at the moment is what architecture to use. Mainly, if I have no doubt there is going to be a server somewhere running Haskell code, I wonder about the client. Should I try to write a browser based game coupled with a Haskell web server? That way, users could easily play the game when (if) it gets to a usable state, and I won't have to worry about cross platform issues for the client. Getting proper server side events or push should be fun, and of course if I end up using something like web sockets I will probably require a fairly cutting edge browser, which negates the advantage. I'm not too sure meddling with AJAX long polling and dynamic HTML is such a attractive option.
The other path is to write a Haskell client. Granted, users will have to download it, which means either me dealing with cross platform issues (provide several exes) or restricting my users to people happy to use cabal install. But I'll get maybe into stuff like OpenGL in Haskell, and do everything in Haskell instead of mixing Haskell with HTML and JavaScript (I've just stumbled upon jmacro, which could be cool I guess).

I'm sure everybody has faced that question at some stage. Ah well, for the moment I'm still wondering what my game will do, so I guess I have time to play with a few things before I make my mind up.

8 comments:

Harmen said...

I had the same idea a while back, and ended up writing the server in haskell and the client in C++. that way I learned both :)

This worked well for me since the client doesn't have _that_ much logic and you have much more options to choose 3D frameworks for the client. No need to write haskell bindings first.

Of course I got completely sidetracked with everything I came across, so nothing's working, but had a lot of fun ending up nowhere :)

jerf said...

Google for "flash socket javascript" (no quotes in the google query). I'm thinking of doing a similar sort of project (not at all a game, but a lot of interaction) and that's the approach I'm eyeing.

I suppose if I'm really slick I'll make it so I can use websockets if they are present, and fall back to flash if not.

wren said...

Depending on what all you're interested in you may want to look into some of the classic browser-based MMO strategy games (e.g. Utopia, though I don't know how the current version compares to the one I played). There was a whole genre of them around 1998~2003 before the graphics-heavy MMORPGs (WoW, etc) came out. You may also want to look into some of the classic (non graphics-heavy) MMORPGs like Ultima Online, or their modern open-source variants like (the excellent) Stendhal or the (ever nascent) The Mana World.

I guess my main point is that there are many subgenres of MMO. They differ obviously in their graphics, but the style of play and the overall user interface are also significantly different. A well-designed rogue-like would be easy to convert into a classic MMORPG. If you're worried about the graphics you could always go for cracktastic ASCII art (like the single-player Dwarf Fortress).

One thing you should be concerned with up front, though, is sharding and migrating. For anything MMO, you need to be able to split the world and the players up and distribute them across multiple machines. Even if you only have one server to play with for now, this is a feature you'll want and it's hard to alter code to add it after the fact.

SebastiƔn said...

You can go OpenGL with isometric view (much like 2D view) and 3D effects. But you need really good artwork for backgrounds.

Server in Haskell makes a lot of sense.

Client in whatever language with builtin scripting in Lua or Scheme would rock. I think Scheme would fit you well considering that you like functional.

James said...

You might consider writing a client (or server) for one of the existing fee MMOs.
Stendhal or The Mana World, mentioned above, would be good choices, or Worldforge. That way you don't have to spec out the protocols or build all the content yourself.

linker said...

I wouldn't really touch HTML/CSS/JS with a barge pole, the reason being their utter brokenness. I'm talking about both specification and implementation.

Current web technologies require too much fiddling to get a result: that's why there are so many "frameworks" out there. Flash is much better for your task.

Kirk said...

Make a text based game like a MUD. Graphics are overrated, only client you need is telnet.

motiur nuggeta said...
This comment has been removed by a blog administrator.