High Guard Combat Software

[kaladorn]

I've been thinking about a ship combat project - something that would be written using Javascript and Java Beans to make it accessible to people over the net. It would also use a background database for data storage.

The concept would be that it would be a generic tool which might provide a way to enter ship data and to represent vector movement and firing, but the details on the firing and the ships themselves would be drawn from the data tables. Thus, not entering the particulars of ships which are copywritten or the weapons tables, one could still have the effect.

This idea has yet to advance to the level where I think it worthile or feasible, but it was an interesting direction and gives me a project as an excuse to do some more Javascript/Java.

I'd like to do something that is useful to me when I play MT, but if I wanted to make any such thing generally available, it'd have to stay far and away from the published mechanics (esp since it'd end up using modified versions of same and I'm sure this violates IP....).

Hmmm again.

We'll see what happens.

 

[kaladorn]

I think we should move this (and any other software related discussions) over to the new 'Software Solutions' forum that Hunter has rolled out for us!

 

[TheEngineer]

Hi,

o.k.
lets move and go on...

Would somme like to try this IRC lone star in order to exchange some thoughts about the software stuff ?

Greetings,

Mert

 

[The Oz]

I'd love to chat with someone about what would be nice in TRAVELLER ship combat software. I'll try to remember to make the Lone Star chat this weekend.

 

[clementk]

Just a note here:

1) Lone Star is technically open for chatting 24-7 minus whenever they do maintenance etc.

2) However most people are there on Sunday's starting at 1pm EST to whenever Sunday night.

So you're more than welcome to set up a time amongst yourselves to work out details but if you want the maxiumum number of people to run ideas off of Sunday afternoon/evening is best.

Oh and software to help with running a Traveller game is very welcome IMO.

Casey (back to Sunken R'yleh)

 

[TheEngineer]

Hi,

next turn....

In order to get away from "religous questions" we could proceed and concentrate on the model view level of the software

(I would not like to use UML for that...)
But nevertheless its perhaps really a good idea to switch to Java as soon as
possible, because of free compilers, IDEs and stuff.
As I implemented the major pieces as "classes" a migration would be quite easy.


Back to the simulator....

<QUOTE Kaledorn>
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?
</QUOTE Kaledorn>
Its correct.
Actually both ships are driven by the computer.
Each ship is driven by a basic motivation/mode, which can be set in the ships configuration.
Right now I use three modes:
- attack - engage target
- breakout - evade for a little time
- flee - get away from other ship
The combination of initial modes defines the simulated scenario.
As I stated in a earlier post I´ve already implemented transition possibilities between attack and breakout.

I would be glad to get some suggestions about additional useful modes.

Regarding the "hits at visual range" topic :
For current development I would like to implement the pure MT ruleset, because its the only official source of more or less detailed requirements.
When I finished the "rule friendly" version I will proceed to implement "best practice" rules. Here we can start "making a good game"
As we got no official comment to that topic right now, I tend to implement a user controlable switch, so he can choose for himself.
But, if we consider armor for these critical hits, in which way could we do that and also stay near to the MT space combat ruleset ?
Any suggestions ?
Add an additional task roll with an armor DM ?

And now something about "movement":

<QUOTE>
----------------------------------------------

Will try....
- calculate perfect thrust vector =
theoretical thrust vector to reach enemy
- adapt thrust vector to maneuver drive limit,
hold heading
-----------------------------------------------
hold heading?
</QUOTE>
The adapted thrust vector keeps the same direction as the "perfect" thrust vector.
Just the "length" is limited to the maximum
drive g-rating.
So, if the perfect vector would be (30,0) the
adapted vector would be (5,0) for a 5g maneuver
drive ship.

Navigation errors:
O.k, lets call it navigation errors in the future

Ship rotation:
I do not handle ship rotation capabilities when dealing with movement.
The thing I do, is to use the agility task check
in order to bring spinal mount weapons into correct position (special rule spinal mount aiming) during attack sequence.
There was a nice thread in the TML (1 or 2 months ago) about agility and rotations and related stuff).
Sadly I did not found any official data about ships rotation....

Brake/Flee:
I´m still looking for better algorithms....

Well, actually I start to implement "skills" as a ships attribute group in order to be able to use a tactical skill pool and to replace the computer DM by the appropriate skill DM.

During the next days/weeks I will try to offer a public download possibility for the alpha version of the program/sources hosted in my domain web space.

What about this IP stuff ?
Am I allowed to publish any free software dealing with MT space combat anyway ?

If so, Kaladorns idea about a generic system, which is "customizable" in order to fit into different combat schemes (MT/CT ..) is very interesting...


Regards,

Mert

 

[FlightCommanderSolitude]

I've been toying around with building a High Guard simulator in Perl, the idea being to model the rules as precisely as possible. I'd like it to be able to run in both an interactive mode and a batch mode, so I could either test my fleet against a computer opponent, play against another person (maybe over the internet...), or have two computer opponents slug it out.

Interface-wise it would be very dull and boring: just text. I'm far more interested in the guts.

One key concept I came up with was the "doctrine" object, which would be consulted whenever a decision had to be made about a game situation. There are a number of "decision-points" in the HG combat sequence where a player needs to take action, but they are fairly well defined in typical wargame fashion. So, given (a) the state of the game and (2) an action to be performed, the doctine object would cough up a response. This would mean coming up with a complete set of "decision-points", which I think is doable.

For example, at the start of every turn, each player decides the composition of his line and reserve; also, they decide whether to launch or recover small craft. So that's two "decision-points" right there. Thus, one of the functions of the doctrine object would be to look at the state of the game and decide which ships to put in the line and which in reserve.

Each combatant fleet would have a doctrine object attached to it. The idea then would be to come up with several different doctrines (aggressive, defensive, simple, complex, Imperial, Zhodani...) so you could pick and choose. There would also be a special interactive doctrine, which would present a menu of options to a human combatant.

The possibilities here are endless; each doctrine object could be as simple or as complex as desired. Thus, formation step could be just "put all vessels into the line", or it could involve in-depth calculations or subtle gambits.

Since most of the rest of HG combat is table-driven, this doctrine stuff is the only really meaty aspect of the code. If anybody has any comments on this idea, I'd be intrigued to hear them.

 

[robject]

Sounds like a good idea, Commander S. Please post your designs to this forum, and I'll start writing perl packages. And Kaladorn, keep us posted on your designs, so to speak.

I'm a perl expert, been at it since '95, and I'm Java certified -- been at that since '99. But I'm a frustrated programmer. Frustrated because I want to write a Traveller app but always got derailed.

I've tried for many years to write TOL -- Traveller On-Line -- but never got past CGI. I've designed tables and filled them with data, and thought about the communication protocol over and over, and even toyed with client applications, but haven't yet done anything interesting. Sigh.

What I'd like to do is have something like WebStart to manage the client versioning, and perhaps use RMI to deal with the protocol -- just pass Query/Response objects back and forth.

My idea of a GUI would be a canvas representing a bird's eye of the player's current location, which would update regularly with temporal data from the server. Graphics would be primitive (anyone remember MULE?). The player would be able to see what and who is around. The player would have to manually 'walk' around the starport, purchasing cargo to load on his ship, filing flight plans, and getting maintenance done on his ship. Once he boards and leaves port, he or his pilot makes for their destination, allowing for detours for skimming or sundry other interplanetary tasks [piracy or anti-piracy, forex].

An ideal implementation would let the player leverage his motor skills, cleverness, awareness, or business acumen, so different people can enjoy different aspects of the game. Motor skills would help gravitational maneuvering, for instance, and problem-solving could help someone decipher the transponder signal patterns from incoming vessels ("That's a trader. That's a patrol ship."). Good awareness might clue someone in on, for instance, how jumps are affected by nearby masses.

NPCs run the mundane aspects of TOL: as traders, they ply interplanetary trade routes, while transports move goods insystem where necessary.

One table in the database is called 'routes', and simply contains pairs of port-ring/ray coords and their distance apart in parsecs. A basic NPC owning a ship can simply pick a destination in his range, file his flight plans, and head off to the next system. With enough NPC freighters, a player might not even need a starship.

Theoretically, a PC need not be his own pilot, either. NPCs, or even PCs, can fulfill starship roles, thus earning regular pay. I don't see how this can be made very useful or meaningful, but it is possible.

 

[kaladorn]

Originally posted by robject:
What I'd like to do is have something like WebStart to manage the client versioning,

A generally accessible VCS is a good idea.


I have friends who have written an on-line engine for Full Thrust via PBeM. The graphics and the interface aren't too bad, and it can manage fights with many ships on a side. I just wish their source was available (it isn't, for IP reasons) and that it was a wee tad more portable. Something like that would be great as a generic sci-fi space combat game if you could make it table driven and populate data tables in a database with particulars of the overall game system you wish to work under. Thus the game itself could avoid being wrapped up in IP issues, and the players could load in various weapons and ship designs and all the system would provide is an interface and some processing engines.

But to make such a generic tool would take a fair bit of thought, a lot of work, and I'm not sure how worthwile such an expenditure of time would really be. Java wouldn't be a bad choice, for platform portability, but I hate UI programming and know less than zero about Swing.

Anyway, there are lots of fish to fry in the computer side of our gaming industry...

 

[Ayuir]

If everyone can wait a few months I may be able to help with the vector intercepts. I few years ago I used to do that in the USAF.

They had/have a pretty good system that is designed to calculate intercepts based on the known/believed maneuver characteristics of both the target and interceptor. I used to teach it and also did quite a bit of simulation work with it.

Once I get some time (I'm attending EOD school right now and barely have time to lurk) I may be able to recreate some of that work.

David

 

[TheEngineer]

Hi,

just a question for roadmap planning.

Regarding the ongoing work with my space combat sim software and possible developments:

- would it be a nice feature to implement fleet battle simulation capabilities, or

- would it be more interesting to migrate to the space combat rules of another Traveller dialect.

Need some suggestions..

Regards,

Mert

 

[kaladorn]

You know my interest is in a generic simulator, but having a system capable of handling multiple traveller versions is an interesting idea.

Here's a question you might ask:

Why?

By that, I mean what is the target? A tool for a ref running a one on one RPG battle and desiring a detailed resolution? A ref wanting to run fully automated large fleet engagements for campaign background? Something else?

These colour what you'll really be doing.

 

[TheEngineer]

Hi,

finally I reached a kind of milestone regarding my software project.
The thing is working quite well now and also supports vector movement in a rectangular or hex grid (I now hate hex grids) environment.

Thinking about the very basic questions - as mentioned by Thomas in the last post, I would define the following targets of the software:

- automatic simulation of one on one battles in order to optimize starship design
- support for a referee to get to hit/to pen task difficulties

In order to improve the usefulness for the referee I will do the following:
- implement a more easy interactive way to define starships position and movement
- implement an easy way to modify certain ship stats
- implement an option view there to hit/to pen values are presented continuously

Well, at least I still have to implement the interupts stuff (which way of use seems to be clearified with the help of Aldan and Thomas...).

The next major work I will start is to convert the simulator to the HG ruleset, because thats not so far away from MT.

About possible ways to design a generic space combat system I am going to think about in december - here I have got holiday.

Besides I have got another question about sensoring (indirectly related to hit resolution), which is posted to the fleet department, because of its a kind of general question.

Regards,

Mert

 

[robject]

THREAD RESURRECT

Originally posted by 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

I've recently been thinking about getting re-certified for Java, so this would be a good project for me to do.

Here are the potential classes involved.

</font>

• "Game" - primary container</font>
• "Squadron" - container - all of one side's ships</font>
• Group - one local batch of combatants</font>
• Ship</font>
• Ship state</font>
• Ship System (CPU, Hangar, Bridge, Laser, Missile...)</font>

 

[The Oz]

If there's anything (except programming, which I can't do) I can do to help you, robject, just let me know.

 

[robject]

Design is simply knowing what each piece is responsible for (i.e. which rules each piece executes) and how to "think" about the problem space.

For example, each battery records damage against itself, but also probably sorts its targets, based on how likely it is to damage them. If you figure out how to calculate the probability for a weapons system to damage a target, then that's probably a big help.

Any other "big picture" rules of thumb could be helpful. Obviously a lot of the decision making requires number crunching.

 

[The Oz]

I wouldn't try to fully automate targeting; I think a good setup would be to have a "target selector" which the user could move from possible target to possible target, and the program would tell the user:

1. How many batteries of each kind of available weapon would be needed to reduce the target to impotence.

2. How many batteries of each kind of available weapon would be needed to reduce the target by one hit on every kind of weapon.

3. How many batteries of each kind of available weapon would be needed to get one certain hit on the target.

Then the user would choose (from a pull-down menu) how many of what kind of available batteries would be fired at that target.

If you want to automate the targeting process I would set up the logic so that the program allocates fire to the enemy ships with the most dangerous firepower first (ships with spinals, and then missile ships), and uses meson guns against heavily armored ships, spinal PAs against big ships with light armor, and missile batteries against lightly protected ships.