| Name: | Troll Bridge |
|---|---|
| Version: | 0.2 |
| Author: | Dennis Payne |
| License: | Mostly GPL |
| Operating System: | x86 Linux |
| Website: | http://www.identicalsoftware.com/troll/ |
Troll Bridge is an adventure in the style of the original Legend of Zelda. The main character is a troll who has escape from slavery. By finding clues and collecting items, the character works to free his people.
The game is still under development. Although it can be played, the game balance needs tweaking to make it enjoyable.
Building a game takes more than simply coding an incredible game engine. A large portion of development time is spent on tools for level design and other content creation. Unfortunately, sufficient time has not been spent creating the necessary tools for Troll Bridge.
Simply trying to build the utilities with Troll Bridge 0.2 will uncover
several failures. The makefile attempts to build three programs,
convscr, splitpcx, and spriteedit(1),
which are not included. These programs serve no purpose and were removed
from the distribution, but the makefiles were never updated. Additionally
filelist.C is included even though it was created simply to test and
debug the FileList class.
The tools themselves are very utilitarian and lack an easy to use interface. Several tools need to be used in conjunction before the results can be seen in the actual game. Except for the screenedit program, the programs have only a paragraph of documentation on the web site.
Several of the routines used by the Troll Bridge utilities can be generalized and moved to a library. Many of these routines could easily be included in the Identical Software's Graphics Library. To facilitate later integration, the functions were seperated from the programs and modified to a similar style as the library.
By sheer chance the format of the text palette file nearly matches the format of GIMP palette files. The GIMP web site has no information on file formats. Without looking at the source we cannot be sure, but the only difference appears to be "GIMP Palette" as the first line. When developing new images it is convenient to have the game palette available; by modifying the load routine we can now have one palette used by all tools(2).
Even with a single palette file you still have to know where it is. Both createmap and text2pcx require the text palette to perform their functions. Many programs use autoconf to hard code the installation paths. Although that would work, text2pcx would always use the Troll Bridge palette even if the utility was used with a later game. Making the palette a command line option is an option, but this becomes annoying if you are only working with one palette. My preferred solution would be to add a configuration file and support in the graphics library. Due to time constraints, I used an environment variable instead.
So you just finished drawing the goblin chieftain and want to add him to Troll Bridge. First the pictures needs to converted to a 256-color .pcx files. Anything you want transparent needs to be the last color. Once converted to .pcx, the images are converted to a text file using pcx2text.
Load the text file, edit the palette entry so that the colors are given names instead of red, green, and blue values. The names must match those found in troll/data/trollpal.txt.
Since each sprite may have several frames, each sprite has it's own directory in troll/data/images/. The individual images are named by their facing and frame. For example the two frames of the troll facing up are trolla0.txt and trolla1.txt. Up to 26 facings and 9 frames may be created for each sprite with the provided tools. The number of frames does not vary between facings.
You then have to run text2pcx on all the text images. Pcx2zsp takes all the .pcx files for a sprite and crushes them into a single .zsp file. After every sprite has been converted to a .zsp, the files are concatenated together and a two byte header is added which specifies the number of sprites.
There is no provided tool that does just the concatenation and header addition. Even if there was, the number of steps to add a picture is too great to do reliably. Instead there is a script createspr that can be used to build all the images and levels. Unfortunately it may take some modification if you install the Troll Bridge source some place other than /proj/troll.
Why all the conversions between formats? Before starting Troll Bridge, I was working on a clone of Legend of Zelda with a couple of friends. Although Troll Bridge is entirely written from scratch(3), some of the tools migrated to the new project.
During development of the Zelda clone a game palette was constructed early on since we had the completed game to view. The changing palette of Troll Bridge required converting all the images. Tools already exist that can convert an image to another palette, but to color shift images easily greater control is needed for the conversion.
First the old binary palette file was replaced by a text file that contains the name and the red, green, and blue values for each color. A simple utility, text2pal, converts the data to the binary file used by the game. This allows the troll's light gray eyes to never be confused with the light gray from the gray monster color scheme.
Since .pcx files have no way of associating colors to names, they too are converted to a text file format. The conversion from .pcx to text file is only partially automated. The current pcx2text utility makes no attempt to convert the palette colors into names.
As an improvement, the patch included here will try to find the first color with the same red, green, and blue values. This could possible be enhanced further by specifying the type of picture being converted. Images generally fall into three categories, monsters, main character/item, or background. A keen observer would notice an even more sophisticated solution. Colors are usually packed closely together. Very rarely does an image use color 1 and 30 but nothing in between. By looking at all the colors used in the picture, an educated guess can be formulated.
Ideally all the images for a sprite could be converted to a single text file. From there a .zsp could be generated directly. No longer would each sprite need a directory. The graphics library already had generalized routines for handling .pcx files. There were no corresponding .zsp routines. Converting .pcx files to text and then back to run through pcx2zsp was easier than fixing up and expanding on pcx2zsp.
All level data is stored in troll/data/levels/. Each level has a directory with all the files. In the directory you need a map file with the same name as the directory. So if the level is called pyramid the file is pyramid.map. Additionally there are .scr files that describe individual screens.
The map file is a simple text file. There are no provided tools for editing them. The easiest way to create one is to copy and modify an existing file. The first four items are the start coordinates for the level. If this is the start level the troll will begin at this location. Otherwise he begins at this location if he dies in the level and decides to continue.
Following the start location are two 16 by 8 tables. The first table describes the map that appears in the top left corner of the game. The table contains the color for each square. The second table associates a particular screen with a pair of map coordinates. The same screen can actually be used multiple times in a level.
Editing screens is done with screenedit. In troll/data/levels/, a blank screen is provided; as an alternative you can copy an existing screen as a starting point. Once you have edited the screens to your satisfaction, the createmap program will read the map file and dump everything together into a .trb file.
Although level designers and artist may not care for command line utilities, programmers would be at home with most of the Troll Bridge editing tools. Screenedit is a different story altogether.
The Legend of Zelda project started with a simple program that created a simple map screen. When a item needed to be added to the screen the C program was modified. Rather than keep multiple versions to generate different screens, txt2scr allowed a text file to be converted to a screen(4). "Hideous" is a good way to describe the text file format.
The original screen designing utility for Troll Bridge was descended from this utility. At one point I attempted to write a new gtk editor but designing the interface and reaching parity to txt2scr was a daunting tasks. Without a reasonable graphical editor, development had slowed to a crawl. Screenedit was thrown together one night.
There is no mouse interface or online help. Only the screen currently being edited can be viewed which causes some difficulty in lining up walls. Scripts for game secrets can not be edited. Instead the secret scripts are export to a text file, edited by a text editor, and imported back. The quick construction means the code is without design and full of assumptions. Although somewhat instructive about possible user-interfaces, any newly designed editor would need to be written from scratch.
When Doom came out, the early tools would simply split apart the wad. After making your modifications, you would rebuild the wad. Later nwt allowed designers to directly modify the wad. The instant ability to substitute graphics encouraged modifications. Unfortunately I did not pay attention to this and instead built tools for programmers.
The old tools don't need to necessarily be discarded. The command line tools could easily be used on the backend. As designers become more familiar with Troll Bridge editing, they may wish to automate some tasks using scripts.
The Troll Bridge tools should be reduced to two core tools. One would edit the graphics. Some sort of animation ability would be a good idea as well, so you can see how the sprite will move in game. The game uses shared libraries to store the monster ai so you cannot easily test new creations. A dummy monster that read sprite and action information from a text file could also be created to test animations.
The second would edit entire levels not just individual screens. By displaying multiple screens or even just the border surounding a screen, the designer can get a feel for the level as a whole and how the screens interconnect. Combined with a easy to understand mouse interface, level creation under Troll Bridge would be more attractive to new users. Tool development is often listed in Game Developer article as essential to success of any game project.
(1) Convscr converts the old screen file format to the new format, but Troll Bridge versions using the old screen format were never released to the public. Splitpcx was used to split the oasis image into several backgrounds. Spriteview allows the viewing of any game sprite but screenedit has nearly all its capabilities.
(2) GIMP has actually not been used to develop most of the images. Instead a shareware paint program PO is normally used.
(3) Actually the keyboard routines came from the earlier development effort.
(4) Scott Benner actually wrote a good level editor for the Legend of Zelda project. Unfortunately it only ran under DOS and worked on a very restricted number of graphic cards.