Antura MiniGames Interface

In this document, we describe the programming interface that is used by all the MiniGames in the Antura project.

The purpose of the interface is to expose to MiniGames a unified and simplified way to access core functionalities, and to define how MiniGames are launched and configured, including the dataflow from the content (e.g. question sets) database towards each MiniGame.

Creating a new MiniGame project

All the MiniGames are in the _games directory of the Antura’s Unity project.

Instead of starting your own MiniGame from scratch, you can use the provided game template:

  1. Make a copy of the _gametemplate directory (which is in the _games directory);

  2. Rename it using the name of your game, e.g. MyNewMasterpiece and put it under the _games directory;

  3. In the folder (MyNewMasterpiece) you will find a set of files and subfolders. You must find and rename “TemplateGame.cs” and “TemplateConfiguration.cs” into “MyNewMasterpieceGame.cs” and “MyNewMasterpieceConfiguration.cs”, according to the game name you chose;

  4. Edit these source files, and change the class names in order to comply with this name change, for example:

    1. Antura.Template namespace should become Antura.MyNewMasterpiece
    2. TemplateGame class should become MyNewMasterpieceGame
    3. TemplateConfiguration class should become MyNewMasterpieceConfiguration

note: MiniGame namespaces may change

Making a MiniGame accessible from the core application

A MiniGame does not exist in a vacuum. The core app needs to know of its existance and how to handle it. For this purpose, the following should be performed:

note: the above requirements are bound to change as it couples MiniGames with the core codebase

Game Structure

Here we describe the software architecture that should be followed by your MiniGames. If you copied the MiniGame template, the main classes are already partially implemented to be compliant with such architecture.

The MiniGame main class should extend MiniGame class, inside the Antura namespace. Such class is realized using the State Pattern The game is divided in an arbitrary number of states, for example:

Such list is just an example of what states a game could have, it’s up to the MiniGame developer to understand how many and what kind of states he should implement.

At a given time, only one state is active and running. When it’s running, Update() and UpdatePhysics() are called on the state in each frame. UpdatePhysics is the equivalent of Unity3D’s FixedUpdate.

All state objects are instanced in the game class, which exposes them as public fields. Each state must have a reference to the MiniGame main class, that you could pass through the constructor.

In this way, when you want to switch game state, you can call:


each time a state transition is completed, the ExitState() method is called on the previous state, and EnterState() is called on the next state.

The purpose of these methods is to process things like setting up the scene graphics, resetting timers, showing/hiding panels, etc.

Ending the Game

When the game is over, call the method EndGame of the {GameName}Game class:

game.EndGame(howMuchStars, gameScore);

howMuchStars should be in the range (0 to 3, included);

gameScore is game-specific (could be 0, if not defined for that MiniGame)

In this way, the game will automatically switch to a special OutcomeState, and show how many stars were obtained, then quit the game.

Game Configuration

Each game folder should have two main folders for scripts:



all the game-related scripts, should be placed inside the _scripts folder; _configurationscripts is a service folder used to define game specific classes that help the in communicating with the core codebase.

The first requirement of your MiniGame is to have a game configuration script. If you want to see how a configuration class is made, you could just copy it from the template directory.

The {GameName}Configuration.cs defines how a MiniGame is configured by the app, and provides the MiniGame some useful interfaces.

Minigame Variations

Each MiniGame is created inside its own scene and namespace. Usually, the core application refers to the MiniGame using a 1-to-1 relationship, detailed by the MiniGameCode that represents the MiniGame in the core application.

However, sometimes it is useful to have a single scene support multiple instances of MiniGames with slight variations. These MiniGames are called variations. Variations are transparent to the core application (they are considered different MiniGames), but multiple variations point to the same MiniGame scene.

Variations are specified in the specific MiniGame’s configuration code, if needed.

Game Difficulty

The game configuration provides a difficulty level. This difficulty value is provided by the Teacher and can be accessed as:

float difficulty = {GameName}Configuration.Instance.Difficulty;

The game difficulty is expressed as a float in the range [0, 1], meaning 0 : easiest, 1 : hardest.

How such difficulty level is implemented must be defined by the MiniGame developer.

Possible choices for difficulty can be:

For example, the MiniGame can linearly control the game speed based on difficulty:

_speed = normalSpeed - difficulty;

or, it could have a finite set of parameters configurations, based on difficulty interval:

if (difficulty < 0.333f)
  // configure game for "easy"

else if (difficulty < 0.666f)
  // configure game for "medium"
  // configure game for "hard"

In this case, please configure a set of at least 5 different configurations (very easy, easy, medium, hard, very hard).

Note that this difficulty must however be related to playskill, not to the learning content. This is because learning difficulty is already taken care of by the Teacher generating suitable Question Packs.

Accessing core functionalities

When you need to access a core feature in any part of your game {GameName}, you do it through the game context:

var context = {GameName}Configuration.Instance.Context;

Such object implements the IGameContext interface.

For example, to show the popup widget (that is, a large dialog with some text inside it),

you call:

context.GetPopupWidget().Show(callback, text, isArabic);

or, to play the game music:


To have a list of all the possible functionalities that you could use, take a look into the IGameContext source.

Audio Manager

The Audio Manager provides some simple methods to play in-game audio, for example:

IAudioSource PlaySound(Sfx sfx);
IAudioSource PlayLetterData(ILivingLetterData id);

It behaves in a similar way to Unity’s AudioSource. It exposes some properties and methods like:

Working with the UI

When you are working on your MiniGame, you do not need to know what prefab are used for the UI or how it is implemented. The game context IGameContext will provide you a set of interfaces to widgets that you can call from your game code.

For example:

ISubtitlesWidget GetSubtitleWidget();
IStarsWidget GetStarsWidget();
IPopupWidget GetPopupWidget();
ICheckmarkWidget GetCheckmarkWidget();

Retrieving dictionary content from Core

Usually, a MiniGame needs vocabulary content to be passed directly from the core code. For instance, some MiniGames need a set of words, that are chosen by the core based on the current game world, or depending on past play history.

Such content is passed to the game using the {GameName}Configuration.cs class by core programmers to MiniGames programmers, through a QuestionProvider interface.

The IQuestionProvider interface exposes the following methods:

Its purpose is to provide a stream of objects that implements the interface IQuestionPack, a very general abstraction for a learning question which includes letters, words and images as fundamental parts.

What is returned as IQuestionPack, will define a package containing ILivingLetterData instances structured as:

All data implements the ILivingLetterData interface and can thus be displayed by a Living Letter. The data can be one of the following:

What follows is a list of possible examples:

Question Builder

Each MiniGame (or MiniGame variation) requires question packs in different forms and this is defined by implementing the method SetupBuilder() inside the Game Configuration, which returns an object implementing the IQuestionBuilder interface.

The IQuestionBuilder defines the learning rules and requirements for the current MiniGame variation and must be correctly setup and configured. The Question Builder will generate the correct Question Packs for a given MiniGame instance.

The MiniGame developer can choose from a set of question builders that the Teacher can support. Refer to the Teacher documentation for further details.

Generating content for test purposes

When developing a MiniGame, test dictionary data, like letters or words, is needed to test the gameplay. To do so, just define a default Question Provider in your Game Configuration class as a custom provider, in the Game Configuration constructor.

For example:

private {GameName}Configuration()
  Questions = new MyQuestionProvider();
  Context = new SampleGameContext();
  Difficulty = 0.0f;

Then, implement your question provider by generating (ILivingLetterData) using:

var newWord = AppManager.I.Teacher.GetRandomTestWordDataLL()
var newLetter = AppManager.I.Teacher.GetRandomTestLetterLL();

@todo: remove references to the teacher.

You can also decompose a word in letters:

var letters = ArabicAlphabetHelper.LetterDataListFromWord(newWord.Data.Arabic, AppManager.I.Letters)

@todo: remove references to the arabic language.

Or instead get all Letters/Words/Phrases:

var letters = AppManager.I.DB.GetAllLetterData();
var words = AppManager.I.DB.GetAllWordData();
var phrases = AppManager.I.DB.GetAllPhraseData();

The default Question Provider is used when you launch the game’s scene directly. Note that when playing the game through the core application, the Question Provider will be the one defined by the core system to provide meaningful learning data as selected by the Teacher. Make sure that the test Question Provider content matches real content, otherwise your game may not work when launched through the core application.

Using the Living Letter prefab

see Antura and Living Letters doc

Using the Antura prefab

see Antura and Living Letters doc

Adding Environment Assets

Environment graphics, like trees, are selected in the scene in order to match the current world of the MiniGame (there are 6 worlds). To do so, you must use the following auto-switching component: AutoWorldPrefab.

Another requisite of each MiniGame scene is that the camera that will render your environment has the following scripts:

The AutoWorldCameraColor, as in AutoWorldPrefab, needs that a field is configured by inspector. The name of the field is Backgroung Color Set, and currently you will find just an asset called “CameraColors” to be selected.

Refactoring Notes