NetworkProtocolNotes

From MountainfortWiki

== general == * [[NetworkProtocolSpec|protocol specification]] * connecting webgl+javascript in browser via html5 websocket (tcp) to lua/c++ server * websocket(tcp) maybe doesn't support binary data but only utf8 "text" blocks * jason encoding for structured network messages might be good for speed on clientside (javascript slow?) and utf8 as well as debugging * 8x8x8 terrain chunk might be transferred as 512byte long utf8 text string, if blocktype is encoded as printable utf8 char == map, show/hide/create/destroy, movement, server-sent content == * mapdata (update) : tile by tile (chunk) or single tile update ** each tile consists of 1 byte tiletype info and 1 byte parameter (4 bits) + lighting (4 bits) info ** collision (solid/empty/liquid/stair-or-ramp), texture is tiletype based ** special infos like direction or liquid fill level is handled via the extra parameter * player * enemies/npcs (mobiles) ** actions/animations * items (on ground and in backpack/inventory. pickup?) * buildings (look like multiple blocks but might be highlighted/tooltipped in client somehow) * particle effects? ** area effects like rain/snow? * time/weather * sound/music effects * chat * clientinteraction sends the current position, direction and the target tile position + face * server sends update interval for looking (gestures for multiplayer) and targetting (default:0.1s) during tool-usage * client sends targetting info : (A:starting point + direction AND B: target tile pos + side) while mouse is down (interval sent from server) * client sends looking direction regularly (interval sent from server) * types for sound/music * tiles (box) types / terraintypes : texture url, name (tooltip) properties * possibly animated or multi-part models : (probably obsolete by model type below) ** monster/creature "models" (pixel art flat sprites first, later maybe simple modelling from big-pixel textures and rect-blocks?) ** player skin ? * model type : vertex+index array (as json or .js file) and texture ** prefabs:block, double-culling-block(foliage), diamond, sphere, cylinder, ingot? (texcoords as param, in case atlas is used: neccessary for terrain) ** can be used by : *** "torch" terraintype items or similar (texture=atlas) (tree-round? foliage? mine-cart-tracks? ladders? stairs?) terrain-type-parameter -> different models? *** items on ground ? *** player wearable equipment (param at which bodypart the model is attached) *** mobiles (ai-enemies, animals) *** vehicles (boats, wagons, mining carts) *** building parts *** particles ? (turn to cam?) * building type (1x1x1, 2x2x1,2x2x2, 3x3x3,3x3x2,3x3x1 ...) ** tooltip ** terraintypes (or model types) for parts * image type ("sprite"?) ** used by gui : texture name +uv start+ dimension(uv) + dimension on screen ** interesting for particles ? (nah, atlas) * icon type = image id + tooltip (e.g. for generic multi-choice dialog)... or negative typeid as value makes this unneccessary? * dialogs (should be moved to gui section below? later) ** can contain text (including icons) ** text input dialog (writing books, signs, player name) ** inventory (quickbar?) ** crafting : list of thinks one can produce (with tooltip and costs, marked red or something like this if you dont have enought ressources) in your backpack == vehicles ? == * df : wagons, minecraft : ships, uo : big ships ? == gui == * chat * playerlist ? * building placement (list of available buildings and required resources) * items crafting inside buildings (list of available items and required resources) * other building functions (switches/levers,heal/sleep?) * generic multi-choice dialog : title text + entries (image + tooltip + text, (color, dimensions, multiple images for ressource list?)) ** idea : per entry list of image,text,image,text,.... can be used for ressource list (probably needs 2d image type with tex+uv start+dimension, see server-sent-content above) ** usable by : building construction, crafting, multiplayer-voting and similar (kick, mapchange, save...) === idea : generic gui system for serverside scripting with thin client === * element = { x,y, w,h, img(url) / text / textentry / checkbox , returncode on click , tooltip on mouseover } * thin client -> doesn't have to understand concepts like "choose from list", all is in server -> scriptable * maybe for serverside options (sight range, map selection ...) * server can send CloseDialog(id) and UpdateDialog(id,newdata) <b>SCRAPPED</b>, problems : things like radar etc that should update every frame, too expensive via network == player actions == * use selected tool on environment (client sends which block or only direction?) ** weapons : direction (ranged) ** place blocks / construct walls * activate object ? (switches) * drop items (pickup automatic?) * construct building (initiates server sent list of available buildingtypes and materials) * use building (starts crafting gui) === construction === * blocks * buildings/workshops ** different sizes but simple shapes : 1x1, 2x2, 3x3 with height 1 each * crafting = gameplay notes = (different wiki page, just noting from chat) * simple axe : stoneage like : use bare hands on : ground->small stones, tree->sticks, combine:stone-axe, slow but gets real wood * mining stone should not be so easily achievable, need pickaxe : metal ** 1 pick total per TEAM as start equip? npc trade? nope =) ** a bit ore findable in soil layers ? (burn wood->coal ->smelt ore ->metal : stone anvil + coal + stone hammer -> crude metal tools) *** metal hammer, metal anvil : better tools = naming conventions = * "tile" is a unit box, used for terrain and similar, 1x1x1 * "chunk" is a group of 8x8x8 tiles * the term "block" is avoided as it is ambigious and could be understood as 1x1x1 or 8x8x8 = gameplay concept = * multiplayer, roughly 4 players, match lasts roughly 1 hour, but can be saved/loaded/continued later * start with nothing, survive & build from scratch (no start items) * build fortress and defend against sieges (after certain time, regular?) and individual enemies * maybe dungeon-heart(movable item?) / king that needs to be defended to create motivation for defense rather than escape * sandbox, play with water/magma simulation = tasks/interest distribution? = * hagish : water-simulation, pathfinding (multithreading)? c++ , ext lib input browser independent keydown * ghoul : lua-scripted events, e.g. tree falling if lumberjacked, webgl client (but quick&dirty,lua>js), network? = todo : planning = * gui system detailed net messages * server : multithreading data access (water sim + pathfinding mainly, double-buffer old=readonly to avoid locking) * physic resync / blocking / cheatprotect ? (later) * player appearance / animation (later)

Return to NetworkProtocolNotes.