Re: CF: the map-editor

["Mark Wedel" <mark@icp.siemens.com>]

On Dec 2,  3:33am, peter@toneby.ml.org wrote:
> Subject: CF: the map-editor
> I finally got the map-editor to compile (I don't know what was wrong
> earlier, probably the maps...), anyway, are there any work currently to
> redo it into GTK? otherwise I would like to try to do it as a way to
> learn GTK.

 David Sundqvist has expressed interest to me in redoing the editor in GTK
also.   Redo in this case means a rewrite from the ground up.

> But since Mark is about to do some major changes to the internals of the
> server, I would like to know if there are any changes to the map-code
> that are planned, if so I would like to know what so I can make som
> assumptions about how to code the editor.

 The major change I tend to make to the internals is how objects are
represented - instead of one global object structure with different meanings of
some of the fields, break it down into several unique object types with clear
cut meanings (exp will always mean experience, and not bonus speed like it does
for rings right now.)

 I'll probably collapse the 100 or so object types into less than 10, with the
rest either being subtypes or actual data in the specific item that determines
its properties.

 For example, a quick list of the master item types:

 monsterss
 players
 weapons
 equipment (rings, armor, shields, helms, boots, ...)
 spell casting items (rods, wands, staves, horns, scrolls,potions, balms)
 and a few more I am sure.

  To further illustrate the idea, we'll take spell casting items.  Most all of
the items mentioned above more or less do the same things - they cast some
spell at some level of potency.  The difference is a scroll is used once and
goes away, wands are used some amount of time but stick around, and rods and
horns have unlimited uses but have a recharge time.

 So the object for this could be something like:

 struct spell_caster {
	int	spell_num (this may in fact be an enumeration type - don't
rember for sure)
	int	level (casting level)
	int	charges (1 for scroll, 5-20 or so for wands)
	int	max_charges (max power for rods - could also be set for a
			maximum charges a wand can hold if a player tries to
			recharge it)
	int	recharge_rate (rate at which it regains charges - 0 for wands)
	int	evaporates:1 (flag - if true, item goes poof when out of
charges)
	char	*applymsg;
}

 Rods/horns have some recharge rate (to mimic how it current is down, heavy
rods would have a faster recharge rate).   If the object has no recharge rate,
it is effectively a wand/scroll/potion.  For scrolls and potions, evaporates
(for
lack of a better name right now) is set so that when the last of the item is
used up, the item disappears.  applymsg is what we print when the player
tries to use it (blows for horns, drinks for potions, fires for
rods/staves/wands, spreads for dusts, etc.)

 This not only simplifies a lot of the code (apply function can pretty much
contain one entry in the switch for all of these objects), but it also means
that new items can very easily be added.

 For things like equipment (rings, armor, helmet, etc), the actual effect of
wearing them is all the same.  So for those, in addition to all the standard
fields (ac, armor, protections, immunes, etc.), we have a few extra fields
which have some identifier for body part and how many of them can be worn - for
most items, the num_worn would be 1, but for rings it would be 2 (it could be
argued to make it 8 - one per finger, but that has many play balance
implications)  But such a system makes it very easy to add new items - you
could add a 'underwear or warmth (protection from cold)'.  This item would have
a new body part identifier, since it can be worn with anything else without
problems.

 The basic idea is to make much of the item handling more general, so addition
of new stuff can easily be done - in many cases without even modifying the
source (right now, to do the underwear example above, you would need a new item
type, and make changes in the apply area).

 Back to the point of the editor - the above changes will certainly mean that
handling of objects will change a bit, so I would hold off on writing object
editing.  However, the basics of the layout and even map interaction is
unlikely to change (insert_ob_in_map is likely to remain unchanged, as are most
all map related functions I would think).  So a lot of the code can be done
without worry of it becoming nonusuable because the backend function have
changed.

-- 

-- Mark Wedel
mark@pyramid.com
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to crossfire-request@ifi.uio.no]