Crossfire Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CF: Crossfires future.
>From: swedel@Tymnet.COM (Scott Wedel)
>The trouble with that approach is when two expanding events (explosions)
>meet then you now have one event that is expanding in only one direction.
I would argue that you would actually want interaction between the events.
Two overlapping fireballs in real life would actually form an oval or sort
of a dumbbell shape (and damage in the overlap zone might increase, but
wouldn't necessarily double).
However, I'll grant that complex interaction between explosions is probably
beyond the scope of crossfire (and would probably lead to all sorts of
anomalous behavior due to the quantization of space and time)
Assuming the goal is to improve speed but maintain current behavior...
>But you want both events to pass through each other and continue on
>in their direction.
...That's certainly a solveable problem.. I'm not familiar with the guts
of the code, but what happens at the core of the explosion? Special case?
Why not generalize the tracking of the explosion directions so that the
core expands in all directions, and squares with multiple explosions
could then maintain the directions of each..
Hmm, I just realized that you're probably maintaining distance info as
well as direction. Still, a small array (one slot for each direction) with
a linked list of distances (and whatever other info on each explosion that
you need to keep) would, I expect, be much faster than a separately-processed
object for each explosion on each square.
--
John R. Murray murray@indigo2.scri.fsu.edu http://www.scri.fsu.edu/~murray/
FSU Aikido Club/North Florida Aikikai home of Miko's Aikido MPEGs and the
Tallahassee, FL WWW Aikido online calendar of events
-This violation of the CDA has been brought to you as a fucking public service-
-- J. Murray (Supreme Court Communications Decency Act decision coming in June)
[to unsubscribe etc., send mail to crossfire-request@ifi.uio.no]