Dune 2 Unit Game Mechanics

[Vanshilar]

Have people looked into how Dune 2 decides how long to delay before a unit fires a projectile? I'm aware that the game editor (specifically, Nyerguds' editor) has a game field "Weapon rate of fire". However, there are two problems with this:

 

1. The times given by this data field doesn't seem to line up with in-game testing. For example, it says that tanks and sonic tanks have a rate of fire of 80, siege tank has 90, devastator has 100, and launcher has 120, but testing shows that their cooldowns are all within 10% of each other. For troopers, trikes, and quads, it states 50, but their cooldown is roughly 80% of the heavy vehicles.

2. Some units fire a second projectile if they're above 50% health. That slightly increases the total cooldown per cycle of 2 shots, by roughly 5% or so.

 

Additionally, troopers fire different projectiles based on range; I'm not sure if there's info on the two different projectiles.

 

Admittedly I tested this on the "slowest" speed setting, so I don't know if I'll see a bigger effect at a faster speed. However, the difference seems a bit much; there's a difference of 30 (50 vs 80) between the troopers/trikes/quads and the tank, but 40 (80 vs 120) between the tank and the launcher, yet the tank's firing rate is much closer to the launcher than the former group.

 

Anyway, I sort of figured somebody else has probably looked into this before, especially if the game has been modified for player vs player so knowing each unit's damage-per-second (DPS) is important. But I haven't found data on this. I was going to do some field tests (in fact, already have a saved game set up for this), but I don't want to duplicate effort that's already been done.

 

As a side note, I also don't know if anyone looked further into how projectiles will sometimes do half damage based on the location of the shooter and the target, and the game speed. I previously posted about it here (I'm Javichal, just I've long since lost the password and email) but didn't really follow up with further testing:

 

http://forum.dune2k.com/topic/19996-info-dune-2-half-damage-bugtip-plus-question-on-fremensarduakar/

 

I still think it has something to do with the projectile exploding not directly on the unit's location, thus the unit taking half damage -- but it can be important from a micromanaging standpoint, seeing as how you can reduce the damage taken by 50% or more. I tested using Dune 2 though so this may no longer be an issue in the Dune 2 mods.

[Vanshilar]

Just an update on this. I did some testing on fastest and the unit rate of fire seems to line up with the game's stats a lot better. The data is basically:

Unit	        RoF	fastest	slowestSoldier    	45	8.59	24.53Trooper (can)	50	9.02	26.59Trooper (roc)	50	9.03	26.14Troopers (can)	50	8.84	26.61Troopers (roc)	50	8.8	-----Trike   	50	8.83	26.63Quad    	50	8.78	25.97Tank    	80	13.54	33.5Launcher	120	20.38	34.57Siege Tank	90	15.45	33.31Sonic Tank	80	14.84	33.31Devastator	100	17.04	33.43

"RoF" is rate of fire from the code (given by Nyerguds' editor). "fastest" is how many seconds between shots on the fastest game speed. "slowest" is the same for slowest game speed. "(can)" refers to the bullet projectile, i.e. close range, while "roc" refers to the rocket projectile i.e. long range. The testing conditions were that all were in the red in HP, except for the troopers, which were at half. This is so that all were firing only 1 projectile, not 2, which slightly increases these numbers.

 

Basically it's as if there were about 5.66 game frames per second on fastest, but on slowest, it doesn't really follow the given numbers as much. I only measured two shots for each so there's quite a bit of measurement error (the cooldown timer is somewhat randomized), but as I measure more shots (I recorded about 10 minutes' worth of them firing) the numbers will hopefully be more in line with the stated numbers. However, the rate of fire on slowest doesn't really match up well to the stated numbers.

 

By the way, troopers do 4 damage using their rocket (2 if halved), while they do 5 damage with their cannon/bullet (2 if halved), so you should move them if you want them to do more damage.

[X3M]

Good job.

 

I find it odd that at a slow pace, the firing rate is off.  You would expect the other way around since the frame rate is of influence as well.

Does the moving projectile have any influence on the total data? Meaning that if an unit shoots, it waits till the projectile hits target. Then starts counting for itself?

[Nyerguds]

Have you looked into the OpenDune code? Everything should be in there somewhere.

[dynasty]

The delay between two shots is always 5.

 

Testing should be done on normal because on any other game speed the

game will adjust the numbers, which is prone to integer arithmetic,

overflows, etc.  There's even an overflow for deviators on normal

speed.

 

The game works with RoF*2, and on the slowest game speed it further

increases the delay by *2.  However, the final value is capped at 255,

so all RoFs above 64 look the same on slowest.

 

Good job.

 

I find it odd that at a slow pace, the firing rate is off.  You would expect the other way around since the frame rate is of influence as well.

Does the moving projectile have any influence on the total data? Meaning that if an unit shoots, it waits till the projectile hits target. Then starts counting for itself?

No.

[Vanshilar]

Hmm I haven't bothered looking into the code of the various open source versions. Are they based on the game executable itself (for example, through people essentially transcribing what the original game executable did) or are they based on independent code that's made to resemble the original game? If it's former then looking into the code would be useful, but if it's the latter then it just depends on how faithfully people tried to understand and emulate the original game's mechanics so it may not be as reliable.

Hmm the delay between two shots always being 5 -- is this regardless of game speed, and/or regardless of the subsequent RoF*2 thing? Is it subject to a randomization amount? It seems like the regular cooldowns are randomized somewhat; two units firing in unison won't be firing in unison for very long, although it may have other causes (such as the game frame thing where lots of units tends to slow things down).

I think testing on each difficulty is relevant because people will play at different speeds, and it may be useful to consider DPS outputs based on the speed that the game is played at. For example, with the cap at 255, it means that the launcher at slower speeds is relatively stronger compared with other units than at faster speeds. It's basically to see how the game really works -- although, yeah, if I were to try to match up with the values in the game files, then maybe testing should be done on normal.

If the game works with RoF*2, what are the cooldowns for the speeds other than slowest (*2)? It seems like fastest is roughly *.67 or so.

[Vanshilar]

Okay so digging around the OpenDune code quickly, in script\unit.c, function uint16 Script_Unit_Fire(ScriptEngine *script), it seems like the relevant part is this line:

u->fireDelay = Tools_AdjustToGameSpeed(ui->fireDelay * 2, 1, 255, true) & 0xFF;

"fireDelay" is apparently (I'm assuming) the rate of fire variable in Nyerguds' editor. Additionally, if it's the 2nd projectile:

u->fireDelay = Tools_AdjustToGameSpeed(5, 1, 10, true) & 0xFF;

So yeah it gets adjusted by the game speed. Additionally, at the end:

u->fireDelay += Tools_Random_256() & 1;

This appears to be what randomizes the actual cooldown.

 

Anyway I guess I'll digest this for a bit, since I'm not that familiar with coding.

 

From uint16 Tools_AdjustToGameSpeed(uint16 normal, uint16 minimum, uint16 maximum, bool inverseSpeed) in tools.c, it seems like the modification based on game speed is:

 

slowest: twice of normal

slow: 1.5x of normal

normal: normal

fast: 3/4 of normal

fastest: half of normal

 

The Tools_Random_256() returns a random value between 0 and 255 -- but to me it seems like this would be too big, seeing as how troopers and trikes/quads have a cooldown of 100, so this randomization would overwhelm it. Also, this is after when the cooldown for the 2nd projectile is set, which would make it really long. So there may be something else going on here (for example, I don't understand the "& 0xFF" and "& 1" parts).

[drnovice]

http://en.wikipedia.org/wiki/Bitwise_operations_in_C#Bitwise_operators

 

Logical Bitwise "AND"

 

FFh = 255 = 1111 1111b

[Nyerguds]

Hmm I haven't bothered looking into the code of the various open source versions. Are they based on the game executable itself (for example, through people essentially transcribing what the original game executable did) or are they based on independent code that's made to resemble the original game?

OpenDune is a full reverse-engineered decompilation of the original exe file.

[Vanshilar]

http://en.wikipedia.org/wiki/Bitwise_operations_in_C#Bitwise_operators

 

Logical Bitwise "AND"

 

FFh = 255 = 1111 1111b

 

Hmm so if I understand it correctly, "& FF" really doesn't do anything (it'll just depend on whatever the other argument is -- although having that code there might be useful if the coder wants to change that value), but "& 1" means that it'll bitwise compare with 0000 0001b? In this case then, since it's paired with a random between 0 and 255, it means that 50% of the time fireDelay will have an extra 1 added to it? Although in testing the variation seems to be larger than this (i.e. a single game frame), but I'll have to go back through the data.

OpenDune is a full reverse-engineered decompilation of the original exe file.

 

Neato. Good to know.

[Vanshilar]

Here's some oddities about taking over enemy bases. Maybe they were known already and I simply hadn't done it enough (in the past I usually destroyed them instead of taking them over):

 

1. Turrets don't fire on enemy turrets or buildings, only units (including air units). Their bullets go through your own structures, but not the enemy's (and the same thing with theirs).

2. I unwittingly placed a turret on the same square where a computer turret used to be. The turret ended up firing on my own units, even though I could repair it and stuff.

3. I placed a heavy factory directly on where the computer used to have a repair center. While the computer still had his construction yard, it briefly became his repair center, but reverted to my heavy factory. I subsequently took over his construction yard, then later on my heavy factory was destroyed. His repair center reappeared on the same spot shortly thereafter and stayed around until I took it over, even though he didn't have a construction yard at this point.

4. When I took over the computer's construction yard, it was in the process of building a heavy factory. I repaired it and let the heavy factory finish, and then placed it (on what used to be walls and an outpost). The heavy factory I placed ended up being the computer's, and in fact the computer made a combat tank with it. I subsequently took it over and was able to make launchers with it (which I'm not naturally able to do, since I was Ordos), so the heavy factory was the computer's race (Harkonnen) and not mine.

 

So other than #1, it seems like the code for taking over enemy buildings and building in the enemy's base isn't exactly perfect, and has some idiosyncracies.

[drnovice]

This because of (I think with release 1.07) the CPU can rebuild over anything, regardless of what there is currently. It's programmed to rebuild the same building that has been destroyed (or take over by player) on the same room.

[MrFlibble]

It's programmed to rebuild the same building that has been destroyed (or take over by player) on the same room.

Actually, IIRC the AI will not rebuild a structure that has been captured by the player. But building a structure on the same place as a destroyed structure which was owned by the AI will not prevent it from rebuilding that structure.

2. I unwittingly placed a turret on the same square where a computer turret used to be. The turret ended up firing on my own units, even though I could repair it and stuff.

It's actually the AI's turret that fired at your units. Because the game does not check if there are any obstacles in place of structure that is being rebuilt, it ends up having two structures occupying the same space. You could repair your turret, but the AI's turret that was rebuilt in the same cell attacked your units.

The tricky thing with turrets is that they do not have House colours and are thus impossible to tell apart except for the minimap.

3. I placed a heavy factory directly on where the computer used to have a repair center. While the computer still had his construction yard, it briefly became his repair center, but reverted to my heavy factory. I subsequently took over his construction yard, then later on my heavy factory was destroyed. His repair center reappeared on the same spot shortly thereafter and stayed around until I took it over, even though he didn't have a construction yard at this point.

Again this happened because your factory and the AI's repair yard occupied the same space.

The only sure way to prevent the AI from rebuilding is to either take out its construction yard or capture its structures (don't forget turrets can also be captured).

[X3M]

Has anyone tried this?

 

Where the turret of an enemy was, a bigger structure of you is placed.

 

Will the turret eventually return?

[MrFlibble]

Good question. I'm not 100% sure but I think that when two structures occupy the same place, the do not coexist in the sense that if e.g. both are turrets then your turret will fire at enemy units while the CPU player's will fire at yours. Rather, they game seems to alternate between the two structures depending on certain circumstances.

IIRC, if for example you place a non-turret structure on the same place where an enemy structure stood, your structure will be in place as long as you don't do anything with it. But if you select that structure, there's a possibility that you will - somehow - select the rebuilt AI' structure instead, and it will temporarily replace yours.

Turrets are a bit different because they can act on their own, i.e. attack nearby enemy units. I think that once there are conditions for a turret to become active, it will do so and replace your structure.

I may be wrong, but I vaguely remember building a silo on top of an enemy turret once. And sometimes the turret would just pop up, and the silo would disappear. But the turret takes up only one cell while the three other cells occupied by the silo would be empty. However, clicking on any of them would actually select the silo and bring it back instead of the turret.

Please note that I'm not 100% sure that it worked that way. I did not test that further either.

[X3M]

Well, I experienced once that my own Refinery was shooting my Harvester that just got deployed after emptying. So at that point the turret was already there, but not visible.

 

I don't remember which side the turret was.

And you would expect the turret to be targeting my own structure. But that didn't happen at all.

[Foxman]

Hi,

 

i am from germany and i am working on new Dune scenario for the Amiga Version 1.0 of Dune 2.

My question is, what is meant with the [team] command in THC´s Editor?

 

 

How can I set the task the troops should have just kept coming (reinforcements)?
Guard ? Offense ? Hunting ?

 

thx 

[drnovice]

Maybe this can help you:

http://www.myway.de/richieland/Dune%20II%20Scenario%20Format%20Specification.pdf

 

Please note that some key in this document doesn't work in original version (see only "Version < 2").