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
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,
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
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, 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
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 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.
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. :-)
- TerraNova Sourceforge Page
- SVG - Scalable Vector Graphics
- ROASP Perl SVG Zone
- Batik SVG Viewer
- Sodipodi SVG Editor
- Adobe SVG Zone
- Server Perl Modules
- XUL - Extensible User Interface Language
- XUL Intro
- XUL Planet