Jump to content

Alpha 2 - Bene Gesserit version out


Recommended Posts

[pre]What do we see in most RTS games: Dune II; WarCraft 1,2,3; StarCraft? I mean the

way they implemented the battle process, the way units fight.

In WarCraft a fight consists of alternate strikes by the two fighting units.

Every strike causes a certain damage (usually much less than the hit points of

the units). So the fight is long, monotonous and predictable.

In Dune-II we find the same. Shots are taken by turn by the fighting units,

which do nothing except shooting at regular intervals of time. That is too an

annoying, long, easy to predict process.

Thus, as usually, in RTS units fight in a very primitive and boring way.

In the times of Dune II that was the only way to implement simultaneous action

of many units in real-time: then the performance of PCs didn't allow more. But

now it's quite another matter: it is possible to make the battle process more

realistic and interesting, less predictable and annoyingly monotonous.

But, in spite of this fact, a majority of modern games are evolving in an

extensive, degenerated way. All development has been reduced, in the most part,

to improving graphics, audio effects and other superficial properties, the

fundamental principles having being left unchanged for many years.

As the result, most of modern RTS offer us no new ideas as compared to early

ones.

In pursuit of profits developers make their games easier and easier to

understand, so that you don't need to reed a huge manual and think about what

you have read, before you can begin playing. This makes the game much more

commercially profitable.

But such games can not render a rich and complicated game universe as good as

games not constrained with the need to be profitable.

So, I propose that Stefan should try to improve the battle process in his game.

He may argue that his purpose is make his game as close to the original Dune II

as possible. Well, Stefan can make this version as a clone and develop another

one, not restricted by a full imitation of Dune II.

Improving the battle process will not affect the overall game atmosphere, or

even it will even saturate it.

IMHO, the following improvements can be made.

More differentiated and special unit properties.

-

Link to post
Share on other sites

At a glance, that would require an entirely new engine, particularly the 'what side are they facing', manoeuvering and 'lying down' states.

I'm going to propose an alternative set of ideas which might have a change of making it into the Maker project.

- Inaccuracy. I'm assuming Stefan already intends to put this in for Rocket Launchers anyway, but I reckon a certain degree of inaccuracy for other weaponry (even if it's just a slight random element and some graphical offsets for the bullets/explosions) should be possible.

- Cover for infantry. Since Dune is a very infantry-based setting, D2TM should reflect that a little. I suggest infantry be more vulnerable on concrete, where they're in the open, average on rock and sand, better on dunes and mountains (but slower), and also quite good where there are craters and ruined buildings. I can think of methods of setting these up, but I won't go into them here. Infantry may also have variable 'skill' in using these (LI - reasonable, HT - poor, Sardaukar - Fairly good, Fremen - very good) - if it's a multiplier applied to any bonuses, it could be for all units, where vehicles have 0.

- More accentuated differences in RoF, range, and perhaps speed; overall armour could perhaps be reduced (or firepower increased) as well. This will mean that siege tanks will have difficulty shooting multiple enemies, but will be devestating when they do hit (i.e. best against structures), whereas trikes can easily handle an onslaught of small units, but are also easily outgunned.

Already, you can see that the player will require some skill to get an edge over his opponent - tactical placing of infantry and a mixture of forces will be required to deal with different types of threats. Meanwhile, there will not be too much need for micromanagement (as the 'what side are they facing' element would introduce), and there shouldn't be all that much to code.

Ideally, I'd like to see a damage model, and perhaps even some collateral damage implemented. But we've got to remember that some of the more sublte ideas may require quite a lot of work for features that the AI will almost certainly ignore, and will make little difference to the player.

"Tanks should maneuver (not to stay motionless as in Dune II) to reduce the chances to hit themselves"

Hehe - Even before you said it, I thought 'Z'!

Link to post
Share on other sites

As I understood, you had proposed a more easy-to-implement way to get rid of the drawbacks I had indicated.

"This will mean that siege tanks will have difficulty shooting multiple enemies, but will be devestating when they do hit (i.e. best against structures), whereas trikes can easily handle an onslaught of small units, but are also easily outgunned."

IMHO, different rates of fire won't cause this. Even with a machine gun, one wouldn't shoot at many enemies simultaneously. He would rather defeat one target and, then, aim and fire at a next one... So would do a siege tank. But for its power guns it would take 1-2 salvoes (2-4 shots) to defeat a soft target (e.g. infantry squad), while for the guns of a trike that would be about 6-8 salvoes to do the same. So, the time needed to defeat a target depends on the firepower (calculated taking into account the target's resistance to this certain weapon), RoF being just one of its constituents. And if a trike and (then) a siege tank fired at a L.I. squad with the same type of ammo (Highly Explosive for example) then the siege tank would destroy them more rapidly, since it has a higher firepower.

So, what will be the difference between the battle tank and the siege tank in your simplified improvement? The higher maneuverability of the former will not have a significant effect on its fighting efficiency.

"Meanwhile, there will not be too much need for micromanagement (as the 'what side are they facing' element would introduce), and there shouldn't be all that much to code."

This micromanagement would allow for some macro features. For example, a bad prepared attack of siege tanks would be vulnerable to a flange counter-attack, cross-fire (very useful in defense), flanking movement and an attack at the rear of the enemy... This involves many new tactical maneuvers that would be useless otherwise.

"But we've got to remember that some of the more sublte ideas may require quite a lot of work for features that the AI will almost certainly ignore, and will make little difference to the player."

Teach the AI to use them, at least partially. Anyway, the player will be able to use them fully. And I am sure a more detailed simulation of units behavior will make the gameplay more interesting and versatile, the random factor more close to that in reality.

As to coding, my improvement is not really hard to implement, it just will require more time. Stefan may develop this gradually so, at the beginning, it will resemble your improvement and, later, will become more and more detailed, until it resembles mine.

Link to post
Share on other sites

"So, what will be the difference between the battle tank and the siege tank in your simplified improvement?"

Flexibility.

If two units doing on average equal damage per unit time have different RoF and bullet damage, then the unit with the greater RoF will waste less damage on overkill.

e.g.

A does 10 damage every 10 seconds and B does 2 damage every 2 seconds. Each does 1 damage per second on average. C is killed after taking 13 damage. Assuming A and B have just fired, A takes 2 shots (20 seconds), and B takes 7 shots (14 seconds). Hence, B can then deal 6 damage to another target in the time it would have taken A to finish C off.

"As to coding, my improvement is not really hard to implement, it just will require more time"

I don't know quite how the engine works, but I suspect that it will require a *lot* more time - I'm guessing it would require a complete overhaul of how units are placed and drawn. At the moment, movement basically happens on a cell to cell basis. Fancy maneuvers would happen on a sub-cell basis, which could mean anything up to a new engine - and even trying to do it on the current engine would result in high CPU overhead.

What I suggested (including a damage model) is really my estimate (in Stefan's absence) of what the engine can take without starting from scratch a second time.

Link to post
Share on other sites

"I think, realism significally suffers from this"

When discussing realism, remember that Dune itself is a science-fiction setting, and the effects of weapons may be ery different to those of today. Talking modern-day realism, we should have tanks costing vast amounts, battles over before new buildings are built, infantry armed with a variety of weapons, and so on. We have to work on the existing conceits.

Regarding calculation... note that "Assuming A and B have just fired". We need this assumption to calculate statistics in-battle: that is, we must examine the situation just as one enemy is destroyed and the unit moves onto the next one. Granted, A has an advantage right at the beginning of a fight, but that disappears soon as it wastes time.

e.g.

From the start of a fight, C1-C5 are being attacked by A or B.

A will kill C1 at 10s, but will then reload for 10s, shoot at 20s and again at 30s, killing C2. Shooting twice more at 40s and 50s, A kills C3, and destroyes C4 and C5 at 70s and 90s respectively.

B, on the other hand, kills C1 after 12s, reloads then attacks C2, killing it at 26s. At 40s and 54s, it kills C3 and C4, then kills C5 at 68s.

B is therefore progressively more efficient as the number of enemies increases.

In game terms, it's more likely that larger numbers will mean more lightly armed enemies, which means that A would be better at killing the lone approaching devastator, while B would be better suited to dealing with packs of trikes.

As to cells...

I see. I had envisaged Z-like movement of the tanks to evade shells, and so forth.

So what you want first is the relative angle from firer F to target T, θ = arctan( (x(F) - x(T))/(y(F)-y(T)) )

The incoming angle would then be φ = θ - orientation(T)*45

Link to post
Share on other sites

To my point, all these ideas are good for a battle simulator, while I seriously doubt D2TM is going to become one such ???

Why don't you like the C&C "rock-paper-scissors model" (weapon types vs armor types), ant222? IMHO, it is quite adequate to the overall game process. Again, as far as I'm concerned, all the strategy game battle systems adhere to board game battle systems, and those are as simple as possible (while not being primitive), so that the players don't necessarily need a scientific calculator to play.

Anyway, it is Stefan who works on the code, and he's to decide what to implement in the game.

Link to post
Share on other sites

"N is the least common multiple of D1 and D2 then both the units are equallyeffective. But in the case when it is not so the machine gunner is better thanthe tank"

Pretty much, yes. (When N is divisible by D1 but not D2, 1 has a very small advantage, but N is divisible by D2 far more often).

This becomes more important when you have fights with lots of mixed units on both sides and they all need to react to the changes in situation and required damage - high RoF lets you do that efficiently.

"I suggest not more than 2-3 types of weapon for each unit"

Now this is interesting, because DII had both troopers and rocket turrets with alternative weapons. Presumably, the AI would have to calculate the optimum weapon for this each time. The question I have is whether there will then be any tactical difference left between units, since all units are capable at damaging others. The other annoying thing for me is new graphics - basically, DII has 2 basic types of projectiles (each with a couple of sizes), bullets (from Lt Inf to Devastator) and rockets (From Trooper to Missile Launcher), plus the Sonic Tank, which isn't graphically represented per se. For some weapons, like grenades, you need a new set of infantry animations, new projectile logic, and some grenade gfx. Adding rockets to trikes would require some graphical alterations to the trike to give it rocket launchers. Giving Tanks machine guns... I don't even know where I'd begin adding the pixels, and you'd need some distinct bullet gfx as well - not all that easy at small res and high speed.

"I believe that 10-20 shots per second, handled in such a way, won't load the CPUtoo much"

Trig operations and divisions are (as far as I recall) relatively CPU-heavy, and while a programme and a language designed to make good use of the CPU to do this could get it to work fast, I don't know if Allegro is up to it, given that I can quite easily slow D2TM down to under 50FPS as it is with a few clarefully chosen clicks.

(Hm. What I remember from DII is that moving units didn't fire, though that doesn't preclude it being used here. It may require quite different coding, though.)

In summary, they're good ideas, and should be implemented in a game, but I just don't think the scope of D2TM is large enough for them all, partly because it's a small project, partly because it would take quite a bit of work for what is at most the icing on the cake.

Link to post
Share on other sites

But why a real-time strategy battle system of a computer game should be similar to that of a board game (to be also simple)? Why not to make something better, something new, something that is not implemented in other games? We don't need a simple system because the computer can quickly perform complicated calculations instead of a scientific calculator. To the user it will remain simple (in the sence that all inner physics is done by the computer and is hidden from the player).

Naturally the CPU can easily handle some complicated calculations needed to support the battle system, but, as I have understood from your conversation with Nema, adding some of the parts of the new battle system to the code could be problematic. That's the only reason for which I would prefer simple solutions to the comlicated ones. Anyway, as I am not a specialist in the coding field, I must rely on the weighty opinions of others, so if you say its better - then it really is ;)

Link to post
Share on other sites

To Nema Fakei.

On multiple wepons.

In Dune II units with alternative wepons chose the optimal weapon only by means of the firer-target distance. If the distance was higher than a ceartain value they used missiles, otherwise - bullets/shells/projectiles. That was very fast to choose the weapon to shoot.

In my system (or, rather, a draft of a system) that'll a little harder:

1. Check distance and reject weapons which can't fire for the needed distance.

2. Basing on the target's class choose a suitable weapon. Armour piercing projectiles are not effective agains infantry and bullet weapons against armoured targets.

That is the main idea, not very complicated. It can't add a significant load on the CPU.

Link to post
Share on other sites

"1. Check distance and reject weapons which can't fire for the needed distance.

2. Basing on the target's class choose a suitable weapon. Armour piercing projectiles are not effective agains infantry and bullet weapons against armoured targets.

That is the main idea, not very complicated. It can't add a significant load on the CPU."

Probably other way round, else you'll potentially end up using long range useless weapons.

"And what is that "small res" that you mentioned?"

It may be bigger than Dune 2, but DII was very small res.

"Just units should look like if they were shooting: smoke, flashes, explosions at places of hits"

Hah! that's even worse. It's already a real pain putting together 32 infantry frames, let alone firing animations (which have to fit in 16x16 blocks), grenade-throwing, and, well - especially since this will be original art, whereas up till now I've been mostly refining the existing art. Limited smoke is possible, but as to flashes, it really depends what you want. Muzzle flashes are a real pain to place, and, given current limitations, can't be built into unit graphics, plus they'd be more original art. If you want fancy lighting effects, I really have no clue. Explosions are already done, as per DII but bigger, though I might improve them since we now have shadow layers.

"Trig operations" should be "Square roots" - sorry!

And Stefan's in Austria, I think.

Link to post
Share on other sites
  • 2 weeks later...
  • 2 weeks later...

A lot to read, so here a very short reply on the 'relative speed movement' (2nd bug, latest post). I actually wonder how this can be a bug. Every cell is 32x32 pixels. Every unit moves the same amount of pixels up/down. Meaning, moving 1 pixel at a time. A timer holds the 'speed' (which is not cpu related, but using an interupt handler)... so...

Going UP/LEFT is the same speed as going UP only.. wondering, how this can be a bug. The units should get at the same goal at the same time.

A short reply on various weapons/hit damage:

I do intent to have more damage types, ie, infantry having a hard time on several units (tanks, etc). But being very effective against light units (trikes, quads). So there is in some extend some flexibility. The question is how much this should be extended. Even a very wide, superb, flexible, physics engine will eventually have one goal: Distinguish unit types and their use. A unit that has simply more firepower = bad.

Basicly , the game should be as 'simple' as chess ;)

Link to post
Share on other sites
Going UP/LEFT is the same speed as going UP only.. wondering, how this can be a bug. The units should get at the same goal at the same time.

...only if they initially were the same distance away from the goal point.

The speed being the same, the same distance will be passed for the same time. The time needed to pass a distance is directly proportional to the distance. At the picture we have a right isosceles triangle fromed by two siege tanks and their destination point. The left tank needs to move along the triange's leg, and the right - along its hypotenuse. The times needed to pass these distances must be in the ratio of the lengths of the distances:

t1/t2 = l1/l2

Accodring to Pithagoras theorem, (l1/l2) in our case equals 1/sqrt(2). Thus, different distances must require different times to pass at the same speed. In Jagged Allianse a diagonal movement is 1,5 times "longer" (requires 1,5 times more action points) than that along the cells. The reason is simple: 1,5 ~ sqrt(2).

Another example. Circle is a figure containing all points located the same distance (radius) from a given point (center). For a certain amount of time, a unit should be able to get to any point if a circle of a radius equal to the product of the unit's speed by the given time. Currently, in D2TM, this property belongs to a square rather then to a circle.

Of course, in a cell-based game it is impossible to have an ideal circle, but it mustn'be a square nevertheless...

The question is how much this should be extended. Even a very wide, superb, flexible, physics engine will eventually have one goal: Distinguish unit types and their use.

You have forgotten another goal: good looking gameplay. When two tanks are motionless and firing at each other by turn it looks very monotonously and boringly. Here I quote myself:

Link to post
Share on other sites

Chess-ness implies: lack of random factor, predictability - terrible. In order to compensate turn-based-ness reaction fire was invented and widely used, because the developers wanted that their games should resemble what they pretend to - a real battle rather than a chess game...

I don't think Stefan meant to say D2TM will be like chess, rather that it will be simple, like chess.

And I do disagree that chess lacks random factor. As for predictability, every strategy game has and should have a certain degree of predictability.

Finally, chess game also resembles a real battle, although that kind of battle can not be seen nowadays anymore... Maybe in a medieval martial arts club?

Link to post
Share on other sites
I don't think Stefan meant to say D2TM will be like chess, rather that it will be simple, like chess.

Yes, and simplicity has consequences. I named them for chess. For D2TM there will be/are consequences making the gameplay of a comparable (with chess) abstractedness.

And I do disagree that chess lacks random factor. As for predictability, every strategy game has and should have a certain degree of predictability.

Chess lacks random factor: the gameplay is controlled by a number strict rules. Every given action in every given situation always leads to the same result unambiguously defined by the rules - no random factor. As to predictability, I meant: too high, not total. And an RTS should have a lesser predictability.

Finally, chess game also resembles a real battle, although that kind of battle can not be seen nowadays anymore... Maybe in a medieval martial arts club?

Modern chess rather symbolizes a real battle. There is no correspondense between how people fignt in action and how pieces 'eat' enemy pieces.

Link to post
Share on other sites

To abbreviate ant's post, the diagonal of a square is longer than its side, therefore it should take about 1.4 times as long to move diagonally as it does vertically.

I wonder - and I'll try out ASAP - how is it in Dune 2?

Edit: as Battle Isle was mentioned and gives a way to fix this problem, why don't we switch to hexagonal blocks? *gets hit by a brick from Stefan* (just kidding here)

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...