Modeling (naval) history on computer.
January 2nd, 2009 From
>X-Authentication-Warning: ecom6.ecn.bgu.edu: mslrc owned process doing -bs
>Date: Mon, 22 Sep 1997 15:00:10 -0500 (CDT)
>From: “Louis R. Coatney”
>X-Sender: mslrc@ecom6.ecn.bgu.edu
>To: mahan@microwrks.com, marhst-l@qucdn.queensu.ca,
> milhst-l@ukanvm.cc.ukans.edu, wwii-l@ubvm.cc.buffalo.edu
>Subject: Re: Modeling (naval) history on computer.
>Precendence: bulk
>Sender: mahan-owner@microworks.net
>Reply-To: mahan@microworks.net
>
>
>Mahan, Marhst-L, Milhst-L, WWII-L,
> I don’t know if we should *pursue* this thread at all. However,
>I thought you might be interested in David Ferris’s depthy description
>of all the thinking that goes into creating a naval history games
>system … for miniature ships, in this case … for/on a computer.
>(His follows my comments.) David is the leader in this hobby field.
>(He also works with a Barne Strousdrup(sp?) who authored C++ ?? )
> Simulations are models … but of historical *events*, rather
>than the *physical* structure of the equipment/ships, themselves.
> Again, such gaming has done much to popularize (military and
>naval) history … to everyone’s benefit.
>
>Lou
> Coatney, mslrc@uxa.ecn.bgu.edu
>
>———- Forwarded message ———-
>Date: Mon, 22 Sep 1997 14:27:21 -0500 (CDT)
>From: “Louis R. Coatney”
>To: Conflict simulation Games
>Subject: Re: “Naval Action” UI( user interface)s
>
>Dave,
> Thanks for your thorough description of all the variables/input
>you include in SHIPBASE 3. Impressive. 🙂
> Computerized/Pascal “Naval Action” is *much* simpler … and it would
>probably be simpler for you to see it when I am finished than for me
>to try to describe it to you, here.
> I won’t be encrypting the code/programming, I don’t think.
> I would like people to be able to see for themselves how the
>program works … and be able to critique/modify it for their own
>personal use. … and Pascal *is* educational/readily readable in
>that respect. (If you remember, one of the criticisms of any computer
>game, generally, is that it’s just a “black box” whose variables
>cannot be seen/understood like a manual game’s.)
> Again, thanks for sharing all the thought that you have put in
>SHIPBASE 3.
>Lou
> Coatney, mslrc@uxa.ecn.bgu.edu
>
>On Mon, 22 Sep 1997, David Ferris wrote:
> > From: David Ferris
> > To: Multiple recipients of list CONSIM-L
> > Newsgroups: bit.listserv.consim-l
> >
> > Lou Coatney on his Pascal program to do computer-assist naval:
> >
> > > There are really only 3 inputs/outputs … excepting
> > > torpedoes: Speed changes, target allocation, and whether or not
> > > the shell hit … and I’m not explaining that one, until I’ve
> > > finished the program. 🙂
> >
> > Okay, you lost me completely.
> > Based on this paragraph from your previous message:
> >
> > > Hmm … Even with a 286, 10 outcomes a minute should be easy. Does
> > > SB3 input gunfire/torpedo allocations and resolve/output them
> > > one-at-a -time??
> >
> > I’m making the assumption (which might be completely incorrect) that you
> > have your program resolving gunnery one turret (or one gun) at a time.
> > SB3 is designed to do fleet actions (up to 300 ships per scenario, plus
> > up to 300 squadrons of aircraft each of which can have up to 200
> > airplanes etc. etc. etc.) so I have it resolve combat one ship at a
> > time, not one turret (or gun) at a time. You select the firing ship from
> > a menu that lists all the ships in the scenario, then you select the
> > target ship from the same menu. (This scrolling menu is where the older
> > 8088, 8086, and 80286 machines bog down with larger scenarios; they do
> > okay with 20 or 30 ships or so, but the 80+ ship scenarios like Jutland
> > take a long time to scroll on anything older than a 286/8.) Then you get
> > a parameter screen where you input the range (in inches), number of guns
> > firing from the primary/secondary/tertiary batteriesm, type of ammo,
> > smoke, target attitude, whether or not your gown is too tight for you to
> > walk up the stairs at the award ceremony (ooops, wrong e-mail) and all
> > that. Most of the time the settings for smoke/ammo/gown/etc. are the
> > same as the last target and default to the correct check boxes, so most
> > of the time all you have to do is enter the range and hit the fire
> > button. The program rolls for each shell fired and tells you the
> > results: number of hits, hit location, duds, amount of damage done, and
> > critical hits.
> >
> > If you’re resolving gunnery by turret (or by gun barrel) that’s fine,
> > but you shouldn’t expect to be doing large fleet actions if that’s your
> > scope. If you’re doing fleet actions, each player represents an admiral
> > in charge of a formation of ships. If you’re resolving by turret, each
> > player is doing the role of a gunnery officer. Different points of view
> > that IMO don’t work well when done simultaneously in large fleet games,
> > but some folks do play it that way.
> >
> > Either way, I assume you’re using arrays in your record structure.
> > Single dimension arrays are best if you’re trying to save memory, 2- or
> > even 3-dimension arrays are fine if you’re comfortable using them. (I
> > don’t recall if Pascal lets you use 3-d arrays. Never mind.) At any
> > rate, you should be indexing your data structure by ships (the Bismarck
> > is ship #1, the battleship formally known as Prince is #2, the Hood is
> > #3…) so the program can keep track of your ship data. You should have
> > record fields for the important stuff like number and type of guns,
> > amount of ammo, armour thicknesses. If you want to get fancy you can get
> > into turret configuration and clever armour layout info. Also make
> > yourself a field (or better yet, several fields) to keep track of which
> > target the firing ship shot at last. This serves at least two purposes:
> > the program then knows who to default to as your next target (saving you
> > lots of keystrokes) and it then automatically knows whether or not you
> > get the bonus for training your guns on the same target.
> >
> > You want your UI to do as much of the work for you as possible. Typing
> > is bad. If you have to type in ship names (or worse yet, ID codes) every
> > time you do a combat, the UI needs work. Menus are good. Check boxes are
> > good. Hot keys are good, just make sure you put a message somewhere on
> > the screen (as opposed to hidden deep in the instruction book that
> > nobody is going to read) what they are and what they do. Mousing is best
> > (sorry, you few surviving mouse haters out there.) If you can get the UI
> > to the point where you can process entire combats with just a few mouse
> > clicks, that’s very good. We almost got there with the current version
> > of SB3; you still have to type in the range, unless it’s the same range
> > as the previous combat, otherwise you can get all the way through with
> > just a few mouse clicks and some scrolling.
> >
> > If you intend for other people to use your program, reading the
> > instruction manual should not be required. (“Idiot-proofing”, or as we
> > called it in the military, “soldier-proofing”.) I evaluate software
> > packages as part of my “real” job. If I can’t figure out how to use a
> > program just by playing around with the menus, the package goes
> > instantly into the circular file. (By “figure out” I don’t mean being
> > able to understand every subtle nuance and knowing how to use every
> > single function, I mean I should be able to get a feel of what the
> > program does and get some rudimentary functionality out of it just by
> > poking around the screens and menus.) Having to type in ID codes or
> > arcane commands (especially if they’re not documented on the screen) is
> > fine for your personal use, but you’ll be hard pressed to find many
> > other people who are willing to use the program, no matter how powerful
> > and spiffy the underlying code is. As I said, the UI will make or break
> > the project. When I take a look at a new program and the first thing it
> > does is blank the screen and ask a single question: “ENTER SHIP NUMBER?”
> > it goes right into the recycling bin. Usually the programmer’s response
> > to this is “But you have to read the (100K+) documentation file before
> > you can run the program!” This is acceptable to some people, but my
> > response is usually either to go play Mechwarrior or to give a long
> > boring lecture on software interface design.
> >
> > Having said all that (at great length, mind you) there’s no “correct”
> > way to go about this, since in the final evaluation this is hobby stuff
> > we’re talking about. Following the old coders’ credo that any method
> > that delivers good results is a “good” method (they way the REAL gurus
> > work, not the way it’s taught in programming classes), whatever approach
> > works for you is the “right” one. At the moment, there’s a guy in
> > England who has his freebie “Salvo” computer-assist program up on the
> > web (I think he used Pascal too, judging from the look of his screens),
> > the guy in Phoenix who is giving away his naval program for CP/M and
> > DOS, and the small companies who sell computer-assist wargame sets in
> > the UK and Australia. Not to mention all the hobbyists who wrote their
> > own programs just for their personal use; somewhere I still have a copy
> > of Andy Eisenberg’s old Apple II rendition of Sea Power. (Seekrieg? One
> > of them.) Each of the ones I’ve seen took a completely different
> > approach, and each did what the author wanted them to do, so I can’t say
> > that any approach is more valid than another, other than to reiterate
> > the lesson that the amount of acceptance the program receives will be
> > directly related to the quality of the UI.
> >
> > DLF
> > dferris@research.att.com
>
>I should mention that Dave has a webpage devoted to SHIPBASE 3 which
> he usually lists at the end of his msgs.