High Guard Combat Software

[rvatsaas]

HAs anyone ever succcessfully created a High Guard Combat computer program? I tried it about 15 years ago, but the task was beyond my limited grasp of FORTRAN and Pascal.

The combat steps are so complex and repetitive that I imagine it is difficult to keep players attention during a ship combat scenario.

Has any one used spreadsheets to keep track of High Guard Combat.

The version I tried to develop would also have had realistic vector movement, but I was never able to solve the adaptive gain problem (a ship trying to match courses with another would never converge)

 

[Whipsnade]

Egapillar wrote:

"Has anyone ever succcessfully created a High Guard Combat computer program? I tried it about 15 years ago, but the task was beyond my limited grasp of FORTRAN and Pascal."


Sir,

I've never seen a complete HG2 combat program, just various spreasheets that handle certain aspects. Naturally, that doens't mean there isn't one out there.

"Has any one used spreadsheets to keep track of High Guard Combat."

That I have seen. There is an active Yahoo group dedicated to CT and HG2 ship designs; 'ct starships'. IIRC, you have to join to access the files section. In the group's files, there is a nifty .xls spreadsheet that requires minimal input from you; weapons' factors and types, agility, computers, etc. and handles all the die rolls including 'to hit', 'to pen', and damage.

"The version I tried to develop would also have had realistic vector movement, but I was never able to solve the adaptive gain problem (a ship trying to match courses with another would never converge)"

That is an entirely different kettle of fish. Another Yahoo group I belong to, 'sfconsim-1', deals with sci-fi game design and play. You'll find many better brains than I gathered there, of course the local drunk tank has many better brains than I too. You may find the message archives, members, and files there of great interest.


Sincerely,
Larsen

 

[kaladorn]

Originally posted by Egapillar:
The version I tried to develop would also have had realistic vector movement, but I was never able to solve the adaptive gain problem (a ship trying to match courses with another would never converge)

General comments:
1. It is hard to do. The enemy will manouver to prevent this (even if it is just rotations) unless you disable her drives.
2. As you approach, your ship would recalc this every few milliseconds and adjust course accordingly. Games don't represent this well.

The way around #2 is to specify some distance and apart (within a map hex or a measuring unit) for the vessels along with some similarity rules for the vectors (such as within 15 degrees and within a few velocity increments of one another) and then apply the old "and then a miracle happens" handwave and declare them docked and using the same (or perhaps an averaged) vector.

 

[rvatsaas]

Regarding Vector movement.

Yes, its very hard to do. I successfully design a simulation of an anti-torpedo intercepting a incoming torpedo (that's the kind of work I was doing at the time), but just matching courses with a "derelict" I found impossible, I could work it out on paper, but in a simulation, I continually over shot the target.

Thanks all for the hints. I will check those links out.

 

[kaladorn]

Originally posted by Egapillar:
incoming torpedo (that's the kind of work I was doing at the time), but just matching courses with a "derelict" I found impossible, I could work it out on paper, but in a simulation, I continually over shot the target.

I'm guessing you were doing this as a 'discrete' solution as opposed to a continous one? If you do it as a discrete solution, or even a numerical methods approach which is discrete plus computers, then you may well have this kind of problem. In order to match courses, you need to have something which will allow you to find both a coincident point on the three space (or two space if using flat space) grid at the same time you have velocity vectors in two or three space that are the same. THAT isn't the simplest bit of math ever done. And chances are, unless your time increment between adjustments is such that the enemy ship moves very little distance, you have a very tough situation.

For another fun mental excercise, try using most space board/minis games to enter a stable orbit around a world. <hint: ha! good luck!>

 

[rvatsaas]

Matching Courses in space (mechancially speaking) is a case of high spring constant with zero damping.

When you think about it, Space combat engagements reduce down to only a few scenarios

1. Defend the planet/Gas Giant and force the retreat of the agressor

2. Escape the planet/Gas Giant and make for 100 diameters

3. Escape to planet surface (when chased by pirates)

4. ambush a fleet that is fueling

5. Deep space slugout

6. Did I miss any?

Actual vector movement doesn't really ad much to any of these, I suppose.

 

[kaladorn]

Originally posted by Egapillar:

1. Defend the planet/Gas Giant and force the retreat of the agressor

2. Escape the planet/Gas Giant and make for 100 diameters

3. Escape to planet surface (when chased by pirates)

4. ambush a fleet that is fueling

5. Deep space slugout

6. Did I miss any?

Actual vector movement doesn't really ad much to any of these, I suppose.

I totally disagree with that - I hate cinematic space movement systems. Abstract systems are also less interesting and tactically challenging. But then, I'm a wargamer too.

You missed plenty of scenarios:
1) Bombard the planet
2) Invade the planet
3) Stop either of the above
4) Attack the High Port
5) Escape the High Port
6) Engage in a battle amidst a traffic pattern
7) Intercept a vessel in open space (it is going
from A to B and you are coming from C)
8) Fight in an asteroid belt or ring system
9) Fight near a star or other source of gravitation or radiation effects

There are lots of interesting space scenarios and I think almost any combat is spiced up by the kind of decisions you have to make when there are actually maps or minis involved. But, YMMV.

 

[rvatsaas]

I am not familiar with the term "Cinematic movement" Does that refer to Stars wars like dogfights?

 

[kaladorn]

Originally posted by Egapillar:
I am not familiar with the term "Cinematic movement" Does that refer to Stars wars like dogfights?

Yes, because it is just that - cinematic. In Star Wars, they have flips and overturns that make your ship corner tighter.... (this works in atmosphere due to said atmosphere... I have no idea why the game figures it'll work in vacuum, except the movie seemed to). At the very least, they are non-Newtonian and don't respect conservation of energy or momentum as far as anyone can tell.

 

[TheEngineer]

Hi,

I have just finished a beta version of my MT spaceship combat software,
which includes vector movement. (Originally I just wanted to have something
to do all the to hit/to pen dice rolling...)
Now I mostly use it to "test" MT combat vessel designs, so I just call it
"Starship Testdrive".

Regarding the vector movement I mainly had problems to implement "live" into
the movement. If you let computer movement be perfect you just get alternating
and swinging movement effects (as Egapillar stated "with a high spring constant").
So I use more or less frequent pilot or sensoring flaws in order to let it
look more "real".

Matching vectors works quite well, when one ship "hunts" another at higher
velocities. (Now I use two basic "modes" of a ship: "attack" and "breakout")
As soon as the fleeing ship is slow enough to reach higher turn rates matching
vectors is quite difficult.
Al least matching vectors is always difficult/impossible when both ships have
nearly identical g ratings (torpedo/anti-torpedo problem).

Mostly I tend to neglect vector movement for space combat purposes. I have
tried to figure out some roleplaying pen/dice/paper mechanics for "typical"
situations (similar to those presented in the last posts), which take concern
of typical effects when using vector movement.
For game purpose I differ mainly between two basic situations:

- Interception/Hunting
Ships with lower g rating try to intercept targets with higher g rating
in order to be able to apply some hits before target moves away
Ships with high g rating try to intercept targets with lower g rating
before target reaches safe areas

- Combat
Both ships want to attack each other, regardsless of g-rating

In both cases I use g-rating, agility, actual movement speed, distance
and of course skills as modifiers for a combat movement task, which effects
the distance again.
For this methods its also quite easy to figure out an appropriate excel
spreadsheet.

If there is anyone interested I will use the next programmming turns to
convert "MT Starship Testdrive" to a "HG Starship Testdrive".
Perhaps somebody is willing to help, too ?
I could provide a bunch of VB source code.


Best regards,


Mert

 

[Flynn]

Hey, Mert,

I, for one, would be very interested in seeing what you have created thus far, and would love to see what you can come up with. I'm sure the code could also be made T20-adaptable once you've got the HG version written.

Looking forward to it,
Flynn

 

[Andrew Boulton]

If there is anyone interested I will use the next programmming turns to
convert "MT Starship Testdrive" to a "HG Starship Testdrive".

No need to downgrade it to HG, but I'd be happy if you upgraded it to T4.

 

[rvatsaas]

Go for it Dude!

I would like to the see the High Guard Version.

I like your approach. Detailed enough to be interesting - not so math intensive. That's where I was headed before I gave up.

 

[rvatsaas]

I would volunteer to help with programming if knew visual basic. Alas, I haven't had time to dabble. I may be forced to with the course I am taking (factory automation)

 

[TheEngineer]

Hi,

guess VB is a pretty good thing for stuff like this ... and offers some feelings of success even
for beginners

I definitly will implement fleet/multi-ship battles and transfer the stuff to CT/HG in
order to re-run TCS campaigns.
T4 is a kind of problems cause I´ve got no
T4 stuff at all. Perhaps Andrew will provide
"migration" support.

If everything is going all right with the "shipping to the retailers" of the 2nd
T20 Handbook, I hope I could get one copy on
the "Essener Spielemesse".

Regarding the actual MT version, I still have
some questions regarding some details of space combat rules. I´ve already posted some stuff to
the TML but it seems like nobody is practicing
those rules..?
So, anybody around here with some good interpretations of the "visual range" rule effects (critical, effect of armor, pen check
required)?

Another one:
A ship may perform sensor scans at any point of
movement (should be the nearest..). Could it
fire at this range, too ?

And another one:
Is anybody here willing to discuss movement
algorithms ? I´m still looking to improve
the computer movement decision path, so perhaps
there are some ideas around...

Thats it so far...

regards,

Mert

 

[kaladorn]

Originally posted by TheEngineer:
guess VB is a pretty good thing for stuff like this ... and offers some feelings of success even
for beginners

<shudder>

Represses all knowledge of months of programming network-service-aware code for client-server Point-of-Sale and Central Retail Management... in VB and VB.Net...

<shakes.... drools....>

Regarding the actual MT version, I still have
some questions regarding some details of space combat rules. I´ve already posted some stuff to
the TML but it seems like nobody is practicing
those rules..?

Sorry, I've been dozing.

So, anybody around here with some good interpretations of the "visual range" rule effects (critical, effect of armor, pen check
required)?

That's a tough one. Care to be a bit more specific?

Visual range is also a bit of a problem as visual range with good optical telescopes can be rather stupidly far....

Another one:
A ship may perform sensor scans at any point of
movement (should be the nearest..). Could it
fire at this range, too ?

To my mind (not addressing the rules particularly), one should be able to fire at any point during one's movement or during the movement of the enemy.... maybe one could apply a small range-based hesitation/delay, but computers of the day should allow such shooting. Heck, even manually you should be able to.

And another one:
Is anybody here willing to discuss movement
algorithms ? I´m still looking to improve
the computer movement decision path, so perhaps
there are some ideas around...

Care to tell me what method you're using now?

Are you trying to make the ship's truly artifically intelligent (probably not, the work load is grotesque) or just to make some moderately sane rules for course selection?

 

[rvatsaas]

I'm Impressed, Herr Mert!

 

[TheEngineer]

<quote>
---------------------------------------------- Originally posted by TheEngineer:
guess VB is a pretty good thing for stuff like
this ... and offers some feelings of success
even for beginners
----------------------------------------------

<shudder>

Represses all knowledge of months of programming network-service-aware code for client-server
Point-of-Sale and Central Retail Management... in VB and VB.Net...

<shakes.... drools....>

</qoute>

Well, the choice of tool is a very basic engineering question...

For myself I use whatever programming environment which is appropriate for the actual task.
Since VB 5.0 I have experienced only minor problems even in larger projects.
On the other hand I notice quite a few java project running against the wall, because
of badly distributed knowledge about the J2EE stuff and missing "experienced" programmers.
Then talking about "experienced" I mean 10 years or more....
At the moment I do my consulting job for the financial governnment. Here we take care
(configuration/test management) for a large VB project (3-tier architecture
mainframe-unix-workstation, about 1500 files, 50 projects, about 32000 users).

This works surprisingly well...so don´t give up....!


<quote>
-----------------------------------------------
Regarding the actual MT version, I still have
some questions regarding some details of space
combat rules. I´ve already posted some stuff
to the TML but it seems like nobody is
practicing those rules..?
---------------------------------------------

Sorry, I've been dozing.
</quote>

WAKE UP !

<quote>
----------------------------------------------
So, anybody around here with some good
interpretations of the "visual range" rule
effects (critical, effect of armor, pen
check required)?
----------------------------------------------

That's a tough one. Care to be a bit more specific?
Visual range is also a bit of a problem as visual range with good optical
telescopes can be rather stupidly far....
</quote>

The MT Referee´s Guide describes the possiblity to do a pinpoint shot when at visual range
(You and Your traget occupying same hex).
If exceptional success +2 is achieved, this hit is also a critical.
Here there is no further information about if still penetration rolls have to be made, and in
which way armor effects this critical.
E.g., the number of criticals inflicted by a spinal mount weapon hit is decreased by higher
armor values.
So, take a visual range hit of a TL 15 fighter: Could this one knock out a major battleship,
because of a critical running thru all defenses, or is it stopped by anything ?



<quote>
----------------------------------------------
Another one:
A ship may perform sensor scans at any point of
movement (should be the nearest..). Could it
fire at this range, too ?
-----------------------------------------------

To my mind (not addressing the rules particularly), one should be able to fire at any point during one's movement or

during the movement of the enemy.... maybe one could apply a small range-based hesitation/delay, but computers of the

day should allow such shooting. Heck, even manually you should be able to.
</quote>

That would be my thought too, but at least it seems not to be stated in the rules
Nevertheless its quite important for the results of simulated combat.

<quote>
-----------------------------------------------
And another one:
Is anybody here willing to discuss movement
algorithms ? I´m still looking to improve
the computer movement decision path, so perhaps
there are some ideas around...
-----------------------------------------------

Care to tell me what method you're using now?

Are you trying to make the ship's truly artifically intelligent
(probably not, the work load is grotesque) or just to make some
moderately sane rules for course selection?
</quote>

Will try....
- calculate perfect thrust vector =
theoretical thrust vector to reach enemy
- adapt thrust vector to maneuver drive limit,
hold heading
- random pilot errors resulting in minor, major
heading changes (adds a bit life)
- modify move mode
"attack" : standard movement mode -
approach target
change to "breakout"
if enemy close behind
"breakout" : major heading change in order
to get a bit away from enemy
change to "attack" if distance
great enough
"flee" : get away from enemy
- if breakout mode apply breakout movement
set heading about 90 degrees away from enemy
heading
- if flee mode apply flee movement
set heading about 90 degrees away from enemy
heading if close to enemy
- brake : if not fleeing, reduce speed if too
fast -> further heading changes too difficult

Well, as I mentioned I could provide source code.

Thanks for any help in advance

Regards,

Mert

 

[kaladorn]

Originally posted by TheEngineer:
Well, the choice of tool is a very basic engineering question...

Sometimes it is a religious question.

For myself I use whatever programming environment which is appropriate for the actual task.

I just happen to think for serious client-server programming, that VB is not the best choice.

Since VB 5.0 I have experienced only minor problems even in larger projects.

Lucky you!

On the other hand I notice quite a few java project running against the wall, because
of badly distributed knowledge about the J2EE stuff and missing "experienced" programmers.
Then talking about "experienced" I mean 10 years or more....

Well, I was formerly a Sr. Network Architect doing MMORPG stuff in Java. But Java has evolved a lot as have the related bits since its origins, so staying current and getting the most out of the latest bits can be a bit challenging. And knowing what not to do is often as important as knowing what *to* do. A lot of people think Java has to be slow - we had C-like speed out of ours since we knew how to avoid the main bottlenecks.

At the moment I do my consulting job for the financial governnment. Here we take care
(configuration/test management) for a large VB project (3-tier architecture
mainframe-unix-workstation, about 1500 files, 50 projects, about 32000 users).

Well, I'm not sure how many drug stores, post office outlets, etc, there are all across Canada, but I'd guess the number is many many thousands. These were all networked into an architecture that had several main servers, several types of networking links, maybe 3-4K files between client and server, and had Java, SOAP, FTP, DB (Oracle and Sybase), and other technologies involved.
The final product worked pretty well, but some of the tooth pulling to get there was rather ugly and there were times I cursed VB (more often than I cursed Java).

The MT Referee´s Guide describes the possiblity to do a pinpoint shot when at visual range
(You and Your traget occupying same hex).
If exceptional success +2 is achieved, this hit is also a critical.
Here there is no further information about if still penetration rolls have to be made, and in
which way armor effects this critical.
E.g., the number of criticals inflicted by a spinal mount weapon hit is decreased by higher
armor values.
So, take a visual range hit of a TL 15 fighter: Could this one knock out a major battleship,
because of a critical running thru all defenses, or is it stopped by anything ?

Unless you are a Star Wars fan, I'd say armour still applies. There really should be better task oriented results here, similar to those in ground combat, where various degrees of exceptional success yielded better penetration/damage.

That would be my thought too, but at least it seems not to be stated in the rules
Nevertheless its quite important for the results of simulated combat.

Well, I think you'll find that you have a choice at some point:

Make a good game/sim or make the one out of the rulebook.

Will try....
- calculate perfect thrust vector =
theoretical thrust vector to reach enemy
- adapt thrust vector to maneuver drive limit,
hold heading

hold heading?

- random pilot errors resulting in minor, major
heading changes (adds a bit life)

Navigation errors I can see. Piloting errors much less likely.

Your navigator or computer (doing nav's job) should be the big part of interception.

- modify move mode
"attack" : standard movement mode -
approach target
change to "breakout"
if enemy close behind
"breakout" : major heading change in order
to get a bit away from enemy
change to "attack" if distance
great enough
"flee" : get away from enemy

Are you precluding the use of a rotation? (The easiest way to bring guns quickly to bear on a rear arc target - note this separates ship heading and course)

- if breakout mode apply breakout movement
set heading about 90 degrees away from enemy
heading
- if flee mode apply flee movement
set heading about 90 degrees away from enemy
heading if close to enemy

Note this may not be optimal if you are trying to outrun someone or hold the distance open for the longest time possible. (I think....)

- brake : if not fleeing, reduce speed if too
fast -> further heading changes too difficult

Well, as I mentioned I could provide source code.

Just let me be sure I understand what you're trying to model:

Two situations:
Two ships that wish to fight.
Two ships, one wishes to fight, the other does not.
One of these ships should be able to be run
by computer (or perhaps both).

Is this correct?

 

[The Oz]

As a CT veteran, I must admit all I'd like to see is software that would automate HG combat as given in HG2. I don't need any movement other than changing range from long to short and jumping away/pursuit situations.

But I'd like to be able to input my own ship designs (including direct from HGS if possible) and have really, really big battles with dozens of ships on each side, plus hordes of fighters, etc. All of varying designs and tech levels