Gunship-X -- Effects systems
by Daniel Eden · 09/04/2008 (12:59 am) · 10 comments
I don't normally bother blogging but given the slackers in #garagegames still haven't unbanned me after my ISP had conniptions...
I've been doing a bit of work on my game of late -- some gameplay and physics stuff here and there but mainly I've been writing some new effects systems. I basically got sick and tired of Torque's stock particles and effects and yanked them all, then wrote my own.
While doing so, I've decided to avoid datablock-based effect information altogether. It's just silly to be sending all the effect data from server to client each load. Especially when the bulk of the data is only ever used on the client anyway.
Instead of datablocks, I've opted to use XML configuration files. Torque handles these internally as a specialized form of resource object (which allows them to be compressed and streamed from the server to clients that lack them when the client loads in). Effect resources can require CRCing or not -- enabling you to set up the game so that only gameplay-affecting effects match on the client and server and that all other effects can be "skinned" on the client-side.
Now, before anyone gets too bored, here's an obligatory youtube movie showing the new effects system in action. It's a short clip and it's largely programmer art, so don't get too excited.
Looks like the youtube embedding breaks when it encounters an underscore in the id tag. I'll post the url.
www.youtube.com/watch?v=AzQQ5mU_7YU&fmt=8
... and an older movie which has a tag without an underscore in it.
I'm still fiddling with the tags and system values and so on, and there are a bunch of extra affectors, emitters, and initializers I want to write, but all up it's very nice to use. Here's a little example
Anyways, more as I think of it...
I've been doing a bit of work on my game of late -- some gameplay and physics stuff here and there but mainly I've been writing some new effects systems. I basically got sick and tired of Torque's stock particles and effects and yanked them all, then wrote my own.
While doing so, I've decided to avoid datablock-based effect information altogether. It's just silly to be sending all the effect data from server to client each load. Especially when the bulk of the data is only ever used on the client anyway.
Instead of datablocks, I've opted to use XML configuration files. Torque handles these internally as a specialized form of resource object (which allows them to be compressed and streamed from the server to clients that lack them when the client loads in). Effect resources can require CRCing or not -- enabling you to set up the game so that only gameplay-affecting effects match on the client and server and that all other effects can be "skinned" on the client-side.
Now, before anyone gets too bored, here's an obligatory youtube movie showing the new effects system in action. It's a short clip and it's largely programmer art, so don't get too excited.
Looks like the youtube embedding breaks when it encounters an underscore in the id tag. I'll post the url.
www.youtube.com/watch?v=AzQQ5mU_7YU&fmt=8
... and an older movie which has a tag without an underscore in it.
I'm still fiddling with the tags and system values and so on, and there are a bunch of extra affectors, emitters, and initializers I want to write, but all up it's very nice to use. Here's a little example
<?xml version="1.0" encoding="UTF-8"?>
<!-- CountermeasureLauncher.Countermeasure.particle -->
<!-- Smoke particle -->
<particle sort = "true" uniform = "true">
<affector>
<colour>
<key value = "254 189 72 51" time = "0.0" />
<key value = "254 189 72 26" time = "0.3" />
<key value = "230 230 230 26" time = "0.75" />
<key value = "255 255 255 0" time = "1.0" />
</colour>
<force z = "0.5" />
<size type = "replace">
<key height = "1.0" time = "0.0" width = "1.0" />
<key height = "2.0" time = "0.75" width = "2.0" />
<key height = "4.0" time = "1.0" width = "4.0" />
</size>
</affector>
<emitter>
<point rate = "80" rate_variation = "20" />
</emitter>
<initializer>
<lifetime value = "3500" />
<rotation variation = "180" />
<normal theta_variation = "45" />
<velocity inherited = "0.2" value = "1" variation = "0.5" />
<width value = "1.0"/>
</initializer>
<source type = "texture" filename = "~/Textures/Particle/PARTICLE_Default.png">
<material alpha = "true" />
</source>
</particle>
<!-- Spark particle -->
<particle sort = "true" uniform = "true">
<affector>
<colour>
<key value = "255 255 128 153" time = "0.0" />
<key value = "255 255 51 255" time = "0.25" />
<key value = "255 128 0 0" time = "1.0" />
</colour>
<size type = "replace">
<key height = "0.2" time = "0.0" width = "0.2" />
<key height = "0.3" time = "0.25" width = "0.3" />
<key height = "0.5" time = "1.0" width = "0.5" />
</size>
</affector>
<emitter>
<point rate = "10" />
</emitter>
<initializer>
<lifetime value = "300" variation = "150" />
<normal theta_variation = "180" />
<velocity inherited = "0.2" value = "1.0" variation = "1.0" />
<width unique = "true" value = "1.0" variation = "0" />
</initializer>
<source type = "texture" filename = "./CountermeasureLauncher.Spark.png">
<material alpha = "true" />
</source>
</particle>Anyways, more as I think of it...
About the author
#2
09/04/2008 (3:02 am)
Some really nice effects you have going on there - looking great.
#3
I know this is a blog about particles but I can't help but mention how superb your flyer looks with the rotating fans - Great stuff!
09/04/2008 (3:59 am)
Awesome work! I love the laser targeting in the older video and some lovely particle effects going on in the new one.I know this is a blog about particles but I can't help but mention how superb your flyer looks with the rotating fans - Great stuff!
#4
09/04/2008 (5:37 am)
Wow looks great, have you done improvements to the flight physics also ? Looks very smooth
#5
09/04/2008 (6:47 am)
Looks great these efects!! :)
#6
@Daniel - So you avoided datablocks... any more specific reason why other than networking? You can use datablocks on the client side by the way... just create them using 'new' instead of 'datablock' in the client scripts and use Sim::findObject( "mydatablockname" ) to look it up in your client side C++ code.
09/04/2008 (8:06 am)
Looks great!@Daniel - So you avoided datablocks... any more specific reason why other than networking? You can use datablocks on the client side by the way... just create them using 'new' instead of 'datablock' in the client scripts and use Sim::findObject( "mydatablockname" ) to look it up in your client side C++ code.
#7
09/04/2008 (8:47 am)
Nice! Love that laser...
#8
09/04/2008 (9:05 am)
Wicked FX! Looks like a lot of fun!
#9
A _lot_ of my engine has been re-written. Everything from SceneObject upwards and a lot of low level stuff like the math libraries and so on is pretty much new code. So, given those aren't stock Torque vehicles, I guess you could say there have been improvements to the flight model.
@Tom Spillman
Yeah, I know you can use client-side datablocks, I'm using them for a lot of sound stuff. My main reasons for using the XML are the reduced networking requirements and easier validation of client effects on the server. I initially considered using client-side scripts to generate the effects, but... Well, I'm trying to make my code more portable (the effects systems doesn't rely on any Torque-native code -- it just plugs into it), and I wasn't happy with the idea of having the effect values accessible from the console or having to implement a separate system to keep track of which effects exist where -- and stream them to where they're missing.
Thanks for the positive feedback guys. Though I really need to get some proper artists involved at some point. Programmer art is killing me. =)
09/04/2008 (4:49 pm)
@Ian RoachA _lot_ of my engine has been re-written. Everything from SceneObject upwards and a lot of low level stuff like the math libraries and so on is pretty much new code. So, given those aren't stock Torque vehicles, I guess you could say there have been improvements to the flight model.
@Tom Spillman
Yeah, I know you can use client-side datablocks, I'm using them for a lot of sound stuff. My main reasons for using the XML are the reduced networking requirements and easier validation of client effects on the server. I initially considered using client-side scripts to generate the effects, but... Well, I'm trying to make my code more portable (the effects systems doesn't rely on any Torque-native code -- it just plugs into it), and I wasn't happy with the idea of having the effect values accessible from the console or having to implement a separate system to keep track of which effects exist where -- and stream them to where they're missing.
Thanks for the positive feedback guys. Though I really need to get some proper artists involved at some point. Programmer art is killing me. =)
#10
Hah! I soooo feel your pain!
The particle effect results are very nice. Totally agree with not having to spew all the effect information from server to client. For now I'm still using stock particles myself, but I'm pretty sure at some point I'll have to do something much more specialized. I need to spend some more time looking at custom resources like you did for the XML stuff. I have a couple of data candidates that could benefit from being resources.
09/05/2008 (11:07 am)
Quote:Thanks for the positive feedback guys. Though I really need to get some proper artists involved at some point. Programmer art is killing me. =)
Hah! I soooo feel your pain!
The particle effect results are very nice. Totally agree with not having to spew all the effect information from server to client. For now I'm still using stock particles myself, but I'm pretty sure at some point I'll have to do something much more specialized. I need to spend some more time looking at custom resources like you did for the XML stuff. I have a couple of data candidates that could benefit from being resources.

Torque Owner Taylor Petrick