How Such Optimize?

[TheJamsh]

This blows my mind, how come I can do this in an engine from '99 (admittedly, built specifically for the game so it minimizes overhead), and I can't do it even with a simple implementation today...

I modified the FAF missile to fire 500 missiles at once. I can't see any evidence of batching, leader/group following etc. Every missile seems to behave like it's completely independent. I'm trying to do something similar right now, but it's just so unfathomably slow. I'm not going about it the best way, but I'm just wondering how BZ2 manages to be so optimized? Like, the code of the game is so underrated considering how much works it's doing...

https://www.youtube.com/watch?v=lH63KW3 ... e=youtu.be

[Red Devil]

i was able do do something similar in Battlefield 2 (2004) by altering a grenade launcher to shoot at the rate of a gatling gun (gives a whole new meaning to, "Hose 'em") so things like that are do-able in other engines.

[TheJamsh]

Oh yeah no argument here, my main question I guess is are there any specific methods BZ uses for stuff like this.

[Zero Angel]

Oh yeah no argument here, my main question I guess is are there any specific methods BZ uses for stuff like this.

FAFs seem to use very basic logic. They don't lead targets for example and they don't seem to prioritize close targets or targets nearer to the center of their scanning radius. I think the reason why they're so light on resources is because of things like that.

[Red Spot]

I.o.w. it might be more functional to figure out what the other program does beyond basicly drawing a slightly randomized straight line forward.
If the program likes to work with youknowwhat and thatthingyanstuff it quickly needs to do some rather heavy calculations.

(In X3 we made several jumpdrive scripts that made the player face the direction he (or one of his ships) is jumping before it makes an 'in sector jump'. Some guy made one with precise calculations and had to warn people about basicly not using it on many ships at once. I made the exact same with more rudementary math and happilly executed it on 100 ships at once. Difference was that my script did not lag the game, but it did move you slightly pivoted towards where you were jumping.)

[GSH]

BZ2 has gotten a lot more optimized since 1999. Try running that test with BZ2 1.0-1.2 on a 1999-era slightly over minspec box, e.g. P2-350, GeForce 1, 64-128MB RAM. You might have to search a dumpster or few for that box; I certainly don't have such a thing anymore. Then compare the results with 1.3.6.5 on a modern box -- say Core2Duo/Sandy Bridge CPU, decent GPU, etc.

Unreal, if you're using all the bells & whistles on things, and using Blueprint or other high level scripting, provides a good looking game, but that has its limitations on what you can achieve. Scripting won't be as optimized as the hand-written SSE Intrinsics I spent a lot of time on for 1.3.5+ to do a lot more work in parallel. BZ2's models are so low-poly and no shaders that they're what modern games use for their furthest-away LOD, if you have one. If you're aiming to put 500+ active items onscreen, you need to plan for that upfront.

[TheJamsh]

Text

Haha, yeah I imagine that doing this in 1999 would have burnt through a few processors, though to me this is still very impressive. I certainly have new found respect for the underlying code in this game and the work that was done to make it as crazy fast as it is now.

As for the UE side, I'm doing it all in C++ but obviously my skills are pretty limited. My current implementation is horrific, it uses a huge collision cone to find potential targets then finds the best one to home in on. The homing side of things isn't too difficult, but the collision cone was a terrible idea. I wasn't expecting to hit more than a hundred objects and stay about 30 frames a second with that method, the actual results were even lower. It's a complex collision too, not a primitive, so I was asking for it.

Writing Intrinsic functions is definitely outside the scope of my skills right now, though my current idea is to build a Quadtree or perhaps an Octree of all of the 'GameObject' components in the world, which should allow me to sift through things much faster without ever having to dive into Collision code too. After getting the only possible targets from the Quadtree the resulting math to generate a cone is relatively inexpensive I imagine, and I could go as far as generating a manager class to split the updates over several frames in case there really are that many objects. Not sure if that's promising or not, I don't know if BZ2 does any kind of tree/distance based sorting for things like this.

What amazes me about it in BZ2 is that this probably works over the internet too, albeit with some spawning lag perhaps. BZ runs on a Lockstep system right? So all inputs/events are built up and then sent in one big packet for the clients? Obviously missing a few steps there. The Multiworld part for example is interesting, though I don't really understand how it works. UE's replication of objects is unfortunately insufficient for this kind of thing, so I'll be bottlenecked by the amount of data being sent anyway until I get to the next level of the engines TCP / socket stuff.