Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[xenoargh]

Basically, three things:

1.  I think that MISSILE / ROCKET / BALLISTIC / BALLISTIC_AS_BEAM / MIRV should all be combined into one group that satisfies the same requirements. 

It's just adding complexity, that we can have AoE on BALLISTIC, but not necessarily on ROCKET; it'd be better and easier to maintain, long-term, to just have one behavior-set. 

For example, a MISSILE is just a guided form of ROCKET; all that differs is inclusion of an AI (could just be a boolean "hasAI" and a pass-through). 

Performance-wise, these sorts of switches in basic behaviors are almost zero-cost.

2.  The visual behaviors need work, too.  BALLISTIC_AS_BEAM has its origin at the WeaponAPI's barrel point; BALLISTIC is offset, backwards no less, by the value of length.  This is non-intuitive stuff; for anything using the core functionality of DamagingProjectileAPI, you'd think that, unless the WeaponAPI specifies RENDER_LOADED_MISSILES, they'd all use the same basic behaviors. 

What I'd like to suggest here, for simplicity, is that new projectiles do a 2-5 frame "accordion", where they start at barrel-origin at nearly zero-length for their quad and then stretch to full size.  This (combined with muzzle-flash) should work well, visually.

I don't think that the additional "glow" features should be mandatory, either.  Most of the time, just one additive quad with a quality texture is all you need to convey a little pew-pew bolt flying around.  There really aren't many situations where using more CPU per frame on the additional stuff is warranted and the savings on VRAM are zero-to-minimal; even if every shot in the game had a unique graphic, we're talking about a teeny amount of memory compared to ships (and this is a priiiiiime area for atlasing, imho).

MISSILE / ROCKET / MIRV get a bunch of custom SFX applied when damaged / dying; these sorts of systems should (imo) be generic and either flag-based (or, better, but more work) directly exposed.

3.  Last, but not least, they're not acting the same in code on the modding end. 

BALLISTIC_AS_BEAM doesn't appear to operate correctly with setDamage(); when read back via getDamage(), the values are really high.  MIRV'd projectiles seem to have similar issues.  If they hit in a normal scenario, they're fine; if they're queried by code, they aren't.

BALLISTIC and BALLISTIC_AS_BEAM operate differently, when it comes to visuals; the way they're "wiped" when they've recorded a hit is different (personally, I think they should all get wiped immediately upon impact; covering that up with fx is better than continuing to let the projectile exist, however tenuously). 

Lastly, BALLISTIC_AS_BEAM implies a two-check-per-frame collision process, but it doesn't appear to be much different in practical outcome from BALLISTIC (and it'd be fairly easy/cheap to use a square-check to find out whether either "where I am this frame" or "where I'll be next frame" will have any intersections with the target's collision circle).

I'm 100% aware these are tiny, nit-picking things compared to the overall design, lol.  That, and I've probably stared at the visuals closely a lot more than most people, while building the stuff in my FX "example" project.