D2R – Riot Control 3

Spawn Point System – Overview

Nodes used to control this script…

Spawn_point_script – what you see below
Spawn_name_vstore – the value store for character group control
Spawn_random_vstore – the value store to do the selection

Figure 1

This state machine controls all of the spawning of characters within the Riot Control level.
Every character within the rounds, and then the sub-groups within the rounds make a request to this state machine to ask to game spawn.
Using this system, it means that you do not have to duplicate the spawning process on every individual character that you want to bring into the world. All updates go into this one script which is a much more centralised system which seriously reduces the workload on the design department.

Spawn System – Breakdown

Part 1

Figure 2

See Figure_2 This is the first stage of the spawning system. The blue state block is just the starting position for the state machine.
2nd is a blank state block. It is useful for any state machine to have a blank state at the beginning of each script as this will help you debug problems that occur further down the line in development. If a script is run via fuse-wire, and nothing is being called of this script, the logic will sit inside this state and wait before moving on.
3rd block. This is a condition state that is waiting for a spawn request to come in. A spawn request originates from a character that resides within a round script. When his group is called to be brought into the game, he will send out a spawn request to the spawn value store which is referenced here on this condition block.
The 4th state block will be picking what spawn point to use. It does this by randomly picking a value from the Spawn_random_vstore. This is the important bit. Using the action farandomisevaluestore you set the number to the amount of spawn points you are using in the level, (Danvers Island Riot control had 15 spawn points) so you tell it to pick a number between 1 and 15. See Figure 3 Then the last setting in this action is shuffle. Setting this to true means that it will not pick the same spawn point twice in a row. Doing this means that it will distribute the spawning characters about the map and reduce the chances of the player spawn camping and killing enemies before they have a chance to get into the play area.

Figure 3

Part 2

Figure 4

In part 1, we are checking for a spawn request, and then randomly selecting a spawn point. Now in part 2, we decide what to do with the spawn point the character has chosen. Highlighted in figure 4 is the first test for what spawn to use, then it runs the actions of that spawn point.
These two blocks are repeated another 14 times to cover all of the 15 spawn points that are in use. Basically it asks”is my value at 1?” if so use this spawn point. If not, it then feeds off of the NO on the condition to ask the next question “is my value at 2?” etc… all the way down to 15.
The way it deals with the last NO in the last condition is that it feeds back up into the state block that will randomise the spawn point value store again. Technically it is not required since it can only get to the number 15 if it is not any of the previous numbers, and it can only be 15. But just to close up all of the loops within the system I have feed it back into itself to re-select another spawn point to use.

Figure 5

Now, the state block deals with the use of the spawn point.
Using the action usevaluestorenodename we call on the sub action of this action to bring a character from the specified group into the world. This uses a lot of sub state machines and that will be covered elsewhere. All you need to know at the moment in this document is that you have requested a spawn point, it has randomly picked one for you and now it has given the character a specific spawn point to use. It works this way for all of the subsequent spawn points so I don’t need to repeat this for all of them.

Part 3

Figure 6

This is the final stage of the spawning system. Once it has picked the spawn point and spawned the character the state machine needs to feed back into itself so it is ready for the next spawn request.
In the very top state block in figure 6 we call the modifyvaluestore action. What this does is that it resets the spawn_request_vstore by reducing its value by -1. Then it feeds back into the “has a spawn request come in” condition ready and waiting for the next spawn request.

What is nice about this system is that it will queue up the spawn requests and process them one by one, chipping away at the value of the spawn_request_vstore each time it spawns someone until the value is back to zero and it can come to a rest, ready for the next time its asked to pick a spawn point for a character.

So, to round this up…