

Tetris in Haskell - whalesalad
http://lambdacolyte.wordpress.com/2009/08/06/tetris-in-haskell/

======
mbrubeck
There's a pretty big collection of games (of varying maturity and complexity)
at the Haskell Wiki, including a couple of tetrises [1]. One of them, Frag
[2], is a pretty cool 3D first-person shooter. It's one of the most popular
current downloads from Hackage [3]. The source code [4] is well-factored and
uses functional reactive programming (FRP) to model time and user
input/output.

1\.
[http://www.haskell.org/haskellwiki/Applications_and_librarie...](http://www.haskell.org/haskellwiki/Applications_and_libraries/Games)

2\. <http://www.haskell.org/haskellwiki/Frag>

3\. [http://donsbot.wordpress.com/2009/08/06/haskell-package-
popu...](http://donsbot.wordpress.com/2009/08/06/haskell-package-popularity-
rankings-august-2009/)

4\. <http://code.haskell.org/frag/src/> (Darcs 'get' enabled)

------
jacquesm
this is a video of somebody playing tetris, it could have been programmed in
java, haskell or brainfuck for that matter.

Without the code to go with it haskell hasn't got much to do with it. Would be
nice to see the source!

~~~
whalesalad
Yeah, the source code would be very good to see.

~~~
jacquesm
If it _is_ programmed in brainfuck though I'm going to eat my hat or
something. Do penance in a major way ;)

~~~
ilyak
I'm afraid most brainfuck implementations don't have non-blockind IO;
therefore, you can't. Otherwise it would be very fun.

~~~
jacquesm
hm... time to get coding :)

maybe we can 'memory map' some of it ? Subsequent locations in memory that you
plot to a screen on over modificiation (b/w would be ok in this case I guess),
a bunch of bitfields that get 'latched' whenever a key is pressed that the
brainfuck mainloop has to walk by every now and then, resets and uses as
branching points ?

That should do it.

It doesn't need blocking io, see. Polling latched inputs is the way the
machines of old did it, it's a bit less efficient but it works.

------
amichail
Presumably this is newsworthy because building Tetris in Haskell is harder
than in an imperative/OO language? Why is that a good thing?

~~~
christopherdone
Presumably this is newsworthy because everyone assumes building Tetris in
Haskell is harder than in an imperative/OO language. This is a good thing
because it proves that it's not.

~~~
boblol123
He says its taken him a week to do it and has had to ask lots of people for
help. So I'd say its much harder than in a language like C#. I could (and so
could most other people here) make tetris in 1-2 days without help.

~~~
jcw
But the thing is, functional game development techniques are nowhere near as
developed or established as those of OO game development. The solutions to the
problems at hand aren't as immediately obvious.

This comes to mind: <http://prog21.dadgum.com/23.html>

~~~
amichail
You don't need to do anything non-trivial for imperative/OO game programming.

If something non-trivial is required for functional programming, then it is
more difficult.

~~~
xenoblitz
As far as I know there is nothing non-trivial that I had to use apart from
introducing state when it was needed by the game via monads and muteable
variables. At first they were tricky because I was used to taking such things
for granted.

What I can tell you is that the backend (which really needs no state) is much
more easier to write in Haskell IMHO.

------
kiba
There is an implementation of tetris in haskell with the source code:
<http://web.comlab.ox.ac.uk/people/Ian.Lynagh/Hetris/>

I discovered it when a regular contributor contributed an article on the game
to my FOSS gaming encyclopedia.

~~~
gtt
Could you provide the link to the encyclopedia of yours?

~~~
kiba
Since you wishes so: <http://libregamewiki.org>

~~~
gtt
tnx!

