Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!apple!shebs
From: shebs@Apple.COM (Stan Shebs)
Newsgroups: comp.sources.games.bugs
Subject: Re: Does Stanley Shebs exist? (was Re: xconq docs)
Message-ID: <9895@goofy.Apple.COM>
Date: 22 Aug 90 23:55:44 GMT
References: <15341@reed.UUCP> <9835@goofy.Apple.COM> <15356@reed.UUCP>
Organization: Apple Computer Inc., Cupertino, CA
Lines: 87

In lieu of actually doing anything, I thought I'd get some of my reactions
on the record here...

In article <15356@reed.UUCP> minar@reed.bitnet (Nelson Minar) writes:

>weird bug that prevents units with < 10% chance of hitting other units to
>  succeed (preventing, for example, bombers from attacking each other even if
>  they have a 9% chance to hit). Patched at Reed.

This wasn't a bug.  There were two reasons to include this limitation: first,
it helps prevent some stupid behavior by the machine player code (OK, OK, there
are plenty of other stupid behaviors :-) ), and secondly, even unsuccessful
attacks consume moves, so attackers could chew up the defender's movement
allowance with very little risk.  The 10% rule was easy to do, there are
probably better solutions.

>units from teams numbered > 6 do not have the proper numbers attached to their
>  icons. This is the result of a sloppy patch to allow more than 7 players,
>  and should be easily fixed.

The limitation to 7 players wasn't entirely arbitrary - the icon design
doesn't really leave any room for two-digit side numbers, and even the
numbers 8 and 9 are very confusing in a 3x5 font displayed as red-on-green
(a real design boner - consider which form of color blindness is most common!)

>the period programming currently limits you to only 14 unit types, presumably
>  because of "limitations in the view mechanism" (maybe only a nybble for the
>  unit type?) A preliminary look through the source code did not show any
>  obvious built in limit.

I changed it to be larger once and lots of stuff broke, so I documented
the bug to avoid having to fix it.  1/2 :-)

>Restoring multi-player games is nonintuitive.

Amen to that - I'm *still* trying to think of a good way to do it!  Note that
the netwide empire-type games don't allow save/restore at all...

>give transports (cities, bombers, troop transports) the ability to be protected
>  by what is inside them. It is awfully unrealistic to read "You have captured
>  the Italian city Obnazgul, (killing 8 i)."  Those 8 infantry should be able
>  to defend their city (while the same 8 infantry might not be able to defend
>  the transport they are aboard).

That's what the "protect" parameter in the period description is for - but it
may not be set correctly in your version of the standard period.  Actually,
the parameter is a little hard to set correctly anyway, since it doesn't
always figure into the hit/capture probabilities in a plausible way.  My
conclusion is that it would have been better to hardcode more reasonable
behavior for the standard period, and not to try to parametrize the whole
program...

>stacking pieces in a hex. There is no obvious reason why a fighter cannot be
>  in the same hex as an infantry, other than the programmign headaches it
>  causes. There are multiple schemes for handling this sort of thing.

For "headache" substitute "migraine".  There are substantial hassles
with display, input, and period specification.  The designs I've seen in
other (computer and non-computer) games have been clunky and unpleasant.
I'd sure like to see some good ideas!

>an interface for finding pieces (maybe).  Seeing that your 280th infantry is
>  being pummeled is nice.  Where IS that 280th infantry? This might be a bad
>  idea.

No, this is something that ought to be done.  A "fast X display" solution is
to flick the screen over, a cheap solution is to add something like "30 hexes
NW of your current view" in the message.

>better order programming for troops. Maybe a bank of little buttons to hit in
>  addition to the key commands (do you remember if its little e or big E to
>  wait for a transport?) It would also be nice to give troops little programs,
>  rather than one order.  This might be too big of a feature.

My half-working Sunview version has buttons, they seem to be OK.

Little programs for units is getting complicated.  An alternative I've wanted
for awhile is for players to be able to specify a whole command hierarchy, so
you would only to have give the detailed orders to a group commander, and then
it would actually do the turn-by-turn movement of units, bugging you when
there is a special problem.  This could also be used to speed up the game via
"command points" that are too scarce to be wasted on the details of flying
fighters about, so you leave that to the group commanders.  I've been doing
a little experimenting, but no conclusions yet.

						stan shebs
						shebs@apple.com