Create RFC-Projectile-Submunition-additions-changes

[EjoThims]

Feature: This RFC is to discuss potential/future changes and additions to projectile and submunition behavior.

I'm going to go ahead and list a few different things I can think of having seen discussed, but the creation of this RFC was prompted specifically by curiosity about weapons creating lasting zones of damage, akin to common spell effects like firewall or blizzard.

List can be expanded/trimmed as we figure out how feasible certain behaviors are with what changes or as new suggestions come up.

Names are descriptive place holders, not any kind of stone set mandate.

In general, even where already possible with submunitions, I think we could benefit from base access to them, to reduce repetitive strings of dozens (or even hundreds) of submunitions, for both creation ease and performance issues.

Feature Details

Pulse AoE- repetitive damage in area, like repeat explosions. Offsets or inaccuracy could change point of origin, and individual explosions need not be same size as zone they spawn within. This is blizzard when using both of those modifications.

Continuous AoE - constant, consistent damage in area (though drop off over time would still be a potential modification), dealt on initial entry as well as at regular times. This is firewall.

AoE Wave - a moving zone of damage that is not stopped by collision. Preferably an attribute that could make either of the above mobile instead of static.

Piercing - a projectile that can pierce X number of targets/frames/whatever measure. Good for hitting multiple ships and/or the same ship multiple times.

Repeat - A projectile that repeats itself X times. A shortcut for looped submunitions that (hopefully) will also avoid the problem of all submunitions in a looped chain going off when enemy is hit early. Modifications could include allowing repeat from initial origin or projectile's current location.

Repeat End - A projectile that spawns at the end of a repeat chain. A shortcut for specific change after a submunition loop.

Charge - projectile that only fires X frames after firing input, preferably from current location of ship or parent projectile.

Spawn - creates a submunition after X frames without current projectile dying

Spawning - creates a submunition -every- X frames without current projectile dying

Sticky - new submunitions are generated from the target ship that was hit by the "sticky" one

Usage Examples

TBD

Performance Impact

TBD

[Amazinite]

Pulse AoE
Continuous AoE
Spawn
Spawning

I believe all these would be covered by the following idea that I have written down:

Projectiles that deal damage while alive instead of on impact
	e.g. a projectile that deals damage in a field around itself; basically perpetually exploding while it's alive
		Potential uses:
			* "black hole bomb" that continually sucks nearby ships in while active
			* "deployable turrets" that fire on nearby enemy ships
				emitters on their own would just create "turrets" that attack the targeted ship, or fire into nothingness if without a target, so would need projectile retargeting to truly be effective. Or just have the turret spin in circles and fire projectiles randomly to begin with.
	Can currently effectively be done via self-nested submunitions, but this can't be stopped once started. The main projectile can also impact asteroids or ships, potentially ending the effect earlier than intended
	How about an "emitter" key that causes a projectile to spawn its submunitions on a reload timer
		`"emitter" 10` would spawn its submunitions every 10 frames, but the emitter projectile still wouldn't die until its lifetime has run out or it has impacted something
		"burst emitter" and "burst emitter count" could also be attributes akin to "burst reload" and "burst count"
		"emitter" causes "submunition" to be created or use a separate "emit" keyword? i.e. "submunition" is ONLY when the projectile dies, "emit" is when "emitter" triggers
	"no collision" keyword to prevent the projectile from colliding with ANY ships or asteroids (step up from phasing which only impacts the target ship)
		"no collision" would still allow AM hits, so "no collision" emitters with missile strength could be destroyed.
	Contextual emission of submunitions?
		Only emit submunitions if there is an enemy in range?
		Basically a "blast radius" detection radius for when emission is triggered
		Not sure on how the syntax/code for this one would work out.
			Could potentially check distance to target + retargeting to nearest target to achieve this
	
	Add "emitter" "burst emitter" and "burst emitter count" to Weapon
	Add similar variables to Projectile for keeping track of a projectile's current emission reload state
	
	Projectile::Move
		Just before or after live effects are created
		if(this projectile emits, i.e. it has submunitions and the emitter attribute)
			Could use a boolean set during projectile creation that determines this instead of checking the submunitions list and emitter attribute every frame
			if(reload, burst reload, and burst count are ready to fire)
				create submunitions (just like you would if the projectile had died)
				decrease burst count
				update reload and burst reload
			update reload and burst reload
			update burst count
	
	Look to Hardpoint::Step and Hardpoint::Fire for how emission reload, burst reload, and burst count should be handled
		Basically just look over how reloading works for Weapons and replicate that over to Projectiles

(My ideas file is basically just me jotting down stuff that pops into my head, so if anything seems incoherent or confusing then just ask and I'll expand upon what I was thinking.)

Under my idea, "emitter" is what you call "spawning".
"continuous AoE" would just be a projectile with an "emitter" of 1 and an explosive submunition.
"pulse AoE" would be the same thing but with an "emitter" value greater than 1.
"spawn" for one time submunition creation is basically what we already have (have an initial submunition that splits into two on death), so not sure anything extra is needed to cover that concept.

Repeat
Repeat End

I'm not really sure on the usefulness of these. If I want a single projectile to repeat itself four times, why not just extend the initial projectile's lifetime by four? If the intention is to have a projectile that repeats itself but also creates other projectiles every time it repeats, I believe that's covered by the above concepts (e.g. instead of repeating four times, just emit four times over the lifetime of the projectile).

AoE Wave

This seems like the most complex idea here to me. To have a moving zone of damage, the weapon/projectile would need to be damaging in rings, whereas normal AoE is just a circle. Hazards are capable of damaging within rings, so projectiles would be capable of making use of the collision detection for damaging in a ring, but this would be an entirely separate concept from what's discussed above. And not only would projectiles need to be able to deal AoE damage in rings, but the game would also need to keep track of how far along the "explosion" has progressed, whereas currently explosions are all single frame events.

Piercing

"pierce" is already used as a keyword for damage that bypasses shields, so I'd suggest "penetraton", a prototype of which I already have on one of my branches: https://github.com/Amazinite/endless-sky/tree/projectile-penetration
See also: endless-sky#424

Charge

"charge" seems to me like it'd strictly be an alternative reload/firing mechanic, not something that affects projectile behavior (you could simply use an intermediate submunition to simulate a projectile charging up in place).
See also: endless-sky#902, endless-sky#982

[EjoThims]

I believe all these would be covered by the following idea that I have written down:

Yea, definitely seems like they could all be worked in from there. :D

"spawn" for one time submunition creation is basically what we already have (have an initial submunition that splits into two on death), so not sure anything extra is needed to cover that concept.

That would still run into the issue of the initial projectile carrying all submunition damage if intercepted early, but "emitter" with right options would still be able to fulfil that role as well.

If the intention is to have a projectile that repeats itself but also creates other projectiles every time it repeats, I believe that's covered by the above concepts (e.g. instead of repeating four times, just emit four times over the lifetime of the projectile).

Yea, that would generally handle it, I think.

AoE Wave

This seems like the most complex idea here to me.

As long as the "emitter" can have velocity still, this should be possible under it as well. Just have it moving between each emit.

To have a moving zone of damage, the weapon/projectile would need to be damaging in rings, whereas normal AoE is just a circle. Hazards are capable of damaging within rings, so projectiles would be capable of making use of the collision detection for damaging in a ring, but this would be an entirely separate concept from what's discussed above. And not only would projectiles need to be able to deal AoE damage in rings, but the game would also need to keep track of how far along the "explosion" has progressed, whereas currently explosions are all single frame events.

The expanding ring you talk about here could certainly be done better alongside other basic shape definitions if/as that type of thing is added, but "emitter" should still be able to duplicate it better than current submunitions shenanigans.

Really does seem like "emitter" handles just about all of these, and "penetration" seems pretty much solved too. :)

[Amazinite]

I got excited enough thinking about the possibilities of this that I went ahead and created a branch with the features I described (even though I wasn't planning on being the one to tackle it): https://github.com/Amazinite/endless-sky/tree/projectile-emission

Using the linked branch, the following outfit is a weapon that deploys "Lances" that track onto targets for 10 seconds before exploding, firing two "Energy Blaster" six times in rapid succession before reloading (i.e. using burst behavior) for a total of 600/10*2 = 300 projectiles emitted over a "Lance's" lifetime. These "Energy Blasters" fire the entire time the "Lance" is alive (i.e. it doesn't wait to actually a target something in range of the "Energy Blasters"). Because of "no collision" these "Lances" will not collide with asteroids or with the ship they are targeting, instead swarming it using missile homing behavior. When the "Lance" runs out its lifetime, it explodes with a blast radius of 200 and a hit force of 2000. Because these are actually missiles, firing with no target (or the target being lost) causes the "Lances" to just fly in a straight line.

outfit "Lance Deployer"
	category "Guns"
	cost 16000
	thumbnail "outfit/unknown"
	"mass" 5
	"outfit space" -5
	"weapon capacity" -5
	"gun ports" -1
	weapon
		sprite "ship/lance"
		"hit effect" "small explosion"
		"die effect" "small explosion"
		"inaccuracy" 3
		"velocity" 6
		"lifetime" 600
		"reload" 120
		"acceleration" 0.1
		"drag" 0.1
		"turn" 3
		"homing" 4
		"infrared tracking" 1
		"radar tracking" 1
		"no collisions"
		"explode on death"
		"blast radius" 200
		"hit force" 2000
		"emit" "Energy Blaster"
			offset -7 -5
		"emit" "Energy Blaster"
			offset 7 -5
		"emitter" 10
		"burst emitter" 5
		"burst emitter count" 6

Creating temporary fighters was the one big idea that got me worked up enough to write this up so quick, but I'm sure there are plenty of other ideas that these three new features could be used for.

[EjoThims]

I keep wanting to play around with this to show examples here of stuff I mentioned, but honestly I'm a bit confused how to install/play from a branch instead of just copying data over, which I don't think will work for this one with the code changes?

[EjoThims]

How about a "sticky" attribute for these?

So that new submunitions are generated from the target ship that was hit by the "sticky" one?