1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
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.
|
