Hi hello hi

Published November 10, 2005
Advertisement
Okay, I seem to be settling back into a bit of a routine of sorts, what with Meghan being in El Paso. [sad] Got a bit more time to start working on my various vaporware projects for awhile, until she comes back anyway. Danged women will get you every time.

Where was I? I don't remember. I seem to vaguely remember something to do with special effects, and the current build of the game features a number of non-moving additively blended particles hanging in mid air in a small cluster, so I am going to assume that I was working on the special effects aspects, and go from there.

Special effects, then... it's always been a bit of a thorn in my side. I have all these ideas (mostly blatantly ripped off from other games of course) for kick-ass lights, bangs and explosions, but I have only the vaguest idea how best to implement an extensible special effects 'engine' if you will, a framework that is flexible and easily extensible and can easily handle chain lightning and meteor drops with equal facility. 3D special effects merely compounds the problem, since there are so vastly many more ways of implementing a given effect. How to generalize any special effect down into a descriptive set of data, and abstract the system such that any given effect can be produced, is where I'm running into problems now.

I can spawn particle clouds with ease; particle effects are no mystery to me. I can do lightning bolts, and flashes, and explosions, and laser beams, and halos, and so on. But tying them all together into a common framework is very frustrating. I reckon this framework will go through as many iterations as the terrain systems have before I am happy with it.

Anyway, I'm back and hopefully I can get back into business.
Previous Entry Werd
Next Entry !
0 likes 3 comments

Comments

evolutional
It ain't the same without you around so much...

As for your effects framework, I have one word "Components". Create a component-based effects system, so each effect has a series of other effects, each of which are components. Your effect component would have extra components to dictate how it's rendered, how it affects the physical world, etc.

Components have either a messaging interface which can be used to generically set and query properties (and also call functions), or even just an integral propertyset which can be iterated over (useful for building a GUI on top of). Your effects components could be proxies for calling scripts (such as Lua or GameMonkey), allowing you to specify and create effects in script.

November 11, 2005 08:12 AM
jollyjeffers
Why try and generalize them down to a SINGLE base? How about 3-4 classes of effect?

1. Material effect (texture blending, complex lighting... but essentially just a material applied to a surface(s))

2. Particle effects (your meteor is just a special case of this - start with ONE particle and on impact spawn many other (dust/debris..))

3. Atmospheric - lightning, maybe flashes in clouds?

etc..

Having a single base (e.g. the D3D FX framework) is nice, but it's not too bad to have 3 or 4 bases - it's when you get 10...50...100 different specialities that it becomes a nightmare to manage [smile]

hth
Jack
November 11, 2005 08:21 AM
FReY
I've had some reasonable success with 'event' based effects.

Basically your effect is comprised of events each of which have a time they start after the effect is activated. You will have various classes of these events eg.
* particle emitter
* sound effect
* lens flare
* game pad rumble
* screen shake
* line trails.
* special callback for special case effects.

It works pretty well in the projects I've worked on and is massively data driven.

December 12, 2005 07:02 AM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement