[gameprogrammer] Re: Designing a language
- From: gorm <gorm@xxxxxx>
- To: gameprogrammer@xxxxxxxxxxxxx
- Date: Fri, 23 Oct 2009 22:47:11 +0200
Hi Paulo,
Interesting blog, I haven't seen that before. I knew the deal about
Naughty Dog, though. If you do a search on Gamasutra.com, you can find a
large postmortem on Jax and Daxter, information is available on what
good and bad sides their lisp system GOAL had.
I am still hoping that some people here, have some experiences that they
would like to share?
Cheers,
Gorm
On Wed, 2009-10-21 at 23:53 +0200, Paulo Pinto wrote:
> Hi,
>
> although not directly related to your question, this might be of
> interest to you.
>
> Abuse is a well known game where Lisp was used:
>
> http://en.wikipedia.org/wiki/Abuse_%28video_game%29
> http://abuse.zoy.org/
>
> While googling for Lisp Games, I found the following blog
> http://lispgamesdev.blogspot.com/
>
> Crash Bandicot also used Lisp:
>
> http://www.franz.com/success/customer_apps/animation_graphics/naughtydog.lhtml
>
> Cheers,
> Paulo
>
> On Wed, Oct 21, 2009 at 10:53 PM, gorm <gorm@xxxxxx> wrote:
> Hi People,
>
> Being a bit of a lurker on this forum, I thought all the chat
> about
> designing a language in the Daydreaming thread, would be a
> perfect
> opportunity to talk about a project of mine.
>
> I am big fan of functional languages. In my last game company,
> 3 Lives
> Left, we used OCaml quite a bit. A problem was that there
> isn't that
> many game development libraries out for OCaml out there, so we
> ended up
> writing our own FFI layer for OGRE, SDL, etc. There exists
> automatic FFI
> generators like SWIG, but it doesn't really pass advanced C++
> code very
> well (like that in OGRE) and the interfaces it generates seem
> quite
> heavy.
>
> The problem with the approach above is that it does not work
> very well
> across platforms, especially when it comes to more
> embedded(like)
> platforms such as the iPhone, PSP Go, XBox 360, etc.
>
> Since then, having worked a bit with lisp, I have become a big
> fan of
> "interactive programming". Nothing beats developing or
> debugging a
> programming while it is actually running.
>
> So the new idea is to build a small, and very tiny C++ game
> and
> interpreter engine around a lisp interpreter. I am using the
> boost::spirit libraries for parsing, and it seems to work
> quite well.
> The basic idea is to have as much engine and game logic
> written in my
> lisp variant.
>
> Now, my fundamental problem is how to design a good interop
> (or ffi)
> layer? Ie. how do I design an easily extensible system, where
> I don't
> have to do a lot of C++ implementation everytime I want to
> introduce a
> new C++ type that can be reached from lisp? Ie how do I in a
> good way
> make it possible to create windows, build a physics system,
> instantiate
> a renderer, detect mouse input, etc in a coherent and clean
> manner from
> the lisp code?
>
> I have worked with one such system before, where each C++ type
> essentially agregated a scriptable type that acted as a bridge
> between
> the two domains. Though clever in some ways, the bridge type
> had to be
> extended with a new method whenever a new method was added to
> a
> scriptable C++ type, and so forth.
>
> Any good ideas, links, comments, etc?
>
> Cheers,
> Gorm
>
>
> ---------------------
> To unsubscribe go to
> http://gameprogrammer.com/mailinglist.html
>
>
>
---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html
Other related posts:
