Yet Another BotF Clone

[QuasarDonkey]

I've been working on a little project for the last two or three weeks. Basically I got so frustrated working on a patch to enlarge the taskforces, that I gave up and decided it would be faster to rewrite BotF from scratch.

The Goal: To create a 90%-compatible BotF clone, using the original data files from STBOF.RES, and featuring the original gameplay. Certain things like networking will not be compatible with the original.

It is written in standard C++ using only OpenGL and SDL for graphics, sound, and networking. This means it will natively run on Linux, Windows, and Mac OS X, at the very least.

I've been mostly working on the underlying libraries. What I've done so far:

• Code for reading many of the files from STBOF.RES, e.g. Lexicon.dic, WDFs, HOBs, etc.
• The basic GUI library (buttons, scrollbars, text rendering, etc.).
• Basic Galactic Map functionality.
• Loading HOB files as 3D meshes and rendering using OpenGL.
• Some of the game's basic data structures (StarSystems, Planets, etc.)
• Loading data from SAV files.

Don't get too excited though, it's not a playable game yet; it's just a collection of code modules and demo programs. Once I make a basic playable demo, I'll post it.

Here are some screenshots to whet your appetites for what is to come (some of these screenshots are old, so it looks better now):

The basic GUI library is almost finished (everything is interactive). You can't see the button glow effects here, but they work

It's also fully hardware-accelerated using OpenGL, and supports alpha-blending.

Sector rendering on the galaxy map: You can click on sectors to select them, or double click to take you to the star system screen.

The HOB loader reads HOB files and translates them into standard triangle meshes, again fully hardware-accelerated.

Luckily, the HOB files store the polygons using counter-clockwise winding, meaning we can support backface-culling - notice how you can't see the back of the ship in this wireframe shot:

It also supports alpha-blending, for the ship cloaking effects (cloaked sovereign):


It supports multi-textured HOB files (this HOB uses 5 textures):


I'll keep you guys informed of my progress. I'm hoping to have a very basic playable prototype over the next week.

[thunderchero]

Very very nice,

I would also like to add that the last image of the ambassador has no BSP data part of the hob, so and small transparent section of older hob files would be corrected by using OpenGL. This mean conversion of models would be much easier in this configuration.

thunderchero

[Tethys]

Oh this is wonderful news! I dont suppose it will be compatible with mods, as perhaps simple importing and stuff with UE? Will modability remain the same or will it be a little less complicated?

[QuasarDonkey]

My intention is to keep it compatible with all existing mods. You'll still be able to mod the game using UE.

Binary Trek.exe patches won't work because we'll have a new Trek.exe. But that won't matter since we'll also have source code

Certain things will be simpler. For one thing, you won't need to worry about texture palettes or any of that non-sense when importing 3D meshes.

But starting out, the game will use all of BotF's original data files, and will thus be subject to many of BotF's limitations. That will change pretty quickly though once the project takes off.

My real goal now is just to get a basic game up and running ASAP. The initial releases will NOT have sound, AI, manual tactical combat, intel, diplomacy, fancy spiral galaxy generation, and more. At first, we'll just have a basic network game (LAN/internet) with automatic tactical combat. Baby steps.

[Deimos]

Well, this sounds amazing heh
Good job on doing it

[Flocke]

I would also like to add that the last image of the ambassador has no BSP data part of the hob, so and small transparent section of older hob files would be corrected by using OpenGL. This mean conversion of models would be much easier in this configuration.

Well yes, that hob reader could be extended to export to .mesh too, that'd be nice. On the other hand you've made good progress TC.

Ah and HF QD

[anjel]

Niiiiiice, these is going to be interesting, i would like to see the progress on the road. If there´s something we can help, here we are
And when you said linux, i couldn´t avoid to think about Android... what you think QD, is it possible to export, what you would do, to that universe ???

[thunderchero]

Well yes, that hob reader could be extended to export to .mesh too, that'd be nice.

I never thought about that

On the other hand you've made good progress TC.

Yes I have made some good progress with conversion to mesh. from what I understand though your mpr project would be easily added once QD has a more advanced version.

thunderchero

[xDx]

This sounds fantastic! A BotF with the source code readily available... man how dreams can come true for a geek like me. Of course as anjel has stated we are all here to offer support and encouragement for you QD good luck with this project. As for me I'm just gonna start throwing slips of latinum at my computer and say "gimme, gimme, gimme." Modability retained is a great bonus to keep esp with UE and I'm guessing when you say Mac, Linux, and Windows you are saying compatibility with 32 bit Win OS or will it be easily used on 64 bit systems as well? Anyways looking forward to hearing of progress on this as it develops

[QuasarDonkey]

Niiiiiice, these is going to be interesting, i would like to see the progress on the road. If there´s something we can help, here we are
And when you said linux, i couldn´t avoid to think about Android... what you think QD, is it possible to export, what you would do, to that universe ???

Thanks Anjel. Actually I was thinking of making an iPad version later, since I have one lying around at home, and I haven't written any cool iPad apps yet. Although I want to get the PC version done first. But I don't think Apple would permit it on the App Store, since it would violate copyright probably

you are saying compatibility with 32 bit Win OS or will it be easily used on 64 bit systems as well?

I'm developing it on a 64-bit Linux system, but it can be recompiled for 32-bit systems as well. So there will be native 32-bit and 64-bit versions. And I'm not using any operating system-specific code, so it will compile and run on pretty much any modern O.S. that can run OpenGL 1.1 & SDL 1.2 (heck it should even run on Windows 95).

[Dr_Breen]

Awesome. you know whats the best about it? it's not about having a source code. it's not about the possibilities to pimp the AI.
no it's the fact that we can get rid of this memory leak finally.

in which language are you writing this? will you release all the code (i'm a beginner with programming and am veeeery intrested into stuff like this :-) )

[QuasarDonkey]

no it's the fact that we can get rid of this memory leak finally.

I hope so

in which language are you writing this? will you release all the code (i'm a beginner with programming and am veeeery intrested into stuff like this :-) )

I'm writing it in C++. And yes, I'll release the source code.

[Tethys]

My real goal now is just to get a basic game up and running ASAP. The initial releases will NOT have sound, AI, manual tactical combat, intel, diplomacy, fancy spiral galaxy generation, and more. At first, we'll just have a basic network game (LAN/internet) with automatic tactical combat. Baby steps.

The vanilla spiral generation never had enough spiral arms for my taste Also, I could see adding a few more galaxy types to the mix, such as Barred Spiral, Interactive Galaxies, Starburst Galaxies, Lenticular (AKA Disk) Galaxies, and even Galactic Clusters (more than one galaxy with gaps in between).

[Lathon]

This is awesome.

You'll still have to be careful about memory management in c++ though......but from you've wrote before, you know your way around C++, so memory management shouldn't be too bad for you

[QuasarDonkey]

You're right. Even with good programming practices, it can be difficult to avoid such bugs in C and C++. But nowadays there are a lot of profiling tools available to help with that sort of thing. On Linux, I use a program called "valgrind". It has an awesome memory leak detector. It even tells you what lines of code the memory leak started on.

Good programming practices in C++ include a technique called RAII (Resource Acquisition Is Initialization). It's worth looking into if you never heard of it (you basically wrap any dynamically allocated resource with a class, and let the class destructor handle the deallocation of the resource; like smart pointers). And of course other good techniques include paying attention to compiler warnings, always declaring a virtual deconstructor for base classes, etc.

It's not really surprising that BotF had memory problems and the developers didn't think of using a memory checker. I've been programming C/C++ for years, but I only discovered such tools around last year.