Blog for Gary Haussmann at GarageGames.com

More AI Pack Trigger Examples

Gary Haussmann — 2006-03-24T14:51:59+00:00

Here is a short set of examples from the "test" mission I'm using to debug and try out the various triggers for use in the "AI Pack" I'm working on with Phil and Dee. In case you haven't read my previous blog entries:

1. This stuff isn't AI at all, but will hopefully make the real AI code easier to use, by allowing you to synchronize the AI to specific events in the game.
2. The expectation is that you can get maybe 80% of the common FPS interactivity done without writing script code, although you may have to edit or copy/add datablocks.
3. No, I don't know when the AI pack will be ready.

OK, so the scenario is your typical fantasy setup, where you need to bind some evil demon dude (or whatever) and then shoot him with exploding crossbow bolts. In this scenario you simply need to light two torches and the evil dude will appear, at which point you kill him. Yay.

So first we slap some triggers at the "front" door to the castle you must enter. The overall effect here is that:

1. When you approach the door, you get a message telling you how to open it.
2. When you operate the door, the two parts of the door slide open.

How this is done: when you enter the volume near the door, the AIVolumeTrigger senses your proximity and sets off an AIEnvironmentEffect trigger. The AIEnvironmentEffect does all the various special effects; in this case, it sends an informative message to you explaining how to open the door (hit 'f').

If you hit 'f' you basically try to set off all AIOperableTrigger objects by sending a message to them. If you are close enough to the AIOperableTrigger and are on the correct team, the AIOperableTrigger will go off. In this case, the AIOperableTrigger fires two AIMovableShapeTrigger objects, which do nothing more than move a TSShape around. Thus the moving TSShapes provide for the "sliding door" effect.

Next we need to "bind" the evil dude. All that is required is to light two torches, simply by running up to them and operating them (the 'f' key again).

How this is done: really all we have is the AIOperableTrigger again, hooked up to an AIEnvironmentalEffect that creates a particle emitter. Not too exciting. However, we also hook up to an AIMultiSourceTrigger, which takes multiple triggers as input and goes off when all the inputs have fired, producing the final effect...

After both torches have been lit, the multisource goes off, creating the evil dude and using an AIEnvironmentalEffect to generate some chat text. Super scary!

Finally, I had this extra screenshot showing some triggers in the editor. The setup shown in the screenshot below is a chest that, when destroyed, explodes and spawns multiple orcs. This is done using the AIDestructableShapeTrigger. I expect the AIDestructableShapeTrigger will be used to make hundreds, nay thousands of destructable crates.

So anyway, that's the current state of the triggers. I need to clean up fields for each trigger object and work on the way trigger names are resolved. Currently, each trigger has to have a globally unique name, which is a little annoying if you need to copy/paste a dozen sliding doors. The plan is to require trigger names to be unique only within a simgroup, so that by grouping triggers appropriately you can re-use the same names over and over. Then there will be more integration with the rest of the AI pack, primarily with dynamically building different AI brains when characters spawn and enabling triggers to send messages to AI entities.

A real simple AI pack example

Gary Haussmann — 2006-02-10T23:11:59+00:00

If you've read some of Phil's posts about his AI Pack, one of the key concepts he mentions in
this post is that a person should be able to setup a lot of situations by simply placing a few objects and setting a few data fields. They should not be required to hack up a bunch of script functions and C++ code, although scripting may be required for a funky or unusual type of AI behavior. In this vein, I've been getting the basic triggers to work and itegrating them into the editor for (hopefully) easy use.

Here I present the simplest possible example, and the one that will probably be used in many places: if the player enters a specific area, NPC baddies spawn. Again, you should be able to do this without writing up additional script code or modifying script files.

So we start by slapping down two trigger objects. One is the volume trigger, that goes off when it is entered, exited, or occupied. Here we have the volume trigger "spawntest" setup right on top of the firepit, which will activate its target "spawnhere" when entered.

The second trigger objects is "spawnhere" which will spawn AIPlayers. When triggered, "spawnhere" will spawn three AI NPCs with a interval of 5 seconds between each spawn, indicated by the "MaxActivation" and "TriggerDelay" fields. You can also see other fields like "monsterType" and "brainFactory" which let you select which AIPlayer datablock and AIBrain to use.

After you enter the volume trigger, the spawner will spew forth three AI DefaultMonsters. At this point the spawner has hit its max activation and so no more orcs will spawn.

Lets say the spawner didn't work quite right and you wanted to tweak the timing or activation values. If we wanted to be annoying we could force you to save and restart the mission to try out your new settings, but luckily there is a reset button in the AI menu that will reset the triggers. After resetting you can walk on the firepit and three more DefaultMonsters will spawn.

So there you can see that the most basic triggers are working. There are a lot of bits that need polishing; for example, some sort of visual animation or feedback indicating when a trigger goes off would be extremely helpful methinks. But at this point I figured I had enough screenshots to justify a blog post :P

An Approach to Making Random Dungeons

Gary Haussmann — 2006-01-02T21:56:50+00:00

I'm a big fan of the old dungeon crawl games (like Nethack) that auto-generated random dungeons and populated them with monsters. So over the holiday break I attempted to make a reasonable generator that would take torque interiors and assemble them in a mission file to approximate the old-school dungeon setup. The initial results were surprisingly easy to produce, but there are many little details to iron out.

Step 1: Make a bunch of modular interiors representing parts of the dungeon. This includes things like hallways, small rooms, and stairs/ramps. Each part will correspond to a single tile in my autogenerated maze, and has to be a standard size and have openings/doors at the right spot. This way all the parts will fit together so that, for instance, the west door of room #323 will match up with the hallway opening of hallway part #193. The screenshot shows a simple part representing a hallway turn.

Step 2: Generate the maze. Here I just have a python script generate a simple maze, like the kind you would have done in an undergraduate algorithms class. The script then tries to match up interiors to appropriate tiles. For instance, a tile with openings to the west and east would correspond to a straight hallway, or perhaps a room with two doors on opposing walls.

The screenshot shows a text dump of the results: The walls of the maze are the "#" characters and tiles are filled with different letters to indicate which DIF structure was placed there. It's only for debugging, so it doesn't really have to make a lot of sense...

Step 3: Generate a mission file containing all the interiors at the proper position and orientation. Load mission. Profit! Here is an example dungeon made up of a 5 x 5 x 2 region of tiles. Yeah, it's three-dimensional, so there are two floors; the ramps are kind of a problem. You can also see some "missing" parts, since I haven't made enough interiors to cover all the possible tile configurations. If the script can't find an interior that matches up to a given tile in the maze, that tile is just left as empty space.

And here is a debugging shot that clearly shows the parts that make up the "Dungeon"

It's not really that easy, though. Slapping dozens of interiors all in one spot is a good way to drag down your FPS, so I'm thinking heavy use of LOD will be needed here. The other main problem is lighting, which stems from my use of portals. The portals block off sunlight from reaching the inside of each part, but since I can't stick the portal at the very edge of each interior, the edges of each part will get lit up. Here you can clearly see the joints between dungeon parts since they are lit up by the sunlight leaking in. Also, lights placed in one DIF won't illuminate other DIF, so the light in a specific room won't bleed out into the adjacent hallways.

Luckily, Universal Static Lights (USL) from the lighting pack can help a lot. The main advantage here is that USL's will illuminate multiple interiors seamlessly, so it's much less obvious where the joints go. In the previous shot, the green illumination is from a USL. Currently I've just turned off the sun altogether and rely on USL's, although if anyone can suggest better methods I could use here I would greatly appreciate it. Here's the same mission file with only USL's in it.

Finally, note that you can make bigger and more complex structures as long as they fit into the tile system. Here is a bigger room which occupies a 2x2 tile region on the map.

Anyway, a nice little diversion over the holidays. I still need to make some more structures (and better ones) but the siren's call of Real Work is wafting to my ears...

Monday Oct 31 23:13

Gary Haussmann — 2005-10-31T23:13:51+00:00

Yet another AI-related post

With all the AI-related posts in the last month, I figured I should throw this up. I figured it was time to make my AI navigation a little better than the "head straight for the target" method used by AIPlayer. I originally tried a dynamic reactive system, where the AIplayer would shoot out several rays each tick and run around walls, but that eats up a lot of processor cycles and only works for simple obstacles. So of course I had to switch to using precomputed navigation graphs and A* code...

I wanted to avoid having to place waypoints manually so my method is very similar to that of other navigation methods you've seen in GG plans, such as Justin Mette's navmesh code. In my setup the level designer slaps down a single node somewhere, typically in the center of the mission area or at a spawn point. The generator will then try to find all the places that are reachable from that point, basically by doing simple "can I walk from here to here?" queries over and over again between nearby points. The drawback is that places you can't get to by walking are not examined, so elevators and teleporters will screw it up. For simple levels it seems to work quite well, though. The mesh node spacing is smaller in areas near interiors while it is quite coarse in the big open terrain areas.

Of course, on top of this navigation graph is the A* algorithm. If no path is found using A* the move behavior falls back on the "go straight at the target" method. It needs some polish, like an actual priority queue in the open list and perhaps some path smoothing, but it is loads better than the previous garbage I had written. Now I just need to write up some code that figures out when to properly recompute the path from start to destination.

Monday Sep 26 3:44

Gary Haussmann — 2005-09-26T03:44:21+00:00

Finishing up the FPS side: inventory, item combining, and quad-wield.

For those who just tuned in, I am pretty much meandering around the torque engine to see how far I can get implementing a FPS/RTS where the two genres are represented by opposing sides, the "humans" (FPS) and the "aliens" (RTS). The HL mod Natural Selection is an analogous game, although the building of structures is conspicuously absent from my game.

It's been a while since I posted my last plan, mainly because I had to go back and redo a lot of scripts doing the basic mechanics, like mounting weapons, spawning/respawning, and the overall inventory system. But the basic mechanics for the FPS team (humans) are complete at this point. Hopefully I can get enough bits working on the RTS side (aliens) to make for an interesting demo at IGC.

To start with, the human player chooses their overall class and also chooses from a set of abilities/enhancements to their avatar. The abilities function similar to "advantages" or "perks" available in many RPGs, and provide a bit of customization to your player.

Once the player spawns, they also get another customization opportunity, by modifying weapons. Scattered around the map are various resources which represent technological parts useful for modifying your weapons. The player can pick these up and they are stashed in the inventory. Here we see the player has picked up some "steel" and "fire" resources, represented by the spheres with colorful icons on them. You can see a bunch of other resources scattered on the ground, currently represented by my colorful programmer-art lozenges.

Using these resources the player can modify his/her weapons; by combining a standard weapon with a specific type of resource, the player can produce a new type of weapon. Here we see the player has combined the Blunderbuss Pistol with the Fire Resource, producing a Flamethrower weapon (the orange pistol-like thing). Any player can produce enhanced weapons, and one class (the Mad Scientist) will be able to create all sorts of wacky equipment on-the-fly.

Finally, here is a gratuitous shot of my steam-powered robot automaton wielding four weapons at once. The robot is pretty much a walking arsenal but is really slow, which makes him a prime target for artillery...

Monday Mar 7 18:54

Gary Haussmann — 2005-03-07T18:54:02+00:00

On implementing ShapeBase decorators, or, how to poison things and set them on fire.

While waiting for the Illumina guys to test out my helicopter-vehicle changes, I decided to fix up some parts of my little prototype game, which is a sort of RTS/FPS with whatever RPG-like aspects I think are cool.

The major gameplay mechanics that I wanted to add are special attacks and player customization. In typical CRPGs there are typically a large variety of special abilites you can get, either through items, race/class combinations, or spells. You can also effects the abilites of others, through what are typically called "buffs/debuffs".

At first I thought about coming up with a big list of buffs and debuffs, and coding them all into the engine. Then I came to my senses :) By coding up the the Decorator Pattern, and making the gameplay effects available to torquescript, I can basically come up with all sorts of bizarre and cool player abilites and attack effects.

Basically the Decorator-which I called an "Aura" for some reason, perhaps my melodramatic side-is a GameBase object that binds itself to a ShapeBase object in the game, be it a player, vehicle, or any other ShapeBase. The Aura does a few things:

1. Draws a particle effect and/or a shape at the player's location.
2. Calls a script function every N milliseconds.
3. The ShapeBase object will query any auras attached to it, giving each aura an opportunity to modify attributes like size and run speed. The aura can also modify any damage the ShapeBase is about to take.
4. Finally, a special Gui control displays all the auras currently attached to the player, and lets the player 'activate' auras. This allows you to dynamically add player abilites that require activation (i.e., sprinting, jetpacks, shields).

Again, the actual attribute and damage modifications are all done in script, although the engine code has to interpret them. For instance, if a certain aura reduces your run speed, the engine code has to be changed to use the modified run speed instead of the default specified in the datablock. Besides that, you can do all sorts of crazy things. Let us take a look:

Here the human player has just BBQ'd a bunch of alien critters with the handy flamethrower resource. Whenever a critter is hit by the flamethrower projectile, there is a chance that a "BurningAura" gets attached to them, which draws the fire particles and applies additional fire damage. The white spider-web like bands around the human player is a ShieldAura, which basically reduces damage.

From the point-of-view of the human player, you can see a few interesting things. First, the critter on the far right is a LOT bigger than the rest, due to a "GrowthAura" that increases size, movement, and attack damage. Second, the icon bar along the bottom shows which auras are currently on the player. The blue trapezoid is my bad art representing the ShieldAura described previously. The brain icon represents a mindblast ability which, when activated, will temporarily slow enemies in the vicinity. You can also see the critter in the back left is poisoned, as indicated by the big cloud of green smoke.

That's it for now; with some tweaks I can pretty much go crazy and start adding in the long list of abilites/effects I have written down in my design doc. Thanks to my neighbor Eric Porter for the cool mindblast icon. Eric also made a poison icon as well. I might hit him up for some more graphics assets later :)

Sunday Jan 30 6:38

Gary Haussmann — 2005-01-30T06:38:11+00:00

As mentioned in my previous plan I am attempting to pit small groups of creatures, controlled with an RTS style point-and-click interface, against the traditional FPS controlled guy with guns. The big problem I saw when starting this was that using the normal AIPlayer to control each creature led them to behave in a rather robotic and uninteresting manner. So I tried to make some AI that was still relatively simple, yet provide for more creature-like behavior.

So I started by giving each creature the ability to hold a set of simple short-term goals, like "attack this guy" or "move to this location". The code figures out which short-term goal currently has the highest priority (based on proximity of enemies, etc.) and does some movement or shooting or whatever to try and satisfy that goal. When all the goals are satisfied, the creature stands around stupidly, although it will still react to approaching enemies. In this picture, the critters are standing around my pimped-up car, having just killed me in it a few seconds ago.

The icon above their heads tells me what current short-term goal they are trying to accomplish. This was for debugging, but I'll probably leave it visible to the controlling player. Other players and enemies won't be able to see the creatures current goal.

For movement, instead of making a beeline to their goal or using full navmesh, each creature basically does a guided random walk. Each tick the creature looks at a random nearby point to see if that point is evaluated as better than its current location. For moving, points closer to the goal point are evaluated higher; for attacking, points within the optimal weapon range to the target are evaluated as better. The net result is a sort of wandering path that accomplishes the task, but looks a little chaotic and less robotic than just moving in pure straight lines.

Here we see a small pack proceeding toward their destination. You can see from the footprints that each critter has made a different zig-zagging path to reach their goal. This makes critter movement more interesting, and also makes them a lot harder to hit.

What next? I need a few more short-term goals (avoid, get item) and then will write up some script functions for the higher-level behaviors like patrol, guard, ambush, etc. And then I have to do some game design to figure out what sort of weapons and abilites to distribute among the critters and humans.