Hi, I've got several ideas matching Mark Wedel's view. > 3)really move the image stuff to the client, with the server having >images > really only because new archs/maps/images may get added faster than >the > client > gets updated. With this, the server only needs one 'fallback' image >set. Yes , i think it's the way to do the things. I really think the game server don't have to be concerned by the display. He's got only to handle positions, events , attributes of the maps,arch & players.(the game logic) It's the client responsibility to display the things. A good thing i think is to have a "tile server" , separated from the game server (in a logical way). Clients could connect to the "tile server" to update their tilesets. This server could be accessed by the artists to add their tiles. The client will have to have an option to enable the player to get some new tilesets. (cf Mark's modif nb 1 to the client) One good thing is that the game server will only have to do game logic! I think it has to be done for the 2.0 version (i don't know much about the versionning policy). I've got several other ideas for server,client and protocol but i need to get deeper into the current implementation to see if they're relevant. Sebastien Bracquemont. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com