About to delve into a big new area for my game - shooting weapons (have melee combat largely implemented)
I wanted to just check my understanding and ask for any design advice.
Right now, I’m thinking that when the player chooses to use a gun or crossbow, etc. - I spawn a static model of a bullet/arrow/whatever and just get it moving.
I would attach a collision solid to the projectile mesh and use it to detect what it hits, right?
Does it make sense to create a task for this projectile , so it can be destroyed. For example, when spawning , I make a task and tell it to trigger in 3 seconds . All the task does is destroy the projectile. Just worrying that this would be resource intensive if I have lots of bullets flying around. Also , how would I actually name these tasks so they’re unique? Is there a better way?
Trying to recall my vector math, so what’s the basic setup the heading for the projectile?
Assume I have positions of source and target. What’s the actual calc to set up an interval properly to get the projectile moving? I can assume I would subtract the pts to get a vector?
All suggestions/advice welcome. A code example that you could point me at would be great, too.
Ok, let me start with #2 above-
Does it make sense to spawn static models to use as projectiles and have individual tasks to destroy them. Or is there a better way (1 kill task that somehow knows which 1 to kill?)
My game is rts-like, with 10-20 chars all firing multiple projectiles. Just wondering what a good approach would be.
Use a collision ray instead of individual bullets colliers. Don’t use bullet meshes; use textured primitives.
Thx for the reply.
re: the geom primitives, is that because they’d be a lot less resource intensive? I’d probably still need to use meshes if I have rockets or arrows or something that needs a mesh?
Revisiting this after a long break.
Any code examples on projectiles (in an rts type game if possible)
Any advice on the questions I posted initially?
A few thoughts:
You say that your game is an RTS-game–am I correct in taking it then that there is no in-game avatar for player (the player instead commands varous units remotely)? If so, then why simulate projectiles at all? Why not have the results of shots be calculated based on the properties of the units in question (and the terrain, if called for), and then play relevant animations as called for?
However, if you do want to simulate projectiles, my own approach–which I do not claim to be either the only or best way–is to have a single “update” method operated by a task, and then give each relevant object an update method of its own. In this way a projectile might measure out its life, and mark itself as “dead” when that time is up, to be cleaned up in the main “update” method. No additional tasks are created–but I’m not sure of how it might perform if you have particularly high numbers of projectiles flying around at a given moment.
Thanks do for the response.
Re: the tasks you mentioned , just for my education - what is the advantage of having individual tasks for each projectile ?
RE: the RTS question. Yes it’s a squad type game. The player controls a team of units (not sure of limit yet, but probably 1-8, depending on mission) he is facing other, similar units.
I guess I was thinking projectiles because there may be the possibility that an enemy shooting a projectile at you could be avoided if you react fast enough to move your unit out of the way . (Some projectiles are slower than others like grenades or arrows)
Ah, I perhaps worded my suggestions poorly; I meant, I believe, to suggest having only one task, which calls a game-level “update” method, which in turn calls the update methods of the various game-objects that you might have.
As to the advantages, I’m afraid that I’m not sufficiently well-versed in that–I’ll leave such recommendations for someone better-informed than myself, I think.
Hmm… All right, I could see that with grenades (which are additionally often timed), but I’m dubious of a player managing to command a squad away from an already-loosed arrow, unless that arrow is very slow.
However, you do have a point regarding grenades–but that seems to me to be likely to be a relatively uncommon case, in which such projectiles could just be treated as an ordinary game-object.
Ok, so if I go the non-object route, what’s the basic approach?
(It would make perfect sense for a laser beam, which I may also implement)
Is it basically:
“Shoot” method invoked
Use collision ray starting from unit (I guess I’ll figure out which way they’re facing as well)
For projectiles that drop minimally over their expected distance and that travel very quickly (such as bullets), I’d suggest treating them as lasers.
- Determine the firing direction
- Cast a ray with its origin at the projectile’s starting point and pointed in the above firing direction
- Find the first collision, if any
- If there is a first collision, determine what it hit, and act accordingly (create a riccochet effect or burst of soil when terrain is hit, deal damage when a unit is hit, etc.)
For projectiles that are intended to drop or arc significantly, but which still move quickly, such as arrows, consider simulating them as parabolas; the basic idea is the same, but with the ray replaced by a parabola.
For slower projectiles, as already indicated, I suggest treating them as normal objects.
The specifics of the above are likely to depend on the specifics of your game: what effects you want to achieve, what collision systems you’re using, etc.
Thx, I’ll start with laser-type weapons as it seems the most straightforward.
In terms of visuals - I think I recall seeing elsewhere on these forums about implementing it using meshdrAwer (which I’ve never used) - is there a sample of that somewhere or is there a better way to actually draw the laser ? I’d like to have options for controlling its color and maybe adding glow.
Appreciate your taking the time.
Just noticed the Avolition source was released. Will give it a look as it looks like the kind of thing I’m trying to do projectile-wise.