Change how login works

[Potjeh]

Right now, you select where you want to continue playing, your character is placed in the world and then you wait some time till your client gets all the information it needs to actually display your surroundings and let you walk and do stuff. With the recent login lag, this takes enough time for someone to break your brick wall, eat all your food, drink some tea, have an after-meal nap and then murder you before you assume control of your character.

The game should send the data first, get confirmation from the client that it has indeed received everything it needs, and then place the character in the world. If the spot where the character was supposed to appear gets blocked while the data is being transmitted, the game can wait 5-10 seconds, and if it fails again just return the player to the character selection menu (and give an error message, of course).

Teleportation has a similar problem, but it's not quite so intense. Still, it'd be really neat if a teleporting character was somewhere outside of the world while he's waiting for the target area's data.

[loftar]

Not that you don't have any point, but I think the real solution to the problem is to get the lag fixed. :)

Of course, that isn't exactly trivial, so I figure you might be arguing for a stop-gap solution. Unfortunately, this isn't trivial to implement either. Not that it couldn't be done, but there is quite some amount of work involved, and it doesn't quite feel worth it just for a stop-gap.

I'll keep it in mind, though. There are a few consequences of it that would have beneficial effects to the overall architecture.

[firemage]

How about saving the graphics on the clients side instead of the servers?
If you are worried about others using your graphics you could use your own file format, even with encryption. I don't know about modern games, but the graphics in Ulima Online came with the client.
That way the server doesn't have to send MBs of data to the client everytime someone logs in or teleports.

I know, that's probably not trivial either, since sending graphics data is probably deeply integrated into client AND server, let alone having to write an en-/decoder for the new format.
But it would definately help with bandwidth overall and greatly reduce the time it takes from login until you can actually play.

And while you're at it, you could rewrite the minimap, so it's generated on the fly client-side from the terrain data it gets from the server anyway. It wouldn't probably be as pretty as it's now, but again it saves bandwidth and you don't have to wait hours until they are generated when you add new supergrids.

[loftar]

I don't really understand why people get this popular idea that all graphics are always sent from the server. The client does have its own copy of the graphical resources. That's the haven-res.jar file.

As for the minimaps, the problem with generating them on the client is partly that the client wouldn't be able to render objects that it doesn't know about on them, so that trees, houses, ridges &c. beyond a certain range wouldn't be visible on the minimap; and partly that the minimaps wouldn't be reusable for cartography. As for taking hours to generate, all I really have to do is write a new minimap renderer.

I would take a jab at your suggestion of "encryption" to prevent people from using the graphics, and its relation to DRM, but I digress for now.

[Potjeh]

I'm not pretending to be a better programmer then you (mainly because I'm not much of a programmer), but doing it the way I'm suggesting is more "right", for a lack of better word.

That, and addresses the issue of client-side lag. I have crappy 256k WLAN, and my login always takes at least 5 seconds. Same with teleportation.

As for minimaps, surely sending them as pngs (or whatever you're using) isn't the most bandwith efficient way? Sending them as raw coordinates of stuff that can be used to generate a minimap on the client would allow for better compression, I'm guessing.

[loftar]

I'm not pretending to be a better programmer then you (mainly because I'm not much of a programmer), but doing it the way I'm suggesting is more "right", for a lack of better word.

Well, yes. I agree that you do have a point. The main reason why it is non-trivial is because the client needs a reference to the object ID for the player when creating the game UI (to be able to track the camera correctly and other such things), and similarly parts of the server code build on the invariant that as long as there as a game UI, there is an in-world player object as well. Fixing that would necessitate decoupling large parts of the client UI functions from the player object and/or make them able to switch objects for the representation of the player, and finding all such server-side dependencies on the player object where the invariant may be violated.

Doing that would be nice and beneificial in several ways, however, which is why I said that I'd keep it in mind.

As for minimaps, surely sending them as pngs (or whatever you're using) isn't the most bandwith efficient way? Sending them as raw coordinates of stuff that can be used to generate a minimap on the client would allow for better compression, I'm guessing.

That is partly true. There are a couple of issues, though. For one thing, I'm not sure how much space would really be saved by it -- I'd have to experiment a bit. I'm also not sure how much bandwidth minimap transfer actually consumes (I should measure that). Mainly, though, I like the freedom that comes with just keeping the minimap as PNGs, since it allows me to do virtually anything with the minimap generator that I might ever fancy, without having to change the client accordingly.