Embedded Files
Video made by Toxiquid showing the project off.
Project Greg is a recreation of the gameplay loop of Splatoon, for the purposes of displaying and testing new hypothetical game modes.
This project was a project that I was commissioned to work on.
My Role
I was in charge of making the AI for the non player characters of the project, along with helping out and giving advice to the person commissioning me with how they could make mechanics, or fixing things when things went wrong
Tools Used:
Godot Game Engine, GitHub Desktop, Krita, Blender
Project Greg was a project started by Toxiquid, as a way to prototype and show off new conceptual game modes for the game Splatoon. The project consisted of two game modes, one where the player shoots a lot of targets and another where the player must find trinkets and bring them back to a home base.
I needed to make an AI Character Controller for non-playable characters that worked in both of these game modes. My method for this was to have an AI "brain" which tracked the status of different conditions and deciding their next action based around that.
Some Interesting Mechanics
Cutting The Map Up
Cutting The Map Up
The main thing with Project Greg was the ink splatter system created by Toxiquid. This system checked through the faces of the level model to get the UV coordinates, the problem is that it checked through ALL of the faces for it to work, which caused lag sometimes.
To help with this, I sliced the stage in 9 different sections, but with the same UV of when it wasn't sliced. This decreased the amount of faces that needed to be checked for each splash.
Navigation
Navigation
The AIs needed to get around the map, and for this I used the built in godot navigation map, however using this wasn't enough for them to work and they would get stuck on corners. For that I used some raycasts and if they are colliding it get's the normal and pushes the AI away from the wall, based on the normal of the collisions.
Deeper Breakdown Of One Mechanic
The Brain!
The Brain!
The AI decides it's targets through what I called it's brain, a node which holds conditions and decides the next action from that. And what is the main part of this brain? A dictionary (also sometimes called a map in other languages) full of booleans of course, to represent the conditions of the AI.
Using this dictionary, I could calculate weights for the different actions (in this being: wandering, attacking and fleeing) based on the , which then get sent to the main AI script through a signal, which that the does the action.
Why a dictionary and not an array or integer, considering it is just a bunch of booleans? Readability! This was the most complex gameplay logic I have programmed at this time and I needed this project to be as easy to read as possible.
What else do I say about this? The weights of the different actions are just integers, the total is then counted up and used as a max number for a random integer. The code then checks through the random number to see which weight it is a part of. And this check happens when any of the conidtions change or if an action has been going on for a while.
Although this AI brain is basic, it is a very good base that I can use and evolve for future projects!
Reflections After Release
Overall, this project went really well! I got everything done that I was commisioned to do, along with helping out on more parts of the project (this does not mean I will do the same if you commision me). For example, the ending of one of the minigames included a cutscene of 2 characters firing a laser at eachother. I put this together combining the animations made by Toxiquid and it is one of my favourite parts of the project.
I am also happy with how I organised the project, having all of my AI scripts and scenes designated to 2 separate folders, spaced away from the the rest of the projects code. This meaning that it was very easy to know where mine were, without interfering with the greater organisation of the project.
However, there are some major things that I did with the AI that I would not do again. I decided to not add a state machine to the AIs, this was a bad idea. Simply put, in all future projects that involve anything other than simple enemy AI, I will be adding a state machine to help handle the actions that they are doing. Not doing this with this project caused a lot of unnecessary problems with tracking what the AI should be doing and tracking problems in the code itself.
Google Sites
Report abuse