Questions about scripting
Hansjörg Malthaner
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
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
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
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
>
> 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
>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
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
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
> 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
> 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
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
>
> 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
>
> following the discussion about Lua scripting in rgra, few questions about
> the basics of scripting popped into my mind:
> 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
>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
>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
> 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
> > 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
> 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
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
> 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
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
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
Steven Fuerst
> 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
> 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
>
> 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
>
> >> - 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
>
>
> > - 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
<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
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
> 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
> 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
Sorry.
> Abilio
Steven Fuerst
> 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
> > 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 to say that I have too litlte experience and need to wait. I
have no chance to get around this argument.
> Steven
c.u.
Hajo
Hansjörg Malthaner
> > > 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.
Unfortunately all you've seen was kind of a quick hack to implant the
iso-view into Angband without too much work. I'd like to say that isn't the
style I usualy use, but you wouldn't belive that either ..
c.u.
Hajo
Rune Jarnes
> 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...
Great answer, I expect you really address the general public here as I don't
have a stand in the lua discussion.
>
> > - 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.
The two requirements were chosen to show how requirements can compete, they
do not advocate a personal opinion. IMO core mechanics should be hidden.
Best Regards
Rune Jarnes
Rune Jarnes
> 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?
Why not start small, I think it is hard to give sound advice, given the
scope of the problem. Implement some parts of the core mechanics and some
scripting to play it out. This is the iterative development model that is
widely acknowledged and used now.
> > 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?
Well, physics for instance : There is gravity. Gravity is 9.8. Game
mechanics : when you move you move one square at a time. Monsters evaluate
and execute their moves after you move. These are foundation rules that
cannot be changed.
If you expose too much you will have effectively created a new language,
which may be just as inefficient expressionwise as the one you started out
with.
>
> > 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.
Let me rephrase this to a better, more general statement:
IMHO The point with scripting is that your TARGET AUDIENCE can express
THEIR IDEAS efficiently.
Best Regards
Rune Jarnes
Steven Fuerst
> 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.
You are right - I can judge you from the code I see. However, I can
also guess how much you know from the questions you ask...
> What should I do to make you change your mind?
Simply stop asking questions about things you say you know already.
(Especially if you will be offended by any answers given in good
faith.)
> > > 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.
I'm not saying you are small. I'm saying your current project is.
I've been there, done that, and have seen all sorts of projects from
the inside. I'm just trying to tell you what I see happen in general
with (open source) projects as time passes. Feel free to ignore that
advice.
> > > 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.
90% of the effort is spent in the last 10% of nearly everything. This
is a fairly common saying...
<snip>
> > > 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?
You ask, but always seem to argue with the resulting advice. It seems
you have already made your mind up before you ask. So why ask at all?
> > 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.
Now that doesn't make any sense. Are you saying you've built the
interface to the scripting code, and have had it stable for a few
months already?
<snip>
> > > > > 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?
I didn't say to wait ten years, I told you to wait until things
settled down (otherwise you'll end up duplicating work).
> > > 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.
I think I can say with some confidence that one year from now you will
spot things with your current design that could be improved. You
simply will have had more experience then. (I was also trying to hint
that the 'basic building blocks' are not the main driver with regards
to changing a design - but you've ignored that as well.)
> 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.
No I don't. I just get annoyed after trying to explain the same basic
concepts over and over again to you.
> 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.
I don't really care how much you've studied. I've seen graduates that
don't know what a bubble sort is. I've also seen fifteen-year olds
capable of making programs that are on the cutting edge of science.
What you do is important, not what you are.
> > > 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?
Nope. When you ask for advice, I give it. You don't tend to like
that advice though.
> 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.
Why do you keep asking about the most basic of rules?
> But well, actually I don't need to convince you...
Correct. I've actually been wondering why you take me so seriously.
I could be a 14yr old who doesn't actually know anything, and is just
trolling you...
Steven
Amy Vartdal
>> 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...
>
> Great answer, I expect you really address the general public here as I
> don't have a stand in the lua discussion.
Unless I'm mistaken, LUA is (nearly) pure C
--
amy
Garth Dighton
<Pine.GSO.3.95.iB1.0.102...@halifax.chebucto.ns.ca>:
>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.
For anyone who knows C, Lua is almost _trivial_ to learn. For anyone who
doesn't know programming, Lua is a reasonable place to start.
> 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...
To learn Lua, you have the very well-written, and short, Lua manual, as
well as other resources at www.lua.org, including a mailing list full of
helpful people, including the developers of the language.
> 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.]
>
The entire Lua manual is probably smaller than those 3 chapters -- Lua is a
very simple, clean language. (Probably the ugliest thing about it, from the
perspective of it's embedding in Angband, is that there are no bitwise
operators -- this is why Robert's using band() and bor() functions in his
scripts).
--
Garth Dighton
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
Check out our new Unlimited Server. No Download or Time Limits!
-----== Over 80,000 Newsgroups - 19 Different Servers! ==-----
Peter Seebach
Garth Dighton <gdig...@geocities.com> wrote:
>For anyone who knows C, Lua is almost _trivial_ to learn. For anyone who
>doesn't know programming, Lua is a reasonable place to start.
Learn? You mean, there's aspects of it that aren't obvious? I haven't
put any measurable time into it yet, but I can patch it.
>The entire Lua manual is probably smaller than those 3 chapters -- Lua is a
>very simple, clean language. (Probably the ugliest thing about it, from the
>perspective of it's embedding in Angband, is that there are no bitwise
>operators -- this is why Robert's using band() and bor() functions in his
>scripts).
C is a wonderful language. I love C. Everyone should learn C, just as
everyone should learn at least one or two foreign languages, and everyone
should try foreign food. Not everyone will want to use C regularly.
I don't see Lua as a bad idea at all; in fact, in many ways, it's an
improvement over the amazing hacks that populate the info files, and yet,
it still serves the same goals.
-s
--
Copyright 2002, all wrongs reversed. Peter Seebach / se...@plethora.net
$ chmod a+x /bin/laden Please do not feed or harbor the terrorists.
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Consulting, computers, web hosting, and shell access: http://www.plethora.net/
Hansjörg Malthaner
>
> Hansjörg Malthaner <hansjoerg...@danet.de> wrote in message news:<3C99FF38...@danet.de>...
> > 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.
>
> You are right - I can judge you from the code I see. However, I can
> also guess how much you know from the questions you ask...
I must accept that ... are my questions really that stupid?
But then I could quite frankly propose that you didn't understand my
question and therefore couldn't give me the advise that I had asked for,
just general rules, which I already knew.
Actaully I was that angry becuase you're advise implies quite a good deal of
stupidity on my side. Your advise wasn't particlulary helpful either,
because it was very general and basic knowledge, which I'm pretty aware of.
I was not angry becuase your advise is wrong, just becuase IMO I follow this
advise quite closely, and still always get the same advise as if I wouldn't
follow it.
If you advise repeteadly to follow a rule, which I already follow, this
implies I'd not follow the rule. If it's a basic rule, this implies that I
don't even know the most basic rules. That hurts.
> > What should I do to make you change your mind?
>
> Simply stop asking questions about things you say you know already.
> (Especially if you will be offended by any answers given in good
> faith.)
Somehow, only your answers tend to offend me - other had answered too, and I
had no problem with their answers. At least the other answer didn't always
imply that I'm too stupid to undertsand a higher level advise.
But you're right: most often when I ask, I already made a decision and just
ask to see, if I made a serious mistake.
> > > > 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.
>
> I'm not saying you are small. I'm saying your current project is.
> I've been there, done that, and have seen all sorts of projects from
> the inside. I'm just trying to tell you what I see happen in general
> with (open source) projects as time passes. Feel free to ignore that
> advice.
I will.
> > > > 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.
>
> 90% of the effort is spent in the last 10% of nearly everything. This
> is a fairly common saying...
I know that. Again this implies that I never heard this advise - as a
person who is programming more than 10 years, how stupid must I be if you
never ever could have heard this rule? At work and as well during my
training this rule was and is quite common knowledge.
> <snip>
>
> > > > 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?
>
> You ask, but always seem to argue with the resulting advice. It seems
> you have already made your mind up before you ask. So why ask at all?
As said above, to avoid serious mistakes.
But DarkGod advised me not to ask, before I made a implementation. Maybe
this is wiser - if I see this discussion it surely is. At least I don't get
placed as a fool all the time - after the implementation, I have a better
position to argue (if the implementation is good, of course).
> > > 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.
>
> Now that doesn't make any sense. Are you saying you've built the
> interface to the scripting code, and have had it stable for a few
> months already?
Not the interface to the scripting code. The interface of the
datastructures, I mean the interface between the program logic and the data
structures.
See, I do not usually access data directly. (I did this in iso-angband to
get the content of the cave array - but that array is declared extern, that
measn public access! No accessor methods existed, the temr package is no
accessor, it works in the other way. IMO if someone declares his data
extern, it's his fault if it gets accessed - he made it public. Using it
means just agreeing witht he contract that he offered!)
I try to avoid that at all if possible in my own programs. I have learned my
lessons about data hidng and proper interfaces. Angband IMO wasn't worh much
effort, so I used the simplest possible solution. If I had knwon, that
you'll treat me like a foll for years if I publsih that code, believe me, I
had chosen another design!
Back to the qustion: In H-World, there are sets of methods to access
sqaures, levels items and such. Those methods are what I call the interface.
Ther is no data exposed. The methods, that is the interface for access, are
quite stable. Those is no data in the public interface, only methods.
The question is: I don't knwo which set of access methods I should export to
the scripts. I won't export data directly, just the accessor methods (as you
suggested).
Now I need rules and help to find a good set of sccessor methods which will
be exported to the scripts.
> <snip>
>
> > > > > > 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?
>
> I didn't say to wait ten years, I told you to wait until things
> settled down (otherwise you'll end up duplicating work).
But I think the things are stable enough - you just keep telling me they
cannot because too young!
IMO you shouldn't judge by the age so much, but by the functionality, that
is implemnted already.
I can never catch up a advance that is measured in age, I can only catch up
with functionality.
> > > > 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.
>
> I think I can say with some confidence that one year from now you will
> spot things with your current design that could be improved. You
> simply will have had more experience then.
Yeas, I agree with that. But I think now is the right moment to include
scripting. IMO the code is stable enough. My only question is about the
interface between the engine and the scripts.
I won't export data, I said that before. I want to export some accessor
functions (that's waht I call a interface). I'm unsure which accessor
functions are a good interface. I mean I have an idea which are, but seek
for either a validation (in which case your advise was not helpful at all,
because you never proposed a interface, just general rules that allow still
much varaition) or get a better interface proposed that I'll then use.
Such general advice like you give, doesn't help to improve the interface I
had in mind - the interface doesn't expose data, and IMO exports high level
constructs. We have difefret ideas about high-level, I've seen that. Well we
need to discuiss this another time.
So my interface followed your advice, even if I wasn't very satisfieed. I
could have made ten other interfaces which also fit to your advise. So you
didn't help me at all, just implied much stupidity on my side with every of
your advise.
> > 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.
An offer? Will you believe him? or someone else?
> > > > 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.
>
> No I don't. I just get annoyed after trying to explain the same basic
> concepts over and over again to you.
Thats is quite what annoys me too. I know those concepts (even if you assume
all the time I don't). So I'm quite angry getting the same advise all over.
IMO I follow those concepts, data hiding for example, quite strictly.
Advicing me to practise data hiding is a bad joke IMO because IMO I practise
it to the best extend possible, in most of my code.
I really hate getting advise which I follow already - it implies I wouldn't
follow this advise at the moment, which usually implies unkowledge or
stupidity. This hurts. And makes me look stupid, which I dislike pretty
much.
> > 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.
>
> I don't really care how much you've studied. I've seen graduates that
> don't know what a bubble sort is. I've also seen fifteen-year olds
> capable of making programs that are on the cutting edge of science.
>
> What you do is important, not what you are.
Shall I explain bubble sort now to prove my knowlegde? Or any of the others?
You judge always from that same pieces of code you've seen when I made the
iso-view open source. That was already pretty old code (4 years
approximatley, that means, written with much less knowledge), and I agree it
wasn't very high quality code. It was a quick and dirty solution. But it
hurts if you think I could not do better. I just don't have any idea how to
get that through to you.
> > > > 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?
>
> Nope. When you ask for advice, I give it. You don't tend to like
> that advice though.
Yes - you advice is too basic, you advise only the things I already know.
That is pretty useless. You always tell me how good you are, how much above
my skills. So I expect better advice from 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.
>
> Why do you keep asking about the most basic of rules?
Actually I didn't ask about the basic rules, at least I hoped for more high
level answers. My question seems to be quite misunderstandable, but I surely
didn't ask for waht you understood from the questions.
> > But well, actually I don't need to convince you...
>
> Correct. I've actually been wondering why you take me so seriously.
> I could be a 14yr old who doesn't actually know anything, and is just
> trolling you...
It's easy to troll me .
But, well, you have at least strong ideas, and most of the time, your advise
is true. Accessing data structures directly is a bad idea (I did that in
Iso-Anbband because is was the quickest solution, and reading XXX HACK XXX
in Angband every third function gave me confidence it's no problem to add
another hacky solution). So I think you know what you're talking about. (But
what I've seen from your asnwers you do hard to understand OO concepts). I
just hope to get advice on a level of equals, not like a beginner. Even if
my questions appear to be too simple, I can understand high level advice
(and if I actualy should get advice I cannot understand because it is too
high, I'll ask again).
I'm really angry to get treatet like a beginner by you all the time - I
program since 1989, have experience in C, C++, Java, assembly langauge on
difefrent systems, Modula-2, Scheme, Perl and some other languages. (Yes I
know you program a few years longer - you told me several times). Basically
my life until now was about programming - that is my job and my hobby.
Program design, especially OO design is one of biggest areas of interst. I
have published quite some fairly successful projects. I'm acknowledged in my
job as OOP expert, I even gave courses for beginners in OOP and design
patterns. I mean, the company surely did not chose me to give OOP courses
because I'm the worst of all OOP experts here.
You say that all doesn't matter, you'll just judge me by my questions and
what you've seen from my code. I have no idea how to prove my knowledge and
skills to you - the code you've seen is like it is, and other code you won't
see, because I don't open source anymore, and asides from iso-angband I
never did.
I can offer to send my code to trustworthy third party judges and get it
judged by them, if you accept this. But only if you accept their judgement,
not just as a joke to fool me again. You can ask my coworkers in different
projects for my skills. I'll give you their email addresses. But actually I
hate being treated like a beginner after I have such a long history in
programming and IMO good skills in both procedural and OO program design.
> Steven
c.u.
Hajo
Hansjörg Malthaner
>
[...]
> Why not start small, I think it is hard to give sound advice, given the
> scope of the problem. Implement some parts of the core mechanics and some
> scripting to play it out. This is the iterative development model that is
> widely acknowledged and used now.
Ok. I've started now, to externlize usages of items. If an item is used, a
propety of this item determines which lua function is called. Currently a
usage involves two object, the user, and the used thing. The lua script gets
both as parameters and can modify them.
I've made a test with a healing potion. I configured it to call a function
named "quaff", which then determines type and subtpye (type=potion,
subtype=healing1) and restores some hitpoints on the player. The result
value of the function determines if the object must be removed from the
players inventory (like for scrols and potions) or stays there.
This works well. It seems to be generic enough to implement a wide variety
of usages. Basically if someone wnats to add a radically new item with a new
behaviour, he can add the item to the data files, and implement a new lua
function for the usage - it seems this allows full configuarbility of item
behaviour :)
> > > 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?
>
> Well, physics for instance : There is gravity. Gravity is 9.8. Game
> mechanics : when you move you move one square at a time. Monsters evaluate
> and execute their moves after you move. These are foundation rules that
> cannot be changed.
Agreed. Both concepts will be part of the engine. But the effect of grivity
change onto a object can be externalized into a lua function (must not,
that's an option) - some items may be crushed by higher gravity, others
aren't affected much. The effect will be determined by the lua function.
Each item can have it's own function, or some can share a function - all
that is configurable. Looks like a powerful interface.
(In H-World gravity is a environmental value. Changes in the environment
affect items, and a connector function determines the effect. That the
general concept)
> Best Regards
> Rune Jarnes
c.u.
Hajo
Archibald
says...
Do you really think that anyone will create variant using your script
engine? I'm afraid that your hope is too optimistic. Are you trying to
make closed source engine with scripts which will allow to create games?
If yes, you have to consider some facts. There are only few game editors
which are acceptable by users (for example HoM&M and Starcraft) and
plenty of unused (Arcanum, Runesword). The good one are *simple*, or even
*very simple*. They haven't options like modify combat formula... You can
say that there is one good game edit engine with scripts and is called
Angband. Yes, you are right but it is *open source* which is very
important in this case and have huge comments in source code (almost
*every* line of code in Angband is commented...). Of course there is
scripting, but this is only to help variant creators, most modifications
are done directly in code. Do you really want to make another Angband?
Are you sure?
--
Archibald
Garth Dighton
<3c9a9546$0$79559$3c09...@news.plethora.net>:
>In article <3c9a845e$1...@news.newsgroups.com>,
>Garth Dighton <gdig...@geocities.com> wrote:
>>For anyone who knows C, Lua is almost _trivial_ to learn. For anyone
>>who doesn't know programming, Lua is a reasonable place to start.
>
>Learn? You mean, there's aspects of it that aren't obvious? I haven't
>put any measurable time into it yet, but I can patch it.
>
About the only thing I found un-obvious were the tag methods (which are
being replaced in the next version of Lua, but that doesn't matter for
Angband).
Tag methods are primarily useful for those implementing OO heirarchies and
similar in Lua.
(Someone asked if Lua is an OO language -- Lua concentrates on being a
'meta'-language in some ways. It doesn't come with any OO mechanism out-of-
the-box, but rather lets you develop your own OO (do you prefer single or
multiple inheritance, for instance?).
Hansjörg Malthaner
>
> Do you really think that anyone will create variant using your script
> engine?
At the moment? Surely not. In five years? Maybe.
> I'm afraid that your hope is too optimistic.
In first place I do H-World for fun of doing it. Second for trying all kind
of ideas I have about role playing games. Then last but not least, for
training C++ and OO design (in my job I do only java coding, and I want to
keep my C++ knowledge). This project is an experiment, but currently it's
going real fine. If it fails - well it was just a experiment, experiments
are allowed to fail :)
> Are you trying to
> make closed source engine with scripts which will allow to create games?
Yes.
> If yes, you have to consider some facts. There are only few game editors
> which are acceptable by users (for example HoM&M and Starcraft) and
> plenty of unused (Arcanum, Runesword). The good one are *simple*, or even
> *very simple*. They haven't options like modify combat formula... You can
> say that there is one good game edit engine with scripts and is called
> Angband. Yes, you are right but it is *open source* which is very
> important in this case and have huge comments in source code (almost
> *every* line of code in Angband is commented...). Of course there is
> scripting, but this is only to help variant creators, most modifications
> are done directly in code. Do you really want to make another Angband?
> Are you sure?
I clearly don't want to make another Angband. The goal is to try if I can
create a game engine and a roguelike game. If I succeed and it becomes
another Angaband - well, at least I have reached my goal to create it. If I
succed, and it gets different from Angband, what I hope, I'm happy. If
someone actually uses it in the end, I'm excited :) But I don't expect that
now, maybe just dream about it.
Just let me go on - it's my project, and I do it for my reasons. If others
like it, it's fine. If not, well, at least I had fun making it. Ask me in a
few years about the result :)
Nevertheless I'll try to consider your advice and keep it simple, at least
I'll try.
> --
> Archibald
Kind regards,
Hansjörg Malthaner
Icosahedron
commercial games that have had scripting are:
1) Freedom Force - super hero RPG that just came out. It uses Python
fairly extensively from the looks of it. Blade of Darkness used
Python as well. Interesting since I would have thought Python would
be inhibitive to real time games, but apparently not.
2) Quake - Quake C of course. Unreal uses UnrealScript as well.
UnrealScript has been heralded as a good programming language.
3) Abuse - hard to find, but a good example of using lisp for all but
the primitives.
4) Crash Bandicoot - the code for this would be hard to see though
since it's PS game.
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?
>
> 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
R Dan Henry
Malthaner <hansjoerg...@danet.de> transmitted thus:
>Archibald wrote:
>> Are you trying to
>> make closed source engine with scripts which will allow to create games?
>
>Yes.
And since H-World is *mainly* an engine, I'd say focus on getting
various types of things into the game and providing *excellent
documentation* of the user-editable parts of the game. Save building
up enough world details to have a playable game for last. Create
something like 3 weapons, 1 ranged weapon, 2 body armors, 3 monsters,
etc. if these items can be added by users. Maybe someone with fiddle
and create a full set for you before you reach that part... but you
really need to document everything nicely for that to happen.
Could also maybe help if I can get it to run on my machine. I'll give
it another try soon.
R. Dan Henry, Grand Pashah of Small Miscellaneous Objects
rdan...@earthlink.net
"Lately, the only thing keeping me from being a serial
killer is my distaste for manual labor." -- Dilbert
Kieron Dunbar
> 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. ;-)
I don't think it would have been better to do it like that, because changes like
that wouldn't have a sensible effect on a game in which the player goes from a
version with the old spell list to one with the new unless you tell people not
to continue mage games from one spell list to the next. If you call it a new
version, you can do whatever you think is best.
--
kwaheri, Kieron (reverse username to reply)
Arcum Dagsson
gandalf...@hotmail.com (Icosahedron) wrote:
> For more information about what might and might not be included, some
> commercial games that have had scripting are:
>
> 1) Freedom Force - super hero RPG that just came out. It uses Python
> fairly extensively from the looks of it. Blade of Darkness used
> Python as well. Interesting since I would have thought Python would
> be inhibitive to real time games, but apparently not.
>
> 2) Quake - Quake C of course. Unreal uses UnrealScript as well.
> UnrealScript has been heralded as a good programming language.
>
> 3) Abuse - hard to find, but a good example of using lisp for all but
> the primitives.
>
> 4) Crash Bandicoot - the code for this would be hard to see though
> since it's PS game.
And, of course, Baldurs Gate, Grim Fandango, and Escape from Monkey Island all
used Lua, the latter even having a bar named after the programming language
in-game...
From http://www.lua.org/uses.html
"Baldur's Gate
BioWare Corp.
Baldur's Gate is a role-playing game (RPG) that is scripted internally using
Lua. All debugging commands were exposed to Lua and a Lua prompt exposed to the
game. This allowed complex debugging without spending much development time
making debugging tools. See also AICompile, a script compiler for Baldur's Gate,
the File Format Hacking Project, and a list of cheat codes..."
--
--Arcum
Yellow bulldozers
Frolic in the drying mud
Arthurs home is gone
Hansjörg Malthaner
> On Fri, 22 Mar 2002 19:31:58 +0100, the disembodied brain of Hansjörg
> Malthaner <hansjoerg...@danet.de> transmitted thus:
>
>>Archibald wrote:
>
>>>Are you trying to
>>>make closed source engine with scripts which will allow to create games?
>>>
>>Yes.
>>
>
> And since H-World is *mainly* an engine, I'd say focus on getting
> various types of things into the game and providing *excellent
> documentation* of the user-editable parts of the game.
The documentation will probably be the most important part. Including
good examples with the default game is the second, I guess.
> Save building
> up enough world details to have a playable game for last. Create
> something like 3 weapons, 1 ranged weapon, 2 body armors, 3 monsters,
> etc. if these items can be added by users. Maybe someone with fiddle
> and create a full set for you before you reach that part... but you
> really need to document everything nicely for that to happen.
I think so.
I guess I should start documenting the data files and put the docs
online for reviews. Items, monsters and some aspects of the game world
are already configureable with data files, thus the docs can be tested
and tried in practise with the current release.
> Could also maybe help if I can get it to run on my machine. I'll give
> it another try soon.
The new version (0.0.3) is built with SDL 1.2 as it was suggested after
the last release. Maybe this one works better on your system.
The Windows version was tested with Win 2K and Win 98se. The Linux
version was tested with SuSE Linux 7.0 and some newer SuSE systems (Not
sure about the version number there).
> R. Dan Henry, Grand Pashah of Small Miscellaneous Objects
> rdan...@earthlink.net
Kind regards,
Hansjörg Malthaner
Archibald
says...
> Archibald wrote:
> >
> > In article <3C999C5C...@danet.de>, hansjoerg...@danet.de
> > says...
> >
> > [...]
> >
> > Do you really think that anyone will create variant using your script
> > engine?
>
> At the moment? Surely not. In five years? Maybe.
>
> > I'm afraid that your hope is too optimistic.
>
> In first place I do H-World for fun of doing it. Second for trying all kind
> of ideas I have about role playing games. Then last but not least, for
> training C++ and OO design (in my job I do only java coding, and I want to
> keep my C++ knowledge). This project is an experiment, but currently it's
> going real fine. If it fails - well it was just a experiment, experiments
> are allowed to fail :)
If this is an experiment then this is completely different story. I
misunderstood that your primary goal was to create game. But experiment
has their own rules...
[...]
> Nevertheless I'll try to consider your advice and keep it simple, at least
> I'll try.
This could be hard to consider in this case, experiments are rather crazy
and complicated, but not simple ;-)
--
Archibald
Mark 'Kamikaze' Hughes
<hansjoerg...@danet.de> spake:
> The very basic question:
> - what functionality should be externalized into scripts?
In my Hephaestus roguelike RPG construction kit
<http://kuoi.asui.uidaho.edu/~kamikaze/Hephaestus/>, I've used a very
simple policy to determine if something should be defined in Java or in
the Minimal scripting language:
1) Can I implement this feature in Minimal? If not, I have to do it in
Java.
2) Do I need it when I try to develop an adventure? In other words, I
try to write an adventure, and as I try to do things, I realize "hey, I
need a function to ..."
3) Wherever possible, provide a usable default value or behavior, and
let the script override that default.
It's a balancing act, but ultimately I'd like all behavioral
components to be scripted. Since I don't let any of my classes modify
the internals of any other class, I can migrate implementation out of
Java into Minimal whenever I want to.
Right now, for instance, combat is hardcoded in Java. However, it
would be quite easy to add a function which sets a "callback" in the
Minimal script to run combat. Then at the start of my combat code, I'd
have:
if( combatFunc_ != null )
return invoke(combatFunc_, null /*no 'targetid$'*/);
This way, if you haven't done a 'set_combat(myCombatFunc())', you get
the stock combat system.
> 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 define all spells in the scripting language - the spells available
and the specifics of their behaviors vary so much between adventures
that I can't reasonably define a stock library of spells. All the Java
code contains is a hash of spell names (like "Fire Arrow (2 MP)") to
Minimal function calls (like 'attackSpell(2,0.25,"an arrow of fire")').
There are a couple of callbacks which are mainly used for spells, but
most spells can be implemented with the same tools you'd want for other
tasks, too.
> - 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) ?
Well, I use a rather cheesy technique. I set parameters into global
variables, like 'actorid$' and 'targetid$'. O, the humanity. However,
the whole point of Minimal is that it's incredibly simple and, well,
minimalistic. Therefore my primary design question was, "Could a BASIC
programmer understand it?"
Do not copy this cheesy technique unless you have the same design
goal.
> 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).
There are two advantages to scripting:
1) To make it easier for non-professional programmers to develop
adventures.
2) To make it easier for to write multiple adventures with the same
engine.
Angband has both - there are a lot of people who'd like to modify
Angband, but can't program in C. There are also many, MANY variants,
and the variants are getting more and more unlike vanilla Angband. If
they add enough scripting, they'll be able to fold most variants back
into the vanilla engine.
If you don't need either of the advantages, and you like coding in
your implementation language, you probably don't need scripting. For
instance, my Umbra <http://kuoi.asui.uidaho.edu/~kamikaze/Umbra/>
pseudo-3D roguelike is written in Python and has only a single
adventure. There's no reason for me to script that, even though it
would be amazingly easy, being Python.
--
<a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"No one is safe. We will print no letters to the editor. We will give no
space to opposing points of view. They are wrong. The Underground Grammarian
is at war and will give the enemy nothing but battle." -TUG, v1n1
Anubis Raskolnikov
> > H-World is off the ground and the engine is complete. But as of yet this is
> > far future.
> [...]
> Are you trying to
> make closed source engine with scripts which will allow to create games?
> If yes, you have to consider some facts. There are only few game editors
> which are acceptable by users (for example HoM&M and Starcraft) and
> plenty of unused (Arcanum, Runesword). The good one are *simple*, or even
> *very simple*. They haven't options like modify combat formula... You can
> say that there is one good game edit engine with scripts and is called
> Angband. Yes, you are right but it is *open source* which is very
> important in this case and have huge comments in source code (
Well,`Archibald, you're not exactly right ;-).
Imagine if ADoM, still closed-source, would have a complicated open script
-- You think that nobody would write a new game with new scripts? I think
someone would (At least I would :-)
regards,
--
Kornel "Anubis" Kisielewicz
GenRogue Rogue-like project (http://www.kki.net.pl/~anubis)
Bru, Pierre
I might be burnt at the stake for this idea but, well...
why not have the "main" and all the interesting part written in
<insert here your favorite scripting language name> and the dark-side
part (all that would run too slow, is too OS dependant, etc.) in
"regular" language ?
Pierre.
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?
>
> 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).
>
>
Archibald
Well, Anubis, you're not exactly right too ;-).
First if you have free time download RPG-editor (from www.runesword.com
IIRC). Then look at their script system, it's very universal, but... do
you think that normal person would like to use it? It's too complicated.
It's much simplier for me to write a game from beginning rather than
start learning this pseudo language. Of course everything depending of
complexity of script and editor. But in this case there was sugestion to
allow changing damage formula. This is too complicated for normal people.
About ADOM editor. I don't think that you would use it because for you
will be easier to write your own game... OK, maybe some fans would write
in this script, but I'm sure that there will be much easier for them to
edit normal C source code if available rather than some strange,
complicated, poorly documented and nonstandard script.
IMO, a reasonable editor will have only simple, easy to understand
options and maybe some simple and very good documented script as an
option for expert users.
--
Archibald
John Bwah
> > '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.
Er. I think part of the problem here is that you're not seperating the
words "concept" and "implementation". The way I originally interpreted what
you said, I was quite with Hansjorg (sorry for missing diacriticals - my
keyboard doesn't have them): the *concept* of a square hasn't changed pretty
much since the 1970s, but its high level representation - the data structure
that represents a square - has many times.
And if there's argument over whether that data structure is high level, then
we're going to get into what constitutes level. I'm one of those who feels
that the bulk of The Real Work (tm) in generating an application is
generating its data structures (yet another one of the reasons why templates
are the most powerful thing ever).
To that end, I feel it appropriate to agree with both of you, by fusing each
of what you said into a horrible mishmash: the concepts underpinning the
game - monsters roaming about on a cartesian grid, items and treasure,
stairs, discrete levels, et cetera - change rarely (good examples of base
concepts changing include uniques, quests, the town level, shops, pets, a
magic system, the various magic systems, classes, races, stats other than
strength, and so on...)
However, though the fundamental data structures which describe these
concepts change every so often, the high-level constructs which operate on
the data are the most likely to change - new smell code, a better group
tactic AI, new inventory stuff, persistent objects with thieves, et cetera.
> > 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.
That's not exactly fair. Angband's history *very* *rarely* has year long
jumps. A year into a project is almost guaranteed to be significant. You
can't guage a closed source foundling project's progress by that of an open
source, group motivated project that's got 18 releases.
> > 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.
Adding scripting is not a trivial thing, and the presence of scripting will
significantly change the approach of the original authoring work of the
game. It's not as easy to hammer things like that into an application as it
is to get it up and running as one of the base pieces of your app.
OTOH, whereas Lua is designed to be not-so-difficult to add, there is the
significant added amount of work. What this really comes down to is whether
Hansjorg feels it's worth the effort for the added return. Hansjorg, it'll
make a lot of your later stuff easier to do, but at significant added
expense getting your first run up and going.
> > > 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.
That seems rather akin to saying "yeah, well, we don't know what the best
way to maeka seatbelt is, so let's just try it, and over time, we'll find
better ones". The amount of expended engineering effort is significantly
less if done once and well than if done multiple times and poorly; moreover,
the benefits from having it right early on are significant. Morever still,
there isn't as much to recode when you switch to a new system.
> > 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...
Er. "You are wrong, in that getting the right interface is not easy", yet
"It is impossible to see the best way of doing something on the first go" ?
Traditionally, interfaces are one of if not the most difficult of tasks to
get elegantly. Am I missing something, here?
> > 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.
I don't mean to be rude, but that doesn't seem to address the question.
As far as the original question goes: "easy adoption" is a relative thing.
Whereas yes, it's rather easier to get showhorned into your app than Python,
it still isn't trivial. Hammering a language into your app isn't a
straightforward thing, yet.
> > 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.
Planning doesn't assume *anything* about the ability to forsee the future.
It simply allows you to be ready for the issues that you're already
cognizant of.
Again, I'm sort of on the edge of being a bastard when I say this, but to be
quite honest, this is a viewpoint which I find infuriating. The suggestion
that because you're not a soothsayer you sohuldn't be planning your large
application is, in my opinion, the largest problem with OSS - that being
specifically that nothing ever really gets planned properly, and you get one
giant hack as an operating system.
Is, it sohuld be noted, is A Bad Thing (tm) for reasons that length makes it
prohibitive to explain. Whereas I recognize this as an opinion, I also
recognize it as the opinion of every software architect, graduate student,
or CS professor I know. It is the opinion expressed at every university
I've attended or visited, within every book I've read (including K&R,
Stroustrup, Knuth, and a bunch of other seminal works), and within every
genuinely professional project I've ever seen the innards of.
Sure, I could be being a blind evangelist. There were people who were
certain the world was flat, because their peers said so. However, I'm also
speaking from personal experience; I wrote a 70,000 LOC app (LOC isn't a
great metric, but it's obvious) in half the time and with half the bugs as a
previous 20,000 LOC app, and I firmly believe that the major difference
(other than experience) was planning.
In my opinion, there is *nothing* worse than a large, unplanned app.
Redundancy, inefficiency, multiple translation, inobvious interface, and
lack of clear descendancy are all canonical problems with grown apps. The
experience of the industry stands as your giant neon "Fair Warning" sign.
John Bwah
> 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...
Er. They weren't games any more than DooM was a game. They shipped with
standard scenarios, and allowed the player to replace those scenarios. I
still think of DooM as a game, though - just one implemented as a game with
a very satisfyingly modular engine.
I bring this up because I feel it's an important point of view, what with
all of the discussion of scripting in Roguelikes. If things are taken to
their extreme, this is going to be a common argument about the roguelikes
themselves - is ScriptAngband a game, or an engine that ships with a default
module?
The reasons this becomes important begin to become obvious when someone
begins to consider multiple concurrent modules. The ability to run
"patches" to the Angband environment (this would require some serious
anti-collision engineering) would obviate the need for god only knows how
many minor branches.
I mean, I'd love to try some of the dozens of angband variants out there,
but it's not worth spending 2 years to get to that point with a high elf
wizard only to discover that no, in fact, that rules switch was a bad idea
after all...
John Bwah
wouldn't
> follow this advise at the moment, which usually implies unkowledge or
> stupidity. This hurts. And makes me look stupid, which I dislike pretty
> much.
Not really. If someone gives you advice to a question you didn't ask, it
reflects on them, not you.
Don't be offended when someone tries to offer help and misses the mark.
Thank them, and be more specific. If they can't get the point, then thank
them for their time, and skip past their posts. It's a public forum.
People of varying skill, insightfulness, and behavioral tendencies will show
up.
> It was a quick and dirty solution. But it hurts if you think I could not
do better.
How was he to know? Many homebrew roguelikes *do* make such egregious
mistakes - look at the example developer's discussion at ARNS if you need an
example, as it's purporting to be a good idea of how to do things. (Take a
look at the notion of how to store items and monsters)
http://arns.freeservers.com/aorpart3.html
Frankly, this is why the good lord gave us code comments. If you know
something's a hack, and you're going to make the source public, put a note
in that says it's a hack. Otherwise, he's doing *exactly* *the* *right*
*thing* - trying to warn you that something could be handled much better.
But, look: be cool. If you're being offended, just stop reading his posts.
People tend to forget how abrasive it seems when they say "no, this is
right, you are wrong", even if they feel that they're correct.
Anubis Raskolnikov
> In article <a7m0kb$2e5$1...@news.tpi.pl>, rasko...@go2.pl says...
> > > > 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.
> > > [...]
> >
> > > Are you trying to
> > > make closed source engine with scripts which will allow to create games?
> > > If yes, you have to consider some facts. There are only few game editors
> > > which are acceptable by users (for example HoM&M and Starcraft) and
> > > plenty of unused (Arcanum, Runesword). The good one are *simple*, or
even
> > > *very simple*. They haven't options like modify combat formula... You
can
> > > say that there is one good game edit engine with scripts and is called
> > > Angband. Yes, you are right but it is *open source* which is very
> > > important in this case and have huge comments in source code (
> >
> > Well,`Archibald, you're not exactly right ;-).
> > Imagine if ADoM, still closed-source, would have a complicated open script
> > -- You think that nobody would write a new game with new scripts? I think
> > someone would (At least I would :-)
> Well, Anubis, you're not exactly right too ;-).
I insist I am ;-).
> First if you have free time download RPG-editor (from www.runesword.com
> IIRC). Then look at their script system, it's very universal, but... do
> you think that normal person would like to use it? It's too complicated.
Firstly -- it is commercial. Secondly -- it's not free, so you can't
publish your world to people who haven't bought it.
Ok, how many Runesword players are there? Comparable to ADoM? How many
players that have "decent programming skills" play RuneSword? How can they
publish their own adventures? Answer all those questions, and it will be
apparent, that comparing a succesfull FREE roguelike game, that allows you
to publish world scripts would be far more popular.
> It's much simplier for me to write a game from beginning rather than
> start learning this pseudo language. Of course everything depending of
> complexity of script and editor. But in this case there was sugestion to
> allow changing damage formula. This is too complicated for normal people.
And Angband source isn't?
> About ADOM editor. I don't think that you would use it because for you
> will be easier to write your own game... OK, maybe some fans would write
> in this script, but I'm sure that there will be much easier for them to
> edit normal C source code if available rather than some strange,
> complicated, poorly documented and nonstandard script.
Base it on C. :-). Anyway, a roguelike script needs only a limited area of
script coverage. If the language would be simple and well-documented, it
wouldn't be a problem.
Smile,
--
Kornel "Anubis" Kisielewicz
GenRogue Developmnet ( http://www.kki.net.pl/~anubis )
cropt
> players that have "decent programming skills" play RuneSword? How can they
> publish their own adventures? Answer all those questions, and it will be
> apparent, that comparing a succesfull FREE roguelike game, that allows you
> to publish world scripts would be far more popular.
Civilization II had some options that were user definable. Not exactly
scripting, but there were a large number of fan contributed worlds.
Anubis Raskolnikov
But still... how many people have bought Runesword, and how many have
bought Civilization? There you have it -- in a big community of game
OWNERS there will be people who will write scripts ;-)
regards,
Anubis
John Bwah
> > scripting, but there were a large number of fan contributed worlds.
>
> But still... how many people have bought Runesword, and how many have
> bought Civilization? There you have it -- in a big community of game
> OWNERS there will be people who will write scripts ;-)
I think you're missing the point. End-user configurability isn't going to
drive any players *away* from a game - the only people who'll even touch it
are those interested. And games like ZZT and MegaZeux, engines like AGT and
GAGS, and all of those make-your-own projects on sourceforge are evidence
that yes, even shareware games can benefit from having end-user scriptable
behavior.
Anubis Raskolnikov
> > But still... how many people have bought Runesword, and how many have
> > bought Civilization? There you have it -- in a big community of game
> > OWNERS there will be people who will write scripts ;-)
> I think you're missing the point. End-user configurability isn't going to
> drive any players *away* from a game - the only people who'll even touch it
> are those interested. And games like ZZT and MegaZeux, engines like AGT and
> GAGS, and all of those make-your-own projects on sourceforge are evidence
> that yes, even shareware games can benefit from having end-user scriptable
> behavior.
Cut. I'm not missing the point. The point is that the point was Archibalds
first post, I cite:
"Do you really think that anyone will create variant using your script
engine? I'm afraid that your hope is too optimistic. Are you trying to
make closed source engine with scripts which will allow to create games?
If yes, you have to consider some facts. There are only few game editors
which are acceptable by users (for example HoM&M and Starcraft) and
plenty of unused (Arcanum, Runesword). The good one are *simple*, or even
*very simple*. They haven't options like modify combat formula... You can
say that there is one good game edit engine with scripts and is called
Angband. Yes, you are right but it is *open source* which is very
important in this case and have huge comments in source code (almost
*every* line of code in Angband is commented...). Of course there is
scripting, but this is only to help variant creators, most modifications
are done directly in code. Do you really want to make another Angband?
Are you sure?"
I was only trying to prove that H-World WOULD BENEFIT from a script
despite it will be closed source. Bascialy it's the point you now made.
(If I'm wrong, give credit to my lacks in English ;-)
Peter Seebach
Anubis Raskolnikov <rasko...@go2.pl> wrote:
>If yes, you have to consider some facts. There are only few game editors
>which are acceptable by users (for example HoM&M and Starcraft) and
>plenty of unused (Arcanum, Runesword).
There's a fairly active mod community for Arcanum; they introduced a new
editor in one of their patches, and now there's mods.
Neo_1061
Malthaner <hansjoerg...@danet.de> jacked into the Matrix and
the following appeared in rec.games.roguelike.angband:
>> | Pain clots and unformed lice pat this train.
WTF?
--
Still waters run deep.
Neo_1061
Malthaner <hansjoerg...@danet.de> jacked into the Matrix and
the following appeared in rec.games.roguelike.angband:
>If you advise repeteadly to follow a rule, which I already follow, this
>implies I'd not follow the rule. If it's a basic rule, this implies that I
>don't even know the most basic rules. That hurts.
Hmm. Anyone noticing a pattern here? 99% of rgra flamewars seem to
stem from someone-or-other being a condescending arse.
Eytan Zweig
"Neo_1061" <inv...@erehwon.invalid> wrote in message
news:3ca55df6....@news.primus.ca...
And by someone else feeling that condescending arses are worth replying to.
Eytan
Screwtape
>On Wed, 20 Mar 2002 19:34:05 +0100, =?iso-8859-1?Q?Hansj=F6rg?=
>Malthaner <hansjoerg...@danet.de> jacked into the Matrix and
>the following appeared in rec.games.roguelike.angband:
>
>>> | Pain clots and unformed lice pat this train.
>
>WTF?
A common sight on trains in Sydney Australia, this sign is usually an
official City Rail sign, edited by some anonymous patron. Unedited
signs read "Plain clothes and uniformed police patrol this train."
--
___________ ____________________________
| Screwtape | Reply-To: munged on Usenet |________ ______ ____ __ _ _ _
|
| "At night, rave near the guard's compartment naked with a blue light."
|
Philip Swartzleonard
>>> 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.
Hansjörg Malthaner || Wed 20 Mar 2002 06:57:39a:
>> 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 ...
Astromarine || Wed 20 Mar 2002 08:17:55a:
> As I said above, I think an engine has to serve as a wrapper, and
> implement the most basic world generation and control functions
My original idea for my project, after learning just a little bit about
pyhton, was make a core executable that knew how to manage a cubic grid,
draw 3d sprites, do los code, and provide a basic gui api. Everything
else was to be written in python. Dungeon generation, the idea of what a
dungeon is, monsters, ai, movement, input/output, gui specification, you
name it.
But now... I started writing in python, and now i see no reason to
create a core executable in a hard language anymore. There are besically
three levels of code: a core engine that controlls maps and los and
things like that; and built upon that a framework or template built on
top of that, a standard game library that you start work with, but will
probably have to change quite a bit to fit your game (ala tads); and on
top of that the game code itself. The lines are blurry, however.
--
Philip Sw "Starweaver" [rasx] :: www.rubydragon.com
Philip Swartzleonard
>> 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...
John Bwah || Wed 27 Mar 2002 01:41:32p:
> Er. They weren't games any more than DooM was a game. They shipped
> with standard scenarios, and allowed the player to replace those
> scenarios. I still think of DooM as a game, though - just one
> implemented as a game with a very satisfyingly modular engine.
There's a key difference, at least in outward perception, however. ZZT
and MZX were built for user customizibility: not only do they come with
an editor there is open support for loading any number of available
worlds. Doom, on the other hand, was never designed to be changed by
anyone except the original creators. All of the extensability came from
a community of hackers and programmers that took apart the pieces and
put them together differently, and this is where all the editors came
from. There isn't even any open or even hidden support for loading
nonstandard levels into the game, the only way to do it is to trick the
thing into thinking it's loading one of it's own... usually by renaming
the level you want 'e1m1' :).
Duke nukem was the first doomish game to act as you say (allthough the
loading support was ugly and not much better than early doom hacks), and
since then, most of them have at least had some support for user addons
that they knew people would make (quake's console allowed you to load
any map by filename, for exapmle.)
Philip Swartzleonard
OT, but anyway: You're a little behind the times... AGT and GAGS are
pretty dead as far as i can tell. Try TADS, Inform, Hugo, Quest,
Glulx/Inform... =)
John Bwah
> and MZX were built for user customizibility: not only do they come with
> an editor there is open support for loading any number of available
> worlds.
This is true.
> Doom, on the other hand, was never designed to be changed by
> anyone except the original creators.
I openly disagree with this.
There are a number of issues to be coivered. However, you need to remember
that iD already had a history of opening their file formats and allowing
users to create their own levels (Wolf3D, certain of the games licensed to
Epic, etc.)
Admittedly, Deu and Matt Fell/Brendon Wyber's work predates iD's releasing
of file format specs in the case of DooM, but that's not to suggest that iD
wanted to keep control of the format. Indeed, that the files were seperate
and encapsulated is not a trivial thing; that takes effort, and it shows
clear evidence that iD wanted for the game to be extensible without having
to repackage copyrighted (and bulky!) material. There is every indication
that this game was designed specifically to be modified.
> Duke nukem was the first doomish game to act as you say (allthough the
> loading support was ugly and not much better than early doom hacks),
I would contend that the first shooter to do this was Wolfenstein, but
there's good argument that many older shareware titles with limited
distribution beat them to the punch.
John Bwah
> pretty dead as far as i can tell. Try TADS, Inform, Hugo, Quest,
> Glulx/Inform... =)
Yeah, I am. It's kinda hard to even get Malmberg's source to compile in
modern environments, if your source predates the graphics/sound update.
I haven't screwed with IF engines in some time. I'm kind of tired of the IF
engines which adhere to the old Z-Machine paradigm; if I'm gonna do
something like that, I might as well write to the actual Z-Machine. Why?
Because then I could play my games on a gameboy
(http://www.work.de/nocash/infgmb.htm) or gameboy advance
(http://www.obsession.se/frotz/).
I have my old, legitimately bought AGT source (from the days before it was
being given away). I also still have my hardcopy paper permission to do
whatever I like with it. And I'm in a roguelike development group, talking
about odd new features and my odd platform targetting. Hee, hee, hee...
Eytan Zweig
> > OT, but anyway: You're a little behind the times... AGT and GAGS are
> > pretty dead as far as i can tell. Try TADS, Inform, Hugo, Quest,
> > Glulx/Inform... =)
>
> Yeah, I am. It's kinda hard to even get Malmberg's source to compile in
> modern environments, if your source predates the graphics/sound update.
>
> I haven't screwed with IF engines in some time. I'm kind of tired of the IF
> engines which adhere to the old Z-Machine paradigm; if I'm gonna do
> something like that, I might as well write to the actual Z-Machine. Why?
> Because then I could play my games on a gameboy
> (http://www.work.de/nocash/infgmb.htm) or gameboy advance
> (http://www.obsession.se/frotz/).
>
Inform writes to the actual z-machine.
Eytan
Archibald
[...]
> > First if you have free time download RPG-editor (from www.runesword.com
> > IIRC). Then look at their script system, it's very universal, but... do
> > you think that normal person would like to use it? It's too complicated.
>
> Firstly -- it is commercial. Secondly -- it's not free, so you can't
> publish your world to people who haven't bought it.
So it changes... A time ago it was freeware, but there weren't many
worlds (about two scenarios only IIRC). It was too complicated for
players.
> Ok, how many Runesword players are there? Comparable to ADoM? How many
> players that have "decent programming skills" play RuneSword? How can they
> publish their own adventures? Answer all those questions, and it will be
> apparent, that comparing a succesfull FREE roguelike game, that allows you
> to publish world scripts would be far more popular.
>
> > It's much simplier for me to write a game from beginning rather than
> > start learning this pseudo language. Of course everything depending of
> > complexity of script and editor. But in this case there was sugestion to
> > allow changing damage formula. This is too complicated for normal people.
>
> And Angband source isn't?
Well, yes :). But it's much easier for programmers to write in C than in
an strange script.
> > About ADOM editor. I don't think that you would use it because for you
> > will be easier to write your own game... OK, maybe some fans would write
> > in this script, but I'm sure that there will be much easier for them to
> > edit normal C source code if available rather than some strange,
> > complicated, poorly documented and nonstandard script.
>
> Base it on C. :-). Anyway, a roguelike script needs only a limited area of
> script coverage. If the language would be simple and well-documented, it
> wouldn't be a problem.
You hit the idea *If the language would be simple and well-documented, it
wouldn't be a problem*. I just said that complicated script is bad, and
only simple script is acceptable. So, it seems that we have identical
opinion? ;)))
--
Archibald
John Bwah
> worlds (about two scenarios only IIRC). It was too complicated for
> players.
(snip)
> > And Angband source isn't?
>
> Well, yes :). But it's much easier for programmers to write in C than in
> an strange script.
Are you arguing the players' side or the programmers' side? If it's C, the
players are gonna suck at it, and if it's script, the programmers are gonna
whine. I say script it.
> > Base it on C. :-). Anyway, a roguelike script needs only a limited area
of
> > script coverage. If the language would be simple and well-documented, it
> > wouldn't be a problem.
>
> You hit the idea *If the language would be simple and well-documented, it
> wouldn't be a problem*. I just said that complicated script is bad, and
> only simple script is acceptable. So, it seems that we have identical
> opinion? ;)))
Well, except that your arguments against script were based on complexity. I
think he was leading your argument back to his premise - and quite
skillfully, at that.
David Damerell
>worlds. Doom, on the other hand, was never designed to be changed by
>anyone except the original creators.
>nonstandard levels into the game,
Nonsense. What do you think 'doom -file <thing>.wad' does?
--
David Damerell <dame...@chiark.greenend.org.uk> flcl?
Archibald
fatz...@earthlink.net says...
> > So it changes... A time ago it was freeware, but there weren't many
> > worlds (about two scenarios only IIRC). It was too complicated for
> > players.
>
> (snip)
>
> > > And Angband source isn't?
> >
> > Well, yes :). But it's much easier for programmers to write in C than in
> > an strange script.
>
> Are you arguing the players' side or the programmers' side? If it's C, the
> players are gonna suck at it, and if it's script, the programmers are gonna
> whine. I say script it.
I just wanted to say that programmers prefer source codes rather than
complicated script, players don't like both source and complicated
script. So there is no point to make complicated script, nobody like it.
The answer in this case is to make open source game or easy script
system.
> > > Base it on C. :-). Anyway, a roguelike script needs only a limited area
> of
> > > script coverage. If the language would be simple and well-documented, it
> > > wouldn't be a problem.
> >
> > You hit the idea *If the language would be simple and well-documented, it
> > wouldn't be a problem*. I just said that complicated script is bad, and
> > only simple script is acceptable. So, it seems that we have identical
> > opinion? ;)))
>
> Well, except that your arguments against script were based on complexity. I
> think he was leading your argument back to his premise - and quite
> skillfully, at that.
I don't think so :)
--
Archibald
Neo_1061
jacked into the Matrix and the following appeared in
rec.games.roguelike.angband:
>m_init(): spawning followupTo('Neo_1061')...done.
>>On Wed, 20 Mar 2002 19:34:05 +0100, =?iso-8859-1?Q?Hansj=F6rg?=
>>Malthaner <hansjoerg...@danet.de> jacked into the Matrix and
>>the following appeared in rec.games.roguelike.angband:
>>
>>>> | Pain clots and unformed lice pat this train.
>>
>>WTF?
>
>A common sight on trains in Sydney Australia, this sign is usually an
>official City Rail sign, edited by some anonymous patron. Unedited
>signs read "Plain clothes and uniformed police patrol this train."
Ah...
We have something similar here. Some of the local buses have signs
reading "Show your pass or POP Transfer on request" -- POP meaning
Proof of Purchase. I've seen these signs modified to say "Show your
ass" ...
Francis Sandow
I'm from England, where the signs on The London Underground used to read:
"Obstructing the doors causes delays and can be dangerous"
Except for this one that I once saw which read:
"Obstruct the doors cause delays and be dangerous"
Davide Inglima - limaCAT
It's the same all the world around then ;)
In Italy on trains we read instead of
"E' pericoloso sporgersi in galleria" (It's dangerous to lean out of the
windows in the galleries) "pericolo orge in galleria" (Danger: orgies in
gallery) :)
--
Davide Inglima, limaCAT
sorry for the off topic :)
Otto Martin
>It's the same all the world around then ;)
>In Italy on trains we read instead of
I suppose I'll have to add the most often seen local one;
The use of the lavatory is restricted to the train's cat.
Otto Martin - käymälää saa käyttää vain junan k(ulkie)issa
--
this unicorn will self destruct in 30
seconds. for official ninja use only.
http://www.megatokyo.com/index.php?strip_id=215
Jacob Kaplan-Moss
Otto Martin <oma...@students.cc.tut.fi> wrote:
> In rec.games.roguelike.angband Davide Inglima - limaCAT
> <hades...@libero.it> wrote:
> >It's the same all the world around then ;)
> >In Italy on trains we read instead of
>
> I suppose I'll have to add the most often seen local one;
> The use of the lavatory is restricted to the train's cat.
Ooh... can I play too?
Down the street at the Self Storage facility someone stole the first
"s", so now I tell my freinds to find me a block from the "Elf Storage"
place...
Jacob
Philip Swartzleonard
Oh god (*can't stop laughing*). That' ones going in my file of 'bad
puns/injokes/references that must be used in a game or story someday' file
=). And how about 'Elf help' books.
--
Philip Sw "Starweaver" [rasx] :: www.rubydragon.com
-Who has seen about the first half of crest of the stars and can see it
now: class selection: s - Space Elf =)
David J. Grabiner
> Down the street at the Self Storage facility someone stole the first
> "s", so now I tell my freinds to find me a block from the "Elf Storage"
> place...
I was in McAllen, Texas just after Hurricane Allan. It is far enough
inland that there wasn't serious damage, but lots of signs had lost a
letter. There were two "Elf Service" stations in town.
George W. Harris
J. Grabiner) wrote:
And, of course, there is the chain of Shell gas stations.
--
Real men don't need macho posturing to bolster their egos.
George W. Harris For actual email address, replace each 'u' with an 'i'.
Jack Wise
My personal favorite is the "Essex House" Hotel that kept loosing
the first two letters of its sign.
--
Jack Wise
Peter Seebach
Philip Swartzleonard <st...@pacbell.net> wrote:
>Oh god (*can't stop laughing*). That' ones going in my file of 'bad
>puns/injokes/references that must be used in a game or story someday' file
>=). And how about 'Elf help' books.
There were signs in Copenhagen saying "Billetautomat", which appeared to refer
to parking meters. Many of them were turned into
Bille[*()]tomat
with an ant and a tomato on the little sticker.
Otto Martin
>Jacob Kaplan-Moss || Mon 15 Apr 2002 04:21:01p:
>>"s", so now I tell my freinds to find me a block from the "Elf Storage"
>>place...
>Oh god (*can't stop laughing*). That' ones going in my file of 'bad
>puns/injokes/references that must be used in a game or story someday' file
>=). And how about 'Elf help' books.
>--
>Philip Sw "Starweaver" [rasx] :: www.rubydragon.com
>-Who has seen about the first half of crest of the stars and can see it
>now: class selection: s - Space Elf =)
Ok, just to get the thing going...
N:74:75:75:65
D:You have light blue eyes,
N:74:75:90:65
D:You have light green eyes,
N:74:75:99:65
D:You have light purple eyes,
N:74:75:100:75
D:You have bright red eyes,
N:75:76:80:55
D:straight
N:75:76:90:55
D:curly
N:75:76:100:60
D:braided
N:76:0:80:55
D:light blue hair, and a fair complexion.
N:76:0:95:55
D:blue hair, and a fair complexion.
N:76:0:100:55
D:dark blue hair, and a fair complexion.
Hope this helps. (Feel free to change the ratios if you recall them
differently. Could also add one thing, but won't (yet), since you
haven't seen the whole series yet. :-)
Otto Martin - local club is currently showing seikai no senki; yay!
Andrew Fenton
Jack Wise wrote:
There's a suburb of Seattle called Bothell; the sign as you enter town reads
"Bothell- for a day or for a lifetime." Inevitably, one day somebody removed
the BOT-...
Andrew
Jonathan Ellis
Andrew Fenton wrote in message <3CBC6B14...@yahoo.com>...
>There's a suburb of Seattle called Bothell; the sign as you enter town
reads
>"Bothell- for a day or for a lifetime." Inevitably, one day somebody
removed
>the BOT-...
Oh, yes. But did anybody think of leaving the "bot-" and adding a
strategically placed "R"? ;-)
Jonathan.