.comment-link {margin-left:.6em;}
Moriash Moreau: My Second Life
Monday, August 14, 2006
Flash, Bang
Earlier this evening, I added one last small bit of special-effects to the GoD. This is something of a red-letter event for me, because it means I've completed the last scripted portion of the Garage of DOOM. The game is now functionally complete. From here on out, it's just cosmetic tweaking and playtesting. Pardon me while I do a little happy dance in my chair...

...Okay, I'm back. As you can see in the picture below, I added a simple muzzle flash effect to the Monster Gun. Nothing too spectacular, but it does add a bit of realism (or at least verisimilitude). The invisible bang was kind of jarring.

I opted for an animated texture instead of a particle effect, mostly because I already use particle effects for creature damage. I didn't want to exceed the client particle counts during pitched skirmishes. That being said, the texture was definitely the way to go. It's handy to be able to control the effect reliably, without trusting to the vagaries of sim performance.

And I learned a little something from even this. Originally, I'd used a collection of six intersecting prim panes (up, down, left, right, front, and rear facings) to create the effect. (I'm sure you've seen variants of this method for making 2-dimensional images look 3-dimensional if you've ever looked closely at a player-made tree.) This was so that I could use the same image for all of the side facings. The image flipped the wrong way around on half the facings if I pasted it on both sides of the prim and animated it. Texture animation overrides texture flipping and angle settings. Additionally, I had the gun activate a single cycle of the animation (thus calling for a full update to be communicated to the sim) for each shot.

That worked just fine, until I started looking at the sim stats. Performing full updates on the parameters of 6 different prims at the rate of fire of the automatic rifle (10 rounds per second) actually had a noticeable impact on the sim. It was small, but in the worst case it sometimes showed up on the dilation readings (0.01 to 0.02 seconds or so) when I cut loose with an extended spray of gunfire with two or three test guns at once. That was a bit of a surprise, initially, but they were calling for 60 updates a second, each!

Dismaying. I take some pride in the minimal impact the game has had on sim performance. I've promised myself that I'd take out anything that proved to cause a notable effect on sim performance. I've already dumped a couple of monster ideas for this reason. And the Rover is on the watch list now, due to the number of physical collisions it generates. (Too bad. It's one of my favorites.) And now this minor effect proved to be the straw that broke the server's back.

Fortunately, I was able to rescue it. First, I trimmed the muzzle flash prim count down to three by making a second, flipped muzzle flash texture. Yes, it's another texture that must be loaded into the client cache, but I think halving the number of prim updates per second is more than worth an extra one-time texture download!

Second, I changed the way the animations are run. When in blunderbuss mode, the gun only fires one shot per second. Three prim (horizontal, vertical, front-back) updates per second is much more acceptable. (That'd be an advantage to a particle effect: only one object - the emitter prim - needs to be updated to activate it. But the trade off is more client-side lag, in addition to the particle count issues mentioned above.) So I stuck with the same trigger-the-animation-each-shot method.

However, the automatic rifle was another issue. I ended up having to go with a looped animation effect in that case. (More experienced weapons designers are probably saying, "Well, duh!" to their screens now.) Now, the first shot turns on the animation loop, which times out a little over a tenth of a second later. Each subsequent shot resets the animation kill timer, effectively keeping the animation running (and the prims un-altered- animated textures only require updates when they're changed) until the player stops shooting. Thus, the three muzzle flash prims only have to update twice per burst: once at the start and once at the end. And since most players tend to use their Monster Guns like firehoses, these updates are generally spread well apart.

This seems to work pretty well, all told. The sim load is no longer noticeable. (And, oh, how I wish some of my neighbors would do similar tests on their sim-squelching scripts. My sim ecology self-righteousness is little comfort when the time dilation dips to 0.3 every two minutes.) The flash timing tends to drift a bit in long bursts, sometimes even to the point of flashing an extra time after the trigger is released. But, given the rate of fire and the other activity during the game (you know, the business of monster killing and not dying), I'd bet I'm the only one who ever notices, and even that is only when I'm not actually playing. I can live with that.

And now, I'll leave you with a lovely little sentiment from a neon sign in Chamonix. Sleep well.

Addendum, 8/18/06:
After some observation, it appears that the system lag I've been seeing in Louise for the past couple weeks has always been coincident with large spikes in Image Frame time (spikes up to a couple hundred milliseconds). So, after all the work, it's quite possible the gun tests just happened to fall on a period of high lag from other sources. Vexing, but I suppose efficiency is its own reward, even if it's not strictly required to fix an apparent problem.

I spoke with Live Help regarding the spikes in sim lag, the image frame time, and the resultant time dilation issues. Turns out there's an ongoing gridwide problem (which the Linden I spoke to was maddeningly vague about), which is being looked into as we speak (spoke). So I might have misjudged my neighbors. We'll see.

Comments: Post a Comment

Return to Main Page