The following I post without followup on my part. I'm currently
unsubscribed to get some work done. I am curious what you folks will make
of this.
Will Wright of SimCity / TheSims fame has recently announced his next game,
"Spore." All content is procedurally generated, and the scale of the game
spans from the microscopic to the galactic. The scope of ambition of this
work is creating quite a ripple in the game industry.
http://gonshaw.net/musings/2005/musing_03_16_05.htm
http://www.1up.com/do/previewPage?cId=3138792&did=1
http://www.gamasutra.com/gdc2005/features/20050315/postcard-diamante.htm
3D procedural content strikes me as an excellent vector for the
popularization of Lisp within the game industry. Also, games are visible
both to geeks and the public at large. Finally, Lisp success stories within
the game industry are known - Naughty Dog, Square - if not numerous. A
viable marketing plan for the aggrandizement of Lisp probably exists here,
but of course much R&D would have to be performed.
Whether 3D procedural content becomes "a rage" is going to depend very much
on whether Spore fulfils its potentials. I believe the success of Spore may
not be so much whether it is a good game, but whether it provides art tools
to the general public with an exceedingly low learning curve.
I don't currently know the technical basis of Spore. I'll be asking around
to see if anybody does.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
When no one else sells courage, supply and demand take hold.
Brandon J. Van Every <·····························@yahoo.com> schrieb:
> Will Wright of SimCity / TheSims fame has recently announced his next game,
> "Spore." All content is procedurally generated, and the scale of the game
> spans from the microscopic to the galactic.
I think the lesson here is that vision and creativity are more important
for making successful games than the particular programming language you
use.
Brandon J. Van Every wrote:
> 3D procedural content strikes me as an excellent vector for the
> popularization of Lisp within the game industry. Also, games are
visible
> both to geeks and the public at large. Finally, Lisp success stories
within
> the game industry are known - Naughty Dog, Square - if not numerous.
A
> viable marketing plan for the aggrandizement of Lisp probably exists
here,
> but of course much R&D would have to be performed.
I think it could be done but in the end it would succeed probably
despite of Lisp not because of it. Game design is a huge magnet. I am
teaching a game design course at the University of Colorado. We have to
fight off students. Part of my research is exploring how Lisp could be
used to make game development tools. Many of the existing game engines
require developer often many minutes to experience even a simple change
to their game because of the need to run make on a huge code base.
Then, they need to start the game from scratch, navigate to the point
of trouble and verify their mod. This sounds bad and could be replaced
with a much more fluid edit/run/debug cycle afforded by Lisp. But
people don't care much for Lisp.
Technical challenges include speed and garbage collection. Ephemeral
garbage makes all the difference but few Lisps implement one. Speed can
be achieved by making good use of hardware acceleration. The bigger
problem may be the mind set of the Lisp community which seems to be
more concerned talking about exciting things such as if using FIRST
instead of CAR is really a great idea, trying to optimize a few parens
away here and there, or if one really needs OOP.
This will get Lisp nowhere. Picking a target such as game
design/development we could pick a real NEW mission for Lisp. Give you
one example: programmable pixel and vertex shaders (see OpenGL Orange
Book). Look at it. It's nasty functional programming that needs to be
done at an assembler level. With a bit of joint effort we could write a
Lisp GPU shader compiler. Imagine writing little (super subset) Lisp
programs executing on your video board GPU at warp speed. Now that
would be cool!
Alex
Prof. Alexander Repenning, University of Colorado
Ingvar <······@hexapodia.net> wrote:
> Yes, it would be very cool. A first step would (probably) be to
> compile to, say, Cg. I've been looking around for specs for the shader
> "machine code" and while I've probably looked in the wrong places, I
> haven't had much luck yet.
perhaps a better idea would be to implement a compiler which compiles
Lisp to the low level pixel shader assembler, like defined by Microsoft
and I assume supported by most newer graphics cards:
http://tinyurl.com/6y686
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Why not target GLSL, the official opengl shader language? ATI and
nvidia probably have compilers for it. I'm pretty sure the nvidia sdk
has one.
Ingvar wrote:
> Frank Buss <··@frank-buss.de> writes:
>
>
>>Ingvar <······@hexapodia.net> wrote:
>>
>>
>>>Yes, it would be very cool. A first step would (probably) be to
>>>compile to, say, Cg. I've been looking around for specs for the shader
>>>"machine code" and while I've probably looked in the wrong places, I
>>>haven't had much luck yet.
>>
>>perhaps a better idea would be to implement a compiler which compiles
>>Lisp to the low level pixel shader assembler, like defined by Microsoft
>>and I assume supported by most newer graphics cards:
>
>
> Possibly. I still haven't found an object format spec. I have a Cg
> comipler. I don't *think* I have a "Microsoft shader assembly language
> compiler". This may look like pointless whinging but it isn't. Once I
> get a bit more time, I'll devote more effort to searching.
>
> //Ingvar
Andy Cristina wrote:
> Why not target GLSL, the official opengl shader language? ATI and
> nvidia probably have compilers for it. I'm pretty sure the nvidia
sdk
> has one.
I would strongly second that. Ideally, it would be possible to create
"ShaderLisp" that, in the spirit of Lisp, it would be able to compile
and run without the need for an intermediate language. We have done
similar thing to compile Lisp into bytecode to run on the MIT
programmable brick (which became the Mindstorm brick) and Java
bytecode.
The hard part is to get started. I have not yet found some spec
explaining the bytecode and how to load it into the video board.
Perhaps the OpenGL Orange book - which i have not read yet - holds the
answers? http://3dshaders.com/shaderSource.html This site also contains
some code.
Did somebody look at this and reach some kind of conclusion?
I personally would prefer an OpenGL 2 based approach over MS specific
technology.
Alexander Repenning schrieb:
> The hard part is to get started. I have not yet found some spec
> explaining the bytecode and how to load it into the video board.
> Perhaps the OpenGL Orange book - which i have not read yet - holds the
> answers? http://3dshaders.com/shaderSource.html This site also contains
> some code.
In case of GLSL there is no bytecode. GLSL is the lowest level that you
can access from your application.
There is a highlevel shader metaprogramming library implemented in C++
which one should look at before starting a lisp-shaderlanguage:
http://libsh.org/
Andy Cristina wrote:
> Why not target GLSL, the official opengl shader language? ATI and
> nvidia probably have compilers for it. I'm pretty sure the nvidia
sdk
> has one.
I would strongly second that. Ideally, it would be possible to create
"ShaderLisp" that, in the spirit of Lisp, it would be able to compile
and run without the need for an intermediate language. We have done
similar thing to compile Lisp into bytecode to run on the MIT
programmable brick (which became the Mindstorm brick) and Java
bytecode.
The hard part is to get started. I have not yet found some spec
explaining the bytecode and how to load it into the video board.
Perhaps the OpenGL Orange book - which i have not read yet - holds the
answers? http://3dshaders.com/shaderSource.html This site also contains
some code.
Did somebody look at this and reach some kind of conclusion?
I personally would prefer an OpenGL 2 based approach over MS specific
technology.
"Alexander Repenning" <·····@cs.colorado.edu> wrote in message >
> I personally would prefer an OpenGL 2 based approach over MS specific
> technology.
>
If only for performance issues I'd rather have both and let the user
decide. The only problem is both are OS/C/C++ based interfaces.
What would a 3d game engine in Lisp interface look like?
Any suggested functions, macros, etc? Maybe we could start with
a Lisp specification and work down to an implementation even if
it required working with some C to produce a dll/so file.
--
Geoff