Copy Link
Add to Bookmark
Report
Doom Editing Digest Vol. 01 Nr. 318
From: owner-doom-editing-digest
To: doom-editing-digest@nvg.unit.no
Subject: doom-editing-digest V1 #318
Reply-To: doom-editing
Errors-To: owner-doom-editing-digest
Precedence: bulk
doom-editing-digest Tuesday, 20 June 1995 Volume 01 : Number 318
Romero talks Quake with IRC losers
re: DOOM PACKETS ...
Re: Romero talks Quake with IRC losers
RE: Re: Doom Limits
RE: Romero talks Quake with IRC losers
re: DOOM PACKETS ...
[none]
re: DOOM PACKETS ...
[none]
[none]
Net packets & UDS page
ADMIN note
re: DOOM PACKETS ...
re: DOOM PACKETS ...
RE: Romero talks Quake with IRC losers
----------------------------------------------------------------------
From: Murray Chapman <muzzle@cs.uq.oz.au>
Date: Mon, 19 Jun 1995 11:29:45 +1000 (EST)
Subject: Romero talks Quake with IRC losers
On Fri, 16 Jun 1995, Mackey McCandlish wrote:
> Anybody who wants a copy of the conversion Romero had with us on IRC
> about Quake in the #dwango channel ftp it from ftp.widomaker.com in the
> pub/avatar director as Romero.ZIP.
Hi there
I wouldn't be surprised if Romero never talked on IRC again, given the
inane, egotistical, selfish, and uninformed shit directed at him by those
IRC losers.
What about all the interesting questions:
(Warning... assumptions follow. Romero, feel free to debunk/confirm!)
a) Where is the conceptual split between client and server? Obviously,
the client merely transmits controller events to the server, but what is
the server sending the client?
Option 1: Processed events, similar to what the client sends the server.
Advantages: relatively low bandwidth, (cf Romero: "14.4k no problem")
Disadvantages: bad scalability (# players)
slow clients slow down entire game
universe size limited by client
Option 2: Universe updates: transformations to be performed on game state
Advantages: efficient, scales better with large # of players (maybe)
Disadvantages: entire game state must be replicated on client, etc
Option 3: Visual updates relative to individual client
Advantages: Allows MASSIVE games on a monster server, maps bigger than
would fit onto a client.... MUD-style
Disadvantages: Huge bandwidth required (modem might be problem)
Bogging down when view changes too much too quickly
Option 4: Clustered/cached visual updates (client has textures, objects,
maps, pre-loaded)
Advantages: compromise
Disadvantages: bandwidth still a problem?
Downloading initial game state
b) Customizability of server.
Customizability is on two levels: DJGPP, and the Quake langage itself.
Both client and server will be compiled with DJGPP. Full ANSI/Objective
C/C++ source code for server will be supplied, but not for client.
Will customization of server be available only thru the Quake programming
language?
Server:
Server will be an event arbitration engine: updates its universe state
depending on the events from the clients. Solves problems with clients
getting out of sync, also solves concurrent event problems.
Either: server source code will be modifiable to allow customization of
the game.
Or: server will have it's own "compiler" for a Quake-specific language
that "runs" objects. (confirmed by ddt)
Or: both!
Bots: Programmable objects, eg vending machines, robots, etc, which
react to inputs/interactions/game state?
According to quakeTALK, John Carmack and American McGee have confirmed
that Quake's game state will be modifiably by a god-like chararcter.
Options:
a) Can God change architecture as the game runs? Ideally, QuakeEd will
be built into the game, allowing you to modify things as the game
runs. Consistent with the reports of a real-time BSP generator.
b) Can God add/remove arbitrary objects/items from the game?
c) Obvious host for "God"/QuakeEd is the server. Can it be on a
client?
d) How is the world constructed? Wolf3d was "block" structured, and
DOOM was sector/linedef/sidedef constructed. Will it be something
like constructive solid geometry, or triangle/vector/polygon?
Client: Basically, a polygon-blitting/clipping engine? Compiled with
DJGPP and presented as .o files, hooks will be published that allow you
to connect hardware-specific addons (sound cards, VR equipment, etc).
To launch the client, you give a list of .o files you want to use, DJGPP
does a link, and then away you go.
Jeez, people! You had the man answering questions, couldn't you have thought
of a few *interesting* ones, not just "My SB16 is better than your
Roland?!?!?!"
Next time someone has a conversation with an id employee, please don't waste
everyone's time!
Pissed,
Murray
- -- Murray Chapman Zheenl Punczna --
- -- muzzle@cs.uq.oz.au zhmmyr@pf.hd.bm.nh --
- -- University of Queensland Havirefvgl bs Dhrrafynaq --
- -- Brisbane, Australia Oevfonar, Nhfgenyvn --
------------------------------
From: Murray Chapman <muzzle@cs.uq.oz.au>
Date: Mon, 19 Jun 1995 12:04:38 +1000 (EST)
Subject: re: DOOM PACKETS ...
On Sat, 17 Jun 1995 Steve=Cox%model=shop%Mat=Hou@bangate.compaq.com wrote:
> I am very familer with IPX packet's and network coding ... thats why
> I am even coming close to thinking about creating a "Spectator Client".
>
> As far as absolute positions being sent in DOOM ... there would most
> definatly have to be an absolute posistion sent "one time only maybe"
> each time the player starts off at a new location after being shot ...
Hi there
It's fairly obvious that the data communicated between nodes in a DOOM
network should be 99% the same as the LMP format: merely a 30Hz sequence of
controller state snapshots.
Given that, your Spectator Client would have to also know the architecture
of the level, so that when people bump into walls/monsters, etc, you know
that though they are holding down "forward", they can't go anywhere.
A more faesable idea would be to write a client which merely displays
for each node in the game the current state of their controls: mouse X/Y,
mouse button state, whether or not the left/forward/backwards/right/strafe
key is held down or not.
From there, you could try something more clever.
I've always wanted DOOM to support "read-only" nodes: they allow you to
wander around the world (no-clipping), viewing, but not affecting state at
all: monsters would ignore you, etc. Oh well... just wait for Quake!
Murray
- -- Murray Chapman Zheenl Punczna --
- -- muzzle@cs.uq.oz.au zhmmyr@pf.hd.bm.nh --
- -- University of Queensland Havirefvgl bs Dhrrafynaq --
- -- Brisbane, Australia Oevfonar, Nhfgenyvn --
------------------------------
From: avatar@widomaker.com (Mackey McCandlish)
Date: Mon, 19 Jun 95 03:25 EDT
Subject: Re: Romero talks Quake with IRC losers
>Jeez, people! You had the man answering questions, couldn't you have thought
>of a few *interesting* ones, not just "My SB16 is better than your
>Roland?!?!?!"
A couple things you apparently missed. None of us had any idea
Romero was showing up until just a couple minutes before hand, therefore for
the most part we were asking questions off the top's of our respective
heads. I tried to ask questions I was interested in, such as the way the
control would work and such (I was _Avatar_, of course). I personally have
very little net access (internet and game connection bbs'.. not big networks
sitting around) so those sort of questions would be trivial to me. I admit I
was somewhat curious as to how much like a MUD Quake would resemble, but the
question didn't jump to mind at that time (I don't have all my Quake
questions written down on a little card in my wallet or anything). Also..
most of us are interested in the way the actual game will play, not how the
graphics are generated. I was under the idea that we knew they would be
tmapped polys all along, not bitmaps or blocks, so I didn't ask. I DID learn
a couple things I didn't know before though, like how the sectioning of
creatures would work (head and body), how looking up/down would be handled
(automatic/keys), and how programmable the keyboard would be (completely,
unlike DOOM). Besides.. as intriguiging as things like how the networking
would be handled are, do you think those are the important things when it
comes right down to it? Isn't the essential gameplay and environment what
it's all about? Am I wrong? Look at ROTT: It has networking and options
coming out its ears.. but the gameplay bites so it's all worthless. Ok?
-*The Avatar*-
http://www.widomaker.com./~avatar
(Nifty pics of DMF there, too).
ftp: ftp.widomaker.com in pub/avatar
The key to ONE MUST FALL is knowing who the 17 hit combos
work on..
DOOM MUST FALL IS OUT! Get it from my home page or ftp site!
------------------------------
From: D.Casali@rea0808.wins.icl.co.uk
Date: Mon, 19 Jun 1995 09:41:38 +0100
Subject: RE: Re: Doom Limits
Jimmy, you may have trouble saving the level while playing it.
Try it, I have had problems with my 450k level crashing when I
try to save! it crashed randomly, not every time in every place.
You may be dismayed that no-one will be able to play your level!
Dario
------------------------------
From: D.Casali@rea0808.wins.icl.co.uk
Date: Mon, 19 Jun 1995 10:27:03 +0100
Subject: RE: Romero talks Quake with IRC losers
Losers = apt description! What I wanna know - demos - can you
fastfoward, pause, rewind etc..., can people spy on a game, join
at will? And, what's the editor gonna be like?
------------------------------
From: Alden Bates <abates@central.co.nz>
Date: Mon, 19 Jun 1995 21:36:54 +1200 (NZST)
Subject: re: DOOM PACKETS ...
On Sat, 17 Jun 1995, Satanic Psycho wrote:
> > As far as absolute positions being sent in DOOM ... there would most
> > definatly have to be an absolute posistion sent "one time only maybe"
> > each time the player starts off at a new location after being shot ...
> I'm not sure about that. I think each doom machine knows where the
> player is going to start before he dies. For example, when you play
> deathmatch with the same computers and the same network cards, I believe
> the colors are always the same and you always start in the same series of
> places.
_But_ (and it's a big but) When replaying lmps recorded on those
machines, the computer does not know what computers/network cards the
game was recorded on.
Ditto for monsters spawning on level 30 of DOOM II. Thus, all this is
not random. Does anyone have any other theories? Mine is that
deathmatch respawning and monster spawning is determined somehow by the
players actions, possibly even determined by the direction the player is
facing at the time, and or position in the level...
Alden Bates
------------------------------
From: Bernd Kreimeier <Bernd.Kreimeier@nero.uni-bonn.de>
Date: Mon, 19 Jun 1995 12:11:02 +0200
Subject: [none]
approve HJKL
From doom-editing-owner@nvg.unit.no Fri Jun 16 15:06:06 1995
Received: from mail02.mail.aol.com (mail02.mail.aol.com [152.163.172.66]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id PAA10576 for <doom-editing@nvg.unit.no>; Fri, 16 Jun 1995 15:06:04 +0200
From: AFree120@aol.com
Received: by mail02.mail.aol.com
(1.37.109.11/16.2) id AA269907919; Fri, 16 Jun 1995 09:05:19 -0400
Date: Fri, 16 Jun 1995 09:05:19 -0400
Message-Id: <950616090518_96085049@aol.com>
To: doom-editing@nvg.unit.no
Subject: Re: Good editors...
David Wallace:
I can't help you with the texture alignment but can you help me with --
How can you add more trigger options than DCK has to pick from. I know there
are fast doors, fast elevators etc.Can you type in the number for the new
triggers some way? Also I have ENDDOOMER. A program to change the end screen
after you exit a level. Are you familiar with it and how do I ad it to levels
made with DCK? Next time: SOUND and new GRAPHICS!
------------------------------
From: Greg Lewis <gregl@umich.edu>
Date: Mon, 19 Jun 1995 06:31:02 -0400 (EDT)
Subject: re: DOOM PACKETS ...
> _But_ (and it's a big but) When replaying lmps recorded on those
> machines, the computer does not know what computers/network cards the
> game was recorded on.
LMPs record the player color as part of their information. Apparently
that is the only information (other than skill/level/etc) that Doom needs
to play correctly.
> Ditto for monsters spawning on level 30 of DOOM II. Thus, all this is
> not random. Does anyone have any other theories? Mine is that
> deathmatch respawning and monster spawning is determined somehow by the
> players actions, possibly even determined by the direction the player is
> facing at the time, and or position in the level...
There is a section of 256 "random" bytes located in the exe, as found
by Matt Fell. I have a suspicion that Doom uses a "random" table, and
just uses the same sequence over and over. So why doesn't Doom play
exactly the same way every time? Because the player never does exactly
the same thing every time. For LMPs, the player DOES do exactly the same
thing, thus the monsters react exactly the same, and it can be played
back no problem.
Greg
------------------------------
From: Bernd Kreimeier <Bernd.Kreimeier@nero.uni-bonn.de>
Date: Mon, 19 Jun 1995 12:11:28 +0200
Subject: [none]
approve HJKL
From doom-editing-owner@nvg.unit.no Fri Jun 16 19:20:42 1995
Received: from mailgate.ericsson.se (mailgate.ericsson.se [130.100.2.2]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id TAA12501 for <doom-editing@nvg.unit.no>; Fri, 16 Jun 1995 19:20:41 +0200
Received: from aachen.ericsson.se (aachen.eed.ericsson.se [164.48.130.2]) by mailgate.ericsson.se (8.6.11/1.0) with SMTP id TAA02550 for <doom-editing@nvg.unit.no>; Fri, 16 Jun 1995 19:20:35 +0200
Received: from chapelle.aachendom by aachen.ericsson.se (4.1/SMI-4.1/AACHEN1.2)
id AA12023; Fri, 16 Jun 95 19:20:35 +0200
Received: by chapelle.aachendom (4.1/SMI-4.1)
id AA27945; Fri, 16 Jun 95 19:20:34 +0200
Date: Fri, 16 Jun 95 19:20:34 +0200
Message-Id: <9506161720.AA27945@chapelle.aachendom>
To: doom-editing@nvg.unit.no
Subject: Re: Doom Limits
From: Raphael.Quinet@aachen.eed.ericsson.se
Reply-To: Raphael.Quinet@aachen.eed.ericsson.se
> If you take a look in the information option in the help menu you will see
> that DCK does have a 8192 sidedef limit. (i.e. 0 sidedefs free) It must be
> a bloody big level. Are you sure you need it to be that big?
> As far as I know none of the other editors handle more than that either,
> so I conclude that it is a Doom limit.
I would be interested in seeing that level. The 8192 sidedefs should not
be a problem for DEU 5.3, although I have never tried a level with so many
sidedefs. Could you either tell me where I can get this level, or try the
latest beta version of DEU 5.3 (beta 9) on it and tell me how it goes?
> A similar question I have is that I have 52 triggers in my level. As
> soon as I run over the 52nd the entire computer crashes and hangs. If I
> remove the section it works fine. Is this a limit?
>
What crashes? Doom or your editor? If it is Doom, then you should check
how many sectors are triggered by all your special linedefs. Maybe you
reached the "plats" limit.
- -Raphael
------------------------------
From: Bernd Kreimeier <Bernd.Kreimeier@nero.uni-bonn.de>
Date: Mon, 19 Jun 1995 12:10:38 +0200
Subject: [none]
approve HJKL
From doom-editing-owner@nvg.unit.no Fri Jun 16 05:04:49 1995
Received: from aviator.cis.ufl.edu (thoth@aviator.cis.ufl.edu [128.227.224.17]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id FAA07322 for <doom-editing@nvg.unit.no>; Fri, 16 Jun 1995 05:04:45 +0200
Received: from localhost by aviator.cis.ufl.edu (8.6.12/cis.ufl.edu)
id XAA11442; Thu, 15 Jun 1995 23:04:27 -0400
Message-Id: <199506160304.XAA11442@aviator.cis.ufl.edu>
To: doom-editing@nvg.unit.no
Subject: Re: Doom Limits
In-reply-to: Your message of "Fri, 16 Jun 1995 11:58:06 +1000."
<199506160158.LAA01697@manuel.anu.edu.au>
Date: Thu, 15 Jun 1995 23:04:27 EDT
From: Robert Forsman <thoth@cis.ufl.edu>
zorro@spirit.com.au (Jeremy Riley) ,in message <199506160158.LAA01697@manuel.an
u.edu.au>, wrote:
> >If you take a look in the information option in the help menu you will see
> that DCK does have a 8192 sidedef limit. (i.e. 0 sidedefs free) It must be
> a bloody big level. Are you sure you need it to be that big?
> As far as I know none of the other editors handle more than that either,
> so I conclude that it is a Doom limit.
Hah. PFME (in beta release 2 right now) will allocate memory until you run
out of swap (at which point I expect it would crash horribly).
I love C++. You write one template class to do a dynamically expanding
array and, bingo, it just works from then on.
------------------------------
From: Bernd Kreimeier <Bernd.Kreimeier@nero.uni-bonn.de>
Date: Mon, 19 Jun 1995 13:08:30 +0200
Subject: Net packets & UDS page
A reminder: there's a UDS errata www page at
http://www.nero.uni-bonn.de/~bernd/uds.html
that contains some updates to the UDS, including
network package data which has been posted on
a.g.d a *long* time ago. Closely related to the
LMP data, and pretty much worthless, as you need
an excact copy of the doom-engine to get a
"current state" from incremental updates.
I'm pretty busy right now, thus I haven't been able
to include the "crossing linedef/linedef on top" stuff
discussed here lately (I'm reading the digest,
or, more precisely, I'm keeping the digest, will
read it later :). If nobody volunteers to send
me a short summary, I'll add the stuff to the "Errata"
myself, later. Same for the NOISE debug feature of
Heretic (Raphael already sent me some stuff from
r.g.d.m).
B.
B
------------------------------
From: Bernd Kreimeier <Bernd.Kreimeier@nero.uni-bonn.de>
Date: Mon, 19 Jun 1995 13:16:34 +0200
Subject: ADMIN note
Just to let you know: as I'm one of the acting
caretaker's of doom-editing at the moment, I'd
like to inform that we decided to try a different
way of handling persistent delivery problems two
weeks ago.
If doom-editing mails delivered to a given recipient
keep bouncing for some days, we unsubscribe said
address w/o further notice, und subscribe the
unreacheable/invalid/no space left recipient to
doom-editing-digest instead. Thus decreases the
amount of delivery failure notifications to approx.
10% (read: one or two a day) per recipient.
Thus if any of you end up getting the digest, the
doom-editing mailer probably hadn't been able to reach
your for some time, and we had to move you. If you don't
like digest mode, make sure that the problem has been
fixed (feel free to contact us at doom-editing-owner,
do *NOT* use the list), unsubscribe from
doom-editing-digest, and subscribe to doom-editing
again.
Just to let you know ;-).
B.
------------------------------
From: Raphael.Quinet@aachen.eed.ericsson.se
Date: Mon, 19 Jun 95 13:56:03 +0200
Subject: re: DOOM PACKETS ...
on Mon, 19 Jun 1995 06:31:02 -0400 (EDT), Greg Lewis <gregl@umich.edu> wrote:
> LMPs record the player color as part of their information. Apparently
> that is the only information (other than skill/level/etc) that Doom needs
> to play correctly.
>
Hmmm... I think Doom also uses the number of "game ticks".
> > Ditto for monsters spawning on level 30 of DOOM II. Thus, all this is
> > not random. Does anyone have any other theories? Mine is that
> > deathmatch respawning and monster spawning is determined somehow by the
> > players actions, possibly even determined by the direction the player is
> > facing at the time, and or position in the level...
>
> There is a section of 256 "random" bytes located in the exe, as found
> by Matt Fell. I have a suspicion that Doom uses a "random" table, and
> just uses the same sequence over and over. So why doesn't Doom play
> exactly the same way every time? Because the player never does exactly
> the same thing every time. For LMPs, the player DOES do exactly the same
> thing, thus the monsters react exactly the same, and it can be played
> back no problem.
>
Right. And if you do exaclty the same thing every time, the monsters will
also do exactly the same thing. Create a PWAD in which the player is out
of reach from the monsters (e.g. in a closed room which has only a small
window so that the player can see outside) and put lots of monsters around.
Then watch what happens when you start the game without hitting any key:
the monsters kill each other in the same order every time.
Also, the monster spawner on level 30 is less random than you think. Use
whatever cheat code you want and look where the monsters are appearing.
Repeat this several times. Hint: compare the order in which the monsters
appear with the things #'s using your favourite editor. The type of each
monster changes (probably depending on your current position), but not the
place where it appears.
Anyway, back to the question that started this thread: it is not possible
to know exactly where each player is and where the monsters are only by
looking at the network packets (unless you have a copy of the source of the
Doom engine, of course). And I think it makes sense: in a multi-player
game, each copy of Doom has to compute the position of all monsters and the
actions triggered by their player (like in single-player game), so computing
the position of up to three new characters is not a big overhead. On the
other hand, sending the info for all monsters would have been a big (and
useless) network overhead.
As I already suggested to someone in private e-mail, the easiest way to
know where each player is is probably to write a small TSR which takes
snapshots of the screen. :-)
- -Raphael
------------------------------
From: Steve=Cox%model=shop%Mat=Hou@bangate.compaq.com
Date: Mon, 19 Jun 95 12:09:03 CDT
Subject: re: DOOM PACKETS ...
>Anyway, back to the question that started this thread: it is not possible
>to know exactly where each player is and where the monsters are only by
>looking at the network packets (unless you have a copy of the source of the
>Doom engine, of course).
You guys are the experts here ... but I think I am correct in saying that
in the beginning ... DOOM sends out one of MANY randomly selected posistions
that the player is initialized at start up ... Maybe a look up like another
person sayed ... but definatly a look-up index of somekind .... you
just can't hard code something like that and come out with decent results.
But I am the newbie and won't contest to your lodgic ;)
>And I think it makes sense: in a multi-player
>game, each copy of Doom has to compute the position of all monsters and the
>actions triggered by their player (like in single-player game), so computing
>the position of up to three new characters is not a big overhead. On the
>other hand, sending the info for all monsters would have been a big (and
>useless) network overhead.
Yes ... I agree ... sending "Events" or "Triggers" make far more sence.
I did find the info you steered me too ... and got the LMP format ...
I am looking into it .... But still want to find the network packet
protocals ... Even if it is specific to just one DOOM game type .
>> I am very familer with IPX packet's and network coding ... thats why
>> I am even coming close to thinking about creating a "Spectator Client".
>>
>> As far as absolute positions being sent in DOOM ... there would most
>> definatly have to be an absolute posistion sent "one time only maybe"
>> each time the player starts off at a new location after being shot ...
>Hi there
>It's fairly obvious that the data communicated between nodes in a DOOM
>network should be 99% the same as the LMP format: merely a 30Hz sequence of
>controller state snapshots.
I hope so ....
>Given that, your Spectator Client would have to also know the architecture
>of the level, so that when people bump into walls/monsters, etc, you know
>that though they are holding down "forward", they can't go anywhere.
This is a must ... thats why all the requests for reading DOOM's WADS.
The Spectator will have to have the same WAD as the one being played
in the deathmatch that the Spectator wants to view ...
>A more faesable idea would be to write a client which merely displays
>for each node in the game the current state of their controls: mouse X/Y,
>mouse button state, whether or not the left/forward/backwards/right/strafe
>key is held down or not.
>From there, you could try something more clever.
>I've always wanted DOOM to support "read-only" nodes: they allow you to
>wander around the world (no-clipping), viewing, but not affecting state at
>all: monsters would ignore you, etc. Oh well... just wait for Quake!
>Murray
I want to display the same thing a 2D level editor displays first ...
No polygons or bitmaps of players .... just a 2D map ... like when
you hit *TAB* ... and see yourself moving around ... but in the
Spectator Client ... you see the monsters or other people playing
and laugh your %$#^ off watching some poor slob walking into a trap he he he
Sending messages too all players would be awsome too ... like ...
"Your going the wrong Way !!! he's to your right !!!! ;) he he he
I don't think that would be to hard to code if I had the packet protocals.
>> As far as absolute positions being sent in DOOM ... there would most
>> definatly have to be an absolute posistion sent "one time only maybe"
>> each time the player starts off at a new location after being shot ...
>I'm not sure about that. I think each doom machine knows where the
>player is going to start before he dies. For example, when you play
>deathmatch with the same computers and the same network cards, I believe
>the colors are always the same and you always start in the same series of
>places.
As I said earlier ... I subscribe to the comment made by another
person that the starting posistions are in a look-up table ... and
a random choise is made ... and that choice is sent out over the
net during start up ... If this is true .... Yes ... I have alot of
work to do ... and probably will not even bother ... since QUAKE
is probably going to do all of this stuff anyway ... but if QUAKE
snags ... and people keep writting DOOM compatible games ... I could
be onto something ...
Just was wondering of anyone had already done alot of the work for me ;)
Steve Cox
SysOp
Houston Game Designer (713) 955-8920
VRBBS Multy-Player Game System (713) 955-7688
------------------------------
From: "C. Sheldon" <sheldonc@acy.digex.net>
Date: Mon, 19 Jun 1995 19:39:36 -0400 (EDT)
Subject: RE: Romero talks Quake with IRC losers
On Mon, 19 Jun 1995 D.Casali@rea0808.wins.icl.co.uk wrote:
> Losers = apt description! What I wanna know - demos - can you
> fastfoward, pause, rewind etc..., can people spy on a game, join
> at will? And, what's the editor gonna be like?
>
Losers!? WHERE THE HELL DO YOU GET OFF!? Generalizing like that about
THOUSANDS of people....what makes us losers? the fact that we use irc?
hmmmmmmmmmm? The fact that we actually PLAY the game!? Have YOU PLAYED
the game!? I doubt very much that many of the readers of this list
actually PLAY doom. I can tell you though that ALL of the people on #Doom
on irc DO play the game...thats what they are there for, and THAT is
what their questions were geared for, we wanna know how its gonna PLAY,
we don't care how it works, as long as it does, we don't care what kinda
network bullshit they put in, as long as we can PLAY it. If that makes us
losers then well.....I'm proud to be a loser.
- -Cliff Sheldon
DrWu @ #Doom
------------------------------
End of doom-editing-digest V1 #318
**********************************
