Assuming Haskell is ready has any work gone into creating design patterns or the like. One of the biggest problems is ALL of the literature regarding game programming is written in an imperative style. My goal for learning Haskell is to make a hobby game written in a Functional language but I am at a loss how to go about it. I an imperative language I would set up a central entity management system and then have subsystems register with it and either transform the entities such as AI or user interface or do something with them IE graphics. This paradigm just will not work as far as I can imagine in Haskell.

On Sun, May 23, 2010 at 6:30 PM, Jake McArthur <jake.mcarthur@gmail.com> wrote:
On 05/23/2010 02:17 PM, Peter Verswyvelen wrote:
IMO: For AAA game programming? Definitely not.

Why not? I suppose it may depend on your definition of "AAA," since there doesn't seem to be any consensus on it. I have seen it mean various combinations of the following, but rarely, if ever, all of them:

 * Big development budget
 * Big marketing budget
 * High quality
 * Large number of sales and/or high revenue
 * High hardware requirements
 * Released by one of a small group of accepted "AAA" publishers

While I think it's very unlikely that the last one will happen any time soon, I don't see any reason that Haskell and/or FRP (or as I now prefer to call my research in the area, Denotative Continuous-Time Programming, or DCTP) inherently can't be a major part of the development of a game that fits any of the definitions in the list.

I suppose DCTP is not itself *ready* for somebody to risk a business investment on it, although it may be in the future, but Haskell as a whole would not be all that risky, in my opinion.

- Jake

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe