<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 16, 2011, at 9:26 PM, Tom Hawkins wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>I want to create a simple browser game using Haskell. It would be<br>nothing complicated: basic 2D graphics, limited sound, and minimal<br>network traffic.<br><br>What is the recommended medium? Flash or JavaScript+SVG?<br></div></blockquote><div><br></div><div>I think your options are: flash or html5+canvas+javascript. </div><div><br></div><div>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 :) </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>So you need to decide:</div><div><br></div><div> 1. what technology do you want to invest in learning</div><div> 2. how important is it that people can run your game with out having to install a new browser</div><div> 3. how much hackery are you willing to do</div><div><br></div><blockquote type="cite"><div>Any recommended Haskell libraries for the server-side logic or client<br>code generation?<br></div></blockquote></div><br><div>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.</div><div><br></div><div>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.</div><div><br></div><div>In other games some of the game logic does reside on the server.</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>You could keep all your state stored in a SQL database. But that just does not sound like a good match for game logic ?</div><div><br></div><div>Personally, I would recommend checking out happstack-state.</div><div><br></div><div>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.</div><div><br></div><div>There is a short tutorial here that will help you get a feel for it,</div><div><br></div><div><a href="http://www.kuliniewicz.org/blog/archives/2009/04/05/happstackstate-the-basics/">http://www.kuliniewicz.org/blog/archives/2009/04/05/happstackstate-the-basics/</a></div><div><br></div><div><br></div><div>You also need an API for talking to the server from the client. </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>(<a href="http://happstack.com/docs/crashcourse/RqData.html%23rqdataerror">http://happstack.com/docs/crashcourse/RqData.html#rqdataerror</a>)</div><div><br></div><div>Check out the crash course to get a feel for the API coverage,</div><div><br></div><div><a href="http://happstack.com/docs/crashcourse/index.html">http://happstack.com/docs/crashcourse/index.html</a></div><div><br></div><div>the haddock documentation in the darcs code has very good coverage.</div><div><br></div><div>- jeremy</div><div><br></div><div>p.s. The darcs code is quite stable. The main holdup is just making the haddock docs even better.</div><div><br></div><div><br></div><div><br></div><div><a href="http://www.kuliniewicz.org/blog/archives/2009/04/05/happstackstate-the-basics/"></a> </div></body></html>