How about this :

- as soon as the player disconnects, the avatar starts turning to stone. For about 30 seconds (or less - enough for a dying player to die) he is still soft and mobile, and does whatever basic script you care to write (fight if attacked, run if dying). However, because he is turning to stone, chances of outrunning an enemy drop fast. After he is stoned, he is invincible, for about three minutes (large enough for a reconnect, small enough that PKs who fought this guy won''t get bored). After that time, the stone spell dispels, and the player’s avatar starts moving by the script and taking damage again.

Or
- player can set some "team access rights". If he disconnects his team will take care of him until he comes back (If done not so properly, I can see some funny situations: "How much for a cool "glow in the dark" Level 20 Necromancer?" - player can reconnect two days later and find out that all the time his character has been used and abused and passed on by countless teams the last few days).

Those situations when a player can reconnect soon are fine, but
what about some other fairly common situations that force a
player from getting online and back into the game?

Let''s see:

Power outage
ISP link gets hit by a truck(telephone poles and such)
ISP decides to perform an unscheduled maint.
Someone picks up the phone to an *eeeeerreeeeeeshhhhhhhhhhh*
and forces you off for a while whilst they make a call
Nuclear meltdown
Armageddon
etc...

-Hyatus
"ni!"

Would it be possible to run a statistical analysis of players disconnect times? Players who have finished their game normally will tend to leave their characters in safe places. Disconnects and crashes will be essentially random. Dickheads who think it is clever to disconnect when they are in trouble will tend to leave the game in combat and on low health. Once the server gets an idea of the sort of player you are, it can deal with you appropriately.

SANDMAN:

That''s a good idea. I can already see a way to abuse it though... If I know that death is permanent and have already pulled the plug on my computer a few times in close situations, I''ll just pull the plug a few times in non-combat situations to even it out.

... obviously you dont TELL the players thats how it works...

Lets assume that the majority of players dont want to cheat, but they want to enjoy the game as it was intended. The disconnect clause in the game protects them from bad stuff happening when they get disconnected through no fault of their own.

Now lets say we have a few tossers who think it is clever to cheat. They realise that the game automatically gets them out of trouble when they disconnect, so they hit the power whenever they are stuffed. If they do this once or twice, they might get away with it. If they do it a lot however, they will be punished (how? Thats another issue)


Edited by - Sandman on July 17, 2001 9:40:23 AM

SANDMAN:
Ah, should''ve thought of that

Still... once they find out, your system goes down the drain.

I think that to really implement permanent death, the system has to be waterproof. Otherwise, players will eventually find a way to bypass all your intentions and then chaos will destroy everything you created.

Ol'' Silvermyst doesn''t even know how to program his own VCR, so take ANYthing he says with a big pile of salt...

I think the IP failure (packet loss, drop off) looks different to the server than if someone drops the game, or simply pulls thier phone/cat5 out of the wall or thier computer. There are 2 things you can do with that: Write you game app to send a specific message to the server that the user has dropped the game, and the server than scans that user''s previouse tracert to determine if his Ip is still leased and active, and to see if the rest of the users on his subnet seem fine, or if his gateway is not active(suggesting a legitimate technical problem). Im not at all sure how that would be done, but basically you have the server check and see if there is a legit failure somewhere. If it determines that everthing is fine, and that you dropped during other player interaction, and that your IP is still active on the cloud, then you would get a mark on your account. After a certain number of mark, and an admin will be notified and real person will start sending emails to that person who is dropping ''illegally''.

The only problem with that is that people have real lives, and they may just need to leave because of real-life priorities. This is a tough one.

I had a solution to permadeath by making a game idea such that your permadeath character is physically disassociated with most of the dangeriouse action, but uses bots to control from thier perspective to fight and get destroyed with. The whole point of the game was to find/capture/kill the permadeath characters in vast 3d fp perspective landscape (underground, in the sky, on the ground ect..) Its a pretty big game idea, but could work on smaller scales as well. The reason I came up with the idea was because I was looking for a way to make multiplayer save-game work. If you are interested in the idea in detail, let me know.

Silvermyst: Permanent death = very small player base. Trust me on this one. It''s a bad idea no matter how you implement it. Average gamers will not tolerate this system, and nobody in this forum is an average gamer. We''re the wrong people to ask.

WarMage: That''s the best death-recovery idea I''ve seen in my life. I hope you don''t mind if I use that someday, provided half a chance. I''ve always tossed around the possibility of "ghost" characters, but I think a quest to recover your belongings (and perhaps even reputation?) is ingenious.

Sandman: Withholding this kind of information from the player will segregate the player-base into two portions: those who know the rules and work around them, and those who suffer because nobody told them what happens if your carrier gets dropped in combat. And your tech support will turn into Hell as half your users whine about it. Remember, gamers in a real world will NOT tolerate being treated unfairly, no matter the circumstances.

We''re talking about games, people. This is commerce, not philosophy. Freeware isn''t going to fill your refrigerator.

TheEnderBean, I'm uncertain how much TCP/IP programming you've done, so I hope to rectify some misconceptions I think you may have After all, PermaDeath is certainly something that needs looking into. Yes, this is Excessively Technical, and I apologize in advance to those whom this is merely a reiteration of TCP/IP usage.

quote: Original post by TheEnderBean
I think the IP failure (packet loss, drop off) looks different to the server than if someone drops the game, or simply pulls thier phone/cat5 out of the wall or thier computer.
There are 2 things you can do with that: Write you game app to send a specific message to the server that the user has dropped the game, and the server than scans that user's previouse tracert to determine if his Ip is still leased and active, and to see if the rest of the users on his subnet seem fine, or if his gateway is not active(suggesting a legitimate technical problem).

I only wish this were true. The fact is that the internet is stateless. A lost packet is a lost packet, and if you're LUCKY your socket subsystem will let you know that you've lost the connection, not just eat up processing time waiting for data and timing out. Eventually your socket layer will time out, at which point you use the thread handle/pid of that socket to clean up the server side. Maybe with the advent of IPv6 you would be able to do better route backtracking to the client IP, but the simple fact of the matter is that trace routes are notoriously unreliable as well as being time-intensive. Beyond that, backtracking is going to stop far short of your client in most cases due to port 23 being firewalled somewhere along the way.

Posting a message from the client is a non-starter. If the connection died from the client, you're NEVER getting that message at the server, I don't care HOW strong your signal is, it ain't crossing an air gap.

quote:
Im not at all sure how that would be done, but basically you have the server check and see if there is a legit failure somewhere. If it determines that everthing is fine, and that you dropped during other player interaction, and that your IP is still active on the cloud, then you would get a mark on your account. After a certain number of mark, and an admin will be notified and real person will start sending emails to that person who is dropping 'illegally'.

Unfortunately I'd have to say this is a compromise! It would be great if we could solve everyone's problems with their connectivity, but are you wanting to write a game, or a supremely complex (read: tick-eater) and intelligent (read: yet more of a tick-eater) server-client process?

Dialup sucks, the internet is congested, and routes get lost, and I think that's why it's more important to make the gameplay worth the hassle of reconnecting when your connection croaks that it is to build this tank of a comms layer where a moderately priced sedan will do.

quote:
The only problem with that is that people have real lives, and they may just need to leave because of real-life priorities. This is a tough one.

Yeah, but our goal is to cure them of that!

quote:
I had a solution to permadeath by making a game idea such that your permadeath character is physically disassociated with most of the dangeriouse action, but uses bots to control from thier perspective to fight and get destroyed with. The whole point of the game was to find/capture/kill the permadeath characters in vast 3d fp perspective landscape (underground, in the sky, on the ground ect..) Its a pretty big game idea, but could work on smaller scales as well. The reason I came up with the idea was because I was looking for a way to make multiplayer save-game work. If you are interested in the idea in detail, let me know.

So you're talking about raising evil döppelgängers of your dead characters? Now that's an idea!

So again, not to tromp on anyone's know-how, because TEB, I love your last idea! I would feel bad if I didn't share what I know, and you designed your features based on behaviors that aren't practical

-----------------
-WarMage

...special bouns cut-scene dialogue from the upcoming (er, upchucking) MMO MIB: K1ngd0mz from Snowball Fight With Satan Studios .

K: Keep it on _this_ _server_.
J: What? What you doin' man?!
K: I'm goin' to get my sword back.

Edited by - WarMage on July 18, 2001 4:09:08 PM

TOM:

I think I disagree with you. I think more players than ever are ready for a permanent death system, but ONLY if inserted into a well-oiled design. Which I agree with (the system has to work perfectly for permanent death to be viable).
(and I say ''I think'' because I just don''t know how many players would accept a permanent death if the rest of the game fully supports it)

The one thing you have to do with a permanent death game, is give the player ample opportunity to PREVENT that last breath from happening.

This means that the player should have the opportunity to really be able to make a good guess about the odds of a fight, before actually stepping into the fray. It also means that escape should be a big part of the game. Run to live another day.

But, I can make the design of the game as perfect as can be, if the wires connecting people to the server aren''t cooperating... the entire system goes down the drain. I think that ''what to do upon a disconnect/crash'' is probably the first aspect I have to tackle. So far, I''m still biased towards the ''set your own AI reactions'' idea.

Woohoo... I''m on day 4 on my C++ in 21 days course. %Another two weeks and I''ll be a master programmer!%