Our team is currently working on a game titled Lil Tribals. It's a community management game based around resource management and social interactions. The primary mechanics involve basic gathering, hunting, and building, while the advanced mechanics are more social focused.
For this week, I was tasked with completing a technical prototype based on previous paper prototypes our team had developed.
Managing Basic Systems and Definitions
To handle the basic overarching systems, I created a GameDef asset along with def classes for characters, resources, foods, and structures. The GameDef asset is then insert into a Manager script in the scene to act as a global reference.
The reason why I chose to create a GameDef, is so that values can be easily adjust from the GameDef asset, while also having an easy way of fetching prefabs and def values at runtime. Each def uses its own enum to distinguish it within the list. For example, CharacterDefs has the character types: Villager, and Boar.
An example of this is when gathering resources. GameObjects with the ResourceProducer script use a ResourceType enum to determine which resource it should produce. When producing, it references the Manager's GameDef to check its ResourceType against the list of different Resources, and fetches the prefab to instantiate from the matching ResourceDef.
Regioned Grid Nodes
Because our game features AI and building, it's important that our game has an optimize grid system. The grid nodes would be used for AI pathfinding, as well as placing structures in the world. While the AI's pathfinding is not yet implemented, the grid system able to be used for placing structures.
Because the game's world space is relatively large, I needed to optimize the node search function by breaking the grid up into smaller grid regions. To do this, I created a PFRegion script that generates nodes (and regions) and a PathFind script that generates regions with defined sizes and depth. The depth determines if the regions should generate nodes, or generate more regions within itself. The higher the depth, the higher the potential for optimized searching. By breaking the grid up into regions, instead of looping through each node in the world, the method instead loops through each region and checks if the desired position is within the region. If the position is within the region, it will then loop through that region's nodes to find the exact node at the desired position, thus reducing the search checks from hundreds or thousands to roughly a few dozen checks.
Role Based AI
The AI being developed is primarily goal oriented. It will have humanistic factors, such as relationships and needs, but will be structured using role behaviours. Standard roles include hunting and building, which tells the NPC the steps required to complete the specified goal. We will be adding other less conventional roles, such as fighting or recovering, as we flesh out the social aspects of the game.
All characters of the same type have the same functionality, meaning that everything NPCs can do, the player is capable of too. However, the player character will be controlled by a Player script, while the NPCs will be controlled by AI scripts. Though this decision is not finalized, the intention is to have the NPCs feel as close to being other players as possible. Currently the AI is capable of hunting and building, but will need to be developed further.
FSM Dialogue System
Because the game features a heavy social focus, the dialogue system will need to be robust enough to handle branching dialogue and events. We have ideas of using dialogue "tokens" to define different speech patterns for general responses, but that has not yet been developed. Currently, I have taken advantage of Unity's FSM to build a state-based dialogue system.
When entering a conversation, both characters will be triggered to go into a conversing mode. When the player is conversing, their controls will change, allowing them to interact with the dialogue. By creating the Animator parameters "continue" and "choice", the player is able to navigate the branching dialogue through inputs.
Each state contains a DialogueState or DialogueStateEvent script. The DialogueState script allows developers to write in dialogue, choose which of the two characters are speaking, and a list of responses. When creating transitions in the FSM, they can be marked with the "continue" and "choice" conditions to await input and navigate based on response choices. The DialogueStateEvent scripts are used for calling methods upon entering or leaving a state. For example, the game uses a DialogueStateEvent for assigning roles through dialogue.
The majority of systems described are still WIPs and will be reworked or refactored to increase development productivity. However, the basis on these systems act as a good reference for our game's technical design.
Next I will be working on cleaning up these systems, followed by focusing in on the social aspects, AI, and dialogue complexities.