[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Game Logic

Jan Ekholm wrote:

> I think SWIG will do this quite nicely for both Perl and Python. You can
> the manually adjust things where needed for optimal performance. This is
> the way I've been thinking of going for my scripting needs.

Yes, type-mapping is eased by Swig, but I have a system (XPLC,
http://xplc.sourceforge.net/) that uses COM-like interface classes which
are juggled around. It's possible, but I'm trying to make it dynamic, so
that if a new class is loaded, front-end to the interfaces can be
generated on-the-fly by the embedding glue... I should work it out.

In particular, I want the information to be in a fixed format which
could be used by different scripting engines. So I could have *both*
Perl and Python in a single game and interacting together. :-)

> > 100% agreeing on this. I hear some people did Perl and Python bindings
> > for libraries like SDL and OpenGL. I wonder if at some point, we'll just
> > write whole games in a scripting language, then profile and convert to C
> > only the slower parts...
> I've used the Python bindings for SDL a little bit. They work quite nicely
> and make it really easy to create gfx games using Python. Obviously this
> is not that way to go for fps Quake-like games, but hey, those are just a
> narrow sector of all games (I'd like to think...). :-)

Well, if you push the profiling enough, you will get to the point of
Quake3 for example, where the menus and a gameplay logic is done in QVM
code and basically only the rendering parts are done by native code...

But I agree that being able to hack a nice graphical game totally in a
script language with something like PySDL is very cool.

"The only 'intuitive' interface is the nipple. After that, it's
all learned." -- bediger@teal.csn.org (on user interfaces)

To unsubscribe, e-mail: linuxgames-unsubscribe@sunsite.auc.dk
For additional commands, e-mail: linuxgames-help@sunsite.auc.dk