>>15
Of course people make their own clients, that's what I said! But why do they have to use ncurses? That's pretty limiting!
If it's to be so unambitious, here is a sketch for protocol of "basic" rpg! It's still missing some things, like player stats, spell visuals, and interaction between players. Player movement is a bit hazy as well! It kind of assumes free movement on a plane with players controlling their own position unless the server teleports them. If we want tile-based movement or less cheating that can change! It also deals with map files, but their format isn't specified—maybe we should skip that anyway and have terrain load in chunks as you approach it! Oh, and it assumes combat occurs in the open world instead of some kind of jap cutscene!
let's say it's a tcp connection, for simplicity! the server opens with a protocol declaration, then the client can disconnect if it's not compatible. then they start sending each other a series of messages! a message is a length prefix, an integer identifying the message type, and some arguments!
server->client:
(HELLO) protocol-and-version [' ' extension ...] '\n'
SERVER_INFO software server-name server-description motd
MAP hash filename size [url]
TERMINATE_CONNECTION reason
CREATURE cid name model is-alive is-player is-you
CREATURE_INFO cid description
CREATURE_MOVE cid zone x-pos y-pos x-vel y-vel facing
CREATURE_POWER cid hp max-hp mana max-mana
CREATURE_TARGET cid other-cid
CREATURE_STATUS cid effect-id effect-name time-left
CREATURE_STATUS_FADES cid effect-id
CREATURE_CAST cid spellid time-left
CREATURE_CAST_COMPLETE cid spellid
CREATURE_CAST_FAILED cid spellid reason
CREATURE_DAMAGED cid by-cid spellid amount
CREATURE_GONE cid
CHAT type channel from message
CENTER_VIEW zone x-pos y-pos
DIALOGUE title text [option ...]
DIALOGUE_CANCEL
LEARN spellid
RESET_SPELLS
INVENTORY_INFO bag-slots [equip-slot-name ...]
INVENTORY_UPDATE slot itemid amount
EQUIPMENT_UPDATE slot itemid amount
ITEM_GAINED itemid amount
ITEM_LOST itemid amount
SPELL_INFO spellid icon name description targettype
ITEM_INFO itemid icon name description is-usable equippable-slots
FILE_REFUSE filename reason
FILE_BEGIN stream-id filename size
FILE_CHUNK stream-id offset bytes
FILE_END stream-id
client->server:
CLIENT_INFO software player-name player-password
ENTER_WORLD
LOGOUT
MOVE x-pos y-pos x-vel y-vel facing
INTERACT cid
CHAT type channel to message
DIALOGUE_CANCEL
DIALOGUE_CHOOSE option
ATTACK cid
USE inventory-slot
WEAR inventory-slot [equip-slot]
CAST spellid cid
CAST_TARGETED spellid x-pos y-pos
CAST_STOP
FILE_GET filename
After the protocol declaration, the server sends SERVER_INFO and MAP and the client sends CLIENT_INFO. The client then attempts to load the required map from local storage; if it is not available, the client can attempt to retrieve it using FILE_GET or via http at the alternate url given in MAP. When the map is loaded, the client sends ENTER_WORLD. The server responds with a barrage of INVENTORY_INFO, SPELL_INFO, ITEM_INFO, INVENTORY_UPDATE, EQUIPMENT_UPDATE, LEARN, and CENTER_VIEW. There will likely be some CREATURE* messages assuming any creatures (including yourself) are within view distance.
CREATURE introduces a new creature to the client or updates an existing one. The other CREATURE* messages update certain attributes or notify of actions/events, and CREATURE_GONE removes the creature from the client's view. SPELL_INFO and ITEM_INFO are meant to populate a cache that the spellid and itemid parameters of other messages refer to. The server must have sent the relevant info message sometime in the current session before referring to the spell/item in any other message. INVENTORY_INFO defines the number of bag slots and the number and names of equipment slots (if any).
cid, effect-id, and stream-id are uniquely chosen identifiers for each instance of a creature, status effect, or file transfer. The rest is pretty much self-explanatory!