Dynamic Geometry

Creators: Alexander Bruce
Engine: Unreal Tournament 2004
Modification: UT2K4 Level Component

Last Update: 17th June 2007
Current Status: Working. Mostly hardcoded.
Further Development: Including further configurability to remove hardcoded components.
Download: Not yet available

Description: Reconstructing the world you play in...

Page 4 - Implementation - Recursive interaction

Shooting tiles is great, and having them respond to players running over them is also fun, but compared to the kinds of interactions we could get out of them, these responses are extremely limited. If we want to do more complex things with our tiles, such as cutting holes in walls or getting bridges to form or collapse, they're going to have to know about each other.

Although movers already have a Leader/Follower setup, this is effectively useless to us as it means doing a whole lot of work by hand, none of which is dynamic throughout the game. In addition, we can't use triggers, as these are neither dynamic nor automatic either, and they increase the number of objects we're dealing. As such, we must write our own "Neighbour" system, that would work whether we had 10 tiles or 10,000 tiles, be set up automatically, and dynamic according to any situation.

The solution I came up with was to call a collision check in PostBeginPlay to set up all of the "neighbours" that tiles potentially had. Doing one check for every tile at startup meant the game took a little longer to load, but this was a sacrifice I was willing to take for functionality. Within a small radius, we can do a CollidingActors check and store anything we find within a Neighbours array for the tile itself. Later refinements to this check were made to store specific tiles in specific locations, such that we could reference the North or West tiles specifically.

Once the neighbours have been set up, we no longer have to do any checks at runtime to work out what each tile is connected to, instead just checking whether known neighbours are open or closed. What this means is that if we set the conditions of our tile to open all neighbours when opening itself, we end up with some nice recursion effects as shown below, which we can control completely when more variables are thrown into the mix.

Recursive Interaction to begin with

Recursive Interaction when left running

Now that this is working, we've got a reference from one tile to every other tile in the level, and further interaction just comes down to logic. Unfortunately, because this is how things are implemented, every bit of logic that takes this idea further also has to be conceptualized recursively as well, which can cause a fair bit of frustration if you lose track of what's going on. It's manageable, as I will later demonstrate much more complex uses for it, but it can sometimes be a nightmare to get perfect results.