Type 2 Digital Being V1 Architecture
Continuing from previous post, we describe Type 2 Digital Being's architecture.
What is Type 2?
Type 2 is 2nd iteration of Digital Being. In Type 1, we created "entity.json" and textures containing various animation of that character. Type 1 is empty vessel. Unless user provides input (i.e. left, right, jump), it does not move.
In Type 2, we add agency and expand the state whole lots (breath, run, walk, pickup, eat, etc.). Simplified version of state machine (let call it SM1) that mimics body behavior is implemented, and simulated. State machine is mostly dumb set of rules that stochastically controls the body and its state.
To add agency, SM1 prompts the LLM (let's call it TM1 for "thinking machine") with predefined set of tools. Then LLM responds with tool calls to set medium/high level goals for the character at that point in time.
SM1 interacts with Body Module (let's call it BM1) and updates its state as needed.
Body Module
Body Module (aka BM1) is greatly simplified version of the humanoid body.
It has 5 submodules:
brainheartlungmusclestomach
Each of these submodules have common local variables:
nutrients: nutrients available to use.oxygen: oxygen available to use.metabolicRate: rate at which we are consuming.fatigue: high when there is prolonged usage.health: the health of the submodule.stress: current stress.
These submodules are dumb container of the local variables. Imagine a mere POJO. They are there to encapsulate local variables. They themselves don't do any action.
And at global level, we have:
heartRatebioTimer
Assume heartRate is fixed at this time. We will variate it once we have a need later.
Assume bioTimer is just increasing tick that loops around at the end of the day.
The body module also tracks.
hunger: This is derived from level of nutrients in different parts of the body. This is a driver for food seeking actions.fatigue: This is derived from weighted average of submodule'sfatigue. This is a driver for rest-related actions.
This concludes the setup for Type 2 V1. We are not going to model fight-or-flight here.
We start with the "gut" of the being. The digestive track. That's all our being will have.
Environment Modeling
World is flat 2D side-scrolling platformer world.
Food spawns from the ground at random locations.
The agent's goal is to stay alive so, it will have to:
look for food.
approach food.
grab it.
eat it.
To stabilize the system, we will make it so that food that is not used will disappear after certain period of time.
Perception
At every tick. The character will survey the current map. And produce the following map.
##########################
######### ######
##### ######
### ######
## ######
## ######
## F S######
##GGGGGGGGGGGGGGGGGG######
##GGGGGGGGGGGGGGGGGG######
where F is food, S is self and G is ground.
The issue with this design is that LLMs are terrible at telling character counts. So, following description may be better suited:
{
"lookingAt": "left",
"visionRange": 10,
"itemsInSight": [{
"kind": "food",
"name": "apple",
"id": "apple-1",
"dy": 0,
"dx": -6
}]
}
Then when this information is passed to the agent, it can suggest proper tool calls.
Interaction Model
We will need a interface between BM1, SM1 and TM1.
BM1 provides encapsulation but exposes variables.
SM1 is able to look at those exposed variables.
BM1 runs on its own tick.
Blood circulation is simulated. This moves nutrients and oxygen to various parts of the body.
Fatigue build up is simulated in the body itself.
SM1 runs on its own tick.
It has readonly access to the exposed body variables.
For example, it can read
hungervariable.SM1 can either make the decision by itself to seek food
Or ask the TM1 for advice. Let's assume that we always ask TM1 with perceived inputs.
It can then call BM1's methods to alter the state.
- For instance, when character eats an apple, it will call
addNutrient(...). The body will add nutrients to the stomach node then ongoing simulation will circulate it.
- For instance, when character eats an apple, it will call
TM1 receives the prompt, and responds with tool calls.
"You are controlling a digital organism in blah blah setting. Use tools."
Then provide them with current perceived variables and vision information.
TM1 responds with tool call to
fetch(id:"apple-1").
SM1 receives
gather(id:"apple-1")with a timeout.It runs its pre-programmed program to gather it.
It writes a log of what happens line by line.
Then if the goal is achieved, it responds.
If timeout happens, it will respond with failure and updated current state.
More advanced version of this can be implemented but for now this should do.
TM1 receives timeout or failure then it tries to handle it by providing different action and so on. Or give up.
- If it receives success, TM1 determines if any additional action is necessary. If not the current mini-session is done. and it responds with "OVER" signal which ends the transaction. If further action is needed, it does another tool call.
SM1 receives "OVER" and closes its mini-session until next tick.
Thinking Machine
TM1 has a context window to remember the history of actions. It works as a short term memory of sort.
It is mini-reinforcement learning setup where the TM1 can try out some operations to gauge the capabilities then fine-tune its behavior live.
Terminal State
If the being is not able to eat before it reaches state where it is not able to give enough fuel to mind and heart, it enters self-preservation state at which the character is "frozen" until nutrients/oxygen is externally provided
Suppression Mechanism
If digital being eats too much, it will need a mechanism to suppress the eating behavior. I'm not sure what would be it but if hunger is 0, the TM1 should be wise enough to not eat anymore even though there is food in front of you.
Let's stop here today. Next week, we should build the body module.
-- Sprited Dev 🐛
