[CF-Devel] Future crossfire changes/projects
Michael Toennies
michael.toennies at nord-com.net
Wed May 16 06:04:11 CDT 2001
You should know that there is one great chance for
changing to isometric gfx.
David Gervais, a prof. artist which has drawn for some full price games
and which has served CF in the last month with some tiles of his free
monsters/tiles
set, has started a true isometric tile set.
Look at this:
http://dgrealm.50megs.com/iso-samples.html
Well, if we can do it in this way, we can also talk about ONE skin design
for linux and/or windows client.
Of course, in style and tiles, there must be some small changes to fit it in
CF,
but the engine then should be useable for all newer items.
The problems is, that DG is at the moment focused at on tile.
Btw: for this style, monsters will look very VERY improved, when they can
turn in 8 directions.
This will give a great realistic look. Because only monsters must have this
directions (map
itself will not turn, forget the compass), it will be not so much work.
The great thing is, that there is a great chance to inlcude DG in Crossfire!
This thing is his baby, so i don't think he will skip the chance to include
this
gfx system in a great engine like CF.
I had think about this isometric changing in the past, so i can tell you
that is will be easy
to change client/server to this. 90% work are the gfx, the whole
gameplay/server will be the same.
>
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.
>
_______________________________________________
>
crossfire-devel mailing list
>
crossfire-devel at lists.real-time.com
>
https://mailman.real-time.com/mailman/listinfo/crossfire-devel
>
More information about the crossfire
mailing list