The purpose of this document is to familiarize the reader with all the aspects of creating new games in the Monrovia environment. Useful issues from suggested software to using static and dynamic building blocks to create a playable gaming arena are covered.
This document is intended for persons responsible for creating gaming arenas. In most cases they will have something to do with administrating the Monrovia server or most likely be administrators themselves so they have prior experience and a good understanding of the system and the environment it runs in. This is why everything is not explained to the most basic detail.
Creating everything needed for a playable arena does not require much software. Game definitions are stored in XML files and BMP files so you will only need a text editor and something to manipulate simple image files. GNU Emacs with XML-mode is preferred choice as an editor. It has also a hex-mode which may be handy for editing the color indices of the BMP file. Some simple pixel based drawing application which shows the palette in the right order is also needed. For example, GIMP is an excellent choice because the color index numbers of the palette can be listed and changed easily.
General game parameters are saved in the file gameparams.xml. It contains the default walk, player and ground parameters. These have to be changed quite rarely. It also contains the game commands, their parameters and possible command classes. Few of them are explained here as an example. These commands can be considered as some kind of standard commands included in every type of game.
The parameters for monrovia.server.platform.commands.Say:
The parameters for monrovia.game.commands.Look:
When adding a new arena the first thing is to add it to the
arenas.xml file. This file contains the names of directories where
the game data is saved. Each arena has its own directory. For example
adding an arena called korso would require the following line to be added
to arenas.xml:
<java.lang.String valueOf="korso"/>
The map image of the arena is saved in the bitmap file map.bmp. This is a 256 color BMP file which allows 256 different objects. It will end up looking very much like map with colored pixels each representing an object. A pixel's color value is mapped as an index into the map.xml file (see chapter 4.2) which lists the bitmaps for all static objects.
A portal is a "door" for moving from one arena to another. It is a special
spot on the map that acts as a gateway between two arenas. Portals are
added to the portals.xml file. Every portal has a name, implementing
class, a list of points on the map the portal is going to be and the
portals parameters. The coordinates for the portal are measured from the
top left corner of the arena. For example having a portal five squares down
from the top left corner would require the following to appear in
portals.xml:
<ArrayOf-java.lang.Object length="1">
<monrovia.tools.IntPoint
mX="0"
mY="5"/>
</ArrayOf-java.lang.Object>
The parameters for implementing class monrovia.server.platform.map.ArenaPort:
The object bitmaps are in the raw palm bitmap format and 16x16 in size. To get a raw palm bitmap from a windows bmp file, first create a 2 color bmp file with size 16x16 and then use the bmp2bitmap script to convert it. For example to convert orc.bmp to orc.bin a command like this could be used: bmp2bitmap orc.bmp -write orc.bin
To add objects to your map you will need the map.xml file. This file
acts as a link between the map and the objects. It has a list of object
bitmaps without the .bin extension (e.g. tree.bin is listed as tree)
looking like this:
<java.lang.String valueOf="tree"/>
<java.lang.String valueOf="mountain"/>
<java.lang.String valueOf="door"/>
One should be careful with the order of these objects as the pixel values of
map.bmp are used as indexes of the objects based on this order.
Every dynamic object has a bitmap associated with it. The format is the raw palm bitmap format and 16x16 in size, the same as for the static bitmaps.
The file creatures.xml lists all the creatures on the arena. Every creature has a name, the implementing class and the object bitmap name (e.g. orc.bin) and also the number of creatures to create with these parameters so that the game designer can create many identical creatures easily. Adding new parameters to creatures is very much like adding portals or creating static map objects due to the nature of XML. The easiest way to add something is to see how it was done before and just copy it and modify the parameters to meet your current needs.
Currently possible implementing classes:
In addition to these behaviour classes every creature has these possible parameters:
In this chapter you will find a simplified list of all the files involved in creating a new game.
Problem | Solution |
---|---|
"Couldn't load <filepath>" message is displayed and the server does not start. | This message is displayed if a needed file is missing or the syntax of some XML file is wrong. Filepath is the path to the file with the problem. Check that the file is in the correct place and in the correct format. |
"pixel value : <x> in map is greater than tile amount: <y>" message is displayed and the server does not start | The tile amount described in map.xml is too low for the pixel values in map.bmp. Since the pixel values are used as indexes into map.xml, there must be enough tiles for the largest pixel value. |
Like stated in the beginning of this document not everything is explained to
the smallest detail. If something was left unclear or you wish to find out
more you should try Administrator's Guide, Client Guide and Technical
Specification.
Administrator's Guide deals with the aspect of managing the Monrovia
server, from setting up the required environment to handling player issues
by using the special administration tool.
Client Guide is all you need to be able to install the gaming software,
connect to the Monrovia server and start playing the game.
Technical Specification is not as light reading as those two documents
mentioned before. It has hardcore descriptions and definitions of
everything from protocol details to user interface solutions.