[MUD-Dev] Re: Let's talk about numbers.

[Brandon J. Rickman]

On Fri, 25 Sep 1998, Jon A. Lambert wrote:
> On 24 Sep 98, Brandon J. Rickman wrote:
> > On Thu, 24 Sep 1998, Jon A. Lambert wrote:
> > > ...
> > Okay, say there are 3 interesting numbers: Zero, One, and Many. 
> > Since 3 is not interesting we should call it Many.  There are Many
> > interesting numbers.  Or there are 4 interesting numbers: Zero, One,
> > 3, and Many.
> > 
> > You are advocating a very rigid and inhumane programming practice. 
> 
> Is it?   Assume you are designing a mud and you decide upon modeling 
> 3 stats.   Your mud has been running for about a month and you've hit 
> upon some good ideas and desire to extend your design to model 2 
> additional stats.  If your implementation has assumed 'many' as 
> opposed to '3' is it more easily modified?   Does this mean your 
> original design was bad because you failed to originally document the 
> need for the 2 additional stats, or good because you were able to 
> modify your design because your implementation assumed extensibility?

My concern is about the numbers that are somewhere between human
understandable numbers (5 stats, 425 hit points, 100k experience) and
MAXINT.  With a tidy and extensible implementation there will be no
warning when some code leak starts appending 1000 element lists together.
(A cooked up example: 'drop all' takes a character's contents list and
simply appends it to the location's contents list.  But there's a bug and
the character's list doesn't get cleared under certain conditions.  A mob
is programmed to pick up stray items and 'drop all' at a certain
location...)

There are also extensibility problems when trying to move from a 1 value
to a Many value, such as when a single flag reference is replaced by a
list of flags.  Does that mean you have to enforce mandatory array access
on all data types?

I think eventually this becomes a development issue, not a design issue.
Development can get a little preoccupied with extensible code, so design
has to yank the numbers back into a functional area.  Design is more of a
challenge when there are constraints, when there is a sandbox to play in.
Development tends to obfuscate constrains ("all code must be object
oriented") in the name of correctness.

> > Some thought should go into how numbers are important to the game,
> > not to the CPU.  Player stats ranging into the thousands would be
> > irritating, stats in the millions incomprehensible.  A player
> > walking around with 2^31 coins in her pocket is still a bug, even if
> > the code is bulletproof.
> 
> I'm not saying that assuming 'many' is to assume 'infinity' nor the 
> limits of the CPU.  I probably shouldn't have parenthesized 
> 'infinity'.   Although it can't be discounted as a possibility in 
> some scientific applications.  Yes there are often damn good reasons 
> to impose limitations on 'many' in order to catch errors.  A string 
> that expands to 1 megabyte may be an error.  Then again, it might 
> also be a .jpeg file.  And there are often times when it is good 
> practice to make an astract data type that exceeds the limitations of 
> you CPU.  A 64-bit integer class on a 32-bit machine for instance.  
> Later the class can be easily replaced by a true 64-bit integer.  
> Depending upon bit flags and bit masks is another problem.  Look at 
> my object-wear model on my web pages for an outstanding example of 
> bad design.  (My only defense is that it was designed to be 
> integrated into a server whose design was already shot to hell with 
> magic-numbers ).

There is a point at which the existence of 64-bit+ integers can paralyze
design.  It is characteristic of why this year's new games won't run on
last year's machines: new games have become a kind of demo software to
show how spiffy the newest machines are.  Instead of saying "you _can_ use
64-bit integers" designers are told "you _have_ to use 64-bit integers".
It is a kind of negative constraint.

I tend to have more respect for a good hack.

- Brandon
ashes at zennet.com