diff options
Diffstat (limited to 'docs/meetings')
-rw-r--r-- | docs/meetings/dev-20050204.txt | 59 |
1 files changed, 59 insertions, 0 deletions
diff --git a/docs/meetings/dev-20050204.txt b/docs/meetings/dev-20050204.txt new file mode 100644 index 00000000..02d1062f --- /dev/null +++ b/docs/meetings/dev-20050204.txt @@ -0,0 +1,59 @@ +--------------------------------------------------------------- +Minutes of the TMW Dev Meeting at Friday, 4th of February, 2005 +--------------------------------------------------------------- + +Presence: Rotonen, Hammerbear, ElvenProgrammer +Timespan: 1.5 hours (21:00-22:30 GMT+1) + + +* More priority is given to allowing the world to be expanded. This effort + needs more tiles, but it also requires Tiled to be integrated with TMW soon. + Hammerbear will now work on reading Tiled's maps. + +* Rotonen mentioned a new graphics artist joined our team. He seems a decent + pixel artist and learns fast. A link to some desert graphics: + + http://themanaworld.homeip.net/testall.png + +* Bear is supposed to start scripting. + +* The equipment system has been discussed. Items will be identified in + messages using IDs instead of names to keep the small message size. The + being definition will define the slots available for that being, and the + item definition will define a slot the item may optionally be equipped in, + maybe multiple can be allowed. + + Being will have a list of inventory and a list of equipment slots. Items + can be moved from one to the other and back as is allowed by their + specifications. Relevant messages for the new server are: + + Client to server: MSG_EQUIP { L beingId, L itemId, S slot } + Server to client: MSG_EQUIPMENT_UPD { L beingId, L itemId, S slot } + + The rationale behind the client sending the beingId to the server is that the + client may be controlling multiple beings. Unequipping can be done by using + the same messages but passing 0 as itemId. + + ElvenProgrammer will start to work on this part. + +* Fixes to A* were mentioned. It is doubtful wether it is worthwhile to fix it + because pathfinding can be moved to server side and will probably better be + completely reimplemented. Also we still plan to switch to pixel-based + movement instead of tile-based movement. + +* Attention was given to the currently proposed movement message pairs: + + Client to server: + + MSG_WALK { L beingId, L x, L y } + MSG_TARGET { L beingId, L targetBeingId } + + Server to client: + + MSG_PATH { L beingId, A path } + MSG_ATTACK { L beingId, L targetBeingId, L damage, S damType } + + This moves away from direct player control, and seems only based on mouse + control. Still, it was pointed out Shura and Hammerbear have been discussing + two ways of doing keyboard control that can map on these kind of messages. + |