summaryrefslogblamecommitdiff
path: root/docs/meetings/dev-20050204.txt
blob: 02d1062fa1f6bfcd739d0c50be1bf0ad0e5f4d84 (plain) (tree)


























































                                                                               
---------------------------------------------------------------
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.