flareteam
Split Hazard and create ParticleManager, Particle
This isn't a necessary refactor, but one that makes logical sense and is kind of bugging me. I understand of we don't want to change it, but I think the code would be more legible.
Hazards are animations and projectiles that represent harmful obstacles during combat. I made Hazards first, then made "non-hazardous hazards" to reuse the animation code (for effects like Healing or blood splatters).
Really all those animations should be a new object called called Particles. And only some of them might have a Hazard attached. Particles would be all the visual information from Hazard, and Hazard keeps all the combat information. The result of casting a Power should sometimes be a Particle (if there is visual information like the Heal spell or a blood splatter), sometimes a Hazard (If there is combat damage to be done, like an arrow shot or a sword swing), and often both. So maybe there's a list of particles and a separate list of hazards, and we use a pointer to keep track of a connected pair.
Maybe thinking of these animations as Particles will let us see more areas we can add them optionally (e.g. on loot pickup, on level-up). ParticleManager should have an addParticle(type_id, Point location).
Possibly we put Particle data in a mods/modname/powers/particles.txt, and powers can be simplified by saying particle=unique_id instead of mixing all that visual info with combat info in powers.txt. This makes sense if multiple powers share the same particle metadata, we'll know once a Particle class is created.
+1 on this! I think it could add a lot of cool effects if we did this nicely.
One thing that's always bothered me was in the Averguard Keep where there is some text saying something like "The runes on the door begin to glow!" This violates the "show, don't tell" principles of game design. Imagine instead the event triggering glowing particle runes flying around the door. The whole game would feel much more magical with visual events like that.
Other obvious cases like the above:
- The cave-in could have falling rock particles.
- The pillar that's destroyed by explosives could also have falling rock particles.
- Each time a boss is killed, some form of special effect to spice up their death
- Tileset effects (like a torch or special magical treasure chest?)
I agree that this would be really useful. Another use case would be adding these particles to NPCs, solving #781.
If this feature changes the spec for existing data files (e.g.powers.txt gets simplified), we may want this Pre-1.0.
Completely new features are okay, but we don't want to break existing syntax after 1.0 if we can help it. Ideally 1.0 comes with a stable spec that we promise not to break unless it's really really important.
I don't think we'll require a syntax change for this feature. Our goal here is to remove the need for non-hazardous Hazards, and to be able to add Particles to other parts of code (like Events). A Particle is just an animation at a position, so we'd just pass the animation filename we read from powers.txt to addParticle(). We'll also need to support the power attribute visual_random, which may be better done in a separate particles.txt file as mentioned above.
The new system would be backwards-compatible with existing Hazard animations. We could then expand the current power attributes to include post_particle and wall_particle, so we don't need to create a new Hazard there when all we need is an animation.
@clintbellanger I've done some work on creating a ParticleManager, but I don't think it's exactly what you had in mind. You described having things like Hazards being attached to Particles. In my code, Particles are still the things that are attached to their parent objects. This is pretty much how we currently do things. in short, I basically abstracted the animation code that was in these parent objects so that it can potentially be used easily in other objects.
However, we know the existing animation code in each object (Hazard, EffectManager, etc) works. I ran into a few crashes and unexplainable errors while working on the new code (namely with copying EffectManagers in Avatar::untransform()). If my code is too unstable, it may make more sense to try and implement simple animation support in Events and keep the stable code. Events are the primary target for adding Particles anyway, judging by the previously mentioned ideas.
In addition, we could cut down the amount of visual data in power definitions by merging directional, visual_random, and visual_option. When creating Particle definitions, I did just that (see the style key in powers/particles.txt).
If anyone wants to checkout the code, get these two branches: https://github.com/dorkster/flare-engine/tree/particles https://github.com/dorkster/flare-game/tree/particles
Coming back to this. @dorkster do you think what we currently have is good enough for 1.0? Or would you want to merge some of this particle refactoring into the main branch?
@clintbellanger I deleted my branch for this, since it was buggy and not exactly what you described originally. What we have right now works, so I'd be fine with keeping it for 1.0. This refactor can be shifted to being a 2.0 goal.