Ho hum

[coder at ibm.net]

Forwarded copy of an email between Ling and I:

On 25/11/97 at 08:38 PM, Ling <elkll at student.lboro.ac.uk> said:

>How's the mud dev list doing these days?

Idling along with abour 5 - 15 messages a day.

>I've managed to get into the business again.  

<bow>

>Although, this time I'm
>trying for a tactical thing.  Game world of less than 1 km square, text
>orientated, no ascii graphics, turn based.  Imagine Aliens when Ripley is
>watching the marines get slaughtered.  The players will be
>watching/directing.

Interesting!  We have a couple new people on who are interested in such
areas.

>Anyway, could I trawl thru your archives please?  

I'm leery of letting non-list members into the archives.  Usenet still has
too much life left in it, rendering the long term survival of the list
iffy.

>I'm specifically
>looking for information about bulk containers.

There hasn't been a whole lot of discussion of bulking containers at the
implementation level.  Most has been fairly high level on the order of,
"We have bulking containers/anonymous groups/whatever and use them to
create XXX neat result..."  I think only Nathan, Adam, and I have gotten
into the nitty details at any point.

>My amazing research and design has sprung up with this:

>  Give objects a class, eg: truck, soldier

>  Go thru an area container looking for a generic class (group of trucks,
>  soldiers)

>  Repeat above for the class (group of Bedford trucks, group of UN
>  soldiers)

>  Repeat for anything else I can think of (group of mostly Bedford trucks,
>  some without trailers, group of UN soldiers, all armed with machines
>  guns, one or two carry a Clansman radio).

There are several base approaches:

  Have objects dynamically and pro-actively recognise that they are in a
grouping situation and thus create the appropriate group object.  This
also requires monitoring changes in the group state to mutate the group
object accordingly, create new groups, or destroy the current group
object.

  Have group objects created dynamically on query.  This has group objects
being ephemeral things, only created for as long as there is interest in
them, and then destroyed immediately afterward.  This can be a variation
of the first approach where objects are promted to make ephemeral grouping
objects which are then soon dismissed (The excuse being that maintaining
them and monitoring/reacting to the state changes is too expensive and
uninteresting), or a simple brute force go-out-and-determine-what-there-is
approach.

The first approach lends itself well to groups in the global namespace. 
The latter tends to lend itself better to groups in private namespaces. 
While this may seem specious, it can be a critical factor.  In games such
as you describe, viewpoint can be a critical factor.  

Consider the case of your players viewing the battlefield:

  Two players may see, and may need to interpret what they see entirely
differently.

  Bubba may see his 5th infantry advancing as a group with his 7th
cavalry.  It is useful for him to see them operating as a group as he
created that group and coordination.  

  Conversely, Boffo would merely see the infantry on one side, and the
cavalry on the other, quite likely not noting their collusion, or if he
does, having to mentally overlay that model over his reports ("Ahh!  The
infantry and cavalry are working together as so!".  
  
This gets more interesting when the members of a group are widely
scattered and thus no longer subject to the spatial proximity rules of
grouping.  A tank squadron may be widely scattered across the battlefield,
but due to the range of their guns and radio comms, able to operate as a
single concerted group.  Bubba, as onwer of the tanks, should natively see
and have this group operation reported to him.  In the general case he
should not see reports on individual tanks, as that would tend to persuade
him that they all are operating seperately.  Conversely of course, Boffo
should see seperate tanks as it is up to him to derive the fact of their
concerted action.

Next extend this to the same tank squad whish has fracted into smaller
groups, each of which is operating independantly...

>PS:  Please don't send your archives to me coz this account can't handle
>it.

No worries.

BTW:  May I cross this reply to you to the list?

--
J C Lawrence                               Internet: claw at null.net
----------(*)                              Internet: coder at ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...
--
J C Lawrence                               Internet: claw at null.net
----------(*)                              Internet: coder at ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...