Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Questions about scripting

98 views
Skip to first unread message

Hansjörg Malthaner

unread,
Mar 20, 2002, 4:10:33 AM3/20/02
to
Hi,

following the discussion about Lua scripting in rgra, few questions about
the basics of scripting popped into my mind:


The very basic question:

- what functionality should be externalized into scripts?

Scripts (unlike datafiles) allow to externalize functionality. Usually they
are used to separate the engine code (hardcoded) from the games code
(scripts). Now, I'm unsure where to draw the line? What is part of the
engine, and what is part of the game. I.e. is a spells code part of the game
engine, or part of the game? Should the spell code be in a script or a
hardcoded program part?


If the separation of game code (scripts) and the engine (hardcoded) is the
way to go, the next questions are about the interface between those two:

- what should the game engine export to the scripts?
- how should scripts interact with the game engine?
- how should the interface expose the exports of the game engine to the
scripts (hereby I mean, how should the exports look like when used in a
script) ?

I'd be also interested to learn the reasons, why something should be
exported (or not) and why a certain type of interfacing is superior to
another.

Finally my thinking led me to the question: Is scripting needed at all for a
game? For example, Angband is a game. It lived 10+ years well without
scripting. Now there are tries to separate it into a engine and game
(script) code. Is this a good idea at all? Why did it work well for 10+
years without scripts if scripting is such a good idea? (IMO in case of
Angband scripting is a bad idea: the Angband engine isn't generic enough to
exist as game engine alone, and if it is always bundled with the scripts to
be played as Angband, the separtion of engine and game code was useless).


I'm asking because a while ago I was thinking about including a scripting
langauge in my own roguelike project, but never found a 'must have' reason
for scripting. Thus I went on without a scripting language. Now I see the
Angband maintainers have a strong idea that scripting is a 'must have' for
Angband, and I'm wondering, if my thinking was wrong.


Kind reagrds,
Hansjörg Malthaner

Astromarine

unread,
Mar 20, 2002, 8:19:31 AM3/20/02
to

My opinion? Angband lived well for a long time, but as a single project
with successive maintainers. Then Ben came along and externalized the
data files (*.txt) and cleared up the code, which counts as
"externalization" of the interfaces. This was what brought along the
flurry of variants, which can arguably be acknowledged as the main force
behind the game's progress and development since then. Robert is just
trying to continue on that vein, not make a big break with the past.
Scripting is IMHO the next logical step after externalizing the data
files.

>
> Kind reagrds,
> Hansjörg Malthaner

Abilio

Hansjörg Malthaner

unread,
Mar 20, 2002, 8:35:46 AM3/20/02
to

That's correct, but I had a few questions regarding scripting in general,
not neccesarily related to Angband but maybe answered with Angband in mind.
(Robert may do what he thinks is best for Angband, he does so anyways.)

I know it's bad stlye to leave that much text, but I've left the questions
unsnipped above, in hope that someone will answer them.

> Abilio

Kind reagrds,
Hansjörg Malthaner

Astromarine

unread,
Mar 20, 2002, 9:20:46 AM3/20/02
to
On Wed, 20 Mar 2002 14:35:46 +0100, Hansjörg Malthaner wrote:

Hi. I'm sorry for replying only to a point which is secondary in your
message, I just thought that your other questions were directed at the
maintainers only. I will try to answer them (since it beats working) with
my *personal* opinion.

> Astromarine wrote:
>>
>> On Wed, 20 Mar 2002 10:10:33 +0100, Hansjörg Malthaner wrote:
>>
>> > Hi,
>> >
>> > following the discussion about Lua scripting in rgra, few questions
>> > about the basics of scripting popped into my mind:
>> >
>> >
>> > The very basic question:
>> >
>> > - what functionality should be externalized into scripts?
>> >
>> > Scripts (unlike datafiles) allow to externalize functionality.
>> > Usually they are used to separate the engine code (hardcoded) from
>> > the games code (scripts). Now, I'm unsure where to draw the line?
>> > What is part of the engine, and what is part of the game. I.e. is a
>> > spells code part of the game engine, or part of the game? Should the
>> > spell code be in a script or a hardcoded program part?
>> >

I have some limited experience with this, due to my participation in a
few Ultima Online free shards. That experience made me think that
the answer should be "as much as humanly possible, barring performance
problems". This is, of course, based on one assumption: You *want* forks
and variantes. The Sphere engine for UO shards, for example, is pure
engine. People are *supposed* to make their own game out of it. But it
leaves things like damage calculations inside the engine. This allows
*only* for other UO shards which all *must* play exactly like the
original except for a few modifications on stuff like items. The shard I
played on has changed most parts of the game by ignoring the underlying
code and doing *everything* but the graphics and comms handling in
scripts. This means that the engine is hugely bloated with unnecessary
stuff in their case.

Angband has to make a decision which is not so hard, since the C code is
open as well. There is no design decision that variants must still play
like angband. Therefore, IMHO, everything should be changed to scripts
unless that causes a performance hit (which is not trivial. Angband is
supposed to work on stupidly ancient machines, and this is a good and
proper thing which I hope will never change.

>> >
>> > If the separation of game code (scripts) and the engine (hardcoded)
>> > is the way to go, the next questions are about the interface between
>> > those two:
>> >
>> > - what should the game engine export to the scripts? - how should
>> > scripts interact with the game engine? - how should the interface
>> > expose the exports of the game engine to the scripts (hereby I mean,
>> > how should the exports look like when used in a script) ?

>> > I'd be also interested to learn the reasons, why something should be
>> > exported (or not) and why a certain type of interfacing is superior
>> > to another.

I am of the opinion that the game engine should be as generic as
possible. Example: Angband wilderness. I think the standard engine (let's
call it the vanilla engine) should have a wilderness. This changes the
way Vanilla "feels", you say? Not at all: the vanilla wilderness *script*
just has to limit it to one town, one screen, no quests. Pern's wilderness
scripts should have lots of quests and dungeons, and a big map. But Pern
should not have to add wilderness *engine code* to angband. After you
make a generalized engine, export everything. Let the scripts access just
a little info, if they want. But when deciding on more stuff or less
stuff, I would vote on the option that minimizes the need for variant
maintainers to code on the engine.

>> >
>> >
>> > Finally my thinking led me to the question: Is scripting needed at
>> > all for a game? For example, Angband is a game. It lived 10+ years
>> > well without scripting. Now there are tries to separate it into a
>> > engine and game (script) code. Is this a good idea at all? Why did it
>> > work well for 10+ years without scripts if scripting is such a good
>> > idea? (IMO in case of Angband scripting is a bad idea: the Angband
>> > engine isn't generic enough to exist as game engine alone, and if it
>> > is always bundled with the scripts to be played as Angband, the
>> > separtion of engine and game code was useless).
>> >
>> >
>> > I'm asking because a while ago I was thinking about including a
>> > scripting langauge in my own roguelike project, but never found a
>> > 'must have' reason for scripting. Thus I went on without a scripting
>> > language. Now I see the Angband maintainers have a strong idea that
>> > scripting is a 'must have' for Angband, and I'm wondering, if my
>> > thinking was wrong.

This depend a LOT on your plans for the game. Angband should be scripted
because it's impossible to think of Angband at this point without
variants. I can not even imagine Angband taking the path of ADOM in terms
of maintainership (one guy, closed source, unforked code). Ultima Online
Sphere server should be scripted because the idea is to allow hundreds of
peple around the world to build their own game. There is no need for
Ultima 9 to be scripted, for example. It is a single game, with closed
technology, which will be evolved beyond recognition anyway by the time
someone decides to make Ul0.

>> >
>
> Kind reagrds,
> Hansjörg Malthaner

Running the risk of being flamed to death. I say that Angband has
fulfilled its destiny as the most customizable roguelike when someone
manages to use scripts and the Angband engine to code Nethack or ADOM.

Hansjörg Malthaner

unread,
Mar 20, 2002, 9:57:39 AM3/20/02
to
Astromarine wrote:
>
> On Wed, 20 Mar 2002 14:35:46 +0100, Hansjörg Malthaner wrote:
>
> Hi. I'm sorry for replying only to a point which is secondary in your
> message, I just thought that your other questions were directed at the
> maintainers only. I will try to answer them (since it beats working) with
> my *personal* opinion.

Thanks :)
All input is appreciated, beuase I have no experience with scripting at all,
so far.



> >> > The very basic question:
> >> >
> >> > - what functionality should be externalized into scripts?
> >> >
> >> > Scripts (unlike datafiles) allow to externalize functionality.
> >> > Usually they are used to separate the engine code (hardcoded) from
> >> > the games code (scripts). Now, I'm unsure where to draw the line?
> >> > What is part of the engine, and what is part of the game. I.e. is a
> >> > spells code part of the game engine, or part of the game? Should the
> >> > spell code be in a script or a hardcoded program part?
> >> >
>
> I have some limited experience with this, due to my participation in a
> few Ultima Online free shards. That experience made me think that
> the answer should be "as much as humanly possible, barring performance
> problems".

Sounds well on a first thought. But if 100% of the functionality are
externalized to scripts, there is nothing left to be the program istelf.
It'd be all script code.

Not bad, maybe, but I think not what is intended to be done with scripts.

> This is, of course, based on one assumption: You *want* forks
> and variantes.

In other projects, I experienced, the more parts of the program are
customizeable, the more people will try to help. I think I want forks and
variaints - usually it is possible to backport changes and good ideas from
the variants, so they help rather than they hurt.

> The Sphere engine for UO shards, for example, is pure
> engine. People are *supposed* to make their own game out of it. But it
> leaves things like damage calculations inside the engine. This allows
> *only* for other UO shards which all *must* play exactly like the
> original except for a few modifications on stuff like items.

That's the point my question was about: what should be part of the core
engine,a nd what shoudl be scriptable.

I.e. if the world is made from rectangular tiles, one can consider this fact
to be part of the game engine. Someone else wants hex tiles in their mod,
and say this should be scriptable. Usually the engines datastructures are
made to fit to one type of world - a rectangle has four neighbouring
sqaures, a hex has 6 neighbours. This is a very fundamental difference. Must
the engine be generic enough to hanlde both cases? Or may a engine set one
of the choices as a fact and let the player build only rectangualr or hex
grids on that engine?

IMO a engine cannot be really generic, it always sets a base for a certain
type of game. I'm searching a good compromise between extensibility and
ease of implementation.

That reminds me: scripts are said to be easier to code, than the native
language of the engine. The main argument for the develoepr is the win in
time, he can write mor ecode in less time by using scripts. But if scripting
leads to a more complex engine, there is no win - the scripts are easier to
write, but developing the engine takes longer. The average game programmer
has to write both, engine and game, so to me it looks as if the best way was
to minimize the overall costs, that is go with limited scripting capablities
and a fairly simple (less genric) engine.

> The shard I
> played on has changed most parts of the game by ignoring the underlying
> code and doing *everything* but the graphics and comms handling in
> scripts. This means that the engine is hugely bloated with unnecessary
> stuff in their case.

In this case, they'd probably be betetr of with a pure graphics engine and a
communication library. There is the word that says "If your only tool is a
hammer, everything looks like a nail" - there are appropriate tols for
distinct tasks, using the wrong tool may be heroic but mostly wastes your
time.



> Angband has to make a decision which is not so hard, since the C code is
> open as well. There is no design decision that variants must still play
> like angband. Therefore, IMHO, everything should be changed to scripts
> unless that causes a performance hit (which is not trivial.

Again, if everything is changed into scripts, nothing is left. It seems
"Everything" can't be the right answer for the quastion "what to externalize
into scripts?".

> Angband is
> supposed to work on stupidly ancient machines, and this is a good and
> proper thing which I hope will never change.

At times I lack the understanding for this, but I must accept it.

> >> > If the separation of game code (scripts) and the engine (hardcoded)
> >> > is the way to go, the next questions are about the interface between
> >> > those two:
> >> >
> >> > - what should the game engine export to the scripts? - how should
> >> > scripts interact with the game engine? - how should the interface
> >> > expose the exports of the game engine to the scripts (hereby I mean,
> >> > how should the exports look like when used in a script) ?
>
> >> > I'd be also interested to learn the reasons, why something should be
> >> > exported (or not) and why a certain type of interfacing is superior
> >> > to another.
>
> I am of the opinion that the game engine should be as generic as
> possible. Example: Angband wilderness. I think the standard engine (let's
> call it the vanilla engine) should have a wilderness. This changes the
> way Vanilla "feels", you say? Not at all: the vanilla wilderness *script*
> just has to limit it to one town, one screen, no quests. Pern's wilderness
> scripts should have lots of quests and dungeons, and a big map. But Pern
> should not have to add wilderness *engine code* to angband. After you
> make a generalized engine, export everything.

The problem is the cocept of the wilderness. Even the engine must have a
concept for a wilderness, otherwise it cannot offer hooks for a wilderness
script.

Assume there was a engine, and it has a concept of wilderness. A varaint
needs a woilder ness and an ocean. Now, must the angband engine be changed
to get a concept of an ocean, too?

The problem is, the engine has a set of concepts; if a concept is missing in
the engine, scripts cannot add this concept. The term 'generic engine' is
nice, but IMO a engine cannot be generic, not generic enough to allow
everything people can imagine.

> Let the scripts access just
> a little info, if they want. But when deciding on more stuff or less
> stuff, I would vote on the option that minimizes the need for variant
> maintainers to code on the engine.

Which leads to the conculsion "externalize everything" which leaves no
engine anmore. Without an engine, noone needs to change engine code, becuase
there are only scripts. This is a self-fulfilling prophecy. Somehow I think
we are caught with a wrong idea here ...

[scripting at all?]

> >> > I'm asking because a while ago I was thinking about including a
> >> > scripting langauge in my own roguelike project, but never found a
> >> > 'must have' reason for scripting. Thus I went on without a scripting
> >> > language. Now I see the Angband maintainers have a strong idea that
> >> > scripting is a 'must have' for Angband, and I'm wondering, if my
> >> > thinking was wrong.
>
> This depend a LOT on your plans for the game. Angband should be scripted
> because it's impossible to think of Angband at this point without
> variants. I can not even imagine Angband taking the path of ADOM in terms
> of maintainership (one guy, closed source, unforked code).

That's right, but ADOM seems doing well, despite it's different develoment
model. Actually my plans go more in direction of ADOM - now scripting seems
to offer a third way, have the engine closed as in ADOM but yet extensible
through the scripts.

I think that's the way I want to go ... allowing others to adapt the
existing and contribute new functionality without changing the core. Now
that sounds liek a 'must have' reason for scripts :)

(If you want to take a look at my project see http://h-world.simugraph.com
... much inspired by roguelikes, but not strictly 'roguelike').

> > Kind reagrds,
> > Hansjörg Malthaner
>
> Running the risk of being flamed to death. I say that Angband has
> fulfilled its destiny as the most customizable roguelike when someone
> manages to use scripts and the Angband engine to code Nethack or ADOM.

I'm sure that can be done with Lua scripting; the question is if anyone
wants this to be done :)

c.u.
Hajo

Screwtape

unread,
Mar 20, 2002, 9:17:54 AM3/20/02
to
m_init(): spawning followupTo('Hansjörg Malthaner')...done.

>Hi,
>
>following the discussion about Lua scripting in rgra, few questions about
>the basics of scripting popped into my mind:
>
>The very basic question:
>
>- what functionality should be externalized into scripts?
>
>Scripts (unlike datafiles) allow to externalize functionality. Usually they
>are used to separate the engine code (hardcoded) from the games code
>(scripts). Now, I'm unsure where to draw the line? What is part of the
>engine, and what is part of the game. I.e. is a spells code part of the game
>engine, or part of the game? Should the spell code be in a script or a
>hardcoded program part?

There's another thread at the moment arguing whether the new Vanilla
Lua scripts have bad style or not - it's also a useful introduction
for the answer to that question.

The *actual* answer to that question is, of course, very complicated -
basically, there *is* no hard line between program and data. You can
draw the line in different places for different parts of the code; you
might implement food in C, but spells in Lua.

The Mozilla webbrowser has an object-oriented design, and a technology
called XPCOM that lets objects be implemented seamlessly in JavaScript
or C++. That's not a very useful technology for Angband, but it shows
that the interpreted/compiled division need not be deep.

Given that (a) My opinion bears no weight, (b) I've never written a
line of Lua code, and (c) I've never hacked on a roguelike game, I
would suggest a handy guideline would be this: Game primitives should
be C, complex things should be scripted.

I don't mean "complex" as in "complicated", I mean as in "built out of
primitives".

For example, the C code knows of things called "rods" that have a
spell and a recharge rate, things called "scrolls" that disappear once
read, and a spell called "recall" which teleports you to/from the
town. All those things should be in the C core. The Lua script should
express the idea that there is a variety of scroll that performs the
spell "recall", and a variety of rod that performs the spell "recall"
with a given recharge rate.

A more complicated example:

C-core: "melee" attack, "mana" attack, "fire" attack, "acid" attack
etc, "beam" effect, "bolt" effect, "ball" effect, etc.

Lua script: there is a spell called "magic missile" that does a "mana"
attack, with a "bolt" effect, for XdY damage. There is a spell called
"Acid ball" that does "acid" damage with a "ball" effect, for XdY
damage, and so on.

Preferably, this would be flexible enough that you could have one
spell have many effects - you might want to add a spell like Antipodes
from Chrono Trigger that does a "bolt" of "fire" and "ice".

In the above examples, we see that the spell "recall" probably needs
to be written in C, the spell "magic missile" probably doesn't.
Inventing a scripting API flexible enough for both those spells is
tricky.

>If the separation of game code (scripts) and the engine (hardcoded) is the
>way to go, the next questions are about the interface between those two:
>
>- what should the game engine export to the scripts?

Exactly what level of detail is up for debate, but certainly it should
be limited to game mechanics. For example, in Quake the game engine
used scripting to define the actions (AI) and capabilities of
monsters, items, weapons, and so forth. Lua scripting should probably
not, in my mind, access the in-memory structures for the level data,
any display functions, and so forth.

Perhaps at a later time, Lua scripts could be extended to have a
menu-system (casting a spell brings up its own menu of choices), or
pluggable modules for dungeon generation, or whatever you like,

>- how should scripts interact with the game engine?

Basically, there's two directions of communication - the engine wants
the scripts to do something, and of course the scripts want the engine
to do something.

The first form of communication is basically things like "Spell <foo>
was cast, targetted at point <x,y> - what should happen?". In my ideal
world, the scripts would be parsed at startup, and construct a great
big datastructure containing all the details of the game, in much the
same way as the edit files are parsed now - with the added benefit
that you can put more things into external text files, more readably.

The second form should be instructions like "do 3d7 fire damage at
position (x,y)" and "teleport the player 20d3 spaces in a random
direction".

Basically, the engine represents the very high-level (player wants to
cast spell 3 of book 1) and the very low-level (dig northward). The
scripts do all the in-between things.

>- how should the interface expose the exports of the game engine to the
>scripts (hereby I mean, how should the exports look like when used in a
>script) ?

Basically, the engine puts two types of things into the scripting
environment. Hooks are functions implemented in Lua that the engine
calls when the user wants something done. Primitives are functions
implemented in C that the scripts call when they want something done.

Exactly what hooks and what primitives there are is entirely decided
by the maintainer, who will probably look at things like
execution-time overhead, gains in flexibility, ugliness/beauty of
code, modifications required to the rest of the system and so forth.
Notice that most of these criteria are quite subjective.

>I'd be also interested to learn the reasons, why something should be
>exported (or not) and why a certain type of interfacing is superior to
>another.

It's quite concievable to have a version of Angband where the only
thing in scripts is the current contents of the edit files. Adding
anything more means ripping code out of C files and replacing it with
Lua hooks.

It's quite concievable to have a version of Angband where the only
thing in C is a thing wrapper around the terminal code, with
*everything* else in scripts.

Those two extremes, and all the variations inbetween, are pretty much
decided on the criteria I listed above, subjective though they are.

>Finally my thinking led me to the question: Is scripting needed at all for a
>game?

Not at all.

>For example, Angband is a game. It lived 10+ years well without
>scripting. Now there are tries to separate it into a engine and game
>(script) code. Is this a good idea at all? Why did it work well for 10+
>years without scripts if scripting is such a good idea?

Every decision is a compromise. Perhaps the guy who wrote the first
version of Angband looked at scripting, weighed it up and decided the
benefits were less than the costs.

Times change - the ability to customise Angband is quite popular,
whereas I hear it wasn't so popular many years ago. Computers are
faster now, so the overhead of scripting is proporionally less.
Whatever Robert's reasons are (you'll have to ask him), he weighed the
pros and cons, and decided that adding scripting would be a Good Idea.

There is nothing "more" you could do in a version of Angband that was
scripted in Perl or VBA than you could do in a version of Angband
written in assembly code with no scripting at all. You don't
(necessarily) get any extra features. The differences are much more
subjective.

As a rgra lurker, I suspect the main reason for the introduction of
scripting is just following the obvious trend of "Vanilla is a great
way to get started writing your own roguelike", but that is of course
my own opinion. There are other things that would make Vanilla addons
even easier to write, but I suspect Robert doesn't have the time to
write a Variant Wizard ("Hi! It looks like you're trying to write a
variant. Can I help?" :) or rewrite Angband entirely in Python, or
host free Variant Writing courses in every major city in every country
in the world, or...

>(IMO in case of Angband scripting is a bad idea: the Angband engine
>isn't generic enough to exist as game engine alone, and if it is
>always bundled with the scripts to be played as Angband, the
>separtion of engine and game code was useless).

The Angband engine, as of 2.9.3, may well not be generic enough to
exist as a game engine alone. Adding scripting support naturally would
involve modifying the engine so that it *is* generic enough to exist
as a game engine alone.

>I'm asking because a while ago I was thinking about including a scripting
>langauge in my own roguelike project, but never found a 'must have' reason
>for scripting. Thus I went on without a scripting language. Now I see the
>Angband maintainers have a strong idea that scripting is a 'must have' for
>Angband, and I'm wondering, if my thinking was wrong.

Does your roguelike have a thriving variant community, who would
obviously be very interested in modifying as much of the game as
possible? Do you see the attraction of being able to fix bugs by
telling people to drop a patched file into their game folder, rather
than fixing the bug in CVS and waiting for the usual crowd to make
binaries for all relevant platforms? Do you find tweaking and tuning
your game data to be tedious and boring, and wish you could edit a
text file and have the changes take place without even restarting your
game?

If you answered yes to any of those questions, scripting might be
something to look at. If you answered no, then feel free to keep
coding the way you like - more power to you.

--
___________ ____________________________
| Screwtape | Reply-To: munged on Usenet |________ ______ ____ __ _ _ _
|
| Pain clots and unformed lice pat this train.
|

Astromarine

unread,
Mar 20, 2002, 10:56:11 AM3/20/02
to
On Wed, 20 Mar 2002 15:17:54 +0100, Screwtape wrote:

Hi. I agree with you on most points, except on one thing. Major snippage
ahead. :)

> Given that (a) My opinion bears no weight, (b) I've never written a line
> of Lua code, and (c) I've never hacked on a roguelike game, I would
> suggest a handy guideline would be this: Game primitives should be C,
> complex things should be scripted.
>
> I don't mean "complex" as in "complicated", I mean as in "built out of
> primitives".
>
> For example, the C code knows of things called "rods" that have a spell
> and a recharge rate, things called "scrolls" that disappear once read,
> and a spell called "recall" which teleports you to/from the town. All
> those things should be in the C core. The Lua script should express the
> idea that there is a variety of scroll that performs the spell "recall",
> and a variety of rod that performs the spell "recall" with a given
> recharge rate.

I think this is a wrong approach (a valid one, just inefficient). A rod
is an object that holds some variables (spell and recharge counter),
executes some functions (bool can_cast, void cast_spell) and nothing
else. There is no reason why this has to be defined in C, and every
reason not to: If I want to change how rods *work* in my variant (say,
having a probability to blow up if used too often, no fixed time limit) I
have to get into the engine. The same with "recall" spell. It is just a
function that determines your next level depending one of your variables
(current depth), implements a counter, and calls back the build level
function in C when counter reaches 0 using next level as a parameter. I
should also be allowed to change what recalling *means* in my variant.
This should be a script.

> A more complicated example:
>
> C-core: "melee" attack, "mana" attack, "fire" attack, "acid" attack etc,
> "beam" effect, "bolt" effect, "ball" effect, etc.

This means that if I want to do game-related stuff like move to o-combat,
add an extra elemental type, or change the special effects of damage
types I should go in the C code. Again, wrong IMHO.

>
> Lua script: there is a spell called "magic missile" that does a "mana"
> attack, with a "bolt" effect, for XdY damage. There is a spell called
> "Acid ball" that does "acid" damage with a "ball" effect, for XdY
> damage, and so on.
>
> Preferably, this would be flexible enough that you could have one spell
> have many effects - you might want to add a spell like Antipodes from
> Chrono Trigger that does a "bolt" of "fire" and "ice".
>
> In the above examples, we see that the spell "recall" probably needs to
> be written in C, the spell "magic missile" probably doesn't. Inventing a
> scripting API flexible enough for both those spells is tricky.
>

I have a different opinion, see above as to why. :)

Abilio

Astromarine

unread,
Mar 20, 2002, 11:17:55 AM3/20/02
to
Hi again :) I admit my "everything" answers are a bit wrong, but not by
much :) IMO, the "engine" if what defines the game's "feel". This means,
an Angband engine will never be real time, will always have concepts such
as player, monsters, items, square grids, random generation, ultimate
goal, etc. These concepts are fairly static in meaning and define a
"genre". Everything else is implementation specifics. The fact that the
player has x stats, which vary from y to z is not generic, it is
a game design choice.

On Wed, 20 Mar 2002 15:57:39 +0100, Hansjörg Malthaner wrote:

> Astromarine wrote:
>>
>> On Wed, 20 Mar 2002 14:35:46 +0100, Hansjörg Malthaner wrote:
>>
>>
>> I am of the opinion that the game engine should be as generic as
>> possible. Example: Angband wilderness. I think the standard engine
>> (let's call it the vanilla engine) should have a wilderness. This
>> changes the way Vanilla "feels", you say? Not at all: the vanilla
>> wilderness *script* just has to limit it to one town, one screen, no
>> quests. Pern's wilderness scripts should have lots of quests and
>> dungeons, and a big map. But Pern should not have to add wilderness
>> *engine code* to angband. After you make a generalized engine, export
>> everything.
>
> The problem is the cocept of the wilderness. Even the engine must have a
> concept for a wilderness, otherwise it cannot offer hooks for a
> wilderness script.

It needs to have the concept of a dungeon level, and a script should know
what being a wilderness *means* (its parameters) and tel the engine to
build a dungeon level with those parameters. Why can't I have fixed
quests, rivers, trees, and towns inside the dungeon? I could be another
separate area accessible only through a cave, or something.

>
> Assume there was a engine, and it has a concept of wilderness. A varaint
> needs a woilder ness and an ocean. Now, must the angband engine be
> changed to get a concept of an ocean, too?

No. An ocean grid square has certain parameters that makes it different
from a land square. The script just knows to tell the engine to generate
x squares of it on a wilderness dungeon level.

>
> The problem is, the engine has a set of concepts; if a concept is
> missing in the engine, scripts cannot add this concept. The term
> 'generic engine' is nice, but IMO a engine cannot be generic, not
> generic enough to allow everything people can imagine.

True, but not as restrictive as you imagine. An engine is a collection of
very high level primitives, and concepts can be defined incrementally in
a script. The engine does not need to know what rods are, just items.
rods are defined in scripts. For example, If light sources and wands are
defined in scripts, I can combine their functions to create a new item
type called "firearm" which is refilled, has "charges", and fires directionally
Just using scripts.


>
>> Let the scripts access just
>> a little info, if they want. But when deciding on more stuff or less
>> stuff, I would vote on the option that minimizes the need for variant
>> maintainers to code on the engine.
>
> Which leads to the conculsion "externalize everything" which leaves no
> engine anmore. Without an engine, noone needs to change engine code,
> becuase there are only scripts. This is a self-fulfilling prophecy.
> Somehow I think we are caught with a wrong idea here ...
>

As I said above, I think an engine has to serve as a wrapper, and
implement the most basic world generation and control functions

>>
>> This depend a LOT on your plans for the game. Angband should be
>> scripted because it's impossible to think of Angband at this point
>> without variants. I can not even imagine Angband taking the path of
>> ADOM in terms of maintainership (one guy, closed source, unforked
>> code).
>
> That's right, but ADOM seems doing well, despite it's different
> develoment model. Actually my plans go more in direction of ADOM - now
> scripting seems to offer a third way, have the engine closed as in ADOM
> but yet extensible through the scripts.
>
> I think that's the way I want to go ... allowing others to adapt the
> existing and contribute new functionality without changing the core. Now
> that sounds liek a 'must have' reason for scripts :)
>
> (If you want to take a look at my project see
> http://h-world.simugraph.com ... much inspired by roguelikes, but not
> strictly 'roguelike').

No time now, at work, but will. ADOM is just fine, and I play it
regularly. I just don't think that model is appropriate for angband.


>> > Kind reagrds,
>> > Hansjörg Malthaner
>>
>> Running the risk of being flamed to death. I say that Angband has
>> fulfilled its destiny as the most customizable roguelike when someone
>> manages to use scripts and the Angband engine to code Nethack or ADOM.
>
> I'm sure that can be done with Lua scripting; the question is if anyone
> wants this to be done :)

hee hee hee

>
> c.u.
> Hajo


Abilio

Rune Jarnes

unread,
Mar 20, 2002, 11:39:26 AM3/20/02
to
>
> following the discussion about Lua scripting in rgra, few questions about
> the basics of scripting popped into my mind:
>
>
> The very basic question:
>
> - what functionality should be externalized into scripts?
>
> Scripts (unlike datafiles) allow to externalize functionality. Usually
they
> are used to separate the engine code (hardcoded) from the games code
> (scripts). Now, I'm unsure where to draw the line? What is part of the
> engine, and what is part of the game. I.e. is a spells code part of the
game
> engine, or part of the game? Should the spell code be in a script or a
> hardcoded program part?

You must realize that there is no one single response to this that is the
truth. Whatever the designer(s) decide to externalize is entirely up to what
they value. That will be subjective and thus there is no generic truth
answer to this.

Here you have two conflicting requirements that addresses what I mean
- It should be easy to add to the game
- It shall be possible to script anything, right down to the core mechanics

You will not be able to provide a single solution (truth) that addresses
both of these requirements.

>
>
> If the separation of game code (scripts) and the engine (hardcoded) is the
> way to go, the next questions are about the interface between those two:
>
> - what should the game engine export to the scripts?
> - how should scripts interact with the game engine?
> - how should the interface expose the exports of the game engine to the
> scripts (hereby I mean, how should the exports look like when used in a
> script) ?

Again, very subjective. First of all, you probably want certain core
mechanics to stay hidden. The next (if you care) is to consider your target
audience. If they are very creative, but not very analytical (usually
conflicting traits), it should be easy to add to the game, thus scripting /
externalization must be pretty simple if you want them to use this.

So target audience, developer(s) philosophy / goal will shape the solution
that is presented.

>
> I'd be also interested to learn the reasons, why something should be
> exported (or not) and why a certain type of interfacing is superior to
> another.
>

This can of course be addressed analytically, but this will be a lot of
work. I'm not up to it. I believe it would end up in a matrix, where you
could plot a position (your decision) and as a function of that, get the
advantages and disadvantages of that solution.

>
>
> Finally my thinking led me to the question: Is scripting needed at all for
a
> game? For example, Angband is a game. It lived 10+ years well without
> scripting. Now there are tries to separate it into a engine and game
> (script) code. Is this a good idea at all? Why did it work well for 10+
> years without scripts if scripting is such a good idea? (IMO in case of
> Angband scripting is a bad idea: the Angband engine isn't generic enough
to
> exist as game engine alone, and if it is always bundled with the scripts
to
> be played as Angband, the separtion of engine and game code was useless).

Script is only needed if you want to provide a simpler interface to people
that can add to the game, but that doesn't have the necessary core skills.
If your scripting doesn't add value in this respect, then it's pretty
worthless IMO.

>
>
> I'm asking because a while ago I was thinking about including a scripting
> langauge in my own roguelike project, but never found a 'must have' reason
> for scripting. Thus I went on without a scripting language. Now I see the
> Angband maintainers have a strong idea that scripting is a 'must have' for
> Angband, and I'm wondering, if my thinking was wrong.

Thinking is never wrong :)

I'll add a favourite philosophy of mine:
If you can't efficiently express yourself in a language, be it a scripting
language, or the chosen core language->Think again. Start with how you want
to express yourself (usually textually, but there are other forms) and work
from that.

And finally, the point to scripting isn't that you don't have to recompile.
Honestly, where's the hassle in that. You still have to test and distribute
the files. IMHO The point with scripting is that CREATIVE PEOPLE can express
THEIR IDEAS in a manner more suitable to them.

Best Regards
Rune Jarnes


Steven Fuerst

unread,
Mar 20, 2002, 12:02:36 PM3/20/02
to
Hansjörg Malthaner <hansjoerg...@danet.de> wrote in message news:<3C985209...@danet.de>...

> Hi,
>
> following the discussion about Lua scripting in rgra, few questions about
> the basics of scripting popped into my mind:
>
>
> The very basic question:
>
> - what functionality should be externalized into scripts?

High-level things. Instead of adding heaps of tiny fragments of C
code everywhere every time you need to add functionality, create a set
of hooks - and use those as an interface. If you pick the right
interface, you'll find that you can export the "exceptions" to the
scripting language, and leave the common-code alone. This adds
enormously to code cleanliness, and makes it extremely easy to make
modifications that were once very difficult.

>
> Scripts (unlike datafiles) allow to externalize functionality. Usually they
> are used to separate the engine code (hardcoded) from the games code
> (scripts). Now, I'm unsure where to draw the line?

Yeh - you need to think very hard about it. The most difficult thing
is getting the right API. Everything else is trivial in comparison.

> What is part of the
> engine, and what is part of the game. I.e. is a spells code part of the game
> engine, or part of the game? Should the spell code be in a script or a
> hardcoded program part?

Low-level stuff is in-game. High-level stuff can be scripted. If you
move the boundary too far either direction, the problems should become
obvious.

If you are exporting too much low-level stuff, then you end up
rewriting the game in the new language. (This is obviously silly.)

If you aren't exporting enough, and your interface is too high of a
level, then you will not be able to do the things you want to do with
it.

> If the separation of game code (scripts) and the engine (hardcoded) is the
> way to go, the next questions are about the interface between those two:
>
> - what should the game engine export to the scripts?

As little as possible to get what is wanted done.

> - how should scripts interact with the game engine?

This is meaningless question with a huge number of possible answers
depending on which scripting language you use.

> - how should the interface expose the exports of the game engine to the
> scripts (hereby I mean, how should the exports look like when used in a
> script) ?

This doesn't matter much either. Semantics can be cleaned up later.

> I'd be also interested to learn the reasons, why something should be
> exported (or not) and why a certain type of interfacing is superior to
> another.

Minimalism is good. Export as little as you can get away with.

>
>
> Finally my thinking led me to the question: Is scripting needed at all for a
> game?

In a turing-complete sense? No. Is it nice to have? Yes.

> For example, Angband is a game. It lived 10+ years well without
> scripting. Now there are tries to separate it into a engine and game
> (script) code. Is this a good idea at all?

Yes.

> Why did it work well for 10+
> years without scripts if scripting is such a good idea?

The whole concept of "well" is being redefined. Scripting allows you
to do things you couldn't do before without huge amounts of effort.
Is reduction of future effort a good thing to aim for? Perhaps. It
all depends on how good you are at predicting what you'll need in the
future. I can probably say that most maintainers probably know
roughly what they would like to add later on to their game. This puts
them in a rather good position in predicting the future of their game.

> (IMO in case of
> Angband scripting is a bad idea: the Angband engine isn't generic enough to
> exist as game engine alone, and if it is always bundled with the scripts to
> be played as Angband, the separtion of engine and game code was useless).

What is "Angband". Do other variants count in that definition? Would
it be good to be able to customise the game so much that a whole new
variant could be made just from those customisations? This is already
possible, and has been done. Should this technique be made easier and
more powerful? Simply saying that it is "useless" is extremely short
sighted imho.


> I'm asking because a while ago I was thinking about including a scripting
> langauge in my own roguelike project, but never found a 'must have' reason
> for scripting.

Your roguelike is in its infancy iirc. You are right - an infant
project doesn't need scripting. An adult project with lots of
children is a different case.

> Thus I went on without a scripting language. Now I see the
> Angband maintainers have a strong idea that scripting is a 'must have' for
> Angband, and I'm wondering, if my thinking was wrong.

Nope. Your thinking isn't wrong. You just are looking at a different
problem.

> Kind reagrds,
> Hansjörg Malthaner

Steven

Hansjörg Malthaner

unread,
Mar 20, 2002, 1:08:38 PM3/20/02
to
Hi Steven,

nice to meet you :)

Steven Fuerst wrote:
>
> Hansjörg Malthaner <hansjoerg...@danet.de> wrote in message news:<3C985209...@danet.de>...

> > The very basic question:


> >
> > - what functionality should be externalized into scripts?
>
> High-level things. Instead of adding heaps of tiny fragments of C
> code everywhere every time you need to add functionality, create a set
> of hooks - and use those as an interface.

I was thinking about exporting the concepts of a 'level', a 'square', an
'item' and such. My project is OO so exporting those building blocks seemed
to be a good idea. Still I'm unsure what parts of those concepts to expose
...

> If you pick the right
> interface, you'll find that you can export the "exceptions" to the
> scripting language, and leave the common-code alone. This adds
> enormously to code cleanliness, and makes it extremely easy to make
> modifications that were once very difficult.

Any hints how to find the 'right' interface?

> > Scripts (unlike datafiles) allow to externalize functionality. Usually they
> > are used to separate the engine code (hardcoded) from the games code
> > (scripts). Now, I'm unsure where to draw the line?
>
> Yeh - you need to think very hard about it. The most difficult thing
> is getting the right API. Everything else is trivial in comparison.

I agree with that. My problem is that I have no good idea how to find out
which API to export. As you write below, my project is at the very
beginning. I have no examples of usages which I could use as a guideline, I
need to define this API right from mind and knowledge. That's what I'm stuck
with now.



> > What is part of the
> > engine, and what is part of the game. I.e. is a spells code part of the game
> > engine, or part of the game? Should the spell code be in a script or a
> > hardcoded program part?
>
> Low-level stuff is in-game. High-level stuff can be scripted. If you
> move the boundary too far either direction, the problems should become
> obvious.

My problem is, on a scale of 1 to 10 about 3 to 7 look like an appropriate
place to make the cut. You're right the far ends disqualify quite celarly,
but I need advice to find a more precise location for the cut. A range of
50% of all is too big.

Are the rules, hints, experiences that I could use as a guideline?

> If you are exporting too much low-level stuff, then you end up
> rewriting the game in the new language. (This is obviously silly.)
>
> If you aren't exporting enough, and your interface is too high of a
> level, then you will not be able to do the things you want to do with
> it.

That's correct, but not really helpful :(
I mean that's an obvious truth, such generic advice isn't what I neeed.



> > If the separation of game code (scripts) and the engine (hardcoded) is the
> > way to go, the next questions are about the interface between those two:
> >
> > - what should the game engine export to the scripts?
>
> As little as possible to get what is wanted done.

What should it be able to do?



> > - how should scripts interact with the game engine?
>
> This is meaningless question with a huge number of possible answers
> depending on which scripting language you use.

I plan to use Lua - every Angband varaint seems to be going to use it, so I
think it's best not to make an exception but use something that others use,
too.



> > I'd be also interested to learn the reasons, why something should be
> > exported (or not) and why a certain type of interfacing is superior to
> > another.
>
> Minimalism is good. Export as little as you can get away with.

As a rule of thumb that is ok. But somehow you just tell me what I already
know :(
Can you give a more elaborate advice?

> > Finally my thinking led me to the question: Is scripting needed at all for a
> > game?
>
> In a turing-complete sense? No. Is it nice to have? Yes.

And in common sense ?

I mean 'nice to have' isn't a strong argument IMO.

> > For example, Angband is a game. It lived 10+ years well without
> > scripting. Now there are tries to separate it into a engine and game
> > (script) code. Is this a good idea at all?
>
> Yes.

Why?



> > I'm asking because a while ago I was thinking about including a scripting
> > langauge in my own roguelike project, but never found a 'must have' reason
> > for scripting.
>
> Your roguelike is in its infancy iirc. You are right - an infant
> project doesn't need scripting. An adult project with lots of
> children is a different case.

The project will grow. I want to prepare it now for a prosperous future. So
I need to think about adding scripting support or not.

It clear that I don't need scripting support now, but maybe it's a good idea
to implement scripting support right from the beginning?

And if I do so, I want to do it as good as possible.

> Steven

Kind reagrds,
Hansjörg Malthaner

Hansjörg Malthaner

unread,
Mar 20, 2002, 1:34:05 PM3/20/02
to
Screwtape wrote:
>
> m_init(): spawning followupTo('Hansjörg Malthaner')...done.
> >Hi,
> >
> >following the discussion about Lua scripting in rgra, few questions about
> >the basics of scripting popped into my mind:
> >
> >The very basic question:
> >
> >- what functionality should be externalized into scripts?
> >
> >Scripts (unlike datafiles) allow to externalize functionality. Usually they
> >are used to separate the engine code (hardcoded) from the games code
> >(scripts). Now, I'm unsure where to draw the line? What is part of the
> >engine, and what is part of the game. I.e. is a spells code part of the game
> >engine, or part of the game? Should the spell code be in a script or a
> >hardcoded program part?
>
> There's another thread at the moment arguing whether the new Vanilla
> Lua scripts have bad style or not - it's also a useful introduction
> for the answer to that question.

I think I've read all messages about scripting in rgra - I've seen that some
say ToME has a better interface than vanilla. But I cannot judge this
actually, I have only a rough idea of ToMEs interface and no idea at all of
Angbands.



> The *actual* answer to that question is, of course, very complicated -
> basically, there *is* no hard line between program and data. You can
> draw the line in different places for different parts of the code; you
> might implement food in C, but spells in Lua.
>
> The Mozilla webbrowser has an object-oriented design, and a technology
> called XPCOM that lets objects be implemented seamlessly in JavaScript
> or C++. That's not a very useful technology for Angband, but it shows
> that the interpreted/compiled division need not be deep.

Sounds promising.My project is OO style also, and the Interface will be OO
style, too. But I think the core objects, like a level, a sqaure, and item
will be part of the engine.

The scripts I have in mind are kind of 'foreign methods' for those objects,
methods that work on the objects data, but are externalized because of their
varietay and little relevance to the core object. Somehow, this is
parametrization on a level on functionality: the objects can be parametrized
with function from scripts, that then will determine parts of the objects
behaviour.



> Given that (a) My opinion bears no weight, (b) I've never written a
> line of Lua code, and (c) I've never hacked on a roguelike game, I
> would suggest a handy guideline would be this: Game primitives should
> be C, complex things should be scripted.

Agreed, this is basic idea IMO, too.



> I don't mean "complex" as in "complicated", I mean as in "built out of
> primitives".

Agreed.



> For example, the C code knows of things called "rods" that have a
> spell and a recharge rate, things called "scrolls" that disappear once
> read, and a spell called "recall" which teleports you to/from the
> town.

IMO the C code should only know 'item' and all that makes a rod out of an
base item should be scripts. Is this too extreme?

> The Lua script should
> express the idea that there is a variety of scroll that performs the
> spell "recall", and a variety of rod that performs the spell "recall"
> with a given recharge rate.

Agreed, up to the point, that also the other properties of a 'rod' should be
scripts, the engine only knows about generic items.

> A more complicated example:
>
> C-core: "melee" attack, "mana" attack, "fire" attack, "acid" attack
> etc, "beam" effect, "bolt" effect, "ball" effect, etc.
>
> Lua script: there is a spell called "magic missile" that does a "mana"
> attack, with a "bolt" effect, for XdY damage. There is a spell called
> "Acid ball" that does "acid" damage with a "ball" effect, for XdY
> damage, and so on.
>
> Preferably, this would be flexible enough that you could have one
> spell have many effects - you might want to add a spell like Antipodes
> from Chrono Trigger that does a "bolt" of "fire" and "ice".
>
> In the above examples, we see that the spell "recall" probably needs
> to be written in C, the spell "magic missile" probably doesn't.

Uh, unsymmetry is mostly very bad for programs. Actually I think the recall
spell can be scripted as well as other spells, it just requires that
loading/generating a level/town can be triggered froma script, too.

> Inventing a scripting API flexible enough for both those spells is
> tricky.

Maybe :)



> >If the separation of game code (scripts) and the engine (hardcoded) is the
> >way to go, the next questions are about the interface between those two:
> >
> >- what should the game engine export to the scripts?
>
> Exactly what level of detail is up for debate, but certainly it should
> be limited to game mechanics. For example, in Quake the game engine
> used scripting to define the actions (AI) and capabilities of
> monsters, items, weapons, and so forth. Lua scripting should probably
> not, in my mind, access the in-memory structures for the level data,
> any display functions, and so forth.

In my project the 'level' is an objetc, the most important part of the
public interface is to retrieve/access the square at location (x,y)

I think, I'll export right this to the lua code, the scripts can then access
sqaures from the current level.

A sqaure gain exports function to retureve all items on that sqaure, all
monsters, etc.

The implementation of a level or a sqaure is hidden, only the interface is
exported.



> Perhaps at a later time, Lua scripts could be extended to have a
> menu-system (casting a spell brings up its own menu of choices), or
> pluggable modules for dungeon generation, or whatever you like,

Interesting ideas :)



> >- how should scripts interact with the game engine?
>
> Basically, there's two directions of communication - the engine wants
> the scripts to do something, and of course the scripts want the engine
> to do something.
>
> The first form of communication is basically things like "Spell <foo>
> was cast, targetted at point <x,y> - what should happen?". In my ideal
> world, the scripts would be parsed at startup, and construct a great
> big datastructure containing all the details of the game, in much the
> same way as the edit files are parsed now - with the added benefit
> that you can put more things into external text files, more readably.
>
> The second form should be instructions like "do 3d7 fire damage at
> position (x,y)" and "teleport the player 20d3 spaces in a random
> direction".
>
> Basically, the engine represents the very high-level (player wants to
> cast spell 3 of book 1) and the very low-level (dig northward). The
> scripts do all the in-between things.

I had the idea, that the engine is always the part in command - it
determines when to execute which script. During execution the roiles are
reversed, and the script can modify the world data structures, the engine is
the passive part then.



> >Finally my thinking led me to the question: Is scripting needed at all for a
> >game?
>
> Not at all.

Many commercial games use scripts. The companies don't do things for fun,
they have reasons. If they use scripts, there should be reasons; if they are
important for a hobby game developers is still a question. But I'd like to
know the reasons :)



> >For example, Angband is a game. It lived 10+ years well without
> >scripting. Now there are tries to separate it into a engine and game
> >(script) code. Is this a good idea at all? Why did it work well for 10+
> >years without scripts if scripting is such a good idea?
>
> Every decision is a compromise. Perhaps the guy who wrote the first
> version of Angband looked at scripting, weighed it up and decided the
> benefits were less than the costs.

I'm trying to make a similar decision, too.



> >(IMO in case of Angband scripting is a bad idea: the Angband engine
> >isn't generic enough to exist as game engine alone, and if it is
> >always bundled with the scripts to be played as Angband, the
> >separtion of engine and game code was useless).
>
> The Angband engine, as of 2.9.3, may well not be generic enough to
> exist as a game engine alone. Adding scripting support naturally would
> involve modifying the engine so that it *is* generic enough to exist
> as a game engine alone.

Ok. I'll just wait and see :)



> >I'm asking because a while ago I was thinking about including a scripting
> >langauge in my own roguelike project, but never found a 'must have' reason
> >for scripting. Thus I went on without a scripting language. Now I see the
> >Angband maintainers have a strong idea that scripting is a 'must have' for
> >Angband, and I'm wondering, if my thinking was wrong.
>
> Does your roguelike have a thriving variant community,

I obviously wasn't very clear. My project has no community, it's much too
small and very young. It is still itself in the very beginning, there was
not even a sligt chance to build a variant as of yet :)

> who would
> obviously be very interested in modifying as much of the game as
> possible? Do you see the attraction of being able to fix bugs by
> telling people to drop a patched file into their game folder, rather
> than fixing the bug in CVS and waiting for the usual crowd to make
> binaries for all relevant platforms?

I'd like to have my game customizeable, easily. Curently there are data
files like the edit files from Angband. You can basically create a whole new
world by editing the data files, but noone can change the functionality.

I'm not sure, but I think I want to have functionality configuarble too,
that means using scripts.

I'm still very unsure about this point ...

> Do you find tweaking and tuning
> your game data to be tedious and boring, and wish you could edit a
> text file and have the changes take place without even restarting your
> game?

The data can be edited, it is externalized in text files, and I'm pretty
happy with that :)
Now, the question is, if externalizing functionality is a equally
well-wokring option or not.


> If you answered yes to any of those questions, scripting might be
> something to look at. If you answered no, then feel free to keep
> coding the way you like - more power to you.

If I remember right, most of my answers were 'maybe' soem with a tendency to
'yes' :)

I'm considering scripting right now, because I think it might be a good
idea; actually I just statred this to get a clearer idea of the pros and
cons, and to avoid stupid mistakes if I make my first steps with scripting.

> | Screwtape | Reply-To: munged on Usenet |________ ______ ____ __ _ _ _
> |
> | Pain clots and unformed lice pat this train.

c.u.
Hajo

stank-monkey

unread,
Mar 20, 2002, 4:17:50 PM3/20/02
to
Hansjörg Malthaner <hansjoerg...@danet.de> wrote in message news:<3C985209...@danet.de>...
> Hi,
>
> following the discussion about Lua scripting in rgra, few questions about
> the basics of scripting popped into my mind:
<snip>
> I'm asking because a while ago I was thinking about including a scripting
> langauge in my own roguelike project, but never found a 'must have' reason
> for scripting. Thus I went on without a scripting language. Now I see the
> Angband maintainers have a strong idea that scripting is a 'must have' for
> Angband, and I'm wondering, if my thinking was wrong.

Inclusion of scripting could make game balance tweaking easier for
your play testers (I'd like to be one when you're done)without the
need to recompile to test each change. If you coded it correctly, you
could selectively turn off script functionality (in a release version)
in places you wanted to, and leave it on elsewhere.
Stanky

> Kind reagrds,
> Hansjörg Malthaner

Screwtape

unread,
Mar 20, 2002, 4:17:30 PM3/20/02
to
m_init(): spawning followupTo('Astromarine')...done.

>On Wed, 20 Mar 2002 15:17:54 +0100, Screwtape wrote:
>
>Hi. I agree with you on most points, except on one thing. Major snippage
>ahead. :)
>
>> Given that (a) My opinion bears no weight, (b) I've never written a line
>> of Lua code, and (c) I've never hacked on a roguelike game, I would
>> suggest a handy guideline would be this: Game primitives should be C,
>> complex things should be scripted.
>>
>> I don't mean "complex" as in "complicated", I mean as in "built out of
>> primitives".
>>
>> For example, the C code knows of things called "rods" that have a spell
>> and a recharge rate, things called "scrolls" that disappear once read,
>> and a spell called "recall" which teleports you to/from the town. All
>> those things should be in the C core. The Lua script should express the
>> idea that there is a variety of scroll that performs the spell "recall",
>> and a variety of rod that performs the spell "recall" with a given
>> recharge rate.
>
>I think this is a wrong approach (a valid one, just inefficient).

Well, it's a purely hypothetical approach too. I have no idea if
Robert really wants to do things that way.

>A rod is an object that holds some variables (spell and recharge
>counter), executes some functions (bool can_cast, void cast_spell)
>and nothing else. There is no reason why this has to be defined in C,
>and every reason not to: If I want to change how rods *work* in my
>variant (say, having a probability to blow up if used too often, no
>fixed time limit) I have to get into the engine. The same with
>"recall" spell. It is just a function that determines your next level
>depending one of your variables (current depth), implements a
>counter, and calls back the build level function in C when counter
>reaches 0 using next level as a parameter. I should also be allowed
>to change what recalling *means* in my variant. This should be a
>script.

Well, part of my reasoning was that I don't know if Lua is a proper OO
language.

Also, the basic question here is how much of the game can be modified
from scripts? You want to mess with WoR, somebody else wanted to play
Angband on a hex-grid instead of a square one. *Yes*, the same core
*could* handle all these variations, with scripting defining the
differences. *No*, Angband is not currently that core.

If Robert is anything like me, he'll start by scripting the easy
things, then the not-too-hard things that are suggested by people he
knows and respects, followed by suggestions he reads on rgra and finds
interesting. Maybe he'll find a easy and simple way to structure the
code so that hex-grids and square-grids can both be supported. Maybe
messing with WoR is hideously complex in the current code base. We'll
all find out when the documentation arrives.

>> A more complicated example:
>>
>> C-core: "melee" attack, "mana" attack, "fire" attack, "acid" attack etc,
>> "beam" effect, "bolt" effect, "ball" effect, etc.
>
>This means that if I want to do game-related stuff like move to o-combat,
>add an extra elemental type, or change the special effects of damage
>types I should go in the C code. Again, wrong IMHO.

It's not really a backward step, though, is it? I mean, if you wanted
to do those things to previous versions of Angband, you'd have been
hacking C anyway.

<snip>

Anyway, thanks for the argument! :)

--
___________ ____________________________
| Screwtape | Reply-To: munged on Usenet |________ ______ ____ __ _ _ _
|

| "Universe-flavored. What you mortals call `butterscotch'." -- T&R, 1999-09-17
|

R. Alan Monroe

unread,
Mar 20, 2002, 7:03:30 PM3/20/02
to
In article <3C985209...@danet.de>, =?iso-8859-1?Q?Hansj=F6rg?= Malthaner <hansjoerg...@danet.de> wrote:
>I'm asking because a while ago I was thinking about including a scripting
>langauge in my own roguelike project, but never found a 'must have' reason
>for scripting. Thus I went on without a scripting language. Now I see the
>Angband maintainers have a strong idea that scripting is a 'must have' for
>Angband, and I'm wondering, if my thinking was wrong.

This is not a real answer, but do a web search for old games like ZZT
and Megazeux. I never played them, but from what I saw, it looked like
they were scriptable to some degree and they had a lot of fan-created
scenarios.

Have fun
Alan

Joseph William Dixon

unread,
Mar 20, 2002, 8:22:38 PM3/20/02
to
On Wed, 20 Mar 2002, Rune Jarnes wrote:
> Here you have two conflicting requirements that addresses what I mean
> - It should be easy to add to the game

Then why go with Lua? It's much easier to add to the game in C - the
number of people who know C is sooooo much greater than those who know Lua,
therefore more people are competent to add to the game.
And, if you don't know C, it's quite easy to find texts at your local
bookstore (and not just specialty bookstores) to learn on your own, assuming
you're not in school (high-school, university, community college) and able
to take a course there. Can't do that for Lua, at least to my knowledge.
To learn Lua, what've you got? I dunno. Not much. Never heard of it being
taught in a formal setting, and I've not seen any texts on it even in the
specialty bookstores in town...

> - It shall be possible to script anything, right down to the core mechanics

Why? When you go with an obscure and relatively unknown language, such as
Lua, no advantage in customizability is gained.

[for an example of how customizable Angband already is without scripting,
look at the amount of stuff I've been able to do to Gumband (compare it to
its base version of ZAngband 2.1.1c) without the 'benefit' of scripting -
all that based on knowledge gained from the first 3 chapters of the 2nd Ed.
'The C Programming Language' by K&R. I was making relatively substantial
changes to Z2.1.1c less than an hour after I'd downloaded the source.]

--
"...there are hardly any excesses of the most crazed psychopath that cannot
easily be duplicated by a normal, kindly family man who just comes into
work every day and has a job to do." [Terry Pratchett, "Small Gods"]
http://www.chebucto.ns.ca/~aa343/index.html

Joseph William Dixon

unread,
Mar 20, 2002, 8:36:24 PM3/20/02
to
On 20 Mar 2002, Steven Fuerst wrote:
> > Why did it work well for 10+ years without scripts if scripting is such
> a good idea?
>
> The whole concept of "well" is being redefined. Scripting allows you
> to do things you couldn't do before without huge amounts of effort.

Like what? The only effort scripting saves is that you don't have to go
through the torturous process of typing 'make' and waiting less than a
minute. ['kay, 7 minutes for my own Gumband - 12 minutes for the last
vanilla alpha (4? 6?) I tried, thanks to the Lua code - but on a more modern
system compilation takes almost no time at all.
On the other hand, Lua *adds* tons of effort - you have to learn a new
programming language which, unlike C, you can't just walk into a bookstore
and buy a textbook (even in the specialty bookstores locally) on, or learn
in a formal setting (such as high school, community/technical college, or
university).

Andrew Doull

unread,
Mar 20, 2002, 9:19:21 PM3/20/02
to
Hansjörg Malthaner <hansjoerg...@danet.de> wrote in message news:<3C98A363...@danet.de>...
> Astromarine wrote:
[...]

> > Angband is
> > supposed to work on stupidly ancient machines, and this is a good and
> > proper thing which I hope will never change.
>
> At times I lack the understanding for this, but I must accept it.
>

There are a couple of good answers for this:

1. Some things that make Angband work well on ancient machines,
make Angband work well everywhere. The efficiency of the current line
of sight code, and display code don't just help a 286, but also your
borg screen saver.

2. At the moment, at least, the lowest common denominator device
happens to be cell-phones and PDA's, rather than computers. If Angband
can resolve its remaining problems with display size dependence, I'm
sure it could be ported over to the next generation of cellphones
fairly easily.

Andrew

Joseph Hewitt

unread,
Mar 20, 2002, 10:25:19 PM3/20/02
to
When I started to build a scripting language for my RL I had no clue
what I was doing... I still don't, I suppose, but I've learned a lot
along the way.

I am working on two games at the same time. In DeadCold, all of the
adventure data is hardcoded into the program. In GearHead, the
adventure data is stored in script files.

One advantage to using scripts that I've found is that it encourages
me to be a better programmer. If everything is scripted, I have to
build effects from primitives, rather than stick jumbles of "if
Monster=Wraith then PowerDrain(PC)" or "if ItemHeld(Staff of Foo) and
Location=AltarOfBar then WinGame()" type lines into my code.

Another advantage is that it becomes very easy to modify my campaign
world. This follows from the above point... If everything is built
from primitive effects rather than lines of program code, details of
the campaign can be changed at will. You won't have to worry about
hunting down every last "if..." statement.

GearHead, like H-World, doesn't have a definite setting yet. Scripting
allows me to play around with a number of locations and develop
routines that will be useful once I feel ready to build the actual
campaign world. Hardcoded data works well for DeadCold since that game
has a definite location and a straightforward plot.

- Joseph Hewitt
--
DeadCold > http://www.geocities.com/pyrrho12/programming/deadcold/index.html
GearHead > http://www.geocities.com/pyrrho12/programming/gearhead/index.html

Keldon Jones

unread,
Mar 21, 2002, 12:40:14 AM3/21/02
to
In rec.games.roguelike.angband Steven Fuerst <s...@mssl.ucl.ac.uk> wrote:

> Hansjorg Malthaner <hansjoerg...@danet.de> wrote:
>> following the discussion about Lua scripting in rgra, few questions about
>> the basics of scripting popped into my mind:
>>
>> The very basic question:
>>
>> - what functionality should be externalized into scripts?

> High-level things. Instead of adding heaps of tiny fragments of C
> code everywhere every time you need to add functionality, create a set
> of hooks - and use those as an interface. If you pick the right
> interface, you'll find that you can export the "exceptions" to the
> scripting language, and leave the common-code alone. This adds
> enormously to code cleanliness, and makes it extremely easy to make
> modifications that were once very difficult.

Anyone interested in this may want to check out PAngband, if the sources are
still easily available. It worked much like Steven describes. There were
about 50 different "events" that the main C code could generate. The Python
scripts could handle (or not) each event seperately and do arbritrary things.

This allowed for great flexibility. If you wanted to add a new command, you
could simply handle the EVENT_COMMAND event, and if the key pressed was for
your new command, do whatever you wanted to do. If you wanted a monster to
summon 10 monsters after dying, handle the EVENT_MONSTER_DEATH and do the
right things.

The implementation was admittedly a little more clumsy than I'd like, but
it was much more flexible than the Lua implementation I've seen.

Keldon

Arcum Dagsson

unread,
Mar 21, 2002, 12:52:51 AM3/21/02
to
In article <u9i8ijq...@corp.supernews.com>,

Actually, neither of them were games in and of themselves, but engines for
games. I recall having a bit of fun playing with laying out levels, and
programming monsters, objects, and switches in ZZT. It had a number of
limitations, though, and the source code no longer exists for ZZT, IIRC. Lots of
fun, though...

--
--Arcum
"There was a terrible ghastly silence.
There was a terrible ghastly noise.
There was a terrible ghastly silence. "

Hansjörg Malthaner

unread,
Mar 21, 2002, 3:39:56 AM3/21/02
to
Hi,


Yesterday evening (CET) I made a first test with Lua scripting for my
project, H-World. It worked surprisingly well. In less that 1 1/2 hours I
had the lua interpreter integrated and built a first bridge to call Lua
scripts on an event.

My test: If the player 'u'ses an item, a lua function can be executed to
determine what should happen. I have no idea at the moment if this is a
clever thing, but it worked nearly immediately.

Somone suggested to bind scripts to events. I think this is what I'll do.
The game engine generates events like 'use item', 'wield item', 'take off
item' etc. Basically an event for everything the player can do. If an object
is involved in the action (always an item in the above given examples), the
item is inquired for a Lua function name (configured in the item
configuration file, that is a text file like in Angband) and if a function
is bound, this function is then called, the parameter are a handle to the
item and a handle to the user (the player or a monter). Thus most
functionality can be externalized into scripts.

To alter the games data, I'll export the following to the scripts:

world class - to load/generate levels
level class - to access game levels
sqaure class - to access sqaures within a level
thing class - in H-World monsters, items and the player are objects of the
thing class

Maybe more will be neccesary. If somone has an idea if the above are a good
or bad idea to export, please let me know. Only the public part of the
interfaces will be exported - well, ok, without knowing the code you can't
judge if that's good or not.


Combat will be scriptable, too, with events generated before attack, for the
attack and after an attack. There will be default implementations for all
three, but each wepaon (item) or monster can override them and replace them
with something else (another script). That means, special weapons or special
monsters can have completely different scripts for combat than the ordinary
things - I think this will allow some nice effects for special or boss
monsters and special weapons.


H-World will most likely become a game engine and a default game built on
it. The game engine will most likely stay closed source, and the game will
be Lua scripts - 'open source' in that sense that everyone can edit them,
add new scripts or whatever he wants to do with them. I definitely hope that
someone will start to build his own game or variant with it some day, when
H-World is off the ground and the engine is complete. But as of yet this is
far future.

It seems that for a closed source engine, scripting is essential - the
configuration files H-World currently uses allow to define the game world,
but the functionality can't be changed. By using scripts, the functionality
can at least be extended, that should be a great benefit.


Someome said, altering a C file and doing 'make' is fast enough. I agree,
but somehow altering a lua script and just restart the game engine feels
more convenient IMO. There is even the chance to reload altered scripts
while the game is running - i.e. if you test a quest, and you find a
mistake, you can alter the script, reload it (without exiting the main
program) and test the change. I don't know yet if this is a good idea, but
at least it is an option.


Last but not least, scripts have a definite 'coolness factor' :)


Btw, I want to gratulate the Angband maintainers for their choice of Lua.
I've seldom seen a component or subsystem that could be integrated that
smoothly and without problems.


Kind regards,
Hansjörg Malthaner

http://h-world.simugraph.com

Steven Fuerst

unread,
Mar 21, 2002, 3:47:20 AM3/21/02
to
Joseph William Dixon <aa...@chebucto.ns.ca> wrote in message news:<Pine.GSO.3.95.iB1.0.102...@halifax.chebucto.ns.ca>...

> On 20 Mar 2002, Steven Fuerst wrote:
> > > Why did it work well for 10+ years without scripts if scripting is such
> > a good idea?
> >
> > The whole concept of "well" is being redefined. Scripting allows you
> > to do things you couldn't do before without huge amounts of effort.
>
> Like what? The only effort scripting saves is that you don't have to go
> through the torturous process of typing 'make' and waiting less than a
> minute. ['kay, 7 minutes for my own Gumband - 12 minutes for the last
> vanilla alpha (4? 6?) I tried, thanks to the Lua code - but on a more modern
> system compilation takes almost no time at all.

Nope - this isn't what you should use scripting for. Simply rewriting
current code in a new language is a waste of time.

What scripting is good for is moving all of the 'exceptions' into one
spot. Instead of a feature having tiny fragments of code scattered
everywhere, you can have them all in one spot. You can do this via C
as well - but the result isn't very pretty...

The fields code in [Z] is a test to see how far the concept can go in
C alone. The result is very powerful, but very complicated.
Converting that code to scripts would result in something slightly
slower, of equal power, and of much less complexity. The reason the
complexity is lowered is because you can abstract it away into the
black-box that is the language interpreter. You don't need to know
how the interpreter works in order to program in the scripting
language. You do need to know how the fields code works if you want
to use it.

> On the other hand, Lua *adds* tons of effort - you have to learn a new
> programming language which, unlike C, you can't just walk into a bookstore
> and buy a textbook (even in the specialty bookstores locally) on, or learn
> in a formal setting (such as high school, community/technical college, or
> university).

Yes - it does add another barrier. However that barrier is rather
small, and when the interface is well-designed, one worth crossing.

Steven

Steven Fuerst

unread,
Mar 21, 2002, 4:11:28 AM3/21/02
to
Hansjörg Malthaner <hansjoerg...@danet.de> wrote in message news:<3C98D026...@danet.de>...

> Hi Steven,
>
> nice to meet you :)
>
> Steven Fuerst wrote:
> >
> > Hansjörg Malthaner <hansjoerg...@danet.de> wrote in message news:<3C985209...@danet.de>...
>
> > > The very basic question:
> > >
> > > - what functionality should be externalized into scripts?
> >
> > High-level things. Instead of adding heaps of tiny fragments of C
> > code everywhere every time you need to add functionality, create a set
> > of hooks - and use those as an interface.
>
> I was thinking about exporting the concepts of a 'level', a 'square', an
> 'item' and such. My project is OO so exporting those building blocks seemed
> to be a good idea. Still I'm unsure what parts of those concepts to expose
> ...

These don't sound like high-level things. Remember, scripting is
relatively slow. You can only convert things that aren't
speed-critical. (This is why scripting the AI is much harder than
people seem to think...)

Don't export each individual square. Export something that tells you
the contents of a square.

> > If you pick the right
> > interface, you'll find that you can export the "exceptions" to the
> > scripting language, and leave the common-code alone. This adds
> > enormously to code cleanliness, and makes it extremely easy to make
> > modifications that were once very difficult.
>
> Any hints how to find the 'right' interface?

Don't export anything.

Ask yourself what you want to do.

Export the minimal amount of functionality in order to do that. Try
to hide the gory details about how data-structures work. You don't
want to have to go back and change everything in the future when you
change an array into a linked list...



> > > Scripts (unlike datafiles) allow to externalize functionality. Usually they
> > > are used to separate the engine code (hardcoded) from the games code
> > > (scripts). Now, I'm unsure where to draw the line?
> >
> > Yeh - you need to think very hard about it. The most difficult thing
> > is getting the right API. Everything else is trivial in comparison.
>
> I agree with that. My problem is that I have no good idea how to find out
> which API to export. As you write below, my project is at the very
> beginning. I have no examples of usages which I could use as a guideline, I
> need to define this API right from mind and knowledge. That's what I'm stuck
> with now.

If your project is just starting, you don't need scripting. It is a
waste of time. You are still at the stage of working out which bits
of code are important, and which are exceptions from the rule. You
don't need to be buzz-word compliant at this stage.



> > > What is part of the
> > > engine, and what is part of the game. I.e. is a spells code part of the game
> > > engine, or part of the game? Should the spell code be in a script or a
> > > hardcoded program part?
> >
> > Low-level stuff is in-game. High-level stuff can be scripted. If you
> > move the boundary too far either direction, the problems should become
> > obvious.
>
> My problem is, on a scale of 1 to 10 about 3 to 7 look like an appropriate
> place to make the cut. You're right the far ends disqualify quite celarly,
> but I need advice to find a more precise location for the cut. A range of
> 50% of all is too big.
>
> Are the rules, hints, experiences that I could use as a guideline?

The smaller the interface, the better. However, you don't want to
make it too small if that means you are doing too much 'dirty work' in
the scripting language.

Only trial+error with itterative refinement will help you here.

> > If you are exporting too much low-level stuff, then you end up
> > rewriting the game in the new language. (This is obviously silly.)
> >
> > If you aren't exporting enough, and your interface is too high of a
> > level, then you will not be able to do the things you want to do with
> > it.
>
> That's correct, but not really helpful :(
> I mean that's an obvious truth, such generic advice isn't what I neeed.

Yes it is what you need. Just try to follow those rules and don't
access low-level stuff directly. It may be painful now to do it that
way, but it will save heaps of effort in the future. Low-level
concepts change over time. High-level concepts tend not to.

> > > If the separation of game code (scripts) and the engine (hardcoded) is the
> > > way to go, the next questions are about the interface between those two:
> > >
> > > - what should the game engine export to the scripts?
> >
> > As little as possible to get what is wanted done.
>
> What should it be able to do?

What do you want it to do?



> > > - how should scripts interact with the game engine?
> >
> > This is meaningless question with a huge number of possible answers
> > depending on which scripting language you use.
>
> I plan to use Lua - every Angband varaint seems to be going to use it, so I
> think it's best not to make an exception but use something that others use,
> too.

imho there is little point adding scripting to a closed-source project
that is barely started.



> > > I'd be also interested to learn the reasons, why something should be
> > > exported (or not) and why a certain type of interfacing is superior to
> > > another.
> >
> > Minimalism is good. Export as little as you can get away with.
>
> As a rule of thumb that is ok. But somehow you just tell me what I already
> know :(
> Can you give a more elaborate advice?

Ask yourself what is likely to be changed in the future with regards
to the code. Anything that is highly likely to be modified probably
isn't worth exporting directly. However, you may need to access that
stuff currently (before the rewrite). In which case abstracting
accessor functions are a good idea.

Don't look directly at the cave[][] array. Call a function in C code
that looks at the array.

> > > Finally my thinking led me to the question: Is scripting needed at all for a
> > > game?
> >
> > In a turing-complete sense? No. Is it nice to have? Yes.
>
> And in common sense ?
>
> I mean 'nice to have' isn't a strong argument IMO.

Yes it is. Scripting makes certain things much easier to do. You can
still do them without scripting, but is the extra effort worth it?
Those 'certain' things are important for adult projects, but not young
ones still in flux.

> > > For example, Angband is a game. It lived 10+ years well without
> > > scripting. Now there are tries to separate it into a engine and game
> > > (script) code. Is this a good idea at all?
> >
> > Yes.
>
> Why?

Why not?



> > > I'm asking because a while ago I was thinking about including a scripting
> > > langauge in my own roguelike project, but never found a 'must have' reason
> > > for scripting.
> >
> > Your roguelike is in its infancy iirc. You are right - an infant
> > project doesn't need scripting. An adult project with lots of
> > children is a different case.
>
> The project will grow. I want to prepare it now for a prosperous future. So
> I need to think about adding scripting support or not.

No you don't. Let it grow first. When it grows up, then you can
worry about it. Until then such worries are premature, and waste
time.



> It clear that I don't need scripting support now, but maybe it's a good idea
> to implement scripting support right from the beginning?

Nope. You'll end up changing way too much over time for it to be
worth it. Only when the game becomes fairly static are the benefits
there.

> And if I do so, I want to do it as good as possible.
>
> > Steven
>
> Kind reagrds,
> Hansjörg Malthaner

Steven

Hansjörg Malthaner

unread,
Mar 21, 2002, 5:00:24 AM3/21/02
to
Steven Fuerst wrote:
>
> Hansjörg Malthaner <hansjoerg...@danet.de> wrote in message news:<3C98D026...@danet.de>...

> > I was thinking about exporting the concepts of a 'level', a 'square', an
> > 'item' and such. My project is OO so exporting those building blocks seemed
> > to be a good idea. Still I'm unsure what parts of those concepts to expose
> > ...
>
> These don't sound like high-level things. Remember, scripting is
> relatively slow. You can only convert things that aren't
> speed-critical. (This is why scripting the AI is much harder than
> people seem to think...)
>
> Don't export each individual square. Export something that tells you
> the contents of a square.

Well, the square is an object, and part of it's interface is a method to
determine the contents of that sqaure. So if you ask to export something to
dteremine the contents of the squre, this is right the square itself. So IMO
even if you say I'm doing the wrong thing, it's quite what you advice ?!



> > > If you pick the right
> > > interface, you'll find that you can export the "exceptions" to the
> > > scripting language, and leave the common-code alone. This adds
> > > enormously to code cleanliness, and makes it extremely easy to make
> > > modifications that were once very difficult.
> >
> > Any hints how to find the 'right' interface?
>
> Don't export anything.
>
> Ask yourself what you want to do.
>
> Export the minimal amount of functionality in order to do that. Try
> to hide the gory details about how data-structures work.

This I good practise in OOP anyways - I'm not so stupid to expose such
things.

> You don't
> want to have to go back and change everything in the future when you
> change an array into a linked list...

That's what interfaces are for (I mean to hide those deatils). I don't plan
to export such implementation details.



> > > If you are exporting too much low-level stuff, then you end up
> > > rewriting the game in the new language. (This is obviously silly.)
> > >
> > > If you aren't exporting enough, and your interface is too high of a
> > > level, then you will not be able to do the things you want to do with
> > > it.
> >
> > That's correct, but not really helpful :(
> > I mean that's an obvious truth, such generic advice isn't what I neeed.
>
> Yes it is what you need. Just try to follow those rules and don't
> access low-level stuff directly. It may be painful now to do it that
> way, but it will save heaps of effort in the future. Low-level
> concepts change over time. High-level concepts tend not to.

Actually my experience is different (maybe we have different ideas of
'low-level'). The concept of a sqaure is unlikely to change (at least the
interface, the implementation may change). The monster AI is likely to
change, even it's interface.



> > I plan to use Lua - every Angband varaint seems to be going to use it, so I
> > think it's best not to make an exception but use something that others use,
> > too.
>
> imho there is little point adding scripting to a closed-source project
> that is barely started.

Barely started? You hurt me. It's nearly a year now, that I work on it, and
most of the basic concept work.

Reagrdless of that, I think especially for a closed source project scripting
is important: if someone cannot change the core, the scripts are the only
thing he can change to change the game. IMO a closed source project needs
good scripting support much more than a open source project, wehre the
source are changeable by everyone.

> > I mean 'nice to have' isn't a strong argument IMO.
>
> Yes it is. Scripting makes certain things much easier to do. You can
> still do them without scripting, but is the extra effort worth it?
> Those 'certain' things are important for adult projects, but not young
> ones still in flux.

And doing everything twice, like you do now? I think changing a script is
easier than changing C or C++ code, so using scripts from the start should
be easier, especially for a project that is 'in flux' (which I don't assume
that H-World is, the interfaces of the basic data structures like levels and
sqaures haven't changed since many months).

Why is Lua advised to be suitable for rapid prototyping if it wasn't the
easy adaption?

> > It clear that I don't need scripting support now, but maybe it's a good idea
> > to implement scripting support right from the beginning?
>
> Nope. You'll end up changing way too much over time for it to be
> worth it. Only when the game becomes fairly static are the benefits
> there.

IMO if the interfaces are fairly stable, it's enough stability to think
about scripting.

The interfaces for the level, sqaure and thing classes didn't change quite
some time, have proven to be suitable for their tasks. Unlike your ZAngband
development, I have a design document which tells what features will be
there, and thus I can create interfaces to suit the needs quite early on - I
know what needs to be done later on. It not doing something, seeing it is
bad, and then doing it some other way. I prefer to think first, and then do
the best solution. That's also the reason why I'm asking here, I don't want
to do the trial-and-error stuff, but develop a good design and then just
implement the design.

But anyways, regardless what I do, you won't like my ideas.

> Steven

c.u.
Hajo

Hansjörg Malthaner

unread,
Mar 21, 2002, 5:49:45 AM3/21/02
to
Keldon Jones wrote:
>

> >> - what functionality should be externalized into scripts?
>
> > High-level things. Instead of adding heaps of tiny fragments of C
> > code everywhere every time you need to add functionality, create a set
> > of hooks - and use those as an interface.

[snip]

> There were
> about 50 different "events" that the main C code could generate. The Python
> scripts could handle (or not) each event seperately and do arbritrary things.
>
> This allowed for great flexibility. If you wanted to add a new command, you
> could simply handle the EVENT_COMMAND event, and if the key pressed was for
> your new command, do whatever you wanted to do. If you wanted a monster to
> summon 10 monsters after dying, handle the EVENT_MONSTER_DEATH and do the
> right things.

This sounds very good, and matches my own thinking widely. I'll use this
approach, and bind sript/lua function calls to events.

> Keldon

Kind regards,
Hansjörg Malthaner

Hansjörg Malthaner

unread,
Mar 21, 2002, 6:10:48 AM3/21/02
to
Rune Jarnes wrote:
>
>
> > - what functionality should be externalized into scripts?

[snip]

> You must realize that there is no one single response to this that is the
> truth. Whatever the designer(s) decide to externalize is entirely up to what
> they value. That will be subjective and thus there is no generic truth
> answer to this.

Well, ok - I was hoping for some answers like 'best practises' or help
backed with good/bad experience in another project.



> Here you have two conflicting requirements that addresses what I mean
> - It should be easy to add to the game
> - It shall be possible to script anything, right down to the core mechanics
>
> You will not be able to provide a single solution (truth) that addresses
> both of these requirements.

My current idea is, to script everything above the world data structure
level. Concepts like

- a game level
- this level is made of sqaures
- the sqaures are rectangular
- there can be items and monsters located on a sqaure
- there can be a feature like a stair or door on a square

will be hardcoded parts of the game engine. Everything above IMO is part of
the game and therefore should be externalized into scripts.

For sake of performance, the field of view code and such will be part of the
game engine, too.

Steven says, this is wrong. Are there other opinions, or is this really the
wrong way to go?

> > If the separation of game code (scripts) and the engine (hardcoded) is the
> > way to go, the next questions are about the interface between those two:
> >
> > - what should the game engine export to the scripts?
> > - how should scripts interact with the game engine?
> > - how should the interface expose the exports of the game engine to the
> > scripts (hereby I mean, how should the exports look like when used in a
> > script) ?
>
> Again, very subjective. First of all, you probably want certain core
> mechanics to stay hidden.

Nothing pops into my mind (the usuall non-imaginative programer syndrom). Do
you have examples?

> The next (if you care) is to consider your target
> audience. If they are very creative, but not very analytical (usually
> conflicting traits), it should be easy to add to the game, thus scripting /
> externalization must be pretty simple if you want them to use this.

I think the target audience for the scripts will be the programmer with some
basic experience in a procedureal languge, and a faint idea of OOP. I guess
this is what you call the analytical ones.

This choice is not backed with reasons, it is just that I think this is what
I want to have.

> So target audience, developer(s) philosophy / goal will shape the solution
> that is presented.

Probaly it matches well, if I externalize most game mechanics, and the
target audience are programmers with basic experience. The core code is
hidden, but there are still many details to be solved in the scripts.

> > I'd be also interested to learn the reasons, why something should be
> > exported (or not) and why a certain type of interfacing is superior to
> > another.
>
> This can of course be addressed analytically, but this will be a lot of
> work. I'm not up to it. I believe it would end up in a matrix, where you
> could plot a position (your decision) and as a function of that, get the
> advantages and disadvantages of that solution.

> Script is only needed if you want to provide a simpler interface to people


> that can add to the game, but that doesn't have the necessary core skills.
> If your scripting doesn't add value in this respect, then it's pretty
> worthless IMO.

I think a simpler interface is at least one of my goals. The other is a
clean separation of engine and game. Scripting will help to reach both goals
IMO.

> > I'm asking because a while ago I was thinking about including a scripting
> > langauge in my own roguelike project, but never found a 'must have' reason
> > for scripting. Thus I went on without a scripting language. Now I see the
> > Angband maintainers have a strong idea that scripting is a 'must have' for
> > Angband, and I'm wondering, if my thinking was wrong.
>
> Thinking is never wrong :)

Thanks :)



> I'll add a favourite philosophy of mine:
> If you can't efficiently express yourself in a language, be it a scripting
> language, or the chosen core language->Think again. Start with how you want
> to express yourself (usually textually, but there are other forms) and work
> from that.

This is a good idea :)
Thanks, I'll put that to a test and see what's the result!

(C++ - the current languge I use for the engine - is awkward, dangerous and
slow to code. Of course purely IMO)



> And finally, the point to scripting isn't that you don't have to recompile.
> Honestly, where's the hassle in that. You still have to test and distribute
> the files. IMHO The point with scripting is that CREATIVE PEOPLE can express
> THEIR IDEAS in a manner more suitable to them.

*Ouch*

But I agree in most points. The roundtrip times are shorter, but probaly not
significantly, to justify scripting just because of the time savings. But it
seems to be easier to debug scripts than to debug C code - maybe because
ther is more control about script execution - I don't know yet if this
applies to Lua scripts.

The *ouch* was because of the creative people. I think software designers
are creative people, too, but I'm sure you meant creativitiy as in arts. And
that's what I was not thinking about ...

> Best Regards
> Rune Jarnes

Kind regards,
Hansjörg Malthaner

DarkGod

unread,
Mar 21, 2002, 6:56:40 AM3/21/02
to
While under the effect of mushrooms of hallucination "Keldon Jones"
<kel...@ont.com> wrote:

> This allowed for great flexibility. If you wanted to add a new command,
> you could simply handle the EVENT_COMMAND event, and if the key pressed
> was for your new command, do whatever you wanted to do. If you wanted a
> monster to summon 10 monsters after dying, handle the
> EVENT_MONSTER_DEATH and do the right things.
>
> The implementation was admittedly a little more clumsy than I'd like,
> but it was much more flexible than the Lua implementation I've seen.

Look at ToME cvs, tahst the way it works. But it also tries to add
niceness for stuff like spells and quests so they are easier to add

--

-----------------------+----------------------------------------------
DarkGod comes from | Do not meddle in the affairs of wizards
the hells for YOU ! :) | because they are subtle and quick to anger.
-----------------------+----------------------------------------------
Pe W Olorin YSo L:50 DL:696 A+++ R+++ Sp++ w:Mage Staff of Mana(240%)
Pe*/PM*(Cr) D H- D c++ f- PV s- TT- d++ P++ M+ C- S++ I+++ So++ B/-
ac- GHB- SQ+ RQ V+++ F:Mage playing Mage-like(see Pernangband Sorcerors)

Jonathan Ellis

unread,
Mar 21, 2002, 9:07:35 PM3/21/02
to

Joseph William Dixon wrote in message ...

>On Wed, 20 Mar 2002, Rune Jarnes wrote:
>> Here you have two conflicting requirements that addresses what I mean
>> - It should be easy to add to the game
>
> Then why go with Lua? It's much easier to add to the game in C - the
>number of people who know C is sooooo much greater than those who know
Lua,
>therefore more people are competent to add to the game.

The trouble is: There are various bits in the source in C which are
pretty easy to understand, and thus edit.

However, not everybody (yet) can compile, and any tweaking the C
code requires recompiling.

With the lua scripts as they are, more things can be tinkered with,
without the need to recompile: which makes changing things and
playtesting things a lot easier, as proposed changes can reach a much
wider audience while still remaining in the realms of proposals and
patches, rather than being "actual" changes which people might later
decide to like, or dislike, but can't then do anything about because
it's not worth the bother to the maintainer of changing it back.

Personally, I think it would have been better to release the
GW-spell-list changes in the form of an easily applicable and
play-test-able patch - p_class.txt, object.txt (in the edit files) and
spells.lua (in the script files): rather than calling it a whole new
version. ;-)

Jonathan.

Astromarine

unread,
Mar 21, 2002, 9:19:20 AM3/21/02
to
On Thu, 21 Mar 2002 11:00:24 +0100, Hansjörg Malthaner wrote:


> But anyways, regardless what I do, you won't like my ideas.
>
>> Steven
>
> c.u.
> Hajo

This was being one of the best discussion I have seen in rgra. That line
is uncalled for. *sigh*

Abilio

cropt

unread,
Mar 21, 2002, 9:19:02 AM3/21/02
to
In rec.games.roguelike.development Steven Fuerst <s...@mssl.ucl.ac.uk> wrote:
> What scripting is good for is moving all of the 'exceptions' into one
> spot. Instead of a feature having tiny fragments of code scattered
> everywhere, you can have them all in one spot. You can do this via C
> as well - but the result isn't very pretty...

I think scripting makes people think about the code in ways which make
the reasons behind OO practices seem obvious. These practices should
make the code easier to change/maintain regardless of any boost scripting
itself gives.
Domain specific languages are often scripted. I think the borg has its
own language. Simple non-general purpose languages can make it easier
for other to modify.

Hansjörg Malthaner

unread,
Mar 21, 2002, 9:32:38 AM3/21/02
to

Sorry.

> Abilio

Steven Fuerst

unread,
Mar 21, 2002, 9:47:28 AM3/21/02
to
Hansjörg Malthaner <hansjoerg...@danet.de> wrote in message news:<3C99AF38...@danet.de>...

> Steven Fuerst wrote:
> >
> > Hansjörg Malthaner <hansjoerg...@danet.de> wrote in message news:<3C98D026...@danet.de>...
>
> > > I was thinking about exporting the concepts of a 'level', a 'square', an
> > > 'item' and such. My project is OO so exporting those building blocks seemed
> > > to be a good idea. Still I'm unsure what parts of those concepts to expose
> > > ...
> >
> > These don't sound like high-level things. Remember, scripting is
> > relatively slow. You can only convert things that aren't
> > speed-critical. (This is why scripting the AI is much harder than
> > people seem to think...)
> >
> > Don't export each individual square. Export something that tells you
> > the contents of a square.
>
> Well, the square is an object, and part of it's interface is a method to
> determine the contents of that sqaure. So if you ask to export something to
> dteremine the contents of the squre, this is right the square itself. So IMO
> even if you say I'm doing the wrong thing, it's quite what you advice ?!

No - the two are subtly different.

Exporting the data directly and exporting a function that looks at
that data yields different code. The first is much less flexible.



> > > > If you pick the right
> > > > interface, you'll find that you can export the "exceptions" to the
> > > > scripting language, and leave the common-code alone. This adds
> > > > enormously to code cleanliness, and makes it extremely easy to make
> > > > modifications that were once very difficult.
> > >
> > > Any hints how to find the 'right' interface?
> >
> > Don't export anything.
> >
> > Ask yourself what you want to do.
> >
> > Export the minimal amount of functionality in order to do that. Try
> > to hide the gory details about how data-structures work.
>
> This I good practise in OOP anyways - I'm not so stupid to expose such
> things.

You may say this now, but in practice your code doesn't seem to follow
those rules in other things you have done.

>
> > > > If you are exporting too much low-level stuff, then you end up
> > > > rewriting the game in the new language. (This is obviously silly.)
> > > >
> > > > If you aren't exporting enough, and your interface is too high of a
> > > > level, then you will not be able to do the things you want to do with
> > > > it.
> > >
> > > That's correct, but not really helpful :(
> > > I mean that's an obvious truth, such generic advice isn't what I neeed.
> >
> > Yes it is what you need. Just try to follow those rules and don't
> > access low-level stuff directly. It may be painful now to do it that
> > way, but it will save heaps of effort in the future. Low-level
> > concepts change over time. High-level concepts tend not to.
>
> Actually my experience is different (maybe we have different ideas of
> 'low-level'). The concept of a sqaure is unlikely to change (at least the
> interface, the implementation may change). The monster AI is likely to
> change, even it's interface.

I beg to differ. In the case of Angband, the data structure of a
'square' has changed many times in the past. (I can count at least
five changes.) The AI has also changed many times. Virtually none of
the game has stayed the same on a code level. However the basic
'concepts' of how things work have not changed much over that time.
You still have objects, monsters and terrain features, even if each is
represented in a totally different way.



> > > I plan to use Lua - every Angband varaint seems to be going to use it, so I
> > > think it's best not to make an exception but use something that others use,
> > > too.
> >
> > imho there is little point adding scripting to a closed-source project
> > that is barely started.
>
> Barely started? You hurt me. It's nearly a year now, that I work on it, and
> most of the basic concept work.

1 year vs a decade is 'barely started' imho. If your game still
exists ten years from now, it is highly likely that almost all of the
current code will no longer be there.



> Reagrdless of that, I think especially for a closed source project scripting
> is important: if someone cannot change the core, the scripts are the only
> thing he can change to change the game. IMO a closed source project needs
> good scripting support much more than a open source project, wehre the
> source are changeable by everyone.

That's true... but if I were you I'd concentrate on getting a
'working' game first. Once that is done, and you have a population of
players willing to extend it, then it will be worth adding scripting.



> > > I mean 'nice to have' isn't a strong argument IMO.
> >
> > Yes it is. Scripting makes certain things much easier to do. You can
> > still do them without scripting, but is the extra effort worth it?
> > Those 'certain' things are important for adult projects, but not young
> > ones still in flux.
>
> And doing everything twice, like you do now?

I'm sorry - I don't understand.

If you're talking about recoding something - then yes. Things get
recoded all the time. It is impossible to see the best way of doing
something on the first go. The largest projects tend to 'feel their
way forward', since any major planning will tend to miss the small
(but important) details that often can cause a rethink of the whole
solution.

> I think changing a script is
> easier than changing C or C++ code, so using scripts from the start should
> be easier, especially for a project that is 'in flux' (which I don't assume
> that H-World is, the interfaces of the basic data structures like levels and
> sqaures haven't changed since many months).

You are right in that changing a script is easy. You are wrong, in
that getting the right interface is not easy. Even if your
data-structures haven't changed for a few months, that doesn't mean
they are very stable yet...

>
> Why is Lua advised to be suitable for rapid prototyping if it wasn't the
> easy adaption?

'Rapid prototyping' often refers to the ease of representing complex
data structures with small amounts of code. It also often means the
ability to edit code that is currently running.



> > > It clear that I don't need scripting support now, but maybe it's a good idea
> > > to implement scripting support right from the beginning?
> >
> > Nope. You'll end up changing way too much over time for it to be
> > worth it. Only when the game becomes fairly static are the benefits
> > there.
>
> IMO if the interfaces are fairly stable, it's enough stability to think
> about scripting.

Perhaps.



> The interfaces for the level, sqaure and thing classes didn't change quite
> some time, have proven to be suitable for their tasks. Unlike your ZAngband
> development, I have a design document which tells what features will be
> there, and thus I can create interfaces to suit the needs quite early on - I
> know what needs to be done later on.

Are you so sure about that? I think you'll find that you may know
what you want - but you won't know exactly how you'll implement it.
Implementation details matter.

> It not doing something, seeing it is
> bad, and then doing it some other way. I prefer to think first, and then do
> the best solution. That's also the reason why I'm asking here, I don't want
> to do the trial-and-error stuff, but develop a good design and then just
> implement the design.

The problem is that you cannot think of everything. Assuming you can
is silly. Yes - try to think as much as possible, but realise you are
only human. Later on you will be able to replace current code with
stuff that is much better - simply from all the experience you will
have gained along the way.



> But anyways, regardless what I do, you won't like my ideas.

Now that is a rather broad and sweeping statement...

Steven

Hansjörg Malthaner

unread,
Mar 21, 2002, 10:41:44 AM3/21/02
to
Steven Fuerst wrote:

> > This I good practise in OOP anyways - I'm not so stupid to expose such
> > things.
>
> You may say this now, but in practice your code doesn't seem to follow
> those rules in other things you have done.

Well .. the only code you had to judge is something I hacked together within
a few hours without caring much. I never made other code open source so you
can't judge.

What should I do to make you change your mind?

> > Barely started? You hurt me. It's nearly a year now, that I work on it, and
> > most of the basic concept work.
>
> 1 year vs a decade is 'barely started' imho. If your game still
> exists ten years from now, it is highly likely that almost all of the
> current code will no longer be there.

It still hurts - you jumped into a mature project and now judge me standing
on the shoulders of giants. From there it's easy to say: "see how small you
are". I build my game off the ground, it's tough work. always being reminded
that other projects are so much more mature doesn't help me at all.



> > Reagrdless of that, I think especially for a closed source project scripting
> > is important: if someone cannot change the core, the scripts are the only
> > thing he can change to change the game. IMO a closed source project needs
> > good scripting support much more than a open source project, wehre the
> > source are changeable by everyone.
>
> That's true... but if I were you I'd concentrate on getting a
> 'working' game first. Once that is done, and you have a population of
> players willing to extend it, then it will be worth adding scripting.

What do you call a working game?
In H-World the player can walk around, fight monsters, pick up things, wield
equipment, take it off, drop things. What's missing is shooting and magic.
IMO the basics work.

Asides from that it is intended to be a game engine, in first place, and
only a simple exemplary game will be delivered with it. IMO now, that the
basics work, is a good moment to think about scripting.

I.e. for Simutrans it took three years until I had a community of players.
But still some decisons can be made before, some even should be made before.
I think scripting shoudl be available before the game engine gets public
acknowledgement, not after.

> > > > I mean 'nice to have' isn't a strong argument IMO.
> > >
> > > Yes it is. Scripting makes certain things much easier to do. You can
> > > still do them without scripting, but is the extra effort worth it?
> > > Those 'certain' things are important for adult projects, but not young
> > > ones still in flux.
> >
> > And doing everything twice, like you do now?
>
> I'm sorry - I don't understand.

I meant first coding functionality in C or C++ and then later when scripting
is added, writing it again in Lua is doing work twice. I'd like to save this
additional work, by using scripts right from the beginning.

> > I think changing a script is
> > easier than changing C or C++ code, so using scripts from the start should
> > be easier, especially for a project that is 'in flux' (which I don't assume
> > that H-World is, the interfaces of the basic data structures like levels and
> > sqaures haven't changed since many months).
>
> You are right in that changing a script is easy. You are wrong, in
> that getting the right interface is not easy.

Well, I just hoped for help when I asked - you always tell me how bad my
things are done, so it's reasonable that I ask others first, isn't it?

> Even if your
> data-structures haven't changed for a few months, that doesn't mean
> they are very stable yet...

I was talking about interfaces, not data structures.

> > Why is Lua advised to be suitable for rapid prototyping if it wasn't the
> > easy adaption?
>
> 'Rapid prototyping' often refers to the ease of representing complex
> data structures with small amounts of code. It also often means the
> ability to edit code that is currently running.

Rapid protoyping also means building test or exemplary systems fast. That
was what I meant here.



> > > > It clear that I don't need scripting support now, but maybe it's a good idea
> > > > to implement scripting support right from the beginning?
> > >
> > > Nope. You'll end up changing way too much over time for it to be
> > > worth it. Only when the game becomes fairly static are the benefits
> > > there.
> >
> > IMO if the interfaces are fairly stable, it's enough stability to think
> > about scripting.
>
> Perhaps.

Should I really wait ten years as you adviced above?



> > The interfaces for the level, sqaure and thing classes didn't change quite
> > some time, have proven to be suitable for their tasks. Unlike your ZAngband
> > development, I have a design document which tells what features will be
> > there, and thus I can create interfaces to suit the needs quite early on - I
> > know what needs to be done later on.
>
> Are you so sure about that? I think you'll find that you may know
> what you want - but you won't know exactly how you'll implement it.
> Implementation details matter.

Time will tell how good that design is. So far I'm very confident that at
least the basic building blocks are very well designed.

If you don't believe me, you could ask Björn Bergström
<dungeon...@swipnet.se> - he has the sources for backup purposes and can
judge independantly. He also reviewed some of my code.



> > It not doing something, seeing it is
> > bad, and then doing it some other way. I prefer to think first, and then do
> > the best solution. That's also the reason why I'm asking here, I don't want
> > to do the trial-and-error stuff, but develop a good design and then just
> > implement the design.
>
> The problem is that you cannot think of everything. Assuming you can
> is silly. Yes - try to think as much as possible, but realise you are
> only human. Later on you will be able to replace current code with
> stuff that is much better - simply from all the experience you will
> have gained along the way.

Sorry if I sounded so arrogant. But you always treat me like a stupid child.
Maybe you could assume at least some basic skills if you give me advice? I
mean, telling you that I've studied computer sciene and work for several
years as appliacation develoepr doesn't seem to impress you, so I just beg
for a bit of acceptance.



> > But anyways, regardless what I do, you won't like my ideas.
>
> Now that is a rather broad and sweeping statement...

Was there any idea I had proposed which was immediately called 'bad' by you?

See, in quite some projects I work together with other people, at work
(professional) and in private projects. Most of my coworkers are skilled
developers, too. My code gets reviewed by them, and quite often my solutions
are acknowledged to be good and thoughtful. This is quite strong contrast
to the feedback that you give me. Actually I'm out of wits what I could do -
the feedback I got from Björn in regard to my code in H-World was rather
positive, so I don't understand why you assume I'm not capable of following
the most basic rules.

But well, actually I don't need to convince you - the most important thing
is that my software works, is bug free and that my coworkers and I can
maintain it in the long run. So I shouldn't care if you treat me like a
fool. But somewhere there is pride in me, pride in my skills and in my work.
I have no project that is 10 years old (well I have, but it's nothing I'm
particularly proud of) the oldest successful project is 4 years. So you'll
always be able