That little bucket of ideas.....

[kage]

I think we should create a property uint32 'effectFlags' of base_object and store effects on unit/structure(either positive(like a moral bonus) or negative(on fire,slowed down due to heavy damage etc)) there,then update them in droidUpdate/structureUpdate functions in main loop,this way we can add/remove specified special effect(s) with some cheap AND/OR operations and make the effects-on-unit more manageable.

the way wz tests whether a droid/structure is on fire or not is a bit hacky,it will become horrible if we have tons of effects on a single unit at one time(each property will need at least an additional BOOL in unit/structure struct)

all the more reason to replace a bit of the game loop with an event queue, and add a system to units that allows for an arbitrary number of "states".

[DevUrandom]

NWN uses "effects" which can be attached to an object. (I think even damage is such an effect.) Those can be removed at any time. (At leasts that's how I remember it from my NWN-modding time.)
Maybe we could use something similar here.
struct droid{ ... listOfEffects* } or similar.
That's a lot slower than a bitmask, but the most extensible thing I can think of. An effect could be anything and we could even let scripts create new effects so they can implement whatever someone wants...

[Watermelon]

NWN uses "effects" which can be attached to an object. (I think even damage is such an effect.) Those can be removed at any time. (At leasts that's how I remember it from my NWN-modding time.)
Maybe we could use something similar here.
struct droid{ ... listOfEffects* } or similar.
That's a lot slower than a bitmask, but the most extensible thing I can think of. An effect could be anything and we could even let scripts create new effects so they can implement whatever someone wants...

hmm isnt NWN alot less responsive than wz(very long cooldown between combat events)? so I assume it's not very demanding for performance when doing effects stuff like wz does.

I think a bitfield is not sufficient to store neccessary values of effect,so a hybrid of bitfield and wz's 'stats pointer/index id' might be a better approach,e.g:

typedef struct _effects {
uint8 id; or struct effect_stats *stats; //index or pointer to detailed stats
uint32 timestarted; //
uint32 timeelapsed;
...other userinfo...
} EFFECTS;

typedef struct _effect_stats {
uint8 id;
uint32 duration;
sint32 damage; //positive damage negative heal/repair
...etc etc ...
} EFFECT_STATS;

typedef struct _droid {
...etc etc...
uint32 iEffects;
EFFECTS effects[MAX_EFFECT_TYPES];
...etc etc...
} DROID;

//global asEffectStats storage
EFFECT_STATS asEffectStats; //read from external data source

DROID *psDroid; //passed to process effect function
EFFECT *tempEffect;
EFFECT_STATS *tempEffectStats;

if (psDroid->iEffects & EFFECT_ONFIRE)
{
tempEffect = psDroid->effects[EFFECT_TYPE_ONFIRE];
tempEffectStats = asEffectStats[tempEffect->id];

if (tempEffect->timestarted == 0) {tempEffect->timestarted = gametime;}

if (tempEffect->timeelapsed >= tempEffectStats->duration )
{
tempEffect->timestarted = 0
tempEffect->timeelapsed = 0
psDroid->iEffects &= ~EFFECT_TYPE_ONFIRE;
}
else
{
damageDroid(psDroid, tempEffectStats->damage);
tempEffect->timeelapsed = gametime - tempEffect->timestarted;
}
}

if (psDroid->iEffects & EFFECT_ANOTHER_EFFECT)
//do something
...

[kage]

NWN uses "effects" which can be attached to an object. (I think even damage is such an effect.) Those can be removed at any time. (At leasts that's how I remember it from my NWN-modding time.)
Maybe we could use something similar here.
struct droid{ ... listOfEffects* } or similar.
That's a lot slower than a bitmask, but the most extensible thing I can think of. An effect could be anything and we could even let scripts create new effects so they can implement whatever someone wants...

exactly the sort of thing i was thinking. and, hey, at least an array of ints/pointers is a hell of a lot faster than an array of strings -- think of how much worse it could possibly be. in the current system, iterating through each effect really is pretty damned slow, but with an event queue in place, it's not that much of an issue... take for example, checking to see if a unit is on fire -- i'm not sure how it's exactly done now, but it might be something like this:

Code: Select all

gameloop_iteration:
  unit_iteration:
    if on_fire is set:
      do_flame_damage( this_unit )
      ticks_of_flame_left--
      if ticks_of_flame_left is 0:
        unset on_fire

with an event loop, it's something like (semi psuedo code):

Code: Select all

//prototype
schedule_event( *action actionToExec, int tick_of_execution );

void unit_hit_by_weapon( *unit unit, *weapon weapon ) {
  apply_base_weapon_damage
  for each of weapon.effects:
    check to see if effect applies, else continue
    push weapon_effect on to unit.listOfEffects
    schedule_event( remove_effect weapon_effect from unit.listOfEffects, current_tick + weapon_effect.duration );
}

note that i avoided putting any damage stuff into the event-based alternative since there are a whole lot of good and bad ways to handle damage -- for example, if we use a dedicated server, then the server can avoid checking flame damage every tick by changing unit_hit_by_weapon

Code: Select all

void unit_hit_by_weapon( *unit unit, *weapon weapon ) {
  apply_base_weapon_damage

  for each effect in unit.listOfEffects:
    unit.hitpoints -= effect.damage_per_tick * ( current_tick - effect.most_recent_tick_applied )
    effect.most_recent_tick_applied = current_tick

  //optimize this if you like by putting it in a few other places above
  if unit.hitpoints < 0: kill_unit( unit )  

  for each of weapon.effects:
    check to see if effect applies, else continue
    push weapon_effect on to unit.listOfEffects
    schedule_event( remove_effect weapon_effect from unit.listOfEffects, current_tick + weapon_effect.duration );
}

note, the above isn't nearly complete, and doesn't cover many edge conditions, but the most common codepath is pretty much there.

remove_effect() would apply any remaining damage. with this kind of system (if it made any sense), the minimal game client would show a constant drain on a units hp when on fire, but the server would not apply damage every tick, but rather only whenever the unit is further hit, or at a precalculated and scheduled time when the sum total of all effect damage to a unit would kill it. this, alone, if all the edge conditions were properly accounted for, would entirely remove the need for a tick by tick check of effects, and there are numerous optimizations on top of optimizations that can be added.

edit:

it looks like watermelon's code fits pretty well with an asynchronus system, like the one i proposed above (if it were purely tick-by-tick, then timeelapsed would not be needed)

[drax]

I would like to suggest some things which, I think, would be great to implement in this game.

1.
In options menu to offer left-right click customization.
For example, I used to when I select unit and want to move somewhere I click right buttob, but in WZ2100 it is used left button.

2.
To use people in tanks.
Eg. machinegun tank can contain 2 people, 1st for driving, 2nd for shooting, and max transportation units to be 5. Units inside tank can die eg from flametrhower or snipper or 2% chance to die from machinegun etc. People inside can leave tank alone and when they do that, tank will be inactive.
This is something like C&C Generals, where people are used in all vehicles.

3.
Other types of vehicles like jeep, bike helicopter...

4.
Camouflage units (like spy's) and some stealth units could be nice.

5.
Also, some nations would be cool, different technologies etc.

- Robot as Metal fatigue : http://en.wikipedia.org/wiki/Metal_Fatigue (which permit construction of "Mechs")

It would be great to implement this thing.


Thank you for such a great game.

[Zarel]

1.
In options menu to offer left-right click customization.
For example, I used to when I select unit and want to move somewhere I click right buttob, but in WZ2100 it is used left button.

This feature is already available in 2.2.

[EvilGuru]

In future please do not resurrect the dead

That is a privilege reserved for the T-virus and messiahs.

Regards, Freddie.

[drax]

This feature is already available in 2.2.

Sorry, I didn't know that.

Just two more suggestions

6.
Chatroom (for internet play) in game instead using mIRC (or any other IRC client) would be good.
eg.
Multiplayer Menu:
-Host Game
-Joing Game
And below these buttons to be chatroom.

In chatroom to be some options like: invite to join in game, ban from joining game...
This should be something similar to blizzards warcraft chat.

7.
possibility to save or make IP favorites list (on this way no need to enter every time IP to join in game)

[robby_kane]

Adding an Air-to-Air homing missile would probably fix this,and we also need a counter missile missile  if it's overpowered.

how about
http://www.youtube.com/watch?v=CAFCudNN ... re=related

[Asterisk]

OH GOD YES.

What ild like to see....

Close range weapons... e.g. some sort of basher/smasher... very high dammage but has a very high risk because it has to get in range...
Differnt types are effective against differnt things... e.g. one would be for bashing buildings...

More propulsion options... (this one will be hard)...
We already have...

wheels
half tracks
track
hover...
2 legged...(cant customize it though =/)
suggested 4 legged...
vtol.
suggest propulsion between vtol and hover.
Suggested helicopter system... (very hard to implement i thinks...)

Some of these will not be able to be customizeable as they are exclusive to things like cyborgs only... being able to customize such things would be great 2...

[ThomasCarstein]

2.
To use people in tanks.
Eg. machinegun tank can contain 2 people, 1st for driving, 2nd for shooting, and max transportation units to be 5. Units inside tank can die eg from flametrhower or snipper or 2% chance to die from machinegun etc. People inside can leave tank alone and when they do that, tank will be inactive.

I have often wondered, if there really are any live people inside those tanks and from logic conclusion I'd say that there aren't, and that the tanks are remote-controled or autonomous.
Think about it: the game's setting is a few years after the collapse - a nuclear holocaust which destroys most of the human and animal population on the planet. After the nuclear blasts the survivors (as is stated in the intro) fought for food and so decimated the population even further. The survivors from Seattle, which are shown in the intro, are driving in 2 military trucks, which suggests that they were no more than 12 - 20. I seriously doubt that they would manage to reproduce sufficiently in 4-5 years later (also think about the radiation damage to their reproductive organs) to put 2 - 5 persons in to each of the 100+ vehicles you can make Furthermore - the land is a nuclear irradiated wasteland and I doubt that any sane person (except scavenger raiders who have nothing to lose and no other options) would want to drive around it in person or even venture out of the vehicle - if you look at Chernobyl for instance, they used robotic and remote-controled vehicles for the heavier work; they only sent people for smaller stuff since they couldn't be on the hotspot for more than 30 seconds else they would die in 12 - 48 hours.
All in all I think that it would take a long time to get sufficient manpower to put at least one person in a vehicle - too long for any use in WZ 2100.

3.
Other types of vehicles like jeep, bike helicopter...

Most of these vehicles were destroyed in the blasts, the survivors probably ransacked and scavenged the rest so they probably would not be working anyway :-S . As for bike helicopters - I haven't seen one yet But if you meant "bike, helicopter..." then I should only say that driving around in the already mentioned nuclear wasteland on a bike would be a 100% suicide mission; as for helicopters - that's what VTOLs are for (Helies were the first VTOL anyway ).

Bye, T.

[Asterisk]

The background hasnt been states if the radiation was like chernobyl or w/e.

Never know, some animals could survive... i really doubt all the earth would have been made into citys without atleast some forrests... most of the forrests would die out but like... a few would survive... >.> (as seen by plants... and the plants that were not used >.> lol)

Bikes and helicopters/what ever unused small vechiles should be given to the scavangers.

[drax]

Most of these vehicles were destroyed in the blasts, the survivors probably ransacked and scavenged the rest so they probably would not be working anyway :-S . As for bike helicopters - I haven't seen one yet But if you meant "bike, helicopter..." then I should only say that driving around in the already mentioned nuclear wasteland on a bike would be a 100% suicide mission; as for helicopters - that's what VTOLs are for (Helies were the first VTOL anyway ).

Ok, but I am still for that bikes, they could be a super fast transport and stealth (or at least hard to see).

[zoid]

when i was saying "go crazy", i meant at low levels -- the right kind of sound can do that, as in purely accoustic with no destructive resonance (think of a really high pitched sine wave, that alternates with just enough randomness to keep the brain from adapting). at much higher aplitudes, or at certain frequencies, you pretty much die instantly if you're lucky (severe aneurism), with maybe a 30 year coma if you're unlucky, and normal armored vehicles wouldn't provide any protection at all depending on the delivery mechanism -- they'd have to be very specifically sound-proofed

Um, the game makes it pretty clear that units are remote controlled via synaptic link. The only humans that get killed are the Scavengers. Besides, we already have EMP and Nexus in multiplayer.