great wargame AI?
Brandon Van Every
better one. There's also a few other things about various wargames that I find
really tiresome, my bitch list is below. Can anyone recommend a wargame that
performs well on many of points (1..5) ? Or, heavens, *all* points? BTW, in
the game I plan to make, the creatures will fight at the tactical scale, i.e.
individual creatures will move around in groups to maul each other.
1) I am sick and tired of wargame designs that have a one-dimensional axis of
victory. If the game, despite all its variety and complexity, has a consistent
monolithic strategy for winning, like "get all the gold" or "train up your guys
the most," it drives me NUTS. In the abstract, such games reduce to
players holding buttons and seeing who can press their own button
fastest/soonest.
2) I am sick and tired of AIs that can't fight. I expect AIs to fight *better*
than most people could, not demonstrably worse. The project I am beginning now
is aimed at rectifying this situation.
3) Micromanagement is CRAP. Real armies do *not* fight by deciding what every
individual soldier will do. The captain, colonel, or general gives *broad*
orders, like "Advance to Schlotzy. Keep to center, do not look left, nor right.
Drive as hard as you possibly can. When you have secured the town, wait for
further instructions." It is assumed that someone else in the chain of command
is worrying about that open left or right flank, or your rear. It is not your
problem. If someone else screws up and doesn't do their job, you're going to
get your ass whipped and that's war.
4) Most wargames reveal way too much information about the enemy's movements,
and indeed even one's own troops! The general back at HQ does *not* know
everything about what's going on. If he wants to know exactly what's going on,
HE DRIVES HIS STAFF CAR UP TO THE FRONT AND LOOKS AT IT. The player's window on
the world of war should be small, and claustrophobic. He must entrust
underlings to execute plans in his absence, because he is *not* an omniscient
god.
5) The individual soldier has a brain, and a sense of self-presevation. He's
not going to stand there letting people shoot him gratuitously! He's always
going to be looking for cover, he's going to fire back at things firing upon
him, and if he gets scared he's going to turn tail and run like hell.
--
Cheers, 3d graphics optimization jock
Brandon Van Every Seattle, WA
Experts eliminate the simpler mistakes in favor of the more
complex ones, thereby achieving a higher degree of stupidity. :-)
Eric Dybsand
news:t76i4.2480$OT5.1...@newsread1.prod.itd.earthlink.net...
> I'm tired of wargames with inferior AI, and to this end, I intend to write
a
> better one.
Excellent! I look forward to playing your game. When might that be?
> There's also a few other things about various wargames that I find
> really tiresome, my bitch list is below. Can anyone recommend a wargame
that
> performs well on many of points (1..5) ? Or, heavens, *all* points? BTW,
in
> the game I plan to make, the creatures will fight at the tactical scale,
i.e.
> individual creatures will move around in groups to maul each other.
I just scanned your bitch list. I think you are refering to what is really
called a RTS or RTT game, and not a wargame. FWIW, and I think
I will get significant agreement from other wargamers, "wargames" are
traditionally turn-based games which feature "operational to tactical"
military operations without resource (other than supply) generation
considerations. Games like Myth, Sid Meier's Gettysburg, Close Combat
are usually considered to be Real-Time Tactical games. Games like Age
of Empires, Dark Reign, Total Annilation are considered to be Real-Time
Strategy games. And games like The Operational Art of War, Steel Panthers,
Panzer/People/Pacific General, The Ardennes Offensive, Combat Mission
and the Talonsoft Battlefront series of games are considered to be
"wargames".
However, I make this distinction only to clarify what most of use call these
types of games, and not to suggest that you can't call your game whatever
you want to call it.
>
> 1) I am sick and tired of wargame designs that have a one-dimensional axis
of
> victory. If the game, despite all its variety and complexity, has a
consistent
> monolithic strategy for winning, like "get all the gold" or "train up your
guys
> the most," it drives me NUTS. In the abstract, such games reduce to
> players holding buttons and seeing who can press their own button
> fastest/soonest.
Again, from a "wargame" point of view, and to directly answer your
explicite question, all of the wargames I mentioned above, require a
strategic thinking process over and above pressing buttons the fastest.
On an RTS or RTT basis however, I agree with you, that the strategies
are shallow in most of these types of games. I think this is partially due
to the "real time" aspect of the game, not giving a (human) player a chance
to actually think through what they want to do in a given move. Another
part I think, is that the game design itself is kept simpler, due to the
fact
that the AI does not have the time to do complex processing on a very
complex problem space.
>
> 2) I am sick and tired of AIs that can't fight. I expect AIs to fight
*better*
> than most people could, not demonstrably worse. The project I am
beginning now
> is aimed at rectifying this situation.
>
Then you shall go down in computer game development history as
the first developer to ever create an AI that is BETTER than an expert
human player at a "wargame" or RTS or RTT (whatever it is that your
game will actually be). If you pull that off, then you will have every
right to crow about it.
Of course, many, many, many other developers have made such a
claim and failed. So, with all due respect, and I wish you all the best,
but I will believe your claim only when you accomplish it.
> 3) Micromanagement is CRAP. Real armies do *not* fight by deciding what
every
> individual soldier will do. The captain, colonel, or general gives
*broad*
> orders, like "Advance to Schlotzy. Keep to center, do not look left, nor
right.
> Drive as hard as you possibly can. When you have secured the town, wait
for
> further instructions." It is assumed that someone else in the chain of
command
> is worrying about that open left or right flank, or your rear. It is not
your
> problem. If someone else screws up and doesn't do their job, you're going
to
> get your ass whipped and that's war.
Micromanagement is a game design issue and not an AI issue. I agree
that any good "wargame" (or RTS or RTT), needs to have as a part of
it, good "unit AI". I think the problem most developers of RTS/RTT
games that display "dumb" unit AI have, is that it is _extremely_ difficult
to design and implement a compact and fast "unit AI" that can deal with
the wide range of situations a given unit must deal with.
We (as computer game AI developers, of which I have been professionally
since 1987) have to face the fact the "unit AI" still resolves down to what
each unit must do, on the very next cycle/move/phase/whatever. That level
of discrete decision-making takes significant cycles (depending on the game
and its depth - ie. the problem space) to accomplish. In "real time" games,
those cycles are not always available, despite the fact that the "problem"
can
actually be solved (given sufficient time).
>
> 4) Most wargames reveal way too much information about the enemy's
movements,
> and indeed even one's own troops! The general back at HQ does *not* know
> everything about what's going on. If he wants to know exactly what's
going on,
> HE DRIVES HIS STAFF CAR UP TO THE FRONT AND LOOKS AT IT. The player's
window on
> the world of war should be small, and claustrophobic. He must entrust
> underlings to execute plans in his absence, because he is *not* an
omniscient
> god.
I agree with this in general, but I must point out that many "wargames" (TAO
and
SP2, Combat Mission and the "General" series) do provide a nice Fog of War
(FOW) feature that limits what the human (ie. the General) can learn about
the
opposition. Most of the RTS/RTT games (which is what I think you are
really
talking about and calling a "wargame") do as you infer, (ie if a unit can
be seen,
its identiy is known, and what its strength is too).
>
> 5) The individual soldier has a brain, and a sense of self-presevation.
He's
> not going to stand there letting people shoot him gratuitously! He's
always
> going to be looking for cover, he's going to fire back at things firing
upon
> him, and if he gets scared he's going to turn tail and run like hell.
>
Back to "unit AI" again. And again, I think this is a design decision and
not
an AI decision. Good "unit AI" can be implemented, but it is up to the game
designer to decide if that is how s/he want his/her game to play.
Obviously,
you probably want your game to have good "unit AI". Great.
Again Brandon, I've read your comments over the years. I would LOVE to
see you _actually_ produce a "wargame" (or a RTS/RTT game if that is
really what you are refering too). I would love to have a chance to play
it.
Also, I think you will learn alot by actually doing it.
Do send me a email when you are ready for beta testing.
Regards,
Eric
----
Eric Dybsand http://pw2.netcom.com/~edybs
Glacier Edge Technology email: ed...@ix.netcom.com
Glendale, Colorado, USA
Brandon Van Every
"Eric Dybsand" <noj...@nospam.com> wrote in message
news:Jk7i4.1405$VO1....@news.uswest.net...
> Brandon Van Every <vane...@3DProgrammer.com> wrote in message
> news:t76i4.2480$OT5.1...@newsread1.prod.itd.earthlink.net...
> > I'm tired of wargames with inferior AI, and to this end, I intend to write
> a
> > better one.
>
> Excellent! I look forward to playing your game. When might that be?
Assuming I start... this weekend... I could make no promises about when I'd
stick it on the net. But it's not going to be a full-blown commercial glitz
title. Sometime this calendar year. It'll be either free (closed source,
sorry) or very cheap, since it won't be full budget and I want people to play
it, to test the theory. I just want to try to get some basic gameplay correct,
because it'll be the 1st time I've ever attempted AI. Owing to my 3D graphics
and particularly my software rasterization background, I feel very confident
about the low-level bit set processing stuff. I can make that go really fast.
Actual "thinking" on the part of the computer, I'm just stepping off a cliff,
we'll see what happens. I'm hoping that by deliberately restricting both
players and AIs to give orders on a higher level, i.e. "send X force to this
region of the board, with the following group cohesion strategy," that the AI
decisions may become doable. After all, this is all anyone ever does in a real
war. The AI does not sit around thinking about whether each individual soldier
can be perfectly brought to bear upon some unfathomably complex objective.
I turned away from AI and wargames awhile ago because I thought it would take me
too long to become an AI expert. So, instead I thought I'd become a triangular
b-spline expert. Aside from taking a long time in and of itself, this has led
me down a garden path of thinking I might need to create a very complicated
modeling/animation package and a very complicated 3d engine before ever writing
a game! Although those investments may indeed be worth making in the long run,
just facing what I don't know about AI can't be any worse in the short run.
> I just scanned your bitch list. I think you are refering to what is really
> called a RTS or RTT game, and not a wargame.
True, it's a RTT. Some people think "wargame" is a generic term, other people
focus it more specifically. For clarity, I'll just call it a RTT.
> Again, from a "wargame" point of view, and to directly answer your
> explicite question, all of the wargames I mentioned above, require a
> strategic thinking process over and above pressing buttons the fastest.
I just got done playing Dungeon Keeper 2. 'Nuff said. :-)
> On an RTS or RTT basis however, I agree with you, that the strategies
> are shallow in most of these types of games. I think this is partially due
> to the "real time" aspect of the game, not giving a (human) player a chance
> to actually think through what they want to do in a given move. Another
> part I think, is that the game design itself is kept simpler, due to the
> fact
> that the AI does not have the time to do complex processing on a very
> complex problem space.
I just read "Panzer Commander: The Memoirs of Colonel Hans Van Luck."
ISBN 0-440-20802-5. His descriptions of his orders were not rocket science.
"Keep contact with the enemy. Maintain radio contact with me at all times,
report all enemy contact. Sweep the flank from here to" whatever that
particular part of North Africa was. Then little peons go out and do it. They
do locally intelligent things, like fight effectively. But there is no amazing
big thinking about how the local fighting takes place. Locally, it's basically
force+skill vs. force+skill. Globally, the generals order around their forces
so that they have decisive advantages locally. Rommel does something like,
assault the Americans because they're the least experienced in Africa, and he
can seize fuel and ammunition by doing so. Montgomery does something like, wait
for a 20 times material advantage before finally assaulting. It's really
amazing those Germans held on for so long, with so little material. Great
tactics, high morale.
So, I'm saying I think many current RTTs are designed wrong. They don't model
war. They assume both that too much information is available (you can see the
whole board + all your troops at once + a lot of the enemy's troops), and that
this information needs to be, or even can be, processed. I'm not sure if any
commercial RTTs have implemented a command/control structure. I've seen a
military research AI sim that did it, studying the emergent behavior of squads
fighting each other. Units basically had offense, defense, and a quality of
linkage to a command/control structure. There was more to it than that, I'm
simplifying, but that was the main idea.
> Then you shall go down in computer game development history as
> the first developer to ever create an AI that is BETTER than an expert
> human player at a "wargame" or RTS or RTT (whatever it is that your
> game will actually be). If you pull that off, then you will have every
> right to crow about it.
I would be satisfied to force a human to play a computer for 2 months solidly
(like, sleep deprivation and so forth) before having any hope of beating the AI.
Whereas currently, most AIs are crushed in mere days after purchasing a product,
because they have big gaping holes in how they plan. There's often no "I" in
the AI, just a hardcoded algorithm that isn't all that effective in the face of
human analysis. I hope that low-level bit crunching of the terrain information,
thinking about regions, and forcing all orders to a higher level of abstraction
will give the AI better tools to reason with.
> Of course, many, many, many other developers have made such a
> claim and failed. So, with all due respect, and I wish you all the best,
> but I will believe your claim only when you accomplish it.
Me too, actually. Like I said, I'm walking off a cliff.
> Micromanagement is a game design issue and not an AI issue.
Well, one way I could answer that is yes, you're absolutely right. And my list
wasn't solely one of AI issues.
Or, I could say I disagree, and that micromanagement overburdens what an AI (and
a human!) have to think about. Your choice, either way. Extrapolate as needed.
> I agree
> that any good "wargame" (or RTS or RTT), needs to have as a part of
> it, good "unit AI". I think the problem most developers of RTS/RTT
> games that display "dumb" unit AI have, is that it is _extremely_ difficult
> to design and implement a compact and fast "unit AI" that can deal with
> the wide range of situations a given unit must deal with.
Sometimes I think we may make something too hard that is really very simple.
Something shoots at you, find cover! Then shoot back. If there's too many of
'em, and you're not scared yet, make an orderly retreat. If you're scared, run
like hell. There are some group tactics to consider here, but really, fighting
is not something you can predict. It's not this clockwork thing. In the
Russian marital art style that I practice, we always do exercises where 3 people
are beating on you. You can't possibly know where 6 pairs of arms are going to
be! You have to avoid, develop sensitivity, and counterattack. No time to
think. Technique is something you learn in order to forget.
> We (as computer game AI developers, of which I have been professionally
> since 1987) have to face the fact the "unit AI" still resolves down to what
> each unit must do, on the very next cycle/move/phase/whatever. That level
> of discrete decision-making takes significant cycles (depending on the game
> and its depth - ie. the problem space) to accomplish. In "real time" games,
> those cycles are not always available, despite the fact that the "problem"
> can actually be solved (given sufficient time).
The 3D graphics guy in me says we have enough computing power now to solve local
problems like line of sight, how many people are shooting at me, where's the
cover, etc. But it's still going to be a rough ride. Part of the way I'm going
to get away with this, is a lot of the creatures are going to be downright
stupid. You're being assulted by 10,000 ANTS. Ants don't think, they swarm.
Or, you're being assaulted by 1 HUGE juggernaut. It doesn't think about pain,
it just concentrates on crushing people in its path. There will be ghosts that
go through walls but only move in straight lines, beause that's how some Chinese
think ghosts move. That's not all there's going to be in this dungeon sim,
there will be orcs that fight rather similarly (I hope) to Russians. :-) And
some kind of Wing Chun guys too, and archers shooting through arrow slits, and
whatnot. But the game isn't really going to be about highly refined squad
tactics, because not all the combatants are going to be highly refined fighters.
The game is going to be more about "send this combo of creatures to this region
of the board, wipe out everything in your way." And it's going to be about how
well you handle your command/control structure, what your supply lines are like,
your "big picture" orders, that are going to determine whether it works or not.
> Also, I think you will learn alot by actually doing it.
Yep!
> Do send me a email when you are ready for beta testing.
Shall do.
Eric Dybsand
Brandon Van Every <vane...@3DProgrammer.com> wrote in message
>
> "Eric Dybsand" <noj...@nospam.com> wrote in message
> news:Jk7i4.1405$VO1....@news.uswest.net...
> > Brandon Van Every <vane...@3DProgrammer.com> wrote in message
> > news:t76i4.2480$OT5.1...@newsread1.prod.itd.earthlink.net...
>
cliff,
> we'll see what happens. I'm hoping that by deliberately restricting both
> players and AIs to give orders on a higher level, i.e. "send X force to
this
> region of the board, with the following group cohesion strategy," that the
AI
> decisions may become doable. After all, this is all anyone ever does in a
real
> war. The AI does not sit around thinking about whether each individual
soldier
> can be perfectly brought to bear upon some unfathomably complex objective.
>
Actually, this depends on the Level of Detail Operation that your
game is simulating. Above, you suggest a high level of operational
control with "send X force to this ...." which is similar to a general
commanding divisions (or at least brigades). If the LoDO takes
place at levels below that which was commanded, then the AI will
have to make some "interpretation" of the orders and decide what
control to apply to the lower ordered sub-unit of the main unit that
was commanded. In other words, if a player gives a command to
"X force to to to X,Y" and X force is actually represented by units
A,B,C then the AI must figure out how A and B and C will carry
out their part of the command given to their parent unit.
So the point is, depending on the LoDO of the game, and the
interface level (where the player issues her commands), then
the AI may have to think about each individual unit and how
that unit reachs a complex objective.
>
> True, it's a RTT. Some people think "wargame" is a generic term, other
people
> focus it more specifically. For clarity, I'll just call it a RTT.
>
> > Again, from a "wargame" point of view, and to directly answer your
> > explicite question, all of the wargames I mentioned above, require a
> > strategic thinking process over and above pressing buttons the fastest.
>
> I just got done playing Dungeon Keeper 2. 'Nuff said. :-)
>
For clarity, DK2 is a RTS not a RTT. And yes, success at
it involves button pressing and clicking. SSG's The Ardennes
Offensive or Norm Kroger's The Operation Art of War, both
require button pressing and clicking to issue orders, but being
turn-based, the thinking that is behind the button-pressing (and
not the speed of pressing) is the key to success.
> > On an RTS or RTT basis however, I agree with you, that the strategies
> > are shallow in most of these types of games. I think this is partially
due
> > to the "real time" aspect of the game, not giving a (human) player a
chance
> > to actually think through what they want to do in a given move. Another
> > part I think, is that the game design itself is kept simpler, due to the
> > fact
> > that the AI does not have the time to do complex processing on a very
> > complex problem space.
>
> I just read "Panzer Commander: The Memoirs of Colonel Hans Van Luck."
> ISBN 0-440-20802-5. His descriptions of his orders were not rocket
science.
> "Keep contact with the enemy. Maintain radio contact with me at all
times,
> report all enemy contact. Sweep the flank from here to" whatever that
> particular part of North Africa was.
This is issuing commands at an operational level that is above the LoDO
that is carried out by the units.
> Then little peons go out and do it. They
> do locally intelligent things, like fight effectively. But there is no
amazing
> big thinking about how the local fighting takes place.
I disagree. I think that for units to fight locally successfully, unless
you
plan to abstract fighting to die roll equivilents, takes a considerable
tactical AI effort. I think as you implement your ideas and your game
becomes playable, this will become more obvious to you.
> Locally, it's basically
> force+skill vs. force+skill. Globally, the generals order around their
forces
> so that they have decisive advantages locally. Rommel does something
like,
> assault the Americans because they're the least experienced in Africa, and
he
> can seize fuel and ammunition by doing so. Montgomery does something
like, wait
> for a 20 times material advantage before finally assaulting.
Right. Still these are examples of operation level command. Not the level
of command one see's in a RTT game.
>
> So, I'm saying I think many current RTTs are designed wrong. They don't
model
> war. They assume both that too much information is available (you can see
the
> whole board + all your troops at once + a lot of the enemy's troops), and
that
> this information needs to be, or even can be, processed. I'm not sure if
any
> commercial RTTs have implemented a command/control structure. I've seen a
> military research AI sim that did it, studying the emergent behavior of
squads
> fighting each other. Units basically had offense, defense, and a quality
of
> linkage to a command/control structure. There was more to it than that,
I'm
> simplifying, but that was the main idea.
Have you played any of Close Combat series, or Sid Meiers Gettysburg or
Antitem or Myth? All of those RTTs demostrate a command/control structure.
Also, at the tactical level, I think it is hard to make a game fun to play,
unless
the designer allows the player to control the entire force. Think of what
an
actual platoon leader does in a combat situation. He issues orders to
squads
or squad leaders at the beginning of the operation, and then views the op
from
his limited POV. Events that occur outside his POV are reported to him by
radio or messenger/runner (how much fun is that in a computer game?). And
the squad leaders end up implementing (read making decisions) his original
orders as they see fit (again, for a computer game, how fun is this?).
Another couple of games you may want to look at is TacOps and Brigade
Combat Team. Both games offer modern tactical combat from the level
of the "Team" commander (basically a reinforced company) and both are
available in demo form which should let you get a feel for them with only
the cost to you of your time and a download.
>
> > Then you shall go down in computer game development history as
> > the first developer to ever create an AI that is BETTER than an expert
> > human player at a "wargame" or RTS or RTT (whatever it is that your
> > game will actually be). If you pull that off, then you will have every
> > right to crow about it.
>
> I would be satisfied to force a human to play a computer for 2 months
solidly
> (like, sleep deprivation and so forth) before having any hope of beating
the AI.
> Whereas currently, most AIs are crushed in mere days after purchasing a
product,
> because they have big gaping holes in how they plan. There's often no "I"
in
> the AI, just a hardcoded algorithm that isn't all that effective in the
face of
> human analysis. I hope that low-level bit crunching of the terrain
information,
> thinking about regions, and forcing all orders to a higher level of
abstraction
> will give the AI better tools to reason with.
I see that you are wisely toning down your claim to make the AI
better than a human. Making an AI that is tough to figure out is
one thing, but since most expert human players will figure out how
to beat any wargame/RTT AI in less than 2 months of continous
play, then that means the AI was not able to overcome the human's
adapability (which is the key strength humans have over AIs).
If you have not yet done so, I think you might want to play
SSGs The Ardennes Offensive or Kroger's The Operational
Art of War, if you want to see more of an AI challenge.
> Sometimes I think we may make something too hard that is really very
simple.
> Something shoots at you, find cover! Then shoot back. If there's too
many of
> 'em, and you're not scared yet, make an orderly retreat. If you're
scared, run
> like hell. There are some group tactics to consider here, but really,
fighting
> is not something you can predict. It's not this clockwork thing. In the
> Russian marital art style that I practice, we always do exercises where 3
people
> are beating on you. You can't possibly know where 6 pairs of arms are
going to
> be! You have to avoid, develop sensitivity, and counterattack. No time
to
> think. Technique is something you learn in order to forget.
You are mainly describing reactive behavior, which I agree is not
difficult to encode. I did so in Enemy Nations and Revolution and
all of my turn-based wargames.
Unfortunately, good tactics (and thus good tactical AI) is far more
than just reactive behavior. For example, and using your martial arts
exercise as an example, just add "protecting a person while defending
yourself" to the exercise, and the tactical problem escalates in complexity.
It is certainly still solvable, but at the cost of much more thinking.
> You're being assulted by 10,000 ANTS. Ants don't think, they swarm.
> Or, you're being assaulted by 1 HUGE juggernaut. It doesn't think about
pain,
> it just concentrates on crushing people in its path. There will be ghosts
that
> go through walls but only move in straight lines, beause that's how some
Chinese
> think ghosts move. That's not all there's going to be in this dungeon
sim,
> there will be orcs that fight rather similarly (I hope) to Russians. :-)
And
> some kind of Wing Chun guys too, and archers shooting through arrow slits,
and
> whatnot. But the game isn't really going to be about highly refined squad
> tactics, because not all the combatants are going to be highly refined
fighters.
> The game is going to be more about "send this combo of creatures to this
region
> of the board, wipe out everything in your way." And it's going to be
about how
> well you handle your command/control structure, what your supply lines are
like,
> your "big picture" orders, that are going to determine whether it works or
not.
>
There has been a lot of AI research done in "flocking" and group behavior
(like ants) that may be of interest to you. I've used emergent behavior
techniques similar to how flocking is done, and achieved some pretty cool
squad-level behavior with the grunts in the squad. It will be interesting
to
see what you think of these techniques, after you have your game running.
Eric
Gerry Quinn
>is not something you can predict. It's not this clockwork thing. In the
>Russian marital art style that I practice, we always do exercises where 3
^^^^^^^^^^^^^^^^
> people
>are beating on you. You can't possibly know where 6 pairs of arms are going to
>be! You have to avoid, develop sensitivity, and counterattack. No time to
>think. Technique is something you learn in order to forget.
>
I guess they have to fill those long Siberian nights somehow...
- Gerry Quinn
R Lorber
objectives then decide which units it should send based on what leaves it
with the resources to achieve the next objective.
"Eric Dybsand" <noj...@nospam.com> wrote in message
news:Jk7i4.1405$VO1....@news.uswest.net...
Brandon Van Every
"Eric Dybsand" <noj...@nospam.com> wrote in message news:o0ji4.288
>
> For clarity, DK2 is a RTS not a RTT.
I'm curious: how do you justify that statement? The absence of "T?" :-)
Scale-wise, it's little individual creatures fighting each other. It certainly
isn't operational or strategic scale. Do you draw a boundary where tactical
games cannot include production?
> > I just read "Panzer Commander: The Memoirs of Colonel Hans Van Luck."
> > ISBN 0-440-20802-5. His descriptions of his orders were not rocket
> science.
> > "Keep contact with the enemy. Maintain radio contact with me at all
> times,
> > report all enemy contact. Sweep the flank from here to" whatever that
> > particular part of North Africa was.
>
> This is issuing commands at an operational level that is above the LoDO
> that is carried out by the units.
Yep. That's the idea of what I want to do: the player issues operational
commands only. Then he sits back and watches the tactics. The way the player
controls tactics, is by sending force mixes of creatures to certain regions,
that happen to have particular kinds of tactics. For instance, a pile of ants
fights differently than a squad of orcs. Indeed, they have fundamentally
different reactions to terrain.
> I disagree. I think that for units to fight locally successfully, unless
> you
> plan to abstract fighting to die roll equivilents, takes a considerable
> tactical AI effort. I think as you implement your ideas and your game
> becomes playable, this will become more obvious to you.
I do not yet feel intimidated by the need to hide, ambush, seek cover, find
bottlenecks to defend, run when terrified, etc. on an individual basis. These
are just LOS problems. Group tactics will be more dicey.However, recall that
not all monsters are even going to be capable of complex group tactics. Ants
swarm. Ghosts are fundamentally antisocial. Juggernauts simply move forwards
and crush.
> Right. Still these are examples of operation level command. Not the level
> of command one see's in a RTT game.
Ok, we'll call it RTO on top of a RTT sim. No die roll abstractions.
> Have you played any of Close Combat series,
I did play a demo of one of them. I got bogged down in the tactical
micromanagement, but I should probably look at the game again.
> or Sid Meiers Gettysburg or Antitem
Tried Gettysburg demo, seemed like a historically accurate game, but I
personally wasn't very excited by it, so I stopped. It seemed pretty involved
so I didn't want to put the time into it. I think I need at least WW I to turn
me on. :-)
> or Myth?
Tried it. Didn't like the grouping dynamics at all. I have a friend of mine
who complains vehemently about problems with grouping dynamics. Like, you put
the guys in formation, then as they march they spread out and lose their
formation, defeating the point of marching in formation in the first place! Or
so his complaint goes. He's also not keen on dwarves that hurl molotov
cocktails at their own guys.
> Also, at the tactical level, I think it is hard to make a game fun to play,
> unless
> the designer allows the player to control the entire force. Think of what
> an
> actual platoon leader does in a combat situation. He issues orders to
> squads
> or squad leaders at the beginning of the operation, and then views the op
> from
> his limited POV. Events that occur outside his POV are reported to him by
> radio or messenger/runner (how much fun is that in a computer game?). And
> the squad leaders end up implementing (read making decisions) his original
> orders as they see fit (again, for a computer game, how fun is this?).
Well, one answer is I guess there isn't enough sneaking around. Part of what I
have in mind is digging sneaky tunnels under people's dungeons and castles, and
building secret doors into/out of things, so that you can get right under
people's noses before you assault them. Also, there is quite possibly going to
be a political axis to what I have in mind. You don't start the game with a
force, you have to recruit a bunch of denizens in a dungeon who may have
absolutely no warlike intents whatsoever. So, instead of 2 operational commands
slugging it out, you have something more like the Balkans where you really don't
know who the enemy is. That increases tension. Finally, it's going to be a
builder game. You have something to do other than micromanage tactics. You can
micromanage your wall constructions instead. :-)
Another possible answer: true RTT should perhaps be implemented Quake style,
with only 1 squad, and you're always just the commander.
> Another couple of games you may want to look at is TacOps and Brigade
> Combat Team. Both games offer modern tactical combat from the level
> of the "Team" commander (basically a reinforced company) and both are
> available in demo form which should let you get a feel for them with only
> the cost to you of your time and a download.
Heh, exactly.
> > I would be satisfied to force a human to play a computer for 2 months
> solidly
> > (like, sleep deprivation and so forth) before having any hope of beating
> the AI.
> > Whereas currently, most AIs are crushed in mere days after purchasing a
> product,
> > because they have big gaping holes in how they plan.
>
> I see that you are wisely toning down your claim to make the AI
> better than a human.
Ok, let me check what I claimed. I said "I am sick and tired of AIs that can't
fight. I expect AIs to fight *better* than most people could, not demonstrably
worse."
I never said "better than any human." Indeed, in martial arts there's always
someone better than you. But I am tired of AIs that fight like white belts in a
fast food karate chain. It should take a helluva lot of experience with a game
to beat the AI in that game. The AI should have a tremendous advantage of
initial experience, summarily tossing the white belt player across the room.
When I wrote my intent, I didn't have a quantitative specific for how I would
measure it. I certainly didn't dream that it would be what you suggested, that
the AI would fight better than an expert human. I would expect, however, that
the AI would put up a stiff fight against an expert human, that the expert human
would have to work hard for his victory. Still, as you said there's probably
going to be a time bound on how long that's doable. So, I give you "2 months of
sleep deprivation" as the timebound. That's the goal that you can point fingers
at me later and say "See! See!" if you're so inclined. :-)
> Making an AI that is tough to figure out is
> one thing, but since most expert human players will figure out how
> to beat any wargame/RTT AI in less than 2 months of continous
> play, then that means the AI was not able to overcome the human's
> adapability (which is the key strength humans have over AIs).
Jeez, I guess you're used to caviar AIs! DK2 AI I beat immediately, with very
few mishaps. People's General took longer but still probably only 1 week to
figure out the consistency of its fighting. You show me a game that you think
will take a seasoned wargamer 2 months of sleep deprivation to start being able
to beat it, and I'll go take a look at it.
> If you have not yet done so, I think you might want to play
> SSGs The Ardennes Offensive or Kroger's The Operational
> Art of War, if you want to see more of an AI challenge.
How do they rate on the criteria above? BTW, giving the computer a 3:1 force
advantage, whether historically accurate or not, does *not* count in my book as
a tough AI. Also, beating the terrain scenario is not the same thing as beating
the AI.
> You are mainly describing reactive behavior, which I agree is not
> difficult to encode. I did so in Enemy Nations and Revolution and
> all of my turn-based wargames.
>
> Unfortunately, good tactics (and thus good tactical AI) is far more
> than just reactive behavior. For example, and using your martial arts
> exercise as an example, just add "protecting a person while defending
> yourself" to the exercise, and the tactical problem escalates in complexity.
> It is certainly still solvable, but at the cost of much more thinking.
Um, actually it doesn't get too much worse than 3 guys attacking you. It's not
a Bruce Lee movie, they're not taking turns! There's no time to think in a real
fight, under that kind of pressure. You learn technique for covering the
problem, then you forget the technique. More importantly you learn mindset, not
to have your mind cramped on any one thing. At any rate, you don't have the
option to train some new technique for 1000 more hours when you are being
engaged by the enemy! You're going to do what you're trained to do, until your
morale breaks... then you're going to self-preserve on instinct. Orcs are not
required to be infinitely flexible fighters, or spontaneous kung fu masters,
learning new things the very moment they fight. They are required to have some
kind of training for how they believe is a good way to fight. They apply it,
and in the wrong circumstance they may very well be toasted by it.
Put another way, cool tactics is something you think about *before* the fight
happens, when you have some time to think. A clever ambush pattern, a defense
through bottlenecks and fields of fire, a group small arms fire pattern against
an incoming jet, etc. Once the fight gets going, all hell breaks loose. The
bodyguard doesn't solve the problem of protecting the client by doing a lot of
neat gonzo stuff. He solves it by covering the client's body and being willing
to take a bullet. And, by having a lot of bodyguards. They train a particular
drill for a particular circumstance.
> There has been a lot of AI research done in "flocking" and group behavior
> (like ants) that may be of interest to you. I've used emergent behavior
> techniques similar to how flocking is done, and achieved some pretty cool
> squad-level behavior with the grunts in the squad. It will be interesting
> to
> see what you think of these techniques, after you have your game running.
Any downloadable simulations you can recommend? I looked at
http://www.cna.org/isaac/ about a year ago, think I'll look at it again.
Eric Dybsand
Brandon Van Every <vane...@3DProgrammer.com> wrote in message
>
> "Eric Dybsand" <noj...@nospam.com> wrote in message news:o0ji4.288
> >
> > For clarity, DK2 is a RTS not a RTT.
>
> I'm curious: how do you justify that statement? The absence of "T?" :-)
> Scale-wise, it's little individual creatures fighting each other. It
certainly
> isn't operational or strategic scale. Do you draw a boundary where
tactical
> games cannot include production?
>
Yes exactly. As soon as a "real-time tactical" game includes production,
I think it moves over to the "real-time strategy" game side. The reason,
is that the resource gathering and unit production aspects require a more
strategic level of planning (albeit in some RTS games, this planning is
certainly
not very much) that does not exist in a purely tactical game.
In others words, "take that bridge" is tactical, but "raise an army to take
that bridge" is strategic.
"Scale" really is not involved in the RTS vs RTT debat, IMHO, because
RTS and RTT are _not_ wargames. "Scale" is useful in defining wargames
such as High Command (strategic) or Third Reich (strategic) or TOAW
(operational) or TAO (operational) or Steel Panthers (tactical).
> > Right. Still these are examples of operation level command. Not the
level
> > of command one see's in a RTT game.
>
> Ok, we'll call it RTO on top of a RTT sim. No die roll abstractions.
>
You can call it whatever you want, as you are the game designer <grin>.
I raised the issue only because alot of other game designers look at
RTT and RTS and wargames as being different.
> > Have you played any of Close Combat series,
>
> I did play a demo of one of them. I got bogged down in the tactical
> micromanagement, but I should probably look at the game again.
>
> > or Sid Meiers Gettysburg or Antitem
>
> Tried Gettysburg demo, seemed like a historically accurate game, but I
> personally wasn't very excited by it, so I stopped. It seemed pretty
involved
> so I didn't want to put the time into it. I think I need at least WW I to
turn
> me on. :-)
>
> > or Myth?
>
> Tried it. Didn't like the grouping dynamics at all. I have a friend of
mine
> who complains vehemently about problems with grouping dynamics. Like, you
put
> the guys in formation, then as they march they spread out and lose their
> formation, defeating the point of marching in formation in the first
place! Or
> so his complaint goes. He's also not keen on dwarves that hurl molotov
> cocktails at their own guys.
>
All three of these games, have their faults, however they are IMO, the
better examples of RTT games.
> Well, one answer is I guess there isn't enough sneaking around. Part of
what I
> have in mind is digging sneaky tunnels under people's dungeons and
castles, and
> building secret doors into/out of things, so that you can get right under
> people's noses before you assault them. Also, there is quite possibly
going to
> be a political axis to what I have in mind. You don't start the game with
a
> force, you have to recruit a bunch of denizens in a dungeon who may have
> absolutely no warlike intents whatsoever. So, instead of 2 operational
commands
> slugging it out, you have something more like the Balkans where you really
don't
> know who the enemy is. That increases tension. Finally, it's going to be
a
> builder game. You have something to do other than micromanage tactics.
You can
> micromanage your wall constructions instead. :-)
>
> Another possible answer: true RTT should perhaps be implemented Quake
style,
> with only 1 squad, and you're always just the commander.
>
Again, I'm not trying to tell you want genre you must refer to your
game as, only what comes to mind as you describe it. Now, with
the "its going to a builder game" comment you just made, it sounds
like you are adding some production (which then infers resource
gathering of some kind) and thus, I think it moves the game closer
to the RTS side of the genre.
I don't think a wargame has been made yet, that will really challenge
the determined expert human player. That's the point I was making.
I still think that it is beyond our current technology to accomplish.
>
> > If you have not yet done so, I think you might want to play
> > SSGs The Ardennes Offensive or Kroger's The Operational
> > Art of War, if you want to see more of an AI challenge.
>
> How do they rate on the criteria above? BTW, giving the computer a 3:1
force
> advantage, whether historically accurate or not, does *not* count in my
book as
> a tough AI. Also, beating the terrain scenario is not the same thing as
beating
> the AI.
I'm not sure what you mean by "terrain scenario" but both TAO and
TOAW can offer a significant challenge to some expert wargame
players, without cheating. Even though, neither game has an AI that
I would call *better* than most expert players.
But you are talking about how a *human* does these things. You will
not be having a *human* do these things within your game. You will
need to have an AI that can do these things, and AIs do things differently
than *humans* do. My point was and still is, adding one more objective
(ie. protecting a person) to your exercise example changes what you
would have to do as a *human*, to the point that simple instinct (what
you have been describing) based on experience may have to change.
The same issue applies for an AI that has to demonstrate "good tactics"
and not just good "instinctive" or "reactive" behavior. It changes what
must be considered to do. Since an AI is not able to adapt as well as
you (a trained and experienced martial artist) could then the problem
becomes harder to solve. Thats the only point I was making.
>
> > There has been a lot of AI research done in "flocking" and group
behavior
> > (like ants) that may be of interest to you. I've used emergent behavior
> > techniques similar to how flocking is done, and achieved some pretty
cool
> > squad-level behavior with the grunts in the squad. It will be
interesting
> > to
> > see what you think of these techniques, after you have your game
running.
>
> Any downloadable simulations you can recommend? I looked at
> http://www.cna.org/isaac/ about a year ago, think I'll look at it again.
>
I have no collection of URLs to offer you. Flocking can be found at
Craig Reynold's web pages which should show up on any search engine.
Ant Behavior is also published in a number of papers and would be
easy to find in a search.
Eric
Isaac Kuo
Brandon Van Every <vane...@3DProgrammer.com> wrote:
>I'm tired of wargames with inferior AI,
Play a good chess game, then...
>and to this end, I intend to write a
>better one. There's also a few other things about various wargames that I find
>really tiresome, my bitch list is below. Can anyone recommend a wargame that
>performs well on many of points (1..5) ? Or, heavens, *all* points? BTW, in
>the game I plan to make, the creatures will fight at the tactical scale, i.e.
>individual creatures will move around in groups to maul each other.
A half-decent Chess game satisfies points 1, 2, and 5. Arguably,
it satisfies point 3, since the level of abstraction from small
details is high.
>1) I am sick and tired of wargame designs that have a one-dimensional axis of
>victory.
Agreed, this makes for a boring game, at least to me.
>2) I am sick and tired of AIs that can't fight. I expect AIs to fight *better*
>than most people could, not demonstrably worse.
Then make your game relatively Chess-like. The best AI technique out
there is still, unfortunately, brute force Alpha-Beta searching.
For most traditional board wargames, this is just plain impractical
due to the sheer number of possible outcomes.
However, if you restrict the number of possible moves and outcomes
like in Chess, you can use brute force to do well.
>3) Micromanagement is CRAP. Real armies do *not* fight by deciding what every
>individual soldier will do. The captain, colonel, or general gives *broad*
>orders, like "Advance to Schlotzy. ...
Is this a game or a simulation? Just because something's not realistic
doesn't mean it's not good for gameplay. Having unrealistically
precise control over one's own forces is traditionally popular in
wargames.
Having too much micromanagement to do can be a gameplay problem,
too, but this generally isn't a problem in a turn based game.
>4) Most wargames reveal way too much information about the enemy's movements,
>and indeed even one's own troops! The general back at HQ does *not* know
>everything about what's going on. If he wants to know exactly what's going on,
>HE DRIVES HIS STAFF CAR UP TO THE FRONT AND LOOKS AT IT.
Is this a wargame or an RPG? If it's an RPG, who are you
supposed to be? The General back at HQ? Then you're not the one
in charge of production either, and you've got to take orders from
the President/Czar/Dictator/whatever.
>The player's window on the world of war should be small, and
>claustrophobic.
Why? That doesn't sound like fun--and IMO the primary objective
of a game should be that it's fun.
>5) The individual soldier has a brain, and a sense of
>self-presevation. He's not going to stand there...
This is something which ASL makes an honest attempt at taking into
account. Indeed, combat in ASL is won more by breaking enemy squads
than just plain killing them.
Anyway, many of the above issues can be tackled by carefully picking
the premise of the game. For instance, look at Syndicate. The God's
eye perspective perfectly matched the premise of your observational
perspective from a satellite. The micromanagement and dumb units
were explained by them being drugged up and being directly controlled
by you.
Another premise that would work well would be Aliens. The commander
of a platoon inside the APC has a direct feed from each soldier, so
it's realistic to have near-perfect knowledge of the locations and
views from each soldier. In this case, though, the soldier's aren't
drugged up dumb slaves, so they could act more independently.
--
_____ Isaac Kuo k...@bit.csc.lsu.edu http://www.csc.lsu.edu/~kuo
__|_)o(_|__ ICQ 29055726
/___________\
\=\)-----(/=/ "Why does Mini-Bigglesworth not have fur?"
Rick Craik
Brandon Van Every wrote in message ...[snip]
Hi;
I hope you don't mind my two cents. I like the way this thread
is developing, so far.
First off, I just wanted to add this comment:
Some games get tiresome micromanaging tactical battles.
But once I am aware of the tactics, and if the game allows me to
build and equip the squad, then I can turn on the auto features.
A well built team is great to watch in action. I first learned
this technique in Master's of Magic.
For example, don't give weapons of mass destruction to a team of
grunts, because they could blow themselves up. Or spellcasters
learn only selective spells, so that auto-casting defensive,
and then offensive spells is most effective with your support group.
Secondly ...
Brandon, can we influence your functional specs? Or more to the point,
could Eric lay out some minimum functionality requirements with regard
to unit AI? I too would like to see a simple demo of some basic
functionality. I was becoming dismayed when reading your some of your
additional game concepts (being influenced by your most recently played
game? :). For a functional demo, I wouldn't care if it was fun.
Perhaps I could start Eric off with some quick off the top of my head
basic unit AI terms for functionality.
ENVIRONMENT:
3D or 2D and point of view?
TERRAIN:
Open or Indoors?
Height? Depressions, level, or high ground.
Obstacles and LOS.
UNITS:
Swarming: Small: Ants
Non Swarming: Big: Juggernauts
Some Swarming: Medium: Orcs
...?
DEFINTIONS:
Small:
Medium:
Big:
Swarming:
...?
DEFINTIONS OF OPERATIONAL COMMANDS:
Attack
Maintain contact
Flank
Hold ground
Ambush
Search and destroy
...?
UNIT BEHAVIOURS:
Take cover
run away
retreat
berserker
high morale
...?
UNIT COMBAT CAPABILTIES:
Ranged and melee attacks.
Walking, running, flying, swimming ...
Area affect attacks.
Sight, Sound, Smell telltales.
...?
I am sure that there are others out here willing to join in and help on both
sides. I don't see this as an open source project, but maybe as an open
minimum specification with Eric's experienced judgement as a guide. And I
sure as heck don't want to take the fun out it. So continue on ...
Tanks for your time
Rick
Brandon Van Every
"Rick Craik" <NOSPAM...@ntl.sympatico.ca> wrote in message news:zGri4.24
>
> Secondly ...
> Brandon, can we influence your functional specs? Or more to the point,
> could Eric lay out some minimum functionality requirements with regard
> to unit AI? I too would like to see a simple demo of some basic
> functionality. I was becoming dismayed when reading your some of your
> additional game concepts (being influenced by your most recently played
> game? :). For a functional demo, I wouldn't care if it was fun.
We can try, so long as it proves productive and not a drain of time. Here goes:
> ENVIRONMENT:
> 3D or 2D and point of view?
2D overhead on a 256x256 grid. Think I may pick "diagonals are not adjacent" as
the basic movement. Don't think I'll waste computational resources on scaling
the diagonals, as it only results in more complicated computations for similar
topological results.
> TERRAIN:
> Open or Indoors?
A dungeon, which will be mostly claustrophobic, but may have some open areas in
it. There will be walls and secret passages.
> Height? Depressions, level, or high ground.
Haven't decided if I'll include height. I consider it a game design decision as
opposed to a functional necessity. Rather than implement generalized height,
maybe there are game design features that will accomplish whatever height was
intended to accomplish. Then again, maybe I really need to dig tunnels
underneath things.
> Obstacles and LOS.
Hiding around corners will be critical. So will camouflage. Haven't decided if
in-grid-square obstacles are really needed. There will be arrow slits.
> UNITS:
> Swarming: Small: Ants
> Non Swarming: Big: Juggernauts
Yep.
> Some Swarming: Medium: Orcs
Orcs are not going to swarm. Orcs are going to melee and will probably be the
most effective, "slipperiest" fighters in the game. Their movement will be very
circular and irregular. I also need some kind of different troops like a Roman
legion, that marches around in formation. Also need some kind of thief/assassin
operators, that are specialized in clandestine stabbing of people in the back.
I'm thinking that these 3 playing types are going to end up being the meat and
potatoes of combat. Don't know if the regular formation guys will really prove
all that useful in cramped dungeon corridors. Maybe I'll forget about the
strict Roman-style formations, and just have guys that attack very directly in
wedges instead of circling like the Orcs do.
> DEFINTIONS OF OPERATIONAL COMMANDS:
> Attack
> Maintain contact
> Flank
> Hold ground
> Ambush
> Search and destroy
> ...?
Retreat.
Stall.
Harass.
Create staggered defense of depth X to some front.
Conceal.
Snipe.
Skulk / infiltrate.
Observe.
Build walls (unit specific)
Dig tunnels (unit specific)
> UNIT BEHAVIOURS:
> Take cover
> run away
> retreat
> berserker
> high morale
> ...?
Attack conservatively
Attack aggressively
Shadow / trail
I'm getting tired, someone else think...
> UNIT COMBAT CAPABILTIES:
> Ranged and melee attacks.
> Walking, running, flying, swimming ...
Doubt I'll allow flying. Sorta defeats the purpose of castle walls.
There will, however, be ghosts that can pass through walls. They will probably
have "Chinese ghost" movement rules, which is to say, they can't move at right
angles! Or some other such bizzare superstitious rationale for how they move.
Thing I don't understand is if the Chinese ghosts can't move at right angles,
why don't they just pass through walls? I have a friend of mine looking up some
info about that, she kinda wants to know what they're really supposed to be able
to do. Also, the creation of ghosts will probably require some particular kind
of death, and the ghost will probably be bound within a certain area of the
death. Generally, ghosts died in some heinous, unspeakable way, like a wrongful
murder. Not just blood on the battlefield.
Mold growing. In contiguous, adjacent chunks.
> Area affect attacks.
> Sight, Sound, Smell telltales.
> ...?
>
>
> I am sure that there are others out here willing to join in and help on both
> sides. I don't see this as an open source project, but maybe as an open
> minimum specification with Eric's experienced judgement as a guide.
Eh, well, let me make it clear: it's my project, not some group thing. But I'm
happy for any suggestions that might make for a more interesting game. Past a
certain point I'm going to have to focus on the tangibles one at a time, rather
than the entire wish list. But one of the fundamental principles, is every new
unit type should fight very, very differently from other unit types. Whether as
a matter of basic tactics, or fundamental nature of movement (flocking swarms
vs. single thieves sneaking, for instance). I really hate units that are just
statistically better or statistically worse than some other unit. Doesn't
contribute to having different ways to win the game, it just makes "force" the
measure of whether or not you'll win.
Brandon Van Every
"Isaac Kuo" <k...@oldbit.csc.lsu.edu> wrote in message
>
> >3) Micromanagement is CRAP. Real armies do *not* fight by deciding what
every
> >individual soldier will do. The captain, colonel, or general gives *broad*
> >orders, like "Advance to Schlotzy. ...
>
> Is this a game or a simulation? Just because something's not realistic
> doesn't mean it's not good for gameplay. Having unrealistically
> precise control over one's own forces is traditionally popular in
> wargames.
As far as I'm concerned, micromanagement is crap. This particular game designer
hath spoken. :-) I don't like it in computer games, it wastes too much of my
time. I don't like it in hex counter games, it takes *forever* to move the damn
things around. I don't care if hundreds of generations of wargamers or strategy
gamers have grown up doing it that way, and love it that way. They are all a
bunch of friggin' accountants, to me it is boring.
I believe in delegation, not micromanagement.
> Why? That doesn't sound like fun--and IMO the primary objective
> of a game should be that it's fun.
"Fun" is something totally in your prejudiced imagination, until you've actually
played a game.
> >5) The individual soldier has a brain, and a sense of
> >self-presevation. He's not going to stand there...
>
> This is something which ASL makes an honest attempt at taking into
> account. Indeed, combat in ASL is won more by breaking enemy squads
> than just plain killing them.
Yep, I plan to model morale.
> Anyway, many of the above issues can be tackled by carefully picking
> the premise of the game. For instance, look at Syndicate. The God's
> eye perspective perfectly matched the premise of your observational
> perspective from a satellite. The micromanagement and dumb units
> were explained by them being drugged up and being directly controlled
> by you.
>
> Another premise that would work well would be Aliens. The commander
> of a platoon inside the APC has a direct feed from each soldier, so
> it's realistic to have near-perfect knowledge of the locations and
> views from each soldier. In this case, though, the soldier's aren't
> drugged up dumb slaves, so they could act more independently.
Then again, these might just be flimsy excuses against tackling the hard game
design problems of greater realism. Like, how to make fog of war *really*
foggy, but still fun to play.
--
Javier Arevalo
wrote:
>Yes exactly. As soon as a "real-time tactical" game includes production,
>I think it moves over to the "real-time strategy" game side. The reason,
>is that the resource gathering and unit production aspects require a more
>strategic level of planning
I would base the difference on time. Most so-called RTS games don't
really require any long-term strategic planning, they are more like a
series of isolated skirmishes against the enemy. Yeah as the game
progresses the effect of previous battles on the number of troops
and/or terrain available will be noticeable, but that doesn't give it
any long-term strategic quality. Some strategies like "build an army
with this specific combo of units" are so simple I would call them
"techniques". :)
And you are right, resource gathering gives RTS their strongest
strategy element: gain terrain in order to gain resources, eventually
starving the enemy, etc.
In truth I wonder how many gamers out there want to face truly
strategic gameplay, with long-term planning, and decisions that will
prove their viability hours after they're made. What if the decision
proved wrong? Go back to the start and replay the mission/scenario
with a new strategy. But of course, a mission shouldn't be prepackaged
so there's a single winning strategy that works all the time.
Balancing gameplay against a strategic AI is such a hard task, most
games rely on scenery and script design to achieve that balance.
Greets
Javier Arevalo
Technology Lead @ the Commandos Team
http://web.jet.es/jare
change nospam to jare in the address to send email
Eric Dybsand
Javier Arevalo <nos...@jet.es> wrote in message
news:388af313...@news.jet.es...
> >I think it moves over to the "real-time strategy" game side. The reason,
> >is that the resource gathering and unit production aspects require a more
> >strategic level of planning
>
> really require any long-term strategic planning, they are more like a
> series of isolated skirmishes against the enemy. Yeah as the game
> progresses the effect of previous battles on the number of troops
> and/or terrain available will be noticeable, but that doesn't give it
> any long-term strategic quality. Some strategies like "build an army
> with this specific combo of units" are so simple I would call them
> "techniques". :)
"Time" is certainly one aspect of the strategic consideration
that differs between an RTS and RTT. However, regardless
of how simple a strategy may be (as in a "technique" as you
call it) it is still a strategy. This difference is what I think is
the separtion between and RTS and RTT.
> In truth I wonder how many gamers out there want to face truly
> strategic gameplay, with long-term planning, and decisions that will
> prove their viability hours after they're made.
It is certainly a minority, albeit a vocal one with very distinct
ideas about what is and is not a fun game. I happen to think
I straddle both worlds. I'm currently enjoying several turn-based
wargames and 4X games, that I can only make one or two turns
each day. At the same time, I'm enjoying Age of Kings, and I
just downloaded the Shogun demo which I plan to play soon.
Other gamers fall into only one or the other camps. To each
their own, I say.
> What if the decision
> proved wrong? Go back to the start and replay the mission/scenario
> with a new strategy.
I typically try to hang in there, and fight my way back. It makes
for more of a challenge and generates more tension (ie. fun) for me.
> But of course, a mission shouldn't be prepackaged
> so there's a single winning strategy that works all the time.
Agreed.
>
> Balancing gameplay against a strategic AI is such a hard task, most
> games rely on scenery and script design to achieve that balance.
Agreed.
Eric
Eric Dybsand
>
> Secondly ...
> Brandon, can we influence your functional specs? Or more to the point,
> could Eric lay out some minimum functionality requirements with regard
> to unit AI? I too would like to see a simple demo of some basic
> functionality. I was becoming dismayed when reading your some of your
> additional game concepts (being influenced by your most recently played
> game? :). For a functional demo, I wouldn't care if it was fun.
This is Brandon's game design. I have no interest in influencing
his design. My interest is only in encouraging him to take the
project into the implementation phase, and get it out onto the
'net for some player feedback. I think doing that, will allow
Brandon to learn alot of what really has to happen in building
the AI in a computer game, as opposed to just discussing it.
In other words, I think it will be a great learning experience.
Eric
Valter Hilden
> ...
> In truth I wonder how many gamers out there want to face truly
> strategic gameplay, with long-term planning, and decisions that will
> prove their viability hours after they're made.
For me, this is the weak point in Civilization-like games. In
particular, I like FreeCiv, but I hate the micro-management you must do
to optimize each and every city's production. I think it's fun to decide
which technologies you want developed, but it's a real pain when you
have more than 20 cities to watch and worry about each and every one of
their citizens. And if you don't do that, you end with less technology
than the AI and lose the game.
Rick Craik
One more nudge (it's Sunday and too cold to go outside) ...
Eric Dybsand wrote in message ...
Further back in this thread Brandon said:
"... and I want people to play it, to test the theory. I just
want to try to get some basic gameplay correct, because it'll
be the 1st time I've ever attempted AI."
and
"Actual "thinking" on the part of the computer, I'm just stepping
off a cliff, we'll see what happens.".
How about some dimensions to "Brandon's Cliff", how wide, how high,
the slope, and how rough is the slide down is? What is this basically
correct great wargame AI gameplay?
I believe you have already contributed to this end with:
"If the LoDO takes place at levels below that which was commanded,
then the AI will have to make some "interpretation" of the orders
and decide what control to apply to the lower ordered sub-unit of
the main unit that was commanded."
And then Brandon says:
"Yep. That's the idea of what I want to do: the player issues operational
commands only."
(I have an associate that I e-mail conceptual outlines to constantly,
he usually replies with one word, "Interesting". I offered to quit
sending them, but he said he enjoyed them. I found that this helped
clarify a lot of things in my mind, and allowed me to move on. I think
Brandon is doing the same thing, and I feel that something more than
just interest may be appropriate, and possibly welcomed.)
So now we have some basic minimum great Wargame AI functionality:
1) Some "interpretation" of the orders.
2) What control to apply to the lower ordered sub-unit?
For (1), what are minimum orders and minimum interpretations?
1.1 LISTS OF OPERATIONAL COMMANDS:
1.1.1 Required Operational Commands
Interpretation of Operational Commands is simple.
[Move, Attack, Hold ground, Search and destroy]
(The first three for sure, the last one is always on my
wish list, and I see it basically as a random move and
attack. Hold ground is a don't move or attack, just the
opposite.)
These commands require wargame AI for;
a) Path finding
We all know this one.
b) Navigation
No-go zones, waypoints, avoid enemy LOS, maintain formation.
c) Morale
Do units carry out basic commands well.
Units are conscripted, mercenaries, patriots, or fanatics.
Requires knowledge of enemy capabilities, probable battle outcome.
Units require a leader.
1.1.2 Featured Operational Commands
Interpretation of Operational Commands is varied.
[Retreat, Harass, Conceal, Maintain contact, Ambush, Stall, Flank]
These are optional features used at the discretion of the game
designer. They pretty well map one to one with Optional wargame AI
commands. If you add the command, you got to write the specific AI.
The exception may be Flank, which requires knowledge of unit groups.
a) Retreat
If not used, then units fight to the death. Otherwise is related
to basic LoDO Moral AI (1.1.1c) for a rout, or at command level
for an orderly fashion.
b) Harass
An extension of search and destroy. Related to basic LoDO Moral
AI (1.1.1c) for knowing when to break off. Requires Conceal
(1.1.2c) functionality.
c) Conceal
Requires Navigation (1.1.1b)
d) Maintain contact
Requires Navigation (1.1.1b), and Unit groups (1.1.4a)
e) Ambush
Requires Conceal (1.1.1c), and possibly Unit groups (1.1.4a)
f) Stall
Requires Retreat (1.1.2a), and Maintain Contact (1.1.2d)
g) Flank
Requires Navigation (1.1.1b), Requires Formation (1.1.4)
1.1.3 Unit Specific Commands
Interpretation of Operational Commands is simple.
[Snipe, Build walls, Skulk / infiltrate, Observe, Dig tunnels]
These are optional features used at the discretion of the game designer.
(My head hurts on this one ...)
1.1.4 Formation Commands
Interpretation of Operational Commands is varied.
[staggered defense, Column, Rank, Wedge]
These are optional features used at the discretion of the game designer.
(I'll need help on this one ...)
These commands require wargame AI for;
a) Unit groups (Stationary and Mobile)
Requires proper deployment of units. If moving, how to thread a
bottleneck. How and when to scatter. How to march in formation.
How to attack in formation.
b) Swarming
Simple unit to unit rules exhibit desirable emergent behaviours.
For (2) What control to apply to the lower ordered sub-unit?
(This is pretty sketchy from my point of view, and have no practical
experience in this area. Which is why I am following this thread.)
2.1 LIST OF CONTROL DECISIONS
Here the WarGame AI is given an operational command and resources
to carry out the command.
2.1.1 Required Control Decisions
How many groups or individuals are required to accomplish orders.
What basic, or featured commands are required.
2.1.2 Featured Control Decisions
Explore, Expand, Exploit, Explode?
2.1.3 Specific Control Decisions
----
Yours
Rick
Eric Dybsand
> Hi Eric;
>
> One more nudge (it's Sunday and too cold to go outside) ...
>
Sorry about that Rick ... it was sunny and fortysomething here today
so I rode the bike about 10 miles. Brandon's game is for Brandon
to design, not me. Besides, my plate is already full. I barely have
time to post as infrequently as I do now, much less help to design
someone else's game.
Thanks, but no thanks.
Eric
Brandon Van Every
"Rick Craik" <NOSPAM...@ntl.sympatico.ca> wrote in message news:pLKi4.261
> Eric said:
> >
> >In other words, I think it will be a great learning experience.
Totally agree. And I do want to concentrate more on implementation than on
theorizing. I believe you have to build something to know what the next phase
is going to be. It is far more likely that I'll discuss nitty-gritty of
operational level AIs trying to outguess human opponents, *after* the basic sim
and unit AI is established. In this way, the project "sucks me into" needing to
know/learn more about AI.
I do think it's worth discussing some of the basic design issues in advance,
though. I'm just not going to talk myself to death about it. :-)
> 1.1 LISTS OF OPERATIONAL COMMANDS:
>
> 1.1.1 Required Operational Commands
> Interpretation of Operational Commands is simple.
> [Move, Attack, Hold ground, Search and destroy]
>
> (The first three for sure, the last one is always on my
> wish list, and I see it basically as a random move and
> attack. Hold ground is a don't move or attack, just the
> opposite.)
I don't agree that the interpretation of operational commands is simple.
Thieves, for instance, will have to do pretty sophisticated things when given a
directive such as "infiltrate the enemy's left flank, establish a sniping
position, and take out targets of opportunity." That thief is going to have to
go to some area of the map, find some cover that has a good view of somewhere
that enemy troops may likely come through, and that has a good escape route.
And then, repeat ad nauseum according to evolving conditions.
What is simple, however, is all of these commands will be issued in regards to a
particular area of operations. As an interface, you'd need to highlight a
irregular area on the map, and also have arrows for direction of intended
advance. Probably there needs to also be a method of specifying qualitative
objectives, like "take over the Red Fire Grotto we've been hearing about." You
don't know where it is, but you know that you want X force to try to capture it,
guessing roughly it's in some northwards region of the board.
Design-wise, I say the *issuing* of the operational commands should be simple.
Not their interpretation. Interpretation is going to require fairly strong unit
AI, and lotsa analysis of conditions. Note also, everyone is going to utilize
the same unit AIs, regardless if the commander is a human or a computer.
Different AIs are going to perform different tasks with different effectiveness,
often *widely* varying degrees of effectiveness. If you tell a Juggernaut to
sneak around the enemy's left flank and snipe at targets of opportunity, what
it's really going to do is bulldoze the left flank as loudly as a screaming
steam engine typically does, bang into walls, etc. It's going to be about the
least stealthy thing imaginable and the player who gave such a silly order will
probably pay the price for it - unless it just happens to create so much happy
confusion that it turns out to be a good result anyways. :-) In general, the
game is going to be about players deploying the correct types of unit AIs to the
correct regions of the board at the correct times.
> 1.1.2 Featured Operational Commands
> Interpretation of Operational Commands is varied.
> [Retreat, Harass, Conceal, Maintain contact, Ambush, Stall, Flank]
>
> These are optional features used at the discretion of the game
> designer.
Something about this comment makes me think we're not on the same page here. If
we're discussing my game, I am the game designer. The commands listed above are
*not* optional, it's what almost every unit has to be capable of interpreting.
All 20th century combat uses sneaking around as a basic method of killing the
enemy - don't care if you're regular army, Special Forces, whatever. Ditto all
the other commands, this is what people do in modern warfare. I'm not
interested in those forms of historical warfare where people lined up and made
nice neat rational targets out of themselves, I'm interested in fighting as
survival.
You could try to make an open conceptual framework for "anybody's game," as
opposed to my game. With option switches and all of that. But, from my
standpoint, that's a complete waste of time both design-wise and
implementation-wise. My experience from writing 3D device drivers is that all
the silly option flags are death. You cannot support all those silly option
flags well. What you need to do, is decide exactly what you intend to support
well, and then hardwire the system to do it.
> a) Retreat
> If not used, then units fight to the death. Otherwise is related
> to basic LoDO Moral AI (1.1.1c) for a rout, or at command level
> for an orderly fashion.
No, units self-preserve according to their morale. It would take ridiculously
high morale to fight to the death, they would have to perceive that no other
option was possible given the circumstances. But notably: some creatures don't
know the meaning of the word "Retreat." Ants, Juggernauts. Dovetails with
creatures who don't know the meaning of the word "fear."
> b) Harass
> An extension of search and destroy. Related to basic LoDO Moral
> AI (1.1.1c) for knowing when to break off. Requires Conceal
> (1.1.2c) functionality.
No, it is fundamentally not the same tactic. It is "seek, shoot, run away."
Whereas search and destroy is "seek, shoot, press. seek, shoot, press."
Harassment means annoying the enemy, to waste the most of its time and
resources, for the least investment of your own time and resources. Harassment
may cause the enemy great consternation, or they might brush it off like a fly.
Depends on the prevailing psychology of the people being attacked (compare
terrorism.) Search and destroy means exterminating the enemy within a specific
area. Generally, it takes a thorough committment of resources to accomplish
this. 1 Thief can harass. 1 Thief *cannot* search and destroy.
> 1.1.3 Unit Specific Commands
> Interpretation of Operational Commands is simple.
> [Snipe, Build walls, Skulk / infiltrate, Observe, Dig tunnels]
>
> These are optional features used at the discretion of the game designer.
Again, whose game are we discussing? Sorry if I don't plan to contribute much
longer to an abstract framework for any possible game. I have a very specific
game in mind, that I need to implement. AI is going to look totally, totally
different in a game where the topology of a dungeon (walls, tunnels) is changing
all the time.
> 1.1.4 Formation Commands
> Interpretation of Operational Commands is varied.
> [staggered defense, Column, Rank, Wedge]
It is important to note that my game will be played in a dungeon. The most
relevant terrains are those found in urban warfare and jungle warfare. It is
probably not advisable to concentrate on the dynamics of footsoldiers fighting
on an open plain, as there will rarely be such a plain to fight upon.
> a) Unit groups (Stationary and Mobile)
> Requires proper deployment of units. If moving, how to thread a
> bottleneck. How and when to scatter.
> How to march in formation.
> How to attack in formation.
Again, the question in my game is not usually how to do these things in a rigid
formation, but how to navigate an irregular terrain with fields of fire, good
visibility, good cover, and flexibility in the face of the unexpected.
One big question is how I'm going to define "cover." In a 256x256 grid game,
the simplest cover is just peeking around a corner. And, you have to explicitly
put objects on board squares for there to be any other kind of cover. I haven't
decided whether I want to implement "cover" with more obstacles, or just rely on
the very abstract notion of the corners being the cover in all circumstances. I
am thinking that corners would seriously limit the available fields of fire,
though. You'd have to implement a "forest" by having lotsa individual
impassable stone squares - stalagmites? Actually, this might not be a bad
paradigm at all... I just wonder if it'll take up too much grid space for what
it buys you.
> 2.1.1 Required Control Decisions
>
> How many groups or individuals are required to accomplish orders.
> What basic, or featured commands are required.
I have a complete dodge about this one: it's really not your problem! A huge
part of the game is political. You don't start with any forces, you just have
an Avatar wandering around in the dungeon and you are trying to recruit forces,
by doing nice/mean things for various creatures, and telling truth/lies to them
about what you're going to reward them with. Basically, you're trying to make a
dungeon that the creatures like more than the other guys' dungeon. So, if you
want to recruit the Orcs to your cause, it's really not your option how they're
going to split themselves up. They have their own chieftains, their own
leaders, and their own sense of how they organize themselves. You can try
ordering them to take 4 different objectives at once... maybe they'll split up
as you'd like, maybe they totally won't. Maybe they'll say screw you and your
silly order, and go work for someone else!
Your capability as a commander: you've got various clumps of self-organizing
material to work with. You tell those clumps where to go.
> 2.1.2 Featured Control Decisions
> Explore, Expand, Exploit, Explode?
No idea what this means.
Isaac Kuo
Brandon Van Every <vane...@3DProgrammer.com> wrote:
>"Isaac Kuo" <k...@oldbit.csc.lsu.edu> wrote in message
>>Is this a game or a simulation? Just because something's not realistic
>>doesn't mean it's not good for gameplay. Having unrealistically
>>precise control over one's own forces is traditionally popular in
>>wargames.
>As far as I'm concerned, micromanagement is crap. This particular
>game designer hath spoken. :-) I don't like it in computer games,
>it wastes too much of my time.
I can appreciate this argument, since it runs from gameplay grounds.
I don't think much of the argument from realism, since the main
objective of a game is to be fun--not to be realistic.
>I believe in delegation, not micromanagement.
In most wargames, the gameplay problems of "micromanagement" are
avoided simply by keeping the game mechanisms simple. If the
player doesn't have control over the exact placement of individual
troops, why bother representing them in the game? Thus, a squad
in ASL is represented by a single counter. An army in 3rd Reich
is represented by a single counter. More detail is pointless,
because the player has no control at finer levels anyway (nor
does the player want such detailed control responsibilities).
[Brandon thinks that a wargame should be claustrophobic, with
the player presented with a very limited view and poor control.]
>>Why? That doesn't sound like fun--and IMO the primary objective
>>of a game should be that it's fun.
>"Fun" is something totally in your prejudiced imagination, until
>you've actually played a game.
Nonsense. You can talk about what's fun and not in theory as
well as practice.
If I say, "In my game, the player will have poor control because
it's realistic," I wouldn't be surprised if others were skeptical
of it being fun.
>>Anyway, many of the above issues can be tackled by carefully picking
>>the premise of the game. For instance, look at Syndicate. The God's
>>eye perspective perfectly matched the premise of your observational
>>perspective from a satellite. The micromanagement and dumb units
>>were explained by them being drugged up and being directly controlled
>>by you.
>>Another premise that would work well would be Aliens. The commander
>>of a platoon inside the APC has a direct feed from each soldier, so
>>it's realistic to have near-perfect knowledge of the locations and
>>views from each soldier. In this case, though, the soldier's aren't
>>drugged up dumb slaves, so they could act more independently.
>Then again, these might just be flimsy excuses against tackling the hard game
>design problems of greater realism.
It's not a flimsy excuse. I think it's a brilliant way to solve
the problem of balancing realism with playability. Instead
of fixing a premise and looking at what's realistic vs what's
playable, figure out what's playable, and find a premise which
makes it realistic.
>Like, how to make fog of war *really* foggy, but still fun to play.
In general, games over which the players have little control over
are not fun.
Remember the basics of a fun game--the player must be able to
make decisions and those decisions must count. A player who
feels he isn't getting enough information and/or can't control
his situation will get frustrated because he either can't make
meaningful decisions.
Brandon Van Every
> I don't think much of the argument from realism, since the main
> objective of a game is to be fun--not to be realistic.
I think "fun vs. realism" is a completely religious issue and a completely
artificial dichotomy. Some people feel that fun EQUALS real, and so they play
games like Rainbow Six and whatnot. The closer you get to real life simulation,
the more such people are pleased. Other people feel that entertainment is
fundamentally escapism and so heightened unreality is what should be sought.
Still others take realism or unrealism in whatever dose they personally think is
appropriate.
> >I believe in delegation, not micromanagement.
>
> In most wargames, the gameplay problems of "micromanagement" are
> avoided simply by keeping the game mechanisms simple. If the
> player doesn't have control over the exact placement of individual
> troops, why bother representing them in the game?
Because the player might be able to make logical deductions about high-level
interactions on the basis of observing automatic, low-level troop movements.
You might call this having an "eye" for the emergent behavior. It is quite a
different approach to studying phenomena than saying "well we don't have
computational resources to represent it, so it's a die roll." Wargames
historically had die rolls because they could not have possibly done anything
else to model complex phenomena.
> More detail is pointless,
> because the player has no control at finer levels anyway (nor
> does the player want such detailed control responsibilities).
Perception *is* control, so long as perception is somehow relevant to the
control you really do have.
> >"Fun" is something totally in your prejudiced imagination, until
> >you've actually played a game.
>
> Nonsense. You can talk about what's fun and not in theory as
> well as practice.
"Un-fun games aren't fun" isn't a theory, it's a tautology.
> If I say, "In my game, the player will have poor control because
> it's realistic," I wouldn't be surprised if others were skeptical
> of it being fun.
You've loaded your definitions with an inherent bias. Your controls will be
"poor" according to what definition? Leave the value judgements out. Define
your controls... then you're going to find that everyone has an opinion on
whether they're "poor" or not.
> >>Anyway, many of the above issues can be tackled by carefully picking
> >>the premise of the game. For instance, look at Syndicate. The God's
> >>eye perspective perfectly matched the premise of your observational
> >>perspective from a satellite. The micromanagement and dumb units
> >>were explained by them being drugged up and being directly controlled
> >>by you.
>
> >>Another premise that would work well would be Aliens. The commander
> >>of a platoon inside the APC has a direct feed from each soldier, so
> >>it's realistic to have near-perfect knowledge of the locations and
> >>views from each soldier. In this case, though, the soldier's aren't
> >>drugged up dumb slaves, so they could act more independently.
>
> >Then again, these might just be flimsy excuses against tackling the hard game
> >design problems of greater realism.
>
> It's not a flimsy excuse. I think it's a brilliant way to solve
> the problem of balancing realism with playability. Instead
> of fixing a premise and looking at what's realistic vs what's
> playable, figure out what's playable, and find a premise which
> makes it realistic.
What if as a player, instead of lauding your brilliance at picking narrow
problems, I say it's crap because you didn't solve the hard problems I wanted
you to solve? Ergo, brilliance or crap is a matter of audience expectations.
If I expect something else from you, I will think your work is crap. Newsgroups
like csipg.strategic are filled with debates like this. You can't please
everybody, so you shouldn't try to. Don't cut your problems down to "a
satellite game" because you're afraid of someone bitching and moaning about
realism. Make a satellite game because you WANT to make a satellite game. No
other reason, no other justification. If someone else thinks it should have
been a satellite game, tell *them* to go make the satellite game.
> >Like, how to make fog of war *really* foggy, but still fun to play.
>
> In general, games over which the players have little control over
> are not fun.
Since when does really foggy = little control? Foggy games are about
*establishing* your control. But, if you don't see a game in those terms, if
you think control is supposed to already be handed to you on a silver platter...
well IMHO you're a wuss. A whiner. Not cut out for anything resembling real
fighting or real warfare. [That's "Queen's You" BTW.]
Isaac Kuo
Brandon Van Every <vane...@3DProgrammer.com> wrote:
>"Isaac Kuo" <k...@oldbit.csc.lsu.edu> wrote in message
>> I can appreciate this argument, since it runs from gameplay grounds.
>> I don't think much of the argument from realism, since the main
>> objective of a game is to be fun--not to be realistic.
>I think "fun vs. realism" is a completely religious issue and a completely
>artificial dichotomy. Some people feel that fun EQUALS real, and so they play
>games like Rainbow Six and whatnot. The closer you get to real life simulation,
>the more such people are pleased. Other people feel that entertainment is
>fundamentally escapism and so heightened unreality is what should be sought.
>Still others take realism or unrealism in whatever dose they personally think is
>appropriate.
Come on, Rainbow Six isn't realistic in ways which would make
the game less fun. When you die, you still get to play by
unrealistically taking control of the next guy. Plain drywall
blocks bullets (forcing the players to engage the enemy more
aggressively and giving them unrealistic defensive options).
The AI of the terrorists...well, they don't freak out and go
berzerk when another gets shot by a silenced bullet right in
front of them.
Of course, you have near perfect control over all your team
members. This is arguably realistic because of the high training
and discipline of your force--which I think is just fine. You
seem to think it could be a disadvantage, since some players
might see it as a thinly veiled excuse to not tackle issues of
imperfect control and coordination.
>>>I believe in delegation, not micromanagement.
>>In most wargames, the gameplay problems of "micromanagement" are
>>avoided simply by keeping the game mechanisms simple. If the
>>player doesn't have control over the exact placement of individual
>>troops, why bother representing them in the game?
>Because the player might be able to make logical deductions about high-level
>interactions on the basis of observing automatic, low-level troop movements.
>You might call this having an "eye" for the emergent behavior. It is quite a
>different approach to studying phenomena than saying "well we don't have
>computational resources to represent it, so it's a die roll." Wargames
>historically had die rolls because they could not have possibly done anything
>else to model complex phenomena.
Wrong answer. If the player's high level decisions can't have
an effect on that low detail level, it still is no more or less
useful than a die roll.
The right answer is that the player might find it interesting to
watch. In other words, it's essentially a cinema cut scene--but
one which is (almost) never the same twice.
Knowing the correct reason why some feature adds to the game
is helpful in designing and implementing it successfully.
>>More detail is pointless,
>>because the player has no control at finer levels anyway (nor
>>does the player want such detailed control responsibilities).
>Perception *is* control, so long as perception is somehow
>relevant to the control you really do have.
If the player has NO control at finer levels, it is not
relevant.
>>>"Fun" is something totally in your prejudiced imagination, until
>>>you've actually played a game.
>>Nonsense. You can talk about what's fun and not in theory as
>>well as practice.
>"Un-fun games aren't fun" isn't a theory, it's a tautology.
So what? Who said that?
>>If I say, "In my game, the player will have poor control because
>>it's realistic," I wouldn't be surprised if others were skeptical
>>of it being fun.
>You've loaded your definitions with an inherent bias. Your controls will be
>"poor" according to what definition?
According to the definition that they won't be good (as opposed to
"rich", another opposite to poor which doesn't make sense in this
context).
>Leave the value judgements out.
It is a value judgement, but not a totally subjective one. It's
a value judgement made by who really matters--the (potential)
players. While that's a subjective judgement for each player,
for the publisher wanting to sell the game to as many players
as possible, it's an objective factor.
What does it mean to have poor control? Basically, it means
that you have difficulty doing what you want to do. For
an individual player, that's a value judgement.
Who knows? Maybe someone out there _likes_ playing Netrek
on a laggy connection that loses 4 out of 5 packets.
>Define your controls... then you're going to find that everyone
>has an opinion on whether they're "poor" or not.
And for games with very poor control, pretty much everyone's
opinion is that the control sucks. That's what really matters.
>>>>Anyway, many of the above issues can be tackled by carefully picking
>>>>the premise of the game. For instance, look at Syndicate. The God's
>>>>eye perspective perfectly matched the premise of your observational
>>>>perspective from a satellite. The micromanagement and dumb units
>>>>were explained by them being drugged up and being directly controlled
>>>>by you.
>>>>Another premise that would work well would be Aliens. The commander
>>>>of a platoon inside the APC has a direct feed from each soldier, so
>>>>it's realistic to have near-perfect knowledge of the locations and
>>>>views from each soldier. In this case, though, the soldier's aren't
>>>>drugged up dumb slaves, so they could act more independently.
>>>Then again, these might just be flimsy excuses against tackling the hard game
>>>design problems of greater realism.
>>It's not a flimsy excuse. I think it's a brilliant way to solve
>>the problem of balancing realism with playability. Instead
>>of fixing a premise and looking at what's realistic vs what's
>>playable, figure out what's playable, and find a premise which
>>makes it realistic.
>What if as a player, instead of lauding your brilliance at picking narrow
>problems, I say it's crap because you didn't solve the hard problems I wanted
>you to solve? Ergo, brilliance or crap is a matter of audience expectations.
>If I expect something else from you, I will think your work is crap.
If only a few players see it that way, then it's not a problem.
The success of games like Rainbow Six and Syndicate suggests
it's not a problem.
If most players see it that way, then it's a problem. What
games failed because of this, I wonder?
>Newsgroups like csipg.strategic are filled with debates like this.
>You can't please everybody, so you shouldn't try to.
Nonsense. You can't please everybody, but you CAN please your
target market. You SHOULD try to please them! (Even if it's
by offering something they didn't know they wanted.)
>Don't cut your problems down to "a
>satellite game" because you're afraid of someone bitching and moaning about
>realism. Make a satellite game because you WANT to make a satellite game. No
>other reason, no other justification. If someone else thinks it should have
>been a satellite game, tell *them* to go make the satellite game.
Huh? Presumably, the creators of Syndicate thought it was a
cool idea. Presumably, the creators of Rainbow Six thought
it was a cool idea. But even so, they no doubt tried to
make a game which was fun to play.
>>>Like, how to make fog of war *really* foggy, but still fun to play.
>>In general, games over which the players have little control over
>>are not fun.
>Since when does really foggy = little control? Foggy games are about
>*establishing* your control. But, if you don't see a game in those terms, if
>you think control is supposed to already be handed to you on a silver platter...
>well IMHO you're a wuss. A whiner. Not cut out for anything resembling real
>fighting or real warfare. [That's "Queen's You" BTW.]
I don't care what you think of me, and the opinion of one consumer
doesn't really matter much in and of itself.
However, it DOES matter if most potential players don't like
struggling just to establish control in a game.
I find it quite ironic that you feel this way, because you yourself
don't like micromanagement. The tedious click-fest that is
micromanagement is itself a struggle to establish/maintain control!
If you think control is supposed to already be handed to you on a
silver platter...well IMHO you're a wuss.
Actually, I don't think you're a wuss. I just think you don't
like fighting the game just to control your forces. What's
more important, the dislike of micromanaging a large force
is a common opinion--it's a flaw in many computer wargames
which isn't apparent at the start (when the forces are small
and controllable).
At least those wargames get the difficulty curve right--it's
easier at the start, and then gets progressively more difficult.
That's a general principle to a fun game.
Brandon Van Every
I'm not participating any longer. The bottom line is: nobody has to design a
game for your own pet version of reality. People have got different subjective
senses of reality, they don't all agree, and it's no game designer's job to
please everybody. Or even to please big crowds, for that matter. You can yell
and scream all you want that "the players" demand this-and-that, but it's just a
hollow megaphone for your own subjective version of reality. Nobody owns the
art and craft of game design, let alone at this early stage of the industry's
history, so it's rather presumptuous to insist that such-and-such an idea will
fail if you don't live in the holy tyrrany of would-be players.
*Tangibles*, to me, right now, means: talk to me about urban/jungle tactics with
a really foggy command-and-control network. Anything else, frankly right now I
don't give a damn. I have a game to write.
"Isaac Kuo" <k...@oldbit.csc.lsu.edu> wrote in message
> Brandon Van Every <vane...@3DProgrammer.com> wrote:
>
> >I think "fun vs. realism" is a completely religious issue and a completely
> >artificial dichotomy. Some people feel that fun EQUALS real, and so they
play
> >games like Rainbow Six and whatnot. The closer you get to real life
simulation,
> >the more such people are pleased. Other people feel that entertainment is
> >fundamentally escapism and so heightened unreality is what should be sought.
> >Still others take realism or unrealism in whatever dose they personally think
is
> >appropriate.
>
> Come on, Rainbow Six isn't realistic in ways which would make
> the game less fun. When you die, you still get to play by
> unrealistically taking control of the next guy.
The basic point is that a lot of players don't like taking 1 bullet in the head
in the 1st place. They want to be a tank, and Rainbow Six doesn't let you be a
tank.
> Plain drywall
> blocks bullets (forcing the players to engage the enemy more
> aggressively and giving them unrealistic defensive options).
Sounds like a limitation of the simulation complexity, not a "fun" issue.
> The AI of the terrorists...well, they don't freak out and go
> berzerk when another gets shot by a silenced bullet right in
> front of them.
Sounds like an error of the AI simulation. Doubt it has anything to do with
things being "fun." And actually - aren't there different settings for how the
AIs react? I'm pretty sure that in the demo I played, if you set the highest
difficulty level, when the terrorists hear gunfire they start killing hostages.
> Of course, you have near perfect control over all your team
> members. This is arguably realistic because of the high training
> and discipline of your force--which I think is just fine. You
> seem to think it could be a disadvantage, since some players
> might see it as a thinly veiled excuse to not tackle issues of
> imperfect control and coordination.
It is when you scale up to 100,000 men as opposed to 10!
> >Because the player might be able to make logical deductions about high-level
> >interactions on the basis of observing automatic, low-level troop movements.
> >You might call this having an "eye" for the emergent behavior. It is quite a
> >different approach to studying phenomena than saying "well we don't have
> >computational resources to represent it, so it's a die roll." Wargames
> >historically had die rolls because they could not have possibly done anything
> >else to model complex phenomena.
>
> Wrong answer. If the player's high level decisions can't have
> an effect on that low detail level, it still is no more or less
> useful than a die roll.
Then you just don't get it. Oh well, I'll have to write the game before some
people understand.
> The right answer is that the player might find it interesting to
> watch. In other words, it's essentially a cinema cut scene--but
> one which is (almost) never the same twice.
>
> Knowing the correct reason why some feature adds to the game
> is helpful in designing and implementing it successfully.
Believing that you already have all the answers is a good way to stifle
innovation.
> >"Un-fun games aren't fun" isn't a theory, it's a tautology.
>
> So what? Who said that?
You did. In your next sentence:
> >>If I say, "In my game, the player will have poor control because
> >>it's realistic," I wouldn't be surprised if others were skeptical
> >>of it being fun.
>
> >You've loaded your definitions with an inherent bias. Your controls will be
> >"poor" according to what definition?
>
> >Leave the value judgements out.
>
> It is a value judgement, but not a totally subjective one.
In your subjective opinion...
> It's
> a value judgement made by who really matters--the (potential)
> players.
...as champion of some unspecified authority known as "the players." Which,
really, can be just about anything you want to imagine them to be, so long as it
suits your subjective bias.
> While that's a subjective judgement for each player,
> for the publisher wanting to sell the game to as many players
> as possible, it's an objective factor.
Nonsense. The publisher, at best, has some info from some playtesters. Who
cannot possibly represent everyone who will ever interact with the game - unless
they just Make It So by reasons of limited brick-and-mortar retail shelf space.
Hollywood screen tests its movies and changes things around according to
reactions... do you really believe this is a process of arriving at The One True
Movie? Hardly. Someone at the top of the food chain makes the ultimate
subjective decision about what's going to happen, based on whatever religion of
inputs they want to follow.
> What does it mean to have poor control? Basically, it means
> that you have difficulty doing what you want to do. For
> an individual player, that's a value judgement.
Well then the vast majority of puzzle-based adventure games are based on "poor"
control, by your definitions. Ever consider that some people *like* having a
strong impediment in front of them? You can go serve some other demographic if
you like, but you can't change the fact that puzzle-heads enjoy tough puzzles.
> Who knows? Maybe someone out there _likes_ playing Netrek
> on a laggy connection that loses 4 out of 5 packets.
We've been discussing issues of so-called "realism" vs. so-called "fun," not
technical inadequacies. Stick to the subject.
> >Define your controls... then you're going to find that everyone
> >has an opinion on whether they're "poor" or not.
>
> And for games with very poor control, pretty much everyone's
> opinion is that the control sucks. That's what really matters.
You're conjecturing about controls that you haven't even seen. I'm *not*
implementing a game with a friggin' joystick!!!! "Control" isn't some absolute
thing that exists in the abstract, you have to consider the "control paradigm."
Do you not like the control in a game of Chess because it takes too long for the
other player to move? Do you not like Blitz Chess because you experience a loss
of control while playing it? Do you not like martial arts because you're not
very well trained in them? WHAT are you trying to control? What are your
expectations vs. your skills? Do you like being told that you're good or do you
like challenges? Do you like things neat, orderly, and rigid, or do you like
things loose, wild, and unpredictable? Geez, the magazine industry only writes
1 million articles a year about people's need for control and loss of control in
a domain as limited as people's sex lives. Why do you think you or anyone would
ever own the market on what kind of control people are looking for?
Um, beg pardon, but Rainbow Six isn't on your list of reality
restricting/dodging concepts above. And proof-by-Syndicate doesn't say anything
about why it was a successfully selling title, only that it sold successfully,
by *your* measure of success. Who knows? Maybe people liked the eye candy or
something. Maybe they liked the concept enough to buy it and not return it for
2 weeks, but it fell short for them after that. Sales = you suckered someone
into plunking down the dough for it, not that you proved you had The One True
Game Design Approach.
> If most players see it that way, then it's a problem. What
> games failed because of this, I wonder?
You tell me. *My* game hasn't even been made yet! And I'm not yet aware of a
game where you issue operational orders to sub-AIs that are pursuing their own
realtime tactics, where you can't micromanage a darned thing, so unless you've
got a whole slew of relevant titles to pull out of your sleeve, I've had about
enough of this almost useless, completely abstract conversation.
> >Newsgroups like csipg.strategic are filled with debates like this.
> >You can't please everybody, so you shouldn't try to.
>
> Nonsense. You can't please everybody, but you CAN please your
> target market. You SHOULD try to please them! (Even if it's
> by offering something they didn't know they wanted.)
Oh THERE's a great excuse. You've now come over to my side! Only you've window
dressed it to say it like you're really trying to please someone else. If you
"know better" than the public what they're going to want to play, if deep in
your heart you feel they're all a bunch of bitching and complaining whiners ("No
beach! No beach!"), then you're not targetting markets you're driving markets.
Big difference as to whose crap you feel you need to listen to, about whether
the "controls" are inadequate.
> >Don't cut your problems down to "a
> >satellite game" because you're afraid of someone bitching and moaning about
> >realism. Make a satellite game because you WANT to make a satellite game.
No
> >other reason, no other justification. If someone else thinks it should have
> >been a satellite game, tell *them* to go make the satellite game.
>
> Huh? Presumably, the creators of Syndicate thought it was a
> cool idea. Presumably, the creators of Rainbow Six thought
> it was a cool idea. But even so, they no doubt tried to
> make a game which was fun to play.
But you Isaac, on the other hand, have been championing the "brilliance" of
these ideas on the basis of them cutting down "reality" to some
weirdly/artificially isolated problem. Which honestly sound like a lot of
Dickensian excuses for why you wouldn't want to have to implement a foggy
comand-and-control network. Command and control is a HARD military problem, and
is usually ignored in RTS games. If I want to write a game that deals with it
in some way, as a fundamental issue of gameplay, don't tell me nobody's
interested. I can assure you that most of the *.war-historical crowd would be
interested - if only I was writing about tanks instead of orcs. You can bitch
and complain all you want that the player has to have his precious control,
you're only posturing for a particular demographic, not all demographics. I'll
grant you: tank rushers ain't gonna dig it. They ain't supposed to.
> I find it quite ironic that you feel this way, because you yourself
> don't like micromanagement. The tedious click-fest that is
> micromanagement is itself a struggle to establish/maintain control!
> If you think control is supposed to already be handed to you on a
> silver platter...well IMHO you're a wuss.
And IMHO a person with that kind of opinion, is a stinking micromanaging
bureaucrat with too much time on his hands. You're probably the same kind of
guy who likes to kill monsters over and over again to run up his stats as high
as he possibly can in an RPG, because it's "fun" to watch numbers turn over.
Other people have got lives, jobs....
I don't *care* what that kind of person wants out of a game. This isn't OS
wars, it's not winner-take-all! They can just go buy someone else's title.
> Actually, I don't think you're a wuss. I just think you don't
> like fighting the game just to control your forces.
I don't like being *bogged down.* At least not as a matter of GUI. If it's
something that the other guy did tactically to me, then I don't like it, but I
accept it as a matter of war.
> What's
> more important, the dislike of micromanaging a large force
> is a common opinion--it's a flaw in many computer wargames
> which isn't apparent at the start (when the forces are small
> and controllable).
>
> At least those wargames get the difficulty curve right--it's
> easier at the start, and then gets progressively more difficult.
> That's a general principle to a fun game.
No, they've got a GUI that doesn't scale. It's not a design virtue.
R Lorber
stands.
Unit AI is combinatrics. You cannot compare 1 unit against another to
determine tactical choices. You also cannot 1 off units against other units
to determine odds (which is essentially what you are doing in the end).
Further, you cannot add up strengths using the above methods to create an
influence map.
Unit AI is the most important thing to determine in a Squad Leader type
game, it is not the level at which you determine your moves. Your moves
should be based on objectives, not destroying other units.
The unit (tactical AI) is the most involving though because of terrain, unit
position and effectiveness (against opposing units). A unit could be good
offensively but bad defensively so they require support units. A counter
that represents a complete Squad with support can be scaled to an individual
soldier (for argument sake) when the other side also has these complete
squad units. So you are back at soldier to soldier tactics and
combinations.
The objectives in wargames are places and not people. The individual
encounters might be about reducing forces though. But in either case unit
AI is of great importance, determining the combinations is a difficult
things to do. I would suggest running simulations of different unit
combinations to determine outcomes which are converted to odds (2-1, 4-2,
etc). Units have basic rules (artillery want to be concealed and in range
and riflemen would want to be at effective range and concealed if possible
to start out as an absolute, but from there things start to degrade). I
think you also have to look at the battlefield as a whole over time and not
localize your engagements unless a battle cannot be joined over past the
time that makes a unit effective in the battle. This would give you a time
frame and pool of combinations to draw from. Choose your units from the
pool by order of objective and have the remaining units in the pool
determine what combination to send on the next objective, etc. By seeing
that the current objective reduces the chances of acquiring later objectives
you can also determine which combinations of units will be effective to take
multiple places.
Having not done squad level AI, there are invariably plenty of things to
consider most of which will not be evident until you see it in the process
of creating the game. Like any other game it is necessary to see examples
in action and build from there. Start with a basic framework and see why it
didn't do what you thought it would and then add tactical savvy until it
looks or plays right.
Sean
"Brandon Van Every" <vane...@3DProgrammer.com> wrote in message
news:jPMi4.5026$lN4.2...@newsread1.prod.itd.earthlink.net...
Rick Craik
>"Rick Craik" <NOSPAM...@ntl.sympatico.ca> wrote in message
news:pLKi4.261
>> Eric said:
>> >
>> >In other words, I think it will be a great learning experience.
>
>Totally agree. And I do want to concentrate more on implementation
>than on theorizing.
[snip]
>Something about this comment makes me think we're not on the same page
>here. If we're discussing my game, I am the game designer. The
>commands listed above are *not* optional, it's what almost every unit
>has to be capable of interpreting.
[snip]
The post was intended to establish a checklist for measuring
"great wargame AI". As a first draft, it happens to line up
along the lines of your design. Design your game as you please,
if it includes all the possible optional features of a wargame AI,
then we will label it a great wargame AI.
I was soliciting for help on any other points not outlined in your
game design. This could relieve the burden of theorizing, and allow
more concentration on implementation.
Yours
Rick
Rick Craik
Brandon Van Every wrote in message
>
>
>> >I believe in delegation, not micromanagement.
>>
>> In most wargames, the gameplay problems of "micromanagement" are
>> avoided simply by keeping the game mechanisms simple. If the
>> player doesn't have control over the exact placement of individual
>> troops, why bother representing them in the game?
>
>Because the player might be able to make logical deductions about
high-level
>interactions on the basis of observing automatic, low-level troop
movements.
>You might call this having an "eye" for the emergent behavior. It is quite
a
>different approach to studying phenomena than saying "well we don't have
>computational resources to represent it, so it's a die roll." Wargames
>historically had die rolls because they could not have possibly done
anything
>else to model complex phenomena.
>
This I like.
Autorun your low-level troops' AI any way you like, but let
me watch. Well, I may want to retreat, recall, surrender
or even offer quarter once in awhile :)
I assume I am watching battles like light calvary and spearmen
versus archers and spearmen. This appeals to the armchair general
in me.
Yours
Rick
Brandon Van Every
"Rick Craik" <NOSPAM...@ntl.sympatico.ca> wrote in message news:7H3j4.52
>
> This I like.
> Autorun your low-level troops' AI any way you like, but let
> me watch. Well, I may want to retreat, recall, surrender
> or even offer quarter once in awhile :)
>
> I assume I am watching battles like light calvary and spearmen
> versus archers and spearmen. This appeals to the armchair general
> in me.
You got it! You understand. If you don't like how it's going, you give a new
order: "Screw this ridge. Go hold *that* ridge, now!!!" And, you plan your
future engagements based on what you learned about how the engagements went in
the past. Leverage your experience.
R Lorber
Sean
"Rick Craik" <NOSPAM...@ntl.sympatico.ca> wrote in message
news:ws6j4.71$sQ1...@198.235.216.4...
>
> R Lorber wrote in message <86iaoi$fr4$1...@bob.news.rcn.net>...
> >I am following this thread to some degree, so I'll just add my opinion as
> it
> >stands.
>
>
> [snip good stuff]
>
> I'm going to try to fit these comments into the second draft of the great
> wargame AI checklist.
>
> Rick
>
>
Peter Cowderoy/PSYCHO
news:3X1j4.4393$bp2.1...@newsread2.prod.itd.earthlink.net...
> *Tangibles*, to me, right now, means: talk to me about urban/jungle
tactics with
> a really foggy command-and-control network. Anything else, frankly right
now I
> don't give a damn. I have a game to write.
>
Hmm, OK. I see three main tasks that troops can be used to perform -
assaulting (including taking people out of cover at short range and simple
short-ranged mass killing), harassing/pinning (ie hindering troops movement
and forcing them to stick to certain areas) and fire support (including
indirect fire, coverbusting and simple long-ranged mass killpower). If you
add in a location to be in and a target, that would probably be an order
system and you could then have your troop types perform each task somewhat
differently. Your circling Orc swarms would be useless at fire support but
they'd probably be good at both harassment in terms of destroying in detail
and assault in order to take people out of cover. But those properties would
be emergent from their circling behaviour. I'm starting to think of
something similar to the formations in Homeworld, only better implemented
(broadly speaking, fixed formations on hotkey which significantly affect
battlefield performance).
> The basic point is that a lot of players don't like taking 1 bullet in the
head
> in the 1st place. They want to be a tank, and Rainbow Six doesn't let you
be a
> tank.
>
Hmm. I know there's a lot of people get irritated in eg Quake 2 when they
get railgunned in the back (I like to be the one with the railgun, but there
you go). OTOH, I think most players can respect a "confrontational" railgun
shot. It's not so much the desire to be a tank as wanting the game to be
about a different set of skills - after all, if you're dodging in Rainbow
Six you've screwed up somewhere. It's just as possible to be on a roll in a
tactical game, you just do it in a different manner.
>"Isaac Kuo" <k...@oldbit.csc.lsu.edu> wrote in message
> > Plain drywall
> > blocks bullets (forcing the players to engage the enemy more
> > aggressively and giving them unrealistic defensive options).
>
> Sounds like a limitation of the simulation complexity, not a "fun" issue.
>
IMO it sounds like both - it's not too hard to make bullets pass through
walls, especially with the 2.5d setup R6 uses. Making the AI do it properly
is a PITA.
> > The AI of the terrorists...well, they don't freak out and go
> > berzerk when another gets shot by a silenced bullet right in
> > front of them.
>
> Sounds like an error of the AI simulation. Doubt it has anything to do
with
> things being "fun." And actually - aren't there different settings for
how the
> AIs react? I'm pretty sure that in the demo I played, if you set the
highest
> difficulty level, when the terrorists hear gunfire they start killing
hostages.
>
There's a difference between that and them charging out all guns blazing,
which could potentially take down one or more team members. It could be like
when you try and pin a large squad in cover with a smaller one - as soon as
the mortars show up the pinned squad's gonna charge the smaller one and
they're gonna get their asses kicked.
> And proof-by-Syndicate doesn't say anything
> about why it was a successfully selling title, only that it sold
successfully,
> by *your* measure of success. Who knows? Maybe people liked the eye
candy or
> something. Maybe they liked the concept enough to buy it and not return
it for
> 2 weeks, but it fell short for them after that. Sales = you suckered
someone
> into plunking down the dough for it, not that you proved you had The One
True
> Game Design Approach.
>
I'd say it was mostly about atmosphere. That and the fact there weren't too
many games about at the time where you could take a flamethrower to a crowd
of civilians while there's a parade on.
> And IMHO a person with that kind of opinion, is a stinking micromanaging
> bureaucrat with too much time on his hands.
Uh, thanks :-( Micromanagement in RTS tends to end up as the equivalent of a
damn good snap-shot aim in an FPS - it makes a large difference but has to
be done pretty much on instinct. That said, I'm talking about the really
low-level stuff. Positioning defense turrets doesn't come under that
category, a quick move that gives your unit of flyers the initiative against
the exact duplicate wing of incoming enemy flyers is. That's one of the
critical differences between TBT and RTS - it's easier to get an adrenaline
rush from a tight assault in an RTS.
> You're probably the same kind of
> guy who likes to kill monsters over and over again to run up his stats as
high
> as he possibly can in an RPG, because it's "fun" to watch numbers turn
over.
> Other people have got lives, jobs....
>
Heh. Just remember that RT and TB micromanagement are very different things.
For starters, in an RT game the situations where it's absolutely neccesary
tend to be ones where you'd expect it - the commando mission from C&C has a
lot to answer for.
> I don't like being *bogged down.* At least not as a matter of GUI. If
it's
> something that the other guy did tactically to me, then I don't like it,
but I
> accept it as a matter of war.
>
The usual paradigm in RTS is to group up units and issue general orders
(this may involve banging a hotkey and clicking the mouse once for each
squad involved), and then hand out specific orders afterwards. So you
maintain a strategic control and then micromanage critical sections to get
an edge in your attack or whatever.
> > At least those wargames get the difficulty curve right--it's
> > easier at the start, and then gets progressively more difficult.
> > That's a general principle to a fun game.
>
> No, they've got a GUI that doesn't scale. It's not a design virtue.
>
Agreed. In one sense, Starcraft's unit limit is a very good thing in that
it's low enough that you can manage everything within the selection limit.
As it is, there are times I'd kill to have a hierarchy for hotkeyed squads.
--------------------------------------------------
psy...@cowderoy.co.uk
'In Ankh-Morpork even the shit have a street to itself...
Truly this is a land of opportunity.' - Detritus, Men at Arms
Rick Craik
it
>stands.
tel...@xenon.triode.net.au
> stick it on the net. But it's not going to be a full-blown commercial glitz
> title. Sometime this calendar year. It'll be either free (closed source,
> sorry) or very cheap, since it won't be full budget and I want people to play
> it, to test the theory. I just want to try to get some basic gameplay correct,
> and particularly my software rasterization background, I feel very confident
> about the low-level bit set processing stuff. I can make that go really fast.
I would suggest using an ASCII console as interface. It is very fast, easy to
code, and no one can suggest that the CPU resources are being wasted by a 3d
engine. Have a look at the many rogue-like games. Also, portability should be
no great problem. After all, this is an AI exercise, restrict yourself to ASCII
and give no other option except working on the AI (and the rules of course).
>> I just scanned your bitch list. I think you are refering to what is really
>> called a RTS or RTT game, and not a wargame.
> True, it's a RTT. Some people think "wargame" is a generic term, other people
> focus it more specifically. For clarity, I'll just call it a RTT.
Yeah, wargame sounds a bit like it is a game about war...
>> On an RTS or RTT basis however, I agree with you, that the strategies
>> are shallow in most of these types of games. I think this is partially due
>> to the "real time" aspect of the game, not giving a (human) player a chance
>> to actually think through what they want to do in a given move.
I see it as greatly related to AI. I was playing Myth a few times and came away
very upset that a game can have such a cool graphics engine and still be close
to unplayable. Aside from the pain-in-the-arse camera angle that is never where
you want it to be and requires about 15 keys to readjust it, the unit-AI is so
stupid that you cannot use any strategy other than ``buy the strongest troops
you can get and run them around in a big bunch''. Some particular complaints:
* The spiders are small, fast, all-terrain and weak. Logic says that they be
used as scouts or spies. Can you tell them to keep visual contact with the
enemy? Can you tell them to keep just out of bow range? Can you tell them
to run away when threatened (preferably run over terrain that others cant
cross)? No to all questions. All you can do is drive them around by hand,
which is fine if you don't have anything else to do.
* Various troops have ``special moves'' which require a combination of key
press and mouse to activate. They will never use special moves for themselves
so once again, if you want your unit to fight properly you have to drive it
all around by hand once more.
* Archers don't know about cover. You cannot instruct any of your ranged-weapon
units to take a shot then step behind cover to reload. Thus, moving them to
positions where there is good cover is useless unless you drive the unit out
of cover, instruct it to shoot, then drive it back under cover again -- gee
I seem to need to drive the units by hand again!
* Units don't recognise their own range and reload times, often a wizard can
fire an effective shot but won't do it until an opponent is closer. Since
the wizard unit has massive offense and no defense it makes sense to fire
as soon as possible because you may not get another chance.
Thus, the game requires making every decision for every unit all the time.
>> Micromanagement is a game design issue and not an AI issue.
Yes it is, the reason micromanagement becomes an issue at all is because each
unit is so stupid that the player must drive them by hand to get reasonable
results. Improve the unit AI and you leave the player free to think about the
bigger picture.
> Well, one way I could answer that is yes, you're absolutely right. And my list
> wasn't solely one of AI issues.
> Or, I could say I disagree, and that micromanagement overburdens what an AI (and
> a human!) have to think about. Your choice, either way. Extrapolate as needed.
Well either way, any game that comes down to the player performing constant
micromanagement of the units is a sucky game. If the player is expected to
manage more than about 5 units and still must specify every move and every
firing action then the game is unplayable.
>> I agree
>> that any good "wargame" (or RTS or RTT), needs to have as a part of
>> it, good "unit AI". I think the problem most developers of RTS/RTT
>> games that display "dumb" unit AI have, is that it is _extremely_ difficult
>> to design and implement a compact and fast "unit AI" that can deal with
>> the wide range of situations a given unit must deal with.
Then provide a bigger spectrum of commands so that the player can give the
unit a few ideas of what to do. Another option is making the units learn from
being driven around so that after the player has been through a few games, the
units get the general idea of what is expected from them. Even a little thought
by the game designer as to what units might typically be used for would be
a good idea.
> Sometimes I think we may make something too hard that is really very simple.
> Something shoots at you, find cover! Then shoot back. If there's too many of
> 'em, and you're not scared yet, make an orderly retreat. If you're scared, run
> like hell. There are some group tactics to consider here, but really, fighting
> is not something you can predict. It's not this clockwork thing. In the
> Russian marital art style that I practice, we always do exercises where 3 people
> are beating on you. You can't possibly know where 6 pairs of arms are going to
> be! You have to avoid, develop sensitivity, and counterattack. No time to
> think. Technique is something you learn in order to forget.
I agree here, a few general rules that allow a unit to prolong its own survival
would make a huge difference to the game.
>> We (as computer game AI developers, of which I have been professionally
>> since 1987) have to face the fact the "unit AI" still resolves down to what
>> each unit must do, on the very next cycle/move/phase/whatever. That level
>> of discrete decision-making takes significant cycles (depending on the game
>> and its depth - ie. the problem space) to accomplish. In "real time" games,
>> those cycles are not always available, despite the fact that the "problem"
>> can actually be solved (given sufficient time).
How difficult it is to say, ``I have just fired, I must reload, thus I have
zero offensive capability and I'm a sitting duck for the next 3 seconds''?
Even dead simple things like, ``I just got hit by that unit, thus it can
see me'' or ``I have a shorter range than my opponent so I want to be either
very close or a long way off but never part way in between''.
Units should also have some idea whether they are going to win or lose before
they get into a fight. Unless their orders explicitly state that they must
fight, they should avoid any encounter that they don't expect to win. This
could easily be implemented by just scanning out the good guys and bad guys in
the local area, counting up how many points of offense and defense are on both
sides and feeding that to some probability curve that has been worked out
by repeated simulation a long time earlier. OK, sometimes this sort of guess
will be wrong, but mostly it gives the units something pratcical to use.
- Tel
Brandon Van Every
<tel...@xenon.triode.net.au> wrote in message
news:86jc4s$62r$1...@hyperion.triode.net.au...
> > Assuming I start... this weekend... I could make no promises about when I'd
> > stick it on the net. But it's not going to be a full-blown commercial glitz
> > title. Sometime this calendar year. It'll be either free (closed source,
> > sorry) or very cheap, since it won't be full budget and I want people to
play
> > it, to test the theory. I just want to try to get some basic gameplay
correct,
> > because it'll be the 1st time I've ever attempted AI. Owing to my 3D
graphics
> > and particularly my software rasterization background, I feel very confident
> > about the low-level bit set processing stuff. I can make that go really
fast.
>
> I would suggest using an ASCII console as interface. It is very fast, easy to
> code, and no one can suggest that the CPU resources are being wasted by a 3d
> engine. Have a look at the many rogue-like games.
Ack, noooooooooo! Aside from my sheer, utter, and complete unwillingness to do
such a thing, doing it in at least a 2D rasterization mode leverages all my
previous experience in 3D software rasterization.
> Also, portability should be no great problem.
Once upon a time I wrote a 3D graphics library so portable that it would run on
every machine ever made - at the cost of barely rendering a single polygon! Not
due to speed, I solved speed pretty well, but due to the incredible amounts of
time I wasted worrying about portability and mondo cool class architectures.
Version 1.0 will simply be a DirectX app. I'll worry about portability if
there's a Version 2.0. A V2.0 would have a much more serious art committment to
it, and would be a full-blown commercial title. I see that as a loooooong way
off yet, I'm not planning on surprising myself.
> * The spiders are small, fast, all-terrain and weak. Logic says that they be
> used as scouts or spies. Can you tell them to keep visual contact with the
> enemy? Can you tell them to keep just out of bow range? Can you tell them
> to run away when threatened (preferably run over terrain that others cant
> cross)? No to all questions. All you can do is drive them around by hand,
> which is fine if you don't have anything else to do.
I would not intend to ever have such a problem in my game. I would intend that
archers either ambush their targers, or be fleeter of foot for tagging an enemy
trying to get away, or waiting and holding for the right moment to let loose.
I'd assume that an enemy aware of archers is going to try to get away, or flank
through cover, etc. In other words, if unit AIs are doing something stupid, I'd
consider that a bug.
> * Various troops have ``special moves'' which require a combination of key
> press and mouse to activate. They will never use special moves for
themselves
> so once again, if you want your unit to fight properly you have to drive it
> all around by hand once more.
Definitely not the sort of GUI I'd ever implement.
> * Archers don't know about cover. You cannot instruct any of your
ranged-weapon
> units to take a shot then step behind cover to reload. Thus, moving them to
> positions where there is good cover is useless unless you drive the unit out
> of cover, instruct it to shoot, then drive it back under cover again -- gee
> I seem to need to drive the units by hand again!
My units will do this automatically - in fact, they'll fire from cover in the
first place if at all possible. Arrow slits, canopy of tree....
> * Units don't recognise their own range and reload times, often a wizard can
> fire an effective shot but won't do it until an opponent is closer. Since
> the wizard unit has massive offense and no defense it makes sense to fire
> as soon as possible because you may not get another chance.
Definitely something units should be aware of. However, I'd point out that real
firing effectiveness can break down in combat, if the creature gets panicked.
Or, if the creature isn't that good at estimating the speed of a closing enemy.
> Well either way, any game that comes down to the player performing constant
> micromanagement of the units is a sucky game.
My sentiments exactly. I like it when I turn on computer vs. computer and watch
all the ants kill each other. I don't like it when the ants kill each other in
a boring, stupid way. Or worse, don't even know how to kill each other!
tel...@xenon.triode.net.au
> You could try to make an open conceptual framework for "anybody's game," as
> opposed to my game. With option switches and all of that. But, from my
> standpoint, that's a complete waste of time both design-wise and
> implementation-wise. My experience from writing 3D device drivers is that all
> the silly option flags are death. You cannot support all those silly option
> flags well. What you need to do, is decide exactly what you intend to support
> well, and then hardwire the system to do it.
Hey! Don't make a decision, make it configurable...
How could all those X11 developers be wrong?
- Tel
tel...@xenon.triode.net.au
> avoided simply by keeping the game mechanisms simple. If the
> player doesn't have control over the exact placement of individual
> troops, why bother representing them in the game?
The point is that the game dynamics is driven by a lot of small events,
(far more than the player can comprehend) but the player can influence
those small events by giving high level orders. I agree that you could
map the high level orders directly to success or failure but then you
have a game which is just a lookup into a probability table. By simulating
all the little events you produce a far larger diversity of outcomes.
>>"Fun" is something totally in your prejudiced imagination, until
>>you've actually played a game.
> Nonsense. You can talk about what's fun and not in theory as
> well as practice.
Using the FUNdamental principles of entertainment calculus, we can derive
a unique constant expression for ... waffle waffle ... taking only the first
two terms of the infinite series .. waffle waffle ... resulting in a predicate
that links the ... waffle waffle ... no fun at all! Q. E. D.
Errr yes, as our expensively purchased market research adequately demonstrates,
no one has ... puff puff ... invented a new game since Pac-Man and as chief
strategic visionary for ... puff puff ... ``Ultimate Games, Wow, Awesome,
Amazing, Pty Ltd'' it would never suit out ultra-conservative management style
to be doing anything that hasn't been tried before. Frankly, if a game isn't
fun today, it's not likely to be fun tomorrow -- and if it doesn't even exist
today, how much fun can that be?
>>Then again, these might just be flimsy excuses against tackling the hard game
>>design problems of greater realism.
> It's not a flimsy excuse. I think it's a brilliant way to solve
> the problem of balancing realism with playability. Instead
> of fixing a premise and looking at what's realistic vs what's
> playable, figure out what's playable, and find a premise which
> makes it realistic.
I have a premise, you are a person who pays money to take this CD home
and put it into your computer. You better enjoy it because you will feel
rather foolish if you don't. Tell your friends you enjoyed it or they will
realise what a git you are.
Is it just me or does anyone else notice how many games use this premise?
For some people, gameplay is everything... the premise is usually a tacky
story anyhow, anyone can buy a cheap railway paperback and get a better
storyline. The game tokens can be blazing animated graphics or circles and
squares and it makes not a bean of difference if gameplay is what matters
to you.
> Remember the basics of a fun game--the player must be able to
> make decisions and those decisions must count. A player who
> feels he isn't getting enough information and/or can't control
> his situation will get frustrated because he either can't make
> meaningful decisions.
Depends entirely on the player. What motivates physicists to study
particles or fields they can never see directly but can at best measure
some secondary effect of? What motivates economists to gamble on the
stock market and go to great lengths to attempt to understand something
that is chaotic in the extreme? Why did players of Doom go and find
all those secret areas? Maybe half the game is figuring out how to
collect information...
- Tel
Brian Gantt
On the issue of micro-management:
The balancing of micro-management vs. lack of control is a tricky issue. On
the one hand you don't want to have to baby-sit each unit. (And in real-time
it becomes near impossible to do so as the unit count goes up) on other you
don't want to be stuck with commanders that won't or can't do what you want
them to do. I like the chain of command structure for this problem, where
you can give high-level orders to company commanders, or go down the chain
and give direct orders to individual squads or units. This way you can
mostly give high level orders but micro-manage where you want to.
Of course saying you're going have high-level orders such as "take this
bridge" and actually implementing then are two different things. The most
I've seen so far in any real-time game is the ability to group units
together for movement purposes.
Virgil
Brandon Van Every <vane...@3DProgrammer.com> wrote in message
> But one of the fundamental principles, is every new
> unit type should fight very, very differently from other unit types.
Whether as
> a matter of basic tactics, or fundamental nature of movement (flocking
swarms
> vs. single thieves sneaking, for instance). I really hate units that are
just
> statistically better or statistically worse than some other unit. Doesn't
> contribute to having different ways to win the game, it just makes "force"
the
> measure of whether or not you'll win.
>
- troops that form a wedge to channel attacking power through one unit at
the apex (see the Thomas Covenant books for example)
- high defensive formations like phalanx - where the overlapping of shields
increases the defence coverage of all troops
- troops that use the environment as part of their attack - eg a giant that
uproots trees or lifts large rocks to use as projectiles
Virgil
Bjorn Reese
> *Tangibles*, to me, right now, means: talk to me about urban/jungle tactics with
> a really foggy command-and-control network. Anything else, frankly right now I
Read "Sun Tzu" (there are several on-line versions available)
Peter Cowderoy/PSYCHO
Bjorn Reese <bre...@mail1.stofanet.dk> wrote in message
news:388DD7C3...@mail1.stofanet.dk...
> Brandon Van Every wrote:
>
> > *Tangibles*, to me, right now, means: talk to me about urban/jungle
tactics with
> > a really foggy command-and-control network. Anything else, frankly
right now I
>
Which doesn't have much to say about what Brandon's asking about. The Art of
War is great for an introduction to the mindset, it sucks in terms of
applicable tactics because it's too broad. A worthwhile read if you haven't
touched it before though.
Brandon Van Every
<tel...@xenon.triode.net.au> wrote in message
news:86jkhj$ogc$1...@hyperion.triode.net.au...
>
> > You could try to make an open conceptual framework for "anybody's game," as
> > opposed to my game. With option switches and all of that. But, from my
> > standpoint, that's a complete waste of time both design-wise and
> > implementation-wise. My experience from writing 3D device drivers is that
all
> > the silly option flags are death. You cannot support all those silly option
> > flags well. What you need to do, is decide exactly what you intend to
support
> > well, and then hardwire the system to do it.
>
> How could all those X11 developers be wrong?
Seeing how that Free3D library I tried to write once upon a time used X11 as its
home system, and was still portable to every other system ever made, I am quite
confident that infinite configurability is vastly, vastly overrated. I think I
am agreeing with your sarcasm. :-)
Brandon Van Every
"Virgil" <vir...@N.O.S.P.A.M.danniis-sister.com> wrote in message
> Have you considered other group tactics such as:
> - troops that form a wedge to channel attacking power through one unit at
> the apex (see the Thomas Covenant books for example)
Hadn't.
> - high defensive formations like phalanx - where the overlapping of shields
> increases the defence coverage of all troops
Had. I don't think it'll come up often because it's a dungeon. Not much room
to move.
> - troops that use the environment as part of their attack - eg a giant that
> uproots trees or lifts large rocks to use as projectiles
Hadn't.
Interesting suggestions. And it's true, such things would very much change the
tactics of different unit types.
Brandon Van Every
"Bjorn Reese" <bre...@mail1.stofanet.dk> wrote in message
news:388DD7C3...@mail1.stofanet.dk...
> Brandon Van Every wrote:
>
with
> > a really foggy command-and-control network. Anything else, frankly right
now I
>
Hmm yeah I guess he did have some good things to say, although I'd paid more
attention to his diplomatic/political stuff than his stuff about what to do on
particular kinds of ground.
Peter Cowderoy/PSYCHO
Brandon Van Every <vane...@3DProgrammer.com> wrote in message
news:aOpj4.609$Wy5....@newsread1.prod.itd.earthlink.net...
>
> "Bjorn Reese" <bre...@mail1.stofanet.dk> wrote in message
> news:388DD7C3...@mail1.stofanet.dk...
> > Brandon Van Every wrote:
> >
tactics
> with
> > > a really foggy command-and-control network. Anything else, frankly
right
> now I
> >
>
> Hmm yeah I guess he did have some good things to say, although I'd paid
more
> attention to his diplomatic/political stuff than his stuff about what to
do on
> particular kinds of ground.
I think most of the comments there become a little harder to directly apply
once you get below the high-strategic scale (eg when talking about buildings
instead of cities). More room for random, and thus more need to account for
it. Not to mention the fact that the type of terrain changes from unit to
unit...
At that scale I work on three rules of thumb and work out all the specifics
on the spot. You can probably guess those rules of thumb, so I guess the
trick would be to have a fixed way of evaluating them.
Rick Craik
"A great wargame AI will have some interpretation of orders and
application of control to lower ordered sub-units." [Eric]
The following is a great wargame AI checklist (2nd draft).
Note:
The document consists of two sections, the first section
concerns input and output, and the second is processing.
Numbered list items suggest a definitive list may be possible.
1 INTERPRETATION OF ORDERS
The issuing of operational commands should be simple.
Depending on the Level of Detailed Operation (LoDO), interpretation
of orders may range from simple to complex.
1.1 LIST OF AI TECHNOLOGY
1.1.1 Path Finding: How to move unit(s)
1.1.2 Navigation: How to effectively move unit(s)
1.1.3 Loyalty: How well would units carry out orders.
1.1.4 Morale: How well could units carry out orders.
1.1.5 Grouping: How to place and move multiple units.
1.1.6 Disengagement: How unit(s) withdraw.
1.1.7 Engagement: How unit(s) attack.
1.1.8 Cover: How unit(s) interact with special terrain.
1.1.9 Specialist: How unit(s) perform unusual tasks.
1.2 LIST OF OPERATIONAL COMMANDS:
Move, Stop, Attack, Defend.
Retreat, Conceal, Harass, Maintain contact, Ambush, Stall, Flank,
Search and Destroy.
Snipe, Build walls, Skulk / Infiltrate, Observe, Dig tunnels.
Staggered defense, Column, Rank, Wedge.
1.2.1 Required Operational Commands
These are fundamental instructions that all units should understand.
Actual Operational Commands are some variant of these.
[Move, Stop, Attack, Defend]
Wargame AI requirements for these commands may be;
a) Path Finding: How to move unit(s)
How to move a unit from point to point. Considers obstacles
and terrain movement costs.
b) Navigation: How to effectively move unit(s).
[No-go zones, waypoints, LOS, maintain formation]
May consider enemy influence.
c) Loyalty: How well would units carry out orders.
[Conscripts, mercenaries, fanatics, animals, chain of command]
Define different unit types.
d) Morale: How well could units carry out orders.
[Fatigue, casualties]
Requires knowledge of friendly and enemy capabilities and
probable battle outcome.
e) Grouping: How to place and move multiple units.
[Stacks, form squad, swarming]
Establish basic formations.
1.2.2 Featured Operational Commands
These are optional concepts used at the discretion of the game
designer.
[Retreat, Conceal, Harass, Maintain contact, Ambush, Stall, Flank,
Search and Destroy]
Wargame AI requirements for these commands may be;
a) Disengagement: How unit(s) withdraws.
[Retreating, a rout, disbanding, surrender, disertion]
A complete range of fundamental AI could be used here.
None -> fight to death, or battle over.
Morale, Loyalty -> for a trigger.
Path Finding -> for a rout.
Navigation, Grouping -> organized retreat.
b) Cover: How unit(s) interact with special terrain.
[Conceal, hide]
Path Finding, Navigation -> get to cover.
Can unit(s) shoot through cover, shoot from cover.
Could enhance Morale and Navigation AI.
c) Engagement: How unit(s) attack.
[Maintain contact, Harass, Search and Destroy, Ambush, Stall,
Flank]
A complete range of fundamental AI could be used here.
None -> dumb as rocks.
Path Finding -> basic.
Navigation -> some suprise, maintain contact, Search and Destroy.
Loyalty, Morale -> may not engage, beserker.
Cover -> Ambush
Grouping -> Flank
Disengagement -> Harass
1.2.3 Unit Specific Commands
[Snipe, Build walls, Skulk / infiltrate, Observe, Dig tunnels]
a) Specialist: How unit(s) perform unusual tasks.
Cover -> observer
Navigation -> scouting
1.2.4 Formation Commands
Interpretation of Operational Commands is varied.
[staggered defense, Column, Rank, Wedge]
These commands require wargame AI for;
a) Advanced Grouping (Stationary and Mobile)
Requires proper deployment of units. If moving, how to thread a
bottleneck. How and when to scatter. How to march in formation.
How to attack in formation. Dungeon crawling.
b) Swarming
Simple unit to unit rules exhibit desirable emergent behaviours.
2 APPLICATION OF CONTROL
Here the great wargame AI is given an operational command and
has resources to carry out the command.
2.1 LIST OF AI DATA
2.1.1 Position: communication, formation
2.1.2 Colors: neutrals, enemies, friends, allies
2.1.2 Terrain Cost: terrain versus locomotion
2.1.3 Unit Moves: speed, locomotion
2.1.4 Unit Attack: range, weapon, area of affect
2.1.5 Targeting: which objects to attack
2.1.6 Unit Defend: armour, armour versus weapon
2.1.7 Terrain LoS: blocks Line of Sight, height, range bonus
2.1.8 Terrain Cover: armour bonus, armour versus weapon
2.1.9 Order of Battle: unit pool
2.1.10 Effectiveness: unit versus unit
2.1.11 Objectives: victory conditions
2.2 LIST OF AI TECHNOLOGY
Recognition: friend or foe
Self-Aware: What ever that means :)
...?
2.3 LIST OF CONTROL DECISIONS
"The objectives in wargames are places and not people.
The individual encounters might be about reducing forces."
[Sean]
These decisions are about objectives and unit effectiveness.
Goal: Has unit accomplished goal?
Combatant: Can unit have a target?
Targeting: Does unit have a target?
In Range: Can unit reach target?
Effectiveness: Can unit damage target?
...?
2.3.1 Required Control Decisions
These decisions could be made by all units:
[rules of engagement, target acquisition]
Some basic wargame AI requirements would be:
a) Recognition: friend or foe
b) Position: communication, formation
...?
2.3.2 Featured Control Decisions
...?
2.2.3 Specific Control Decisions
...?
Rick Craik
Didn't quite make it. Need help. I laid out some basic data, and
decisions hoping to work my way up to your level of control decisions. I'll
work on it some more, but posted what I had done so far. I am going to be
occupied for the next couple days on other things ...
Yours,
Rick
R Lorber wrote in message <86iu2r$8h7$1...@bob.news.rcn.net>...
>Great. Thank you.
>
>Sean
>"Rick Craik" <NOSPAM...@ntl.sympatico.ca> wrote in message
>news:ws6j4.71$sQ1...@198.235.216.4...
>>
>> R Lorber wrote in message <86iaoi$fr4$1...@bob.news.rcn.net>...
>> >I am following this thread to some degree, so I'll just add my opinion
as
>> it
>> >stands.
>>
>>
R Lorber
That's ok, but the decisions are basically odds and objective point value
based. Finding those odds are the really difficult part.
Sean
"Rick Craik" <NOSPAM...@ntl.sympatico.ca> wrote in message
news:h2Mj4.197$kJ6...@198.235.216.4...
> Hi Sean;
>
> Didn't quite make it. Need help. I laid out some basic data, and
> decisions hoping to work my way up to your level of control decisions.
I'll
> work on it some more, but posted what I had done so far. I am going to be
> occupied for the next couple days on other things ...
>
> Yours,
> Rick
>
>
> R Lorber wrote in message <86iu2r$8h7$1...@bob.news.rcn.net>...
> >Great. Thank you.
> >
> >Sean
> >"Rick Craik" <NOSPAM...@ntl.sympatico.ca> wrote in message
> >news:ws6j4.71$sQ1...@198.235.216.4...
> >>
> >> R Lorber wrote in message <86iaoi$fr4$1...@bob.news.rcn.net>...
> >> >I am following this thread to some degree, so I'll just add my opinion
> as
> >> it
> >> >stands.
> >>
> >>
Rick Craik
R Lorber wrote in message <86ojgd$2su$1...@bob.news.rcn.net>...
>Rick,
>
>That's ok, but the decisions are basically odds and objective point value
>based. Finding those odds are the really difficult part.
It seems that my point of view from the checklist is
more along the lines of what you are doing, and not
how you are doing it. But it may be necessary for you to describe
how you are doing it, so I can describe what you are doing.
Make any sense?
A clipping from your previous post:
>A counter that represents a complete Squad with support can be scaled
>to an individual soldier (for argument sake) when the other side also
>has these complete squad units.
Scaling, this can be part of analogical reasoning, or pattern
recognition. For example, given; a squad of infantry, a squad of
bowmen and a squad of artillery. Is this a scaled up version of an
adventure party consisting of a fighter (infantry), an archer (bowmen)
and a spell caster (artillery). I understand that this is not exactly
the situation your describing, but it can be useful in accounting for
some AI tactical savvy.
So now, in the checklist, do I say you used, Pattern Recognition,
Scaling, or Analogical reasoning, a classification system?
Then again, you have used it as preprocessor to build your odds
tables. But somewhere, during gameplay, you must do your scaling
again in order to use the tables properly.
Would you have a nice word or two handy for describing this process
of identifying and scaling squads of units to find proper look-up
table indices? So then the checklist can point out that the AI
recognizes basic classes of tactical groups and makes rational
tactical decisions.
(Achieving objectives is a whole other process that depends upon
this AI technology described above, so I would like to get a
handle on this part first. But a wargame could be designed without
an objective oriented process, so it is reasonalble that the two
proceses are separatly described.)
Tanks for your time,
Rick
>
>Sean
>
>"Rick Craik" <NOSPAM...@ntl.sympatico.ca> wrote in message
R Lorber
> Hi Sean;
>
> R Lorber wrote in message <86ojgd$2su$1...@bob.news.rcn.net>...
> >Rick,
> >
> >That's ok, but the decisions are basically odds and objective point value
> >based. Finding those odds are the really difficult part.
>
>
> It seems that my point of view from the checklist is
> more along the lines of what you are doing, and not
> how you are doing it. But it may be necessary for you to describe
> how you are doing it, so I can describe what you are doing.
> Make any sense?
>
get that info you need to know how the battle plays out.
> A clipping from your previous post:
> >A counter that represents a complete Squad with support can be scaled
> >to an individual soldier (for argument sake) when the other side also
> >has these complete squad units.
>
> Scaling, this can be part of analogical reasoning, or pattern
> recognition. For example, given; a squad of infantry, a squad of
> bowmen and a squad of artillery. Is this a scaled up version of an
> adventure party consisting of a fighter (infantry), an archer (bowmen)
> and a spell caster (artillery). I understand that this is not exactly
> the situation your describing, but it can be useful in accounting for
> some AI tactical savvy.
>
I made the mistake of saying that a squad at the level we were discussing
(man to man) contained support units which they don't. I think the scaling
applies to much bigger units like entire armies verses armies or fleets
verses fleets. They have all the support units built in, so to get odds you
just have to add up your armies against his armies (the estimate you are
getting anyway) as long as you have a time frame and there are no terrain
modifiers to give 1 an advantage over another. What I really think is
important about scaling is that an AI programmer need not worry about the
units and capabilities if the units are of the same type and strength, the
only determining factors are terrain and timing. I once responded to a post
where someone was writing some sort of squad level wargame in which he kept
heaping capabilites on units (both sides). So you would have tanks, then
later on tanks with reactive armor, etc. If both sides are the same, then
you are back to just tanks, no matter how many capabilities they both have.
They cancel each other out and you are left with the basic factors again
tank verses tank scaled back to 1 on 1. If one side had more capabilites
then you could no longer cancel directly but that's not how odds are
ultimatly determined anyway, they are determined by playing out the battle,
which also doesn't determine odds really, just win or lose and units
destroyed.
> So now, in the checklist, do I say you used, Pattern Recognition,
> Scaling, or Analogical reasoning, a classification system?
> Then again, you have used it as preprocessor to build your odds
> tables. But somewhere, during gameplay, you must do your scaling
> again in order to use the tables properly.
>
> Would you have a nice word or two handy for describing this process
> of identifying and scaling squads of units to find proper look-up
> table indices? So then the checklist can point out that the AI
> recognizes basic classes of tactical groups and makes rational
> tactical decisions.
>
> (Achieving objectives is a whole other process that depends upon
> this AI technology described above, so I would like to get a
> handle on this part first. But a wargame could be designed without
> an objective oriented process, so it is reasonalble that the two
> proceses are separatly described.)
>
I would start with objectives and work your way down to tactics and this is
why. Your program would start out getting unreasonable odds, but so what.
If it is basing its decsions on this (plus victory points for achieving the
actual objective) then from this frame you can hone your odds determining
capability by doing work on the tactics. But in this basic framework, the
timing is worked out (no matter how wrong the odds estimates are) and that's
at least half the problem. When I say timing, I mean the pool of units that
are alloted to be in the battle of a period of time, from that pool (who is
engaged) you can simulate a battle, know what resources are left and choose
the next objective.
> Tanks for your time,
lol. You're welcome!
> Rick
>
> >
> >Sean
> >
> >"Rick Craik" <NOSPAM...@ntl.sympatico.ca> wrote in message
R Lorber
>
> R Lorber wrote in message <86qa02$82d$1...@bob.news.rcn.net>...
> >> Hi Sean;
> >>
> >> R Lorber wrote in message <86ojgd$2su$1...@bob.news.rcn.net>...
> >> >Rick,
> >> >
> >> >That's ok, but the decisions are basically odds and objective point
> value
> >> >based. Finding those odds are the really difficult part.
> >>
> >>
> >> It seems that my point of view from the checklist is
> >> more along the lines of what you are doing, and not
> >> how you are doing it.
> >>
> >How you are getting those odds would describe what you are doing because
to
> >get that info you need to know how the battle plays out.
>
>
> and determining which odds to access in gameplay:
>
> a) Identification
> b) Classification
> c) Scaling
> d) Create or Access Simulation data
>
>
Hmmm. No scaling or classification because in my scheme it would just play
it out to determine outcome.
Identification is good, you would want to know what units were going to meet
you. The simulation data is the units you are estimating are going to be
part of the battle.
I would start both sides (or multiple sides if the game supports more then 2
players) start with absolutes, meaning that opponents will target objectives
as if they were facing worst case scenarios. This way it will devote all or
most resources to securing 1 objective. Then, using this data plug it into
the next round as real current estimates and repeat (do this for all
opponets) After a few rounds of this, decent estimates should appear.
Sean
> [snip undigested food for thought]
>
> Rick
>
>
Rick Craik
>> Hi Sean;
>>
>> R Lorber wrote in message <86ojgd$2su$1...@bob.news.rcn.net>...
>> >Rick,
>> >
>> >That's ok, but the decisions are basically odds and objective point
value
>> >based. Finding those odds are the really difficult part.
>>
>>
>> It seems that my point of view from the checklist is
>> more along the lines of what you are doing, and not
>> how you are doing it.
[snip]
>>
>How you are getting those odds would describe what you are doing because to
>get that info you need to know how the battle plays out.
OK, so how about these four processes are needed for odds creation
and determining which odds to access in gameplay:
a) Identification
b) Classification
c) Scaling
d) Create or Access Simulation data
Rick Craik
[snip
>> OK, so how about these four processes are needed for odds creation
>> and determining which odds to access in gameplay:
>>
>> a) Identification
>> b) Classification
>> c) Scaling
>> d) Create or Access Simulation data
>>
>>
>Hmmm. No scaling or classification because in my scheme it would just play
>it out to determine outcome.
Sorry, I made an assumption there that I shouldn't have. So I will refrain
from any procedural analysis in the future when describing a list of
techniques. All I am interested in, for the great wargame AI checklist, is
the lists of AI techniques. If you used classification of units at least
once, then it goes on the list. If you scaled these classified units once,
it goes on the list. You, as the programmer, or as the game designer,
decide what is useful to your current design.
So moving along ...
Given the above list of techniques of assessing units, AI decisions
could be made:
- at the tactical level, the simulation data could be used to affect
morale.
- at the strategic level, the same data could be used for a battle plan.
>
>Identification is good, you would want to know what units were going to
>meet you. The simulation data is the units you are estimating are
>going to be part of the battle.
>
>I would start both sides (or multiple sides if the game supports more
>then 2 players) start with absolutes, meaning that opponents will
>target objectives as if they were facing worst case scenarios.
>This way it will devote all or most resources to securing 1 objective.
>Then, using this data plug it into the next round as real current
>estimates and repeat (do this for all opponets) After a few rounds
>of this, decent estimates should appear.
Alrighty then, you have just described HOW you would do something.
But WHAT is it you are doing? It seems to be some sort of goal seeking
technique. Can we have a nice word or two to describe this?
But for now I think I will back-track a bit and review your
"Time and Terrain" battle plan issues ...
Say you had 150 tank units per side, but the enemy had positioned them
as 50 top left, 50 top center and 50 top right. Your units were all bottom
center. Remove the time element by saying all units move at the same
speed, terrain is flat, etc. Do you apply any intelligence to this
situation? (I assume I am tackling the terrain issue here.)
Tanks, tanks, tanks
Rick
Wim Libaers
Brandon Van Every <vane...@3DProgrammer.com> schreef in berichtnieuws
3X1j4.4393$bp2.1...@newsread2.prod.itd.earthlink.net...
[...]
> > What's
> > more important, the dislike of micromanaging a large force
> > is a common opinion--it's a flaw in many computer wargames
> > which isn't apparent at the start (when the forces are small
> > and controllable).
> >
> > At least those wargames get the difficulty curve right--it's
> > easier at the start, and then gets progressively more difficult.
> > That's a general principle to a fun game.
>
> No, they've got a GUI that doesn't scale. It's not a design virtue.
Exactly. This was exactly what caused me to stop playing Dark Reign about
halfway through the game. Your units are dumb, very dumb. If one of them is
being killed, the one right next to it doesn't even move. All is fine as
long as you have one force you can keep on the screen, or you have plenty of
resources so you can afford some losses due to bad coordination. And then
you suddenly get to the point where you're expected to take over two bridges
over a river, with your base and resources halfway between the bridges. Then
you get a three-front war with two "supply routes" for new units on their
way to the bridges, and because you can't babysit every area along the front
line you lose against smaller groups of enemies, because the computer can
micromanage everything everywhere.
I hate it when such things happen.
The worst thing probably is that you have already bought it, and these kinds
of problems don't usually appear until you're quite far into the game. Of
course, you can see micromanagement from the beginning, but you can't know
if the complexity will become prohibitive if you get further into the game.
In the mean time, the publisher already has collected a lot of money and
decides to make such a game again. In the worst case, that second one sells
too, only adding to the amounts of successful crap.
--
Wim Libaers
Remove DONTSPAM from my reply address to send me mail.
R Lorber
> Hi Sean
>
> [snip
> >> OK, so how about these four processes are needed for odds creation
> >> and determining which odds to access in gameplay:
> >>
> >> a) Identification
> >> b) Classification
> >> c) Scaling
> >> d) Create or Access Simulation data
> >>
> >>
> >Hmmm. No scaling or classification because in my scheme it would just
play
> >it out to determine outcome.
>
>
> Sorry, I made an assumption there that I shouldn't have. So I will refrain
> from any procedural analysis in the future when describing a list of
> techniques. All I am interested in, for the great wargame AI checklist, is
> the lists of AI techniques. If you used classification of units at least
> once, then it goes on the list. If you scaled these classified units once,
> it goes on the list. You, as the programmer, or as the game designer,
> decide what is useful to your current design.
>
bunch of areas so this would be more of an overall system. Does it work?
I'm not sure yet, but it has worked for me to some degree on a grander
scale.
> So moving along ...
> Given the above list of techniques of assessing units, AI decisions
> could be made:
> - at the tactical level, the simulation data could be used to affect
> morale.
> - at the strategic level, the same data could be used for a battle plan.
>
> >
> >Identification is good, you would want to know what units were going to
> >meet you. The simulation data is the units you are estimating are
> >going to be part of the battle.
I should add that accurate estimates are one of the most important things in
this system. The questions that come up (to me) is how long a battle is and
who can participate. How long is a battle if it involves reinforcements
from other ares of the map for instance. The answer may be to view a battle
through progressive time periods. So, if at TP 0 you consider only units in
range that can say, fire effectively on any enemy unit- that would be
included in the first TP. Next, TP 1 could be units that can move into
range in 1 time period and fire in the second. Then TP 2 could be 2 range
away and fire, etc. Something like this could give you absolute estimates
over time. You would then play out the TP 0 battle to judge attrition.
BUT! There are no front lines drawn on the map at this stage (when they
already must be drawn) so units you are estimating reaching battle TP 0
might get destroyed on the way (not reengaged I don't think). And plenty of
other issues.
> >
> >I would start both sides (or multiple sides if the game supports more
> >then 2 players) start with absolutes, meaning that opponents will
> >target objectives as if they were facing worst case scenarios.
> >This way it will devote all or most resources to securing 1 objective.
> >Then, using this data plug it into the next round as real current
> >estimates and repeat (do this for all opponets) After a few rounds
> >of this, decent estimates should appear.
>
>
>
> Alrighty then, you have just described HOW you would do something.
> But WHAT is it you are doing? It seems to be some sort of goal seeking
> technique. Can we have a nice word or two to describe this?
>
It is a honing in method because it is always looking for weak points and
identifying strong points. But the honing is just an outcome of lots and
lots of techniques.
> But for now I think I will back-track a bit and review your
> "Time and Terrain" battle plan issues ...
>
> Say you had 150 tank units per side, but the enemy had positioned them
> as 50 top left, 50 top center and 50 top right. Your units were all bottom
> center. Remove the time element by saying all units move at the same
> speed, terrain is flat, etc. Do you apply any intelligence to this
> situation? (I assume I am tackling the terrain issue here.)
>
>
That's a good question. It could be TP 0 and from there it could follow
some basic rules such as:
Preprocess:
Calculate hit effectiveness for both sides based on position on terrain.
Rules:
1. Assess if this is maneuvaur, fire, retreat situation for both sides based
purely on hit effectiveness (perhaps if to hit is greater then being hit and
unable to move into a better position. This would automatically determine
if a *unit* is behaving offensively or defensively withing the battle which
is different from the battle being slated as an offensive or defensive
*campaign*) This is the man to man engagement stage after all and not
straight movement.
2. Execute battle
Remember that even though maneuvaring, firing and retreating are the
backbone to the AI, though this is not how objectives are directly
considered. Why they are targetted utilizes a more sophisticated system
then the above, so the more sophisticated it is, the better tactics and
ultimatley the better the estimates.. This is a good example of scale
because even in this battle it still needs to draw the lines that are
necessairy to make the grander system to work (which must also draw lines on
a larger scale). How's that for confusing.. lol
> Tanks, tanks, tanks
No problem this is fun.
Sean
>
> Rick
>
>
>
>
>
>
>
>
>
Rick Craik
R Lorber wrote in message <86v9rm$gid$1...@bob.news.rcn.net>...[snip]
>> All I am interested in, for the great wargame AI checklist, is
>> the lists of AI techniques.
[snip]
>I'm not sure what type of technique this is, I think I'm jumping around to
a
>bunch of areas so this would be more of an overall system. Does it work?
>I'm not sure yet, but it has worked for me to some degree on a grander
>scale.
Sure. This Q&A session is somewhat like asking a pro dart player how many
inches he raises his back foot heel from the ground when releasing the
dart. The pro doesn't even think about it. But a trainer has an eye for
these things, and suggests styles that maintain accuracy and endurance
while drinking beer. :)
When I program, I see entire systems in my mind, based on previous
experience, and know ahead of time that the program will work. But
someone else may look at it and suggest OOP, or Event Driven procedures
for this or that. That screws me up for a while.
I am relieved that you have already written your program, and that
I am only possibly screwing up your future designs :(
>> So moving along ...
[snip timing stuff again]
>
>It is a honing in method because it is always looking for weak points and
>identifying strong points. But the honing is just an outcome of lots and
>lots of techniques.
Honing is a good "technique word". Hmm. (2 m's)
>
>> But for now I think I will back-track a bit and review your
>> "Time and Terrain" battle plan issues ...
>>
>> Say you had 150 tank units per side, but the enemy had positioned them
>> as 50 top left, 50 top center and 50 top right. Your units were all
bottom
>> center. Remove the time element by saying all units move at the same
>> speed, terrain is flat, etc. Do you apply any intelligence to this
>> situation? (I assume I am tackling the terrain issue here.)
>>
>>
>
>That's a good question. It could be TP 0 and from there it could follow
>some basic rules such as:
>
>Preprocess:
>Calculate hit effectiveness for both sides based on position on terrain.
I was wondering if you transformed the three dimensions of position down
to the one scalar value of range. OK. The word Simplification comes to
mind and seems related to Scaling. Hmmm. (3 m's)
>
>Rules:
>1. Assess if this is maneuver, fire, retreat situation for both sides
based
>purely on hit effectiveness (perhaps if to hit is greater then being hit
and
>unable to move into a better position. This would automatically determine
>if a *unit* is behaving offensively or defensively within the battle which
>is different from the battle being slated as an offensive or defensive
>*campaign*) This is the man to man engagement stage after all and not
>straight movement.
Very interesting. Unit Effectiveness Assessment. Hmmm. (My spell checker
won't pass 4 m's.)
>
>2. Execute battle
>
>Remember that even though maneuvering, firing and retreating are the
>backbone to the AI, though this is not how objectives are directly
>considered. Why they are targeted utilizes a more sophisticated system
>then the above, so the more sophisticated it is, the better tactics and
>ultimately the better the estimates.. This is a good example of scale
Yes, for now, I find it easier to get a handle on the lower scale, but
the grander scale is always in the back of my mind ...
... Is there any chance that after Simplification and several Unit
Effectiveness Assessments, that the battle field plays like pieces on a
chess board? That you could exhaustively search every possible combination
(in theory). Let us say that the Simplification gives you four or five
different "chess pieces", and that Unit Effectiveness Assessments work
out to give you about a dozen "chess board squares" (each player can
move several pieces each turn (or TP), or is your game actually a
"u go, I go" turn based, like chess)? I am just trying for
a point of reference here, for getting a handle on the grand battle
techniques. You can consider the opponent's king as the objective,
as it's effectiveness is quite low, and movement slow.
>because even in this battle it still needs to draw the lines that
>are necessary to make the grander system to work (which must also
>draw lines on a larger scale). How's that for confusing.. lol
In summary, this post has considered your following techniques:
a) Simplification; calculate hit effectiveness based on position.
b) Unit Effectiveness Assessment; maneuver, fire, retreat situations
determine if a unit is behaving differently from the overall
offensive or defensive battle.
c) Honing; looking for weak points and identifying strong points.
The time to consider the time in "Time and Terrain" battle plan issues
is next time ...
Yours,
Rick
R Lorber
Well designs come and go. The important thing is that we try different
things to see what works. I am self taught through my own experiences and
inspired by what I see in other games and what I read and understand. This
really isn't a game idea per se, and it really only applies to a certain
type of game (although this turns out to be the best game lol) Besides
there is so much to do to accomplish this (if possible and I believe it
definitly is) that the resources involved would be pretty big.
> >> So moving along ...
> [snip timing stuff again]
>
> >
> >It is a honing in method because it is always looking for weak points and
> >identifying strong points. But the honing is just an outcome of lots and
> >lots of techniques.
>
>
> Honing is a good "technique word". Hmm. (2 m's)
>
>
Sort of general. Definitly 2 m's though.
>
> >
> >> But for now I think I will back-track a bit and review your
> >> "Time and Terrain" battle plan issues ...
> >>
> >> Say you had 150 tank units per side, but the enemy had positioned them
> >> as 50 top left, 50 top center and 50 top right. Your units were all
> bottom
> >> center. Remove the time element by saying all units move at the same
> >> speed, terrain is flat, etc. Do you apply any intelligence to this
> >> situation? (I assume I am tackling the terrain issue here.)
> >>
> >>
> >
> >That's a good question. It could be TP 0 and from there it could follow
> >some basic rules such as:
> >
> >Preprocess:
> >Calculate hit effectiveness for both sides based on position on terrain.
>
>
> I was wondering if you transformed the three dimensions of position down
> to the one scalar value of range. OK. The word Simplification comes to
> mind and seems related to Scaling. Hmmm. (3 m's)
>
>
You are right you must scale these fish one at a time. It is like scaling a
fish though. If the unit that you want to engage in a battle is 5 TP's away
or 5 fish-scales, you would proceed by resolving the units TP 0 first (from
the tail of the fish) to 5 TP's away which is the head of the fish. But in
this case the fish has scales running in all directions and the fish is
being scaled all at once, meaning that every unit and its destination TP 0
must be determined to see what will be moving down the road at the next
(simulated) TP 0. With the basic rules in place these could be played out
pretty fast as battles. After the current battle (for all units on map at
TP 0 or "engaged") it would need to play out the next battle down the road
as well (cut paste blah..lol) so attrition at TP 0 should be done for all
units at once. This way you know aht is left and proceed to the next TP down
the road.
Right 3m's But that is later (I think) plus it is best utilized in
multi-player games (what is he talking about exactly...lol)
> >
> >Rules:
> >1. Assess if this is maneuver, fire, retreat situation for both sides
> based
> >purely on hit effectiveness (perhaps if to hit is greater then being hit
> and
> >unable to move into a better position. This would automatically
determine
> >if a *unit* is behaving offensively or defensively within the battle
which
> >is different from the battle being slated as an offensive or defensive
> >*campaign*) This is the man to man engagement stage after all and not
> >straight movement.
>
>
> Very interesting. Unit Effectiveness Assessment. Hmmm. (My spell checker
> won't pass 4 m's.)
>
>
Yes exactly. The orders are to defend but our man sees a good opportunity
to attack and in doing so can better defend for the team.
>
> >
> >2. Execute battle
> >
> >Remember that even though maneuvering, firing and retreating are the
> >backbone to the AI, though this is not how objectives are directly
> >considered. Why they are targeted utilizes a more sophisticated system
> >then the above, so the more sophisticated it is, the better tactics and
> >ultimately the better the estimates.. This is a good example of scale
>
>
> Yes, for now, I find it easier to get a handle on the lower scale, but
> the grander scale is always in the back of my mind ...
>
> ... Is there any chance that after Simplification and several Unit
> Effectiveness Assessments, that the battle field plays like pieces on a
> chess board? That you could exhaustively search every possible combination
> (in theory). Let us say that the Simplification gives you four or five
> different "chess pieces", and that Unit Effectiveness Assessments work
> out to give you about a dozen "chess board squares" (each player can
> move several pieces each turn (or TP), or is your game actually a
> "u go, I go" turn based, like chess)? I am just trying for
> a point of reference here, for getting a handle on the grand battle
> techniques. You can consider the opponent's king as the objective,
> as it's effectiveness is quite low, and movement slow.
>
>
This would be a real time game, but it could be used in the Squad Leader
system because that is simulated real time. I don't think there are
combinations to look at here except at TP 0 target battle. This is where
you should determine if 2 tanks would be an effective addition to the battle
given the combination of units. You would have already determined (roughly)
if the tanks would make it there given that you play through these
relatively quick (and always getting slower-- but better) rules for each
unit at its current position.
To try and restate the idea, every unit has orders and destination. The
orders are attack and defend. The destination is an objective like one that
must be held in order to get victory points. Every unit executes TP 0 they
are either engaged or can move (moving within an engagment is engagment).
If a unit is not engaged it moves to the TP 1. If engaged it remains at TP
0. After all units TP 0 is resolved (units destroyed, moved into new
position) are known. This is the new TP 0 for all units. It is also a
simulation that the AI uses to think ahead and suppose what units are going
to be where. When the unit reaches its final TP position it will have
fought its way through all the other TP's and with this information you know
when and if the unit can be counted as part of the estimate reenforcements,
etc.
> >because even in this battle it still needs to draw the lines that
> >are necessary to make the grander system to work (which must also
> >draw lines on a larger scale). How's that for confusing.. lol
>
>
>
> In summary, this post has considered your following techniques:
>
> a) Simplification; calculate hit effectiveness based on position.
>
> b) Unit Effectiveness Assessment; maneuver, fire, retreat situations
> determine if a unit is behaving differently from the overall
> offensive or defensive battle.
>
> c) Honing; looking for weak points and identifying strong points.
>
>
> The time to consider the time in "Time and Terrain" battle plan issues
> is next time ...
>
Nice. a + b yes, c will hopefully be the payoff if everything works
correctly.
Thanks Rick.
> Yours,
> Rick
>
>
Rick Craik
R Lorber wrote in message <86vt82$si7$1...@bob.news.rcn.net>...
>
>"Rick Craik" <NOSPAM...@ntl.sympatico.ca> wrote in message
>news:ahJk4.7$vU6...@198.235.216.4...
>>
[snip]
>Besides there is so much to do to accomplish this (if possible
>and I believe it definitly is) that the resources involved
>would be pretty big.
This seems true.
But the great wargame AI checklist is not concerned
with the resources required. A lot of AI possibilities are
dropped because of scarce computing resources. Accordingly,
a game would check off it's utilized AI and state it's
hardware minimum requirements, and game style (RTS, RTT ...).
I suppose we could add projected resource usage needed for
a AI functionality for design estimates. But a lot of this
stuff is state of the art and changes dramatically. I have
chosen to leave it out, the designer/programmers can
exercise their own choices on that subject. If a
great wargame AI SDK was developed, then it would
definitely outline projected resource usage as part of
it's featured capabilities.
>
>> >> So moving along ...
>> [snip timing stuff again]
[snip]
>
>You are right you must scale these fish one at a time.
>It is like scaling a fish though. If the unit that you
>want to engage in a battle is 5 TP's away or 5 fish-scales,
>you would proceed by resolving the units TP 0 first (from the
>tail of the fish) to 5 TP's away which is the head of the fish.
>But in this case the fish has scales running in all directions
>and the fish is being scaled all at once, meaning that every unit
>and its destination TP 0 must be determined to see what will be
>moving down the road at the next (simulated) TP 0. With the basic
>rules in place these could be played out pretty fast as battles.
>After the current battle (for all units on map at TP 0 or "engaged")
>it would need to play out the next battle down the road as well
>(cut paste blah..lol) so attrition at TP 0 should be done for all
>units at once. This way you know aht is left and proceed to the
>next TP down the road.
Is there depth to this forecasting (honing). Like in forecasting
chess moves. I understand we may have campaigns, battles,
and engagements. In battles, can we forecast engagements to a
depth of say TP5? For campaigns, forecast to a depth of x number
of battles? And likewise for single units in engagements.
Or is a battle always conclusive in a certain number
of TPs? Do re-enforcements on both sides affect this?
[snip]
>> The time to consider the time in "Time and Terrain" battle plan issues
>> is next time ...
After some thought, I don't believe that there are any 'time' issues
that affect wargame AI. It is just one of the four dimensions
(x, y, z, t), and has been covered in Forecasting, and Scaling.
Also, I believe that objectives are used in Identification
and Forecasting. For example an enemy scout unit that
is nowhere near an objective, or can possibly see your
units could be ignored.
Well I think I got a handle on everything, and can summarize
what this editor is going to put in the great wargame AI
checklist:
a) Identification; decide who and where is the enemy.
b) Classification; decide what are the unit capabilities.
c) Scaling; find lowest common unit sizes.
d) Simplification; calculate hit effectiveness based on position.
e) Assessment; what are unit's engagement behaviours.
f) Forecasting; identifying weak and strong points.
I am going to let these items sink in for a while. Wait see
if there are any other comments, and then fit them in the
checklist.
Yours,
Rick
R Lorber
> Hi Sean
>
>
> R Lorber wrote in message <86vt82$si7$1...@bob.news.rcn.net>...> >news:ahJk4.7$vU6...@198.235.216.4...
> >>
>
>
> [snip]
>
> >Besides there is so much to do to accomplish this (if possible
> >and I believe it definitly is) that the resources involved
> >would be pretty big.
>
> But the great wargame AI checklist is not concerned
> with the resources required. A lot of AI possibilities are
> dropped because of scarce computing resources. Accordingly,
> a game would check off it's utilized AI and state it's
> hardware minimum requirements, and game style (RTS, RTT ...).
>
> I suppose we could add projected resource usage needed for
> a AI functionality for design estimates. But a lot of this
> stuff is state of the art and changes dramatically. I have
> chosen to leave it out, the designer/programmers can
> exercise their own choices on that subject. If a
> great wargame AI SDK was developed, then it would
> definitely outline projected resource usage as part of
> it's featured capabilities.
>
Right the checklist should definitly include a method like this but it would
be difficult to name. Maybe "Playing Piece Length Simulation by way of
Local Estimates"
The system's primary objective is to plug in a piece and destination and see
if it reaches its goal. On that note, we all know it is necessairy to have
some very incredible path finding. Until the path finding (which is of
course the foundation) is worked out, the system will not function well (or
very well anyway)
> >
> >> >> So moving along ...
> >> [snip timing stuff again]
> [snip]
> >
> >You are right you must scale these fish one at a time.
> >It is like scaling a fish though. If the unit that you
> >want to engage in a battle is 5 TP's away or 5 fish-scales,
> >you would proceed by resolving the units TP 0 first (from the
> >tail of the fish) to 5 TP's away which is the head of the fish.
> >But in this case the fish has scales running in all directions
> >and the fish is being scaled all at once, meaning that every unit
> >and its destination TP 0 must be determined to see what will be
> >moving down the road at the next (simulated) TP 0. With the basic
> >rules in place these could be played out pretty fast as battles.
> >After the current battle (for all units on map at TP 0 or "engaged")
> >it would need to play out the next battle down the road as well
> >(cut paste blah..lol) so attrition at TP 0 should be done for all
> >units at once. This way you know aht is left and proceed to the
> >next TP down the road.
>
> Is there depth to this forecasting (honing). Like in forecasting
> chess moves. I understand we may have campaigns, battles,
> and engagements. In battles, can we forecast engagements to a
> depth of say TP5? For campaigns, forecast to a depth of x number
> of battles? And likewise for single units in engagements.
>
No the depth must be the entire playing area. A unit needs to test to see
if could reach from their origin to any objective (not every space). The
honing is a high level affair that is deciding to choose its objective based
purely on the outcome of sent units to an objective. The computer must use
these estimates in a forward feeding recursive manner, so the computer must
believe it is an expert or authority on the estimates. At first, the
computer with bad pathfinding (pathfinding that includes deciding how to go
based on orders) played against itself it would be accurately determining
estimates all the time (which is a blessing in disguise because it let's you
get the basic flow going) but if I were to play as a human against it, I
would easily beat it (and watch it be stupid all at the same time). At this
point it is easier to get into the nitty gritty of tactics which where all
the fun is (at least for me)
I think the rules are fast enough right now (what are there, 3?) to be able
to determine outcome of the present time period for every piece on the board
and then from the outcomes of that proceed to the next time period (all in
simulation) Somewhat realistically I think it would take about for say,
5000 units on each side, maybe 5 seconds on 200mhz computer for each TP0 (if
that much).
> Or is a battle always conclusive in a certain number
> of TPs? Do re-enforcements on both sides affect this?
>
That's up to the objectives in the partiuclar scenario you are playing.
Does the objective need to be taken by turn 5 and if not the game is over.
The reinforcements are a foregone conclusion. According to the AI they will
reach that space because of all the ground work it has done.and is
estimating that they will (with appropriate attrition.. woo hoo!)
> [snip]
>
> >> The time to consider the time in "Time and Terrain" battle plan issues
> >> is next time ...
>
>
> After some thought, I don't believe that there are any 'time' issues
> that affect wargame AI. It is just one of the four dimensions
> (x, y, z, t), and has been covered in Forecasting, and Scaling.
>
Perhaps but I am not familiar with those terms.
> Also, I believe that objectives are used in Identification
> and Forecasting. For example an enemy scout unit that
> is nowhere near an objective, or can possibly see your
> units could be ignored.
>
>
Well, as a by-product you are playing all sides of the battle so all enemies
are played out too.
> Well I think I got a handle on everything, and can summarize
> what this editor is going to put in the great wargame AI
> checklist:
>
> a) Identification; decide who and where is the enemy.
>
> b) Classification; decide what are the unit capabilities.
>
> c) Scaling; find lowest common unit sizes.
>
> d) Simplification; calculate hit effectiveness based on position.
>
> e) Assessment; what are unit's engagement behaviours.
>
> f) Forecasting; identifying weak and strong points.
>
>
>
> I am going to let these items sink in for a while. Wait see
> if there are any other comments, and then fit them in the
> checklist.
>
> Yours,
> Rick
>
>
Good. Maybe someone can write this up (code wise) if they already have some
good pathfindng at their disposal. Then they can show the application to
all interested parties. I could help with any problems that might come up.
We can conduct that through private e-mail if you like or Onelist, etc.
Sean
Rick Craik
R Lorber wrote in message <8732v6$kok$1...@bob.news.rcn.net>...
[snip]
>
>Right the checklist should definitly include a method like this but
>it would be difficult to name. Maybe "Playing Piece Length Simulation
>by way of Local Estimates"
>
>The system's primary objective is to plug in a piece and destination and
>see if it reaches its goal. On that note, we all know it is necessairy
>to have some very incredible path finding. Until the path finding (which
>is of course the foundation) is worked out, the system will not function
>well (or very well anyway)
>
I felt that Path-Finding should be a separate level of AI, and Navigation
would include your "very incredible path finding". Like you say, it is a
foundation. The Navigation concept is separated on the checklist, but a
programmer may actually integrate it all and call it his "very incredible
path finding module".
For example; if while moving, a unit is using a basic path-finding
route, the unit draws fire, the path-finding concept does not help the
unit decide on it's Rules of Engagement. By enhancing the movement
routines with a Navigation concept (way-points, no-go zones), the chances
of drawing fire are decreased, but again, still no help on RoE decisions.
Your "Playing Piece Length Simulation by way of Local Estimates"
would be an application using, hopefully, concepts outlined in the
checklist. It is akin to "Moving units without getting destroyed while
wandering into enemy bases by using no-go zones".
With this in mind, do you think the checklist is too general?
Or that it is just stating the obvious?
[snip]
>> After some thought, I don't believe that there are any 'time' issues
>> that affect wargame AI. It is just one of the four dimensions
>> (x, y, z, t), and has been covered in Forecasting, and Scaling.
>>
>
>Perhaps but I am not familiar with those terms.
"Forecasting, and Scaling" or "the four dimensions (x, y, z, t)"?
"Forecasting, and Scaling" are concepts derived from your examples and
detailed in this thread.
"the four dimensions (x, y, z, t)" refer to the positions of units over
time. Scaling reduces the numbers of positions to consider, and
Forecasting considers the units at different points in time.
Is this ok now?
[snip]
>Good. Maybe someone can write this up (code wise) if they already have
>some good pathfinding at their disposal. Then they can show the
>application to all interested parties. I could help with any problems
>that might come up. We can conduct that through private e-mail if you
>like or Onelist, etc.
>
>Sean
Well, my hidden agenda here is a bit different. I have a game project
already in development, but the combat requirements are not yet defined.
I need an outline, like the checklist, to give me a reality check. Too soon
to say that I am interested. (I assume you are referring to the "Playing
Piece Length Simulation by way of Local Estimates".)
R Lorber
>
> R Lorber wrote in message <8732v6$kok$1...@bob.news.rcn.net>...
> [snip]
> >
> >Right the checklist should definitly include a method like this but
> >it would be difficult to name. Maybe "Playing Piece Length Simulation
> >by way of Local Estimates"
> >
> >The system's primary objective is to plug in a piece and destination and
> >see if it reaches its goal. On that note, we all know it is necessairy
> >to have some very incredible path finding. Until the path finding (which
> >is of course the foundation) is worked out, the system will not function
> >well (or very well anyway)
> >
>
>
> would include your "very incredible path finding". Like you say, it is a
> foundation. The Navigation concept is separated on the checklist, but a
> programmer may actually integrate it all and call it his "very incredible
> path finding module".
I am working on the path finding aspect. It is that vexing NP-Complete
problem. I'll let you know when I work that out.... lol
>
> For example; if while moving, a unit is using a basic path-finding
> route, the unit draws fire, the path-finding concept does not help the
> unit decide on it's Rules of Engagement. By enhancing the movement
> routines with a Navigation concept (way-points, no-go zones), the chances
> of drawing fire are decreased, but again, still no help on RoE decisions.
>
Well it can in the form of cost.
> Your "Playing Piece Length Simulation by way of Local Estimates"
> would be an application using, hopefully, concepts outlined in the
> checklist. It is akin to "Moving units without getting destroyed while
> wandering into enemy bases by using no-go zones".
>
> With this in mind, do you think the checklist is too general?
> Or that it is just stating the obvious?
I have not seen the current version but last time it looked like it was
taking shape.
>
>
> [snip]
>
>
> >> After some thought, I don't believe that there are any 'time' issues
> >> that affect wargame AI. It is just one of the four dimensions
> >> (x, y, z, t), and has been covered in Forecasting, and Scaling.
> >>
> >
> >Perhaps but I am not familiar with those terms.
>
>
> "Forecasting, and Scaling" or "the four dimensions (x, y, z, t)"?
>
> "Forecasting, and Scaling" are concepts derived from your examples and
> detailed in this thread.
>
> "the four dimensions (x, y, z, t)" refer to the positions of units over
> time. Scaling reduces the numbers of positions to consider, and
> Forecasting considers the units at different points in time.
> Is this ok now?
>
>
> [snip]
>
>
> >Good. Maybe someone can write this up (code wise) if they already have
> >some good pathfinding at their disposal. Then they can show the
> >application to all interested parties. I could help with any problems
> >that might come up. We can conduct that through private e-mail if you
> >like or Onelist, etc.
> >
> >Sean
>
>
> Well, my hidden agenda here is a bit different. I have a game project
> already in development, but the combat requirements are not yet defined.
> I need an outline, like the checklist, to give me a reality check. Too
soon
> to say that I am interested. (I assume you are referring to the "Playing
> Piece Length Simulation by way of Local Estimates".)
>
>
If you are going to start implementing this stuff I would be interested in
your progress. If you want to work together on Length simulation blah blah
I would be interested in that as well.
Sean
>
>
>
>
>
LANDRU X
One thing that makes real AI so difficult is dealing with Unknowns.
Each item on your list below increases in difficulty a magnitude
when uncertain/possibly incorrect/unknown information is possible.
(most wargames dont have this attribute enuf and cause them to barely
resemble the wars they are supposed to simulate)
Dealing with 'the fog of war' adaquately is the sign of a great general
(ie-- maintaining reserves, maintaining flexibility, aggressive scouting/spying,
knowning how the enemy thinks, understanding of ones own troops capabilities
etc...)
Risk/Resource management problems are difficult and get alot worse when unknown
factors are present (logicwise, adding dynamic reevaluation and contingency
capabilities easily quadruples the code and data required).
Command conflict resolution (a real world problem due to imperfect communications
and subcommander individualism) adds another chunk of AI (rare in current games).
Its no wonder game AI is still so primitive, as proper AI solutions increase
geometricly compared to the simulations complexity. Even the simple Chit unit
(offense/defense/movement) type games (pre-genralized) are not yet done adaquately
as the CPU requirements as yet are insufficient to match an ordinary persons
capability.
Doru-Julian Bugariu
Thema Re: great wargame AI? (even harder than people think):
> Command conflict resolution (a real world problem due to imperfect
communications
> and subcommander individualism) adds another chunk of AI (rare in
current games).
Apropos subcommander individualism. Imagine something like this: You
say to your General to go to the right side of the battlefield and
stay there but he runs straight into the arms of the enemy because his
„individualism-parameter“ is to high and he „thinks“ he good enaugh to
win the battle. I thing the players won't be very happy ;-)))
Banny