T3.1.1 · AI-driven Game Platform Prototype

What the ADGP actually is

Not a container. A living body.

An AI-driven Game Platform will be prototyped to disrupt the traditional knowledge acquisition pattern. Online Training in Game Platform Operation and the Platform Manual lead to a Joint Methodology for operating the Game Platform, which will become the permanent educational source for AI experimentation, as stated in the proposal.

The Joint Methodology for operating the Game Platform is a crucial concept requiring visualization. Imagine yourself as an architect leading a team, creating a story, plot, gameplay, and endless AI interactions; it's a vast project. You connect and manage various interfaces and software components integrated into the ADGP for your game. One single person doing it all, no way.

Another important concept is: the ADGP has coded a series of interactions that you can use; one example is the virtual avatar (we name it Seekers, because our game prototype is about seeking the truth), which can give you information that is pre-defined but at the same time can talk to you; and you can talk to him/her, which is very powerful. These conversations between virtual and real can't be managed; in short, we can't guess what you, as a real player, will say when playing the game, but we can learn afterward, when the game is completed, what the conversation was about and extract data and conclusions about the quality of your game design and content. The quality of your game is not only based on the features coded; if the story has no traction, your game will not be played, but the experience of critical thinking in game creation is your benefit.

The REBOOT AI-driven Platform (ADGP) is not a video game platform concept; it is beyond. It is an educational game platform with two main objectives: 1. You understand how to create games, including all the UX/UI elements, and how to use GEN-AI not only to produce the game features, but to create educational experiences that without GEN-AI were not possible till today.

Video · IsabelOne key benefit of AI is creating virtual players that can convey parts of the story from one perspective, which is crucial for managing player attention. ADGP also enables virtual-real conversations, meaning you chat with your virtual partner game character about the game, which requires decision-making involving ethics, values, and cultural heritage significance. REBOOT ADGP masters all interactions behind story, plot, gameplay, and mechanics in your game.

The two mistakes

Cost of the question, cost of the answer

The first mistake is thinking the AI can code a full game platform without you explaining what your needs are, what the interactions should be, and the UX/UI. The second mistake is that you need to understand two new concepts: input or prompt token cost and output token cost. Or, in more accessible language:

Cost of processing the question. Cost of generating the answer.

Moreover, you need to understand the economics of GEN-AI costs. This is very important because any AI interaction runs on the API of the AI you choose for your game. You have a pro subscription for Claude; that cost doesn't cover the API cost. The mindset is not ChatGPT- or Claude-style: asking questions or profiling a skill. Each question and answer that you can't predict when playing the game costs you money. Then learn dataset optimization using JSON and .md files. Learn how to frame the dataset of what your virtual player and real player can do together.

Using a free cost model will not deliver quality with a high probability of expending endless hours of work and personal frustration. If you pay, you are not the product; you get the service. No API free model, and if one day you wake up and it is no longer free. Avoid it.

REBOOT Architecture overview infographic

ADGP · Capitalizes on JSON

What is JSON? Not a misspelled name

JSON (JavaScript Object Notation) is a simple text format used to organize, store, and exchange information in a structured way. It represents data through names, values, lists and groups of related information.

Example:

{
  "player": "Sofia",
  "level": 2,
  "mission": "Find the missing document",
  "completed": false
}

Although JSON originated from JavaScript, it can be used with almost every programming language and digital platform.

Why is JSON useful for AI?

AI systems work better when information is clearly structured. JSON tells the AI exactly what each piece of information represents. Instead of receiving an unstructured paragraph, the AI can identify separate elements such as the user, question, context, answer, category, score or next action.

JSON is especially useful for:

Sending data to an AI through an API
Defining the format in which the AI must answer
Organizing datasets used to train or consult AI systems
Connecting an AI agent with websites, applications, games and databases
Storing conversations, decisions, rules, characters or game levels
Reducing ambiguity and making outputs easier to validate

Main benefits

Clarity: Every value has a defined label and purpose.
Consistency: Information can always follow the same structure.
Interoperability: Different systems can exchange and understand the same data.
Automation: Software can read JSON automatically and trigger actions without manual intervention.
Reliable AI outputs: The AI can be instructed to return specific fields instead of an unpredictable block of text.
Easy validation: A system can check whether required information is present, correctly formatted, or missing.
Scalability: The same structure can be used for ten records or millions of records.
Human readability: JSON can be read both by people and machines.

In simple terms, JSON acts as a common language between AI, software, databases, and digital platforms, making information easier to understand, process, and reuse.

Three frameworks, one table

Design Thinking, Agile, and LEGO

The classic Design Thinking process (ideation, prototyping, testing, and iteration) applies in full. The second framework is Agile; you need to understand what is in your backlog, prioritize Sprints, and hold retrospectives. The third one uses LEGO to set up your game table and discover incredible things you never thought about. Put the final user group of your game on the table.

Less EGO, more LEGO.

Why we asked so many questions

Technology changes by the day

To create the Reboot AI-driven Game Platform (ADGP), we asked ourselves so many questions because the technology changes by the day, enabling new features, interactions, datasets, and analyses you never thought were possible. The first step was to stay aligned with what the proposal requires in terms of tasks across WP3 and WP4.

In this document, we focus on our personal experience designing the REBOOT platform. We acknowledge that there may be other ways to do it. The idea behind ADGP is that it can host any kind of game, from beginner to highly complex interactions, and support any kind of content for educational purposes or new business services related to cultural heritage.

Ideation to iteration

Post-its, LEGO Serious Play, and a second round

When you ideate, you write on Post-its and stick them on the wall to see the whole picture. Then you prototype. We did this with real people and the LEGO® Serious Play® methodology to gather feedback on REBOOT, which aims to reconcile HED curricula with industry needs in job-simulated environments for competitive degrees. New learning pathways counterbalance Gen-AI skills with an enhanced metacognitive capital for HED students. To boost innovation, an integrative, SDG-driven approach addresses the ethical dimension of Gen-AI and, through new learning pathways, achieves a diversity of higher skills and transversal competencies as required by the EU Digital Education Action Plan 2021–2027 and the DIGICOMP 2.2.

The iteration is a long process to understand how you can enhance your features and open new possibilities by imagining how this could work. A second iteration is needed, or maybe more.

This is how we started:

Post-itTo mentally map your backlog and sprint task priorities is key to designing properly. When AI helps identify task value, it can inspire confidence in your planning process, making you feel more motivated and assured.

LEGO Serious Play session prototyping the ADGP

LSP · ADGPLEGO enables you to set up and discover new things in the game system that you did not think about, fostering a sense of curiosity and engagement. The collective contribution is one of the most important values, making everyone feel involved and appreciated in the creative process. Each member around the table is seeing the ADGP from a different angle.

Start here, before any code

Decide what "AI-driven" means for you

This is the single most common failure point. People say "AI-driven game" and mean three different things without realizing it:

AI as a character

The player talks to it (like the Agent) is possible, but we humanize it via Hey-Gen.

AI as a content generator

Writes the story for you (we have that implemented in the platform, but it depends on what your question is and certainly hours of dedication).

AI as a grading / analysis layer

Watching what the player does; it is a must in any game.

•

These are three different products with three different costs, three different risk profiles, and three different things that can go wrong. Pick one as the primary job before you write a line of code. You can add the others later, but if you try to build all three at once from day one, you'll end up with something that does all three badly. This is exactly what our last round of questions was circling: we didn't actually know which job the AI has, and everything downstream depended on that answer.

Build in this order

Or you'll redo everything — well, in fact, you keep doing and re-doing all the time until it works.

Write one complete, non-technical script first

By hand. No AI involved. If you can't write a session that works on paper, with someone playing the AI's part manually, no amount of engineering will save it. This is the step most technical teams skip, and it's the one that would have caught our dual-mode and branching questions early.

Decide what's a platform primitive versus what's authored content

And write that decision down before a second game gets built. If you don't do this explicitly, every "new game" secretly becomes a new codebase, and "reusable platform" turns out to have been one game wearing a costume.

Build the smallest version that can be played by a real stranger

Not a colleague who already knows the plot. Test it before you build the authoring tools, the dashboards, or the second game. Everyone wants to build the platform before proving the one thing on it works. Resist that.

Only then build for reuse

The templates, the non-technical authoring interface, the multi-tenant infrastructure. Building reusability before you've proven one instance works is the most expensive mistake in this space, because you end up generalizing the wrong thing.

The traps, specifically

Five ways this goes wrong

Confusing a good demo with a working system

A scripted, rehearsed playthrough where you know all the answers proves nothing about what happens when a real, confused 19-year-old talks to your AI at 11 pm. Test with the person who has no idea what's going on.

Underestimating per-session cost

Every AI turn costs real money. "Free to run" evaporates the moment you have 16 students in a room. Know your cost per completed playthrough before you promise scale.

Treating safety and moderation as a later step

If students are talking to the AI freely, and especially if the subject matter is sensitive, this has to be designed in from the start, not patched on before evaluators arrive.

No definition of a bad outcome

If a student can "finish" without doing any real verification and the system can't tell the difference, you don't have a learning tool, you have a chat toy with a plot.

Assuming comparability across games that were never designed to be comparable

If four people build four games on four topics, "the same learning outcome" is a claim you have to engineer for, not something that happens automatically because they share a codebase.

The honest gut-check question

Ask yourself, for every feature:

Can I point to the moment this actually happened, with a real person, or am I describing what should happen?

That's the exact line our questions kept landing on. A platform description that's full of "the system does X" when X has never actually run in a prototype: do not promise what you do not test.

The real test is simple: could you sit across from the player, after the session, and explain out loud exactly why the AI was designed to behave the way it did, including the parts where it was allowed to be wrong? If that conversation would be uncomfortable to have, the design is not finished yet.

AI is not what builds the game. AI is who the student works with.

This task is often misread as "use AI to generate a game." That is not what it is. The platform puts an AI system inside the story, acting almost like another player, and asks the student to work with it the way a researcher works with a source: read what it gives you, check it, correct it, decide what actually goes in the final record. That back-and-forth, not the finished game, is the skill being taught.

Every piece of information that ends up in the game (a document, a testimony, a claim) passes through the student's hands first. The student decides if it is confirmed, disputed, or still unclear. That decision is what we mean by "customizing information." It is not a settings menu. It is the student doing the work of verification, one piece at a time.

Before the technical/pedagogical split

The questions we actually asked

Let's start with 20 preliminary questions, formatted based on what we know and have learned about game design and AI integration.

Core AI interaction

What AI does the platform actually run on — an API like Claude or GPT, a custom-trained model, or something else?

Is there one AI configuration per game, or can a single game have multiple distinct AI characters (like each virtual player is an AI agent) with different rules running at once?

How are a character's "invariant rules" (never interprets, never initiates, stores everything, one deliberate wrong answer) actually enforced — a system prompt, hard-coded logic, or both?

Is the deliberate wrong answer scripted in advance, or does the AI generate it dynamically each session?

Content and authoring

When a partner builds their own game, do they write content in a structured format (a template, a spreadsheet, a JSON file — another fancy word to learn) that the platform reads, or do they need a developer to hard-code it?

Is there an authoring interface (a dashboard, a form) non-technical staff can use, or is "partner builds their own game" currently a developer task?

How does the platform store the Fact Log and Ethics Log technically — a database per game, a shared schema, something else?

Can partners reuse platform mechanics (like the verification system) with completely different subject matter, or does each new topic require custom logic?

The verification mechanic itself

When a student marks something as verified/disputed, what actually happens in the system — does it change what the AI says next, unlock content, just get logged for review? This is very relevant for interactions between real and virtual players.

Is there any automatic checking, or is verification entirely the student's judgment with no system-side validation? The REBOOT project requires we analyze and validate the game results, and the creation process will take at least three months to produce a meaningful game.

Learning data and assessment

Does the platform log what each student does (what they verified, what they missed, how long they took), or is play currently not tracked at the individual level?

Is there any output HED evaluators or teachers can actually look at afterward — a report, a dashboard — or does assessment happen entirely outside the platform right now?

Multi-game / multi-partner reuse

Right now, does the platform actually support more than one game running on it, and create an instance of the game so that you have the same game playing at the same time in the same place with different players, each one on its own instance?

Is the platform single-tenant (one game live at a time) or can multiple partner games run simultaneously on shared infrastructure?

Technical shape

Is this a website, a native app, a chat interface (like WhatsApp or Telegram), or several of these?

Does it require an internet connection throughout, or does any part work offline?

Language, access, safety

Is the platform currently built for one language, or is multilingual support part of what's already there?

Any accessibility work done yet (screen readers, text size, alternatives to reading-heavy interaction)?

Any content moderation or safety layer on the AI's output, given students will be talking to it freely?

How is student interaction data handled for GDPR, since it's an EU higher-education project?

•

That gave us a lot to think about. Because this is an educational project, we decided to introduce another angle.

Because this is an educational project

Pedagogical framing

Is there an actual learning outcomes framework behind this (Bloom's taxonomy, a specific EU digital/AI competence framework, ECTS credit mapping), or is "builds critical thinking" currently a claim without a formal structure behind it?

What does a student walk away with that a teacher can grade — an essay, a completed dossier, a portfolio piece — or is playing the game itself the only output?

The teacher's role during play

Is a teacher/facilitator present and active while students play, or is this designed to run unsupervised?

Does the facilitator need training to run a session, and does anything exist yet (a guide, a briefing document) to support that?

What happens when the mystery doesn't resolve

Since REBOOT's central question stays open by design, is there a debrief structure outside the game where the "real" pedagogical point gets made explicit, or does the ambiguity stand permanently with no closing discussion?

Can a student "finish" without ever verifying anything properly, and if so, does the game let them know that's a worse outcome, or does it just end the same either way?

Evidence it actually works

Has this been tested with any real students yet, even informally, or is everything in this document still pre-pilot?

If tested, what did people actually do that surprised you, versus what you expected?

Positioning against what already exists

What makes this different from an AI chatbot tutor or an existing serious game with a quiz layer, in terms a skeptical evaluator would actually accept? What's the genuine novelty claim?

After the project ends

Who hosts and pays for this once REBOOT's funding runs out, given every AI interaction has a real API cost per student?

Is the platform's code open source for other universities to adopt, or proprietary to the consortium?

Cross-partner consistency

If four different partners build four different games on four different topics, how do you know a student's experience and learning outcome on one is comparable to another? Is there a shared quality bar, or does each partner's game stand alone?

•

We question this: "what does the platform do," and the other asked, "what does the pedagogy need?" What I hadn't yet asked was what happens at the seam between them, where a story decision (a character, a mode, a pacing beat) turns into a technical requirement, or where a technical limit quietly constrains what story you're allowed to tell. Here's that combined set.

Where story meets technical limit

Ten seams between story and system

(combines: multiple AI characters + rule enforcement)

REBOOT has seven AI-adjacent entities running at once: let's imagine you have the Oracle plus six Seekers (we do not call them game players anymore, but Seekers, each with a distinct psychological profile). Is that seven separate configurations with seven rule sets, or one system playing all seven roles? This decides both the cost per session and what "defining a character" even means for a partner building a two-character game instead of seven.

(combines: authoring format + the dual-mode Seeker system)

REBOOT runs two AI behavior modes, one scripted, one strictly grounded to verified content, as a deliberate lesson about AI hallucination. Is dual-mode a feature every partner's game gets automatically, or something written by hand for REBOOT's specific point? If a partner's game doesn't need that distinction, does the authoring template force them to define both modes anyway?

(combines: what verification actually changes + branching character paths)

A Seeker path is built as X number of defined steps. Is branching, the story reshaping itself based on what a student verifies, a platform primitive, or was that structure written by hand step by step, with the platform just delivering static content underneath? A partner writing something simpler or more complex needs to know which.

(combines: scripted vs dynamic wrong answers + narrative pacing)

The AI's deliberate wrong answer is tied to a "once per season" pacing device. Is that timing enforced by the system (RAG), or placed by hand by the writers? If a partner's game runs as a single two-hour session instead of a multi-day season, does the platform know how to relocate that beat, or does someone redesign it from scratch every time? We noticed this when we ran a JavaScript distance map to get time optimization moving the Seekers from one Heritage to another to define multiple territorial encounters with players you're supposed to know.

(combines: non-technical authoring interface + character psychology)

Can a partner define a character's "wound" and resulting behavior through a form, or does giving a character consistent emotional logic currently require someone who can write and tune prompts directly? This is the real test of whether "any partner can build their own game" is true yet. Our REBOOT game prototype to validate the AI-driven platform is strong on this concept.

(combines: cross-partner comparability + the Fact Log/Ethics Log structure)

REBOOT's content splits into two logs, Fact and Ethics, because its subject is surveillance and moral complicity. If a partner's topic doesn't split that way, a sustainable tourism game, say, is the two-log structure a fixed requirement they must force their content into, or something REBOOT-specific they can drop? This also decides whether "comparable learning outcomes across games" is even measurable, since comparability needs a shared structure underneath it.

(combines: technical architecture + the website/wiki as continuous fiction)

The companion website and the fourth-wall-break device both assume the fiction persists outside a single play session. Does the platform actually track story state across sessions and across the website, or does each session start fresh with no memory of what happened last time? That was a particular challenge; we created a WIKI with all the content of our Game prototype and supporting websites' information based on the alternate reality game concept. The game platform has what we have defined as an ORACLE that contains all the information and captures in real time the experience of the virtual-real AI conversation. This enables a real facilitator to map what is happening in real time and interact in the game using direct messages to the Seekers.

(combines: content moderation + subject sensitivity)

REBOOT deals with state persecution and death under a dictatorship. Is safety configuration set per game based on subject matter, or is there one fixed guardrail setup for every partner's game regardless of topic? A tourism game and a game about political persecution plausibly need different limits.

(combines: has it been tested + season-length pacing)

Has anyone actually played a full season end to end to see if the pacing works, or does the season structure exist only on paper right now?

(combines: open source/sustainability + who owns the fiction)

If the platform is shared with other universities, does REBOOT's specific content, including the University, the Seekers, and the City, ship as the working demo, or does the platform arrive empty, with every partner starting from zero? That determines how much of what we've built together actually transfers versus being a one-off illustration.

•

A piece of experience:

Behind the story

The Fact Log

The Fact Log is not a summary screen bolted onto the game. It is the game: the story, the plot, and the mechanics all come from what the student has verified and chosen to keep. A weak, unchecked Fact Log makes for a thin, confusing game. A carefully checked one makes the story make sense.

The quality of the game IS the quality of the student's verification work.

What the collaboration produces

More than a game: REBOOT AI-driven Platform is a complete package

Working with the AI does not just produce playable content. Across a full development cycle, it produces everything needed to run and present the experience as a real product:

The story and plot

What actually happened, and what is still disputed.

The gameplay and mechanics

How a player moves through the investigation.

A companion wiki

Documenting the world, in the style of an alternate reality game.

A public-facing website

Presenting the fiction as if it were real.

This matters for two reasons at once. First, it is a genuine piece of service design: a package that a tourism destination or heritage site could plausibly use to attract and engage visitors. Second, and just as important, building it forces the student to practice critical thinking and to apply European ethical standards, because every claim they let into the Fact Log has to be defensible.

From one prototype to a shared platform

T3.1.1 delivers the platform finished, not a rough draft

T3.1.1 delivers the platform in a finished, tested state, not a rough draft partners have to fix or finish. ERUDITA is the demonstration that its features actually work end to end: the Oracle, the verification mechanic, the Fact Log, the companion website.

Platform built and tested once

By the team responsible for T3.1.1.

REBOOT as the proof of concept

Built on it, using the lace-and-surveillance case.

Partners build their own game

Same ready-made platform, their own topic.

•

No partner needs to build their own AI infrastructure. What they inherit is a tested system and a working example of how to use it well.

Before anyone writes a line of code

Pre-build checklist

Finally, your sort of checklist — but you have to create yours.

Define the AI's job

We have named the AI's primary role (character, generator, or analysis layer) and are not trying to build all three at once.

We can explain, in one sentence, what the AI is not allowed to do.

Prove the design on paper

A complete session has been written and played by hand, with no AI involved, and it worked.

We know what a bad outcome looks like, and the system can tell the difference between a bad and a good one.

Separate platform from content

We have written down what counts as a reusable platform feature versus what is one-off authored content.

We have not yet built reuse tooling for a platform that has only run once.

Test with a real stranger

Someone with no prior knowledge of the design has played it, unsupervised, without us in the room.

We were surprised by at least one thing they did.

Know the real cost

We know the AI cost per completed session, at expected scale, not just per test run.

Ethics and moderation, built in, not bolted on

Players are told plainly that they are talking to an AI, and that it can be wrong.

There is a safety and moderation layer appropriate to the subject matter, decided before launch, not after a problem.

We could explain, out loud, to a player, why the AI behaves the way it does, including its deliberate flaws.

Player interaction data is handled with the same care as any personal reflection, not just the legal minimum.

Fairness and access

We know who this has been tested with, and who it has not.

Language, cultural framing, and accessibility needs have been actively considered, not assumed away.

Comparability, if more than one game exists

If multiple REBOOT game titles will run on this platform, we have defined what "comparable outcome" means across them, rather than assuming a shared codebase guarantees it.