McGill University

Computer Science Master's Project

Meta-Architecture

for

Computer Game Development

Irwin Chiu Hau

119930882

April 30, 2005

Student: Irwin Chiu HauProfessor: Clark VerbruggeProject: Meta-Architecture for Game DevelopmentDate: April 30, 2005

Abstract

Creating large computer games often requires multiple software development stages.Repeated prototyping is needed to approve the final design; this will result in a significantoverhead cost as a design is revisited multiple times.

In this project, a concept for improving the process of game development ispresented. As a result, the Meta-Architecture Language has been invented to model gamearchitectures. Then, an application is written to generate compilable and runnable codefrom architecture scripts expressed using such language.

Modelling game architectures using the Meta-Architecture Language allows usersto program games will less effort. The Meta-Architecture for Game Development approachfocuses on Modelling and Simulation, Software Engineering, and particularly on SoftwareArchitecture and Design to discover techniques to make game development lesscomplicated. Such are fast prototyping, incremental game design and automatic systemintegration.

Our approach is demonstrated and validated through different game designs andrepeated prototype implementation of several test games. These games are constructedwithin our framework to reveal different aspects of the game framework design. Inaddition, these games also come in multiple versions to demonstrate the evolution of gamearchitectures.

Contents

1 Introduction

1.1 Motivation1.2 Goals1.3 Roadmap

2 Meta-Architecture for Game Development

2.1 Features2.2 Introduction To Meta-Architecture2.3 Meta-Architecture2.4 Protocol2.5 Simulator2.6 Libraries2.7 Compiler

3 Games

3.1 LIGHTS3.2 CONNECTFOUR3.3 TETRIS

4 Related Work

5 Future Work

6 Conclusion

References

Appendix

1 Introduction

1.1 Motivation

Computer games are becoming more and more popular these days, many gamers spendcountless hours playing good games. On the other side, building computer games can alsobe a pleasing thing to do, because we can build a world out of our own imagination.Therefore, for my Computer Science Master’s Project, I have decided to create somecomputer games. From my previous experience, it is not easy to settle a good game design,to have the game implemented and to make it work flawlessly in one attempt.

As mentioned above, building games is not always an easy task, because it demandsa great amount of effort, especially for more complicated games. First we need to beginwith a game design, but new requirements can appear during any stage of the gamedevelopment, therefore we can't make any final decisions straightaway. So we simply needto start with a rough design, then we need to start coding the game. Since we build gamespart by part, we need to integrate all the pieces together. Afterwards, we need to testwhether the game works or not. The game may not meet its requirements; consequently, weneed to fix things up and make some improvements. This situation shows us that gamedevelopment process adopts a process spiral model, that means we will end up in gamedesign phase again, we will subsequently repeat over the same steps until the game isworking properly. Hence, game development is a very long process.

We certainly want to find some ways to speed up the game development process.To do this, we can improve the process management, use existing game libraries orsophisticated applications. The combination of these solutions has led me to invent anapplication that can build games in a much simpler way. The entire framework will becalled Meta-Architecture for Game Development; this tool will help developers setup aninitial game design, integrate subsystems and improve the existing design. This conceptallows fast prototyping, which is one of the most basic techniques for discovering gooddesigns, and validating early requirements. Then, this tool will generate an entiresimulation system for any game architecture and then integrate all the subsystems into thefinal game. If the game needs improvements such as design changes, the game architecturecan be modified on the fly, and then its source code will be updated automatically. Inaddition to this tool, I also created libraries that provide networking support and a verysimple GUI framework for building larger games.

As a result, Meta-Architecture for Game Development does not only reduce theoverhead cost of game development, moreover it reveals the expressiveness of the gamearchitecture and design. The application can be used to establish the data flow and thecommunications between independent components of the system. By taking the fulladvantage of this concept, we can even embed middlewares into these components. Asmentioned earlier, some games will be built; but in this situation, they will be writtenwithin our framework.

1.2 Goals

The main purpose of this project is to build a framework that can help us develop games byfollowing a more structured procedure; being organized can speed up the work process, andlead to better outcomes. Here are the goals for this project:

1. To invent a high level scripting language that describes a game architecture.2. To build a simulator for the game architecture.3. To write a compiler that reads such scripts and generates runnable code.4. To create some games.5. To analyze Meta-Architecture for Game Development.

For now, I will briefly describe what each component is trying to achieve.

1.2.1 The Language

In order to describe a game architecture, we need a very high level language. This languageshould be very simple but powerful, it should let us describe any game from the designer'spoint of view. The Meta-Architecture Language allows any architecture to be expressedliterally.

1.2.2 The Tool

Once we have a scripting language for modelling architectures, we need a very complexapplication that can read architecture scripts and do the rest of the work. To achieve this,we need a compiler that can generate compilable and runnable code from scripts. We alsoneed a simulator and other libraries to execute the architectures.

The Code Generator

The code generator takes architecture scripts as input and generates compilable andrunnable Java code. Furthermore, it can apply changes, such as architecture expansion ormodification, to existing game designs.

The Libraries

These include the essential libraries required by the game architecture and the simulator. Inaddition, a robust communication package is provided to handle sockets, and a small GUIpackage is also included to create a simple graphical framework.

The Helper Scripts

The helper scripts are shells scripts that compile and run the game. They set classpaths,compile necessary java files and run the executable file.

1.2.3 The Games

After the compiler has been written, we may want to use it to build some games. Toevaluate this tool and game architectures, three games will be built; these games also comein different flavours.

These are the games that will be built:

1. Lights2. Connect Four

1. Hot-seat Console2. Hot-seat Graphical3. Networked

3. Tetris1. Single Player2. Two-Player Networked

1.2.4 Analysis

Multiple versions for each game are written for validation purposes. Adding more featuresin each version allows us to discover the workload required for altering game designs. Ifgames are built within the framework, the effort required should be minimal. Thus, theMeta-Architecture for Game Development approach should facilitate game development.

1.3 Roadmap

In section 2, the entire Meta-Architecture for Game Development approach is describedand explained; details include features, language, mechanism and implementations.

In section 3, three games are introduced, expressed using the Meta-Architecture languageand implemented.

In section 4, Game Construction Systems and the related work are presented.

In section 5, we are given several options for future work; many improvements can bemade to expand Meta-Architecture framework.

And finally, we will conclude this experiment in section 6.

2 Meta-Architecture for Game Development

I gave the name Meta-Architecture for Game Development to my framework for gamedevelopment, the concept is based on Modelling and Simulation, Software Engineering,and especially Software Architecture and Design. By exploring these areas, we may comeup with some effective ways to model computer game architectures and simulate them.

Different games can adopt different structures, so I bring forth a super generic classthat can represent all the architectures, and I named this abstraction the Meta-Architecture.To express them literally, I invented a language called Meta-Architecture Language. In thiswhole section, everything related to Meta-Architecture framework will be explained. I willprovide descriptions, explain details, and give examples related this concept.

2.1 Features

As one of the objectives, I want to create a strong and useful application that can assistgame development in different perspectives. I will begin by introducing the features thatMeta-Architecture for Game Development will provide:

1. Flexibility - Fast Prototyping2. Extensibility - Incremental Design3. Modularity - Independent Modules4. Simplicity - Automatic System Integration5. Fast - Less Coding

I will describe and explain each feature in succession about how this application can helpdevelopers building games.

Flexibility - Fast Prototyping

When the programmer isn’t certain about what design to use, fast prototyping will helpprogrammers create a semi-empty architecture by generating initial runnable code. Lateron, the programmer can change the game design such as adding or removing subsystems.

Extensibility – Incremental Design

This tool allows the architecture to evolve and to expand; which means that subsystems canbe removed, replaced, or added to the architecture at anytime. This feature permitsprogrammers to improve a game architecture incrementally.

Modularity - Independent Subsystems

To be more manageable, the entire system is composed of subsystems; these componentsare specifically called modules in this project. Each of them does a specific task, and it cancommunicate with other modules through message passing. These components can act likelibraries, or a simulator unit depending on how we operate them. In consequence,middlewares can be embedded into these subsystems.

Simplicity - Automatic System Integration

The programmer doesn't need to integrate any subsystems; this is accomplished by theapplication. When the compiler generates runnable code, it will establish thecommunication channels between subsystems. Thus, integration is done beforehand duringthe fast prototyping stage. If the architecture has been modified, then the system will beautomatically updated during the next code generation phase.

Fast - Less Coding

Since the compiler generates a portion of the game source code, we have less code to write.In addition, the GUI framework and communication libraries are supplied so thatprogrammers can fully take advantage of them.

2.2 Introduction To Meta-Architecture

In simple words, Meta-Architecture is the super generic class of all game architectures.Due to the fact that different games may have different designs, we need such a high levelabstraction to describe game architectures. From this point of view, all games are made upof simple components called modules, and these modules can communicate with othersthrough message passing. The mechanism of Meta-Architecture is composed of manyelements; all together form the complete framework.

Here's the overview of the mechanism:

1. Meta-Architecture2. Protocol System3. Simulator4. Libraries5. Compiler

Here's just a brief description for these different elements. The Meta-Architecturedefines the structure of a game. The Protocol System defines the rules and actions used bymodules and channels. The Simulator and Libraries together become the implementation ofMeta-Architecture; they are used to run game architectures. And finally, the Compiler isthe main tool used to generate code from the Meta-Architecture Language. The nextsubsections will describe in further details the concept of Meta- Architecture.

2.3 Meta-Architecture

As mention before, Meta-Architecture represents the very high level of abstraction fordescribing game architectures. Without it, we cannot declare a generic architecture, in orderto be capable of expressing it in a language, we need genericity. At this level of abstraction,any architecture is composed of three basic entities:

· GAME· MODULE· CHANNEL

The architecture of a game is built from these entities. The Meta-Architecturecomprises a GAME label, a set of MODULEs and a set of CHANNELs. Meta-Architecture, Architecture, GAME, MODULEs and CHANNELs will be explained in thefollowing subsections.

2.3.1 META-ARCHITECTURE

Now we go into the details, Meta-Architecture represents the super generic class of allgame architectures. In simple words, it is the architecture of the game architectures. It ismade of MODULEs that are interconnected using CHANNELs, it contains a GAME labelused to distinguish one architecture from another.

Here's the graphical description of the Meta-Architecture:

Figure 2.3.1 The graphical representation of the META-ARCHITECTURE

Here's the Meta-Architecture Language: Syntax and Grammar

-----------------------------------------------------------------------game IDENTIFIER

module IDENTIFIER…

channel IDENTIFIER [IDENTIFIER, …, IDENTIFIER]…

-----------------------------------------------------------------------

The text above illustrates a super generic architecture script. The actual architecturefile stores a game architecture in a file that ends with a '.gg' extension. This script containsthree sections, the first one is used to declare the game name, the second one is used to

GAME

MODULE MODULE

MODULE

CHANNEL

CHANNEL

…

… MODULE

declare modules, and the third one is used to declare channels. The word IDENTIFIER is tobe replaced with other labels.

For the more details on the syntax and grammar please refer to the gamegen.l andgamegen.y files.

2.3.2 ARCHITECTURE

Now we have a language that can model an overall game structure, we can proceed bydeclaring some architectures. An ARCHITECTURE is the concrete architecture of a game,it is composed of a specific GAME label, a specific set of MODULEs and a specific set ofCHANNELs. Game architectures are saved into architecture files; these files have '.gg'extensions.

Example 2.3.1: A simple architecture

Here's the graphical representation of an architecture which contains:

· a specific game label (GAME1)· two specific modules (MODULE1 and MODULE2)· one specific channel (MODULE1_TO_MODULE2)

Figure 2.3.2 A simple architecture

GAME1

MODULE1

MODULE2

MODULE1_TO_MODULE2

This GAME1 architecture can be expressed using the following script. Forexample, this script can be stored in a file called 'module_file.gg'.

module_file.gg--------------------------------------------------------------game GAME1module MODULE1module MODULE2channel MODULE1 [MODULE2]--------------------------------------------------------------

To generate this architecture, we type

./gamegen module_file.gg

at the command prompt, and compilable templates will be generated.

Example 2.3.2: The architecture for CONNECTFOURGRAPHICS

This illustrates the authentic architecture for the graphical version of my Connect Fourgame; it has three modules and two channels. The data module stores game states and gamemechanics. The logic module performs some state evaluations, and the GUI moduledisplays the game state. This game will be presented later in the game section, for now, Iwill just quickly go over the declaration of this architecture.

Figure 2.3.3 The architecture of CONNECTFOURGRAPHICS

CONNECTFOURGRAPHICS

DATA LOGIC

DATA_TO_LOGIC

GUI

GUI_TO_DATA

This architecture is defined in a file named “connectfourgraphics.gg”.

--------------------------------------------------------------game CONNECTFOURGRAPHICSmodule DATAmodule LOGICmodule GUIchannel GUI[DATA]channel DATA[LOGIC]--------------------------------------------------------------

Thus, architectures can illustrate the overall design of a system. From thesegraphical representations, we can perceive the data flow and the communication betweensubsystems.

2.3.3 GAME

As there are many ways to design a game, different games can share the same architecture;therefore we want to assign a name to each architecture to avoid guessing which game is itreferring to. A GAME is just a label inserted into an architecture to distinguish it fromothers, it is also used to give a name to a game.

For instance, the architecture from Example 2.3.2 has the game labelCONNECTFOURGRAPHICS declared, without it we won't know that is used for whichgame.

To declare a game or an architecture, we write

game IDENTIFIER

2.3.4 MODULE

A MODULE is the basic simulation unit of the architecture. It may contain objects thatrepresent the state of the module, functions that are executed by the simulator or by eventcalls. We can also embedded middlewares into different modules to form a complexsystem.

The graphical representation of a module is:

Figure 2.3.4 The graphical representation of a MODULE

MODULE

To declare a module we write

module IDENTIFIER

2.3.5 CHANNEL

Even though modules are independent subsystems, they may need to interact with othermodules. The only way is to do it through message passing; a module can communicatewith other modules only via CHANNELs. Each channel is dedicated to a module pair, sothat no other modules have access to it. A channel allows only one-way communication,but it does return an event synchronously, this is analogous to a function call in mostprogramming languages such as C and JAVA.

The graphical representation of a channel is:

Figure 2.3.5 The graphical representation of a CHANNEL

To declare a channel, we write

channel SRCMOD[DSTMOD]

The resulting channel name will be labelled SRCMOD_TO_DSTMOD. In this context,SRCMOD (source / sender) is the module that sends events, and DSTMOD (destination /receiver) is the module that receives events.

Example 2.3.3: The channel MODULE1_TO_MODULE2.

In this graph, MODULE1 have access to send events to MODULE2 through the channelMODULE1_TO_MODULE2.

Figure 2.3.6 The channel MODULE1_TO_MODULE2

CHANNEL

MODULE1_TO_MODULE2

MODULE1 MODULE2

2.3.6 Modelling Game Architectures

After identifying the purposes of the three basic entities GAME, MODULE andCHANNEL, we can combine them to model game architectures. Building the model is thestarting point for the game development design phase, having a model is not sufficient; weneed to make it active by adding some content to the entire system. The next sectionprovides all necessary information to make modules and channels alive.

2.4 Protocol System

The architecture of a game is nothing more than a model, it doesn't do anything. In order toturn it into an active system, we need to assign tasks to its subsystem. Therefore, we needto add objects, functions, libraries and / or middlewares into the modules according to theirpurposes. Once these modules acquire any content, they will be given orders to performcertain tasks. These modules understand and accept specific requests. All this will be donethrough the Protocol System and Message Passing.

Before jumping into the Protocol System, we need to learn how to insert contentsinto modules. After that, I will introduce the protocol system and message passing, andexplain them in details. Then I will finish this subsection by giving out examples on how todeclare protocols and apply them for message passing.

2.4.1 Inserting Content into Modules

Declaring a module will only create an empty subsystem, this module will not do any work.Therefore, we must insert objects, functions, and libraries into a module, to turn it into asimulation unit, state machine or a black box depending on the content it holds.

At first, when a module is declared in an architecture file, fast prototyping willgenerate a template for this module from this file. In this current implementation, ModuleTemplates are in Java Code, they are subclasses of the MODULE class which will beexplained in better detail in the ‘Libraries’ section. For now, initially generated templateshave empty spaces dedicated for user code, so we need to fill out the blanks and add somecontents into the modules. Module Templates are also called Module Files once they gethave their filename extension renamed to ‘.mm’. We can use attach Module Files to embedexisting module content into a new or modified architecture.

Example 2.4.1: Module Templates generated by fast prototyping

In this example, we demonstrate the module templates generated by fast prototyping. Giventhis architecture file:

--------------------------------------------game CONNECTFOURGRAPHICSmodule DATAmodule LOGICmodule GUIchannel GUI[DATA]channel DATA[LOGIC]--------------------------------------------

The following module templates are generated:

· CONNECTFOURGRAPHICS/DATA/DATA.java,· CONNECTFOURGRAPHICS/LOGIC/LOGIC.java,· CONNECTFOURGRAPHICS/GUI/GUI.java.

Example 2.4.2: Feeding Module Templates back to the architecture files.

From the previous example, three java files were generated. If for any reason we want toadd a new module to the system or replace an existing module for expanding or modifyingthe architecture respectively, then we need to feed these modules files back to the codegenerator.

To do this, we need to change the extension of the three files to '.mm'. For example,we can change

'DATA.java' into 'connectfourgraphics_data.mm','LOGIC.java' into 'connectfourgraphics_logic.mm','GUI.java' into 'connectfourgraphics_gui.mm'.

Afterwards, we feed back these files to the architecture file by attaching thembehind each module declaration. In this example, we add a new module SOUND to thesystem, and embed the old modules into the updated version.

--------------------------------------------game CONNECTFOURGRAPHICSmodule DATA : connectfourgraphics_data.mmmodule LOGIC : connectfourgraphics_logic.mmmodule GUI : connectfourgraphics_gui.mmmodule SOUNDchannel GUI[DATA]channel DATA[LOGIC, SOUND]--------------------------------------------

From this updated architecture file, the application will add the sound module in to thearchitecture, and re-establish connections. Old modules will keep their content, because wehave fed in their respective module files.

2.4.2 Protocols

After we have a system with complete content, modules may need to communicate withothers, this is done through message passing. We need establish links between modulepairs; this permits access to send messages from one module to another.

After the channels are established, we need to set up a data transfer procedure, thisis accomplished through protocols. Every channel adopts a similar protocol system; thisdefines a procedure for event transferring between the source module and the destinationmodule. Each channel contains a list of protocols that reveals the purpose of the interactionbetween two modules. And each protocol contains an event-to-function mapping thattranslates an event into a series of commands. So basically, a module sends an event toanother module through a channel. The next step, the receiver module will interpret thatevent, and then execute some commands. And finally, the result will be returned to thesender. If desired, protocols can be declared during the fast prototyping stage, which isbefore adding contents to modules.

2.4.3 Anatomy of a protocol

A protocol has two distinguishable parts, an event and a body.

Event:

An event is just a Java object, possibly with several parameters. Events are being sent andreceived from the source module to the destination module.

Body:

The body contains code that will be executed by the destination module.

Event-to-Function Mapping:

The result of the protocol system is the “Event-to-Function Mapping, the protocol defineswhat is being requested, processed and returned. When the receiver receives an event, itwill distinguish this event, and execute the corresponding code. Depending on howprotocols are declared, we can define setting, polling, and sending operations.

2.4.4 Channel Files

Protocols lists are stored in channel files; these files have the '.pp' extensions. Without anattached protocol file, a channel does nothing. Channel files can also be called protocolfiles. Once again, these files reveal the purpose of the interaction between two modules.

To declare a protocol, we write

protocol EVENTNAME(type ident1, type ident2, …){ // body // insert code here // for example // ... ans = func(protocol.ident1, protocol.ident2, ...); return MM_PROTOCOL_RECV.singletonMM_PROTOCOL_RECV(ans);}

In this situation, ‘type’ is a Java primitive type (or Java object), ‘idents’ areparameter names, ‘func’ is an arbitrary function, and the protocol returns a Receive Eventcontaining the object ‘ans’. To retrieve parameters in the body, we need to add ‘protocol.’in front of them.

To attach a protocol file to a channel, we write

channel SRCMOD[DSTMOD : protocol_file.pp]

Similarly to Java modules files, Java channel file are also generated. Recall from Example2.4.1, the following architecture script

--------------------------------------------game CONNECTFOURGRAPHICSmodule DATAmodule LOGICmodule GUIchannel GUI[DATA]channel DATA[LOGIC]--------------------------------------------

generates the following templates:

· CONNECTFOURGRAPHICS/DATA/GUI_TO_DATA.java· CONNECTFOURGRAPHICS/LOGIC/DATA_TO_LOGIC.java

These files contain definitions for protocol events declarations and functions for eventtransfer.

Example 2.4.3: LIGHTS’s data_to_logic protocol file

This figure illustrates a protocol embedded into the channel DATA_TO_LOGIC, in thisexample this protocol defines a “polling command”. The ISALLON event is used torequest a test from the LOGIC module.

Figure 2.4.1 LIGHTS's DATA_TO_LOGIC protocol file

Example 2.4.4: Game TETRIS gui_to_data protocol file

In this example, we demonstrate how protocols reveal the use of a channel. For instance,the following script shows that the GUI module sends events to the DATA module mostlyfor registering user actions such as moving a Tetris piece. In this case, SETGUITREADYis an example of a ‘setting command’, and GETTETRISSTATE is a 'polling command'.Here are four of the seven protocols defined in the channel GUI_TO_DATA from the gameof TETRIS.

protocol SETGUIREADY(){ setGuiReady();}

protocol MOVEPIECELEFT(){ movePieceLeft();}

protocol MOVEPIECERIGHT(){ movePieceRight();}

...

protocol GETTETRISSTATE(){ TetrisStateRO ts = tetrisState.getTetrisStateRO(); return MM_PROTOCOL_RECV.singletonMM_PROTOCOL_RECV(ts);}

DATA_TO_LOGIC

DATA LOGIC

protocol ISALLON(int [][] mat){ // do something // ... // return result}

We can see that each protocol has a set of commands that will be executed by thedestination module. To be more systematic, the list of commands should preferably bereplaced by a single function that is named according to the corresponding event name.

For example,

protocol MOVEPIECERIGHT(){ movePieceRight();}

Example 2.4.5: CONNECTFOUR data_to_logic protocol file

In this example, protocols with events parameters are presented, this illustrates that eventscan include parameters. This is the entire protocol list for the DATA_TO_LOGIC channelof CONNECTFOUR. Here are some protocols containing events with parameters.

protocol GETWINNER(ConnectFourBoardRO cfs){ return MM_PROTOCOL_RECV.singletonMM_PROTOCOL_RECV ( getWinner(protocol.cfs) );}

protocol ISVALIDMOVE(ConnectFourBoardRO cfb, int col){ return MM_PROTOCOL_RECV.singletonMM_PROTOCOL_RECV ( isValidMove(protocol.cfb, protocol.col) );}

protocol GETEMPTYPOSITION(ConnectFourBoardRO cfb, int col){ return MM_PROTOCOL_RECV.singletonMM_PROTOCOL_RECV ( getEmptySlot(protocol.cfb, protocol.col) );}

All three protocols return an event. To return an event, we write

return MM_PROTOCOL_RECV.singletonMM_PROTOCOL_RECV(...)

'Null' will be returned if the line above is not specified.

The singletonMM_PROTOCOL_RECV method is implemented for memoryefficiency purposes; instead of creating new MM_PROTOCOL_RECV events after everyinteraction, the singleton pattern is used to reduce garbage collection. Events can beconstructed in the normal way.

Example 2.4.6: Communication between modules

In this example, we disclose the code necessary for sending events. The following portionof code is found in the DATA module of the CONNECTFOUR game, this shows us how tosend an event from DATA to LOGIC through the DATA_TO_LOGIC channel. TheMM_PROTOCOL_SEND mmps object is a container that stores an outgoing event. In thiscase, the outgoing event is the protocol GETWINNER with a ConnectFourBoardRO objectas parameter.

mmps = MM_PROTOCOL_SEND.singletonMM_PROTOCOL_SEND ( DATA_TO_LOGIC.GETWINNER.singletonGETWINNER ( this.connectFourStateRW.getConnectFourBoardRO() ) );

mmpr = data_to_logic.DATA_TO_LOGIC__SYNC_MAIN(mmps);

To send this event and store the answer, we write

mmpr = data_to_logic.DATA_TO_LOGIC__SYNC_MAIN(mmps);

In this situation, mmpr contains an Integer object that determines the winner. This numberis accessible by calling

(Integer) mmpr.getContent()

2.5 Simulator

We have just gone through the modelling of a game architecture, and protocols. At thismoment, we almost have a complete runnable game; the only missing part is the simulationof the entire system. To run the system, a simulator is required. In this implementation, themain execution of the game architecture is performed by using a loop. Every module has atick() function which is called at every cycle.

This illustration demonstrates the work done by the simulator.

Figure 2.5.1 The simulator

Module1

tick()

Module2

tick()

Module3

tick()

ModuleN

tick()

…

Timing

Thread Sleep

The simulator features three different timings (or looping methods):

· maximum frame rate (loopMaxRate)· high frame rate (loopHighRate)· fixed frame rate (loopFixedRate)

The maximum refresh rate doesn’t give up any CPU time per cycle; it allows thegame to use the CPU to its capacity. This is effective in games such as first person shooter,because we want to have fast frame rates.

The high frame rate gives up a specific small sleep time to a cycle to allow fastresponses from unexpected context changed such as alt-tabbing. This is useful fordedicated game servers, when graphics is not needed, we may want to give the CPU somerest.

The fixed frame rate gives up a computed amount of time to a cycle to allowapproximately the same number of frame per second. This timing mode is especially usefulin discrete time simulation, or frame based simulation where actions depends on thenumber of frames and not time.

For real-time games, the SYSTEM class provides all the information about thecurrent frame such as current time and previous time, the time difference between thecurrent and the previous frame and the current frame rate. This SYSTEM object can beaccessed by any module, and it gets updated at every cycle.

2.6 Libraries

This project includes three main libraries, one is essential to the Meta-ArchitectureRuntime which is needed by the simulator, the other two libraries are additional packagesfor networking support, and simple GUI framework. Other libraries are games specific,such as the TETRISLIB which is used by TETRISSERVER and TETRISCLIENT. Allthese libraries are written in Java 1.5, and take advantage of the new version features suchas generic types, enhanced for loops and concurrency packages.

2.6.1 Meta-Architecture Game Modelling and Simulation library (MGMS lib)

The Meta-Architecture Game Modelling and Simulation library is the core of the Meta-Architecture implementation. This library contains Modules, Channels and Simulator classdefinitions. As a whole, it is served to simulate the entire system.

Here’s the structure of the package tree:

MGMS | + MODULE | + MODULE.java + MM_CHANNEL.java + MM_PROTOCOL.java + MM_PROTOCOL_RECV.java + MM_PROTOCOL_SEND.java | + SIMULATOR | + SIMULATOR.java + SYSTEM.java | |

MODULE.java

MODULE is a Java abstract class for implementing the module entity, it contains the twoabstract methods init() and tick(). The init() method is called after all the modules havebeen added to the simulator. Then the tick() method is called at every cycle by thesimulation loop. Generated module templates are subclasses of the MODULE class, thesetemplates implement the init() and tick() method.

MM_CHANNEL.java

MM_CHANNEL is an empty interface which is used for implementing the channel entity.Specific channels are sub-interfaces of MM_CHANNEL; they have their protocolsembedded as internal public classes. They also have a public __SYNC_MAIN(MM_PROTOCOL_SEND mmps) method for event transferring. This is the only methodaccessible by module to communicate with another module.

Example 2.6.1: The generated GUI_TO_DATA Java channel file

This example shows the file GUI_TO_DATA.java which is generated by the compiler. Thechannel was declared as following:

channel GUI[DATA]:connectfourconsole_gui_to_data

and its corresponding GUI_TO_DATA.java file

public interface GUI_TO_DATA extends MM_CHANNEL{ public class GETCONNECTFOURSTATE { private static GETCONNECTFOURSTATE singleton = new GETCONNECTFOURSTATE();

public static GETCONNECTFOURSTATE singletonGETCONNECTFOURSTATE() {

return singleton; } }

public class DROPTOKEN { public int col;

private static DROPTOKEN singleton = new DROPTOKEN();

public static DROPTOKEN singletonDROPTOKEN(int col) { singleton.col = col;

return singleton; } }

public MM_PROTOCOL_RECV GUI_TO_DATA__SYNC_MAIN(MM_PROTOCOL_SEND mmps);}

MM_PROTOCOL.java , MM_PROTOCOL_SEND.java , MM_PROTOCOL_RECV.java

These classes are protocol containers; they have a reference to a protocol object, andmethods to set and return their content. MM_PROTOCOL_SEND is used to specify theevent sent by the source module, and MM_PROTOCOL_RECV is used to receive theevent returned by the destination module.

SIMULATOR.java

In this subsection, the implementation of the simulator is described. The SIMULATOR isthe parent class of all the architectures’ runnable class, it contains three looping methodsand the tick() method. It doesn’t contain the main() method. Hence to run this class, themain method must be implemented in its subclass which is the GAME itself. The GAMEwill call the super() method of SIMULATOR, then add all its modules and establish all thechannels, and finally start the loop() method that calls tick(). The SIMULATOR’s tick()method will call the tick() method for each of its module. So the execution traverses all thetick() methods of the GAME’s modules. The code generation will do all work relating tothe simulation, therefore game programmers do no need to worry about anything.

SYSTEM.java

This class stores information of the current frame, as mentioned in the section 2.4, it storesthe current frame time, previous frame time, frame time difference and current frame rate.It is up to game programmers to take advantage of this information to build real timegames.

2.6.1 Communication Lib

The communication package features a sophisticated socket handling; the top layer sendsand receives Java serialized objects, and the underneath transparent layer uses UDP for datatransferring. The complete server and client are included in this package. The server storesa list of connected clients and does routing tasks. Both the server and client have a dataintegrity mechanism, a data ordering mechanism and a synchronization mechanism.

Data Integrity Mechanism

This mechanism checks whether received data are not altered in any way, if they are, thenthese bad data will become error events. Objects that fail during the serialization processwill immediately become error events. If the server (or client) receives an object that itcannot understand; for instance, it doesn’t have the class definition of such object, then thisdata will also be interpreted as an error event.

Here are some examples of error codes:

· ERROR_CLASS_NOT_FOUND· ERROR_DATA_CORRUPTED· ERROR_SERIALIZATION

For more, please refer to CommEvent.java for the whole list of event.

Data Ordering Mechanism

This mechanism will detect any data loss, or out-of-order data, then repair them. For dataloss, the server (or client) will report this incident to its peer, and wait for the missing datato arrive. For out-of-order data, the data will be sorted before they get retrieved. Ifeverything is fine, the data will be appended into the CommEvent Queue. A Data LossEvent will be constructed if the missing data cannot be recovered in a relevant amount oftime, then it is up to the external application to handle this incident.

Synchronization Mechanism

This mechanism does handshaking when there are new incoming connections. If theconnection is accepted, then the client will be added to the server’s list. This process does athree-way handshake to ensure that both parties are properly synchronized.

This mechanism also attempts to keep connections alive by pinging the server (orclient) between intervals. Failure to do so will result in connection loss, and then it will bereported to the CommEvent Queue.

The CommEvent Server

The CommEvent Server contains

· a list of clients· a Send Event Buffer per client· a Receive Event Buffer per client

· a CommEvent Queue

The server dedicates a Send Event Buffer and a Receive Event Buffer to each clientfor the Data Ordering Mechanism, when the Receive Event Buffer contains absolutely noerrors, then all its content will be appended to the CommEvent Queue. Now, thisCommEvent Queue contains communication events, and these events are ready to be polledby an external application.

The server will try to keep all connection alive, but it will remove any client thatfails to respond after a certain amount of time. This incident will be reported by appendinga timeout event into the CommEvent Queue.

The CommEvent Client

The CommEvent Client contains

· the server’s address· a Send Event Buffer· a Receive Event Buffer· a CommEvent Queue

The client does similar work, but instead of having a list of clients; it only contains theserver’s address. Hence, it doesn't do any routing task, and only communicates with theserver.

The client will be disconnected from the server if it doesn’t receive any data for acertain amount of time. This incident will be reported by appending a timeout event into theCommEvent Queue.

2.6.2 GUI Lib

This package only includes an initialized frame, an initialized applet and a double bufferedcanvas. The initialized frame is a JFrame, it contains a label displaying the frame rate of thegame, and it also allows the program to be terminated by clicking the [x] button. Thedouble buffered canvas will remove any stair-case effect by drawing images off-screen, andthen flush the off-screen buffer to the main buffer. In addition, the canvas will initializeimages; it will pre-load them first before attempting to draw them. This package is verysmall, but it provides a quick start for displaying graphics.

2.7 Compiler

To generate source code from an architecture script, a compiler is required. In this project,the written compiler is a multi-stage multi-pass compiler. It reads Game Files, ModuleFiles and Channel Files; then generates the entire game. In addition, the compiler alsogenerates helper scripts that set classpaths, compile the Java source code, and run the game.

2.7.1 Multi-Stage Compiler

The compiler starts by parsing a Game File, and in the meantime, it opens any attachedModule Files and Channel Files for further parsing. If module files and channel files are notattached, then GAME templates will be generated immediately. On the other hand, if thereare attached files, then the compiler will also parse these files to generate a more completesystem. This is done in two stages, the first stage is executed for fast prototyping, and thesecond stage is for architecture upgrade.

Stage One

In more details, the first stage is always performed, when module files and channel files arenot provided, this results in a fast prototyping stage. Fast prototyping is executed byparsing the game file, constructing the Abstract Syntax Tree (AST), verifying the AST andgenerating module and channel templates.

This figure shows the outcome of the stage one code generation process

Figure 2.7.1 Stage 1 code generation

Example 2.7.1: Generated files and directory structure

This is an example illustrating the directory structure generated by the compiler.

GAME/GAME/GAME.javaGAME/MODULE1/MODULE1.javaGAME/MODULE1/MODULE2_TO_MODULE1.javaGAME/MODULE1/MODULE4_TO_MODULE1.java…GAME/MODULE2/MODULE2.java…compile.shrun.sh

The GAME label is to be replaced with the game name, and MODULE with other modulenames, etc.

architecture.gg

game …

module ...…channel ……

CompilerModule Templates

Channel Templates

Game Compilation and Run Scripts

Main Executable

Stage two

The second stage is only executed if module files and channel files are attached. This stagewill alter the AST by refining the module and channel nodes. For example, extra sourcecode from module files will be inserted into the corresponding nodes. This code will beembedded into the game during the code generation phase.

Similarly, the stage two generates the same files, but module templates and channeltemplates contain extra code that comes from module files and channel respectively.

Figure 2.7.2 Stage 2 code generation

2.7.2 Multi-Pass Compiler

From another perspective, this compiler uses a multi-pass technique. The entire process isdone in four phases.

1) Parsing and AST Construction2) Symbol Table3) Type Checking4) Code Generation

In Phase 1, game files, modules files and channel files are parsed, and then an abstractsyntax tree will be built. This AST stores the parsed file in form of nodes, if module andchannel files are attached, then extra code will be inserted into the corresponding nodes.

architecture.gg

game …

module ...…channel ……

CompilerModule Templates

Channel Templates

Game Compilation and Run Scripts

Main Executable

Module Files

Channel Files

In phase 2, the compiler will verify if identifiers are declared correctly. For example,we cannot declare two modules using the same name, or two channels connecting the samemodules, etc.

In phase 3, the compiler checks the type of each identifier. For example, each channeldeclaration requires two module identifiers; other types of identifiers are invalid.

And finally in phase 4, all the source code and helper scripts will be generated. TheAST will be traversed multiple times to generate different files.

3 Games

In this section, we present three different games built using Meta-Architecture concept.Each game also comes in different versions, some with minor changes, and others withextra features. These modifications demonstrate the evolution of their architectures.

All the first versions of each game are built by following the same procedure:

1. Begin with fast prototyping2. Add some protocols3. Refine modules4. Run the compiler5. Test the game6. Go back to step 2 until game is completed.

3.1 LIGHTS

Lights is a simple game built during early stages of Meta-Architecture for GameDevelopment, this small game demonstrates the concept of Meta-Architecture.

The goal of this game is to light up all the black spots. Clicking on a spot will flipthe state of the adjacent spots.

Figure 3.1.1

The architecture of LIGHTS

Figure 3.1.2 The architecture of LIGHTS

In this design, the DATA module stores the game board, the LOGIC module tests ifall the lights are on, and the GUI module displays the game content.

CHANNELs are established in such way to formulate these three processes.

· DATA sends ISALLON event to LOGIC to test if lights are all on.· DATA sends the board state to GUI for display.· GUI detects mouse clicks and sends actions to DATA.

This game is extremely simple; it requires no additional libraries, or other java files.The entire game is assembled using architecture, module and channel files.

3.2 CONNECTFOUR

In this project, three versions of Connect Four are written, a console, a graphical and anetworked Connect Four. The console and the graphical versions acquire the same designand architecture; the only difference lies in the GUI module, which has a minor change indisplaying content. The networked version requires architecture expansion; a module thathandles networking is added into the system.

LIGHTS

DATA LOGIC

DATA_TO_LOGIC

GUI

GUI_TO_DATA

DATA_TO_GUI

3.2.1 CONNECTFOURCONSOLE

Screenshot of CONNECTFOURCONSOLE

Figure 3.2.1 CONNECTFOURCONSOLE screenshot

The architecture of CONNECTFOURCONSOLE

Figure 3.2.2 The architecture of CONNECTFOURCONSOLE

The DATA module contains a state machine, and functions used to perform useractions. The LOGIC module acts like black box to test who is the winner. The GUI modulecontains a painting state machine, since the GUI requests the game state by a 'pollingcommand', the DATA module returns the read-only version of the game state forconvenience. This will disallow GUI to alter the game state.

CONNECTFOURCONSOLE

DATA LOGIC

DATA_TO_LOGIC

GUI

GUI_TO_DATA

This CHANNEL layout allows:

· DATA to perform tests by sending GETWINNER, ISVALIDMOVE andGETEMPTYPOSITION events to LOGIC.

· GUI to request the game state by sending a GETCONNECTFOURSTATE event tothe DATA.

· GUI to send a DROPTOKEN event to the DATA for dropping tokens.

3.2.2 CONNECTFOURGRAPHICS

This is the 2D graphical version of the previous game; CONNECTFOURGRAPHICS hasexactly the same architecture as CONNECTFOURCONSOLE. The only changes lie insidethe GUI module, instead of displaying the board in text mode, the board is represented in2D graphics.

Screenshot of CONNECTFOURGRAPHICS

Figure 3.2.3 CONNECTFOURGRAPHICS screenshot

For this game, the game states are stored in the DATA folder. Since we hadchanged the GAME label, both the directory structure and the classpaths changed, thereforewe need to fix the import section of the module templates by repairing the classpaths. Toavoid this problem, we can create an external library where its classpath lies outside of thegenerated tree. The effort required for this modification is negligible, only the GUI moduledemands content change. To drop tokens, the text input usage is being replaced by mouseclicks, and then action events are sent to the DATA module exactly in the same way asbefore.

3.2.3 CONNECTFOURNETWORK

This version of Connect Four adds network support to the CONNECTFOURGRAPHICSthrough the GUI module, without altering other modules, game states and game rules. Todo this, a P2P module is added into the architecture, it has 2 channels, one incoming fromGUI and the other outgoing to GUI. This design does not require any modification in gamemechanics; we can use the existing unaltered state machine and game logics. This is doneby redirecting I/O to server and client.

For the client, the GUI will request the ConnectBoardState from the P2P moduleinstead of the data. All input actions (such as token drop / mouse clicks) will be redirectedto the server.

For the server, the P2P module will send the ConnectBoardState to its client. If thegame’s current turn belongs to the client, then the server accepts input actions from theclient, otherwise it only listens to its own mouse clicks.

The server and client are both the same program, the game starts by being the hot-seat version, and it

· becomes the server if the command /host is entered.· becomes the client if the command /connect address is entered.

Screenshot of CONNECTFOURNETWORK

Figure 3.2.4 CONNECTFOURNETWORK screenshot

In this screenshot, the server and client look identical. But behind the scene, theserver is the one which update the game state and send the data to the client. The clientsends actions to the server if there are user inputs such as mouse clicks.

This design allowed adding support to Connect Four without much effort,redirecting the I/O can be a good design, especially in this case.

The architecture of CONNECTFOURNETWORK

Figure 3.2.5 The architecture of CONNECTFOURNETWORK

3.3 TETRIS

Tetris is one of the most popular games; therefore I decided to build it using the Meta-Architecture approach. In this project, this game is semi-real-time; it uses frame-basedtiming at a nearly constant frame rate (around 25±2 fps). In other words, the simulationtiming (or calculation) is computed based on the number of frames, and not on time.

Two versions of Tetris are designed and implemented. The single version is aprototype, the game is runnable, but only the same block falls. The multiplayer versionincludes a graphical game client and a dedicated server.

CONNECTFOURNETWORK

DATA LOGIC

DATA_TO_LOGIC

GUI

GUI_TO_DATA

P2P

GUI_TO_P2P

P2P_TO_GUI

3.3.1 Single Player TETRIS (Prototype Version)

Figure 3.3.1 TETRIS screenshot

The architecture of TETRIS

Figure 3.3.2 The architecture of TETRIS

TETRIS

DATA LOGIC

DATA_TO_LOGIC

GUI

GUI_TO_DATA

Once again, TETRIS has the same architecture as CONNECTFOURGRAPHICS,because this architecture is quite simple to work with. Game content and rules are createdin a similar style. Therefore, I will not give out extra details regarding this version of thetetris game.

3.3.2 Two-Player Networked TETRIS (i.e. TETRISNETWORK)

This version is inspired by the coop hot-seat version of the Tetris game. Originally, thisgame is played on a single game console; but now, it can be played over the internet.

Figure 3.3.3 Two-player networked Tetris screenshot

The architecture of TETRISSERVER (Dedicated Server)

Figure 3.3.4 The architecture of TETRISSERVER

Similarly to previous game architectures, TETRISSERVER keeps two existingmodules, the DATA and LOGIC modules, but their content differs from the single playerversion of TETRIS, since this is the networked multi-player version, the state machine andgame logics should behave differently. The ROUTER replaces GUI, but it serves the samepurpose, it handles the game I/O. But instead of displaying graphics and receivingkeyboard button events, it sends out game states and receives client actions.

The architecture of TETRISCLIENT (Graphical Client)

Figure 3.3.5 The architecture of TETRISSERVER

This design leads to a dummy graphical client, the client has no game logics, it onlydisplays the data sent by the server. According to the above figure, the GUI modulerequests the game state from the PROXY module.

TETRISCLIENT

GUI PROXY

GUI_TO_PROXY

TETRISSERVER

DATA LOGIC

DATA_TO_LOGIC

ROUTER

ROUTER_TO_DATA

The overall design

The server communicates with the clients through virtual ROUTER_TO_PROXY andPROXY_TO_ROUTER channels. This is achieved by inserting a communication serverinto the ROUTER module, and a client into the PROXY module.

Figure 3.3.6 The overall networked tetris design

Both the Tetris server and client use an external TETRISLIB library, because theyshare some of the game content. External libraries outside of the generated directory pathcan also eliminate some troubles such as repairing the import classpaths (as mentioned insection 3.2.2). This can happen when the directory structure gets altered after a designchange; as a consequence, some class definitions will not be found. Therefore, externallibraries are recommended to avoid these risks.

TETRISSERVER

DATA LOGIC

DATA_TO_LOGIC

ROUTER

ROUTER_TO_DATA

TETRISCLIENT

GUI PROXY

GUI_TO_PROXY

TETRISCLIENT

GUI PROXY

GUI_TO_PROXY

4 Related Work

Modelling and Simulation, Software Engineering, Game Architecture and Design[1] often propose new and better methods for building large systems. These areas alwaysmention how fast-prototyping, software design, modelling can help building applications ina much simpler way. Therefore, a multitude of Computer-aided Software Engineeringsystems [2] are built for software development, they include editing tools, prototypingtools, re-engineering tools, etc. These tools are specifically designed for softwaredevelopment, but they can be applied to computer game development.

Game Construction Systems and Languages is a particular area for moderncomputer games research; it focuses on discovering techniques and applications to speed upthe process of game development. Generally, these applications allow us to build gameswith less programming effort by generating games from scripts. Meta-Architecture forGame Development can be assigned to this research area. This experiment is not the onlyone of its kind; there are many others such as EGGG [3], METAGAME [4], Morphling [5]and Multi-game [6]. These applications are capable to design, create or play all the gamesthat belong a specific domain.

For example, EGGG is an application that allows users create almost all kinds ofgraphical two-dimensional games. Instead of focusing on game structures, it aims at thegame process. Games are described as a series of statements. Unlike Meta-Architecture, theEGGG Language is a descriptive language, it doesn’t model any flow control, and thereforeit is not a program.

Alternatively, METAGAME also allows users to describe games and have thesegames generated by a compiler. But METAGAMES is much more restrictive, thisapplication only generates a very limited range of games that belong to the SymmetricChess-Like Games. Within this framework, games are described by declaring gameobjectives, rules, setups and constraints.

On the other hand, the Morphling is not a program that can only design the wholeclass of two-player combinatorial games, but in addition, it can also play them. Thisapplication comes in form of a graphical game editing tool, the game board layout can beadjusted using the editor, and game rules can be defined in using the editor.

Similarly, Multigame is a very high level language for describing board games andcreating games. Interestingly, its compiler can analyze game rules and generate a parallelprogram that plays the game. Generating game AI allows programmers to save some effortfrom designing and implementing an AI system.

In contrast to these applications, Meta-Architecture allows users to create all sortsof games, without restricting itself to generate a specific class of games. Because Meta-Architecture works on a higher layer of control flow, instead of generating specific gamesfrom scripts, it generates architectures and establishes communications between sub-systems. And then, we can embed contents into the whole system to form a complete game.

5 Future Work

There are many possible improvements for Meta-Architecture for Game Development, andthere are also some research directions that could be expanded. Regarding libraryimprovement, we can refine the existing packages, add TCP support to the networkingengine, build a better GUI framework, or provide more game libraries in the form ofmodules.

Building more games can also be one of the options, but re-implementing multi-game engines such as EGGG, METAGAMES, Morphling and Multigame within the Meta-Architecture framework would be more challenging. If achieved correctly, then we canmake them share the same GUI module, and hopefully, networking support can be madepossible by using a P2P module which is designed like the one from the networked versionof Connect Four.

During the progression of the project, an interesting forethought intervened; it maybe technically possible to allow the Meta-Architecture Simulator to support hot-swappablemodules. This would permit us to replace or add a module during the simulation. Thisfeature may allow game servers and client to be upgraded or patched without beingrestarted.

Since the code generator generates Java code, for convenience, the compiler shouldbe re-written in Java, so that we do not need a C compiler. Alternatively, we can re-implement the compiler to generate C/C++ code, and rewrite the entire framework andlibraries in C/C++. The Meta-Architecture would then be more directly applicable to thecurrent game development environment, where C/C++ is more dominant.

6 Conclusion

I have described an approach to design computers games, and then I built an applicationthat can make game development less complicated. Using this application, differentversions of three games were successfully written with minimal effort. For each game, thefast prototyping feature allowed me to start with a simple architecture, and generate anentire compilable and runnable vanilla system. Then I added essence to this system totransform it into the final game.

The code generated had saved me lots of effort; I didn’t have to integrate anysubsystems into a whole application. Making minor game modifications is easier thanbefore; for example, to convert the console version of Connect Four into the 2D version,only the GUI module needs to be modified. Upgrading a game still required a decentamount of effort; for example, to add networked multi-player support to Tetris, the gamearchitecture, the game content (state machine, rules), all of these need to be altered. Thereason behind is that we have to build a Tetris game server and a game client, butmodelling them is quite straightforward.

To summarize the benefits, this application is really helpful in five differentperspectives; which are flexibility, extensibility, simplicity, modularity and speed. Meta-Architecture for Game Development has met all its expectations and goals; hopefully it willcontinue to grow in features. We anticipate more games and multi-game engines builtwithin this framework.

References

[1] Andrew Rollings and Dave Morris. Game Architecture and Design, New Riders,2003.

[2] Ian Sommerville. Software Engineering, the 5th edition, Addison-Wesley, 1998.

[3] Jim Orwant. EGGG: Automated programming for game generation. IBM SystemsJournal, 39(3 & 4), 2000.

[4] Barney Pell. Metagame in Symmetric, Chess-Like Games, University of Cambridge, Computer Laboratory Technical Report No. 277, 1992

[5] Ingo Althöfer. Computer-aided game inventing, Reports on Optimization,Friedrich-Schiller-Universität Jena, TR#3-11, March 2003.

[6] John Romein, Henry Bal, Dick Grune. Multigame - a very high level language fordescribing board games, in "Proc. First Annual Conference of the Advanced Schoolfor Computing and Imaging ASCI", May 1995, pp. 278-287

Appendix

(Source code and games on CD)