now the beam type attacks in my game are coded awkwardly. I just want to know if anyone want to share their theories on design. Let's say I make it cause damage on bump and leave the rest as filler, but than if someone walks into the beam they won't get hurt.
I could do something where I do damage on crossed(I don't remember but I had some problems with that too).
What's the best way to take damage away from the player with a beam type attack?
I guess my main problem is a teleport my beam into correct position so it's stationary and cross doesn't work cause it's not moving. So the other question would be how can you make a beam look pleasing while moving and spawning more behind it when it's crossed a tile
ID:1876292
 Jun 17 2015, 12:26 pm (Edited by moderator on Jun 17 2015, 2:10 pm)
|
|
|
Jun 17 2015, 12:35 pm
|
|
HaxRp
 |
I'm having trouble with my very own beam system too, similar positioning.
|
I fixed the formatting on your post. For future reference, remember you should put any text you add outside the <b>...</b> tags. Also, may as well remove the original template if you don't use it.
| |
Try Crossed()? Just make sure your beam is a mob and not an obj. Then just run a simple while-loop to deal damage per tick as long as they remain inside.
| |
I guess my main problem is a teleport my beam into correct position so it's stationary and cross doesn't work cause it's not moving. So the other question would be how can you make a beam look pleasing while moving and spawning more behind it when it's crossed a tile Basic trigonometry. https://gfycat.com/RawWatchfulBrownbear Read up on your trig, focusing on the unit circle, sine and cosine in particular. | |
Just make sure your beam is a mob and not an obj Why? Mobs only make sense for things that should have vision. Beams don't need vision. | |
Ter13 wrote:
Why? Mobs only make sense for things that should have vision. Beams don't need vision. I meant if he wanted to use Crossed(). It's not the most optimal solution, I'm aware. | |
Crossed() is defined for movable atoms, which include objs as well as mobs. Another common misconception is that the Cross() family of procs only work in pixel movement, which is false.
| |
DanteVFenris wrote:
Let's say I make it cause damage on bump and leave the rest as filler, but than if someone walks into the beam they won't get hurt.It just depends how you want to do it. It's your game, after all, and there's no right or wrong way to implement a beam attack. Try to define what a beam is before writing code to implement it. Where do they come from? What are they? Where are they going? If someone walks into the beam, should it be interrupted like a beam of light or a stream of water, so that the part past them continues but the part hitting them is blocked? Off the top of my head, you probably could use an actual beam of particles that are in constant motion. Or should the person be prevented from stepping in the way, as if the beam is solid? That would probably be the easiest, most efficient, and probably less cool thing to do, though, and no part of the beam would have to move. | |
yea thats some good design decision. It would be less cool but more efficient. So many decisions.
Beams also are hard artistically too. Like for legit "energy beams" dbz style i have buus fury to look at and mimic. But for my blood whip i do not. | |
thats definatley the type of beam im looking for but sense im only making 4 directions movable i only need straight beams and not use math. Just need to make them artistically appealing as you did.
This was a design decision to ruduce time, and make pvp easier by being more direct in the position you attack in(at least thats what ive found, i also find it too easy to dodge attacks) | |
Honestly, 4-directional projectiles make games unplayable for me.
| |
well sense your attacking with keys 1-7. If i was doing a game where everyone could do a beam attack i could implement that, but sense only certain classes are it would be like the classes that can do that have one extra move on slot.
Though what i could do is make every class have their own unique clicking ability!! oh my god such a great idea. Itll go onto my thinking list. But for now that will prolong development. That may be an after release idea. Like i could do it so it just does that for only targeted abilities as well. But again dont have the time to spend time on that. As i have zero experience with messing around with trig with in relations to images. | |
Ter13 wrote:
Honestly, 4-directional projectiles make games unplayable for me. Well, then. ): If you wanted to play around with animate() and lists, you could send off one projectile in whatever direction and have it drop animate()'d trail pieces as it goes(for fancy fading beams). While the beam is being drawn to whatever it's max length is, have the projectile keep a list of each turf it crosses so you can have a loop running simutaneously that collects any mobs that are in the turfs to a list. That way you get a beam that only relies on one actual projectile, while still hurting all the mobs that step foot in the effected ray. I'm sure there's an easier method, but that's more or less the approach I'd take. | |
animate() can do that!!!! how!!! this is what ive wanted to do forever
i find a hard time thinking of ways to use animate. Would i have to make each piece as a seperate objects? | |
Animate() in this instance isn't doing anything but attempting to negate the extra load from otherwise adding new trail objs every step. You'll still need to make a proc to initiate each trail piece, but it's (marginably) less load.
I might experiment with the idea when I'm home and share the results. (: | |
Ter actually posted a very nice looking full directional beam gif on the pixel movement thread in Tutorials. It looks really nice and I'm sure if you asked nicely and ate all of your vegetables, he'd go into how he did it.
Sorry for bragging on you, Ter, but it does look nice, at least. | |
I'm assuming it's taking an icon which just details the look of one "segment" of the beam, rotates it, then stretches it to the appropriate length. All while having a "cap" at the ends.
| |
I'm assuming it's taking an icon which just details the look of one "segment" of the beam, rotates it, then stretches it to the appropriate length. All while having a "cap" at the ends. Nope, I actually have to break it up into 32x32 segments because BYOND doesn't do visibility of scaled icons right. | |
Ter13 wrote:
I'm assuming it's taking an icon which just details the look of one "segment" of the beam, rotates it, then stretches it to the appropriate length. All while having a "cap" at the ends. Let me guess, blurring due to the anti-aliasing? I've run into that before myself and it's obnoxious, wondering if it's the same reason... and if it's the reason we're asking for nearest neighbor? | |