Beam fusion

[nemesis2290]

Is it possible? Like when standing next to your partner and you both shoot a beam at roughly the same time, can the two energy beams fuse into a more potent one? Say two weaker fighters are on a team going 2v1 against a stronger opponent, let's say goten and trunks vs super buu, buu blasts a huge energy beam at them, but they counter it with two beams that fuse before the clash making the initial beam larger and allowing goten and trunks to continue pumping energy into the beam.

Is it AT ALL possible? I'm thinking not, probably has something to do with having to swap out the two beams with a new model in its place etc, therefore making it a waste of time to make in the long run.

I also searched the forum and found nothing on this, but I'm not 100% sure i'm the first poster on this topic xP

Anyways tell me what you think?

Also another quick idea, going super saiyan in a beam clash? not possible right? bummer D:

 

[Grega]

Is it possible? Yes

Is it probable? No

Adding a whole new system that reworks the beam system itself for nothing more than a visual gain would be a waste of time ATM. So youll have to be happy with a 3 way PS.

 

[IFlip92]

But the Super Sayian transformation during a PS is definitely possible I should think since it is possible in the current versions of esf as far as I've seen in the tutorial posted on esf-world, I havent actually tried it yet

 

[nemesis2290]

Oh wow didn't think it would be possible

Yeah I'm happy with the current way PS are, just a thought ^^

More looking forward to playing around a bit with the new melee system more than anything..

 

[Grega]

Oh wow didn't think it would be possible

Yeah I'm happy with the current way PS are, just a thought ^^

More looking forward to playing around a bit with the new melee system more than anything..

From a coding sense of view it would be something like this

If(client1.shootbeam() && client2.shootbeam() && distance(client1, client2) <= 100 && delay(client1, client2) <= 0.2)
{
removebeam(client1, client2);
beamfuse(client1, client2);
{

Pretty much saying if client 1 and 2 fire a beam in close proximity within 0.2 seconds of one another, their beams get removed and replaced by a fused beam. The question would only be who to give control for the fused beam.

And thats where the main issue lies.

Though adding all those extra checks and stuff so that 1 player can sit back and watch while the other takes control of his beam and tries to shoot someone with it is both a waste of coding and FX time not to mention bad for gameplay to strand a player unable to do anything while someone else aims his beam.

 

[Mkilbride]

They both aim it.

Make it like a PS, but between the two people, while aiming.

 

[Grega]

They both aim it.

Make it like a PS, but between the two people, while aiming.

One looks left and the other to the right. One used beam lock on, the other doesnt. What then?

 

[Mkilbride]

It jitters back in forth, kinda like Special beam cannon. Forces people to work in tandem.

 

[Henry]

Why not give the control to the first player who shot the beam? i think its the logic way to go, since the other player would be like just adding more power to the first beam.

 

[harSens]

From a coding sense of view it would be something like this

If(client1.shootbeam() && client2.shootbeam() && distance(client1, client2) <= 100 && delay(client1, client2) <= 0.2)
{
removebeam(client1, client2);
beamfuse(client1, client2);
{

Pretty much saying if client 1 and 2 fire a beam in close proximity within 0.2 seconds of one another, their beams get removed and replaced by a fused beam. The question would only be who to give control for the fused beam.

And thats where the main issue lies.

Though adding all those extra checks and stuff so that 1 player can sit back and watch while the other takes control of his beam and tries to shoot someone with it is both a waste of coding and FX time not to mention bad for gameplay to strand a player unable to do anything while someone else aims his beam.

Yes, except that that's wrong and that there is another gazillion extra issues:
- You probably only want to fuse beams that are actually going into a similar direction
- You probably only want to fuse with beams from team mates
- Distance between 'clients' is not very informative, you'd like to know the distance between their beams instead, similar argument for 'delay'
- You need to keep track of the 'delay so far' somewhere
- What about balls/detached beams?
- What should the fused beam and all of its fx look like?
- What happens if one of the players detonates?
- Removing a beam from a player and replacing it with a fused beam is not some trivial matter
- etc etc

 

[Grega]

Yes, except that that's wrong and that there is another gazillion extra issues:
- You probably only want to fuse beams that are actually going into a similar direction
- You probably only want to fuse with beams from team mates
- Distance between 'clients' is not very informative, you'd like to know the distance between their beams instead, similar argument for 'delay'
- You need to keep track of the 'delay so far' somewhere
- What about balls/detached beams?
- What should the fused beam and all of its fx look like?
- What happens if one of the players detonates?
- Removing a beam from a player and replacing it with a fused beam is not some trivial matter
- etc etc

Hars i know that. What i posted was an overly simplified implementation example.

And i also wrote this remember

Though adding all those extra checks and stuff so that 1 player can sit back and watch while the other takes control of his beam and tries to shoot someone with it is both a waste of coding and FX time not to mention bad for gameplay to strand a player unable to do anything while someone else aims his beam.

 

[harSens]

Hars i know that. What i posted was an overly simplified implementation example.

And i also wrote this remember

Yes, I'm just saying that you shouldn't post code examples that are conceptually iffy and oversimplified in some aspects and over specified in other (why only expand the collision detection algorithm between the beams, but not the actual fusion??). It suggests that we can implement beam fusion in three lines of code, but that we're just too lazy to do so.

 

[hleV]

Well,

on PowerStruggleStart
check BeamType
check ClientTeam
check BeamDirection
FuseBeamHeads
disable BeamDetonation

on PlayerDamage
check InFusedBeam
DefuseBeamHeads

 

[Grega]

Yes, I'm just saying that you shouldn't post code examples that are conceptually iffy and oversimplified in some aspects and over specified in other (why only expand the collision detection algorithm between the beams, but not the actual fusion??). It suggests that we can implement beam fusion in three lines of code, but that we're just too lazy to do so.

If thats all the beef you have with it then im glad XD

And yes i know its oversimplified, thats why i did it. Do you REALLY think id post a code example going it out of my head on the forum and do all the 1000 lines that would be needed otherwhise?

 

[harSens]

No, I'm suggesting that we should first resolve all design issues and lay out a proper design before throwing around pseudo code that either has implicit design decisions (in hlev's case) or is so simple that is uninformative at best and misleading at worst (in Grega's case).

 

[Grega]

No, I'm suggesting that we should first resolve all design issues and lay out a proper design before throwing around pseudo code that either has implicit design decisions (in hlev's case) or is so simple that is uninformative at best and misleading at worst (in Grega's case).

Fine ^^;

Sorry for posting iffy code examples.

 

[Damaera]

Fine ^^;

Sorry for posting iffy code examples.

You better be sorry, punk!

 

[Reptile]

You better be sorry, punk!

agreed