April 1997
- From out of the shadows... Dan Mazeau
- Introduction Shawn Halpenny
- Introduction Nathan Yospe
- Introduction Chris Gray
- Introduction coder@ibm.net
- Introduction S001GMU@nova.wright.edu
- Introduction Jeff Kesselman
- Introduction Chris Gray
- Introduction Mik Clarke
- Introduction Caliban Tiresias Darklock
- Introduction Mik Clarke
- Introduction Caliban Tiresias Darklock
- Introduction J C Lawrence
- Introduction Elia Morling
- Event-driven? Michael Hohensee
- Event-driven? Nathan Yospe
- Event-driven? coder@ibm.net
- Event-driven? Jon A. Lambert
- Event-driven? Adam Wiggins
- Event-driven? Shawn Halpenny
- Event-driven? Chris Gray
- Event-driven? coder@ibm.net
- (subject missing) Dan Mazeau
- A late introduction Jon A. Lambert
- Re-Introduction S001GMU@nova.wright.edu
- New guy Walter Goodwin
- New guy coder@ibm.net
- Socket Stuff Shawn Halpenny
- database stuff Chris Gray
- So in an event-driven server, how do you ... Michael Hohensee
- So in an event-driven server, how do you ... Nathan Yospe
- So in an event-driven server, how do you ... S001GMU@nova.wright.edu
- So in an event-driven server, how do you ... Chris Gray
- So in an event-driven server, how do you ... clawrenc@xsvr1.cup.hp.com
- So in an event-driven server, how do you ... clawrenc@cup.hp.com
- Off on the languages tangent! Chris Gray
- Yet Another Introduction Reed D. Copsey, Jr.
- Yet Another Introduction Nathan Yospe
- Yet Another Introduction clawrenc@cup.hp.com
- Yet Another Introduction clawrenc@cup.hp.com
- Yet Another Introduction Adam Wiggins
- Yet Another Introduction Dmitri Kondratiev
- self-intro: Cynbe Cynbe ru Taren
- Unique id's Chris Gray
- Unique id's clawrenc@cup.hp.com
- Unique id's Jon A. Lambert
- Unique id's coder@ibm.net
- Unique id's Jon A. Lambert
- Unique id's coder@ibm.net
- Unique id's Jeff Kesselman
- Unique id's clawrenc@cup.hp.com
- Unique id's Jon A. Lambert
- Dupes are my fault (again) coder@ibm.net
- six degrees of submission ... er, compilation. Cynbe ru Taren
- six degrees of submission ... er, compilation. Jeff Kesselman
- Java as a mudserver language Cynbe ru Taren
- Java as a mudserver language Jeff Kesselman
- Execution Chris Gray
- Using system time for ObjectIDs clawrenc@cup.hp.com
- short absence Chris Gray
- short absence coder@ibm.net
- Hello! Ross Nicoll
- Ho hum (clarifiyign AI terms) Jeff Kesselman
- Ho hum Ling
- Ho hum Nathan Yospe
- Ho hum coder@ibm.net
- Ho hum coder@ibm.net
Forwarded copy of an email between Ling and I:
On 25/11/97 at 08:38 PM, Ling <elkll@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@null.net
----------(*) Internet: coder@ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...
--
J C Lawrence Internet: claw@null.net
----------(*) Internet: coder@ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...
- Fw: Just a bit of musing Travis Casey
- Risk Assessment -- was (Ho hum) Jon A. Lambert
- Who is Steward and what can he do for me? Jon A. Lambert
- Who is Steward and what can he do for me? clawrenc@cup.hp.com
- Who is Steward and what can he do for me? Chris Gray
- project management (or coding, kings, and other things) Jon A. Lambert
- Threads and Sockets (Was Ho hum) S001GMU@nova.wright.edu
- Threads and Sockets (Was Ho hum) Jeff Kesselman
- Threads and Sockets (Was Ho hum) S001GMU@nova.wright.edu
- Threads and Sockets (Was Ho hum) clawrenc@cup.hp.com
- Threads and Sockets (Was Ho hum) Chris Gray
- Strings & Memory Usage Greg Munt
- Strings & Memory Usage clawrenc@cup.hp.com
- Strings & Memory Usage Jeff Kesselman
- Strings & Memory Usage Shawn Halpenny
- Strings & Memory Usage ashen
- Strings & Memory Usage Chris Gray
- Steward coder@ibm.net
- r.g.m.* - worthwhile thread Nathan Yospe
- r.g.m.* - worthwhile thread clawrenc@cup.hp.com
- r.g.m.* - worthwhile thread Jeff Kesselman
- r.g.m.* - worthwhile thread Chris Gray
- (fwd) A Mud Protocol (MUD Markup Language) coder@ibm.net
- Ho hum (Sockets) Ling
- Steward and other painful friends coder@ibm.net
- A Combat System (please critique!) S001GMU@nova.wright.edu
- Your Message To mud-dev Jon A. Lambert
- I'm back Chris Gray
- Changes to the list coder@ibm.net
- Oops coder@ibm.net
- Verb binding Chris Gray
- Verb binding clawrenc@cup.hp.com
- Verb binding ashen
- Verb binding Chris Gray
- Verb binding Adam Wiggins
- Verb binding clawrenc@cup.hp.com
- Verb binding S001GMU@nova.wright.edu
- Verb binding Shawn Halpenny
- Verb binding Chris Gray
- Verb binding clawrenc@cup.hp.com
- Verb binding Chris Gray
- Why have a combat state? Jeff Kesselman
- Why have a combat state? clawrenc@cup.hp.com
- Introduction Jamie Norrish
- Introduction S001GMU@nova.wright.edu
- Introduction clawrenc@cup.hp.com
- Introduction Jeff Kesselman
- Introduction clawrenc@cup.hp.com
- Introduction Chris Gray
- Introduction Travis Casey
- Introduction Jeff Kesselman
- Introduction scherecwich@angelfire.com
- Introduction Jon A. Lambert
- Introduction Chris Gray
- (fwd) Issues from the digests and Wout's list Raz
- (fwd) Issues from the digests and Wout's list Chris Gray
- (fwd) Issues from the digests and Wout's list clawrenc@cup.hp.com
- (fwd) Issues from the digests and Wout's list Raz
- (fwd) Issues from the digests and Wout's list Chris Gray
- (fwd) Issues from the digests and Wout's list clawrenc@cup.hp.com
- (fwd) Issues from the digests and Wout's list Chris Gray
- (fwd) Issues from the digests and Wout's list clawrenc@cup.hp.com
- (fwd) Issues from the digests and Wout's list Oliver Jowett
- (fwd) Issues from the digests and Wout's list Chris Gray
- (fwd) Issues from the digests and Wout's list clawrenc@cup.hp.com
- (fwd) Issues from the digests and Wout's list Raz
- (fwd) Issues from the digests and Wout's list Miroslav Silovic
- (fwd) Issues from the digests and Wout's list clawrenc@cup.hp.com
- (fwd) Issues from the digests and Wout's list Adam Wiggins
- (fwd) Issues from the digests and Wout's list clawrenc@cup.hp.com
- (fwd) Issues from the digests and Wout's list Miroslav Silovic
- (fwd) Issues from the digests and Wout's list clawrenc@cup.hp.com
- (fwd) Issues from the digests and Wout's list Raz
- (fwd) Issues from the digests and Wout's list clawrenc@cup.hp.com
- (fwd) Issues from the digests and Wout's list clawrenc@cup.hp.com
- Me Raz
- Sendmail changes coder@ibm.net
- Reposts Adam Wiggins
- Semaphores, Mutices, fd_sets Greg Munt
- Semaphores, Mutices, fd_sets Jeff Kesselman
- Semaphores, Mutices, fd_sets clawrenc@cup.hp.com
- MUD Design Digest V1 #55 coder@ibm.net
- Me Raz
- Magnetic Scrolls' magical parser Greg Munt
- Magnetic Scrolls' magical parser clawrenc@cup.hp.com
- Magnetic Scrolls' magical parser Adam Wiggins
- Magnetic Scrolls' magical parser Nathan Yospe
- Magnetic Scrolls' magical parser Chris Gray
- Magnetic Scrolls' magical parser Ling
- Magnetic Scrolls' magical parser Chris Gray
- Magnetic Scrolls' magical parser Shawn Halpenny
- Reposts Jeff Kesselman
- Email change Alex Oren
- SUBSCRIBE Alex Oren
- (fwd) Death in Muds -(also Birth, Imprisonment, Aging, and skill development) coder@ibm.net
- fd_set limitations Greg Munt
- parsing Chris Gray