Client-Server Technology and Generic Game Clients

In the commercial world, creating both a client and a server for a specific game application is considered acceptable. Additional staff can be hired to perform the coding and control maintained over the workers to ensure the client and server work together.

In the open source community, however, development works best the more modular an application is, because it can be developed independently by a variety of people not all under the same control, relying on standard API's, cross-platform libraries, open file formats, and established system architectures. Unfortunately, while these strengths have been employed on many kinds of software, the open source community has had more trouble with game development.

One of the reasons for this trouble is the lack of open standard, API's, etc. Without these things in place, each game project must "reinvent the wheel" and devote large chunks of resources to implementing their own protocols, file formats, and so forth. Since they are not standards, it is difficult to share the work with other projects.

Another issue with open source game development has been that often games lack sufficient quality artwork, or require much more than a small team of artists can produce. Exacerbating this problem is the fact that the tools artists enjoy are very diverse and usually also very expensive. And since these proprietary tools lack common file formats, it becomes technically difficult for the work of more than a handful of artists to be used together.

For these reasons, it is believed that creation of general purpose client/server pairs, relying only on standard graphic file formats for which freely available, interoperable editors are available, is best for the open source community.

Traditionally, there is a strong dependency between a given client and server. With early proprietary games the client would have a huge amount of game-logic embedded in it, so that the network interactivity could be minimized. As it was discovered that clever players could hack their clients to provide extra info or allow them to submit instructions they shouldn't, it became evident that the client should not be trusted to determine the game physics or logic.

In practice, the client still performed some game logic but was not trusted, and only the server's engine would be considered correct. But in theory, because game logic is moved off to the server, the client could be designed to be ignorant of game rules entirely, opening the possibility of having a generic client, that could play a variety of different kinds of games. Unfortunately, a game logic alone does not define the game - graphics and user interface also play a large part in determining the game experience. In order to make a truly general purpose client, one needs to be able to distribute not only game logic control, but also graphics and user interface definitions to the client. SVG and XUL address these latter needs, respectively.

Perl

Game programmers tend to be very demanding of the performance of their games. Thus traditionally, low languages such as Assembler, or C++ have been preferred. Recently, scripting languages have been recognized as providing a quick way to code a game, with an allowable degredation in performace. In the open source world, acceptance of scripting languages for game development has been much wider, perhaps largely due to the fact that open source games tend to lag machine performance much more so than commercial game developments. Indeed, commercial game developers are famous for pushing hardware to its physical limits.

While many scripting languages have been employed for game development, Perl has not been one of them. While there are a few small Perl games, including some web-based games, it is not a commonly used language, exemplified by the lack of Game-relevant code modules on CPAN.

However, Perl is a fun language to code in, for a variety of reasons. It is possible to do very powerful things in a short amount of code. It is well documented and has a vast wealth of libraries and reusable programs. It is well suited for text processing, database operation, and network interactivity. It has good support for many of the technologies required to implement a game. In terms of performance, it also ranks very high in benchmark tests, especially for text-oriented applications. Furthermore, its perl module architecture allows writing of high-performance modules in low level languages, and automatic generation of Perl wrapper interfaces.

SVG

SVG, or "Scalable Vector Graphics", is a standard XML-based syntax for describing vector graphics. 'Vector graphics' differ from the more traditional 'raster graphics' in that instead of being comprised of a grid of pixils of different colors, they are comprised of sets of points and shape descriptions. The computer uses these points to determine how to draw the shape on screen, when needed, instead of merely blit points to locations on the screen.

This distinction has rather profound consequences for the purposes of online gaming. Raster-based graphics are great from the standpoint of being able to capture photo-realistic images, but can be rather space-intensive; consider the case of a simple walking stick figure image, that requires 12 frames of animation in each of 8 directions. Additional animations for running, sitting, using an weapon, opening a door, etc. etc. linearly increases the storage required.

For a non-networked game, storage requirements are probably not a major concern, given increasing hard drive capacities, however in a client/server networked environment, if one wishes to be able to dynamically serve new graphics to the client, the bandwidth required is a killer.

SVG is a way to communicate the shapes and objects in a descriptive way, allowing the client to do the work of figuring out how to present those shapes graphically on the client's display. SVG includes support for animation, transforms, and scripting (via Javascript). It also includes the ability to include raster images, analogous to including images in an HTML file.

SVG is an XML-based open standard, as opposed to the many various proprietary descriptive graphics languages (both 2D and 3D) that are traditionally used. Because of this, there are a variety of good support libraries in many languages, free example code, and open source editors, which gives it an edge over a number of other options, from an open-source development standpoint. SVG appears to be an exciting new technology with a unique combination of strengths in application to client-server open source game development.

SVG in games will allow distribution of easily downloadable clients, since one will not need to download a number of graphics files, fonts, etc. with it. It will permit a wider range of dynamic animations, with much higher fidelity than usually available; for example, animations in any direction, not just the 8 compass directions, can easily be generated.

For game purposes, perhaps one of the most interesting differences is that since it is not pixil-based, games needn't be represented in grid form. Some 3D games today have begun to explore non-grid-based gaming, so this feature is very contemporary.

There are a few SVG-based games, but most are proof of concept (such as an Asteroids-style game), and most are playable only within Web Browsers and tend to require plug-ins. There are of course some Flash-based games, however they too are only available for web browsers with certain plug-ins.

XUL

XUL is a technology invented by the Mozilla Project for describing user interfaces in a platform-independent, XML-based manner. This allows a server to describe a game's user interface just like it would use SVG to describe the game's graphics.

Game Concepts

There are a number of different game technology ideas we would like to make available with this framework. While many of these may not be implemented in the example game we provide, we wish to try to develop the framework in a fashion that would allow these capabilities to be added in the future, or to be implemented in separate games.

Zones and Layers

Imagine layering a series of polygons representing soil, ground vegetation, animal migratory zones, rainfall intensity / weather patterns, etc. Think about having a soil layer with a particular fertility rating, a layer of vegetation on top, that extract nutrient levels and affect the underlying soil fertility, a layer on top representing bizon grazing zones, and a lion hunting area. Each turn, depending on the "density" rating of a given zone, it will influence the density of the underlying zone. Think also about with individual units, having polygonal fields of views, zones of influence, fire ranges, etc. Logistical accessibility and reach could be calculated with polygons, that would be improved by things like rivers and roads and diminished by enemy fields of control, forests, rough ground, etc. Obviously, developing a game utilizing all those capabilities would be more than just the two of us could do, I think, but I think it'd well be within our abilities to at least build the underlying architecture to support games that might wish to use such capabilities.

Example Game: "Endarchy"

This is a post-apocalyptic game, where the players are trying to recreate / reestablish societies within a ravished world; attempting to extract knowledge from ancient times, avoid plagues and radioactive wastelands, explore/control/defeat out-of-control automated robotic installations, defend themselves against mutant brigand groups, genetically uplifted animals, descendants of leftover military organizations emerging from bomb shelters, etc. It takes place a couple hundred years after a nuclear/chemical/ biological/ecological disaster that wiped out 99% of the human population of Earth. Think Gama World, Matrix, Road Warrior, and your favorite post-apocalyptic B-movies. :-)

External Links

TerraNova

TerraNova Sourceforge Page

SVG - Scalable Vector Graphics

SVG-PL

ROASP Perl SVG Zone

Batik SVG Viewer

Sodipodi SVG Editor

Adobe SVG Zone

Server Perl Modules

Games::Object

Games::Dice

XUL - Extensible User Interface Language

XUL Intro

XUL Planet