Spring RTS Engine

I think these suggestions would rock, but only when watching a demo, because while playing I doubt anyone will be that close to his units to see the details that are proposed here. Maybe we can also have burning wreckages, which seems pretty realistic to me.

Burning wreckages: yay. devoting cpu power to animating used cannon-fodder: nay.

Its little things like death animations that really make a game.

I don't know about you, but I notice aircraft falling out of the sky in heavy engagements, units being shunted to the side by explosions, and the kickback of heavy weaponry...

I agree whit both.

On one side, this would make battles even MORE cooler then they are now, and less work creating death animations that in the end look corny reptevie.

On the other side, i got an old computer, and whit a large battle (30 peewes vs 30 aks (yes, noone uses aks, but still) the vrekathe animation would cause slowdown.

May i suggest that as soon as the wregathe has finished it animation, it becomes unmobile, as any other wreckage. And that ther should be a wreckage LIMIT. I seen my computer struggle to the max to render 300 pelican corpes + boats, and other dead stuff. The lag was... horribole.

Yeah, as I said earlier in this thread, I understand that my original suggestions was too hopeful, and I toned it down to, so that I only wanted Spring to Generate death animations for units, after which the same old wreckage system is used.

Now, really, WHY would you need an automatic death animation creator. Just really, WHY? Why can't you make something yourself, especially with the new animation interpolation system? Really, death animations should be handled by script while the unit lives (or rather, twitches in agony), and then the unit just dies, and leaves a corpse. This system is rather easy to implement, and allows for great modding flexibility. Why use automatic animation generators, I'll probably never understand...

If it's possible, break apart every piece of a unit and implement some simple physics on the parts. Then use the same maths that calculates the amount that a weapon deforms ground to work out how much 'push' weapons have. The more push, the higher the chance of the part breaking off. A high push will also make a part get 'blown clear'. So a unit killed by lasers will basically just get a change to its texture, whereas a unit hit by a bertha will be blown across the entire screen.

If this works well, then it opens up an entirely new level of complexity - parts falling off, cannons etc. Kind of like in MAD TA. I'm not saying get rid of corpses, I mean there are still many OTA fanatics. But this could be an EXCELLENT feature for mods on TA or other games.

Infact, if units have two textures, paint and underneath, and even a third, burnt texture, then we could use paint being stripped off units to determine at a glance how much life they have.

The method for determining texture 'tear' could be something like this;
You calculate the distance of each vertex from the blast center, then assign it a damage value based on this and the 'push' of the weapon (explosions strip off more paint than lasers). The three textures across faces are then melded based on the damage value of the four points.

When a unit explodes, the explosion does high damage to all its vertices, and pushes the parts quite a bit. So if a part breaks off in the killing blow it goes flying, and also the texture undegoes a drastice change. So it will still be very obvious whether a unit is dead or not.

You're also forgetting that sometimes the unit isnt the end of a weapon shot. For example shoot a wall with a laser and soon enough the laser will come out the other side.
Shoot a peewee with a bertha and it shouldnt just break apart and splatter over the screen in a fiery death, the bertha shot itself should carry on throuht he peewee tho at a slower speed causin less damage.

Thus

Uh... Mirrsen, that's exactly what I said. To a T.

How about you have ragdoll phychics? for K-Bots that would be awesome, for tanks it could probably better determine where the tank ends up when dead...

Mmm, FPS physics in an RTS, cpu crushingly beautiful.

You know, there is probably a way to mimmick ragdoll physics without having to actually have any CPU calculations.

For example, you could make it that when any kbot is flung into the air, it runs its walking animation at twice the speed it usually plays. This should look like the Kbot is kicking and screaming through the air. You could also allow players to make their own animations for when a unit is flung into the air. To increase the effect, I'd say that units should get flung into the air more often, and not always terminally. I think this would be done by dividing the unit's estimated weight (judged by its metal cost, I believe) by 1/3 or 2 or something...

Warlord Zsinj wrote:...
For example, you could make it that when any kbot is flung into the air, it runs its walking animation at twice the speed it usually plays. This should look like the Kbot is kicking and screaming through the air.
...

I dont think that would look good, just reminds me of Black & White where the villagers did something simmilar when you threw them.
Shure, looked ok (at best) from a distance, but if you got a little bit closer, it looked like crap.
But who knows, maybe works better in spring.

...
To increase the effect, I'd say that units should get flung into the air more often, and not always terminally. I think this would be done by dividing the unit's estimated weight (judged by its metal cost, I believe) by 1/3 or 2 or something...

I agree.

That wouldn't look very good, especially on the landing.

I don't need flying animations when I have the NEO PEEWEES. I once saw a peewee getting flung into the air in a low trajectory above a horde of Core units, and while they aimed their guns on him, he turned around (midair!) and started spraying his EMGs on them. I think he killed one, too. Unfortunately, he had no chances of survival.

Limbs flying off when a unit dies, or gets damaged, is possible, and more than that, IT IS ALREADY SO. It's just that the corpses for such situations are usually a heap of rubble, not something distinguishable.

Weapons need a new tag, to keep them bouncing through units, and forbid them bouncing on land.

You have to ask yourself, Delta, would you rather have it, and make it look average, or leave it as it is with nothing. Units remain completely motionless when in the air (I have yet to see a matrix-peewee ).

I don't think it would look bad, given that units don't fly half as far as they do in Black & White, and it is certainly better than nothing.

Absolutely...

Spring do already so much reinterpretaion of scripts it kills all my complex scripts. The more the engine try to create new animation on the fly the less scripters can control their hand-made animation. And so the less new cool amazing scripts can be scripted in Spring.

But zw, your scripts were done using clever workarounds in an engine where what you are trying to do was never intended to be done.

Why use a workaround, when in Spring you can do it directly?
You just need to realise that Spring isn't OTA, it is an entirely new game using the best bits from OTA. Because Spring is different to TA, it invalidates a number of assumptions your scripts make.

The other thing of course, is that with those advance scripts only you could really do them, which means it took 6 years of scripting evolution to reach the point that you have. Why should it be so complicated, exploring the depths of the engine, when Spring can do things directly, and easily, for everyone?

I disagree with Warlord's suggetions, like Z said, this would be detrimental to the customizability of units.

As for Ragdoll physics, they could be enabled or disabled by the user.

It's already been done in Generals as far as I can see, or at the very least a simulated rag doll physics.

I highly dounbt they would be hard on the CPU.