Egoboo Developer Interview

Editor's Note: Ben and Aaron Bishop are the creators of Egoboo, the subject of an earlier article entitled "Egoboo:
The Cute Way to Dungeon Role Play." They graciously agreed to talk to the
O'Reilly Network about what they've learned from writing their game.

O'Reilly Network: Besides portability, what technical
advantages are there in developing Egoboo under OpenGL? How would the
development of Egoboo been different had the game been made under OpenGL from
the start?

Ben Bishop: Portability is one of the main advantages.
Other than that, it is especially suitable to an open source project, as the
API is much more programmer-friendly. Also, it is useful that OpenGL is as
widely supported as it is. You can find good OpenGL implementations for almost
all 3D cards these days.

If we had begun with OpenGL, some of our existing bugs would not have been
introduced. Such a major rewrite of code always causes problems. Also, we would
have saved a great deal of time that we could have perhaps spent in developing
game data.

Aaron Bishop: OpenGL is much more readable than Direct3D.
It's very hard to go back and make any sense out of the original code. Direct3D
is hard. I can only hope the game would have been better if I had used OpenGL
[from the start].

ORN: For the Windows platform, are there any advantages in
programming 3D graphics under Direct3D as opposed to OpenGL?

BB: There are certainly some arguments that you could make
about advantages of Direct3D under Windows. Specifically, I'd be thinking of
things like additional features and better support from graphics card makers.
For Egoboo though, the advantages don't nearly outweigh the disadvantages.

AB: No. It seems to me that games made with Direct3D are
much more bug-prone than OpenGL games.

ORN: Why was the Quake II modeling format, in particular
(and not another game's format), chosen for Egoboo's own modeling format? What
kind of technical matters did you deal with when incorporating the Quake II
modeling format into the Egoboo engine?

AB: That would be because of the freeware Quake II modeler.
It was the best modeling tool I could afford. The hardest part was attaching
two models together--for example, a sword in someone's hand, or a character
riding a mount.

To do an attachment, I use one central vertex that tells me where to put the
attached object, then three vertices that show me which way each axis points
(Front, Side, and Up). These give me the rotation for the attached part.

ORN: So why was it necessary to develop an original map-making program, Cartman, for Egoboo, instead of using an already existing tool used to make map levels for another game?

AB: It's mostly just the order in which things were built.
Cartman was one of the first things I did for Egoboo, and at the time that was
the easiest way to do it. In retrospect, a better map-making tool would have
saved countless hours of work.

BB: I'd also like to add that there are enhancements to
Cartman and new map-making/random-generation utilities that have been
contributed since Egoboo has gone open source.

ORN: Regarding Egoboo's AI, how was the scripting language
for it developed? Was it based on any other pre-existing program, code, or
technology? What technical advantages would there be in using Lua for this?

BB: I'd actually prefer to keep scripting as it is now, but
being an open source project, there are other developers who are excited about
getting Lua in. They hope this will be easier to work with for developing
future scripts.

I am a bit concerned about throwing away or perhaps introducing bugs into
the existing scripts we have. This is a very big concern when you consider that
we have been very slow in making progress in developing new NPCs [non-player
characters] and new levels.

AB: Egoboo's script language was the first time I had
written anything like a compiler, so I tried to make it as simple as possible.
It isn't very pretty, and it isn't very efficient, but it's one of the things I
am most pleased with in the game.

Lua probably doesn't offer much advantage other than being easier to use.

ORN: So what are a few of the fundamental game design
rules, philosophies, and conclusions you've come to about making a 3D graphics game
like Egoboo?

BB:

1. When you're making a game by yourself, it's better to do it backwards.
Try to get as much of the support code (script language, windowing, sound
effects, etc.) done before moving on to graphics and artwork. The purpose being
that some parts of a game age more quickly than others. Technology-wise, Egoboo
was out-of-date before it was even released.

2. Download size should be reduced. Lossy compression of textures and sounds
is probably a good idea.

3. Content creation (artwork, sounds, levels, etc.) takes a lot of time.
Either find good tools or make them--this will save you time later. For
existing tools, we like GIMP and Audacity. We don't know of
a good, free, powerful modeler.

Certain types of games require much less artistic effort/time. For example,
a space-ship game requires very little animation and the models are relatively
simple to build, compared to a game like Egoboo.

4. Network code is hard. Consider doing multiplayer on one computer instead.
There are good multiplayer console games, like Super Smash Bros. Melee, that
might not be as much fun over a network.

5. The script language is important. Having one will help; having a good one
will really help.

6. Open source projects are a great way to get publicity/job offers for
aspiring game developers.

7. Design the game so that it is easy as much as possible to substitute text
from other languages. Egoboo seems to be more popular in non-English speaking
countries, despite the fact it has no multilingual support. Maybe [it is best
to] centralize all strings into one text file.

8. Writing a game takes a lot of time. The new game Aaron is working on has
consumed about 2,000 hours of his life so far.