summaryrefslogtreecommitdiff
path: root/docs/meetings/dev-20050204.txt
diff options
context:
space:
mode:
Diffstat (limited to 'docs/meetings/dev-20050204.txt')
-rw-r--r--docs/meetings/dev-20050204.txt59
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.
+