Command & Conquer

They might have done this long time ago if hardware performance is not an issue especially on a game like this were you can produce a lot of units that adds strain to your computer.

Maybe they can add some sort of balancing manager to handle how much husks will be left behind like they did in CoD

Uhh, I don't think that's a good idea for C&C. The golden rule of C&C always have been and is: Keep it simple. No need to get things too complicated by adding such a feature.

Also ... the requirements, don't you think this would overstress almost any computer? Especially in huge freakin battles? I prefer them to disappear.

maybe the body can be a simplified model

But that doesn't answer the problem on handling their volume on the map, then again my CoD idea is there to do it.

Hm, lets see......

I Spam 1000 infantry,

All Get mowed down by quad Cannons

PC blows up.

That good news for ya?

this would be fun

I'd love to see more rubbish, fires, smoke, junk on the battle field, and unlike units, this stuff could be made with very few polygons, and potentially even be destroyed, at which point, it would turn into a heap of scrap and fade away into the ground ... OR ... stamp itself into the ground texture using normal mapping and other tricks like that.

No huge resource hog, but definitely a possibility for fun here.

If you killed units infantry with a nuke, they'd probably be vaporized, and if you blew up a unit powerfully enough, it would end up as shrapnel instead of needing a wasted model.

But everything instantly vanishing isn't that exciting.

Not really a fan of long-term persistent bodies. For one, seeing mounds of dead troops is disgusting, and should only be used to drive an effect home. For example, if GLA launches an anthrax attack on a town, then it would be really really powerful to see all of the civilian dead in the streets, slumping over other object and the like. That would be incredibly powerful visual imagery, something too powerful to waste on every game for simply the fact of "realism". I attribute it to the generic "BLOODY DEAD BODY!!!!" in every FPS; when used correctly, it can drive the emotional moment home, but otherwise it's a corny and cheap trick.

Second, when you have specific gameplay implementations for persistent dead bodies (the requiring of pushing them over to access paths), you better darn well make sure that everyone will have the capability even those who need to have the lowest of low settings. It's never a good thing to give people who pay more money for better hardware an advantage, but it's even worse to punish them by requiring them to do more work.

All you need to do is limit the number of persistent bodies. You create a pool of say 1000 'bodies' that the PC can handle; then as more die, the oldest one disappear (get pop'ed off the stack). You can also remove the bodies after 1 minute or so from the stack so they aren't drawn. If you have a 'system monitor' that checks the speed of the system, the first thing it can do if it tracks things slowing down is remove bodies from the screen and tidy up memory. You only need to store 3 bits of information anyway, the bodies location, type, and 'time of death'. You only draw what's viewable by the player anyway (so you could limit it to only show 50 bodies on the screen at once). Its low system intensity if done right.

DoW1 has this feature. It is kinda cool unless you get blocked in a corner and are trying to hold out. Then all you have dead bodies all over the entrance to your base.
I think if you are going for realism, then focus more on the terrain. TS had the option to turn on terrain scarring. I really enjoyed that feature of the game because you could literally change the terrain around the map to fit your needs. Also, it was cool because if you bomb somebody's base extensively, there would be craters and potholes to reflect that. I haven't seen that feature on many games lately, I would love to see it return.

All of that is well in good if the bodies don't heavily impact the gameplay (ie: the idea that dead bodies and husks can "block" paths and be required to be moved). Now as long as it's something like a TF2 style persistance, which is a rag-doll that doesn't inhibit anyone's motion. You also need to store more than 3 bytes as each body would have a collision detection proxy mesh to force objects to collide with it off-screen.

The only 1000 bodies option, again under the OP's original proposition of having gameplay affection collision and alteration of motion, won't work well because unless I personally keep track of the latest 1000 instances, so I can predict which one will "vanish" next. Even so, it's essentiall a monte carlo gamble as I can't always predict when that's going to happen. That wouldn't be a good system to use.

The time delay system would be the best option, as it's a constant that all players can be aware of.

The X bodies on screen at once is especially concerning, as bodies/husks may be there/not there depending on what the screen is showing each player. Again, this works if bodies/husks where either non-colliding, or didn't affect the live unit's motion, path, or speed directly or indirectly (like colliding with another object, thus stopping the live unit).

I think they could do it like Dawn of War. Give us the option ranging all the way from no persistent bodies at all, all the way to all bodies persistent. In between you could have "bodies disappear after X number of bodies are on the screen", so for example after the 101st body is on the screen, the 1st body would disappear because you set it to only 100 bodies.

Such an option I don't think would hurt the engine. Stronger computers would be able to handle it. Weaker computers would just have it turned off. End of story.

How do you address this?

fix'd

But anyway, I'm against this madness!

That wouldn't have to actually be a part of it. I know the OP says it, but it's not necessary in order for this to be good. In fact, I'd rather they were just visible, and completely non-interactible. Though honestly if I'm reading that correctly it shouldn't really matter anyway.