[Haskell] ANNOUNCE: Frag: a First Person Shooting game
Mun Hon Cheong
Features:
*Yampa, a domain-specific embedded language
for the programming of hybrid systems that
using the concepts of Functional Reactive
Programming (FRP) was used to program the
game entities.
*The Quake 3 BSP level format, Q3Map2,
and the MD3 format for models and
animations are used in this game.
*Sven Panne's OpenGL binding, HOpenGL is
used to render graphics.
Requirements:
HOpenGL which is provided with GHC
OpenGL drivers that support the vertex array
and multitexture OpenGL extensions
Darcs: darcs get http://www.cse.unsw.edu.au/~pls/repos/frag
Thanks goes to Don Stewart, this project would not
have become public if not for him.
Enjoy,
Mun
_______________________________________________
Haskell mailing list
Has...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Tomasz Zielonka
> Frag is a 3D First Person Shooting game.
I would be nice if you could put some screenshots somewhere.
Best regards
Tomasz
Donald Bruce Stewart
> On Tue, Nov 22, 2005 at 05:05:17PM +1100, Mun Hon Cheong wrote:
> > Frag is a 3D First Person Shooting game.
> I would be nice if you could put some screenshots somewhere.
A wiki page has been put up on haskell.org, with screenshots:
http://haskell.org/hawiki/Frag
-- Don
Joel Reymont
I hope this ushers the era of Haskell games! I, for one, was
certainly looking for something like this.
Did you encounter any difficulties in your development because of
Haskell?
Was lazy evaluation ever a problem?
Why did you choose Yampa to program the game entities? Did this give
you a particular advantage?
Isn't your frame rate a bit low?
Thanks, Joel
On Nov 22, 2005, at 6:05 AM, Mun Hon Cheong wrote:
> Frag is a 3D First Person Shooting game.
>
> Features:
>
> *Yampa, a domain-specific embedded language
> for the programming of hybrid systems that
> using the concepts of Functional Reactive
> Programming (FRP) was used to program the
> game entities.
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Kenneth Hoste
> Frag is a 3D First Person Shooting game.
>
> Features:
>
> * <snip>
This is a real cool Haskell project, and I think a lot of people will
agree with me.
Also, many people will wonder what problems you were faced with, how you
solved them,
which features you used, and so on... (see Joel Reymont's post).
It might be a good idea to answer all those questions at once: write a
TMR article on it !
TMR is a e-zine which provides non-academic though interesting articles
on topics concerning Haskell.
I think your Frag project is an ideal candidate for a TMR article. Don't
worry about 'that's for smart people',
the level of difficulty of the articles varies a lot (which doesn't make
them less interesting).
If you're interested (or someone else is, on any topic), please ask
people (shapr, boegel, ...) in the #haskell channel on
irc.freenode.org, mail the editor (Shae Erisson, see the wiki
[http://haskell.org/tmrwiki] for more info), or just simply
reply to this mail.
Hope to hear from you,
boegel
--
Statistics are like a bikini. What they reveal is suggestive, but what they conceal is vital (Aaron Levenstein)
Kenneth Hoste
ELIS - Ghent University
http://elis.ugent.be/~kehoste
Sebastian Sylvan
> Frag is a 3D First Person Shooting game.
>
> Features:
>
> *Yampa, a domain-specific embedded language
> for the programming of hybrid systems that
> using the concepts of Functional Reactive
> Programming (FRP) was used to program the
> game entities.
>
> *The Quake 3 BSP level format, Q3Map2,
> and the MD3 format for models and
> animations are used in this game.
>
> *Sven Panne's OpenGL binding, HOpenGL is
> used to render graphics.
>
> Requirements:
>
> HOpenGL which is provided with GHC
>
> OpenGL drivers that support the vertex array
> and multitexture OpenGL extensions
>
> Darcs: darcs get http://www.cse.unsw.edu.au/~pls/repos/frag
>
> Thanks goes to Don Stewart, this project would not
> have become public if not for him.
>
This is really cool.
I too would like to read a post-mortem on this project. What worked
well, what didn't, etc.
There aren't a lot of game engines written in Haskell so it would be
interesting to see how it worked out for you.
/S
--
Sebastian Sylvan
+46(0)736-818655
UIN: 44640862
Sven Panne
> This is really cool.
Yes, I am really impressed, too! Finally Haskell enters the world we the real
big bucks are made, e.g. Electronic Arts alone made a $3.1 billion annual
revenue last year. :-)
> I too would like to read a post-mortem on this project. What worked
> well, what didn't, etc.
> There aren't a lot of game engines written in Haskell so it would be
> interesting to see how it worked out for you.
As the developer/maintainer of the OpenGL and GLUT packages used, I would be
highly interested in a post-mortem, too, especially regarding the API design,
missing features, etc. Some years ago I wrote a Quake 1 level viewer (still
in my old HOpenGL tar files somewhere) and one could see hickups due to GC,
but this doesn't seem to be an issue anymore. Nice!
Of course the next step should be using the OpenAL/ALUT packages to hear the
screams of your enemies when you frag them... >:-)
http://haskell.org/HOpenGL/newAPI/OpenAL/Sound-OpenAL.html
http://haskell.org/HOpenGL/newAPI/ALUT/Sound-ALUT.html
Cheers,
S.
P.S.: Some commandline options for choosing the resolution or full-screen
rendering and "invert mouse" would be highly appreciated.
Mun Hon Cheong
Did you encounter any difficulties in your
development because of Haskell?
Well, Haskell is different compared with other languages
like C. I thought collision detection would be easier
if i could use some local or global variables, but i
managed to get around it.
Was lazy evaluation ever a problem?
I found some space leaks in the game, so i had to profile and
enforce strictness in some areas.
Why did you choose Yampa to program the game
entities? Did this give you a particular advantage?
Me and Sean Seefried thought it that would be interesting
to use FRP in the game. I thought the design of
the Space Invaders game in the paper "The Yampa Arcade"
would work for this game and it did.
We could use Yampa's parallel switchers to simulate game
entities simultaneously without much trouble. I felt
that Yampa offered good encapsulation. State information
could be kept inside the signal function used to define the game entity
and they were updated within that function. So with a
well designed interface we could add game entities without major
changes to the rest of the program.
Isn't your frame rate a bit low?
Yeah, it does run slower than Quake 3 which would run on
my Pentium II 350 and voodoo3 , currently i doubt my game could do
the same.
I'm sure there are optimisations that could be used to improve
the games performance.
On my machine with an Athlon 1900+ and a Geforce 4mx the game
runs at 60fps in "leveleg". If you find that the framerate
doesn't go above 60fps, its because its capped at 60.
HopenGL
I didn't find any missing features.
Perhaps a listing of functions that have changed significantly
from the original API could be made? ( I've forgotten which functions
that I had trouble looking for though, but it wasn't because their
gl prefixes were removed)
regards,
Mun
Jens Petersen
> Frag is a 3D First Person Shooting game.
Thanks for releasing this!
It built fine for me with ghc-6.4.1 on Fedora Core 4 x86_64,
but when I run it I get:
frag% ./a.out leveleg
:
:
"loaded textures/egyptians/sand_egy.tga"
"loaded textures/egyptians/leaf.tga"
"loaded textures/egyptians/gold_trim02.tga"
"missing texture: models/mapobjects/Skull/skull.tga"
"missing texture: textures/common/trigger.tga"
"loaded textures/egyptians/oldstone_ramses.tga"
"missing texture: textures/sfx/hellfog.tga"
*** glibc detected *** ./a.out: malloc(): memory corruption: 0x0000000000807f90 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3d03d6b79e]
/lib64/libc.so.6(malloc+0x7b)[0x3d03d6cb3b]
/a.out[0x58aa95]
======= Memory map: ========
:
:
Minimal gdb backtrace:
Program received signal SIGABRT, Aborted.
[Switching to Thread 46912496296672 (LWP 20343)]
0x0000003d03d2f280 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x0000003d03d2f280 in raise () from /lib64/libc.so.6
#1 0x0000003d03d30750 in abort () from /lib64/libc.so.6
#2 0x0000003d03d64a7f in __libc_message () from /lib64/libc.so.6
#3 0x0000003d03d6b79e in _int_malloc () from /lib64/libc.so.6
#4 0x0000003d03d6cb3b in malloc () from /lib64/libc.so.6
#5 0x000000000058aa95 in ForeignziMarshalziAlloc_zdwccall2_info ()
#6 0x0000000000000028 in ?? ()
#7 0x0000000000000000 in ?? ()
Jens
Sven Panne
> [...]
> "loaded textures/egyptians/leaf.tga"
> "loaded textures/egyptians/gold_trim02.tga"
> "missing texture: models/mapobjects/Skull/skull.tga"
> "missing texture: textures/common/trigger.tga"
> "loaded textures/egyptians/oldstone_ramses.tga"
> "missing texture: textures/sfx/hellfog.tga"
> *** glibc detected *** ./a.out: malloc(): memory corruption:
> 0x0000000000807f90 *** ======= Backtrace: =========
> /lib64/libc.so.6[0x3d03d6b79e]
> /lib64/libc.so.6(malloc+0x7b)[0x3d03d6cb3b]
> [...]
A quick look into the frag sources reveals that its I/O assumes 32bit
little-endian (i.e. x86-like) memory layout, so there's no surprise that it
segfaults on x86-64. This should be easily fixable, I think... Mun?
Cheers,
S.
Daniel Örstadius
Running "ghc --make -O2 -fglasgow-exts main.hs" gives
..
Compiling Quaternion ( ./Quaternion.hs,
/Quaternion.o )
Compiling ReadImage ( ./ReadImage.hs,
/ReadImage.o )
/ReadImage.hs:60:
Type constructor or class not in scope:
`PixelData'
/ReadImage.hs:68: Data constructor not in scope:
`PixelData'
I am using ghc 6.2.2. I have tried adding "-package
GLUT" to the command line, but still the same output.
Daniel
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
Sven Panne
> [...] I am using ghc 6.2.2. I have tried adding "-package
> GLUT" to the command line, but still the same output.
The problem comes from an API change in the OpenGL package about 2 years ago.
Upgrading to a GHC 6.4.x should help.
Cheers,
S.