Keypoint
ScriptAction: I'll cover this one under the Scripting section.

ScriptDispatcher: I never used these, but they appear to have a couple unique scripting properties and are a good way to put a lot of scripting information into one actor icon [Look at the ScriptAction arrays in SailingShip for an example of where I should have used the ScriptDispatchers for the sake of visual cleanliness].

LookTarget: These are a good way to focus the player's attention, as Ragnar will turn his head to look at these, and they take priority over normal look targets like items and enemies. You can turn them on or off by calling the name Tag that you give them.

ActorGenerator: This is the big one, and we used these for many different things ranging from spawning in enemies to spawning in rockfalls, etc. In one case I used an ActorGenerator to spawn in Counters.

There are a lot of options under these guys, so I'm just going to haphazardly tear into it here.

If you go to the ActorGenerators Properties, there are a bunch of options under the category "ActorGenerator".

ActorClass: This is where you put in the name of the actor you want spawned. You do this in the standard Unreal manner of selecting the actor in the Classes menu and then clicking "use" in four ActorClass slots.

ActorProbability: Pretty self-explanatory. Just make sure it's not "zero" or it won't spawn. You can type in any sort of values that you like; if there are more than one, the engine will average them out. So it's the relative scale that matters when weighting out the odds, not the specific numbers used.

bInitiallyActive: if this is left at its default of FALSE, you need to trigger the name of the actorgenerator to set it off.

bMoveWhenUnreachable: This only applies to enemy Pawns when you're spawning them in. By default, Pawns will not roam around the map or hunt Ragnar if he is in an area they can't get to (like a ledge he edge-grabbed to, etc.), and is done for the sake of processor efficiency. If you set this to TRUE, the Actorgenerated Pawns will always try to get to Ragnar, even if they can't. It's a case-by-case thing, but the less you use it, the better your performance will be. [Watch for the "Move" time in the Global stats - if it's skyrocketing, you'd better 'dumb' some enemies down by disabling this]

bRandomPosition: If set to TRUE, the actor(s) will spawn in random locations, based on the ActorGenerator's CollisionHeight and CollisionRadius. [In all cases, the spawned actor(s) take the ActorGenerator's direction.]

bSpawnWithNoShield/bSpawnWithNoWeapon: These pertain to spawning enemy pawns and are self-explanatory.


bTriggerCreations: If this is set to TRUE, then the actorgenerator will "call" the actors immediately after spawning them. We needed this in the case of the rockfalls throughout the game. In those cases, we were ActorGenerating RockLarge, RockHuge, RockMedium, etc. [located under Decorations in the Classes menu], and those actors have special physics code so that they fall naturally, bounce, etc. But they don't do all that nice physics stuff if they aren't Triggered, so in the case of them you need to have bTriggerCreations->TRUE. Probably not too useful for anything else, so the default is FALSE.

DelayAlways/DelayRandom/DelayType: These three work in conjuction for timing when you're ActorGenerating a whole bunch of things at once. DelayAlways is the minimum delay between each spawn, while DelayRandom is a random amount of time that gets added to that. For instance, if the ActorGenerator was set to spawn in 10 crows over time, and DelayAlways was 2 (seconds) while DelayRandom was 3, there would be a minimum of 2 seconds and a maximum of 5 seconds of time between the spawning of each of the 10 crows. DelayType weights this. If DelayType for the 10 crows were set to "Increasing", for instance, the first would spawn with a larger gap (again, between 2 and 5 seconds), and by the end there would be pretty much only 2 seconds between the spawning of the final couple crows.

DirectionWeight/DirectionWeightRandom: setting a DirectionWeight will cause the spawned actor to 'spit out' in the direction of the ActorGenerator's direction arrow. DirectionWeightRandom is a random amount that is added to this when you want variety. We didn't use DirectionWeight much; I found it to be a little quirky, but that was long ago and I don't quite recall.

QuantityAlways/QuantityRandom: If you're just spawning in one enemy, set QuantityAlways to 1 and QuantityRandom to zero. Otherwise, it works along the same lines: If QAlways it 5 and QRandom is 2, you'll get between 5 and 7 of whatever you're spawning in.

SpawnOrders/SpawnAlertOrders/SpawnTriggerOrders: These allow you to spawn in a Pawn with all the Orders functionality that you would have if you'd placed him in the editor. See the "Scripting" section of this document for an explanation of how these three-order types work.

SpawnWithEvent: This works as advertised - it gives whatever you're spawning an event. So if you want the opening of a door triggered by a creature's death, ActorGenerate that creature with the door's Tag as the creature's Event that it spawns with.


SpawnWithHealth: No-brainer. When left at zero you get the creature's default.

SpawnWithTag: This lets you give a specific Tag name to creatures you spawn, therefore allowing you to Order them to do Scripting at some point after they've been spawned.

SpawnWithWeapon/SpawnWithSheild: If left as is, the creature will spawn with its standard weaponry. To put the name of a weapon or shield in these slots, highlight the weapon/shield in the Classes menu and select "use" under the property slot.

SpawnWithHuntDistance: HuntDistance defines how far the creature will roam - it's basically a tethering distance between the creature and the place where it was spawned. But it's got some problems and we made sure that is was disabled for all ActorGenerators in Rune.

So that's the almighty ActorGenerator for you. I'll go into some detail on the process of making convincing rockfalls:

What you want to do is put the four sizes of rock in the four ActorClass slots, and then balance the ActorProbabilities as you'd like (most smaller or medium, most large...?). There are two types of rock, both located under Decoration:

RockHuge/RockLarge/RockMedium/RockSmall: These four will hurt the player (maybe Small and even Medium don't...? not sure), and will bounce off walls and land on the ground. That last phrase sounded idiotically unnecessary, but there's a reason! Because...

RockAvalancheHuge/Large/Medium/Small: These four work the exact same as normal rocks, but they explode whenever they hit any kind of surface. In other words, if you're worried about tons of Rock actors piling up on screen and melting the framerate, use these Avalanche ones because you get all the functionality gameplay-wise but no big actor build-up (though the shard particles are a momentary hit, so use your discretion).

Then it's just a matter of setting up your bRandomPosition area, the total number of rocks, and the timing. And remember that the ActorGenerator is not a one-shot tool - you can keep calling it all day long whenever you want it to spit out your swarm of crows, avalanche, bad guy, or whatever.


SoundPlayer: These are a real godsend and can be made to work in many different ways.

Under their "Sound" Property are the settings for setting up continuous, looping ambient sounds. There's no better example of how to do this well than by looking at the work out sound guy did on our levels when he made his ambient sound passes. By subtly varying pitch and volume of even the same looping sound file and then overlapping the radii of multiple sound players playing it, you can achieve some very realistic environmental effects. Note that just about all actors in Rune can play an ambient sound - even lights have a slot for it now. But for the sake of sanity I'd stick with using SoundPlayers so you get that easily recognizeable icon.

"SoundPlayer" Property: This is where all the good stuff is.

AutoContinuous: If set to FALSE, the SoundPlayer will only play its sounds each time it is triggered. If set to TRUE, the SoundPlayer will continously play the sounds in its sound slots based on their probabilities, the random and minimum delays, etc.

bPlayerSound: If set to FALSE, the sound will emanate from the SoundPlayer's location in the world. If set to TRUE, the sound will play off of Ragnar. This was used for points where theme music or "aha!" music was played, and it means the volume stays consistent as the player moves around.

bRandomPosition: If set to TRUE, the sound(s) will play from a random location within the space defined RndPositionHeight and RndPositionRadius.

RandomDelayMax/Min/RandomPercentPitch/Volume: These tend to pertain to when you want the SoundPlayer to autoContinuously play some environmental sounds. For instance, maybe you have 4 different non-looping animal sounds that you want to play throughout an area. You could give that SoundPlayer a nice big random radius that covers the general area, and set it to bAutoContinuous->TRUE. These 4 properties that we're on to now let you adjust the timing/randomness of those animal sounds' playback. RandomDelayMin and Max define the range of time between each sound being played (chosen by the SoundPlayer from its TSound list and probabilities), whereas RandomPercentPitch and Volume add randomness to the sounds so that they don't always sound identical. In these cases, our sound guy would recommend not going too crazy with the RandomPitch and Volume. The scenario you want to avoid is the sound by chance randomly playing right where the camera is with some crazy 150% volume blasting in the player's speakers.

Aside from playing a looping ambient sound (which, incidentally, all have an "L" at the end of their name in the Sounds menu so you can tell at a glance) through the Sound property and setting up a looping system of non-looping environment sounds, as described in the preceding paragraph, the other major use of SoundPlayers is as a triggerable sound source. In these cases (like playing a theme song when a battle starts or playing an explosion sound during a big scripted crash), you'll want to turn bAutoContinuous to FALSE and muck with these settings:

TSound: This is where you insert the name of a sound file that you have highlighted under the Sounds menu.

TSoundProbability: Here you give the odds of playback if you have multiple sounds you want called randomly.

TSoundPitch: You can change each of the 4 sounds' pitches here. Not that RandomPercentPitch will work its variation off of this number, as it should.

TSoundVolume: Ditto.

To set up the SoundPlayer so that it plays a sound back when triggered, you need to do these things:

TriggerBehavior: Set it to "Single" if you want one sound played each time the SoundPlayer is called. As far as Continuous and ContinuousOnOff are concerned, I can't vouch that they work as advertised, but the idea is this: if it's set to "Continuous", then once the SoundPlayer is called it'll start cranking out sounds from the TSound slots all day long, with frequency based on the RandomMin and Max. If it's set to "ContinuousOnOff", it'll do this as well but will turn silent again if the SoundPlayer gets triggered a second time.

SelectMode: Let's say you're planning on calling the SoundPlayer multiple times, and you have more than one sound in the TSound slots. If SelectMode is set to "Cycle", you'll get the same order of sounds each time, starting with whatever's in slot "0" the first time it's called. If SelectMode is set to "Random", you'll get a random sound based on the probabilities you set up.

TriggerCountdown: If this is left to its default of zero, you can just keep calling the SoundPlayer again and again all day and you'll get a sound played back every time. But if you put a value in here, the SoundPlayer will effectively disable itself after that many calls. So if it's set 3, the fourth and subsequent times you call the SoundPlayer you won't hear jack.

[ Click here for printable version ]