Crossfire Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CF: Alchemy and costs of generated items



On Mon, 15 Jun 1998, "Mark Wedel" <mark@stealth.eng.pyramid.com> wrote:
[...]
> I am also not sure how easy it would be to do, but giving some bonus
> for actually having a copy of the recipe.  A lot of the game is
> already player knowledge and not character knowledge.  For alchemy,
> once the player finds out the recipe, and and all of his characters
> could use it.

Good idea.  The alchemy code could be changed in such a way that the
probability of succeeding is divided by two (or even more) if the
player is not carrying the recipe (except for basic recipes, maybe).
This means that it would be (very) hard to create useful stuff without
having the formula, and this would mean that a formula known by the
player will be less useful if his character does not have it.  Of
course, the game should also encourage people to carry their recipes
all the time.

Here is how could be done:

- All formulas would be on scrolls or sheets of paper, never in books
  (except for books containing one page - see below).  This would
  ensure that it is easy for a character to carry at least 20 or 30
  formulas without adding more than 10 in weight.

- In the good old crossfire tradition of overloading some fields of
  the object structure with unrelated values, we could use sp, hp or
  something else to store the "index" of the recipe.  This introduces
  a dependency between the scrolls stored in the maps and lib/formulae,
  but this should not be a big problem since this is already done for
  spellbooks.

- When someone casts the alchemy spell over a cauldron, the code would
  try to find the corresponding formula as it does now.  In addition,
  it would check if the character is carrying a scroll with the
  corresponding index number.  If not, then the chance of succeeding
  would be greatly reduced (except for basic recipes).  We could even
  make it so that alchemy never fails if the player is carrying the
  corresponding recipe.

- Maybe add a new container: a book that can only hold recipes.  This
  would help the player who has to carry many of them.  It makes sense
  to have a wizard carrying his alchemy book around, but it would be
  impractical to carry 50 scrolls, for example.  These containers
  could also be used for quest formulas: the scroll could be stored in
  a no-pick book (the player would have to tear the page off the
  book).

The problem of "character knowledge vs. player knowledge" is also
present in other parts of the game.  Spells and skills are "character
knowledge", but most other things found in books are "player
knowledge" only: alchemy recipes, knowledge of gods and religions,
spell paths, monsters, value of some artifacts, location of quests.
Same for the passwords that you learn in some places and use
elsewhere.  Actually, it is not a bad thing to have some books
providing "player knowledge" (except for the alchemy stuff, maybe).
It would even be a good thing to allow the player to recall these when
needed, in an easier way than having his character carrying the book
all the time.

This brings me to the C-S protocol...  In a private discussion with
David Sundqvist about the crossfire client, I mentioned that some
information could be sent to the client as HTML pages that would be
stored permanently and browsable at any time (thus crossfire would be
a self-documenting game, with its manual building up as the player
reads the books in the game).  Well, there is still a long way to go
before we can do that, and maybe HTML is not such a good idea because
some map makers would abuse HTML to create some nice effects that
would only work with a specific browser, and so on.  But at least I
think that some information should be sent to the client in a more
structured way than line-by-line with new_draw_info().  If the C-S
protocol could support several types of messages, it would be possible
for the client to know what to do with some of them.

Most clients would still dump all info in the main window, but some
clients could also store a copy of the messages permanently, so that
the player could re-read them later.  This would also be useful for
displaying the list of known spells, list of skills, etc.  For
example, the GTK client could display the list of known spells in a
separate window and allow the user to click in this list to switch to
the corresponding spell.  This would be very useful for newbies who
are not familiar yet with keybindings and don't want to type "cast
cause medium wounds" or "cast protection from electricity" all the
time...

[...]
> But this also brings something up in the formula - while rare
> objects should be costly and may not be, the rarity of the item
> should also be taken into consideration when computing those cost
> values.

Well, that's exactly what I meant.  :-)  I know how the body parts are
generated and why some of them have a low cost despite the fact that
they are rare (because a few treasurelists are used for most monsters,
and the cost of the generated objects is a basic cost that is
multiplied by the monster's level).  I don't want to change the cost
of these items: first because it would not be easy to do for some of
them, second because it would not make sense to increase their value.

What I would like to do is to find a way to compute some "rarity
factor" in the formula that compares the value of the ingredients with
the value of the object created by each recipe.  For example, a sage's
head is cheap, but much harder to find than 1000 platinium coins.
Same for the dragon's steaks, which used to be easy to find until the
wyverns started generating wyvern's steaks instead of dragon's steaks.
Dragon's scales and beholdereyes cost nothing, but they are harder to
obtain than the potions that can be generated from them by using some
recipes.

Maybe I should use the chance factor from the treasurelists to compute
the probability of having some body parts generated by the given
monster, and add a "value bonus" to the objects that have a low chance
of being generated by this monster.  This would ignore the fact that
the monster may be easy to find (and kill) or not, but this is
impossible to guess anyway (even scanning all maps would not be
enough, because some monsters can be summoned by spells).

> I think a lot more could be done with the alchemy code - I remember
> one of the old ultima games where certain ingrediants could be found
> by searching in certain places at certain times.  Addng stuff like
> that, or mining for some minerals in deep mines, etc could add some
> color to the game.

Yes.  For example, the FireTemple maps (accessed from the volcano in
one of the world maps) contain some nice stones that are not used in
any formula.  They should be used for creating something useful.

Also, one of the things that I have been thinking about for a while is
to separate the recipes in several categories: alchemy, smithery, etc.
The "alchemy" recipes would require a cauldron and create potions and
balms.  The "smithery" recipes would require an anvil (or a furnace --
better for a container) and create weapons and shields.  The "weaver"
recipes would require a spinning wheel or a weaving loom to create
some special robes and armours.  All these recipes would use the same
lib/formulae file and be handled by the same code.  The only
difference is that an extra flag would check which kind of container
(cauldron, furnace, whatever) is required for each formula.  That flag
could also be used to select the appropriate skill for computing the
chance of success and the number of objects created.

Since nobody appears to be working on that part of the code for the
moment, maybe I will try to implement some of these ideas.

-Raphael

[to unsubscribe etc., send mail to crossfire-request@ifi.uio.no]