Contents

Organizing Projects
Creating Libraries
Runtime Log Files
Protecting
Image Data
Introduction
to Scripting
The String Table

Printable version
Discuss this article
in the forums

The Series

Beginning Windows
Programming
Using Resources
in Win32 Programs
Tracking Your
Window/Using GDI
Introduction
to DirectX
Palettes and Pixels
in DirectDraw
Bitmapped Graphics
in DirectDraw
Developing the
Game Structure
Basic Tile Engines
Adding Characters
Tips and Tricks

The String Table

Remember way back in article 2, when we looked at resources, and I told you that you could use a string table to represent all kinds of data in a game? Well I thought I'd give you an idea as to what use you can make of a string table in an RPG. RPGs especially benefit from something like this, since most of them end up having lots of text.

The first and most obvious use for a string table is to store narration and/or character dialogue. Those two things together will make up a very large part of the text needed in an RPG, and so it's important to have an organized way to store it. You could put it in a file -- but then anyone playing your RPG would be able to change the dialogue however they wanted. Your beautiful ending scene could become a recreation of "All your base are belong to us," and we can't have that, can we? :) You could store the strings directly in your scripts somehow, but then you'd have to worry about how to encode them, and besides, it would break our plan of having short, fixed-length instructions. So what's left? Use the string table.

Storing dialogue this way helps your scripts in another way, too: it gives you a very easy format for creating a function that displays text on the screen. For example, look at the following script command:

showText 10, 10, 253, 5

This could be translated as "At screen position (10, 10), show five lines of text, beginning with line 253 in the string table." The only problem here is that you're going to have a lot of dialogue, but you only have one string table, so it's easy to get lost in there. There are a couple things you can do to get around that. The first is pretty easy: just group your text into logical sections and use a few #define statements to define where the different sections are located, so you can get to them easily. You might have something like:

#define ST_OPENINGSCENETEXT  35
#define ST_FIRSTTOWNNPCS     253
#define ST_SECONDTOWNNPCS    428

But if you have a really big project going, that's not going to be enough. In that case, what you might want to do is to write a utility that lets you add text to all sorts of little partitions that you can create, so it gives the effect of having many string tables, but then the program combines them all into one and writes the resource script for you. This can be very convenient, and it's quite easy to do. All you need is a way to create divisions of text, almost like a directory tree on your computer, and a way for the program to tell you what string table index it assigns to the text you write down, so that you don't even have to look at the string table to easily access any dialogue in the game.

Lists of items, magic spells, menu options, etc. are also good candidates for the string table, since you can just define a constant and then use offsets to locate the relevant data. For example, in Terran I have a constant called ST_ITEMDESCRIPTIONS which is an index into the string table. When I want to pull up a description for an item, I just load string number (ST_ITEMDESCRIPTIONS + nItemNumber).

The last thing you might want to use a string table for is filenames, be they for image files, map files, scripts, or anything else. That way you can have all your filenames together, so they are easy to find and change if you need to do so. You can again use numeric constants to represent the filenames by acting as indices into the string table. When my game needs to load the script for initializing a game, it calls the script loading function with a value of SCRID_GAMEINIT, which of course just tells the loader where it can find the filename.

Closing

And so it ends. Congratulate yourself if you've been with me since the beginning of the series; we've come from displaying a blank window on a screen to being just about ready to take on most of the features of a simple, albeit complete DirectX-based RPG, or whatever other type of games you're interested in writing. I have to quit writing for awhile, but if you want to get more info on any part of game development instead of striking out on your own, GameDev.Net has all the resources you need.

As for the future, I'm thinking about getting a series on scripting going once I have more time (read: in May when classes are done with). Some people have even suggested writing a book based on this general outline. At first I didn't know about that, but it's starting to sound like an interesting idea. If I do something like that, it will of course be much more detailed, and cover a myriad things I didn't get to here, like scripting engines, responsive NPCs, tips for other game genres like basic shooters, and using DirectX 8 for graphics so you can get hardware acceleration for things like alpha-blending. If you'd be interested in seeing something like that, let me know, so I have an idea as to what people would think of it.

Thanks to the many, many people who sent in positive feedback on the series; this has gone over even better than I had hoped for! If you still have questions about anything in these articles, as always, feel free to E-mail me at ironblayde@aeon-software.com. I'm on ICQ less and less these days, so E-mail is your best bet. Well, happy coding, everyone, and I'll see you later.