HELPEE APP
This application aims to make assistance for disabled individuals to be more accessible by connecting volunteers and professionals with them through the Helpee app.
HELPEE APP
This application aims to make assistance for disabled individuals to be more accessible by connecting volunteers and professionals with them through the Helpee app.
HELPEE APP
Work Process
Firstly the team figure out the problem that we wanted to target and simplified it into a problem statement. Using that we were able to figure out the User Goal and solution.
With the solution, we have our target audience then, we were able to generate a few features we wanted to have in our application. Then we created the initial flowchart and personas to assist with our designing process. Extra research was done for competition as well as possible expansion for our app.
Work Process
NG YU LUN
Key Takeaways
Project Maxbuzza is a technical project done for a duration of 12 weeks. In this project, the player are supposed to guide a pack of dogs through an unknown realm where the dogs will face challenges and temptations. In this project I had to design and create:
-
Dynamic Ai Behaviour - Actors that have unique and consistent behaviour that are identifiable to that instance of the actor.
-
Modular Ai - Writing modular scripts that can be easily plugged in/out to create new unique actor types.
-
Pack Behaviour - A behaviour that allows actors to acknowledge each other and affect one another as long as they are part of a pack.
-
Consequential Actions - Actions affecting all other actor, such as collateral damage from fights or consequences affecting biases of actors within the area.
First Iteration
The inception of the Ai system, used a state machine with a conditional reasoner.
Examples:
Pros
A state machine and conditional reasoner, was my first knee-jerk reaction when I decided to work on this project.
It gave me relatively okay organisation of my states and a lot of control of when and how these states happen.
-
Had full control of the Actor’s behaviour and 5W1H of actions.
Cons
The Actors were very predictable and robotic, this was not a very good sign for a dynamic project. However, I did believe with time and precise polishing of the conditions I could pull a dynamic behaviour.
Which was the second con, it takes a lot of time to create a good Actor behaviour with this method, not just due to the polishing required for each unique case but also due to the number of nested conditions used for each state and action.
-
Too predictable/ robotic.
-
Take too much time to make a unique Actor’s behaviour
-
Too difficult to change due to amount of nested conditions required to make sure states and actions are done correctly.
Second Iteration
Using Modular AI with a Weight-based reasoner.
Examples:
Weight-based reasoner diagram:
Pros
With the use of Modular AI, this iteration of the project made making unique Actors easy, each action I wanted the actor to have could be recycled to another actor.
The world states allowed me to identify the reason why weighs are added in easily. I could add weights and states to consider without creating a bunch of nested conditions from before.
The weight-based AI chose the best-suited action for each situation the Actor was in, actors would act differently based on their health, items they were hold, and environment.
-
Easy to change.
-
Very Organised.
-
Understandable.
-
Not as predictable.
Cons
Compared to the first iteration, this iteration felt less predictable, however, the actors still felt robotic.
In most situation, every actor would pick the same action and do the same thing, making the actor look unnatural which was bad for a pack simulator.
-
Still too predictable.
-
Still had some nested conditions.
Third Iteration
Using Modular AI with a Utility-based reasoner.
Examples:
Utility-based reasoner diagram:
Pros
Utility-based AI allowed me to promote all the states to be on the same level. This method allowed me to take away all the conditional ifs from the actions and allowed utility AI to handle all the decisions.
The increased randomness allowed my actors to perform more naturally as though they were real creatures existing in the wildness.
-
Much more natural behaviour due to the randomness.
-
Simpler graph.
-
Reduced complexity of code.
Cons
In this iteration, though I was able to achieve organic behaviour from my actors, I lost the pack aspect of the project as each actor despite knowing they are a part of a pack will react differently, like running away, attacking, or ignoring.
Secondly, players were not engaged with the project, it did not feel good to watch a pack of actors doing their thing and waiting for something to happen.
-
Natural behaviour made the actor look like it did not belong in a pack.
-
Player were not engaged with lack of interactability.
Final Iteration
Using Modular AI with a Weight-based + Conditional + Utility-based reasoner.
Thoughts
I also realised that the problem faced before in my AI-System could be fixed by using a combination of all three methods that were used before a specific parts of the decision phase in order to get a natural but yet have a level of predictability for the players.
This means that I will nest reasoners into actions.
Examples:
Level 1 - Weights
Level 1 of the state graph is where the designer implements new behaviours into the actors.
I used weights for level 1 due to the ease of implementing new behaviours. Weights allow me to avoid nested conditionals which tangles up behaviours and forces you to write the same code again in a different way.
Level 2 - Conditionals
At level 2, a conditional reasoner was added into the action after being selected in level 1. For example, once a dog has decided it is curious, it has to choose an appropriate response to an item where it likes it or not.
A conditional reasoner is usually used when there is a Boolean decision to be made. This keeps things simple and the nested conditionals at a minimum.
A conditional gives a lot of control to the designer, making this decision very predictable when it happens, thus, I usually avoid using this reasoner when it is at the lowest level.
Level 3 - Utility
Level 3 is the lowest level of a decision, it determines the way the actor would respond to the situation.
Using utility here, allows me to create a natural/ random-ish response with biases based on the dog’s personality. With the earlier levels being very definitive, it sort of classifies the action in level 3 to be an appropriate response. Thus, using utility provides variety to the player so that they would not see robotic behaviours.
Brief Anatomy of An Actor
Personality
Creating personality of each dog allowed for dynamic behaviour to happen:
-
Created biases, using items and a memory system, dogs were able to remember things that they like and dislike and react appropriately. For example, if a dog has experience with fire, it would be actively avoided when seen. On the other hand, a dog who has no experience would not and fearlessly play with the fire until it gets bored or hurt.
-
Using stats, as a way to affect their level of curiosity, playfulness, and aggression. Dogs who are more curious would choose to discover items instead of fight. Stats are also used in decision-making to affect the likelihood of certain actions. It is also used to affect sub-stats such as health, damage, vision range, and success rates.
Item System
Items are also categorized, so that when a positive reaction happens, all items under the same category are given a positive affinity as well.
The items are important as they serve as one of the two decisions the dogs have to make, actor or item, to display their personality.
Memory System
Unlike the visual memory the sensor has, the memory system in the actors can be viewed as long-term memory.
-
When a dog is happy with the objects, and other dogs see it, they will remember that the item is good.
-
When a dog has a strong dislike for something, he would choose to avoid it or bark at it.
This system not only allowed for consistent and varied personalities, and it also can be used for the benefit of the player, if the player is having trouble leading his pack, he could use this system to help the dogs avoid hazards or pick up items that the player wants.
Stat System
The stat system used a simple multiplier modifier to:
-
Increase or decrease the base sub-stats of a dog.
-
Affect successful interaction rates.
-
Affect decision-making and weights of a dog.
Dynamic Personality
Even though the systems were quite simple, as they begin to intertwine the results were exponential. The systems were able to create “new” or in-between personalities as dogs would appear with varying stats and biases.
For example, a smart dog (High int) would choose to tinker with items over fighting enemies. However, when a dog has both high int and low dex, meaning this dog is smart and not playful, he would become an obedient dog. This happens because the low dex, makes the dog unable to see, meaning it would not be distracted and would often obey the player’s commands.
On the other hand, a dog with high int, dex, and str, would be a dog that is constantly distracted with items or fighting.
Post-Mortem
What I learnt while working on this project?
-
Working at the right level.
-
Choosing the right level of control while designing the AI. Using the appropriate procedural technique, conditional, weights, utility at the right time, and purpose to achieve a proper and efficient workflow
-
Choosing the right level to add variables/ applying systems. Originally, I chose to keep the stat systems contained only affecting sub-stats, when I decided to apply it to items and decision-making, the actors start behaving more consistently and had more purpose in their actions.
- Choosing the right level of modularity in modular programming was pivotal to how I was able to make these many huge iterations within 12 weeks.
-
-
Embracing my failures, often I would face large roadblocks and stay stuck at an undesirable state for my project, at those times, I found it best to keep going by show my work to people and hearing the painful feedbacks, which motivated to keep going.
-
Filtering feedback and verifying doubts. At each step of this project, I had a long list of doubts that grew everyday, most time I choose to ignore them until I receive feedback confirming them. This is because, if I had not, I would find myself procrastinating and doubting my every action.
-
Staying true to my design. With all the doubts and feedbacks, I have received, it would have been difficult to know what feedback to use and not, that’s when I would go back to the experience I wanted my project to give to my players and use it as a guide to keep my project going where I wanted it to be.
What went wrong?
-
The original plan for the game. The plan for the AI behaviours. Working on my projects, I realized none of the plans I had would work, so I had to stay flexible and constantly refactor code and redesigning my systems to get the results I wanted.
What went right?
-
Everything that went wrong. If I could redo this project, I would still have done it in the same way as I did now, each iteration was an important step for my understanding of modular AI & coding as well as the design methodologies.
Files
Check out the full iteration process!