[MUD-Dev] C&C and Event Rescheduling
clawrenc at cup.hp.com
clawrenc at cup.hp.com
Mon Aug 18 17:17:18 CEST 1997
In <3.0.2.32.19970815094745.00890a10 at mail.tenetwork.com>, on 08/15/97
at 10:49 AM, Jeff Kesselman <jeffk at tenetwork.com> said:
>At 04:48 PM 8/14/97 PST8PDT, you wrote:
>>clawrenc at cup.hp.com wrote:
>>> I have severe allergic reactions to tick based systems.
>>> Characteristically I prefer the "as fast as the system will let you,"
>>> model. The idea that I'll deliberately program a system so that a
>>> human can wait on a computer seems treasonous.
>Problem with thsi in the real world is it favors LPBs (low ping
>bastards) over those witha lsower connection, and bots over humans.
Yes, it favours the faster connections. My general answer to this is
that the answer is to design the game system to not rely on user
speed. As I tend to favour what many here call "chess-like" game
mechanics where detailed and correct action counts for far more than
speed, I don't *think* I have a problem here.
Minor supporting notes: I don't intend for a repetitive action to
*ever* sustainably be profitable. While a little bit more difficlt I
also don't intend for the map between any two significantly seperated
points to be constant. User traffic alone (or the bot's own traffic)
will cause the map to change. I do intend to make the world extremely
reactive to user actions.
The bot comment I count as an express failure in game design. Any
game which can be profitably automated via a bot is a flawed game
design. I am not interested in producing games where humans are
merely less effective bots.
>'course if you don't care abotu the fact that a bot on a T1 net-near
>your site is basicly the ultimate player, then maybe its a
>nbon-issue.
It may happen. If it does I would account my effort as disasterously
failed.
--
J C Lawrence Internet: claw at null.net
(Contractor) Internet: coder at ibm.net
---------------(*) Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...
More information about the mud-dev-archive
mailing list