Overview

Project: Master Of None

Estimated Development Time: 50-60 hours

Lines Of Code: 700

Description: The Teamwide Knowledge System is a way of tracking the world relative to what a team has experienced or been exposed to.  

Objectives:

  1. Knowledge is to be shared on a teamwide basis, rather than being NPC specific.
  2. Knowledge won't be absolute but relative to what a team has discovered.
  3. Tracking data needs to be kept light in order to be processed and sorted quickly.

 

Thought Process and Choices

 

Why I chose to use a Teamwide Knowledge System:

The idea of using a knowledge system in Master Of None sprang from the need to have a tangible set of data that reflects the perspective of a NPC. The team aspect both reduces memory/processing and emulates the concept of teammates communicating to each other.

Without having a system in place to handle what is known to a particular NPC or group of NPCs, then most AI typically relies upon what is in their immediate awareness. A second option, would to simply make the AI omniscient from the get-go. Both of which are not a big issue, depending on the game they are implemented within, but if you want an AI capable of planning out their strategies on a level wide scale, then they need to have a semi-realistic view of that level.

This is why everything in Master Of None from the action planning to the level navigation relies upon the information managed within the knowledge system.

 

Risks:

  1. Since a NPC's understanding is not absolute, some choices that AI make may appear illogical to a player. This is more relevant when it comes to observing enemies, due to the fact that they have an entirely different perspective than the player. If they haven't been in a room, they have no idea what could be waiting behind the door, which could lead to the circumstances where an enemy retreats into a far worse situation than they previously been in.
  2. Although most components have been purposefully kept light(low memory cost), it still has the potential to be storing a lot of data.

 

Results:

The Teamwide Knowledge System turned out to be a far more complex network of modules than I had originally designed, placing a lot of importance on the interface that manages this network.

 

Design and Development

A NPC has to be able spot items in the environment or in containers they are searching. This NPC also needs to spots enemies. At first glance, this is what most people would assume is all that goes into a knowledge system. Doesn't sound too bad, right?

Well, there also has to be a way for these NPCs to notice when items are missing, determine if a container has already been searched, keep track if a door is locked, remember if a room has been explored recently, as well as a number of other little details that are often overlooked.

One can get overwhelmed when realizing how much a knowledge system actually has to do. This why I relied heavily upon two aspects to make it more manageable: Teamwide and Room-Based.

 

Room-Based

The concept Room-Based, simply means that the game world/level is viewed as a series of connected rooms. This helps reduce the number of queries and tasks required in a specific quadrant of the map. It is these rooms and connections that help in the case of level navigation. Making it Room-Based also gives us a concrete way of keeping knowledge relative.

For example, Initially when a NPC is considering where the closest health station is, it considers how many rooms away it is, rather than measuring out the path. Maybe in this query of health stations, the NPC also wants to avoid enemies. So instead of generating a navigation path and checking each of the waypoints for enemies within some arbitrary range, the NPC merely has to check the enemy count the team has for each of the rooms along the way. This can be applied in so many different situations, but as you can see, it simplifies the information needing to be processed, and all it is is a way of grouping data.

For the sake of brevity, this next example is only following the NPC's knowledge of items. In all actuality, the state of doors and other details would be tracked at the same time. The image below is the starting condition for a NPC just entering the level. He doesn't know anything about the world, yet, other than the location of rooms.

 

In the next image, the NPC has traveled through room 2 into room 3, where he has discovered two items: a handful of bullets and a medkit.

**Click on the images to increase its size

 

The NPC's awareness and knowledge are two separate systems. Awareness is only what is immediatly apparent to the NPC. When a new item enters its awareness, it is passed onto the knowledge system to see if it already has a reference of that item. If the Item is new, it creates a tracker for it. A tracker is a general description of the object, including its last known location. At the same time, the room component within the knowledge system keep a reference of this tracker to make it easy to compare different areas of the map.

I would also like to point out, that at this time, both the known status(Location, Count, etc..) of the items and their true status are the same. This is not always the case, as seen in the next image.

 

While the NPC was off exploring a different room, something moved the first groups of bullets he found into room 4. However, this is where the concept of relative knowledge comes into play. Since, the NPC did not have view of the item being moved, he(along with his team) still believe the item is in room 3.

Its not until the next image, that the NPC has returned to room 4 to find the bullets missing.

 

When noticed missing, the NPC is asked to due a brief scan over the room for the bullets. If the item is still not found, its tracker is removed from all referencing components("Room Knowledge" in this case), then is deleted all together.

 

After exploring room 4, the group of bullets is found once again. However, its previous tracker has been deleted, so it creates a new tracker and reveals it to all the networked components. Once more aligning known status of the item with its true status.

 

Teamwide

Making knowledge teamwide rather than NPC specific is as much a matter of matching the gameplay as it is a matter of efficiency. In Master Of None, your crew is exploring unknown ships together and it makes sense that they would constantly be relaying information to each other about what they have found or enemies they have spotted.

An example of this is when it comes to noticing missing items in a room. You don't need to constantly be checking for missing items; when a NPC collects something it automatically removes it from its team's knowledge. There is a cooldown of roughly 30 seconds in between checks of a single room by each team. At the same time, it only takes one NPC to check the room for these missing objects, so the knowledge system actually chooses a teammate for the job, while they are in that particular room.