Jump to content


Photo

Missiles


  • Please log in to reply
131 replies to this topic

#1 _alias

_alias

    Newbie

  • Members
  • 7 posts

Posted 25 May 2006 - 04:07 AM

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!

#2 Torg

Torg

    Leopard

  • Members
  • 1631 posts
  • Gender:Male
  • Location:Drouin, Australia

Posted 25 May 2006 - 02:01 PM

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)

#3 Roja

Roja

    Unicorn

  • Admin
  • 8802 posts
  • Gender:Not Telling

Posted 25 May 2006 - 02:19 PM

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 :D

#4 ttlanhil

ttlanhil

    Bear

  • Members
  • 5155 posts
  • Location:adl2.internode.on.net; south australia!
  • Interests:pineapples, programming, and EL 8^)

Posted 25 May 2006 - 02:24 PM

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 by ttlanhil, 25 May 2006 - 02:26 PM.


#5 Torg

Torg

    Leopard

  • Members
  • 1631 posts
  • Gender:Male
  • Location:Drouin, Australia

Posted 25 May 2006 - 03:32 PM

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.

#6 Kalach

Kalach

    Skunk

  • Members
  • 149 posts

Posted 25 May 2006 - 03:41 PM

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 by Kalach, 25 May 2006 - 03:42 PM.


#7 Roja

Roja

    Unicorn

  • Admin
  • 8802 posts
  • Gender:Not Telling

Posted 25 May 2006 - 03:53 PM

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 :D

#8 Kalach

Kalach

    Skunk

  • Members
  • 149 posts

Posted 25 May 2006 - 04:08 PM

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?

#9 Roja

Roja

    Unicorn

  • Admin
  • 8802 posts
  • Gender:Not Telling

Posted 25 May 2006 - 04:37 PM

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 :)

#10 Kalach

Kalach

    Skunk

  • Members
  • 149 posts

Posted 25 May 2006 - 04:46 PM




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 :D


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? :P :) :huh:

#11 Learner

Learner

    Ant

  • Admin
  • 5434 posts
  • Gender:Male
  • Location:MN, USA
  • Interests:Persistent RPG

Posted 25 May 2006 - 04:50 PM





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 :D


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? :P :) :huh:

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

#12 Kalach

Kalach

    Skunk

  • Members
  • 149 posts

Posted 25 May 2006 - 04:56 PM






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 :D


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? :P :) :huh:

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.)

#13 ttlanhil

ttlanhil

    Bear

  • Members
  • 5155 posts
  • Location:adl2.internode.on.net; south australia!
  • Interests:pineapples, programming, and EL 8^)

Posted 25 May 2006 - 05:40 PM

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



#14 Kalach

Kalach

    Skunk

  • Members
  • 149 posts

Posted 25 May 2006 - 06:09 PM

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?

#15 _alias

_alias

    Newbie

  • Members
  • 7 posts

Posted 25 May 2006 - 07:38 PM

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

#16 Atlantis

Atlantis

    Feran

  • Members
  • 2035 posts
  • Location:sunny_moon
  • Interests:Dasdfadf, asdfdsf....werersdf asjkfjdsf ? skjdfkj....asdfasdf!

Posted 25 May 2006 - 07:51 PM

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.

#17 _alias

_alias

    Newbie

  • Members
  • 7 posts

Posted 25 May 2006 - 08:26 PM

Yeah that kinda thing

#18 Entropy

Entropy

    teh G0d

  • Admin
  • 14293 posts
  • Gender:Male
  • Location:USA

Posted 25 May 2006 - 08:43 PM

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.

#19 Roja

Roja

    Unicorn

  • Admin
  • 8802 posts
  • Gender:Not Telling

Posted 25 May 2006 - 08:49 PM

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.

#20 Grum

Grum

    Phantom Warrior

  • Members
  • 2672 posts
  • Location:Lost in the quartz mine -- again

Posted 25 May 2006 - 09:39 PM

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...




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users