On Thu, 17 May 2001, Mike Ponicki wrote: > > On the technical side, if we move all (or as much as possible) game > content to the client side, this wouldn't be an issue- the client can > choose to render the game any way he/she chooses. But as for the creative > side (which I think is what you were referring to), it would be a lot more > work to have to keep two or more tilesets updated with new objects. Note that it was an intentional design goal to assume the client is not trustworthy. Therefor, the server does not believe anything the client says. That said, sound area already client side (server just tells client what to play), images can be client side (either through the cache option of -imagefile option in the unix client - perhaps these should be turned on by default instead off of). Dealing with maps gets tricky. The current map set is 10 megabtyes or so, and is not in the most easily parsible format (not really hard, but not completely trivial). I don't really want to see that moving to the client (trust on this is less an issue, since most all maps are available and the player can download them and view them anyways - issue is more complication). Plus, the bandwidth from the maps probably isn't that great - the bigger bandwidth hog is the objects on top of the maps that move around or change time to time - the client having a copy won't help that. The other bandwidth hog is large piles of objects on the ground. This gets costly because for each item, we send the name information (arrow/arrows) as well as lots of other duplicate information (face for example). In some cases, you get unique artifacts and can't help that, but most big piles are a whole bunch of mundane objects that could perhaps be handled in a better fashion. If it was a commercial game with known information between the client and server, it could probably get simplied to '80 of item 1734', and the client would know item 1734 is arrows, its face is this, and its weight is this.