Re: [Adonthell-general] Items

[Kai Sterker]

On Tue, 8 Oct 2002 11:23:36 +0200 Benjamin Walther-Franks wrote:

> Good idea with the names, but I'd rather keep them as two entries. We
> have three entries on songs and even four on spells, so it doesn't
> harm to keep two different forging abilities. Think of the diferent
> abilkities as a focus on certain disciplines: Similiar as earth magic
> will heal and fire magic will destroy, forge weapons can be used for
> offensive ends and forge armour to defensive. 

Exactly. One is more offensive, the other defensive, so it makes sense
to distinguish between them.


> > What I do not understand is why we need
> > the availability (that long table). I propose that we can just have
> > the faction alignment handle all that (I think faction alignment can
> > be quite a powerful tool!). And in some cases the characters can
> > just tell the character that she can not learn something

I imagine that it will be quite like that. As Ben says, players wouldn't
see the table, but for developers it is important to know who will be
able to learn what and to what degree.

I guess there are at least two tests a character has to pass to learn
something. He must be able to learn it (no dwarf will be able to learn
songs of the birds). Second, his faction alignment must match that of
his teacher. For common abilities, latter wouldn't be a real problem, as
there'll be all kinds of teachers available. For less common stuff,
alignment would play a bigger role.

Btw, as I read the table, the numbers show both the availablity of
teachers and the maximum rank a certain race can gain in an ability,
right?


> We could even go as far as to say that once a
> player has one rank in an ability, he can freely buy ranks with
> advancement points.

I like the idea that special events make the player advance in an
attribute. I'm not so sure about freely buying ranks. First of all, it's
an exception from the rules, and exceptions just introduce more
complexity. Second, we have this "availabilty of abilities" table now.
It would be sorta pointless, when people could gain ranks just so. By
using the teachers we could also prevent players from advancing too fast
in an ability. They can't probably just buy two or three ranks. At least
they would need to do the teacher a favour in between, gather more money
first, or even seek a more capable teacher.

 
> As to the availability table: Even though the table seems quite
> complex, the player will never see anything of this, in fact, he will
> see even less than before, since he doesn't see which abilities are
> available to him, but discovers them as he goes along. It's more for
> implementational uses like.

That's really good. Although people could still look at the rules and
see it. But the majority wouldn't, I guess.
 

> The more I think about it the better it sounds. Yeah, faction
> alignment is definately the way to go!

If you can find a way to handle this with faction alignment, I'm all for
it. But I think then you would have to take all the different factions
we'll have into account, see for what race/gender they are, what they'll
teach and so on. Might be easier to start with the table and design
factions accordingly. In that case, faction alignment based learning
will be a result of the rules. Oh well, I'll leave that totally to you
guys ...


> See above. I just think it's important that these ideas fit into a
> general rule system, and are not just standalone rules for v0.4

True, although the rules will be specific to the Adonthell world in
general. And factions that make it into v0.4 will most likely appear in
v1.0 as well.


> > All the rules can be roughly devided into 3 categories:

Possibly true. However, I'm not sure if we need such a division. I mean,
it's got no practical use, has it?


> <skills>
> 
> I like the part you added on advancing in skills. As to the
> implementation part, your suggestions sound sensible, but I'm the
> wrong person to talk to...

Yeah, the advancing part sounds really great :). That'll prevent people
from advancing too fast without introducing any artificial restrictions.

Concerning the implementation:
I imagine the rules would comes as a number of python modules. Those
could be imported and directly used from a dialogue. No changes to the
dialogue system would be required.

In general, we'll have to define an interface between those rule modules
and the engine. That way, the engine could work with different sets of
rules, as long as they implement that interface.

As for your chest example:
The dialogue engine isn't really suitable for handling this. The problem
is that each chest would have different properties (a special key,
complexity of lock or trap). So you would need a differnt dialogue for
each chest, which isn't worth the trouble.

However, as the dialogue system is divided into backend and frontend, we
could have a 'chest module' that creates the dialogue with the
properties of a chest on the fly. Then we could use the dialogue GUI to
display the options and get the player's choices. But of course we could
also write an extra GUI that fits better. I.e has nice icons for the
available actions (find trap, disarm, pick, unlock, open, cancel).


> <items>
> 
> All sounds very sensible, and doesn't really stand in conflict with
> anything I wrote. So if you and the others are okay with it I'll
> incorporate all of that (including your writing on skills) into the
> existing rules. 

There is only one thing I would like to change somewhat: making stuff.
Be it runes, enhancements, inventions. I think all of that should work
in more or less the same fashion. Whenever the player comes across
something new to make, it'll be added to the according 'book'.

To actually make something, the player would simply pop up the book and
select whatever entry he wants to make. This is exactly the same thing
as casting a spell, except that a spell does not require ingredients,
only power. As a consequence, a player could even assign a recipe to a
'quick-button', just like a spell, move or feat.

Anyway, when selecting to make something, the engine would check whether
the player has the proper ingredients and tools. In the case he has, the
invention or potion would be created, a rune inscribed, a weapon
enhanced. Otherwise a message could appear, along the line "I need more
sulphur for this."


I think that would be a more generic solution than having to talk to an
anvil, which would only cover a few special cases. Above would handle
everything from spells and songs to inventions and alchemy.

The actual entries would be similar to items. I.e. a list of icons that
display some descriptive text, requirements and the like when examined
closer.

What do you think?


> I'll also start a new document that has all the items
> and talents ideas we have come up with so far. This can then be added
> to the doc-cvs and anyone can add to it anytime.

Good idea.