[CF-Devel] Future crossfire changes/projects

[Mark Wedel]

 Now that 1.0 is out, I'd like to get a little discussion/input on future
changes for crossfire (say 2.0).  I'm trying to keep these a bit more general in
nature and not go into details of exactly how feasible different options are (as
other changes may make some things easier or harder to do).  This is also to
make it aware to others possible projects they may want to take on.  I'm also
trying to limit to big and/or controversial projects.  Doing something like
adding a new spell isn't going to make this list.

 If you followup, it is probably worth while to start a thread for each of the
proposed changes, so that conversation on each one is easier.  Using the brief
description in the Change line for subject is probably a good idea.

General template I'm using:
Proposed Change: Brief description of change
Details: More detail on the change and other notes
Pros & Cons: possible benefits

 So on to my list:

Change: Increase viewable area of map
Details: Currently, the viewable area of the map window is 11x11.  this change
suggests making this area 17x17 or some other number (best solution would be to
have this a config option).
Pros: Larger viewable area gives more glitz to the client.  Most games have a
much larger viewable area.  Beyond the glitz factor, I think this may improve
play/strategy.  On a 11x11 map, the farthest a monster can be and still in site
is basically 4 spaces (monster being on the 5th).  If the size is 17x17, this
now increases to 7 spaces, giving more oppurtunity to notice spells and other
effects.
Cons: Larger maps means more bandwidth to get updates.  This may break/weaken
some maps (ie, a map where you pull a lever and cannot currently see the
result.  OTOH, if youu have 2 players cooperating, they see that anyways). 
Things like the world maps wouldn't have enough padding spaces beyond the
exits.  Some maps may hide big treasures/monsters currently out of sight, but
I'm not really sure the problem if that becomes visible.  This change would
require clients to get updated.


Change: Improved client/server communication
Details: This is intentionally broad - looking for input for things that should
get improved.  One thing that definately should get changed is text messages
should have a content type instead of sending color type - this change would let
the client choose the color and potentially other informatiion (font, what
window to draw it to, etc.)
Another case would be to improve ground object handling (for example, if on a
very large pile, sending more objects each tick, so if you stand there, the
entire stack might get sent).
Pros: Should make the game more playable
Cons: obsoletes old clients, don't want to do features that are a lot of work to
do but give little gain.

Change: Performance improvements
Details: Currently, crossfire has some pretty severe performance issues when
dealing with lots of spell objects. Very large maps can 'freeze' the server
while loading.  Likely to be other areas where performance is not very good. 
These should get fixed up.
Pros: Improved performance is always a good thing.
Cons: Some changes may be difficult to make or involve lots of code changes (and
hence lots of potential bugs).  Areas of improvement should really get
identified so areas that don't have any real problem don't get worked on.

Change: Improve NPC communication/scripting
Details: Currently, it can be very difficult to hold a conversation with an npc
because the communication is stateless and it isn't always to figure out the
keywords.  More advanced scripting would also allow for more complicated npc's
(or remove the need of linking a bunch of objects to mimic some communication)
Pros: improved communication is desirable
Cons: May requiring redoing a lot of npcs.  If an external scripting language is
used, has the potential problem of reliability issues (external script could
hang server by never returning)

Change: New map editor
Details: Currently, crossedit is basically unmaintained, and buggy.  Ideally a
replacement would be less buggy and more maintainable (if it was written in GTK,
for example, at least its using the same toolkit as the client).  However,
something more portable so that windows and mac could use it would allow more
people to design maps.
Pros: More reliable editor
Cons: May be a lot of work for not a great leap in reliability.  If written in
GTK, may lack portability to windows/mac (dunno if there is gtk port to those
systems).  If not written in gtk, it then lacks commonality with client, so its
yet another toolkit that people need to learn (IMO, on reason currently client
is largely unmaintained is no one really wants to learn Xt at this point in
time)

Change: Clean up object structure
Details: Currently, values in the object structure has different meanings
depending on the type of object - for example, sp has nothing to do with
spellpoints when used with exits.  This inconsistent use leads to problems (ie,
sp regen speed bug when using permanent experience).  Idea could be taken to
several different levels:
1) Basic - just add enough unique elements to object struct so nothing gets
re-used with these conflicting values.  Str always means strength.  This would
result in higher memory usage
2) Go to object type/subtype setup.  So equipment would be a major type, with
its own substructure type, creatues another major type, exits/transporters
another, etc - roughly a dozen major object types with subtypes.  Within each
major type, all the values mean the same thing.  This is a lot of work, and I'm
not sure the work is worth the gain.
Related: Remove integer values from archetypes/maps and use string names. 
Instead of attacktype 5, it would be attacktype physical|electricity.  This
would likely reduce bugs in archetypes, and make them much easier to read. 
downside of this is a bit worse performance loading these things up.
Pros: In the long run, may make things more stable as values don't get tromped
over for other uses.  If option #2 is taken, may make things more modular, and
more extensible (adding a new equipment subtype easier - since most functions
would deal with the main equipment type in the same fashion, supporting a new
subtype may not require any more changes than just for the equip logic)
Cons: Likely to introduce new bugs.  Potential for more memory consumption & a
lot of work (depending on which of these options is taken)

Change: Have tiling of maps done automatically by server
Details: Currently, tiling (ie, the world maps) is done by duplicating spaces
from neighboring map and lining the map with invisible exits.  This more or less
works, but has some problems (things don't always line up quite right).  One
example I can think of is the wyvern question - if you come into that square
from the south, your are on a different map and don't hit it.  The idea here
would be that there would be logic that says 'use map xyz for east, abc for
north, and qwe for south'.  As the player approaches the east edge of a map, the
server would see that xyz is to the east, load it up, and display the spaces on
that map as the player gets closer to the edge, and automatically handle when
the player moves over.
 This also has an advantage in that you can synthesize layers.  Imagine for
example a tower with the balcony on the south side on say floors 2 and 3.  With
tiling, for levels 2 and 3, you could specify that south map is 'towerentry'. 
So as you stand on the balcony of either level 2 and 3, you would see this map. 
If someone walked up to the tower, both players on level 2 and 3 would see this
player.  but towerentry itself would say map north is tower1, so they would
disappear into the first floor.  If one of the players jumped off the balcony,
they would once again be on this entry map, and as they went north, be on the
first level again.
Pros: Would make map designing of large maps easier.  Could have some cool
advantages
Cons: Could be a bit of work for the benefits gained.

Change: Increase outdoor map scale
Details:
Main issue is that the continent itself is quite small relative to other maps -
in apparant scale, the continent is only 2-3 times larger than the city.
 There are 3 main points on how to do this (I'm going to include pros/cons with
each one)
1) just take the world maps, and blow them up by 2,3,4 (or more) times.  Do some
cleanup so they aren't
so blocky (as well as exits).  Pro: Easy to do.  Con: there is still a disparate
scale
2) unified outdoor scale.  In this mode, things like the city would actually be
on the world maps (so you have the same scale inside and outside the city
gates).  Pros: Unifies 'outdoor' scale.  Puts cities actually in the world map,
so various spells or other abilities could let you bypass gates and so forth,
giving the game more potential character.  Cons:  A bit more effort to do.  May
open things up to abuses.
3) Totally unified scale.  This basically takes #2 above and extends it to
everything.  So shops are just 20x20 blocks actually located within the city,
which is located with the world as a large.  This would make everything much
bigger (cities would have to be several hundred spaces across just to hold all
the dungeons, shops, etc).  Going accross country really would be a major
journey.  Pros: Basically takes what maps we have now and creates an apparantly
huge world.  May let players find maps they otherwise wouldn't (I know for a
fact I don't try every house in the city, since 90% are closed, but if your
taking a shortcut accross some area, you may notice some monsters in some
house).  Cons:  A lot more work - this could probably be done more piecemeal. 
May make the scale too big (very hard to find some dungeons for example). 
Definately would want automatic tiling if this is done.

Change: Allow transportation objects
Details: Basically allow things like horses, dragons, boats, etc which speed up
travel time or let you travel over types of terrain you normally could not go
over.
Pros: Adds some neat abilities
Cons: Ability to travel over some types of spaces may open up abuses (ie, easy
to get some quests, etc). Demand for this may not be really high?

Change: Spell objects
Details: remove spellist.h and spells.h file - instead have all that information
contained in archetypes.  Rely on archetype data for more information for spells
(ie, size of explosion for the variosu fireballs would be by value in arch).  A
players known spells would be these spell archetypes in the players inventory. 
These archetypes would also be mutable, so someone could easily make a 'mega
fireball' by taking a large fireball spell object, increase sp and size, and
putting it in a spellbooks (spellbooks would basically be a book with a spell
object within it - if player successfully learns it, this object goes from book
to player object)
Pros: Make spells much more extensible, and may actually reduce amount of code
(as more data would come from archetypes and not values in the code itself)
Cons: Likely to be some performance hit.  Mapmakers could put out abusive spells
(but no worse than right now with abusive objects I would guess)

 Phew.  Longer than I thought it would be.