Development of Chapas an Open Source Video Game with Genetic Terrain Programming Nelson Rodrigues
Miguel Frade
F. Fernandez de Vega
Centro Univ. de Mérida Escola Superior de Tecnologia e Gestão Univ. de Extremadura Inst. Politécnico de Leiria España Portugal
[email protected] [email protected]
Abstract Chapas is a turn-based bottlecap racing game, developed with the implementation of Genetic Terrain Programming techniques in mind, resorting solely on open source tools. This paper describes the development process of the game itself, as well as the potential of Chapas as a platform for testing new terrain generation techniques and arti cial intelligence algorithms.
1
Introduction
Many educators have taken an interest in the eects that video games have on players, and how some of the motivating aspects of video games might be harnessed to facilitate learning [18]. Initial studies comparing video game teaching eectiveness to the classic lecture show positive improvements, typically 30% or more [14]. These results point out the important role video games can play on education. Games are also ideal test beds for computational intelligence theories, architectures and algorithms [13]. We wanted to test the suitability of the Genetic Terrain Programing (GTP) technique to generate terrains on a real game. For these reasons, we wanted to gain experience on building a video game from scratch and do it recurring only to open source tools. This way we can release the source code without any restrictions and contribute to the community by sharing our code and knowledge.
Centro Univ. de Mérida Univ. de Extremadura España
[email protected]
This was the genesis of the Chapas video game project with a partnership between Centro Universitario de Mérida (Universidad de Extremadura), GLOW [10] and Junta de Extremadura, Spain. In this paper we detail the technical development of Chapas video game, the used tools and hurdles found during the process. Section 2 details the research and selection of the game engine to be used in the project, as well as the Genetic Terrain Programming technique. The physic engines and its application are presented in Section 3. Section 4 explains the network implementation, Section 5 details the user interface and Section 6 presents some considerations about video game testing. Finally, the conclusions are presented on Section 7.
2
Background
Chapas is an open source turn-based bottlecap racing game, with 3D graphics, where the players strategically control the racers with cards. A typical round of Chapas starts by dealing 9 random cards to each player. Each of these cards represents movement points for the dierent bottlecaps. Afterwards, an auction takes place, where the players use their money (an initially set amount, that accumulates over dierent rounds), to buy the bottlecaps better suited to each player's cards. Finally the race phase starts, where the players use their cards, on their respective turn, to
move the bottlecaps across the eld, passing through each checkpoint (where they can restock their cards for money). The round ends when every player has reached the nish line, or ran out of cards. The Chapas video game project is under development for the past 16 months by a team of 7 persons: one manager and three programmers from Centro Universitario de Mérida and three designers from GLOW. Only one programmer has been working full time on the project, everyone else has been on partial time. The game development cycle is composed of several phases, starting from devising a concept and researching its feasibility, passing through the implementation, design, and nally the testing stage. After the de nition of Chapas script came the technical decisions on how to implement it. Choosing the game engine is of most importance due to its in uence on the entire project. Based on previous research [19] done by the programmers team, Panda3D was chosen as the open source game engine among 121 possibilities. The criteria used, in the aforementioned research, was: 3D capability, multiplatform, multi-API (OpenGL and Direct3D), type of license, documentation quality and development stage. In the end, only three engines passed all criteria: Panda3D, Torque Game Engine and Ogre3D. While Torque Game Engine was the winner previously, its non-free license was not desirable for this project. Ogre3D also felt short by not having built-in network support. Panda3D is a framework for 3D rendering and game development in Python and/or C++ programs, developed by Disney and maintained by Carnegie Mellon University's Entertainment Technology Center [4]. This game is also a platform for testing terrains generated with Genetic Terrain Programing (GTP) technique. This technique uses Genetic Programming (GP) to evolve mathematical expressions, designated Terrain Programs (TPs), which can be executed procedurally. The rst implementation of GTP was interactive [6, 8], were the user guided the evolution by choosing terrains accordingly to
Figure 1: Terrain represented as a grayscale image
Table 1: In-game terrain generation times. Dimension
Time
(height × width) 128 × 128 256 × 256 512 × 512 1024 × 1024
(seconds) 0.25 0.96 3.82 15.49
his aesthetic feelings or desired features. However, the search for a terrain with speci c features might be a tiresome endeavor on interactive evolutionary applications [3]. Therefore, the technique was improved and a new version of GTP was presented that performs automatic evaluation of terrains based on accessibility constraints [7], or based on obstacles edge length [9]. On the rst attempt to integrate TPs on the game, terrains were computed with the noise library in Blender. The result was then turned into a grayscale image (see Fig. 1), which were loaded into Panda3D. This data was passed to a Panda3D class, namely GeoMipTerrain, which would generate the terrain represented in the grayscale image. This process was deemed ine cient, as not only it was too slow, as it also required either an installation of Blender, or pre-generated grayscale images. For the second approach, the noise library
Dx
y
Terrain area at 100% Dx/ S x
Dy Sy
View area
Lx
(0,0)
Dy
Ly
x
Figure 3: Terrain view area Figure 2: Early generated terrains using both approaches. was made independent from Blender, eliminating the need to generate the grayscale image. With the library fully integrated in the project, the height map could now be generated dynamically, and passed directly to the GeoMipTerrain class, drastically reducing generation times. Given the dimensions of a level in this kind of game, a 128 × 128 terrain is already enough. As we can see in Table 1 a larger terrain can still be generated relatively fast with this approach. However, further optimizations would have to be implemented if a terrain larger than 512 × 512 was necessary, namely a full conversion of the terrain generation algorithm from Python to C++. On Fig. 2 we can see the early results of both approaches. The terrain on the left was generated with the rst approach, corresponding to the grayscale image in gure 1. On the right, is a terrain generated with the second approach from the TP shown in (1), where myLog(a) returns zero if a = 0 and log(|a|) otherwise.
Table 2: Used parameters to generate the terrain on the right side of Fig. 2. Value
and and and and
10.0 0.0 2.0 128
Dx Lx Sx nr
Dy Ly Sy nc
whose size nr × nc depends on the amount of samples that de ne the height map resolution. Equation (2) shows the relation between the height map matrix H and TPs continuous function. hr,c represents the elevation value for row r and column c, and Dx , Dy are the terrain dimensions. Sx , Sy allow the control of the zoom level and Lx , Ly allow us to localize the origin of the terrain view area (see Fig. 3). Table 2 shows the parameters used to generate the terrain on the right side of Fig. 2.
hr,c =f
T P =myLog(myLog(myLog(myLog(myLog(
c×
Dx nc −1
Sx
+ Lx ,
r×
Dy nr −1
Sy
! + Ly
r ∈ {1, · · · , nr }, c ∈ {1, · · · , nc },
myLog(f Bm(x, y, 0, 1.0, 1.97, 2))))))) (1)
The terrains are represented as height maps and to create them, from a TP, the continuous surface must be sampled with xed increments of x and y to obtain the corresponding altitude z , where z = f (x, y), x, y, z ∈ R. The altitudes r values are stored in matrix H = {hr,c }r≤n c≤nc ,
Parameter
+
Dx , Dy , Sx , Sy ∈ R
3
(2)
and Lx , Ly ∈ R
Physics
The interaction of objects within the game requires the use of a dynamics simulation engine in order to enact real world physics, by
applying and using its known laws. This is accomplished by using data structures (such as bodies and respective masses, densities and friction coe cients), to store the information needed for a relatively accurate simulation, as dierent forces are applied to the objects. The bodies are inserted into a container (world) and all the data and physics calculations come into play when a world step is performed. This world step consists of a time frame where the physics are simulated. For example, considering a body at position x at time t, the engine calculates where it is supposed to be at time t + 1, taking into account all the forces applied to the object, and current trajectory. The dynamics simulation engine resorts to physics systems to perform calculations. Panda3D has two integrated physics systems: the built-in physics engine and the Open Dynamics Engine (ODE) [16]. ODE is still an experimental system, but it already far surpasses the built-in engine, being capable of much more realistic and con gurable simulations [16]. Thus, this engine was chosen for the main game loop. ODE is an open source rigid body physics engine that has some popularity in the eld, both in open source and commercial applications and as a platform for scienti c research [17]. The engine was designed so that the collision detection system is separated from the dynamics simulation. The collision system consists in using simple geometry (e.g.: spheres, cubes, cylinders), or complete triangle meshes. The latter should be avoided whenever possible, as it is slower and more prone to mistakes. This geometry is used to calculate collisions in real time, and report them, along with the collision data, to a callback method. Panda3D has an automated system to handle the callback's repetitive tasks. To determine which objects are supposed to collide among themselves, a bitmask system is used. Each dierent kind of object has it's own bitmask, and every time a collision is detected, a logical AN D operation is performed on the two bitmasks. If the result is dierent than zero, then those two geometries are considered for collision.
There are also other tasks that involve collision detection, such as clicking an object, that were accomplished with the more simplistic built-in engine, since an actual simulation is not required for this kind of task.
3.1 Problems and di culties There were quite a few complications and limitations inherent to these systems. The following are some of the most relevant that were encountered. One of the most important problems was the bottlecap's representation in the physical world, since ODE's collision detection system does not detect collisions between cylinders. However, the built-in Panda3D collision detection system does detect this kind of collision. So, in order to use this collision system and still process it with ODE's dynamics simulation, an implementation of the conservation of momentum and elastic collision's theory [5] was written, in order to connect both systems, providing a relatively accurate simulation of a real collision. Cylinders collisions.
Any ODE collision involving trimeshes is faulty, and the engine requires smaller time steps to detect the collision itself, resulting on slower performance for more accuracy. However, the most reasonable solution for the terrain body is using a trimesh due to it's pseudo-random nature. This has generated several problems to date, some of which are still being analyzed, such as occasional nonexistent collisions on a at plane, in which the bottlecap seems to collide, when there's nothing there. Though, this problem has not manifested itself on non- at terrains. Trimesh collisions.
issues. Over time various performance issues arose, aecting the gameplay experience greatly. Here are some of the main solutions for increasing the performance that were used: Performance
Gathering all of the non-moving nodes
into one single node, decreasing drastically the number of individual nodes. Using a smaller terrain with a larger scale, emulating a terrain of the same size, while having a lot less polygons. Freeing unused resources during the race phase. After these and many other improvements, the performance rose from an unstable 10 frames per second to a satisfactory [1] average of 60 frames per second, rarely going below 30 frames per second, on the development machine (Ubuntu 8.10, Intel Core2 Duo 2.8GHz, Nvidia GeForce 9700M GT 512MB). Discrepancies
in
Physics
Emulations.
Initially it was assumed that on dierent clients, a physics emulation initiated with the same values would wield the same results. This way, it would be possible to send the clients only the force and direction for each bottlecap, and perform the emulation locally. However, it was later found that this is not the case, the minor dierences from client to client accumulate over time and become quite noticeable. For this reason, the physics system had to be centralized in the server, with only one emulation running. At each iteration the bottlecap's positions are sent to each client, and the former places them manually. While this increases the network tra c considerably, it was found to be the best working solution.
4
Network
The network support in the game is built on the Networking API [16] provided by Panda3D. A client-server paradigm is used for both single player and multiplayer. Panda3D's network support is based on polling, as a synchronous activity, due to the lack of threading support of the engine. However, a recent version of the latter does have an experimental threading support, but has not been used since the previous implementation is functional for six players, the maximum number allowed in Chapas.
The network system implemented consists of a server being created when an user chooses to start a game, and afterward a client is created for each player. The server acts as the main node of the game, used to broadcast player's commands, notices and messages. The server is also responsible for adjusting the client's physical inaccuracies, ensuring the simulation remains equal for all players. Depending on how the players are distributed spatially, the gameplay is aected. On each turn, the network system allows all players who are able to play simultaneously to do so, meaning that if all players are on dierent computers, they will all play at the same time, while if all players are on the same computer they play in turns. Thus, the gameplay experience varies depending on the physical distribution of the players. This allows for the players to customize their experience, and still be able to play the game with the maximum number of players, regardless of the number of computers they have access to.
5
Graphical User Interface
A graphical user interface (GUI) consists of graphical icons and visual indicators, as opposed to text-based interfaces, to fully represent the information and actions available to a user. Any game requires a functional GUI in order for the players to properly con gure it, and interact with the game itself, thus generating visual feedback. In Chapas, the user interface consists of the regular menu items for con guration (see Fig. 4), and various HUDs 1 representing relevant information such as player status, current cards, force and direction, among others. In order to create these elements, classes based on Panda3D's DirectGUI modules [16] were created, in order to implement a custom look envisioned by the designer's team (ses Fig. 5). In order to reach as many audiences as possible, there is an internationalization and lo1 HUD
(head-up display) is the method by which
information is visually relayed to the player as part of a game's user interface. It takes its name from the head-up displays used in modern aircraft.
Figure 5: Screen shot of Chapas during play
Figure 4: Screen shots of Chapas con guring players names (top) and choosing cards sets (bottom)
calization system in place. Internationalization is the process of adapting an application so that it can be translated to various languages without internal changes, and localization is the process of adding locale-speci c components for a speci c language, in order to adapt it to a region. The solution used in the game is the GNU gettext system [11, 15], which is a set of tools that provide a framework for producing multilingual messages. This way, in order to translate the game into a new language, the translator simply has to translate a previously exported text le that contains all the translatable strings in the game, open it with a regular text editor, and send the le back to the developers, so that it can be included in the source (see Fig. 6).
5.1 Resources This section describes how the resources used throughout the game, such as 3D models, audio and texture artwork, were created.
Figure 6: Screen shot of Chapas language menu
and Textures. On a threedimensional virtual environment, the objects (regardless of inanimate or living) are represented by three-dimensional models. In order to create these models, a designer may employ various modeling techniques, in this case, the modeling of splines, which depend on curved lines to de ne the visible surface of the model. Then, a second designer draws the detailed textures, and maps them to the splines, which results into a detailed 3D virtual representation of a real (or ctional) object. These models are then converted into the .egg format, using one of Panda3D's exporting tools [16], so that they can be imported into a Panda3D scene. In order to avoid placing several hundreds of these models in a scene manually, a coordinates and rotation export script was written, as well as a parser class for importing the results, thus automating the process. All conceptual art, as well as graphical design 2D and 3D used in Chapas was created Models
by GLOW, an audiovisual studio specialized in generating digital content for mediums [10], based in Almendralejo, Spain. Music. Music is an important environmental element in video games, often a major factor in setting the mood and pace of the scene. For the music heard during the menu navigation, player setup and auction, a track by the Special Quartet Namouche [2], The Search was used, in collaboration with local musicians, who were kind enough to allow the use of their music in the game. As for the music heard during the race itself, a track from a community dedicated to share free music under Creative Common licenses and the Free Art License, Jamendo [12], was used. More speci cally, A La Machette from the Tribal album, by Chriss Onac.
6
Testing
Finally, after most requirements have been met, and the coding process completed, the software must be tested to ensure it is released with as few defects as possible. So far the game was released to three students that volunteered as testers, and provided feedback via a Trac ticket report system2 . The students tested the game under dierent operating systems on dierent computer setups, and found various bugs on both the installation and the application. These tickets were then resolved by the programing team, and the testing cycle subsequently repeated itself on every development iteration. Through this process, the stability and robustness of the product, and consequently its quality, was improved to a great extent. On a second phase we will try gather a broader audience of testers before the nal release.
7
Conclusion
The technical details behind the development of the Chapas video game have been presented. The main proposed requirements have been 2 http://trac.edgewall.org/
met and the main coding process is completed. The game was released to a small group of student volunteers for beta testing, to ensure the game has as few faults and bugs as possible. In spite of some hurdles, this project showed that is possible to develop a multi platform 3D game recurring only to free and open source tools. The suitability of the GTP technique to generate terrains was also demonstrated. This video game showed potential to be used as a platform for the research of other evolutionary algorithms. The Chapas video game is still in progress and so far only the Prehistory level has been released, but other levels are foreseen such as the Egypt Civilization. Work must done to spread the word and gather more attention over this project to reach a broad audience and enable the creation of both players and developers communities. To reach this goals a playable release of Chapas is now available for the public at https://forja.unex. es/projects/chapas.
Acknowledgments The third author acknowledges the support of the following projects: TIN200768083-C02-01 (Nohnes project, Spanish MSE); PDT-08A09 and GRU-09105 (Junta de Extremadura). Thanks are due to the Special Quartet Namouche band for their musical contribution.
References [1] Mike Acton. How much does framerate matter? website, (accessed Apr. 2010). http://www.insomniacgames.com/ blogcast/blog/mike_acton/1503082. [2] Badejazz. Badejazz. website, (accessed Apr. 2010). http://www.badejazz.es. [3] Peter Bentley. Evolutionary Design by Computers. Morgan Kaufmann Publishers, Inc., CA, USA, 1999. [4] Carnegie Mellon University's Technology Center. Building virtual worlds. web-
site, (acessed Apr. 2010). http://bvw. etc.cmu.edu/.
[10] Glow. Glow. website, (accessed Apr. 2010). http://www.theglow.es.
Crowell. ConservaLight and Matter. www.lightandmatter.com, Fullerton, California, April 2010.
[11] GNU. gettext. website, (accessed Apr. 2010). http://www.gnu.org/software/ gettext/.
[5] Benjamin
tion Laws.
[6] Miguel Frade, F. Fernandez de Vega, and Carlos Cotta. Modelling video games' landscapes by means of genetic terrain programming - a new approach for improving users' experience. In Mario Giacobini et al., editors, Applications of Evolutionary Computing, volume 4974 of LNCS, pages 485490, Napoli, Italy, 2008. Springer. [7] Miguel Frade, Francisco Fernandez de Vega, and Carlos Cotta. Evolution of arti cial terrains for video games based on accessibility. In Cecilia Di Chio et al., editors, Applications of Evolutionary Computation, volume 6024 of Lecture Notes in Computer Science, pages 9099. Springer, 2010. [8] Miguel Frade, Francisco Fernández de Vega, and Carlos Cotta. Breeding terrains with genetic terrain programming the evolution of terrain generators. In-
ternational Journal for Computer Games Technology, 2009(Article ID 125714):13, 2009.
[9] Miguel Frade, Francisco Fernández de Vega, and Carlos Cotta. Evolution of arti cial terrains for video games based on obstacles edge length. In IEEE
Congress on Evolutionary Computation 2010, page 8, Jul. 2010. (in press).
[12] Jamendo. Jamendo - free and legal music downloads. website, (accessed Apr. 2010). http://www.jamendo.com/. [13] Simon M. Lucas and Graham Kendall. Evolutionary computation and games.
IEEE Computational Intelligence Magazine, 2006.
[14] Merrilea J. Mayo. Games for science and engineering education. Commun. ACM, 50(7):3035, 2007.
A tutorial on Native Language Support using GNU gettext. Project
[15] Gora Mohanty.
Rebati, 2004. http://oriya.sarovar. org/docs/gettext/. [16] Panda 3D. Panda3D manual. website, (accessed Apr. 2010). http://www. panda3d.org/wiki/index.php/Physics. [17] Russel Smith. Open dynamics engine. website, (accessed Apr. 2010). http:// www.ode.org. [18] K.D. Squire. Video games in education. Int. J. Intell. Games & Simulation, 2(1):4962, 2003. [19] Flávio Timóteo and Nelson Rodrigues. Adrenaline. Technical report, Instituto Politécnico de Leiria, Leiria, Portugal, 2007. (in portuguese).
