Re: CF: what did I do? (so I don't do it again)

[Aaron Baugher <abaugher@rnet.com>]

From: Christian Stieber <stieber@informatik.tu-muenchen.de>

> If you could "quit" and restart from an older point in time, it
> would be a great builtin way to cheat [snip]

> I don't know why so many people expect it to work like this. Are
> many commercial CRPGs or action games implemented like this? I know
> that Civilization/Colonization allowed this sort of cheating.

All the ones I've played allow it, and in many, it's practically
necessary.  Of course, most of these games are not multi-player in the
on-going sense of crossfire, where you are advancing along with other
players in the long term.  Most of them just have multi-player
'sessions', during which if you quit you *do* lose.  Since crossfire
isn't really a competition in that sense, it makes more sense to do it
the way it's currently done.

Some games I used to play on the Commodore 64 had limited saving.
Ultima IV, for example, only allowed saves while outdoors, so you
couldn't save while in dungeons or cities.  This kept you from using
the 'save, open door, die, restart, open other door' strategy.

Here's my idea for keeping the save-on-disconnect from being abused in 
combination with server resets (gather treasure, disconnect, wait a
day, gather treasure again):  Designate a point on each map where
disconnected characters will be relocated.  So, if I'm anywhere on a
map and my client gets disconnected, when I reconnect, I will be on
the same map, but at a 'safe' location, that was chosen because it was 
neither under imminent attack or near any treasure.

Of course, that opens up the 'kill connection if almost dead'
strategy.  To combat that, the server, upon seeing a client
disconnect, could check something to determine if the player was under
attack.  This could mean looking for monsters in the squares around
him, checking to see if his hit points are below a certain level, or
some other means.  If the player is determined to have been under
attack, save him in that same location.  If he was not under attack,
and thus was presumably disconnected accidentally, then save him in
the safe spot.  It wouldn't be perfect, and would require some more
complexity to the save code, but it would attempt to deal with both
abuses.


Aaron
-- 
Aaron Baugher - abaugher@rnet.com - Quincy, IL, USA
Extreme Systems Consulting - http://haruchai.rnet.com/esc/
CGI, Perl, Java, and Linux/Unix Administration


-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to crossfire-request@ifi.uio.no]