Egoboo Developer Interviewby Howard Wen
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?
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.
Other Linux Interviews
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.
Return to the Linux DevCenter.