Missiles

[_alias]

Just got the cvs and checked out the TODO file, by missile support you mean support for arrows, fireballs etc?

 

If it is ill have a go...

 

Should i just write a feature that moves xyz coordinates and allow other developers to attach textures and effects to these coords? Or do the whole thing :/

 

Someone enlighten me!

[Torg]

Just got the cvs and checked out the TODO file, by missile support you mean support for arrows, fireballs etc?

Firstly, that TODO file is about a year old. I'm meant to be updating it... and I shall. I guess this is a good reason to. :-S

 

If it is ill have a go...

Improved Particle Engine:

There are many ways to improve how the particles work, and it would also need to be updated in the map editor, fixing/improving this will also get us closer to the next topic....

 

Magic Spell FX :

This goes hand in hand with the improved particle engine. That would need to be done before MagicFX, however in updating the particle engine MagicFX should be taken into consideration.

These are some quotes from the thread that's most current as a "todo" list, so yes. It's more for fireballs and magic spells, but I think the movement code is also valid for projectiles.

 

Should i just write a feature that moves xyz coordinates and allow other developers to attach textures and effects to these coords? Or do the whole thing :/

I think (from Roja's comment) it is a mix of the movement code, and the particle effect. Seperating them should be a must so the code can have textures applied, but feel free to also write some particle effects for them (or better yet, take on the particle engine)

[Roja]

Well of course we want bows/arrows in the game!

 

You will have to discuss things with Entropy however, as he started to work on this but some problems arose with it. Mainly getting the arrow to be drawn in a direct route to the target. And for the arrow to leave the model at the exact hieght it's supposed to.

 

I'd be making the character animations with shooting the arrow, but it basically has to start as a 3d arrow that's on the mesh file(and always stays there) then translate to a 2d or 3d sprite...well it's complicated

[ttlanhil]

maybe something along the lines of:

(if projectile) add 3d object from server

(if spell) add particle object (new stuff, but working similar to above. you could have pre-designed particle 'objects' such as balls that trail particles (comet style), shoot off particles (ball lightening), fire dart, etc. heck, maybe that could be done in the normal 3d objects setup)

launch object (target x, target y, target z, speed) (speed perhaps as 10ths of a tick (as you move from one tile to the next, that's a tick)... and launch object as opposed to move, in that launch will do the entire motion)

remove particle/3d object

(optional... for blood, spell effects, whatever) add particle effect (at target location. presumably an actor)

(if appropriate) add/remove health from actor... etc

you can also add sound, animation commands, etc

 

so I see the 'best' option as being able to build particle objects. probably XML rather than graphics design, but so that the handler takes care of any needed particles

 

ed: x.y.z would either be floats or decimals of a tile (maybe 10ths?) so that you can have it start and end right where you want... in between is handled by the client updating position, as a decimal or float set of co-ords

Edited May 25, 2006 by ttlanhil

[Torg]

Along with part of Ttl's post are the problems I can see with determining if an actor has moved, or do all effects happen within the time from one step to another.

 

That said, those are server issues so something Learner and Ent need to work out.

[Kalach]

Along with part of Ttl's post are the problems I can see with determining if an actor has moved, or do all effects happen within the time from one step to another.

 

That said, those are server issues so something Learner and Ent need to work out.

 

 

For live effect, instead of positing "source" and "target", you can go with motion and collision detection. The missle would be similar to another actor. (Man, we could have fun if we were in an object-oriented environment.)

 

Basic Idea:

 

Missile is launched in a particular direction at a particular rate. It continues along that detection/rate until it reaches something it cannot pass through. It then checks that thing it cannot pass through to see if it's an actor. If it is an actor it "attacks" the actor. (Interestingly, a "parry" block could be considered a counterattack by the actor against the missle, with chance to destroy it.)

 

That's just my take as a programmer who is addicted to reuse and generalization.

 

Edit

 

Just reread Torg's post and I know that this is only useful to Ent/Lrn... Sorry. Leaving it for their sake.

Edited May 25, 2006 by Kalach

[Roja]

I think the problem was was that the actors can only face a total of... 8 directions i think, 0 degrees, 22.5, 45, 67.5, 90, etc..

So if the arrow is shot from a straight line at one of those angles, the farther the target is away from you the less accurate that shot is. So it's possible that the arrow can hit the target(it passes the collision test), but the arrow doesn't visually show it hit the target-and that looks bad.

 

Think I explained it all now

[Kalach]

I think the problem was was that the actors can only face a total of... 8 directions i think, 0 degrees, 22.5, 45, 67.5, 90, etc..

So if the arrow is shot from a straight line at one of those angles, the farther the target is away from you the less accurate that shot is. So it's possible that the arrow can hit the target(it passes the collision test), but the arrow doesn't visually show it hit the target-and that looks bad.

 

Think I explained it all now

 

 

I think I understand this: The problem is that if the target is actually at 11.25 degrees from an actor, the actor cannot face to the target, and the arrow may be facing the wrong way. The actor may end up shooting cockeyed, instead of straight on.

 

This could come back to the question of timeframes. How instantaneous are we looking at the missle moving, related to the rate of movement by a player? Should it be possible to say lead a player and hit them when they move to the spot? Can a moving player be missed by their natural movement?

[Roja]

 

 

I think I understand this: The problem is that if the target is actually at 11.25 degrees from an actor, the actor cannot face to the target, and the arrow may be facing the wrong way. The actor may end up shooting cockeyed, instead of straight on.

 

Exactly.

 

The rest of your question you'll have to get Entropy's response on

[Kalach]

 

 

I think I understand this: The problem is that if the target is actually at 11.25 degrees from an actor, the actor cannot face to the target, and the arrow may be facing the wrong way. The actor may end up shooting cockeyed, instead of straight on.

 

Exactly.

 

The rest of your question you'll have to get Entropy's response on

 

You like saying that to me.

 

I am, of course, totally ignorant of how this all works, but perhaps a lie is appropriate. Can the client show something moving A: in a straight (not grid limited) fashion and B: that doesn't exist in the server "physical" world?

[Learner]

 

 

I think I understand this: The problem is that if the target is actually at 11.25 degrees from an actor, the actor cannot face to the target, and the arrow may be facing the wrong way. The actor may end up shooting cockeyed, instead of straight on.

 

Exactly.

 

The rest of your question you'll have to get Entropy's response on

 

You like saying that to me.

 

I am, of course, totally ignorant of how this all works, but perhaps a lie is appropriate. Can the client show something moving A: in a straight (not grid limited) fashion and B: that doesn't exist in the server "physical" world?

Technically, when missles are added, it would be possible to make them fly in a straight line to their destination on the client.

[Kalach]

 

 

I think I understand this: The problem is that if the target is actually at 11.25 degrees from an actor, the actor cannot face to the target, and the arrow may be facing the wrong way. The actor may end up shooting cockeyed, instead of straight on.

 

Exactly.

 

The rest of your question you'll have to get Entropy's response on

 

You like saying that to me.

 

I am, of course, totally ignorant of how this all works, but perhaps a lie is appropriate. Can the client show something moving A: in a straight (not grid limited) fashion and B: that doesn't exist in the server "physical" world?

Technically, when missles are added, it would be possible to make them fly in a straight line to their destination on the client.

 

That's what I was getting at with "Lying." Basically, the client and the server would not be "in sync." The server would be moving it's "actor" along and doing appropriate checks. The client would be playing an animation moving in a straight line.

 

The problem still lies in the firing of a missle out of an inappropriate position of the actor, (11.25 or -11.25 instead of 0) Would that be an animation? (I am, clearly, very weak on graphics programming.)

[ttlanhil]

That's what I was getting at with "Lying." Basically, the client and the server would not be "in sync." The server would be moving it's "actor" along and doing appropriate checks. The client would be playing an animation moving in a straight line.

I dealt with that (quote as footnote). simply use decimal co-ords. note that the server does have to do about the samr thing, in case you shoot from outside a players' view, and the arrow comes in... you can have it enter at a co-ord on the path (or near it, I guess, since you can't check the actor source anyway), but the server does need to follow it properly

The problem still lies in the firing of a missle out of an inappropriate position of the actor, (11.25 or -11.25 instead of 0) Would that be an animation? (I am, clearly, very weak on graphics programming.)

not really a problem. allow time for a partial turn first. as in when you go to fire, the client does a partial turn (none, half, or all of a 1/4 turn animation, with the rotation speed adjusted... it'll look close enough to accurate) at the same time as drawing the string/raising crossbow/turning to cast spell/etc. if you do it in 2+ degree increments you can fit it in a Uint8 (or Sint8 and have it +/- from current direction, though you then assume the angle is correct, which it may not be) so it's not much more network traffic

once you finish, of course, you simply go back to facing one of the 8 directions (not necessarily the one you started from, probably just the closest)

 

foot:

x.y.z would either be floats or decimals of a tile (maybe 10ths?) so that you can have it start and end right where you want... in between is handled by the client updating position, as a decimal or float set of co-ords

[Kalach]

That's what I was getting at with "Lying." Basically, the client and the server would not be "in sync." The server would be moving it's "actor" along and doing appropriate checks. The client would be playing an animation moving in a straight line.

I dealt with that (quote as footnote). simply use decimal co-ords. note that the server does have to do about the samr thing, in case you shoot from outside a players' view, and the arrow comes in... you can have it enter at a co-ord on the path (or near it, I guess, since you can't check the actor source anyway), but the server does need to follow it properly

 

I guess I assumed that the server was forced to work in increments of whole tiles. It makes sense that it wouldn't. Does this still fall prey to the problems that Roja said Learner and Ent were working through?

 

 

_alias, do you have the information you need?

[_alias]

Well kinda but i had my own idea... You cant shoot a missile, unless its aimed at a target (like in combat mode), you then calculate whether the missile will hit the target before its actually animated. Then you move the missile with the coordinates, basically think of attacking with a melee weapon from a distance with a missile animation. This would be much easier to do than letting you shoot missiles at anything, cos no collision detection code will be needed, how? Well you take the enemys position and your position work out the time the missile will take to hit the enemy from a given speed and acceleration (equations of motion), and show the missile for that time only...then show a hit decal or something as soon as the time is up.

 

Most of the mmorpgs ive played dont let you use projectiles/missiles unless they are aimed at a target, mainly because of the reason above..

 

Also should i try to write the code in previous files or make my own files? Never used CVS before so im kinda worried if ill be doing something im not allowed to do...

 

-Thanks- _alias

[Atlantis]

Well, the way I would think it would work is this:

If you have your bow equipped, and an arrow in your inventory, you would use the attack icon (or walk in non-pk map), click on the thing you want to kill.

 

Then, buncha equations of distance and levels and their defence and such, and if you hit it, animation shows arrow going from you to it, if not, arrow is either not fired, or lands on the ground near the target.

[_alias]

Yeah that kinda thing

[Entropy]

The problem is far more complex than it seems.

There are basically a few issues:

 

1. A missile such as an arrow will have to be in the bow, and leave the bow in the desired direction. The missile has to be separate from the bow.

 

2. Some collision detection has to be implemented on the server in order to avoid firing through trees, houses and stuff. That collision detection has to be very fast.

 

3. The state of the server and the state of the client is delayed. The server for example has all the actors at a certain position, with a clear line of sight between two players, so an arrow would go through open space. The clients, however, can be a little behind, and to them the arrow would go through some other player or object.

[Roja]

The first one could possibly be solved by using a combination of precise parameters such as the exact height the arrow needs to be for each model, and the exact frame of animation that the arrow would be launched from the model and become the 2d/3d sprite object thing. I'd work with the programmer to find all that data.

 

The rest... up to you guys wish I could help more.

[Grum]

2. Some collision detection has to be implemented on the server in order to avoid firing through trees, houses and stuff. That collision detection has to be very fast.

Well, you can nearly always get away with checking if all tiles on the straight line between attacker and target are walkable. Of course you can't shoot across rivers then, but it would be relatively simple to implement. I think...

[Learner]

2. Some collision detection has to be implemented on the server in order to avoid firing through trees, houses and stuff. That collision detection has to be very fast.

Well, you can nearly always get away with checking if all tiles on the straight line between attacker and target are walkable. Of course you can't shoot across rivers then, but it would be relatively simple to implement. I think...

Then you have to worry about shooting thru walls, and other things that you can walk on top of? That also allows you to shoot thru trees, but not over a fence. Issues like that is exactly why some sort of collision detection would be needed server side.

[Entropy]

Well, you can nearly always get away with checking if all tiles on the straight line between attacker and target are walkable. Of course you can't shoot across rivers then, but it would be relatively simple to implement. I think...

 

Exactly. It will look ugly for example shooting at someone on the docks, or if there is a small bush or log in the way.

[dns_server]

It should not be too hard to determine the path that the arrow would take, you just need to use a 2d line drawing algorithm like Bresenham's line algorithm (the most efficent 2d algorythem) to process the map. just use the algorithm to check to see if there are any 3d objects (or people) located at that square.

 

so the way that i would do it is have the client and server send out vectors (with starting and ending coords).

eg player a wants to attack b:

1) a > sends a attack_Bow (x,y)

2) server checks range etc

3) server walks through the line algorithm to see what tile the collision will ocur on

4) server sends to all actors show_missile (type, x1, y1, x2, y2) for the clients to draw

5) server processes damage etc

[Torg]

I know this is off topic, but might be handy for him, so...

Also should i try to write the code in previous files or make my own files? Never used CVS before so im kinda worried if ill be doing something im not allowed to do...

FIrstly, you checkout a copy of the code (checkout is one of the CVS commands).

Then, edit it making your changes. Usually in a seperate directory to your clean copy.

After the changes are complete and you are ready to submit it, update both directories incase other files have been changed (update is another CVS command).

Lastly, do a diff on the 2 copies of the code (or use the CVS diff command in your working directory) and send the output to a file (my_patch.diff). Then, post the diff file on Berlios and post here to show off your work.

 

2) server checks range etc

3) server walks through the line algorithm to see what tile the collision will ocur on

I think the problem Learner and Ent are talking about is not *how* to do this... but that it takes too long. It needs to be extremely efficient. That algorithm link however could be handy in solving that problem. :-)

[Entropy]

It should not be too hard to determine the path that the arrow would take, you just need to use a 2d line drawing algorithm like Bresenham's line algorithm (the most efficent 2d algorythem) to process the map. just use the algorithm to check to see if there are any 3d objects (or people) located at that square.

 

so the way that i would do it is have the client and server send out vectors (with starting and ending coords).

eg player a wants to attack b:

1) a > sends a attack_Bow (x,y)

2) server checks range etc

3) server walks through the line algorithm to see what tile the collision will ocur on

4) server sends to all actors show_missile (type, x1, y1, x2, y2) for the clients to draw

5) server processes damage etc

Wow, really? I thought it would have been a little more complex than just a 2d line algorithm. I guess I was wrong. Would you be so kind to provide us with the C source code?