Gamification Device Wowcube: Design And Program Environment

WOWCube Design

WOWCube is a mechatronic game console, which consists of eight identical sections equipped with individual means of computation and communication that integrate the sections in a common logic device. The main method of controlling the console is varying the mutual position of the sections in a manner similar to well-known Rubik’s Cube. As opposed to Rubik’s Cube, where the color of each cube face is static and predetermined, and the search for one and only one combination is the aim of the game, the WOWCube has 24 displays on the faces of the elements, whereas the winning combinations and the gaming strategy are specified in software and depend on the game uploaded to the console.

The possibility to vary the gaming process in the WOWCube software is ensured by a set of microcontrollers, which render on-screen graphics, determine the game mechanics, and support the interaction of adjacent sections via a couple of serial ports (universal synchronous asynchronous receiver/transmitters, USART). These ports are full-duplex and support data exchange between not only neighboring sections, but any other sections as well. In this case, some sections act as relay agents.

Each section shaped as a cube has three internal and three external sides (faces), where “internal” means conventionally the sides, which face the sides of the neighboring sections, and “external” means the sides visible to the user. Each external face of each section is equipped with a 240x240 TFT display, which has a maximum color depth of 18 bits and is connected to the microcontroller directly via a parallel bus (see Fig. 2 ).

See Full Size >

After any change in the configuration, i.e., rotation of the console sections relative to each other, newly contacted sections are identified by each section in software. This allows controlling the gaming process, for example, a game item can move from the display of one section to the display of another section, which is adjacent to the former one, within the common plane formed by the displays of four adjacent sections. From the player’s viewpoint, this looks like a continuous motion of the item along a common display formed by the face of the console in the stable position, excluding the technological gap between the TFT displays that comprise it.

The internal sides are equipped with groups of magnetic contacts ensuring the electric contact between the mating contacts of neighboring sections (Fig.  2 ). Each group consists of four contacts, namely: TX for USART data transmission, RX for USART data reception, Charge being the common charging bus for all sections (which also has the function of rebooting the sections it joins at a specific moment in the case of “grounding”) with a charging voltage of +5 V relative to the common wire, and Ground being the “ground” or “common wire”. The latter contact is the reference point for formation of logical levels at the RX and TX contacts, as well as the charging voltage and the low level of rebooting at the Charge contact.

The contacts are located in such a way as to ensure that the Ground and Charge contacts of neighboring sections always connect to the peer contacts, respectively, whereas the connection of the USART contacts, contrariwise, is always “crossover” in full accordance with the data transmission protocol, i.e., an RX contact is always connected to the neighboring TX contact, and a TX contact, to the neighboring RX contact. This is achieved by installing the Ground and Charge contacts in the same radius from the device center, and the RX and TX contacts, in the same circle, symmetrically relative to the radius, at which the rest of the contacts are situated.

The patented design of the contacts (patent WO2018075714, see Fig.  3 ) makes it possible to maintain electric connections between arbitrary contacts, which are elements of the console structure, independently of the initial orientation of the magnetic poles of ball-shaped neodymium magnets, while making the console position stable when the neighboring displays on adjacent faces lie in the same plane.

Magnetic interaction between neodymium magnets, which is stronger than the interaction of the magnets with their collars ensure reorientation of the magnets after each variation in the console configuration, thus maintaining reliable electric contacts in the USART data links.

See Full Size >

Development framework

The gaming logic module and the emulator exchange data using the user datagram protocol (UDP). UDP is not a random choice, since it is included in all operating systems (OS) making it possible to port the development framework to other platforms making as few changes as possible.

The communication between the unit cubes is based on the Tag-Length-Value (TLV) method, which is used to record small data in computer files and telecommunication protocols. The method specifies a structure of three fields, namely, the tag, the data length, and the data. The fields of the tag and data length have a size of 1 or 2 bytes, and the size of the third field is determined by the value of the second field.

The WOWCube game logic is programmed in the PAWN language, with an individual script for each game.

Processing module

The code for emulation of operation of the physical device is common for all games. it contains the following classes:

• CDisplay is the display object responsible for rendering of a display image;

• CFace describes one of the three sides of the tube and contains CDisplay;

• CCube is the object corresponding to one of the eight cubes; totally, there are eight such objects, each containing three CFace objects;

• CCubeSet is the object of the entire WOWCube; it creates 8 CCube objects and is responsible for animation of the cube rotation in the emulator;

• CPawnLogic describes the interface of data exchange with PAWN via UDP.

The main task fulfilled by the model is to emulate the operation of the physical model and serve as the API. The communication with PAWN is supported by the command pattern. The code of the object command, which is received and transmitted by the module, is as follows:

class CPawnCmd {

public int cubeN;

public byte[] pkt;

CPawnCmd(int _cubeN, byte[] _pkt) {

this.cubeN = _cubeN;

this.pkt = new byte[_pkt.length];

arrayCopy(_pkt,this.pkt);

}

}

The following commands are sent to the Processing interface in the current version of the development framework (0.2):

• CMD_GUI_DEBUG is the command required for debugging;

• CMD_FILL is the command for monochrome filling of the display (the above-mentioned CDisplay class; it is required for display clearing or highlighting for emphasis);

• CMD_BITMAP is the most frequent command; it renders a display image corresponding to the number received with the command. The image is taken from the common resource set (PImage res[]).

The following commands are sent to the binary interface (cubios_abi.pwn):

• CMD_PAWN_DEBUG is the command required for debugging in the PAWN module already;

• CMD_TICK is the command for imitation of one cycle of microcontroller operation; it is sent every 100 milliseconds;

• CMD_ATTACH is the command sent at an instant when the cube halves stop rotating;

• CMD_DETACH is the command sent at an instant when the cube halves start rotating.

It should be noted that the commands are sent within a cycle via each of the eight ports. As it has been already mentioned, modules exchange data using the UDP protocol, and an individual port corresponds to each of the eight cubes. A separate port corresponds to the processing module.

The diagram of the module classes is shown in Fig.  4 .

The same module describes functions/events:

void mouseDragged() is for rotation of the 3D cube projection using a mouse;

void keyPressed() is for rotation of the 3D cube projection using a keyboard; and

void receive(byte[] pkt, String ip, int port) is for reception of cube data batches using the UDP protocol.

See Full Size >

PAWN module

The module where the game logic is written contains:

• cubios_abi.pwn, the binary interface responsible for the data exchange with the Processing via UDP;

• %gamename%.pwn describing the game logics; and

• game.amx, the complied binarty file (byte code) containing the logics of all games.

The transmitted and received commands were described above in Section  2.1 , and will not be repeated here. Note only that the GUI commands are received by the following functions:

@receivepacket(const packet[], size, const source[]) {

run(packet, size, source);

}

The run function launches processing of the received command. The commands are sent in the game logic script by calling the functions abi_CMD_BITMAP and abi_CMD_FILL.

The cubios_abi binary interface includes the following functions:

• abi_CMD_BITMAP, abi_CMD_FILL are the above-mentioned commands for data transmission to the Processing;

• abi_InitialFacePositionAtProjection is the initial location of the face side of the cube on the projection;

• abi_FacePositionAtProjection is the location of the current position of the face side of the cube on the projection;

• abi_DeserializePositonsMatrix is deserialization of the batch of data received from the Processing;

• abi_LogSndPkt, abi_LogRcvPkt is the function of logging of the data sent and received, respectively;

• abi_LogPositionsMatrix is the matrix of the current position of the cubes.

The %gamename%.pwn contains the game logic. The main function of all eight cubes is identical:

main() {

new opt{100};

argindex(0, opt);

abi_cubeN = strval(opt);

listenport(PAWN_PORT_BASE+abi_cubeN);

}

Receiving the cube number at its output, the cube starts sounding this port in order to exchange commands with the processing interface. The rest of the methods in the given file differ depending on the game.

json module

This module contains a file with tasks for automatic assembling, compiling, emulating, etc. One can have a look at the tasks at https://code.visualstudio.com/docs/editor/tasks.

To launch a game on the WOWCube, it is necessary to first compile it. The task for game compilation looks as follows:

"label": "1) WOWCube compile game logic (Pawn language)",

"type": "shell",

"command": "../../Pawn/bin/pawncc %gameName%.pwn -ogame",

"options": {

"cwd": "./pawn"

},

"problemMatcher": []

The framework will compile the game as a game.amx file. Then, the game logic should be started. Since each cube is an individual element, they all should be launched separately. Sequential starting of all eight cubes is executed by the following task which launches tasks of individual cubes:

"label": "2) WOWCube run #0-7 Cube game logic (Pawn language)",

"dependsOn": [

"WOWCube run #0",

"WOWCube run #1",

"WOWCube run #2",

"WOWCube run #3",

"WOWCube run #4",

"WOWCube run #5",

"WOWCube run #6",

"WOWCube run #7",

],

"problemMatcher": []

The task of an individual cube has the following code:

"label": "WOWCube run # %cubeNumber%",

"type": "shell",

"command": "../../Pawn/bin/pawnrun game.amx %cubeNumber%",

"options": {

"cwd": "./pawn"

},

"problemMatcher": []

The last but not least element to launch is GUI:

"label": "3) WOWCube run GUI emulator (Processing language)",

"type": "shell",

"command": "../Processing/processing-java.exe --sketch=../WOWCube --run",

"problemMatcher": []