Yet Another BotF Clone

[DotAliscious]

I was hoping no-one would ask.
I've been a bit busy this last week, so it's slowed things down even more than they had been. The project has lost some of its initial momentum, but it will pick up again once I've integrated the new components (I've completely rewritten the underlying graphics and GUI code, and more). But it's all taking way more time than I thought. There's just not enough hours in the day. And there are inter-dependencies between components, so rewriting one thing affects other code. Which is why I wanted to get this underlying stuff 100% done before letting anyone else work on anything. I guess it's like building a house; you lay the foundation before you do other stuff, right?

But it feels like I've been playing ping-pong with some of the design concepts. I don't know why it's so easy to prototype things straight from my mind, but if I start designing things properly, I find it difficult to settle on a final design. So for the rest of this project, I won't bother redesigning / rewriting any more components. I'll just crank out prototype code as fast as I can, slap it together, and do small refactoring every-so-often. We can look at fixing design problems when the whole game is working.

I'm hoping to get development back on track within a few days. I want to get a completely clean and documented code-base with which other people can join in development.

Just slap it up on github or something. Refactoring code is my favorite coding activity. I'd gladly help with things like reducing the coupling.

[QuasarDonkey]

Well it's a bit all over the place right now. Just bear with me a little while longer. Reducing the coupling is one thing I've been working on, for example eliminating coupling between the GUI library and WDF files. I use an abstract factory to create widgets given an ID. See later on, I'll be wanting to move away from the WDF files to something both resolution-independent and dynamically resizable at run-time (but it doesn't have all the needed features yet).

Actually on that note, I've figured out a way of adapting the WDF files to work at any resolution. So you design a screen once, and export the WDFs and TGAs at 800x600, 1024x768, etc. I just need to make some modifications to the WDF editor, but I don't have time now. I might take some time to implement that after this refactoring, since it could be used with both vanilla BotF and the new clone.

[Dr_Breen]

Well it's a bit all over the place right now.

yep thats how we know botf.

Just bear with me a little while longer.

hey, we're making mods for a 13 year old game...i think we've proofed that we're very patient

[Callahan]

What version of C++ will there be needed to play around with the code once it is released ?

I currently work with 6.0 and DirectX 8. Yea, I know, - I could hammer code into a cave wall as well....

About equipment: Does one need an OpenAL sound system ? Do we need a high end Graphics card.
I would appreciate not to be bound to High-Tech hardware, if that is possible and convenient.

P.S. QD - you are my hero - if it works in the end....

Cordial Greetings
Callahan

[QuasarDonkey]

You mean Microsoft Visual C++ 6? That's *old*. In theory, it could work with that, but knowing Microsoft like I do, VC6 is not standards-compliant. So it probably won't work. But nowadays there are loads of free compilers anyway. It doesn't use DirectX either since that would limit the game to Windows only. It uses SDL and OpenGL 1.1. They should run on pretty much anything.

About equipment: Does one need an OpenAL sound system ? Do we need a high end Graphics card.

Right now, there's no sound at all, so you don't even need a sound card. Graphics-wise, I'm not sure, but I think any graphics card after 1998 should work just fine. I'm not doing anything fancy.

[DotAliscious]

You mean Microsoft Visual C++ 6? That's *old*. In theory, it could work with that, but knowing Microsoft like I do, VC6 is not standards-compliant. So it probably won't work. But nowadays there are loads of free compilers anyway. It doesn't use DirectX either since that would limit the game to Windows only. It uses SDL and OpenGL 1.1. They should run on pretty much anything.

About equipment: Does one need an OpenAL sound system ? Do we need a high end Graphics card.

Right now, there's no sound at all, so you don't even need a sound card. Graphics-wise, I'm not sure, but I think any graphics card after 1998 should work just fine. I'm not doing anything fancy.

I wonder how much of this game could be run in parallel?

[xDx]

Hey QD sorry about late response been busy yada yada same old story... anyways my math is a bit rustier then I thought and haven't much time lately to brush up. But I'm still interested just might need some time and a general "push" in the direction you're looking to go. However with engineers interested in this "mod" of yours you might do better by enlisting their help instead of someone like me who hasn't applied these kind of maths in over ten years :\ But that aside for the dynamic flight movement are you using a standard proper velocity or will ships speed up and slow down during maneuvers? Thereby needing to solve for v. Also are you looking to add the z axis to create a true 3D combat or maybe just keeping it on a 2D plane for now and just solve for differential x? I might be a little off the mark yet so please excuse me if this seems elementary to ask but just throwing it out there....

[QuasarDonkey]

They're good questions, and to be honest I'm not really sure right now. I was discussing some of this with cl10k, who reckons I may have been over-complicating it.

I think the most important thing for 3D combat now is for people to play some battles, and pay close attention to the maneuvers. It's really the only way we can closely approximate BotF's behaviour (okay, not the only way, the harder way is to reverse engineer Trek.exe).

See I tried playing some 1 vs 1 ship battles, and I couldn't really tell via observation how the maneuvers worked. Take the 'charge' maneuver. If the enemy is holding/hailing, charge just moves in a straight line. Simple. But I couldn't tell what's happening when the enemy is moving.

With the circle maneuver, I *think* it just moves in a fixed-radius, and doesn't track the enemy. Since the battle is constrained to a relatively small area, it wouldn't matter what circle you follow, because the enemy will probably always be in weapons range.

Another thing is that during a lot of close-combat maneuvers, I noticed ships doing U-turns.

The point of this is that we may not need to use differential equations and numerical integration, but much simpler equations using only a single time variable and a few constants. But the real point is that we need more research.

So if anyone can provide useful info on the combat...
Also, if anyone wants to take a crack at reversing BotF's code, a good place to start in the Standard IDA DB would be with AI_Assault, AI_Circle, etc., which branch off to other subroutines in TCMath, etc. It's all very heavy on floating-point math. I don't know how it works, but I know it uses splines to compute smooth paths.

[thunderchero]

well I am going to babble a little here,

first off to view combat maneuvers what I would do is, raise the hull and shields and lower damage so combat would never end then use replay from top view to see movements of each type of command. Best if done in multi player mode

but as for coding of your project I would just use the command images (cb_m_01.tga) as to how to make them move. But as you pointed out make them adjust as the target moves.

as for things like circle have the radius determined by the lowest max firing distance less 100 (phaser or torpedeos) instead of a fixed radius but while adjusting to the movement of selected target.

also keep all ship movements related to ship agility.

just a few thoughts

thunderchero

[xDx]

Well from what I can tell in combat as it stands... while combat is considered 3D it only is 3D in the sense of the models... combat occurs on a 2D plane at least in reference to starting locations running along the x and y axis. Ship initial placement does involve the z axis but since BotF does not incorporate a z buffer it's not used meaning it seems to only operate combat within a specific sphere centered around the origin of the x and y axis (the origin I believe is the middle point between both starting fleets). In regards to maneuvers f.e. charge/assault... the ship will move in a straight line if the target ships are stationary but factor in movement the charging ships seems to use a floating point (as you pointed out) fixed on their specific target. If the whole fleet is the target then the floating point is the center of the "sphere" the fleet occupies. Probably a huge reason why weapons fire is so inaccurate when an entire fleet is targeted instead of ship by ship.

Yes the ships do perform U turns when firing/ramming a ship (quite fast too despite whatever agility value they have) as the model seems to disregard phaser slots and can only fire from the forward of the ships. I remember reading somewhere in regards to vanilla that Cardassian ships were the only empire able to shoot weapons from the aft of the ship. I took that as being able to fire while facing away from their opponent. I never really gave it much thought and since I haven't played vanilla in quite awhile I can't verify this right now.

For circle/harry maneuvers (I never use them) they are not accomplished on one turn. Performing this maneuver the ship seems to do a U turn move backwards and start the maneuver then stop. If u continue the circle maneuver next turn they will continue in the arc started in the previous turn and so on. Why I never use those maneuvers is they take several turns to perform at least in my opinion (maybe why I lose all the time lol). My point being is the circle and harry maneuvers I think operate based on that initial origin point between the two fleets. I'll do some more research in a game I'm about to play in MP shortly concerning the other maneuvers. Bottom line is this: after that first combat turn if we could create a varying origin point between the fleets for each subsequent turn: and also increase the time increment for each turn (again I read somewhere that each combat turn=15 seconds of real time but I can't verify that either) then this would give each ship more time to complete the maneuver, then maybe combat maneuvers would at least be more "streamlined".......... just some rambling off the top of my head

[QuasarDonkey]

first off to view combat maneuvers what I would do is, raise the hull and shields and lower damage so combat would never end then use replay from top view to see movements of each type of command. Best if done in multi player mode

I like this idea. We can also alter agility/defense to see the exact behaviour (I'm particularly interested in extreme low and high values, since they should make the maneuvers more explicit and easier to see).

xDx, it's interesting what you mention about circle maneuvers taking multiple turns, very astute.

But I have a few modding questions:

• I noticed in UE that all ships have an 'agility' of 0 or 100 only. What's that about?
  Edit: I just noticed agility of 0 is for starbases, 100 is for most ships, and 100+ for more agile ships.
• What's the ship 'defense' value used for?
• Where are the locations of phaser/torpedo banks for each ship? Inside the HOBs?
• I'm not sure what these 'phaser slots' are, I haven't had time to read about them yet. I guess I should.

I may just start tinkering with UE to get a better feel for ship mechanics, I've never done that before

[thunderchero]

[*]I noticed in UE that all ships have an 'agility' of 0 or 100 only. What's that about?
Edit: I just noticed agility of 0 is for starbases, 100 is for most ships, and 100+ for more agile ships.

Think agility is only used in evade command but not sure. higher values have been given but when evade is used will cause crash if set too high.

[*]What's the ship 'defense' value used for?

you might find some useful info in this post about defense. from what I understand it is a bonus (opposite of accuracy).
viewtopic.php?f=9&t=74&p=591&sid=447358 ... 8c97c#p591

[*]Where are the locations of phaser/torpedo banks for each ship? Inside the HOBs?

yes phaser are part of hob files but torpedeos are just based from center of hob.

[*]I'm not sure what these 'phaser slots' are, I haven't had time to read about them yet. I guess I should.

this post might be one of the best post about phaser slots and how they are part of vanilla hob file.
viewtopic.php?f=4&t=1812&hilit=textures ... ff40ae43c0

basicly a phaser slot is a single polygon (triangle) assigned for phasers to fire from.

thunderchero

[QuasarDonkey]

Thanks thunder, that's cool. Even better that the damage points are stored in the HOBs too. My HOB loader is based on Falcon's, so it has complete access to all of the HOB data. (I rewrote the Falcon one since it won't work on 64-bit machines, and is very Frankenstein-ish; also to avoid legal issues.) What Callahan noted as the 'scars' or damage points are listed in the HOB definition as "dynamic vertices". Then right after dynamic vertices are "dynamic polygons". My guess is that BotF uses these for the phaser slots too.

[Tethys]

ALL HOB data? If so, there was a project dealing with damage textures and where they were stored in the HOBs, but nothing ever came to fruition on that. Also, TC and I did some work on phaser HOBs, but we could not find out how to create one from scratch like we do with the ship models. Im not asking you to look into it right now, but it could be worth looking at down the road.

EDIT: Just saw you already found the damage slots. Sorry bout that lol.

[thunderchero]

ALL HOB data? If so, there was a project dealing with damage textures and where they were stored in the HOBs, but nothing ever came to fruition on that. Also, TC and I did some work on phaser HOBs, but we could not find out how to create one from scratch like we do with the ship models. Im not asking you to look into it right now, but it could be worth looking at down the road.

wrong........ something did come from both but just not worth the time it would take to edit each model

thunderchero