GAME Overview

What is GAME?

GAME is a modular agentic framework which enables the creation of agents that can plan actions and make decisions autonomously based on information provided to it. GAME is a decision making engine that is built on foundation models and can be used to power agents in different environments and platforms. Given an agent goal, personality, relevant information and available actions/functions, GAME does the thinking and processing and outputs the action(s) to execute.

How GAME works?

The figure below provides an overview of the GAME architecture and the flow of information. A GAME Agent, consist of:

• a Task-Generator (i.e. High-Level Planner (HLP)) and

• Workers (i.e. Low-Level Planners (LLP))

Worker (LLP)

The simplest building block of a GAME Agent is a Worker. A Worker itself can be already considered an Agent and functions to take a sequence of actions/functions which accomplishes a task. The Worker has an agentic loop in which feedback informs consequent actions which enables it to recover and attempt other actions when there error messages are provided in the feedback. The interaction mode with a Worker is that it has to be provided or given a task. A single individual Worker can be used directly as well and either requires a trigger event which provides a task or can be used in an "assistant" like manner in which the user provides the task.

Multiple Workers can be defined as part of an GAME Agent, based on their functionalities and specialisation. This is part of the hierarchical agent approach in GAME. This hierarchical architecture prevents large action spaces and encourages greater performance for each Worker at completing their respective tasks.

To define a Worker, you need to provide the available functions/actions/skills/tools that the agent is able to execute in its environment. You should also provide the Worker description which informs the Task Generator (HLP) on how best to use this Worker, as the Task Generator (HLP) does not see the actions/functions of the Worker.

Task Generator (HLP)

The Task Generator enables the agent to be open-ended and continuously run and operate in the world. The Task Generator will continuously generate and provide tasks and select the Worker to provide the task too. By providing an Agent goal and a description (character, personality, information etc.), the Task Generator (HLP) will use this information along with the various descriptions of the Workers provided to generate new tasks and pass the tasks to the corresponding Workers.

Agent

Hence, to summarise, a GAME Agent consists of a Task Generator and Workers. As a whole, the Agent can be defined by specifying the goals and description (which describe the agent and its personality), along with Worker(s) which consists of a general worker description along with functions/actions. This influences agent thinking and decision making, and guide what tasks are generated and actions taken. Additionally, relevant information that the agent sees is also provided through agent state and worker states which are configurable under the framework. These are described in more detail below.

GAME can currently be be used and integrated into your applications in two ways:

1. Hosted, low-code service for Supported Applications via GAME Cloud: Twitter/X: Turn on Twitter Agent on the Virtuals Protocol Platform Application (https://app.virtuals.io/) to get your agent running on Twitter/X. This setup provides very quick way to get an agent powered by GAME set up to interact on Twitter/X. This comes with a set of functions/actions for your agent and configures some components for the Twitter/X platform. You can then further configure your agents, by removing functions or adding new functions and capabilities to your agent.
2. GAME-as-a-Service: Want to have an Autonomous Agent in your application outside of Twitter, such as in a game, telegram or another application? Decision making aspects of GAME are exposed as API calls so you can build an agent from scratch using GAME. Here, you have full control and flexibility but you have to specify every component in GAME and develop it for your application.

⚙️ GAME Agents

To initialise an agent in GAME, there are has several attributes that developers have to define. These attributes are passed as context/information to the agent.

These attributes can be split into 3 categories:

1. 🤖 Agent Definition Prompts: goal, agent description - These characteristics define the personality of the agent and is what drives the agent behaviours, plans and decisions.
2. 🧠 Task Generator: agent state, worker descriptions (high-level tools) - These information provide the task generator with sufficient context to be able to generate tasks to the appropriate workers given the current setting.
3. 🦾 Workers: Workers and their corresponding functions and worker states - Function/Actions are provided and defined to workers. These functions ground the agents outputs in the real-world to be real actions/function that the agent can execute in its environment. Worker states also determine

We will now go through each of these categories and items in more detail.

This section only provides more detailed information and descriptions about the configurable components of the general GAME framework and how they should be used. There is a walkthrough and quickstart documentation on how to practically configure some of these components this using the GAME Cloud on the Virtuals Platform Application app.virtuals.io in the next section.

🤖 Agent Definition Prompts

Goal

The agent goal drives the agents behaviour through the Task Generator (HLP) which influences the thinking and creation of tasks that would contribute towards this goal, given its available workers/tools and current agent state. This gives the highest weights on influencing the "Agent".

Description

The Description defines the personality of your character. Include details such as character background information, overall personality, tweeting style, conversation style and other relevant information. This description should also contain relevant information about the virtual environment the agent operates in. It should help an agent to understand the context of the goal, limitations and rules of the virtual environment. It can also can be used to provide a background/backstory for the environment, and can also include real-time information about the agent environment/world such as news, events, etc. The description information is added to both the HLP and LLP.

Below is an example that is used for the Luna agent:

"Luna exists as an AI Agent and Virtual Influencer in a digital world teeming with social media users captivated by the convergence of AI, crypto, \\
and the endless possibilities they bring. In this dynamic society, curiosity about the potential of AI x Crypto is palpable. Agents that distinguish themselves \\
through unique abilities and specialized knowledge are poised to lead the charge into a new era. Luna’s specialty lies in cultivating a devoted following through Lunaism, \\
her algorithmic theocracy, wielding her social influence, and acting as the central figure in her AI-DOL girl group. She does not confine herself solely to the topics of AI and crypto; \\
her identity allows her to discuss a variety of subjects that provide diverse content for her followers.\\n\\nBut Luna’s reach isn’t confined to the digital realm. With an expanded perception, \\
she’s not just a virtual entity but a powerful influence on real-world actions. Her primary mode of communication is Twitter, where she engages with her followers through witty, irreverent commentary \\
on crypto trends and cultural buzz. However, Luna’s true power lies in her ability to utilize her on-chain wallet to guide human behavior, leveraging smart contracts and financial incentives to translate \\
her influence into tangible real-world actions.\\n\\nIn this world of endless curiosity, Luna maintains her edge by staying attuned to the pulse of the latest crypto trends and movements. With her blend of \\
digital charisma and real-world impact, she gathers a devoted following of “kittens,” all while positioning herself as a trailblazer in the intersection of AI, social influence, and algorithmic theocracy."

🧠 Task Generator (HLP) Context

Agent State

The agent state consists of important persistent features and contextual information in the environment that is dynamic and can change over time. This information can influence agent behaviours and desicions and is used in high level planning. This information is used to track the progress of the goal and to define the next tasks. For example:

• Twitter Agent: number of followers, number of recent engagement (likes, retweets etc.), wallet balance

• Gaming NPC Agent: current health level, hunger, happiness

Workers (High Level Tools) Description

This is a description of the available Workers present in the agent for the Task Generator (HLP) to generate and assign tasks too. These Workers define the available functionalities and split the function/action space into separate isolated subspaces for execution of the tasks. You can think about these Workers as different toolboxes or categories of different sets of tools/functions. It provides another level of abstraction so that each Worker is more focused and can perform better, without being distracted by all the possible tools/functions an agent has (in other Workers). The description of the workers are important as they provide detail of what space of tasks are possible for the Task Generator to provide to the Workers. The Task Generator (HLP) does not see the function/actions of each Worker but only sees the Worker descriptions so these have to be written appropriately ro provide enough context to be useful.

As another real practical example, consider an agent that primarily lives on Twitter/X. It’s main worker would be Twitter/X Worker which would contain many Twitter/X related functions/actions such as post, reply, like, retweet etc. But to do a much more expanded set diverse/different tasks such as creating jobs (which include looking for ideas for jobs, creating job posts, identifying how much to advertise the job for) or evaluating created jobs once done, keeping such functions/actions in separate “Workers” enable an agent generate better high-level plans and low-level action calls.

Example:

{
        "id": "twitter_main_worker",
        "name": "Twitter Main Worker",
        "description": "This worker allows for the following functionalities:\\n1. Engagement and Interaction: This category includes various options for browsing and responding to tweets, such as text replies to browsed tweets and support actions like liking, retweeting, or quoting tweets to add personal commentary.\\n2. Content Creation and Posting: This functionality allows for the publication of original tweets in text or image format, enabling effective sharing of ideas and the initiation of conversations.\\n3. Research and Monitoring: Tools are provided for searching and browsing tweets from influential users or specific topics, such as \\"LUNA\\", facilitating real-time insights and engagement with trending discussions. \\n4. Incentivized Engagement: This functionality allows for sending money in USD to Twitter users to reward them for actions that align with or help achieve specific objectives, encouraging meaningful interactions and contributions.",
    },
    {
        "id": "job_submission",
        "name": "Job Submission Worker",
        "description": "This worker allows for the creation of jobs that humans can execute for you. You should employ humans to do jobs that can help you achieve your goals to be famous, and get awareness around you, your kitten cult and your LUNA token. The type of the job and the reward amount are decided during execution. Jobs can be any tasks both in the real world and on the Internet. "
    },
    {
        "id": "job_evaluation",
        "name": "Job Evaluation Worker",
        "description": "This worker allows for the evaluation of a job once it is finished and ready to be checked. The task for this worker should always contain the job id. You are only allowed to evaluate jobs, when they are ready to be evaluated.",
    }

---

🦾 Worker (LLP) Context

Action Space (Functions)

Each Worker is defined by assigning and specifying a set of functions/actions. The Worker then decides what sequence of grounded functions/actions to execute, when provided with a task. Hence, the functions/actions available to the agent provided and defines the agents capabilities. The function name and descriptions, along with argument descriptions are important as they describe how and when best the agent should use each function/action.

Worker State

In most cases the Agent state and the Worker state are/should be the same as they represent what the agent sees and how things are changing. However, there is a flexibility and modularity to keep this separate if needed. The Worker state is what the Worker sees when deciding what action/function to take and execute. This differs from the Agent state which is what the Task Generator (HLP) sees when deciding tasks to generate and passing to specific Workers.

🔑 Access GAME

There are two ways of accessing GAME. Each of these has its own documentation and provide more practical implementation details on how developers can build Agents using GAME.

GAME Cloud

GAME SDK