Why are air units allowed to overlap?

A simple technical question to Uber devs, or any modders. Land and naval units cannot be massed into blobs of hundreds of units easily in TA and SupCom because they don't overlap and as such the entirety of said blob will not be able to come into range of the enemy to fire. So it makes sense to break up your blob of land/naval units in order to use them effectively.

On the other hand, air units in the same games are allowed to overlap. This leads to absurd situations where 1 zillion Hawks/ASFs/whatevers can be crammed in a 20x20x20m cube, and all 1 zillion can then shoot. Which is a big reason why they're so effective in said games.

So why are air units allowed to overlap when no other units are? And if there is a technical reason for it (as opposed to a gameplay reason), could something like flowfield pathing or any sort of new method of doing things help?

it was worst in supcom 2 xD I hope this wont happen in PA. ^^

Only due to lack of AOE AA.

yeah but in SupCom 1 it didnt look as crappy when 100 air units flew on the same spot. In SupCom 2 you really "noticed" it.

I know that the intention is to somehow avoid this happening, not sure how exactly you'd do it without planes crashing into each other or moving unrealistically, but Neutrino has said that he's against units clipping through each other so hopefully an elegant solution will be found.

Bumpers. Very large rubber bumpers.

possibly because collision checks are relatively costly on performance, especially on fast moving units, which require a small physics time step for accurate results (checking the collision many times per second)

Another reason is that IRL airplanes could use 3 dimensions, where in most RTS games aircraft are locked into a certain height. Having a flat "soup" of aircraft will most likely look at least as strange as a dense blob.

Maybe something like a 3d implementation of the "boids" algorithm could work to have relatively cheap collision check emulation? http://www-cs-faculty.stanford.edu/~ero ... boids.html

I honestly can't imagine that an RTS will ever manage combat aircraft in a realistic way: Similar to many aspect of warfare, game designers simply don't know enough about it to even approach handling it in a realistic way.

Does anybody on the design team even know how aircraft are managed above the battlefield? It turns out it's quite complex. Three dimensional sectors and zones are specifically designate for specific, individual aircraft, or individual formations (for example, a pair of fighters. Many restrictions are in place to prevent combat aircraft from colliding with each other, and dozens of people and systems (both on the aircraft and off) are dedicated to ensuring they don't collide or even get too close.

The fact of the matter is, any attempt to simulate these kinds of restrictions might be "unintuitive" or "unfun", and losing friendly aircraft due to collisions with other friendly aircraft it more likely to be even less fun for players.

Further, there are ways that could conceivably be designed to handle air traffic intelligently, but they'd be difficult to represent. Remember, modern aircraft fly really high in the air: 30,000 feet is a medium altitude aircraft. The U-2 flies over 100,000 feet. These aircraft fly at 6 and 20 miles above the surface of the earth: There would simply be no way to see all of your aircraft at all of the different altitudes they could be at all at once and manage them as a cohesive group.

For all the reasons above, you get the simplified, toddler version of aircraft physics and and traffic control... and I don't see that changing anytime soon.

That Boid simulation looks awesome though. Easy enough to implement and the produced result looks quite organic with little to no collisions, neither with other planes nor with the terrain. It even works with only a limited variation in height for the whole flock as you can simply add another rule, which encourages the units to steer towards the desired flight level.

Only thing I'm not sure about, is how that algorithm behaves for groups of aircraft traveling in opposite directions.

Other possible approach would be, to dig out the flow field system which was planned for SupCom 2 and see if that approach can be modified to be suitable for air units.

I'm reminded of this as well. www.youtube.com/watch?v=4ErEBkj_3PY

Surely the modern PC has the processing power to do this with a few thousand units, especially combined with flow field technology.

I've actually read most of Daniel Mellinger's papers. I have a massive engineer-crush on that man, as well as U. Penn.

Well i looks nice, would be even better with more inertia imo. But:

thats quite bad.

This certainly seems like one of those areas where the increase in CPU power since 1997 should be applied liberally.

THat's given me one of those slightly jarring but slightly mindblowing thoughts regarding the pace of change.

A 166Mhz Pentium with 32MB of RAM could run TA very well, and a 200Mhz, 64MB machine could run it pretty much perfectly.

Given the ~16x increase in processor speeds (not even accounting for multi-core and architecture improvements), and the ~125x increase in RAM, and the likelihood that PA will be able to trash any hardware you throw at it, it sort of makes sense that the RTS genre has stalled for a while.

And this is half the reason I have to put up with terrible code from coworkers. "We'll just run it on a faster computer" *begins rant on self taught programers*

Thankfully, Uber is not made up of my coworkers.

It's actually a valid answer for many situations. Not in game design usually, but everywhere else. It's often a lot cheaper to run it on a better computer.

That's true assuming there is any at all level of optimization and coding gains are expensive which may generally be true. But in my case, if I can spend an hour to make it run on the order of 1000x faster, I'm not sure the faster computer is worth it, and I know I'm not an efficient coder. MATLAB lets people get away with so many awful things, my best friend and worst enemy.

^I'd make a crack about doing professional MATLAB, but my job is mostly javascript (powerful, flexible, no fun).

I'd make a crack about calling grad school professional, but I'm the grad student

MatLab is all about liberal use of colons. ;P

I find it to be a great scripting language, but for actual programming; it's terrible.