In my opinion, permanant death implies one of two things.
1. Characters are easily built up to at least upper mid levels.
2. It is very hard to die.


1 implies a sort of "disposable world". It doesn''t really matter, things get thrown away.

2 implies some sorts of fail safes, and multiple states of ''deadness''. Not quite sure how you''d pull that one off, especially seeing that most games are "kill them beforet they kill you".

If neither of those were true, the game will become frusterating to many players.

Hope that helps

AP:

My design revolves around the basic idea "life is short".

I want the player to understand that death can be around the next corner. And the next corner... and the next.

Players will find satisfaction in merely staying alive long enough to gain a reputation ("have you heard about AP? He''s lived for at least 10 full days! And I hear he''s an excellent fighter to take along on quests.")

Multiple states of deadness? Well... I think it''s just going to be a ''make sure you take a healer'' along kind of thing. You''re only dead once you''re dead. But... once that happens... all you can do is admire your gravestone (ala ''Rogue'').

Life will really be cheap. Players will try many different characters (I have a really good idea of how to keep that interesting, although bringing it up before didn''t get me a lot of response... I''ll keep it my little secret from now on ) and just have fun in the action part of the game.

It''s not going to be a grande fantasy world with places to explore, it''ll be just pure action-based questing.

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

Sometimes its better to do things the easy way...

Why not just take a ''snapshot'' of everything around the player on disconnect? Then, whenever a player decides to pull the plug or crashes legitimately, he ends up in the same scenario he left.

This would have exploits too though. If you took snapshots of items on the monster or on the ground, then they could use it to duplicate items. The players could also get some buddies to meet him at the load point and have them kill the monster as soon as he logs in. These two aren''t very hard to fix though.

Darkmage: Lets do some Q and A so you can help me understand, cause you know the tech side better than me, and as well I can make my idea more clear, and see where it gets us. Since Im somewhat of a lay person to TCP/IP, I want to know more so im very excited to learn a alot from you.

First: The game server knows when the client is on or off? correct? and it knows/knew/has a log of the Tcp address (whether masked behind a NAT or not) of the client. Right? (please expound on how this typically works, as Im sure differnt games handle tcp differently, right?)

3. Is it possible for the client app to read the clients "gateway" address off its tcp config, and are ISP "gateways" visible to public internet? If they are not, would be "illegal" for a persons app to read the client tcp config and report it back to the server?

2. From the servers perspective, if a persons connection fluctuates wildly and is precipitated by a drop from the server, how much server side resources and coding would have to be implemented to read this and determine that the person most likely lost connection due to a problem. You see what Im getting at? Of course, a person usually loses connecectivity suddenly and of no fault of thier own, then how much resoures would it take for the server to ping the persons Tcp address, and thier "gateway" (depending on answer to questions 2 ) To determine if they got back on real fast, or if thier ISP is ok.

Then again, I guess somthing could go wrong bettween hops beyond the persons gateway and the game server still leaving the client connected to the internet ok, just not to the part that gets to the game server. And that, I assume gets just about impossible to trace.

You are right, the more I think about it, the more crazy it starts getting to try and have the server go through all that trouble to determine wheter the Ip/app drop is a legit problem, or if the guy yanked the cat5/phone cord out of the wall. I still would like the answers/elplanations though, cause I would learn alot from them. Thanks.

P.s.

The reason I thought of the "gateway" reading idea, is because there are already games that dont allow you to log in as same person from 2 differnt Tcp address''s. I thought about the problem of DHCP assigned addressing, and the fact that for many, they dont always have the same Tcp address. For instance, my Dsl only leases me the same tpc address for a day at time, yet I can still play IdlePimps (funny ass game btw, and my fiance plays it more than me ), and wont boot me. Yet if I log in at work, it will wipe out my character for cheating. (they dont want you playing the game from multiple systems) How do they do this? Do they go by MAC address? That would make sence..

PIK:

Snapshot would work in any single-player environment, yes (and there IS room for that in my design). But whenever more than one player is involved, the snapshot solution would mean that any player in the dungeon would ''freeze'' until the disconnected player returns.

For single player mode ''snapshot'' is the ultimate solution though.

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

Most of the ideas here are really good, and the best solution to this problem might be to use several of them.

So far a combination of the AI bots, the afterlife quest and the keeping of statistics on the player is the best idea imo. Combine those three in an effective and reasonable manner and I think you can honestly say you have done more than your duty to keep disconnections from ruining the game.

I wouldn''t recommend a system that dispenses penalities based on disconnections secretly. Either lay down the consequences to the player flat out front and say that the penalities will get more severe, or be prepared to write a very advanced and hard to predict secret system and spend a lot of time matching wits with people that are trying to crack it.

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

Not exactly. You start out the game with your permadeath character, and a squad of bots to interface with via a VR interface within the virtual controls of the game. (think futuristic). So, you would keep you perma-death character in safe locale (in your hidden base in huge a 3d world) and interface with your bots to play with. Think Battlezone in strat mode, but not only can you have and build units, but you can "be" your other units(in my idea, UT type bot, who could control tanks/shuttles/ships). You pre-program you bots to go to certain locations, and once they get to a point where you want to interface w/ one of you bots, you walk up to a VR control interface in the game (ala controlling Turrets in Tribes1/2). In effect my game is mix of the best element of Battlezone (strategy part) and Tribes, and then adding internally rendered ships/shuttles/vehicles and functioning transporter system ala Star Trek. Its really quite a good idea I think, and kinda makes for a new type of genre\: call it a M/MedMSGFPPDCS (Massive/Medium Mulitplayer Save-Game First Person PermaDeath Combat System ) which is tailed to veteran clan/tribe groups for more advanced long term game play.

In Battlezone you can set the number of lives of yoru character, so in effect it could be made for permadeath. The problem with Battlezone1/2 is that in multiplayer strat, you could only have 8 players, but each one HAD to control thier own Recycler, and could not just be a tank guy on another team. There was real objectives, just kill one another, and blow up each others stuff, and no multi-player save-game for those longer skirmishes. And the maps were to small to support alot of pple.

Silvermyst:

Okay, you just totally screwed my vision of this game all to hell. I was actually agreeing with your reply to my last post, until I read what you just wrote most recently, and now I think you are definitely looking in the wrong direction.

You contradicted yourself. First, you wanted to give players the option of weighing a battle before it happens. Then you wanted death to appear around every corner. And now you''re basically saying life is cheap. That''s the ultimate heresy against hardcore gamers. You''ve already lost my money.

It''s a real shame that I have to say this, because we were in total unison up until you said "life is short," and now I''m just pissed that you''d have the audacity to assume nobody will mind losing their characters on a regular basis. I''m going to share with you one of the Laws of Online World Design, and maybe you''ll understand what I''m talking about.

The expectations are higher than of similar actions in the real world. For example: players will expect all labor to result in profit; they will expect life to be fair; they will expect to be protected from aggression before the fact, and not just to seek redress after the fact; they will expect problems to be resolved quickly; they will expect that their integrity will be assumed to be beyond reproach; in other words, they will expect too much, and you will not be able to supply it all. The trick is to manage the expectations.

This is not taken out of context; it''s the entire quote, and it''s something to think about. Let''s say I play your game for three months with the same character. By this time, we can assume I''ve grown very attached to my character. Then, somebody trips over my phone cord and disconnects me, and my character is killed. Then I''m going to demand that you recover my character for me, and when you don''t, I''m going to stop paying your monthly fee, and I''m going to tell everyone I know that your game sucks.

The Matrix has taught us how important word-of-mouth is. First week it was out, the movie mas virtually ignored. Third week, it was number-one at the Home Box Office.

I''m under the impression that you plan to make monsters unbeatable, because it looks like you expect characters to die every few minutes/hours/days. I''m telling you, no one will tolerate that. Whether you want to believe it or not, make the game and watch your sales fall through the floor. I''m just trying to warn you beforehand.

WarMage''s afterlife idea is great. I''ve got another system you can use that involves permanent death, but on such a highly-regulated basis that it will be unlikely for anyone to die in under a month, and even less likely for everyone to die eventually. Shawn Bruckner and I developed this system for my own game, and you''re welcome to use it if you like.

When a character is completedly defeated in battle or otherwise, he earns a certain number of "death points." As these death points increase, the penalty for losing becomes more severe, until eventually it results in final death, and loss of the character. (At this point, maybe the character''s name appears on a headstone in a nearby graveyard, to add something permanent to the world. Players will love this.)

Minimal death penalties should be insignifact and recoverable, like the temporary deduction of stats and/or skills. Moderate penalties should involve handicaps (broken bones that must be healed by a specialist), permanent stat deduction, and loss of cheap equipment. Severe penalties would be permanent stat deduction, permanent handicaps (severed arm, can only be healed by high-level magic), loss of valuable equipment (artifacts, magic items).

Here''s the death formula we came up with:

Penalty = (EnemyLevel - PlayerLevel) + DamageOverkill

Minimum of one death point, of course. I can also see mixing this approach with WarMage''s idea to create sort of a double-life. It might even be interesting to allow the dead character to remain as a ghost forever, and visit parts of the world that living characters cannot. This would make the game twice as interesting.

Anyway, I still stand on my opinion that permanent death has no place in MMORPG''s. It defeats the whole sense of the genre, and I can''t see it ever being a good thing. Look at the statistics: very few people waste their time with Hardcore characters in Diablo II. They suffer from the same connectivity problems you''re talking about, and they hate it.

That doesn''t mean there''s no solution. You could do anything and everything to make sure a character outlives his first month, but I still think your game won''t be as tantalizing if the possibility of permanent death is lingering over my head at all times. People will spend more time fearing death and less time enjoying your game for what it is. And that''s the ultimate heresy against artists.

TOM:

Let''s see if I can explain my gameplan a little better (because I think you got the wrong picture).

The way it SHOULD work:

Player picks a quest, based on his level of experience. Quests are shown by ''rumour'', so they are not always completely reliable. You can pick a quest ''I heard of a spaceship floating in space over there, and it''s said there''s some small alien beings in it'' and encounter just that: a few aliens that are easily finished off by your team. Or, it could be that those small aliens are only the young of a large pack of large aliens... which WILL pose a problem for your team.

After picking a quest, you set off. The important thing to remember is that this game will FORCE players to really watch what they''re doing. They HAVE to scout ahead. If at one point they see even the slightest sign of a danger to great for the team to handle, they should bail out. If they see just those small aliens, they can kill them. But if they hear the sound of their parents coming... they should leave, immediately.

Weighing battle does NOT mean that the player will be able to get a perfect estimation of the odds. It just means that the player with good observation will have an advantage over a player with bad observation.

DEATH AROUND EVERY CORNER:
This does not mean that death lays waiting around every corner, it just means that there''s always that CHANCE that death is waiting there. If there are 100 corners to be turned, maybe one of them is deadly. But, scouting ahead might show this and give the team the chance to back out. Or it might give the team the chance to overcome death and win.

LIFE IS CHEAP:
That''s just the way it is. Heros die. Smart heroes stay alive. Usually being smart means picking your fights. Fight when the odds are good, leave when the odds are bad. If you''ve played that character for three months and want to keep playing with him, you better make sure to pick the right team mates and do not make any mistakes.

DISCONNECT:
I agree. Getting disconnected and losing your character SUCKS! That''s why my first goal is to somehow find the best solution to that problem.

MONSTERS UNBEATABLE:
Not at all. Actually, with a permanent death system, I think I can actually make the monsters a little easier to beat. After all, it''ll be fun for the player to fight and kill 100 of them... but he has to be on his guard at all times, because one of them just might spell his downfall. I think a permanent death system doesn''t need such a heavy balance between player and monsters.


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

quote: Original post by TheEnderBean
First: The game server knows when the client is on or off? correct? and it knows/knew/has a log of the Tcp address (whether masked behind a NAT or not) of the client. Right? (please expound on how this typically works, as Im sure differnt games handle tcp differently, right?)

It is not always easy to tell exactly when a client ''lost link''. If the problem is traffic, then you won''t know until the connection times out. If the problem is that a packet went missing, then if that packet shows up, the connection is fine again, and if it doesn''t, the link will be dropped, a little while down the line. But in the meantime, neither side is getting any information. It''s quite possible for someone to die at the server-side while a link is frozen, and then for it to right itself later, sending a load of data to the client in one go. In short, connections are technically either off or on, but there''s a big grey area too.

quote: 2. From the servers perspective, if a persons connection fluctuates wildly and is precipitated by a drop from the server, how much server side resources and coding would have to be implemented to read this and determine that the person most likely lost connection due to a problem. You see what Im getting at? Of course, a person usually loses connecectivity suddenly and of no fault of thier own, then how much resoures would it take for the server to ping the persons Tcp address, and thier "gateway" (depending on answer to questions 2 ) To determine if they got back on real fast, or if thier ISP is ok.

Sadly, this approach is too naive. There is a lot more to a connection than just the ISP. eg, noise on the telephone line. Or the fact that your ping might go a different route to the original connection.

There is also another situation, where a player actually connects through a proxy. They may not know about the proxy, since it could be at their ISP. However, the implication is that the connection between player and ISP might be dropped, but the connection between ISP and Game might still be there! This obviously complicates matters.