From: Levi Conley
Subject: What would a game loop look like in Lisp?
Date: 
Message-ID: <ff18f689.0111160133.879cda8@posting.google.com>
Suppose you wanted to write a Doom clone in Lisp (let's just assume
for a second you could hack out 15-20 frames per second in the
graphics).  Can anyone give me an outline of how to do the game loop? 
I don't have the kahunas just yet to tackle that project, but I may
well attempt an interactive text adventure (real time, not turn-based)
when I get a little more Lisp experience under my belt.

BTW, does anyone know of any Lisp gaming efforts?  I don't imagine one
could produce state of the art first-person-shooters, but 20 frames
per second 2.5D sprite games ought to be reasonable, and it seems to
me that trading off some graphics for more intelligent game play would
be a worthwhile endeavor.

From: Michael Hudson
Subject: Re: What would a game loop look like in Lisp?
Date: 
Message-ID: <uvggbjajr.fsf@python.net>
···············@cs.com (Levi Conley) writes:

> BTW, does anyone know of any Lisp gaming efforts?

I think much of the logic of Crash Bandicoot was written in a kind of
bizarre hacked-up lisp dialect (there was an article on gamasutra
about it, but it seems one needs to register to see it now and I can't
be bothered).

> I don't imagine one could produce state of the art
> first-person-shooters, but 20 frames per second 2.5D sprite games
> ought to be reasonable, and it seems to me that trading off some
> graphics for more intelligent game play would be a worthwhile
> endeavor.

I don't think you're the only one.  I think it's more usual to write
the game engine in C/assembler/whatever and then drive the engine in
lisp/other high level language.

Cheers,
M.

-- 
  (Unfortunately, while you get Tom Baker saying "then we 
   were attacked by monsters", he doesn't flash and make 
  "neeeeooww-sploot" noises.)
      -- Gareth Marlow, ucam.chat, from Owen Dunn's review of the year
From: Greg Menke
Subject: Re: What would a game loop look like in Lisp?
Date: 
Message-ID: <m3elmyyhdn.fsf@europa.pienet>
> 
> > BTW, does anyone know of any Lisp gaming efforts?
> 
> I think much of the logic of Crash Bandicoot was written in a kind of
> bizarre hacked-up lisp dialect (there was an article on gamasutra
> about it, but it seems one needs to register to see it now and I can't
> be bothered).
> 

You can often get around their login foolishness by searching in
Google and grabbing the cached copy.  But if the article was published
after they started the login stuff, you may be stuck with getting a
login and yet more spam.

Gregm
From: Mark Dalgarno
Subject: Re: What would a game loop look like in Lisp?
Date: 
Message-ID: <u3d3ff0i4.fsf@scientia.com>
Michael Hudson <···@python.net> writes:

> ···············@cs.com (Levi Conley) writes:
> 
> > BTW, does anyone know of any Lisp gaming efforts?
> 
> I think much of the logic of Crash Bandicoot was written in a kind of
> bizarre hacked-up lisp dialect (there was an article on gamasutra
> about it, but it seems one needs to register to see it now and I can't
> be bothered).

http://www.franz.com/success/customer_apps/animation_graphics/index.lhtml

Has some links of relevance.

Mark
From: Jochen Schmidt
Subject: Re: What would a game loop look like in Lisp?
Date: 
Message-ID: <9t32cm$dad$1@rznews2.rrze.uni-erlangen.de>
Levi Conley wrote:

> Suppose you wanted to write a Doom clone in Lisp (let's just assume
> for a second you could hack out 15-20 frames per second in the
> graphics).  Can anyone give me an outline of how to do the game loop?
> I don't have the kahunas just yet to tackle that project, but I may
> well attempt an interactive text adventure (real time, not turn-based)
> when I get a little more Lisp experience under my belt.
> 
> BTW, does anyone know of any Lisp gaming efforts?  I don't imagine one
> could produce state of the art first-person-shooters, but 20 frames
> per second 2.5D sprite games ought to be reasonable, and it seems to
> me that trading off some graphics for more intelligent game play would
> be a worthwhile endeavor.

There are OpenGL bindings for several Lispsystems (ACL, CMUCL, LW).
The main problem you may face is probably not general speed but more
the Garbage Collector. In a 3D-Shooter even a little pause is recognizable
while running steadily through some dungeon. But it is probably possible
to tune the GC for the running program in a way that makes the whole thing
usable.

--
http://www.dataheaven.de
From: Janis Dzerins
Subject: Re: What would a game loop look like in Lisp?
Date: 
Message-ID: <878zd6et8r.fsf@asaka.latnet.lv>
···············@cs.com (Levi Conley) writes:

> Suppose you wanted to write a Doom clone in Lisp (let's just assume
> for a second you could hack out 15-20 frames per second in the
> graphics).  Can anyone give me an outline of how to do the game loop? 

Why would a game loop in Lisp be different from game loop in any other
language?

> BTW, does anyone know of any Lisp gaming efforts?  I don't imagine one
> could produce state of the art first-person-shooters, but 20 frames
> per second 2.5D sprite games ought to be reasonable, and it seems to
> me that trading off some graphics for more intelligent game play would
> be a worthwhile endeavor.

May I suggest looking at Abuse. It is a game (now public domain)
written in C++ with a Lisp interpreter for game character
manipulation. Crack.com went out of business before finishing the
other game (Golgotha) featuring a much more sophisticated game engine
with better Lisp. Its souces are also public domain and there is also
an opensource effort going on on the game.

-- 
Janis Dzerins

  Eat shit -- billions of flies can't be wrong.
From: Paul Wallich
Subject: Re: What would a game loop look like in Lisp?
Date: 
Message-ID: <pw-1611011243090001@192.168.1.100>
In article <··············@asaka.latnet.lv>, Janis Dzerins
<·····@latnet.lv> wrote:

>···············@cs.com (Levi Conley) writes:
>
>> Suppose you wanted to write a Doom clone in Lisp (let's just assume
>> for a second you could hack out 15-20 frames per second in the
>> graphics).  Can anyone give me an outline of how to do the game loop? 
>
>Why would a game loop in Lisp be different from game loop in any other
>language?

I think doing a game in Lisp might make it clearer (especially if you have
some access to threading) that packing the whole thing into a single loop
isn't necessarily the way to go. There's obviously going to be a repeating
task along the lines of DisplayCurrentWorldState, but everything else need
not be synchronous, and in fact you can make some interesting things happen
in the gameplay by trading off the "intelligence" of some of your objects 
against their reaction time.

(You could also do this within the context of a single loop by only allowing
each thing to execute a fixed quantum of instructions, but that could be
ugly. Or maybe not)

But mostly Moore's Law makes the question of language for gameplay
irrelevant -- rendering eats the vast majority of your time.

paul
From: Janis Dzerins
Subject: Re: What would a game loop look like in Lisp?
Date: 
Message-ID: <87y9l6d0hq.fsf@asaka.latnet.lv>
··@panix.com (Paul Wallich) writes:

> In article <··············@asaka.latnet.lv>, Janis Dzerins
> <·····@latnet.lv> wrote:
> 
> >···············@cs.com (Levi Conley) writes:
> >
> >> Suppose you wanted to write a Doom clone in Lisp (let's just assume
> >> for a second you could hack out 15-20 frames per second in the
> >> graphics).  Can anyone give me an outline of how to do the game loop? 
> >
> >Why would a game loop in Lisp be different from game loop in any other
> >language?
> 
> I think doing a game in Lisp might make it clearer (especially if you have
> some access to threading) that packing the whole thing into a single loop
> isn't necessarily the way to go. There's obviously going to be a repeating
> task along the lines of DisplayCurrentWorldState, but everything else need
> not be synchronous, and in fact you can make some interesting things happen
> in the gameplay by trading off the "intelligence" of some of your objects 
> against their reaction time.

The problem of DisplayCurrentWorldState running asynchronously is that
it needs a snapshot of the world state or otherwise you get the effect
like when drawing something on the screen simultanously with the
monitor (as opposed to blitting the whole thing while monitor is
retracing; I may be messing up terminology but it's been a while I did
these kind of things).

> (You could also do this within the context of a single loop by only allowing
> each thing to execute a fixed quantum of instructions, but that could be
> ugly. Or maybe not)

This is a better approach since now you can adjust game speed and not
influence computer opponent's smartness. (And if the computer can't
keep up with the frame rate, the frame rate will drop, not the
smartness of computer opponents.)

> But mostly Moore's Law makes the question of language for gameplay
> irrelevant -- rendering eats the vast majority of your time.

And rendering stuff can be written in as low-lewel language as
necessary.

-- 
Janis Dzerins

  Eat shit -- billions of flies can't be wrong.
From: Paul Wallich
Subject: Re: What would a game loop look like in Lisp?
Date: 
Message-ID: <pw-1711011432370001@192.168.1.100>
In article <··············@asaka.latnet.lv>, Janis Dzerins
<·····@latnet.lv> wrote:

>The problem of DisplayCurrentWorldState running asynchronously is that
>it needs a snapshot of the world state or otherwise you get the effect
>like when drawing something on the screen simultanously with the
>monitor (as opposed to blitting the whole thing while monitor is
>retracing; I may be messing up terminology but it's been a while I did
>these kind of things).

The video tearing or equivalent thing is at a much smaller granularity than
what I think you would be worrying about. The current state of the world
would have a series of objects with positions and orientations (and damage
conditions or whatever), and the renderer would deal with getting the lines,
polygons and textures right. 

There would obviously be some interesting display consistency issues, where
things that didn't quite make the display deadline in a given cycle would 
appear in a different place from where they "really were", but I sorta see that
as a feature, not a bug.

>> (You could also do this within the context of a single loop by only allowing
>> each thing to execute a fixed quantum of instructions, but that could be
>> ugly. Or maybe not)
>
>This is a better approach since now you can adjust game speed and not
>influence computer opponent's smartness. (And if the computer can't
>keep up with the frame rate, the frame rate will drop, not the
>smartness of computer opponents.)

But it doesn't make sense (except insofar as you want to be in the geek
hardware wars) to tie the rate at which new frames are displayed to the
rate at which _all_ information in the system gets calculated. Different
gizmos on your universe will be able to change position/velocity/etc
at different speeds, i.e. be more or less maneuverable, but in a properly
designed game architecture that should be orthogonal to what appears 
on the screen.

Of course part of the problem is that you have to think at a fairly deep
level about just how to implement "intelligence" for your gizmos, and
probably develop several little languages to program them in...

paul
From: Janis Dzerins
Subject: Re: What would a game loop look like in Lisp?
Date: 
Message-ID: <87u1vrc8kt.fsf@asaka.latnet.lv>
··@panix.com (Paul Wallich) writes:

> In article <··············@asaka.latnet.lv>, Janis Dzerins
> <·····@latnet.lv> wrote:
> 
> >The problem of DisplayCurrentWorldState running asynchronously is that
> >it needs a snapshot of the world state or otherwise you get the effect
> >like when drawing something on the screen simultanously with the
> >monitor (as opposed to blitting the whole thing while monitor is
> >retracing; I may be messing up terminology but it's been a while I did
> >these kind of things).
> 
> The video tearing or equivalent thing is at a much smaller granularity than
> what I think you would be worrying about. The current state of the world
> would have a series of objects with positions and orientations (and damage
> conditions or whatever), and the renderer would deal with getting the lines,
> polygons and textures right. 

And getting it right in a multithreaded evironment is, well, more
complicated than in single threaded. So in order to have all objects
stay where they are so they can be drawn correctly, the rendering
thread must be synchronized with the game logistics part (this is the
"snapshot" part I mentioned abov) at least at a game object level.

> There would obviously be some interesting display consistency
> issues, where things that didn't quite make the display deadline in
> a given cycle would appear in a different place from where they
> "really were", but I sorta see that as a feature, not a bug.

I don't quite get at what you mean by "display deadline".

> >> (You could also do this within the context of a single loop by
> >> only allowing each thing to execute a fixed quantum of
> >> instructions, but that could be ugly. Or maybe not)
> >
> >This is a better approach since now you can adjust game speed and not
> >influence computer opponent's smartness. (And if the computer can't
> >keep up with the frame rate, the frame rate will drop, not the
> >smartness of computer opponents.)
> 
> But it doesn't make sense (except insofar as you want to be in the geek
> hardware wars) to tie the rate at which new frames are displayed to the
> rate at which _all_ information in the system gets calculated.

That's why we have quantums here. It is not necessary to execute all
code at every frame (although I did all processing every frame the
last time I wrote these toys).

> Different gizmos on your universe will be able to change
> position/velocity/etc at different speeds, i.e. be more or less
> maneuverable, but in a properly designed game architecture that
> should be orthogonal to what appears on the screen.

That's right -- since you know the speed and time since last frame,
you can calculate the position. That's what I did, and it might be
(and I think is, now) a very bad way to do it.

> Of course part of the problem is that you have to think at a fairly deep
> level about just how to implement "intelligence" for your gizmos, and
> probably develop several little languages to program them in...

The little language you mention is irrelevant to the fact that some
code that does "intelligence" part must be run sometimes -- how often
and for how long is also irrelevant at the level we speak.

The "quantum" model is very suited for fixed frame rate games (I just
don't get why people want to get those 200 and more frames-per-second
if the refresh rate of monitors is around 100Hz (depens on monitor and
video card, of course)). It is not the only way to do it, but it
should not be dismissed as useless.

There are also games where every frame is not completely redrawn each
time, althogh I can't think of any such 3D game. But games used to be
fun before the "first person shooters" era.

-- 
Janis Dzerins

  Eat shit -- billions of flies can't be wrong.
From: Levi Conley
Subject: Re: What would a game loop look like in Lisp?
Date: 
Message-ID: <ff18f689.0111161517.6fab9c53@posting.google.com>
Janis Dzerins <·····@latnet.lv> wrote in message news:<··············@asaka.latnet.lv>...
> ···············@cs.com (Levi Conley) writes:
> 
> > Suppose you wanted to write a Doom clone in Lisp (let's just assume
> > for a second you could hack out 15-20 frames per second in the
> > graphics).  Can anyone give me an outline of how to do the game loop? 
> 
> Why would a game loop in Lisp be different from game loop in any other
> language?

That's what I want to know.  You'll have to forgive my Lisp naivete. 
I am still very much a newbie, trying to get my mind properly wrapped
around functional programming.  I just don't know what the
possibilities are.  Would you want to warp Lisp into a C++ like event
loop structure, or are there better, more elegant ways to do it?
From: Christopher Stacy
Subject: Re: What would a game loop look like in Lisp?
Date: 
Message-ID: <u8zd6jb8i.fsf@spacy.Boston.MA.US>
>>>>> On 16 Nov 2001 15:17:37 -0800, Levi Conley ("Levi") writes:

 Levi> Janis Dzerins <·····@latnet.lv> wrote in message news:<··············@asaka.latnet.lv>...
 >> ···············@cs.com (Levi Conley) writes:
 >> 
 >> > Suppose you wanted to write a Doom clone in Lisp (let's just assume
 >> > for a second you could hack out 15-20 frames per second in the
 >> > graphics).  Can anyone give me an outline of how to do the game loop? 
 >> 
 >> Why would a game loop in Lisp be different from game loop in any other
 >> language?

 Levi> That's what I want to know.  You'll have to forgive my Lisp naivete. 
 Levi> I am still very much a newbie, trying to get my mind properly wrapped
 Levi> around functional programming.  I just don't know what the
 Levi> possibilities are.  Would you want to warp Lisp into a C++ like event
 Levi> loop structure, or are there better, more elegant ways to do it?

Lisp does not impose any particular control structure on you,
so you can implement an event loop if you like.
(Same thing for C++ by the way.)
From: Barry Margolin
Subject: Re: What would a game loop look like in Lisp?
Date: 
Message-ID: <wUaJ7.46$I25.5573@burlma1-snr2>
In article <···························@posting.google.com>,
Levi Conley <···············@cs.com> wrote:
>BTW, does anyone know of any Lisp gaming efforts?

I think there was a version of Mazewar that ran on the original MIT Lisp
Machines.  That game (which I think was originally implemented on the Xerox
Stars) could probably be considered the great-granddaddy of all
first-person shoot-em-up games.

-- 
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Kent M Pitman
Subject: Re: What would a game loop look like in Lisp?
Date: 
Message-ID: <sfw8zd6wu4i.fsf@shell01.TheWorld.com>
Barry Margolin <······@genuity.net> writes:

> In article <···························@posting.google.com>,
> Levi Conley <···············@cs.com> wrote:
> >BTW, does anyone know of any Lisp gaming efforts?
> 
> I think there was a version of Mazewar that ran on the original MIT Lisp
> Machines.  That game (which I think was originally implemented on the Xerox
> Stars) could probably be considered the great-granddaddy of all
> first-person shoot-em-up games.

Really? Not wumpus or asteroids? Mazewar was multi-user, though, I guess.
From: Barry Margolin
Subject: Re: What would a game loop look like in Lisp?
Date: 
Message-ID: <z9dJ7.49$I25.6001@burlma1-snr2>
In article <···············@shell01.TheWorld.com>,
Kent M Pitman  <······@world.std.com> wrote:
>Barry Margolin <······@genuity.net> writes:
>
>> In article <···························@posting.google.com>,
>> Levi Conley <···············@cs.com> wrote:
>> >BTW, does anyone know of any Lisp gaming efforts?
>> 
>> I think there was a version of Mazewar that ran on the original MIT Lisp
>> Machines.  That game (which I think was originally implemented on the Xerox
>> Stars) could probably be considered the great-granddaddy of all
>> first-person shoot-em-up games.
>
>Really? Not wumpus or asteroids? Mazewar was multi-user, though, I guess.

I don't know wumpus, but I don't consider Asteroids to be in the
"first-person shoot-em-up" category.  It's a third-person game, because the
perspective is from outside the spaceship.  In F-P S-E-U games, the
player's perspective is that of the shooter, and they typically involve
traveling through a scenario of some kind (e.g. the maze in Mazewar) to
encounter things to shoot at.

-- 
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Janis Dzerins
Subject: Re: What would a game loop look like in Lisp?
Date: 
Message-ID: <873d3eeidv.fsf@asaka.latnet.lv>
Barry Margolin <······@genuity.net> writes:

> In article <···························@posting.google.com>,
> Levi Conley <···············@cs.com> wrote:
> >BTW, does anyone know of any Lisp gaming efforts?
> 
> I think there was a version of Mazewar that ran on the original MIT Lisp
> Machines.  That game (which I think was originally implemented on the Xerox
> Stars) could probably be considered the great-granddaddy of all
> first-person shoot-em-up games.

I forgot to mention the "feebs" game. I run it in CMU CL with CLX
without problems. Check
http://ww.telent.net/cliki/Planet%20of%20the%20Feebs.

-- 
Janis Dzerins

  Eat shit -- billions of flies can't be wrong.
From: Richard Krush
Subject: Re: What would a game loop look like in Lisp?
Date: 
Message-ID: <9t9p0n$17814$1@ID-60069.news.dfncis.de>
Levi Conley <···············@cs.com> wrote:
>
> [snip]
>
> BTW, does anyone know of any Lisp gaming efforts?  I don't imagine one
> could produce state of the art first-person-shooters, but 20 frames
> per second 2.5D sprite games ought to be reasonable, and it seems to
> me that trading off some graphics for more intelligent game play would
> be a worthwhile endeavor.

Perhaps that's not really what you meant, but there is an open-source
project called LAngband, which is a Lisp clone of the rogue/nethack-like
game called Angband (which has many other implementations as well). It's
using the ASCII chachacters instead of the graphics, but I think it doesn't
really matter. The homepage of the game can be found at the following
address:
    <http://langband.sourceforge.net/>

Hope this helps,
  rk

-- 
 Richard Krushelnitskiy   "I know not with what weapons World War III will
 ·········@gmx.net         be fought, but World War IV will be fought with
 http://rkrush.cjb.net     sticks and stones." -- Albert Einstein