[CF-Devel] Combat animations/sound
crossfire-devel at archives.real-time.com
crossfire-devel at archives.real-time.com
Tue Feb 10 04:22:29 CST 2004
Le Mardi 10 Février 2004 09:28, Mark Wedel a écrit :
>
tchize wrote:
>
> - additionnal layers (bottom of everything, bottom, middle, top, on top
>
> of everything). Not yet fixed, see point below.
>
>
>
> - More than one visible item available in a layer (they just stack at
>
> that layer)
>
>
Note that also requires rework on the server side - currently, the server
>
only calculates the face for 3 layers (floor, middle, top). So at some
>
level, there will always be some imposed limit on the number of layers -
>
there is some practical limit (in very early hacking I did (before the
>
client/server split), aside from performance of drawing every object on a
>
space, after you get a few, the pile just looks like a complete jumble -
>
only the top couple were distinguishable).
>
>
That said, adding layers could be nice. One of the problems right now
>
related to the map sending is that faces can 'change' layers.
>
>
eG, you could have floor, food, orc. However, now an arrow is fired, and
>
passes over the orc - that space would now be drawn as floor, orc, arrow -
>
basically meaning 2 faces get updated.
>
>
If you say there are like 4 layers, that could work reasonably well - you
>
could basically have up to 2 objects/layer - the layers being floor,
>
equipment/misc objects, creatures (monsters & players), and flying objects.
>
>
That would generally fix the problem above - food would be on the
>
equipment layer, orc on the monster layer. So when the arrow shows up, it
>
just goes on the flying laying, so the stuff underneath doesn't need to get
>
updated.
>
>
> - Map is made of 2 concurrent part: * The mostly fixed one (ground,
>
> buildings, non pickable/non killable items) * The non fixed one (mainly
>
> monsters and pickables).
>
>
As I mention below, I don't see the gain in doing this. Server already
>
works on not re-sending data the client knows about.
Not really true. Move one step left, you get a mapscroll followed by the left
map column sent by server. But then move one step right, the server send
again the right column which disappeared when you moved left.
And the backgrounds animations are a big problem too. Be near the seen ad you
get agian and again map updates.
>
>
So the only perceived gain I could really see is that somehow the
>
protocol itself could be made more efficiently.
>
>
> The mostly fixed part of map would be send to client only one time. This
>
> would includes additionnal info like blocked squares (so client can
>
> precalculate moves, and make things look softer). Changes to this part of
>
> map (which may happen from time to time) will trigger a patch event from
>
> server to client so map are against in sync. I am thinking about using a
>
> big picture for the map background/buildings/Walls(so mapmakers could
>
> design a map made of something else than squares)
>
>
Well, a big picture is a different issue. The idea itself is nice.
>
However, that is more of a nature of the client itself sending the
>
background, and the other layers still being drawn on top of it. So I'd
>
then say that gets into an issue that the map shouldn't have the extra
>
layers if it is designed with that background.
>
Yeah idea is nice, didn't think deeply about it yet. Anyway not a priority.
>
> No need to say map animations would be handled only by client.
>
>
Note that map animations get trickier than inventory animations.
>
>
This is mainly for two reasons - 1) inventory animations don't change
>
much (eg, the only one I am aware of that will change animation speed is
>
the power crystal) and 2) You need to send more state info for map
>
animations.
>
>
The second point is consider a map with 20 orcs. You don't want them all
>
animated in the same phase - there is code to make it so that doesn't
>
happen (There speed is randomized). Likewise, there are many more things
>
that can effect the animation phase of creatures (spells, terrain, etc).
>
So now for those 20 orcs, for each orc, you need to store away the phase,
>
animation speed, and animation. And I'd have to look at the code, but the
>
time to next phase may be necessary (eg, a creature that has speed 0.25
>
will sit in phase 1 for 4 ticks. So even if we say it is on phase 1, does
>
it stay on phase 1 for 1 more ticks, 3 ticks, etc).
>
Already thought about it. Think about something like sending 'object (eg orc
5147831)' at location, and along with it a value derivated from speed_left
(which is used to know when next step of animation is to trigger) the speed
value and the animation. Because some object have different animation at
different time,s server could send info like <change animation for object
5147831 to animation number 7452>
or could send infos like <object 5147831 moves of -1,0>, but those info should
only be send for non fixed part and only if <object 5147831> is visible by
player (or becomes visible or disappear) so this would prevent 'look thru
wall/ track monster' cheats
>
So it becomes a much trickier issue of whether the client handling all
>
that, and the server sending that once is greatly more efficient. Eg, if
>
the player is standing still, kills an orc, and another orc steps up, need
>
to send all that stuff for the new orc, which is not likely to be on the
>
same phase
>
>
Now there are some cases where it is more a clear cut gain. The moving
>
spikes, burnouts, etc, are things that won't get effected, and our
>
stationary.
and sea
>
>
> That's why 'mostly fixed' should be choosen with care. Nothing. Also note
>
> that client already knows more than player (aka disable darkness code an
>
> see better. i know complete dark is not send but nearly complete dark is
>
> alaos difficult to see). The main idea is to prevent sending map info to
>
> client if they are the same as in released maps.
>
>
But darkness was always optional - it is a visual effect, and is known
>
that clients may display it differently (some settings within the gtk
>
client may make the images more/less visible). However, for all purposes,
>
a dark space is still considered with view (eg, if you look at the space,
>
you get the same level of detail).
>
>
Note that the server already does work to make sure we don't send data
>
the client already knows about. So I'm not really sure what is gained by
>
trying to send the static data only once - that is basically already
>
happens only once.
>
>
And I really don't want to add the extra complexity of 'this is a public
>
map, handle with method X' vs 'this is a custom map, handle with method y'.
No the idea is <<is this the background i find
in /usr/share/crossfire-cleint/maps? if yes, put it in memory, if not
download from server>> (like images are cache handled for now)
>
>
And from a client perspective, this can get more complicated. Eg, one
>
can rightfully consider using fog of war not cheating (it is just showing
>
you what you've seen before). But the simplest implentation of the client
>
basically says if we have info for a space draw it. So now you could get
>
players seeing stuff on the fog map that they havent' actually seen yet.
>
In a sense cheating, but not intentional on the client side.
>
>
Since I started this, a few thoughts on what I'd like to see in the map
>
protocol:
>
>
1) Sound support. Current sound stuff could use this, but I'm also
>
thinking about if you have recurring sounds or the like (sounds of a
>
waterfall, those moving spikes, etc.)
Yeah and ambiant music (gros did a hack for this)
>
>
2) Lighting - instead of sending darkness for each space, tell the clien
>
that the map is dark X, and instead send the light sources (and their
>
intensity). This would actually reduce bandwidth, and should also make it
>
easier for better lighting effects (server would still calculate darkness
>
just in terms of line of sight). Related to this, light sources could
>
potentially have different colors - of course, up to the client if it can
>
do anything with that.
agree
>
>
3) Clean up some of the handling as related to big images and their heads.
>
Ideally, server can mark there is a head object on a space so that the code
>
for sending the packet doesn't have to do as much work.
>
>
>
_______________________________________________
>
crossfire-devel mailing list
>
crossfire-devel at lists.real-time.com
>
https://mailman.real-time.com/mailman/listinfo/crossfire-devel
_______________________________________________
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