Script speed

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

I'm _still_ tinkering with my dungeon generation walkaround demo, and
have been considering a slight shift in the design, but I'm unsure
whether or not it's feasible.

Basically, my current approach is to code key bits of code, as well as
all data structures and containers, in C++, and to script the dungeon
generation process in Lua (and, in the future, to script most of the
game logic in Lua as well). Most of my problems have been (thus far)
problems caused by the interaction between the two systems. Now I'm
considering, why not do the whole thing in Lua, except for the
sound/display/input functions? My only concern is that running Lua in
the main game loop may cause speed issues. Any more experienced Lua
coders able to comment on Lua's speed? All my experience in Lua has
been on code far too small to make a valid judgement on it's performance.


--
My projects are currently on hold, but I do have
some junk at the site below.

http://www.freewebs.com/timsrl/index.htm

--

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Timothy Pruett wrote:
> I'm _still_ tinkering with my dungeon generation walkaround demo, and
> have been considering a slight shift in the design, but I'm unsure
> whether or not it's feasible.
>
> Basically, my current approach is to code key bits of code, as well as
> all data structures and containers, in C++, and to script the dungeon
> generation process in Lua (and, in the future, to script most of the
> game logic in Lua as well). Most of my problems have been (thus far)
> problems caused by the interaction between the two systems. Now I'm
> considering, why not do the whole thing in Lua, except for the
> sound/display/input functions? My only concern is that running Lua in
> the main game loop may cause speed issues. Any more experienced Lua
> coders able to comment on Lua's speed? All my experience in Lua has
> been on code far too small to make a valid judgement on it's performance.

I'd be more concerned about the maintainability of Lua when you scale
it to your entire game logic.

Since you don't have your compiler watching over you, you will have to
practice some more discipline.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

"Timothy Pruett" <drakalor.tourist@gmail.com> schrieb im Newsbeitrag
news:TfKdna3KtPYWol7fRVn-ig@adelphia.com...
> I'm _still_ tinkering with my dungeon generation walkaround demo, and have
> been considering a slight shift in the design, but I'm unsure whether or
> not it's feasible.
>
> Basically, my current approach is to code key bits of code, as well as all
> data structures and containers, in C++, and to script the dungeon
> generation process in Lua (and, in the future, to script most of the game
> logic in Lua as well). Most of my problems have been (thus far) problems
> caused by the interaction between the two systems. Now I'm considering,
> why not do the whole thing in Lua, except for the sound/display/input
> functions? My only concern is that running Lua in the main game loop may
> cause speed issues. Any more experienced Lua coders able to comment on
> Lua's speed? All my experience in Lua has been on code far too small to
> make a valid judgement on it's performance.

People around here are bold enough to use pure Slowthon and Cerl for their
RLs and you worry about Lua's performance?
I'm quite sure that if you code the very few speed critical parts of the
game (pathfinding, FOV, AI) in C performance shouldn't be an issue.

copx

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

One thing to be concerned about is the memory size. It seems to get a
little slower as the memory requirements grow. Garbage collection can
get pretty slow to. For a turn-based game though, this should be
alright.

There's also the point that you have to rely on garbage collection,
which can make managing object destruction a little more frustraiting
(no destructors to call).

Are you using any tools to help in binding your C/C++ code to Lua?
This could make things a lot easier. If you're coding your bindings by
hand, that would explain the problems.

I have several recommendations if you are interested, along with some
tips on methods on integrating them easilly.

I'm in agreement with Jeff about a compiler watching over you - it can
stop a lot of errors before they happen. I do think Lua is good for
the reflection, and flexability though. Lots of power in it.

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Timothy Pruett <drakalor.tourist@gmail.com> wrote:

[snip]

> My only concern is that running Lua in the main game loop may cause
> speed issues. Any more experienced Lua coders able to comment on
> Lua's speed? All my experience in Lua has been on code far too small
> to make a valid judgement on it's performance.

FWIW, my plan for the roguelike I'll probably never
write was to do it in Lua with lumps of C, and I wasn't worried about
the speed implications on my comparitively slow machines.

Lua's pretty quick, really - it's designed to be, which is a good start
- but it seems to compare favourably with other interpreted languages in
things like the Computer Language Shootout as well. I've never had any
problems with its speed which weren't solved by picking a better
algorithm or putting the number-crunching bits into C. Unfortunately, I
don't think even the most complex things I've done compare to the
complexity of a big roguelike.

Going by postings to the Lua mailing list there are many games (including
graphics-heavy ones which need a good performance between frames) using Lua,
but that tends to be in a hookable scripting role rather than as the main
implementation language. I'd say it's still a good sign that it'll be
fast enough for you though.

Lua 5.1 (coming soonish - preview versions are available now) should
offer at least one useful improvement for large projects as the garbage
collection has been improved to smooth it out and prevent any big pauses
while collection takes place. Though there are normally enough pauses
in a roguelike for you to schedule it when its convenient anyway.

HTH
--
Antony Sidwell.

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Arakon wrote:
> One thing to be concerned about is the memory size. It seems to get a
> little slower as the memory requirements grow. Garbage collection can
> get pretty slow to. For a turn-based game though, this should be
> alright.

That's a pretty big concern, since my target system is, well, my
Pentium II laptop with 128MB of RAM. It's a bit of a wasted effort to
develop a game that I can't even play and enjoy. Fortunately, someone
else mentioned that Lua 5.1 will take care of some garbage collection
issues, which will hopefully negate this problem.

> There's also the point that you have to rely on garbage collection,
> which can make managing object destruction a little more frustraiting
> (no destructors to call).

Most of my coding experience is with C++, and it always feels wierd to
not to have complete control over object destruction. It bugs me a
bit, but that just goes to show that I need to broaden my horizons some.

> Are you using any tools to help in binding your C/C++ code to Lua?
> This could make things a lot easier. If you're coding your bindings by
> hand, that would explain the problems.
>
> I have several recommendations if you are interested, along with some
> tips on methods on integrating them easilly.

So far, I have been doing them by hand, and it's a pain in the ass.
I'd love to hear your recommendations.

> I'm in agreement with Jeff about a compiler watching over you - it can
> stop a lot of errors before they happen. I do think Lua is good for
> the reflection, and flexability though. Lots of power in it.

Lua has pretty good error checking, and I've piddled around enough
with Perl and a few other similar languages to know to tread carefully
without a compiler watching my back.


--
My projects are currently on hold, but I do have
some junk at the site below.

http://www.freewebs.com/timsrl/index.htm

--

 

[Guest]

Archived from groups: rec.games.roguelike.development (More info?)

Timothy Pruett wrote:

> Now I'm
> considering, why not do the whole thing in Lua, except for the
> sound/display/input functions? My only concern is that running Lua in
> the main game loop may cause speed issues.

My project (no release yet, perhaps a developer's demo soon) uses
Objective Caml and my judgement on speed issues and interpreted
languages in general goes like this:
Development platform is a 400MHz PII.
For the NCurses interface, when compiled to native code, there are no
speed issues.
For the same interface, when running purely from interpreted bytecode,
it is noticeably slower, but still perfectly acceptable- it keeps up
with my typing speed and the typematic delay of my system, though in
fullscreen scrolling look_mode there is some slowdown. Not enough to be
crippling.
When running from interpreted bytecode using internal
machine-independent graphics primitives, it is too slow for comfort;
0.25 second turns or somesuch.
So you want graphics to be handled through compiled native code, as is
always the case, but basically I think you'll find that an efficient
interpreted language on fairly old hardware is perfectly acceptable
speed-wise.

> Most of my problems have been (thus far)
> problems caused by the interaction between the two systems.

This is the one to watch out for. When previously using Python (not
really a comparison with Lua, but anyway...) I always thought "if it
gets too slow I can always speed it up with C". Maybe true, but unless
you're *really* familiar with both, I believe switching between two
languages in one project, except for wrapping around external libraries,
is more effort than it's worth. Hence Objective Caml in my case.

--jude hungerford.