Reactive buildings

Oh sorry, let me write the (as you say, trivial) AI for you.

Code:

int timeout; = 3 //seconds
int counter = 0;
if (thisUnit.hasFlag("TakingDamage")) then {
    thisUnit.packup(); // ok there may be a little bit of code to handle
                       // the animations in this function, but it would be a
                       // simple matter of copy/paste once it is created for one unit
    counter = 0;
} else {
    counter++;
    if (counter >= timeout) then 
        thisUnit.unpack();
}

Not the most efficient code in the world, but given it took me less than 3 minutes to do it no big deal. And it is reusable.

hasFlag("takingDamage") is tricky part. You also need to account packing and unpacking animation speed and trigger increased protection after some moment. You can't just count frames - you need to operate on time. Also, this should be done on both server and client and "packed" is actual unit's/structure state that should be propagated to all interested clients. And in case if you are a client and just saw this unit, you need to skip n first animation frames to make correct animation.

And even if you are doing it for one unit it makes sense to make a framework, so you may easily tweak or replace this unit later. So... All this is trivial, but it's much more of code than you imagine. And this code adds complexity. For what?

If we want to stop trivial damage from closing them, why not make it close after taking a set amount of damage.

I don't know how to code, or i'd show an example, but:

int timeout; = 3 //seconds
int counter = 0;
if (thisUnit.hasFlag("Takingset numberDamage")) then {
thisUnit.packup(); // ok there may be a little bit of code to handle
// the animations in this function, but it would be a
// simple matter of copy/paste once it is created for one unit
counter = 0;
} else {
counter++;
if (counter >= timeout) then
thisUnit.unpack();
}

That's certainly written wrong, i just hope it shows what im trying to explain. After the solar generator has taken a set number of damage, in a short period of time, generator closes. I don't know how to add a time factor in coding either, so forgive me my vagueness...

You are forgetting one thing, namely that all that stuff about timing the animation between client and server will have to be done anyway (unless there are no animations for anything...). Boo hoo I have to irregularly send an extra bit of data to clients to inform them on the units current state, oh noes it might get lost between the position, orientation, health, isStunned, isExploding, isOn etc of the other 10,000 odd entities in the game.

The *unique* code required to get a solar plant to fold up IS trivial, and relatively small.

@sabetwolf Adding a minimum threshold of some sort would be appropriate, either that or getting it to ignore certain damage types (like damage from exploding buildings and crashed planes, the main sources of "trivial" damage).

Yup, I laid out some options / rough guidelines for such systems earlier in the thread.

Mike

Units don't have complex long animations, you don't need to sync them, you just need to design your units in that way so nobody notices the glitch. You can do this with any simple short looped animation.

You want to make "structure" a "unit with zero max speed", so it may support anything that units do support (including flag "receivingDamage"). But with that you'll also need to program a lot of useless callbacks for every structure that are only relevant for units. More or less, you always do prefer explicit separate well-defined groups of functionality without some kind of "doEverythingClass" hellish all-rounder. Navy is different kind of units and Turrets are different kind of structures.

To make that in OOP fashion, you need to deploy a complex hierarchy of classes, so each unit/structure goes. Turrets are reactive by default, so it's easy to implement popup turret, but resource stations are not reactive, so you need to make them reactive. And this will affect all resource stations. Or you need to add another class for reactive resource stations specifically. Or make multiple inheritance. Or make solar collector a turret.

It's always takes you 1 day to implement feature, 2 more days to debug it, 4 more days to write a usable tool for artists/gamedesigners and 12 more days to reimplement all this as Right Thing™

So it's not trivial as you think. It may lead to complete redesign of all callback system. And fast-and-easy hacks are not the solution.

Please, stop talking about implementation in code. You are sounding clueless. (To everyone)

Sorry, but your experience in Zero-K is not an argument here, as it's a different model.

Dude I'm just a webdeveloper and I think you're sounding clueless. If they'd need to redesign their event handling system at this point in time for any reason, they've done something very wrong. That's a pretty basic system with a lot of default implementations.

I'd rate them higher than that.

Yep I'm joining the clueless bandwagon.

Lets see who do we have in this thread. We have googlefrog who, as you say, worked on Zero-K (fyi different model is a joke of a reason to dismiss him). Then there is pluisjen, a webdeveloper. Not the same field of programming but he probably knows how a team of programmers work, and how they structure their projects. Then there is me, final year IT uni student that likes programming and has done a bit of most types, including working for some quite large companies. Then there is you, nightnord who... I'm sorry, what were your credentials? please tell me its more than having google open in another tab.

Now, back to your ling-winded reply. Did I mention any data that was specific to units and not buildings? No.

Also there are plenty of animations which similar to the solar deployed that need to be synced. An artillery unit being deployed, a nuke firing, the separation sequence for a space rocket etc. Don't be so naive to think that just because there you don't want buildings to have animations that the underlying framework and necessary code for those animations aren't already there in part or all-together.

OMG I have liuik alll the credentials! and yuu have lke non!


That's what you sound like.

Ignore Nightnord, he's an obnoxious tart.

Well I'm glad we settled that. Back to the topic.

So far some ideas are:

- Fold up solar plants
- Turrets that pop up from the ground

What other things could buildings do to react to their surroundings and otherwise be awesome?

Mines? some kind of trap?

Mines are ridiculous in RTS, and discussed at length elsewhere.

Really we've discussed the pros and cons of this idea enough for the devs to know how we feel. We also had a whole lot of dickwagging and general idiocy. COUGH NORD.

Mines generally deplete after use which makes them not that effective. A temporary line that would not deter a sustained assault. Also not very practical to build more while under attack.

On the other hand, it provides a reason to use T1 units (as fodder) when you are already teched up to max.

In the context that T1 units are inferior to T2 units as per SupCom/FA I'm assuming.

Mike

Mines can be the first line of defence and can force the opponent to attack from 1 angle. If he attacks from another angle he will step on more mines. Mines can also be placed infront of defences. When the enemy tries to overrun the defences his units will most likely be bunched up and an AoE mine will hit several units.
The most interesting use of mines I have seen is in XTA on the Spring engine.
Mines are cheap, fast to build and deadly.
In many occasions they are better than stationary defence since the attackers units go boom and if he hasn't seen the mines being built he are unlikely to know that are any defence there at all.
They create a metagame where the attacker don't know if he should spread out his units, weather there are several lines of mines, where they are placed and so.
In XTA mines are very fragile so putting them near own units are likely to result in them blowing up as the friendly units take fire.

I think TA proved how mines are a thing to avoid.

Either you would never build them, or always would.

Correct igncom1, mines are crazy hard to balance and don't work every well against human opponents.

@godde, all i need to do is attack the ground in front of me and no more mines, or send in fodder first (the cheapest scout unit for example), or use hover units, or artillery, or go around, or just attack the enemy and let the splash damage deal with them.

Other examples of cool building effects:

- Buildings that suck power (shields, massfabs, heavyarty) may form a visual power line between buildings towards nearby power generators.
- Moving attachements eg radars, cameras, spotlights etc.
- Radar towers with a airRaid horn that goes off (in an ambient noise kind of way) if an air unit passes overhead
- Walls that form ramps when units are nearby to let them drive over.


Just off the top of my head, with little regard to suitability and balance.