This is the third post mortem posting on my #SYNTYGameJam contribution, The Clipper Kids. Read the second part here.

Part 2: The Systems (2)

Interaction

The interaction system isn't too complicated and if you have ever worked with Game Creator or any comparable toolkit before, you will be very familiar with how it works and you can skip the next paragraph. For everyone else, I'll quickly explain the overall concept.

The idea is that interactions are "enabled" whenever the player enters a certain area around the interactable object. Just like the rooms described in the last chapter, this happens through a collider which is configured to act as a trigger. Once it's triggered by "player enter", two other objects are enabled: 1. an interaction icon, indicating that the player can do something here; 2. another trigger which executes the actual interaction upon keypress. Now the player can either move on and exit the trigger area, which disables both of these objects again. Or they can use the interaction button (key E in my case) and execute the interaction actions.

(While writing this it occurs to me that I never looked into what happens if I switch players while the active one has activated an interaction – that's probably another bug I'll have to fix.)

The most prominent interaction objects in The Clipper Kids are the searchable items like this suitcase:

Originally I hadn't planned to have this "glow spot", but since there was so much which could potentially be examined, I decided to make the players' lives a little easier.

Again, I created a prefab and here's how the entire hierarchy looks like:

When used in the game scene, I simply added the actual object prefab as a child of the "ObjectHolder" and repositioned the glow a little, if necessary. Then I filled the local variables (see bottom of inspector on the right side) depending on the object. Most of the objects received a standard "nothing found" action in the "search_result_action" variable, which is executed after the search animation. The three bomb items got their own "BombXFound" action instead.

There's a bit more involved, for example, if an "owner" is configured, I regularly check if the owner is within the "checking_distance" during the search. If yes, they call the player out, the search is aborted, and the "warned" field is either set; or, if already warned, the player gets detained, using the "detain_action" which is also passed into the prefab.

My personal highlight of this whole thing is the hourglass animation, for two reasons. It's a very pragmatic approach and it's good use of more Synty assets. I simply modified an existing paper scribble from the Kids pack.

As you can see, there are several UI image game objects in the hierarchy above. I never did any serious 2D development with Unity so I had no idea how to create or animate a sprite sheet. All my sprites are individual images and materials right now. So I decided to fake an animation by enabling one image after another using a long list of Game Creator actions "Set object active" and "Wait".

I am not unhappy with how it turned out in the game!

Behaviour Trees

Or behavior, if you prefer. I am using them to steer the NPCs in the game, and here's a specific example for staff members:

Just like other prefabs, behaviour trees live outside the scene and anything scene related has to be passed in as parameters at runtime. That's what's happening in the "blackboard" on the left side. All of these are references to GO's in the scene with Game Creator actions.

• The "work_actions" is what should be executed while the staff member is following their regular schedule. For example, the cook in the galley simply moves back and forth between two configured waypoints.
• The "detain_action" is what should be executed if one or multiple kids are caught. It's the same that's used above in the "searchable object" prefab.
• The "cancel_action" is what should happen if a running "work action" needs to be cancelled because the NPC has spotted the player.
• The "look_at_action" is what should happen if the NPC should look at the player. I added this later when I noticed that just rotating the invoker of the behaviour isn't always enough, e.g. in case of the captain where the entire chair needs to rotate.

Now this simple tree executes three different tasks in parallel:

• Task (1) gathers players in the same room AND in sight of the NPC. I wrote my own Action for that, because it was easier to combine my own room system and the perception system from Game Creator's behaviour module that way. The result is stored in a "list variable" that every NPC has.
• Task (2) has a condition: it is only executed if this "list variable" is empty, i.e. no player is in the same room and visible to the NPC. In that case, the "work_actions" are executed.
• Task (3) has the opposite condition: it is executed if the "list variable" is not empty. In that case, the "work_actions" are cancelled by calling the "cancel_action" and the NPC is forced to look at the player and shout some warnings before the detected players are eventually detained. To make this work, I created different entry points into the detain logic: one for each kid, and then another one which looks into the invoker's "list variable" and checks if either kid is an element in the list and calls the corresponding individual detain action.

To be continued

I guess that's it about the most important systems in the game. I've already created a list of known bugs, so next up are possible next steps. I've got some ideas!