The Mana World - User contributions [en]

User talk:Dabe/Backstory

2007-03-12T10:45:19Z

Avaniel: just talking

We need to discuss creating a timeline to take the place of this awkward article. Any event worth giving detailed information about, can be turned in to a link/article. I would like to have something more like a video game intro, to very vaguely & quickly tell the story. (like in SoM of course)

I'm not sure how to go about doing this efficiently, in a wiki environment. [[User:Dabe|Dabe]] 00:42, 5 March 2007 (CET)

=== @ Epic ===
I like the short one, the perspective that is given to a new player, is exactly what you would expect to remain from an ancient history. We had four crystals, world was good; crystals gone, world in turmoil. Then it's up to the player to find out why and how to fix it. Maybe even something like "A hero gave us four crystals, to balance the world." If you're still going with the one hero from every race, who defeated the gods together. [[User:Avaniel|Avaniel]] 11:45, 12 March 2007 (CET)

Archive:Threat level

2007-03-09T16:50:02Z

Avaniel: comment

{{Status_red}}

The premise of this page is to demonstrate a possible monster-threat system, where the game would warn the player when the monster is too strong for them to defeat. The system proposed here is fairly simple, but should work fine. Of course, this assumes the player isn't using any glitches/cheats. There might be a small bit of error for long-ranged players, due to the distance the monster has to travel to attack.

if m. exp < 0.1% p. lvl exp => gray
if (m. spd > player spd) & (m. atk > p. atk) & (m. hp > p. hp) => red
if (m. spd - player spd) < -99% m. spd
if (m. atk - p. atk) > 49% m. atk
if (m. hp - p. hp) > 49% m. hp => red
if (m. hp - p. hp) = -50% to 50% m. hp => orange
if (m. hp - p. hp) < -50% m hp => green
if (m. atk - p. atk) < 50% & > 0% m. atk
if (m. hp - p. hp) > 99% m. hp => orange
if (m. hp - p. hp) > 149% m. hp => red
if (m. hp - p. hp) < 100% m. hp => green
if (m. atk - p. atk) < 0% m. atk
if (m. hp - p. hp) > 99% m. hp => orange
if (m. hp - p. hp) > 149% m. hp => red
if (m. hp - p. hp) < 100% m. hp => green
if (m. spd - player spd) > -100% < 1% m. spd
if (m. atk - p. atk) > 49% m. atk
if (m. hp - p. hp) > 49% m. hp => red
if (m. hp - p. hp) = -50% to 50% m. hp => orange
if (m. hp - p. hp) < -50% m hp => green
if (m. atk - p. atk) < 50% & > 0% m. atk
if (m. hp - p. hp) > 99% m. hp => orange
if (m. hp - p. hp) > 149% m. hp => red
if (m. hp - p. hp) < 100% m. hp => green
if (m. atk - p. atk) < 0% m. atk
if (m. hp - p. hp) > 99% m. hp => orange
if (m. hp - p. hp) > 149% m. hp => red
if (m. hp - p. hp) < 100% m. hp => green
if (m. spd - player spd) > 0% m. spd
if (m. atk - p. atk) > 49% m. atk
if (m. hp - p. hp) < -199% m. hp => orange
if (m. hp - p. hp) < -249% m. hp => green
if (m. hp - p. hp) > -200% m. hp => red
if (m. atk - p. atk) < 50% & > 0% m. atk
if (m. hp - p. hp) > 0% & < 49% m. hp => orange
if (m. hp - p. hp) > 50% m. hp => red
if (m. hp - p. hp) < 0% m. hp => green
if (m. atk - p. atk) < 0% m. atk
if (m. hp - p. hp) > 49% m. hp => red
if (m. hp - p. hp) > -49% < 50% m. hp => orange
if (m. hp - p. hp) < -50% m. hp => green

:''What would you say about, defining a meaningfull way to calculate being levels and basing threat level on that? --[[User:Avaniel|Avaniel]] 17:50, 9 March 2007 (CET)''

Archive:Collision determination

2007-03-03T00:42:08Z

Avaniel:

{{Status_red}}

This page was created to document the collision detection algorithms used in The Mana World. After the algorithms are converted to C++ and added to the code base it is very difficult to verify the assumptions and math of the author. Therefore an explanation of the algorithms used, is given below. Of course any improvements or clarifications can allso be added and discussed on this page.

Strictly speaking, the algorithms discussed here, compute if two geometric figures intersect. However, the result is then used in a dynamic game. In the game world two objects will collide if their movement areas intersect.

== Circle-Sector with Disk ==
''By [[User:Avaniel|Avaniel]] 20:37, 27 February 2007 (CET)''

In order to determine if a circle-sector and a disk collide, we start with transforming the coordinates of the 2d space in such a way that the center of the circle-sector is located at the origin. The circle-sector can then be defined by a radius ''R'', a half-top-angle ''alpha'' and a placement angle ''beta'', as shown in diagram (1).

The disk can simply be defined by its center-point ''P'' and its radius ''RP'', where point ''P'' can be anywhere in the 2d space. See diagram (CSD-1) for an overview.

[[Image:Collision-circlesecor-disk-dimensions.png|frame|none|Diagram (CSD-1) - Overview of the Circle-Sector and Disk]]

In order to determine if the circle-sector and the circle intersect, the x-y plane is divided in 6 ''Voronoi'' like regions. The regions are based on the vertexes ''O-A'', ''O-B'' and the arc ''A-B''. They are shown in diagram (CSD-2).

[[Image:Collision-circlesecor-disk-voronoi.png|frame|none|Diagram (CSD-2) - The x-y plane divide in 6 'Voronoi' regions]]

For each region it is now determined what the pre-conditions for an overlap are, if ''P'' is in that region. If necessary, the pre-conditions for point ''P'' being in the region will be derived as well.

In the following text, a subscript ''x'' and ''y'' are used to indicate x and y coordinate of a point. If the coordinates considered are in a tranformed coordinate system, an extra indicator will be added. For example the x-coordinate of point A in the x1-y1 coordinate system is denoted as: Ax1

=== Region 1 ===

Region 1 is highlighted in diagram (CSD-3), it includes the interior of the Circle-sector. For region 1, the coordinates for point ''P'' are transformed to coordinate system 1 (shown in diagram (CSD-4)). [[:Image:Collision-circlesecor-disk-example1.png|An example of a region 1 collision is given here.]]

[[Image:Collision-circlesecor-disk-voronoi1.png|frame|none|Diagram (CSD-3) - 'Voronoi' region 1 highlighted]]
[[Image:Collision-circlesecor-disk-axis1.png|frame|none|Diagram (CSD-4) - Coordinate system 1]]

The coordinates for point ''P'' in coordinate system 1 are:

:Px1 = Px cos(beta-alpha) + Py sin(beta-alpha)

:Py1 = Py cos(beta-alpha) - Px sin(beta-alpha)

Using goniometric relations this can be simplified to:

:Px1 = Px {cos(alpha)cos(beta) + sin(alpha)sin(beta)} + Py {-sin(alpha)cos(beta) + cos(alpha)sin(beta)}

:Py1 = Py {cos(alpha)cos(beta) + sin(alpha)sin(beta)} - Px {-sin(alpha)cos(beta) + cos(alpha)sin(beta)}

Point ''P'' is inside region 1 if

:Px1 >= 0 , Py1 >= 0 and Py1 <= Px1 tan(2alpha) = Px1 {2sin(alpha)cos(alpha) / (cos2(alpha) - sin2(alpha))}

The Circle-sector and the disc then intersect if

:Px2 + Py2 <= (R + RP)2

=== Region 2 ===

Region 2 is highlighted in diagram (CSD-5). For this region no coordinate transformations are necessary. [[:Image:Collision-circlesecor-disk-example2.png|An example of a region 2 collision is given here.]]

[[Image:Collision-circlesecor-disk-voronoi2.png|frame|none|Diagram (CSD-5) - 'Voronoi' region 2 highlighted]]

If point ''P'' is inside region 2, the circle-sector and the disk can only intersect if point ''B'' is inside the circle.

:(Px - Bx)2 + (Py - By)2 <= RP2

The coordinates of point ''B'' are:

:Bx = R cos(alpha + beta) = R {cos(alpha)cos(beta) - sin(alpha)sin(beta)}

:By = R sin(alpha + beta) = R {sin(alpha)cos(beta) + cos(alpha)sin(beta)}

With the coordinates for ''B'' the condition can now be evaluated.

=== Region 3 ===

Region 3 is highlighted in diagram (CSD-6). For this region no coordinate transformations are necessary. [[:Image:Collision-circlesecor-disk-example3.png|An example of a region 3 collision is given here.]]

[[Image:Collision-circlesecor-disk-voronoi3.png|frame|none|Diagram (CSD-6) - 'Voronoi' region 3 highlighted]]

Analogous to region 2, the circle-sector and the disk can only intersect if point ''A'' is inside the disk. The condition for this is:

:(Px - Ax)2 + (Py - Ay)2 <= RP2

The coordinates of point ''A'' are:

:Ax = R cos(-alpha + beta) = R {cos(alpha)cos(beta) + sin(alpha)sin(beta)}

:Ay = R sin(-alpha + beta) = R {-sin(alpha)cos(beta) + cos(alpha)sin(beta)}

With the coordinates for ''A'' the condition can now be evaluated.

=== Region 4 ===

Region 4 is highlighted in diagram (CSD-7). For this region no coordinate transformations are necessary. [[:Image:Collision-circlesecor-disk-example4.png|An example of a region 4 collision is given here.]]

[[Image:Collision-circlesecor-disk-voronoi4.png|frame|none|Diagram (CSD-7) - 'Voronoi' region 4 highlighted]]

Analogous to regions 2 and 3, the circle-sector and the disk can only intersect if point ''O'' is inside the disk. The condition for this is:

:Px2 + Py2 <= RP2

=== Region 5 ===

Region 5 is highlighted in diagram (CSD-8). For region 5, the coordinates for point ''P'' are transformed to coordinate system 2 (shown in diagram (CSD-9)). [[:Image:Collision-circlesecor-disk-example5.png|An example of a region 5 collision is given here.]]

[[Image:Collision-circlesecor-disk-voronoi5.png|frame|none|Diagram (CSD-8) - 'Voronoi' region 5 highlighted]]
[[Image:Collision-circlesecor-disk-axis2.png|frame|none|Diagram (CSD-9) - Coordinate system 2]]

In the local coordinates the following conditions for ''P'' being in region 5, can be formulated:

:Px2 <= 0, Px2 >= -R and Py2 >= 0

The condition for the circle-sector and the disk intersecting is:

:Py2 <= RP

The coordinates for ''P'' in coordinate system 2 are given by:

:Px2 = Pxcos(alpha + beta + pi) + Pysin(alpha + beta + pi)

:Py2 = Pycos(alpha + beta + pi) - Pxsin(alpha + beta + pi)

Using the goniometric relations to handle the ''pi'' term first, the coordinates become:

:Px2 = -Pxcos(alpha + beta) + Pysin(alpha + beta )

:Py2 = -Pycos(alpha + beta) - Pxsin(alpha + beta )

Now using the goniometric relations to seperate ''alpha'' and ''beta'':

:Px2 = -Px{cos(alpha)cos(beta) - sin(alpha)sin(beta)} + Py{sin(alpha)cos(beta) + cos(alpha)sin(beta)}

:Py2 = -Py{cos(alpha)cos(beta) - sin(alpha)sin(beta)} - Px{sin(alpha)cos(beta) + cos(alpha)sin(beta)}

The conditions can now be evaluated.

=== Region 6 ===

Region 6 is highlighted in diagram (CSD-10). For region 6, the coordinates for point ''P'' are transformed to coordinate system 3 (shown in diagram (CSD-11)). [[:Image:Collision-circlesecor-disk-example6.png|An example of a region 6 collision is given here.]]

[[Image:Collision-circlesecor-disk-voronoi6.png|frame|none|Diagram (CSD-10) - 'Voronoi' region 6 highlighted]]
[[Image:Collision-circlesecor-disk-axis3.png|frame|none|Diagram (CSD-11) - Coordinate system 3]]

In the local coordinates the following conditions for ''P'' being in region 6, can be formulated:

:Px3 >= 0, Px3 <= R and Py3 >= 0

The condition for the circle-sector and the disk intersecting is:

:Py3 <= RP

The coordinates for ''P'' in coordinate system 3 are given by:

:Px3 = Pxcos(alpha + beta) + Pysin(alpha + beta)

:Py3 = Pycos(alpha + beta) - Pxsin(alpha + beta)

Now using the goniometric relations to seperate ''alpha'' and ''beta'':

:Px3 = Px{cos(alpha)cos(beta) - sin(alpha)sin(beta)} + Py{sin(alpha)cos(beta) + cos(alpha)sin(beta)}

:Py3 = Py{cos(alpha)cos(beta) - sin(alpha)sin(beta)} - Px{sin(alpha)cos(beta) + cos(alpha)sin(beta)}

The conditions can now be evaluated.

=== Bounding Circle ===

The above laid out method is mathematically accurate and sufficient. However, it is not very fast. By applying a bounding circle and checking if the disk intersects with that, The six region based intersection test only have to be applied to likely candidates. An overview of the bounding circle is given in diagram (CSD-12). For these calculations coordinate system 4 will be used, which is shown in diagram (CSD-13).

[[Image:Collision-circlesecor-disk-boundingcircle.png|frame|none|Diagram (CSD-12) - Overview of the bounding circle]]
[[Image:Collision-circlesecor-disk-axis4.png|frame|none|Diagram (CSD-13) - Coordinate system 4]]

The radius of the bounding circle ''RC'' is given by:

:RC = R / (2*cos(alpha))

The coordinates of the center point in coordinate system 4 are then given by:

:Cx4 = R / (2*cos(alpha))

:Cy4 = 0

The coordinates for ''P'' in coordinate system 4 are given by:

:Px4 = Pxcos(beta) + Pysin(beta)

:Py4 = Pycos(beta) - Pxsin(beta)

The condition for the disk intersecting the bounding circle is then given by:

:(Px4 - Cx4)2 + (Py4 - Cy4)2 <= (RP + RC)2

Inserting the values for ''Cx4'', ''Cx4'' and ''RC'', into the condition yields:

:(Px42 + Py42)*cos(alpha) - Px4*R <= RP2*cos(alpha) + RP*R

To achieve this result, both sides where multiplied by ''(2*cos(alpha))'', which means that an extra condition is imposed.:

:cos(alpha) > 0; alpha < 90o

Together with the observation that the bounding circle becomes infinitly large at a value for ''alpha'' of 90o, we have to limit ''alpha'' to a maximum of 85o, for practical reasons.

The condition can now be evaluated.

=== The Algorithm ===

The following values need to be given; the radius of the circle-sector ''R'', the half-top-angle ''alpha'', the placement angle ''beta'', the coordinates of the center of the circle-sector, the coordinates of the center of the disk ''P'' and the radius of the disk ''RP''.
* Subtract the coordinates of the center of the circle sector from the coordinates of point ''P'', thereby obtaining the coordinates of ''P'' in the primary coordinate system.
* Calculate sin(alpha), cos(alpha), sin(beta) and cos(beta) and store them in temporary variables.
* Calculate the coordinates of point ''P'' in coordinate system 4.
* Check for an intersection with the bounding circle.
** Return false if there is no intersection.
* Check for a region 4 intersection.
* Calculate the coordinates of point ''A'' in the primary coordinate system.
* Check for a region 3 intersection.
* Calculate the coordinates of point ''B'' in the primary coordinate system.
* Check for a region 2 intersection.
* Calculate the coordinates of point ''P'' in coordinate system 1.
* Determine if ''P'' is is region 5 (realising that coordinate system 2 is the exact opposite of coordinate system 1).
** Check for a region 5 intersection. Return the result.
* Calculate tan(2alpha).
* Determine if ''P'' is is region 1.
** Check for a region 1 intersection. Return the result.
* Calculate the coordinates of point ''P'' in coordinate system 3.
* Determine if ''P'' is is region 6.
** Check for a region 6 intersection. Return the result.

Any but the first five steps can be moved, if that is found to be more appropriate. The algorithm includes 5 calls to a trigonomic function.

In the current combat implementation sin(beta) and cos(beta) do not need to be calculated at runtime. ''Beta'' is determined by the direction the attacker is facing. There are only four possible values for ''beta''; 0, pi/2, pi and pi*3/2. Because the half-top-angle is a property of the weapon used, sin(alpha), cos(alpha) and tan(2alpha) could be computed on startup of the game-server and stored for use.

== Simplified collision test ==
By [[User:BjÃ¸rn|BjÃ¸rn]] 00:32, 28 February 2007 (CET)

Since our enemies aren't exactly circles anyway, I'm prepared to do away with some of the above complexity. However if the above is efficiently and understandable enough, I'm prepared to go with it. What I would propose is visualized as follows:

[[Image:Circle-sector hit test.png|frame|none|Overview of a simplified test]]

In essense, the gradiented area is checked for collision instead of the exact circle. It would only require the areas with blue and red dotted lines to be checked on intersection and the circle radii to be checked for proximity. Something like:

:blueA = dir - widenessAngle
:blueB = dir + widenessAngle

:redA = cos(diskY / diskX) - cos(diskRadius / dist)
:redB = cos(diskY / diskX) + cos(diskRadius / dist)

:diskDist = sqrt(diskX*diskX + diskY*diskY)

:collision = redA < blueB && redB > blueA && diskDist - diskRadius < circleRadius

Ok that's two trigonomic function calls, two divisions and one sqrt (which could be avoided when circleRadius and diskRadius where given in their squared form).

:''The squareroot can be avoided by using:''

::diskDist2 <= (diskRadius + circleRadius)2

:''However all the trigonomic function calls, contain a distance and are not cacheable (in a meaningfull way).''
:''[[User:Avaniel|Avaniel]] 01:30, 28 February 2007 (CET)''

Hmm, or maybe I should just let the pros handle this...

Archive:Collision determination

2007-03-03T00:12:48Z

Avaniel: Improved "Circle-Sector with Disk"

{{Status_red}}

This page was created to document the collision detection algorithms used in The Mana World. After the algorithms are converted to C++ and added to the code base it is very difficult to verify the assumptions and math of the author. Therefore an explanation of the algorithms used, is given below. Of course any improvements or clarifications can allso be added and discussed on this page.

Strictly speaking, the algorithms discussed here, compute if two geometric figures intersect. However, the result is then used in a dynamic game. In the game world two objects will collide if their movement areas intersect.

== Circle-Sector with Disk ==
''By [[User:Avaniel|Avaniel]] 20:37, 27 February 2007 (CET)''

In order to determine if a circle-sector and a disk collide, we start with transforming the coordinates of the 2d space in such a way that the center of the circle-sector is located at the origin. The circle-sector can then be defined by a radius ''R'', a half-top-angle ''alpha'' and a placement angle ''beta'', as shown in diagram (1).

The disk can simply be defined by its center-point ''P'' and its radius ''RP'', where point ''P'' can be anywhere in the 2d space. See diagram (CSD-1) for an overview.

[[Image:Collision-circlesecor-disk-dimensions.png|frame|none|Diagram (CSD-1) - Overview of the Circle-Sector and Disk]]

In order to determine if the circle-sector and the circle intersect, the x-y plane is divided in 6 ''Voronoi'' like regions. The regions are based on the vertexes ''O-A'', ''O-B'' and the arc ''A-B''. They are shown in diagram (CSD-2).

[[Image:Collision-circlesecor-disk-voronoi.png|frame|none|Diagram (CSD-2) - The x-y plane divide in 6 'Voronoi' regions]]

For each region it is now determined what the pre-conditions for an overlap are, if ''P'' is in that region. If necessary, the pre-conditions for point ''P'' being in the region will be derived as well.

In the following text, a subscript ''x'' and ''y'' are used to indicate x and y coordinate of a point. If the coordinates considered are in a tranformed coordinate system, an extra indicator will be added. For example the x-coordinate of point A in the x1-y1 coordinate system is denoted as: Ax1

=== Region 1 ===

Region 1 is highlighted in diagram (CSD-3), it includes the interior of the Circle-sector. For region 1, the coordinates for point ''P'' are transformed to coordinate system 1 (shown in diagram (CSD-4)). [[:Image:Collision-circlesecor-disk-example1.png|An example of a region 1 collision is given here.]]

[[Image:Collision-circlesecor-disk-voronoi1.png|frame|none|Diagram (CSD-3) - 'Voronoi' region 1 highlighted]]
[[Image:Collision-circlesecor-disk-axis1.png|frame|none|Diagram (CSD-4) - Coordinate system 1]]

The coordinates for point ''P'' in coordinate system 1 are:

:Px1 = Px cos(beta-alpha) + Py sin(beta-alpha)

:Py1 = Py cos(beta-alpha) - Px sin(beta-alpha)

Using goniometric relations this can be simplified to:

:Px1 = Px {cos(alpha)cos(beta) + sin(alpha)sin(beta)} + Py {-sin(alpha)cos(beta) + cos(alpha)sin(beta)}

:Py1 = Py {cos(alpha)cos(beta) + sin(alpha)sin(beta)} - Px {-sin(alpha)cos(beta) + cos(alpha)sin(beta)}

Point ''P'' is inside region 1 if

:Px1 >= 0 , Py1 >= 0 and Py1 <= Px1 tan(2alpha) = Px1 {2sin(alpha)cos(alpha) / (cos2(alpha) - sin2(alpha))}

The Circle-sector and the disc then intersect if

:Px2 + Py2 <= (R + RP)2

=== Region 2 ===

Region 2 is highlighted in diagram (CSD-5). For this region no coordinate transformations are necessary. [[:Image:Collision-circlesecor-disk-example2.png|An example of a region 2 collision is given here.]]

[[Image:Collision-circlesecor-disk-voronoi2.png|frame|none|Diagram (CSD-5) - 'Voronoi' region 2 highlighted]]

If point ''P'' is inside region 2, the circle-sector and the disk can only intersect if point ''B'' is inside the circle.

:(Px - Bx)2 + (Py - By)2 <= RP2

The coordinates of point ''B'' are:

:Bx = R cos(alpha + beta) = R {cos(alpha)cos(beta) - sin(alpha)sin(beta)}

:By = R sin(alpha + beta) = R {sin(alpha)cos(beta) + cos(alpha)sin(beta)}

With the coordinates for ''B'' the condition can now be evaluated.

=== Region 3 ===

Region 3 is highlighted in diagram (CSD-6). For this region no coordinate transformations are necessary. [[:Image:Collision-circlesecor-disk-example3.png|An example of a region 3 collision is given here.]]

[[Image:Collision-circlesecor-disk-voronoi3.png|frame|none|Diagram (CSD-6) - 'Voronoi' region 3 highlighted]]

Analogous to region 2, the circle-sector and the disk can only intersect if point ''A'' is inside the disk. The condition for this is:

:(Px - Ax)2 + (Py - Ay)2 <= RP2

The coordinates of point ''A'' are:

:Ax = R cos(-alpha + beta) = R {cos(alpha)cos(beta) + sin(alpha)sin(beta)}

:Ay = R sin(-alpha + beta) = R {-sin(alpha)cos(beta) + cos(alpha)sin(beta)}

With the coordinates for ''A'' the condition can now be evaluated.

=== Region 4 ===

Region 4 is highlighted in diagram (CSD-7). For this region no coordinate transformations are necessary. [[:Image:Collision-circlesecor-disk-example4.png|An example of a region 4 collision is given here.]]

[[Image:Collision-circlesecor-disk-voronoi4.png|frame|none|Diagram (CSD-7) - 'Voronoi' region 4 highlighted]]

Analogous to regions 2 and 3, the circle-sector and the disk can only intersect if point ''O'' is inside the disk. The condition for this is:

:Px2 + Py2 <= RP2

=== Region 5 ===

Region 5 is highlighted in diagram (CSD-8). For region 5, the coordinates for point ''P'' are transformed to coordinate system 2 (shown in diagram (CSD-9)). [[:Image:Collision-circlesecor-disk-example5.png|An example of a region 5 collision is given here.]]

[[Image:Collision-circlesecor-disk-voronoi5.png|frame|none|Diagram (CSD-8) - 'Voronoi' region 5 highlighted]]
[[Image:Collision-circlesecor-disk-axis2.png|frame|none|Diagram (CSD-9) - Coordinate system 2]]

In the local coordinates the following conditions for ''P'' being in region 5, can be formulated:

:Px2 <= 0, Px2 >= -R and Py2 >= 0

The condition for the circle-sector and the disk intersecting is:

:Py2 <= RP

The coordinates for ''P'' in coordinate system 2 are given by:

:Px2 = Pxcos(alpha + beta + pi) + Pysin(alpha + beta + pi)

:Py2 = Pycos(alpha + beta + pi) - Pxsin(alpha + beta + pi)

Using the goniometric relations to handle the ''pi'' term first, the coordinates become:

:Px2 = -Pxcos(alpha + beta) + Pysin(alpha + beta )

:Py2 = -Pycos(alpha + beta) - Pxsin(alpha + beta )

Now using the goniometric relations to seperate ''alpha'' and ''beta'':

:Px2 = -Px{cos(alpha)cos(beta) - sin(alpha)sin(beta)} + Py{sin(alpha)cos(beta) + cos(alpha)sin(beta)}

:Py2 = -Py{cos(alpha)cos(beta) - sin(alpha)sin(beta)} - Px{sin(alpha)cos(beta) + cos(alpha)sin(beta)}

The conditions can now be evaluated.

=== Region 6 ===

Region 6 is highlighted in diagram (CSD-10). For region 6, the coordinates for point ''P'' are transformed to coordinate system 3 (shown in diagram (CSD-11)). [[:Image:Collision-circlesecor-disk-example6.png|An example of a region 6 collision is given here.]]

[[Image:Collision-circlesecor-disk-voronoi6.png|frame|none|Diagram (CSD-10) - 'Voronoi' region 6 highlighted]]
[[Image:Collision-circlesecor-disk-axis3.png|frame|none|Diagram (CSD-11) - Coordinate system 3]]

In the local coordinates the following conditions for ''P'' being in region 6, can be formulated:

:Px3 >= 0, Px3 <= R and Py3 >= 0

The condition for the circle-sector and the disk intersecting is:

:Py3 <= RP

The coordinates for ''P'' in coordinate system 3 are given by:

:Px3 = Pxcos(alpha + beta) + Pysin(alpha + beta)

:Py3 = Pycos(alpha + beta) - Pxsin(alpha + beta)

Now using the goniometric relations to seperate ''alpha'' and ''beta'':

:Px3 = Px{cos(alpha)cos(beta) - sin(alpha)sin(beta)} + Py{sin(alpha)cos(beta) + cos(alpha)sin(beta)}

:Py3 = Py{cos(alpha)cos(beta) - sin(alpha)sin(beta)} - Px{sin(alpha)cos(beta) + cos(alpha)sin(beta)}

The conditions can now be evaluated.

=== Bounding Circle ===

The above laid out method is mathematically accurate and sufficient. However, it is not very fast. By applying a bounding circle and checking if the disk intersects with that, a lot of the work above can be simplified to just a few equations. An overview of the bounding circle is given in diagram (CSD-12). For these calculations coordinate system 4 will be used, which is shown in diagram (CSD-13).

[[Image:Collision-circlesecor-disk-boundingcircle.png|frame|none|Diagram (CSD-12) - Overview of the bounding circle]]
[[Image:Collision-circlesecor-disk-axis4.png|frame|none|Diagram (CSD-13) - Coordinate system 4]]

The radius of the bounding circle ''RC'' is given by:

:RC = R / (2*cos(alpha))

The coordinates of the center point in coordinate system 4 are then given by:

:Cx4 = R / (2*cos(alpha))

:Cy4 = 0

The coordinates for ''P'' in coordinate system 4 are given by:

:Px4 = Pxcos(beta) + Pysin(beta)

:Py4 = Pycos(beta) - Pxsin(beta)

The condition for the disk intersecting the bounding circle is then given by:

:(Px4 - Cx4)2 + (Py4 - Cy4)2 <= (RP + RC)2

Inserting the values for ''Cx4'', ''Cx4'' and ''RC'', into the condition yields:

:(Px42 + Py42)*cos(alpha) - Px4*R <= RP2*cos(alpha) + RP*R

To achieve this result, both sides where multiplied by ''(2*cos(alpha))'', which means that an extra condition is imposed.:

:cos(alpha) > 0; alpha < 90o

Together with the observation that the bounding circle becomes infinitly large at a value for ''alpha'' of 90o, we have to limit ''alpha'' to a maximum of 85o, for practical reasons.

The condition can now be evaluated.

=== The Algorithm ===

The following values need to be given; the radius of the circle-sector ''R'', the half-top-angle ''alpha'', the placement angle ''beta'', the coordinates of the center of the circle-sector, the coordinates of the center of the disk ''P'' and the radius of the disk ''RP''.
* Subtract the coordinates of the center of the circle sector from the coordinates of point ''P'', thereby obtaining the coordinates of ''P'' in the primary coordinate system.
* Calculate sin(alpha), cos(alpha), sin(beta) and cos(beta) and store them in temporary variables.
* Calculate the coordinates of point ''P'' in coordinate system 4.
* Check for an intersection with the bounding circle.
** Return false if there is no intersection.
* Calculate the coordinates of point ''P'' in coordinate system 1.
* Check if ''P'' is is region 5 (realising that coordinate system 2 is the exact opposite of coordinate system 1).
** Check for a region 5 intersection. Return the result.
* Calculate tan(2alpha).
* Check if ''P'' is is region 1.
** Check for a region 1 intersection. Return the result.
* Calculate the coordinates of point ''P'' in coordinate system 3.
* Check if ''P'' is is region 6.
** Check for a region 6 intersection. Return the result.
* If ''P'' is not in region 1, region 5 or region 6, but the disk does intersect the bounding circle, then the intersection must be in region 2, region 3, or region 4.

Any but the first five steps can be moved, if that is found to be more appropriate. The algorithm includes 5 calls to a trigonomic function.

In the current combat implementation sin(beta) and cos(beta) do not need to be calculated at runtime. ''Beta'' is determined by the direction the attacker is facing. There are only four possible values for ''beta''; 0, pi/2, pi and pi*3/2. Because the half-top-angle is a property of the weapon used, sin(alpha), cos(alpha) and tan(2alpha) could be computed on startup of the game-server and stored for use.

== Simplified collision test ==
By [[User:BjÃ¸rn|BjÃ¸rn]] 00:32, 28 February 2007 (CET)

Since our enemies aren't exactly circles anyway, I'm prepared to do away with some of the above complexity. However if the above is efficiently and understandable enough, I'm prepared to go with it. What I would propose is visualized as follows:

[[Image:Circle-sector hit test.png|frame|none|Overview of a simplified test]]

In essense, the gradiented area is checked for collision instead of the exact circle. It would only require the areas with blue and red dotted lines to be checked on intersection and the circle radii to be checked for proximity. Something like:

:blueA = dir - widenessAngle
:blueB = dir + widenessAngle

:redA = cos(diskY / diskX) - cos(diskRadius / dist)
:redB = cos(diskY / diskX) + cos(diskRadius / dist)

:diskDist = sqrt(diskX*diskX + diskY*diskY)

:collision = redA < blueB && redB > blueA && diskDist - diskRadius < circleRadius

Ok that's two trigonomic function calls, two divisions and one sqrt (which could be avoided when circleRadius and diskRadius where given in their squared form).

:''The squareroot can be avoided by using:''

::diskDist2 <= (diskRadius + circleRadius)2

:''However all the trigonomic function calls, contain a distance and are not cacheable (in a meaningfull way).''
:''[[User:Avaniel|Avaniel]] 01:30, 28 February 2007 (CET)''

Hmm, or maybe I should just let the pros handle this...

File:Collision-circlesecor-disk-axis4.png

2007-03-02T21:30:34Z

Avaniel:

File:Collision-circlesecor-disk-boundingcircle.png

2007-03-02T21:30:20Z

Avaniel:

Development:Developers

2007-03-01T14:29:29Z

Avaniel: Modified the Avaniel entry

== Active ==
{| border="0" cellspacing="0" cellpadding="5" width="100%" style="border-bottom: 2px solid #efdead"
! style="background:#efdead;" width="150px" align="left" | Name
! style="background:#efdead;" width="200px" align="left" | Occupation
! style="background:#efdead;" width="150px" align="left" | Location

{{dev1| [[User:Bertram|Bertram]] | Programmer, Debian package maintainer | France}}
{{dev2| [[User:BjÃ¸rn|BjÃ¸rn Lindeijer]] | Lead Programmer | The Netherlands}}
{{dev1| [[User:Crush|Crush]] | Pixel artist, mapper, programmer | Germany}}
{{dev2| [[User:Dabe|Dabe]] | Story and Geography writer | }}
{{dev1| [[User:Doener|Doener]] | Programmer | Germany}}
{{dev2| [[User:ElvenProgrammer|ElvenProgrammer]] | Project leader, programmer | Italy}}
{{dev1| [[User:Silene|Guillaume Melquiond (Silene)]] | Programmer | France}}
{{dev2| [[User:Irukard|Irukard]] | Pixel artist | Poland}}
{{dev1| [[User:maci|maci]] | User support | Germany}}
{{dev2| [[User:hackgrid|Matt]] | Blabbering idiot | Germany}}
{{dev1| [[User:Modanung|Modanung]] | Pixel artist, concept artist | The Netherlands}}
{{dev2| [[User:Pajarico|Pajarico]] | Art, writer | Spain}}
{{dev1| [[User:Pauan|Pauan]] | Graphics artist | USA}}
{{dev2| [[User:Platyna|Platyna]] | Slackware package maintainer | Poland}}
{{dev1| [[User:Avaniel|Rogier Polak (Avaniel)]] | Programmer | The Netherlands}}
{{dev2| [[User:Rotonen|Rotonen]] | Head of art, story and music | Finland}}
{{dev1| [[User:Trapdoor|trapdoor]] | Programmer |}}
{{dev2| [[User:Tuxtgz|Tuxtgz]] | Webinterface-Programmer | Germany}}
{{dev1| [[User:VictorSan|VictorSan]] | Programmer | Spain}}
|}

== Retired ==
{| border="0" cellspacing="0" cellpadding="5" width="100%" style="border-bottom: 2px solid #efdead"
! style="background:#efdead;" width="150px" align="left" | Name
! style="background:#efdead;" width="200px" align="left" | Occupation
! style="background:#efdead;" width="150px" align="left" | Location

{{dev1| [[User:Gagaofdeath|Andrej Sinicyn]] | Programmer | Germany}}
{{dev2| [[User:Bear|Bear]] | Scripter | USA}}
{{dev1| [[User:Catfish_Man|Catfish_Man]] | Mac port | USA}}
{{dev2| Chetic | Mapper | }}
{{dev1| [[User:Clef|Clef]] | Pixel artist | }}
{{dev2| [[User:Demon|Demon]] | Pixel artist | }}
{{dev1| [[User:deviexx|deviexx]] | Content manager | }}
{{dev2| [[User:Golgo|Golgo]] | Pixel artist | }}
{{dev1| Gnulia | Concept artist | }}
{{dev2| Igor Morgado (imorgado) | Tester | }}
{{dev1| [[User:Javila|Javila]] | Programmer | Brazil}}
{{dev2| [[User:kindjal|kindjal]] | Programmer | France, currently Italy}}
{{dev1| [[User:Kinetic|Kinetic]] | Pixel artist | USA}}
{{dev2| kth5 (Shura) | Programmer | }}
{{dev1| [[User:Kyokai|Kyokai]] | Game systems designer | }}
{{dev2| [[User:Maester Pixel|Maester Pixel]] | Pixel artist | USA}}
{{dev1| [[User:Magick|Magick]] | Musician | }}
{{dev2| [[User:Mkael|Mkael]] | Concept artist | Finland}}
{{dev1| [[User:Mra|Mra]] | Programmer | Germany}}
{{dev2| [[User:Neko-mon|Neko-mon]] | Pixel artist | Brazil}}
{{dev1| Neorice | Pixel artist | }}
{{dev2| [[User:Nym|nym]] | Programmer | Australia}}
{{dev1| Rodney Dawes (dobey) | Packager (install process) | }}
{{dev2| Romulo Fernandes (razor85) | Artist | }}
{{dev1| Simon Edwardsson (simonedw/simedw) | Packager (Mac) | }}
{{dev2| [[User:Sora|Sora]] | Pixel artist | Poland}}
{{dev1| [[User:Sull|Sull]] | Pixel artist and hosting | Canada}}
{{dev2| [[User:Talaroc|Talaroc]] | Pixel artist | }}
{{dev1| Ti Sing Hao | Musician | }}
{{dev2| Ultramichy | Hosting | }}
{{dev1| [[User:Usiu|Mateusz Kaduk (Usiu)]] | Programmer | Poland}}
{{dev2| Vlady | Artist | }}
{{dev1| zenogais (bitshift2002) | Programmer | }}
|}

Archive:Collision determination

2007-02-28T00:30:15Z

Avaniel: Comments @BjÃ¸rn:Simplified collision test

{{Status_red}}

This page was created to document the collision detection algorithms used in The Mana World. After the algorithms are converted to C++ and added to the code base it is very difficult to verify the assumptions and math of the author. Therefore an explanation of the algorithms used, is given below. Of course any improvements or clarifications can allso be added and discussed on this page.

Strictly speaking, the algorithms discussed here, compute if two geometric figures intersect. However, the result is then used in a dynamic game. In the game world two objects will collide if their movement areas intersect.

== Circle-Sector with Disk ==
''By [[User:Avaniel|Avaniel]] 20:37, 27 February 2007 (CET)''

In order to determine if a circle-sector and a disk collide, we start with transforming the coordinates of the 2d space in such a way that the center of the circle-sector is located at the origin. The circle-sector can then be defined by a radius ''R'', a half-top-angle ''alpha'' and a placement angle ''beta'', as shown in diagram (1).

The disk can simply be defined by its center-point ''P'' and its radius ''RP'', where point ''P'' can be anywhere in the 2d space. See diagram (CSD-1) for an overview.

[[Image:Collision-circlesecor-disk-dimensions.png|frame|none|Diagram (CSD-1) - Overview of the Circle-Sector and Disk]]

In order to determine if the circle-sector and the circle intersect, the x-y plane is divided in 6 ''Voronoi'' like regions. The regions are based on the vertexes ''O-A'', ''O-B'' and the arc ''A-B''. They are shown in diagram (CSD-2).

[[Image:Collision-circlesecor-disk-voronoi.png|frame|none|Diagram (CSD-2) - The x-y plane divide in 6 'Voronoi' regions]]

For each region it is now determined what the pre-conditions for an overlap are, if ''P'' is in that region. If necessary, the pre-conditions for point ''P'' being in the region will be derived as well.

In the following text, a subscript ''x'' and ''y'' are used to indicate x and y coordinate of a point. If the coordinates considered are in a tranformed coordinate system, an extra indicator will be added. For example the x-coordinate of point A in the x1-y1 coordinate system is denoted as: Ax1

=== Region 1 ===

Region 1 is highlighted in diagram (CSD-3), it includes the interior of the Circle-sector. For region 1, the coordinates for point ''P'' are transformed to coordinate system 1 (shown in diagram (CSD-4)). [[:Image:Collision-circlesecor-disk-example1.png|An example of a region 1 collision is given here.]]

[[Image:Collision-circlesecor-disk-voronoi1.png|frame|none|Diagram (CSD-3) - 'Voronoi' region 1 highlighted]]
[[Image:Collision-circlesecor-disk-axis1.png|frame|none|Diagram (CSD-4) - Coordinate system 1]]

The coordinates for point ''P'' in coordinate system 1 are:

:Px1 = Px cos(beta-alpha) + Py sin(beta-alpha)

:Py1 = Py cos(beta-alpha) - Px sin(beta-alpha)

Using goniometric relations this can be simplified to:

:Px1 = Px {cos(alpha)cos(beta) + sin(alpha)sin(beta)} + Py {-sin(alpha)cos(beta) + cos(alpha)sin(beta)}

:Py1 = Py {cos(alpha)cos(beta) + sin(alpha)sin(beta)} - Px {-sin(alpha)cos(beta) + cos(alpha)sin(beta)}

Point ''P'' is inside region 1 if

:Px1 >= 0 , Py1 >= 0 and Py1 <= Px1 tan(2alpha) = Px1 {2sin(alpha)cos(alpha) / (cos2(alpha) - sin2(alpha))}

The Circle-sector and the disc then intersect if

:Px2 + Py2 <= (R + RP)2

=== Region 2 ===

Region 2 is highlighted in diagram (CSD-5). For this region no coordinate transformations are necessary. [[:Image:Collision-circlesecor-disk-example2.png|An example of a region 2 collision is given here.]]

[[Image:Collision-circlesecor-disk-voronoi2.png|frame|none|Diagram (CSD-5) - 'Voronoi' region 2 highlighted]]

If point ''P'' is inside region 2, the circle-sector and the disk can only intersect if point ''B'' is inside the circle.

:(Px - Bx)2 + (Py - By)2 <= RP2

The coordinates of point ''B'' are:

:Bx = R cos(alpha + beta) = R {cos(alpha)cos(beta) - sin(alpha)sin(beta)}

:By = R sin(alpha + beta) = R {sin(alpha)cos(beta) + cos(alpha)sin(beta)}

With the coordinates for ''B'' the condition can now be evaluated.

=== Region 3 ===

Region 3 is highlighted in diagram (CSD-6). For this region no coordinate transformations are necessary. [[:Image:Collision-circlesecor-disk-example3.png|An example of a region 3 collision is given here.]]

[[Image:Collision-circlesecor-disk-voronoi3.png|frame|none|Diagram (CSD-6) - 'Voronoi' region 3 highlighted]]

Analogous to region 2, the circle-sector and the disk can only intersect if point ''A'' is inside the disk. The condition for this is:

:(Px - Ax)2 + (Py - Ay)2 <= RP2

The coordinates of point ''A'' are:

:Ax = R cos(-alpha + beta) = R {cos(alpha)cos(beta) + sin(alpha)sin(beta)}

:Ay = R sin(-alpha + beta) = R {-sin(alpha)cos(beta) + cos(alpha)sin(beta)}

With the coordinates for ''A'' the condition can now be evaluated.

=== Region 4 ===

Region 4 is highlighted in diagram (CSD-7). For this region no coordinate transformations are necessary. [[:Image:Collision-circlesecor-disk-example4.png|An example of a region 4 collision is given here.]]

[[Image:Collision-circlesecor-disk-voronoi4.png|frame|none|Diagram (CSD-7) - 'Voronoi' region 4 highlighted]]

Analogous to regions 2 and 3, the circle-sector and the disk can only intersect if point ''O'' is inside the disk. The condition for this is:

:Px2 + Py2 <= RP2

=== Region 5 ===

Region 5 is highlighted in diagram (CSD-8). For region 5, the coordinates for point ''P'' are transformed to coordinate system 2 (shown in diagram (CSD-9)). [[:Image:Collision-circlesecor-disk-example5.png|An example of a region 5 collision is given here.]]

[[Image:Collision-circlesecor-disk-voronoi5.png|frame|none|Diagram (CSD-8) - 'Voronoi' region 5 highlighted]]
[[Image:Collision-circlesecor-disk-axis2.png|frame|none|Diagram (CSD-9) - Coordinate system 2]]

In the local coordinates the following conditions for ''P'' being in region 5, can be formulated:

:Px2 <= 0, Px2 >= -R and Py2 >= 0

The condition for the circle-sector and the disk intersecting is:

:Py2 <= RP

The coordinates for ''P'' in coordinate system 2 are given by:

:Px2 = Pxcos(alpha + beta + pi) + Pysin(alpha + beta + pi)

:Py2 = Pycos(alpha + beta + pi) - Pxsin(alpha + beta + pi)

Using the goniometric relations to handle the ''pi'' term first, the coordinates become:

:Px2 = -Pxcos(alpha + beta) + Pysin(alpha + beta )

:Py2 = -Pycos(alpha + beta) - Pxsin(alpha + beta )

Now using the goniometric relations to seperate ''alpha'' and ''beta'':

:Px2 = -Px{cos(alpha)cos(beta) - sin(alpha)sin(beta)} + Py{sin(alpha)cos(beta) + cos(alpha)sin(beta)}

:Py2 = -Py{cos(alpha)cos(beta) - sin(alpha)sin(beta)} - Px{sin(alpha)cos(beta) + cos(alpha)sin(beta)}

The conditions can now be evaluated.

=== Region 6 ===

Region 6 is highlighted in diagram (CSD-10). For region 6, the coordinates for point ''P'' are transformed to coordinate system 3 (shown in diagram (CSD-11)). [[:Image:Collision-circlesecor-disk-example6.png|An example of a region 6 collision is given here.]]

[[Image:Collision-circlesecor-disk-voronoi6.png|frame|none|Diagram (CSD-10) - 'Voronoi' region 6 highlighted]]
[[Image:Collision-circlesecor-disk-axis3.png|frame|none|Diagram (CSD-11) - Coordinate system 3]]

In the local coordinates the following conditions for ''P'' being in region 6, can be formulated:

:Px3 >= 0, Px3 <= R and Py3 >= 0

The condition for the circle-sector and the disk intersecting is:

:Py3 <= RP

The coordinates for ''P'' in coordinate system 3 are given by:

:Px3 = Pxcos(alpha + beta) + Pysin(alpha + beta)

:Py3 = Pycos(alpha + beta) - Pxsin(alpha + beta)

Now using the goniometric relations to seperate ''alpha'' and ''beta'':

:Px3 = Px{cos(alpha)cos(beta) - sin(alpha)sin(beta)} + Py{sin(alpha)cos(beta) + cos(alpha)sin(beta)}

:Py3 = Py{cos(alpha)cos(beta) - sin(alpha)sin(beta)} - Px{sin(alpha)cos(beta) + cos(alpha)sin(beta)}

The conditions can now be evaluated.

=== The Algorithm ===

The following values need to be given; the radius of the circle-sector ''R'', the half-top-angle ''alpha'', the placement angle ''beta'', the coordinates of the center of the circle-sector, the coordinates of the center of the disk ''P'' and the radius of the disk ''RP''.
* Subtract the coordinates of the center of the circle sector from the coordinates of point ''P''.
* Check for a region 4 intersection.
* Calculate sin(alpha), cos(alpha), sin(beta) and cos(beta) and store them in temporary variables.
* Calculate the coordinates of point ''A''.
* Check for a region 3 intersection.
* Calculate the coordinates of point ''B''.
* Check for a region 2 intersection.
* Calculate the coordinates of point ''P'' in coordinate system 2.
* Check for a region 5 intersection.
* Calculate the coordinates of point ''P'' in coordinate system 3.
* Check for a region 6 intersection.
* Calculate the coordinates of point ''P'' in coordinate system 1 and tan(2alpha).
* Check for a region 1 intersection.

Any but the first three steps can be moved, if that is found to be more appropriate. The algorithm includes 4 calls to a trigonomic function and just 1 division.

In the current combat implementation sin(beta) and cos(beta) do not need to be calculated at runtime. ''Beta'' is determined by the direction the attacker is facing. There are only four possible values for ''beta''; 0, pi/2, pi and pi*3/2. Because the half-top-angle is a property of the weapon used, sin(alpha), cos(alpha) and tan(2alpha) could be computed on startup of the game-server and stored for use.

== Simplified collision test ==
By [[User:BjÃ¸rn|BjÃ¸rn]] 00:32, 28 February 2007 (CET)

Since our enemies aren't exactly circles anyway, I'm prepared to do away with some of the above complexity. However if the above is efficiently and understandable enough, I'm prepared to go with it. What I would propose is visualized as follows:

[[Image:Circle-sector hit test.png|frame|none|Overview of a simplified test]]

In essense, the gradiented area is checked for collision instead of the exact circle. It would only require the areas with blue and red dotted lines to be checked on intersection and the circle radii to be checked for proximity. Something like:

:blueA = dir - widenessAngle
:blueB = dir + widenessAngle

:redA = cos(diskY / diskX) - cos(diskRadius / dist)
:redB = cos(diskY / diskX) + cos(diskRadius / dist)

:diskDist = sqrt(diskX*diskX + diskY*diskY)

:collision = redA < blueB && redB > blueA && diskDist - diskRadius < circleRadius

Ok that's two trigonomic function calls, two divisions and one sqrt (which could be avoided when circleRadius and diskRadius where given in their squared form).

:''The squareroot can be avoided by using:''

::diskDist2 <= (diskRadius + circleRadius)2

:''However all the trigonomic function calls, contain a distance and are not cacheable (in a meaningfull way).''
:''[[User:Avaniel|Avaniel]] 01:30, 28 February 2007 (CET)''

Hmm, or maybe I should just let the pros handle this...

Archive:Collision determination

2007-02-27T21:33:58Z

Avaniel: Fixed typos

{{Status_red}}

This page was created to document the collision detection algorithms used in The Mana World. After the algorithms are converted to C++ and added to the code base it is very difficult to verify the assumptions and math of the author. Therefore an explanation of the algorithms used, is given below. Of course any improvements or clarifications can allso be added and discussed on this page.

Strictly speaking, the algorithms discussed here, compute if two geometric figures intersect. However, the result is then used in a dynamic game. In the game world two objects will collide if their movement areas intersect.

== Circle-Sector with Disk ==
''By [[User:Avaniel|Avaniel]] 20:37, 27 February 2007 (CET)''

In order to determine if a circle-sector and a disk collide, we start with transforming the coordinates of the 2d space in such a way that the center of the circle-sector is located at the origin. The circle-sector can then be defined by a radius ''R'', a half-top-angle ''alpha'' and a placement angle ''beta'', as shown in diagram (1).

The disk can simply be defined by its center-point ''P'' and its radius ''RP'', where point ''P'' can be anywhere in the 2d space. See diagram (CSD-1) for an overview.

[[Image:Collision-circlesecor-disk-dimensions.png|frame|none|Diagram (CSD-1) - Overview of the Circle-Sector and Disk]]

In order to determine if the circle-sector and the circle intersect, the x-y plane is divided in 6 ''Voronoi'' like regions. The regions are based on the vertexes ''O-A'', ''O-B'' and the arc ''A-B''. They are shown in diagram (CSD-2).

[[Image:Collision-circlesecor-disk-voronoi.png|frame|none|Diagram (CSD-2) - The x-y plane divide in 6 'Voronoi' regions]]

For each region it is now determined what the pre-conditions for an overlap are, if ''P'' is in that region. If necessary, the pre-conditions for point ''P'' being in the region will be derived as well.

In the following text, a subscript ''x'' and ''y'' are used to indicate x and y coordinate of a point. If the coordinates considered are in a tranformed coordinate system, an extra indicator will be added. For example the x-coordinate of point A in the x1-y1 coordinate system is denoted as: Ax1

=== Region 1 ===

Region 1 is highlighted in diagram (CSD-3), it includes the interior of the Circle-sector. For region 1, the coordinates for point ''P'' are transformed to coordinate system 1 (shown in diagram (CSD-4)). [[:Image:Collision-circlesecor-disk-example1.png|An example of a region 1 collision is given here.]]

[[Image:Collision-circlesecor-disk-voronoi1.png|frame|none|Diagram (CSD-3) - 'Voronoi' region 1 highlighted]]
[[Image:Collision-circlesecor-disk-axis1.png|frame|none|Diagram (CSD-4) - Coordinate system 1]]

The coordinates for point ''P'' in coordinate system 1 are:

:Px1 = Px cos(beta-alpha) + Py sin(beta-alpha)

:Py1 = Py cos(beta-alpha) - Px sin(beta-alpha)

Using goniometric relations this can be simplified to:

:Px1 = Px {cos(alpha)cos(beta) + sin(alpha)sin(beta)} + Py {-sin(alpha)cos(beta) + cos(alpha)sin(beta)}

:Py1 = Py {cos(alpha)cos(beta) + sin(alpha)sin(beta)} - Px {-sin(alpha)cos(beta) + cos(alpha)sin(beta)}

Point ''P'' is inside region 1 if

:Px1 >= 0 , Py1 >= 0 and Py1 <= Px1 tan(2alpha) = Px1 {2sin(alpha)cos(alpha) / (cos2(alpha) - sin2(alpha))}

The Circle-sector and the disc then intersect if

:Px2 + Py2 <= (R + RP)2

=== Region 2 ===

Region 2 is highlighted in diagram (CSD-5). For this region no coordinate transformations are necessary. [[:Image:Collision-circlesecor-disk-example2.png|An example of a region 2 collision is given here.]]

[[Image:Collision-circlesecor-disk-voronoi2.png|frame|none|Diagram (CSD-5) - 'Voronoi' region 2 highlighted]]

If point ''P'' is inside region 2, the circle-sector and the disk can only intersect if point ''B'' is inside the circle.

:(Px - Bx)2 + (Py - By)2 <= RP2

The coordinates of point ''B'' are:

:Bx = R cos(alpha + beta) = R {cos(alpha)cos(beta) - sin(alpha)sin(beta)}

:By = R sin(alpha + beta) = R {sin(alpha)cos(beta) + cos(alpha)sin(beta)}

With the coordinates for ''B'' the condition can now be evaluated.

=== Region 3 ===

Region 3 is highlighted in diagram (CSD-6). For this region no coordinate transformations are necessary. [[:Image:Collision-circlesecor-disk-example3.png|An example of a region 3 collision is given here.]]

[[Image:Collision-circlesecor-disk-voronoi3.png|frame|none|Diagram (CSD-6) - 'Voronoi' region 3 highlighted]]

Analogous to region 2, the circle-sector and the disk can only intersect if point ''A'' is inside the disk. The condition for this is:

:(Px - Ax)2 + (Py - Ay)2 <= RP2

The coordinates of point ''A'' are:

:Ax = R cos(-alpha + beta) = R {cos(alpha)cos(beta) + sin(alpha)sin(beta)}

:Ay = R sin(-alpha + beta) = R {-sin(alpha)cos(beta) + cos(alpha)sin(beta)}

With the coordinates for ''A'' the condition can now be evaluated.

=== Region 4 ===

Region 4 is highlighted in diagram (CSD-7). For this region no coordinate transformations are necessary. [[:Image:Collision-circlesecor-disk-example4.png|An example of a region 4 collision is given here.]]

[[Image:Collision-circlesecor-disk-voronoi4.png|frame|none|Diagram (CSD-7) - 'Voronoi' region 4 highlighted]]

Analogous to regions 2 and 3, the circle-sector and the disk can only intersect if point ''O'' is inside the disk. The condition for this is:

:Px2 + Py2 <= RP2

=== Region 5 ===

Region 5 is highlighted in diagram (CSD-8). For region 5, the coordinates for point ''P'' are transformed to coordinate system 2 (shown in diagram (CSD-9)). [[:Image:Collision-circlesecor-disk-example5.png|An example of a region 5 collision is given here.]]

[[Image:Collision-circlesecor-disk-voronoi5.png|frame|none|Diagram (CSD-8) - 'Voronoi' region 5 highlighted]]
[[Image:Collision-circlesecor-disk-axis2.png|frame|none|Diagram (CSD-9) - Coordinate system 2]]

In the local coordinates the following conditions for ''P'' being in region 5, can be formulated:

:Px2 <= 0, Px2 >= -R and Py2 >= 0

The condition for the circle-sector and the disk intersecting is:

:Py2 <= RP

The coordinates for ''P'' in coordinate system 2 are given by:

:Px2 = Pxcos(alpha + beta + pi) + Pysin(alpha + beta + pi)

:Py2 = Pycos(alpha + beta + pi) - Pxsin(alpha + beta + pi)

Using the goniometric relations to handle the ''pi'' term first, the coordinates become:

:Px2 = -Pxcos(alpha + beta) + Pysin(alpha + beta )

:Py2 = -Pycos(alpha + beta) - Pxsin(alpha + beta )

Now using the goniometric relations to seperate ''alpha'' and ''beta'':

:Px2 = -Px{cos(alpha)cos(beta) - sin(alpha)sin(beta)} + Py{sin(alpha)cos(beta) + cos(alpha)sin(beta)}

:Py2 = -Py{cos(alpha)cos(beta) - sin(alpha)sin(beta)} - Px{sin(alpha)cos(beta) + cos(alpha)sin(beta)}

The conditions can now be evaluated.

=== Region 6 ===

Region 6 is highlighted in diagram (CSD-10). For region 6, the coordinates for point ''P'' are transformed to coordinate system 3 (shown in diagram (CSD-11)). [[:Image:Collision-circlesecor-disk-example6.png|An example of a region 6 collision is given here.]]

[[Image:Collision-circlesecor-disk-voronoi6.png|frame|none|Diagram (CSD-10) - 'Voronoi' region 6 highlighted]]
[[Image:Collision-circlesecor-disk-axis3.png|frame|none|Diagram (CSD-11) - Coordinate system 3]]

In the local coordinates the following conditions for ''P'' being in region 6, can be formulated:

:Px3 >= 0, Px3 <= R and Py3 >= 0

The condition for the circle-sector and the disk intersecting is:

:Py3 <= RP

The coordinates for ''P'' in coordinate system 3 are given by:

:Px3 = Pxcos(alpha + beta) + Pysin(alpha + beta)

:Py3 = Pycos(alpha + beta) - Pxsin(alpha + beta)

Now using the goniometric relations to seperate ''alpha'' and ''beta'':

:Px3 = Px{cos(alpha)cos(beta) - sin(alpha)sin(beta)} + Py{sin(alpha)cos(beta) + cos(alpha)sin(beta)}

:Py3 = Py{cos(alpha)cos(beta) - sin(alpha)sin(beta)} - Px{sin(alpha)cos(beta) + cos(alpha)sin(beta)}

The conditions can now be evaluated.

=== The Algorithm ===

The following values need to be given; the radius of the circle-sector ''R'', the half-top-angle ''alpha'', the placement angle ''beta'', the coordinates of the center of the circle-sector, the coordinates of the center of the disk ''P'' and the radius of the disk ''RP''.
* Subtract the coordinates of the center of the circle sector from the coordinates of point ''P''.
* Check for a region 4 intersection.
* Calculate sin(alpha), cos(alpha), sin(beta) and cos(beta) and store them in temporary variables.
* Calculate the coordinates of point ''A''.
* Check for a region 3 intersection.
* Calculate the coordinates of point ''B''.
* Check for a region 2 intersection.
* Calculate the coordinates of point ''P'' in coordinate system 2.
* Check for a region 5 intersection.
* Calculate the coordinates of point ''P'' in coordinate system 3.
* Check for a region 6 intersection.
* Calculate the coordinates of point ''P'' in coordinate system 1 and tan(2alpha).
* Check for a region 1 intersection.

Any but the first three steps can be moved, if that is found to be more appropriate. The algorithm includes 4 calls to a trigonomic function and just 1 division.

In the current combat implementation sin(beta) and cos(beta) do not need to be calculated at runtime. ''Beta'' is determined by the direction the attacker is facing. There are only four possible values for ''beta''; 0, pi/2, pi and pi*3/2. Because the half-top-angle is a property of the weapon used, sin(alpha), cos(alpha) and tan(2alpha) could be computed on startup of the game-server and stored for use.

Archive:Collision determination

2007-02-27T19:37:37Z

Avaniel: Final touch...

{{Status_red}}

This page was created to document the collision detection algorithms used in The Mana World. After the algorithms are converted to C++ and added to the code base it is very difficult to verify the assumptions and math of the author. Therefore an explanation of the algorithms used, is given below. Of course any improvements or clarifications can allso be added and discussed on this page.

Strictly speaking, the algorithms discussed here, compute if two geometric figures intersect. However, the result is then used in a dynamic game. In the game world two objects will collide if their movement areas intersect.

== Circle-Sector with Disk ==
''By [[User:Avaniel|Avaniel]] 20:37, 27 February 2007 (CET)''

In order to determine if a circle-sector and a disk collide, we start with transforming the coordinates of the 2d space in such a way that the center of the circle-sector is located at the origin. The circle-sector can then be defined by a radius ''R'', a half-top-angle ''alpha'' and a placement angle ''beta'', as shown in diagram (1).

The disk can simply be defined by its center-point ''P'' and its radius ''RP'', where point ''P'' can be anywhere in the 2d space. See diagram (CSD-1) for an overview.

[[Image:Collision-circlesecor-disk-dimensions.png|frame|none|Diagram (CSD-1) - Overview of the Circle-Sector and Disk]]

In order to determine if the circle-sector and the circle intersect, the x-y plane is divided in 6 ''Voronoi'' like regions. The regions are based on the vertexes ''O-A'', ''O-B'' and the arc ''A-B''. They are shown in diagram (CSD-2).

[[Image:Collision-circlesecor-disk-voronoi.png|frame|none|Diagram (CSD-2) - The x-y plane divide in 6 'Voronoi' regions]]

For each region it is now determined what the pre-conditions for an overlap are, if ''P'' is in that region. If necessary, the pre-conditions for point ''P'' being in the region will be derived as well.

In the following text, a subscript ''x'' and ''y'' are used to indicate x and y coordinate of a point. If the coordinates considered are in a tranformed coordinate system, an extra indicator will be added. For example the x-coordinate of point A in the x1-y1 coordinate system is denoted as: Ax1

=== Region 1 ===

Region 1 is highlighted in diagram (CSD-3), it includes the interior of the Circle-sector. For region 1, the coordinates for point ''P'' are transformed to coordinate system 1 (shown in diagram (CSD-4)). [[:Image:Collision-circlesecor-disk-example1.png|An example of a region 1 collision is give here.]]

[[Image:Collision-circlesecor-disk-voronoi1.png|frame|none|Diagram (CSD-3) - 'Voronoi' region 1 highlighted]]
[[Image:Collision-circlesecor-disk-axis1.png|frame|none|Diagram (CSD-4) - Coordinate system 1]]

The coordinates for point ''P'' in coordinate system 1 are:

:Px1 = Px cos(beta-alpha) + Py sin(beta-alpha)

:Py1 = Py cos(beta-alpha) - Px sin(beta-alpha)

Using goniometric relations this can be simplified to:

:Px1 = Px {cos(alpha)cos(beta) + sin(alpha)sin(beta)} + Py {-sin(alpha)cos(beta) + cos(alpha)sin(beta)}

:Py1 = Py {cos(alpha)cos(beta) + sin(alpha)sin(beta)} - Px {-sin(alpha)cos(beta) + cos(alpha)sin(beta)}

Point ''P'' is inside region 1 if

:Px1 >= 0 , Py1 >= 0 and Py1 <= Px1 tan(2alpha) = Px1 {2sin(alpha)cos(alpha) / (cos2(alpha) - sin2(alpha))}

The Circle-sector and the disc then intersect if

:Px2 + Px2 <= (R + RP)2

=== Region 2 ===

Region 2 is highlighted in diagram (CSD-5). For this region no coordinate transformations are necessary. [[:Image:Collision-circlesecor-disk-example2.png|An example of a region 2 collision is give here.]]

[[Image:Collision-circlesecor-disk-voronoi2.png|frame|none|Diagram (CSD-5) - 'Voronoi' region 2 highlighted]]

If point ''P'' is inside region 2, the circle-sector and the disk can only intersect if point ''B'' is inside the circle.

:(Px - Bx)2 + (Py - By)2 <= RP2

The coordinates of point ''B'' are:

:Bx = R cos(alpha + beta) = R {cos(alpha)cos(beta) - sin(alpha)sin(beta)}

:By = R sin(alpha + beta) = R {sin(alpha)cos(beta) + cos(alpha)sin(beta)}

With the coordinates for ''B'' the condition can now be evaluated.

=== Region 3 ===

Region 3 is highlighted in diagram (CSD-6). For this region no coordinate transformations are necessary. [[:Image:Collision-circlesecor-disk-example3.png|An example of a region 3 collision is give here.]]

[[Image:Collision-circlesecor-disk-voronoi3.png|frame|none|Diagram (CSD-6) - 'Voronoi' region 3 highlighted]]

Analogous to region 2, the circle-sector and the disk can only intersect if point ''A'' is inside the disk. The condition for this is:

:(Px - Ax)2 + (Py - Ay)2 <= RP2

The coordinates of point ''A'' are:

:Ax = R cos(-alpha + beta) = R {cos(alpha)cos(beta) + sin(alpha)sin(beta)}

:Ay = R sin(-alpha + beta) = R {-sin(alpha)cos(beta) + cos(alpha)sin(beta)}

With the coordinates for ''A'' the condition can now be evaluated.

=== Region 4 ===

Region 4 is highlighted in diagram (CSD-7). For this region no coordinate transformations are necessary. [[:Image:Collision-circlesecor-disk-example4.png|An example of a region 4 collision is give here.]]

[[Image:Collision-circlesecor-disk-voronoi4.png|frame|none|Diagram (CSD-7) - 'Voronoi' region 4 highlighted]]

Analogous to regions 2 and 3, the circle-sector and the disk can only intersect if point ''O'' is inside the disk. The condition for this is:

:Px2 + Py2 <= RP2

=== Region 5 ===

Region 5 is highlighted in diagram (CSD-8). For region 5, the coordinates for point ''P'' are transformed to coordinate system 2 (shown in diagram (CSD-9)). [[:Image:Collision-circlesecor-disk-example5.png|An example of a region 5 collision is give here.]]

[[Image:Collision-circlesecor-disk-voronoi5.png|frame|none|Diagram (CSD-8) - 'Voronoi' region 5 highlighted]]
[[Image:Collision-circlesecor-disk-axis2.png|frame|none|Diagram (CSD-9) - Coordinate system 2]]

In the local coordinates the following conditions for ''P'' being in region 5, can be formulated:

:Px2 <= 0, Px2 >= -R and Py2 >= 0

The condition for the circle-sector and the disk intersecting is:

:Py2 <= RP

The coordinates for ''P'' in coordinate system 2 are given by:

:Px2 = Pxcos(alpha + beta + pi) + Pysin(alpha + beta + pi)

:Py2 = Pycos(alpha + beta + pi) - Pxsin(alpha + beta + pi)

Using the goniometric relations to handle the ''pi'' term first, the coordinates become:

:Px2 = -Pxcos(alpha + beta) + Pysin(alpha + beta )

:Py2 = -Pycos(alpha + beta) - Pxsin(alpha + beta )

Now using the goniometric relations to seperate ''alpha'' and ''beta'':

:Px2 = -Px{cos(alpha)cos(beta) - sin(alpha)sin(beta)} + Py{sin(alpha)cos(beta) + cos(alpha)sin(beta)}

:Py2 = -Py{cos(alpha)cos(beta) - sin(alpha)sin(beta)} - Px{sin(alpha)cos(beta) + cos(alpha)sin(beta)}

The conditions can now be evaluated.

=== Region 6 ===

Region 6 is highlighted in diagram (CSD-10). For region 6, the coordinates for point ''P'' are transformed to coordinate system 3 (shown in diagram (CSD-11)). [[:Image:Collision-circlesecor-disk-example6.png|An example of a region 6 collision is give here.]]

[[Image:Collision-circlesecor-disk-voronoi6.png|frame|none|Diagram (CSD-10) - 'Voronoi' region 6 highlighted]]
[[Image:Collision-circlesecor-disk-axis3.png|frame|none|Diagram (CSD-11) - Coordinate system 3]]

In the local coordinates the following conditions for ''P'' being in region 6, can be formulated:

:Px3 >= 0, Px3 <= R and Py3 >= 0

The condition for the circle-sector and the disk intersecting is:

:Py3 <= RP

The coordinates for ''P'' in coordinate system 3 are given by:

:Px3 = Pxcos(alpha + beta) + Pysin(alpha + beta)

:Py3 = Pycos(alpha + beta) - Pxsin(alpha + beta)

Now using the goniometric relations to seperate ''alpha'' and ''beta'':

:Px3 = Px{cos(alpha)cos(beta) - sin(alpha)sin(beta)} + Py{sin(alpha)cos(beta) + cos(alpha)sin(beta)}

:Py3 = Py{cos(alpha)cos(beta) - sin(alpha)sin(beta)} - Px{sin(alpha)cos(beta) + cos(alpha)sin(beta)}

The conditions can now be evaluated.

=== The Algorithm ===

The following values need to be given; the radius of the circle-sector ''R'', the half-top-angle ''alpha'', the placement angle ''beta'', the coordinates of the center of the circle-sector, the coordinates of the center of the disk ''P'' and the radius of the disk ''RP''.
* Subtract the coordinates of the center of the circle sector from the coordinates of point ''P''.
* Check for a region 4 intersection.
* Calculate sin(alpha), cos(alpha), sin(beta) and cos(beta) and store them in temporary variables.
* Calculate the coordinates of point ''A''.
* Check for a region 3 intersection.
* Calculate the coordinates of point ''B''.
* Check for a region 2 intersection.
* Calculate the coordinates of point ''P'' in coordinate system 2.
* Check for a region 5 intersection.
* Calculate the coordinates of point ''P'' in coordinate system 3.
* Check for a region 6 intersection.
* Calculate the coordinates of point ''P'' in coordinate system 1.
* Check for a region 1 intersection.

Any but the first three steps can be moved, if that is found to be more appropriate. The algorithm includes 4 calls to a trigonomic function and just 1 division.

In the current combat implementation sin(beta) and cos(beta) do not need to be calculated at runtime. ''Beta'' is determined by the direction the attacker is facing. There are only four possible values for ''beta''; 0, pi/2, pi and pi*3/2. Because the half-top-angle is a property of the weapon used, sin(alpha), cos(alpha) and tan(2alpha) could be computed on startup of the game-server and stored for use.

Archive:Collision determination

2007-02-27T04:43:46Z

Avaniel: Added the Circle-Sector with Disk collision

File:Collision-circlesecor-disk-voronoi6.png

2007-02-27T04:21:32Z

Avaniel:

File:Collision-circlesecor-disk-voronoi5.png

2007-02-27T04:21:14Z

Avaniel:

File:Collision-circlesecor-disk-voronoi4.png

2007-02-27T04:18:38Z

Avaniel:

File:Collision-circlesecor-disk-voronoi3.png

2007-02-27T04:18:20Z

Avaniel:

File:Collision-circlesecor-disk-voronoi2.png

2007-02-27T04:18:07Z

Avaniel:

File:Collision-circlesecor-disk-voronoi1.png

2007-02-27T04:17:49Z

Avaniel:

File:Collision-circlesecor-disk-voronoi.png

2007-02-27T04:17:30Z

Avaniel:

File:Collision-circlesecor-disk-example6.png

2007-02-27T04:17:16Z

Avaniel:

File:Collision-circlesecor-disk-example5.png

2007-02-27T04:16:46Z

Avaniel:

File:Collision-circlesecor-disk-example4.png

2007-02-27T04:16:31Z

Avaniel:

File:Collision-circlesecor-disk-example3.png

2007-02-27T04:16:17Z

Avaniel:

File:Collision-circlesecor-disk-example2.png

2007-02-27T04:15:51Z

Avaniel:

File:Collision-circlesecor-disk-example1.png

2007-02-27T04:15:06Z

Avaniel:

File:Collision-circlesecor-disk-dimensions.png

2007-02-27T04:14:38Z

Avaniel:

File:Collision-circlesecor-disk-axis3.png

2007-02-27T04:14:18Z

Avaniel:

File:Collision-circlesecor-disk-axis2.png

2007-02-27T04:14:03Z

Avaniel:

File:Collision-circlesecor-disk-axis1.png

2007-02-27T04:13:47Z

Avaniel:

Archive:Collision determination

2007-02-27T02:34:57Z

Avaniel: Just saving changes

Archive:Collision determination

2007-02-27T01:32:17Z

Avaniel: Just saving changes

Archive:Collision determination

2007-02-26T23:04:12Z

Avaniel: Just saving changes

User:Avaniel

2007-02-26T19:17:04Z

Avaniel:

Real name: Rogier Polak

Avaniel on IRC, the forum and (offcoarse) this wiki.

===Pages created by me===
(just an easy way for me to keep track of them all :-) )
*[[Collision determination]]

Archive talk:Skill system 2

2007-02-26T00:31:14Z

Avaniel: another set of comments

Eeiya, I think this is a good proposal, however I offer some minor suggestions. As others have stated, we should NOT just give the EXP/items to the first person to hit it, because that would encourage players attacking every monster on a map. Instead, it should either be time, or distance based, possibly a mixture of both. For instance, move 15 tiles away from the monster and it returns to "everybody mode." Or, after you have not attacked for a certain amount of time, it will once again return to "everybody mode." We should NOT have it party based (meaning the ENTIRE party has to move away from the monster). Why? Because then there would be large parties dedicated to attacking monsters, and as long as at least one person in the party is close enough to the monster(s), everybody gets EXP. No, that won't work at all. Instead, if even ONE person in the party leaves the area, I think the monster should go back to being a free kill. BUT! Let's say that one player in the party left to go buy an item, but the rest of the party (let's say 4 people) stayed behind. The instant the player leaves, the monster goes back into free mode. However, since the rest of the party is still around, and still attacking it, the monster only stays in free mode for less than a second. Thus, the balance is maintained. I also think that only those within a certain radius of the monster should get EXP (in other words, if you go AFK and don't move, you shouldn't be able to leech off your party which is three maps away.) So yeah, just some minor suggestions, but I approve of it overall.
:::::::::::::::::::::::::::::[[User:Pauan|Pauan]] 04:03, 1 January 2007 (CET)

=== @Direct Combat Skills - 1 ===
Why not base the exp gained on the work done directly?
For fighters this would mean exp is calculated based on the hp loss of the enemy after each of the fighter's hits. Healers would gain exp which based on the amount of hp gained by the wounded. Combined with the ''challenge rating'', this could balance out group attacks quite nicely. Healers would be able to heal more if a group is damaged more and so profit from attacking stronger mobs as much as the rest of the team.
In this way the game server doesn't need to store a play-by-play of the fight to calculate exp. It could just be stored in a buffer, ready for use when the fight ends (allthough I would not be opposed to levelling during a fight).
This would work in the following manner:
* Player attacks with short sword equiped
* Damage to mob is calculated
* Exp for that player is calculated based on the damage done
* Exp is added to Player's sword-skill-exp-buffer (or something like that)
* Rinse, repeat
* Mob dies, exp is added OR Player dies, bye bye exp (if a buffer is used)
[[User:Avaniel|Avaniel]] 12:09, 16 February 2007 (CET)

::This concept was in fact my first idea. But there were a lot of problems I found when I thought about it thoroughly.

::'''1st:''' When you calculate exp based on enemies hp loss, what happens when the mob is healed? Players could heal mobs intentionally again and again to harvest tons of exp.
:::''Actually, I would consider this a good tactic. We just have to calculate the numbers so that a player couldn't do it by himself after a certain level. Frankly, I would encourage this form of cooperation.'' [[User:Avaniel|Avaniel]] 15:51, 16 February 2007 (CET)
::::I just see here a lot of potential for abuse. It would also encourage irrational behavior. Monsters are for getting defeated. Players should be encouraged to fight them as efficient as possible. --[[User:Crush|Crush]] 00:49, 26 February 2007 (CET)
:::::''Think of it as a cat playing with a mouse, or a lioness bringing small live prey to her cubs, to teach them hunting. As I said, it should only be a viable option for weak players.''--[[User:Avaniel|Avaniel]] 01:31, 26 February 2007 (CET)

::'''2nd:''' i) To calculate the exp of healers based on the challenge rating of the mob is also very complicate. ii) What challenge rating should apply when a fighter is attacked by multiple enemies with different challenge ratings? iii) And what is when the combat is over and the healer heals? Which attackers challenge rating does apply then? iv) And what about support spells? How should these be awarded?
:::''i,iii) I wouldn't apply a ''challenge rating'' to healing spells. Just the hp gained should be efficient. If you are the healer in a group of tanks, you won't get very far if they insist on fighting bunnies.''
:::''ii) If a fighter hits three enemies with one slash of his sword, he'll recieve exp based on the individual enemies he hits, and their respective ''challenge ratings''.''
:::''iv) For support spells we'll find a solution eventually (maybe based on magic defense of the mob).'' [[User:Avaniel|Avaniel]] 15:51, 16 February 2007 (CET)

::'''3rd:''' Exp based on damage done is favoring offensive characters (damage dealers) while defensive characters (tanks) are very unprivileged and receive almost no exp although they are doing a very important job, too. Of course it would be possible to give exp for received damage. But this would encourage people to get hurt as much as possible and not avoiding damage as you would expect them. This would result in very unrealistic behavior.
:::''We could base this on natural (sans magic) healing. I'll just add a quote:'' '''What doesn't kill me, makes me stronger''' ''But at this point I don't see much difference between ''tanks'' and ''fighters''. '' [[User:Avaniel|Avaniel]] 15:51, 16 February 2007 (CET)
::::There is a reason why I don't want any exp gain for losing hit points. People will stand around and let mobs attack them without striking back to build up hp. Maybe even while being afk. I want to reward the players for fighting efficient and not for letting the mobs beat them up. --[[User:Crush|Crush]] 00:49, 26 February 2007 (CET)
:::::''Or we could let 'defense' be an actual skill, which gaines exp if the character blocks an attack (exp based on mob lvl). We would then need to implement a 'block' action, which may only be used with certain weapons. For example you could block a sword attack with another sword but it would be much more effective with a shield. Vitality could then be based on the total exp gained on (allmost) all skills.''--[[User:Avaniel|Avaniel]] 01:31, 26 February 2007 (CET)

::'''4th:''' The reason why I decided to distribute exp evenly between the skills is that it allows the player to train new skills while still doing the most work with the main skill. This doesn't force the player to use weak skills over and over again while they have much stronger skills. Instead it allows them to still be effective and advance in the game while the training of a new skill is a secondary task.
:::''If you'd rather be an archer after 4 weeks of being a warrior, you'd beter do the work like the rest of the n00bs :) On a more serious note, I think it will promote character diversity, and multiple characters per player.'' [[User:Avaniel|Avaniel]] 15:51, 16 February 2007 (CET)

::I hope you see now why i decided to do things like i did. --[[User:Crush|Crush]] 14:04, 16 February 2007 (CET)
:::''Yes and no :)'' [[User:Avaniel|Avaniel]] 15:51, 16 February 2007 (CET)

=== @"Forgetting" of unused skills ===
As a side note, I wouldn't decrease a random skill, I would much prefer it if a set of incompatible skills are defined. For instance if a player learns a new spell or gains a level in a magic related skill, weapon skills decrease. This would work in the following scenario: lets define that weapon skills and magic skills are incompatible; A player could be training his sword skill, gain a level in that, after which his magic skill decreases. Eventually his magic skill will decrease past the minimum level required to use that healing spell he favors. He would then need to make a decision if he really wants to train magic to regain the healing spell. Only to loose the spell once more after the next increase of his weapon skill.

The (gained exp / lost exp) quotient would have to be calculated to allow only for low level multi-purpose-characters. I would combine this with some exponential exp requirements, which depend on total exp instead of current skill level. This would mean that you could actually ruin a character completely. When the characters exp requirements for a next level of skill are very high and the skill level itself is very low.

In this way a set of compatible skills could also be defined, which will not decrease. An example which comes to mind is smithing and sword fighting.

[[User:Avaniel|Avaniel]] 12:09, 16 February 2007 (CET)

:i like the idea of the counterbalancing of lost skills, as magic increases then weapon skills decrease ... i think there should be other ones though to, like if you chose to start using an axe as opposed to a sword, your sword skills decrease as your axe skills increase.
:[[User:zick|zick]] 12:09, 16 February 2007 (CET)

=== @New enemy spawning/exp generating proposal === by [[User:zick|zick]]

i think this proposal would work best with a SoM/Zelda-ish battle engine, as opposed to the one that is currently implemented ...

everytime an enemy is respawned, the server determines its HP by the following equation (subject to change, shown in psuedocode):

((enemyBaseHP +/- randomNumZeroToFive) * randLVL) +/- randNumZeroToEleven)

description of this equation:
"enemyBaseHP" is a static value (doesn't change) defined in an enemies config file
"randLVL" is a dynamic value generated by using the equation (avgLvlOfPlayersOnMap +/- randNumZeroToFive) and is the level of the enemy, which determines how strong the enemy is, its drop tables, how much experience it will give, etc.
"randomNumZeroToFive" and "randNumZeroToEleven" are values generated from a dice-rolling function (6 & 12-sided respectively)
the "+/-" operator randomly chooses whether to add or subtract values

in other words, every enemy levels in the same manner as players do, gaining abilities and getting stronger with every level. You may even find level 99 maggots! Also two enemies with the same levels may actually have differing amounts of HP and give out differing amounts of exp.

: Ok, I like the variation principle, but only within a well defined boundary. I dislike the idea of having monster strength based on average player strength. I think exploration should be promoted and that the starting area's really shouldn't have anything of interest for higher level players.[[User:Avaniel|Avaniel]] 21:40, 17 February 2007 (CET)

:: as far as exploration there should be some other reasons to explore than just gaining experience, such as quests. maybe even since you want add more races at some point, you always start a new character as a human, but when you make your way from the human towns to say the fish-peoples town, you gain the ability to start a new character as a fish-person (which opens new weapons (shops sell items based on sex and race), skills, and places you can go (humans can't travel everywhere that say a fish-person can and vice versa)) --[[User:zick|zick]] 16:09, 17 February 2007 (CET)

also something interesting that i want to add is that this makes it easier to create enemies ... just create a base species and allow it level on it own, no more trying to come up with different names for red slimes and green slimes (what happens when you run out of colors, hmmm!) ever notice how old school rpgs like ff on snes, would use the same spriteset for all of its imps and just call them imps or imp generals or imp captain, what happens when you run out of ranks. plus then i think it makes the enemies be more like the creatures of this world you've created. if we were to make a rpg of our planet, and cougars were one of the enemies, we wouldn't have blue cougars and red cougars, we'd just have cougars ... but not every cougar looks quite the same, so why not allow the enemy spriteset include variations of an enemy (check out the following image: [http://www.bottledtalent.com/images/productspuddlebunnies.gif bunnies] and check out all the different bunnies some are white some are spotted some are brown, etc.)

: I believe that, the green/red/white/yellow slimes are just an easy way to get started, the endgoal will most definetly be a diverse world, with different species of mobs. Basically, this stuff is waiting on well defined view of the game world, after which concept artists can get started developing a whole range of mobs. The system described here just makes it easier to be lazy.[[User:Avaniel|Avaniel]] 21:40, 17 February 2007 (CET)

while talking about enemies, the EXP system should be mentioned and explained. First off every enemy has a base EXP value, stored in its config file. This value has the following equation applied to it:

((enemyBaseEXP +/- randomNumZeroToFive) * enemyLVL) +/- randNumZeroToEleven)

this value is the total amount of distrubitable EXP that the enemy can give. each player that contributed to the death of said enemy (who is still on the current map when death occurs) is awarded a percentage (rounded to the nearest whole number) of these EXP based on the overall percentage damage that they did. also there are two bonuses that can be applied to the EXP you are awarded. the first is called the "kill bonus" and is granted to the person who actually kills the enemy, this encourages kill stealing (part of the friendly-fire free for all system that i would like explain later). this bonus is equivalent to the "baseEXP" value. the second bonus is an "overkill bonus" and is granted when your final killing hit is more than the remaining HP of the enemy (the system knows how much damage you have to do to kill the enemy and usually won't overkill by much, unless you kill with a critical hit, a limit break, or a special move) and is generated by dividing the amount of damage over the remaining HP by the baseEXP (and of course rounding to a whole number)

:So, basically you agree with the proposal I posted above. I like the overkill idea, though I'm not sure of it's usefulness and I'm unsure if this would work against the effort to steer higher level players to higher level areas.[[User:Avaniel|Avaniel]] 21:40, 17 February 2007 (CET)

:: see above on "steering" ... the bonuses are only gonna be a couple of extra exp, nothing drastic. --[[User:zick|zick]] 16:10, 17 February 2007 (CET)

even lowly maggots can be powerful enemies, if someone with a level 99 enters a map with a lot of other noobs and throws off the curve. enemies level with players and each enemy has different attacks at different levels (as well as strength and defense). enemies dont gain level until respawn. enemies generate exp, gold and have different drop tables based on their level also.

:''even lowly maggots can be powerful enemies...'' No, just no...[[User:Avaniel|Avaniel]] 21:40, 17 February 2007 (CET)

:: okay i think you need to keep in mind that a maggot will only have a base exp of 1 or 2, so no matter how you calculate it your still not getting a lot of exp as compared to a creature with say a base exp of 10 or 100, that'll be when you'll start getting major exp. and i'm guessing there will be a more grinder approach to how much exp you will need to gain to reach the next level, like in games like "maple story" ... --[[User:zick|zick]] 16:11, 17 February 2007 (CET)

::Haha, reminds me of the [http://prblog.typepad.com/photos/uncategorized/killer20rabbit_1.jpg killer rabbit]. Anyway I don't think it's a good idea to scale monster toughness depending on the level of the players on the map. Instead I think we should use a rather [http://forums.themanaworld.org/viewtopic.php?p=16372#16372 flat leveling curve] to make sure a good amount of monsters are interesting to fight and if maggots are no longer your taste, it's simply time to move on. --[[User:BjÃ¸rn|BjÃ¸rn]] 14:21, 25 February 2007 (CET)

Archive talk:Skill system 2

2007-02-17T20:40:11Z

Avaniel: comments @zick, formatting for comments @Crush

Eeiya, I think this is a good proposal, however I offer some minor suggestions. As others have stated, we should NOT just give the EXP/items to the first person to hit it, because that would encourage players attacking every monster on a map. Instead, it should either be time, or distance based, possibly a mixture of both. For instance, move 15 tiles away from the monster and it returns to "everybody mode." Or, after you have not attacked for a certain amount of time, it will once again return to "everybody mode." We should NOT have it party based (meaning the ENTIRE party has to move away from the monster). Why? Because then there would be large parties dedicated to attacking monsters, and as long as at least one person in the party is close enough to the monster(s), everybody gets EXP. No, that won't work at all. Instead, if even ONE person in the party leaves the area, I think the monster should go back to being a free kill. BUT! Let's say that one player in the party left to go buy an item, but the rest of the party (let's say 4 people) stayed behind. The instant the player leaves, the monster goes back into free mode. However, since the rest of the party is still around, and still attacking it, the monster only stays in free mode for less than a second. Thus, the balance is maintained. I also think that only those within a certain radius of the monster should get EXP (in other words, if you go AFK and don't move, you shouldn't be able to leech off your party which is three maps away.) So yeah, just some minor suggestions, but I approve of it overall.
:::::::::::::::::::::::::::::[[User:Pauan|Pauan]] 04:03, 1 January 2007 (CET)

=== @Direct Combat Skills - 1 ===
Why not base the exp gained on the work done directly?
For fighters this would mean exp is calculated based on the hp loss of the enemy after each of the fighter's hits. Healers would gain exp which based on the amount of hp gained by the wounded. Combined with the ''challenge rating'', this could balance out group attacks quite nicely. Healers would be able to heal more if a group is damaged more and so profit from attacking stronger mobs as much as the rest of the team.
In this way the game server doesn't need to store a play-by-play of the fight to calculate exp. It could just be stored in a buffer, ready for use when the fight ends (allthough I would not be opposed to levelling during a fight).
This would work in the following manner:
* Player attacks with short sword equiped
* Damage to mob is calculated
* Exp for that player is calculated based on the damage done
* Exp is added to Player's sword-skill-exp-buffer (or something like that)
* Rinse, repeat
* Mob dies, exp is added OR Player dies, bye bye exp (if a buffer is used)
[[User:Avaniel|Avaniel]] 12:09, 16 February 2007 (CET)

::This concept was in fact my first idea. But there were a lot of problems I found when I thought about it thoroughly.

::'''1st:''' When you calculate exp based on enemies hp loss, what happens when the mob is healed? Players could heal mobs intentionally again and again to harvest tons of exp.
:::''Actually, I would consider this a good tactic. We just have to calculate the numbers so that a player couldn't do it by himself after a certain level. Frankly, I would encourage this form of cooperation.'' [[User:Avaniel|Avaniel]] 15:51, 16 February 2007 (CET)
::'''2nd:''' i) To calculate the exp of healers based on the challenge rating of the mob is also very complicate. ii) What challenge rating should apply when a fighter is attacked by multiple enemies with different challenge ratings? iii) And what is when the combat is over and the healer heals? Which attackers challenge rating does apply then? iv) And what about support spells? How should these be awarded?
:::''i,iii) I wouldn't apply a ''challenge rating'' to healing spells. Just the hp gained should be efficient. If you are the healer in a group of tanks, you won't get very far if they insist on fighting bunnies.''
:::''ii) If a fighter hits three enemies with one slash of his sword, he'll recieve exp based on the individual enemies he hits, and their respective ''challenge ratings''.''
:::''iv) For support spells we'll find a solution eventually (maybe based on magic defense of the mob).'' [[User:Avaniel|Avaniel]] 15:51, 16 February 2007 (CET)

::'''3rd:''' Exp based on damage done is favoring offensive characters (damage dealers) while defensive characters (tanks) are very unprivileged and receive almost no exp although they are doing a very important job, too. Of course it would be possible to give exp for received damage. But this would encourage people to get hurt as much as possible and not avoiding damage as you would expect them. This would result in very unrealistic behavior.
:::''We could base this on natural (sans magic) healing. I'll just add a quote:'' '''What doesn't kill me, makes me stronger''' ''But at this point I don't see much difference between ''tanks'' and ''fighters''. '' [[User:Avaniel|Avaniel]] 15:51, 16 February 2007 (CET)

::'''4th:''' The reason why I decided to distribute exp evenly between the skills is that it allows the player to train new skills while still doing the most work with the main skill. This doesn't force the player to use weak skills over and over again while they have much stronger skills. Instead it allows them to still be effective and advance in the game while the training of a new skill is a secondary task.
:::''If you'd rather be an archer after 4 weeks of being a warrior, you'd beter do the work like the rest of the n00bs :) On a more serious note, I think it will promote character diversity, and multiple characters per player.'' [[User:Avaniel|Avaniel]] 15:51, 16 February 2007 (CET)

::I hope you see now why i decided to do things like i did. --[[User:Crush|Crush]] 14:04, 16 February 2007 (CET)
:::''Yes and no :)'' [[User:Avaniel|Avaniel]] 15:51, 16 February 2007 (CET)

=== @"Forgetting" of unused skills ===
As a side note, I wouldn't decrease a random skill, I would much prefer it if a set of incompatible skills are defined. For instance if a player learns a new spell or gains a level in a magic related skill, weapon skills decrease. This would work in the following scenario: lets define that weapon skills and magic skills are incompatible; A player could be training his sword skill, gain a level in that, after which his magic skill decreases. Eventually his magic skill will decrease past the minimum level required to use that healing spell he favors. He would then need to make a decision if he really wants to train magic to regain the healing spell. Only to loose the spell once more after the next increase of his weapon skill.

The (gained exp / lost exp) quotient would have to be calculated to allow only for low level multi-purpose-characters. I would combine this with some exponential exp requirements, which depend on total exp instead of current skill level. This would mean that you could actually ruin a character completely. When the characters exp requirements for a next level of skill are very high and the skill level itself is very low.

In this way a set of compatible skills could also be defined, which will not decrease. An example which comes to mind is smithing and sword fighting.

[[User:Avaniel|Avaniel]] 12:09, 16 February 2007 (CET)

:i like the idea of the counterbalancing of lost skills, as magic increases then weapon skills decrease ... i think there should be other ones though to, like if you chose to start using an axe as opposed to a sword, your sword skills decrease as your axe skills increase.
:[[User:zick|zick]] 12:09, 16 February 2007 (CET)

=== @New enemy spawning/exp generating proposal ===

i think this proposal would work best with a SoM/Zelda-ish battle engine, as opposed to the one that is currently implemented ...

everytime an enemy is respawned, the server determines its HP by the following equation (subject to change, shown in psuedocode):

((enemyBaseHP +/- randomNumZeroToFive) * randLVL) +/- randNumZeroToEleven)

description of this equation:
"enemyBaseHP" is a static value (doesn't change) defined in an enemies config file
"randLVL" is a dynamic value generated by using the equation (avgLvlOfPlayersOnMap +/- randNumZeroToFive) and is the level of the enemy, which determines how strong the enemy is, its drop tables, how much experience it will give, etc.
"randomNumZeroToFive" and "randNumZeroToEleven" are values generated from a dice-rolling function (6 & 12-sided respectively)
the "+/-" operator randomly chooses whether to add or subtract values

in other words, every enemy levels in the same manner as players do, gaining abilities and getting stronger with every level. You may even find level 99 maggots! Also two enemies with the same levels may actually have differing amounts of HP and give out differing amounts of exp.
: Ok, I like the variation principle, but only within a well defined boundry. I dislike the idea of having monster strength based on average player strength. I think exploration should be promoted and that the starting area's really shouldn't have anything of interest for higher level players.[[User:Avaniel|Avaniel]] 21:40, 17 February 2007 (CET)
also something interesting that i want to add is that this makes it easier to create enemies ... just create a base species and allow it level on it own, no more trying to come up with different names for red slimes and green slimes (what happens when you run out of colors, hmmm!) ever notice how old school rpgs like ff on snes, would use the same spriteset for all of its imps and just call them imps or imp generals or imp captain, what happens when you run out of ranks. plus then i think it makes the enemies be more like the creatures of this world you've created. if we were to make a rpg of our planet, and cougars were one of the enemies, we wouldn't have blue cougars and red cougars, we'd just have cougars ... but not every cougar looks quite the same, so why not allow the enemy spriteset include variations of an enemy (check out the following image: [http://www.bottledtalent.com/images/productspuddlebunnies.gif link bunnies] and check out all the different bunnies some are white some are spotted some are brown, etc.)
:I believe that, the green/red/white/yellow slimes are just an easy way to get started, the endgoal will most definetly be a diverse world, with different species of mobs. Basically, this stuff is waiting on well defined view of the game world, after which concept artists can get started develloping a whole range of mobs. The system described here just makes it easier to be lazy.[[User:Avaniel|Avaniel]] 21:40, 17 February 2007 (CET)

while talking about enemies, the EXP system should be mentioned and explained. First off every enemy has a base EXP value, stored in its config file. This value has the following equation applied to it:

((enemyBaseEXP +/- randomNumZeroToFive) * enemyLVL) +/- randNumZeroToEleven)

this value is the total amount of distrubitable EXP that the enemy can give. each player that contributed to the death of said enemy (who is still on the current map when death occurs) is awarded a percentage (rounded to the nearest whole number) of these EXP based on the overall percentage damage that they did. also there are two bonuses that can be applied to the EXP you are awarded. the first is called the "kill bonus" and is granted to the person who actually kills the enemy, this encourages kill stealing (part of the friendly-fire free for all system that i would like explain later). this bonus is equivalent to the "baseEXP" value. the second bonus is an "overkill bonus" and is granted when your final killing hit is more than the remaining HP of the enemy (the system knows how much damage you have to do to kill the enemy and usually won't overkill by much, unless you kill with a critical hit, a limit break, or a special move) and is generated by dividing the amount of damage over the remaining HP by the baseEXP (and of course rounding to a whole number)
:So, basically you agree with the proposal I posted above. I like the overkill idea, though I'm not sure of it's usefullness and I'm unsure if this would work against the effort to stear higher level players to higher level areas.[[User:Avaniel|Avaniel]] 21:40, 17 February 2007 (CET)

even lowly maggots can be powerful enemies, if someone with a level 99 enters a map with a lot of other noobs and throws off the curve. enemies level with players and each enemy has different attacks at different levels (as well as strength and defense). enemies dont gain level until respawn. enemies generate exp, gold and have different drop tables based on their level also.
:''even lowly maggots can be powerful enemies...'' No, just no...[[User:Avaniel|Avaniel]] 21:40, 17 February 2007 (CET)
[[User:zick|zick]] 12:09, 16 February 2007 (CET)

Archive talk:Skill system 2

2007-02-16T14:51:47Z

Avaniel: comments

Archive talk:Skill system 2

2007-02-16T11:09:27Z

Avaniel: Some comments

Archive talk:Skill system 2

2007-02-16T11:07:21Z

Avaniel:

User:Avaniel

2007-02-13T00:18:44Z

Avaniel:

Real name: Rogier Polak

Avaniel on IRC, the forum and (offcoarse) this wiki.

User:Avaniel

2007-02-13T00:18:29Z

Avaniel: nothing much ...

Real name: Rogier Polak
Avaniel on IRC, the forum and (offcoarse) this wiki.

User talk:Avaniel

2007-02-13T00:13:57Z

Avaniel: Some minor clarification

I have been working / thinking on how an inventory system might be implemented in the new server. While doing this, I came across some problems with naming conventions. To resolve these issues I would like to propose the following:

=== Renaming stats to attributes ===

The current use of these in the code are:
* Rawstats, defined during character creation and increased after level up. The rawstats are; strength, agility, vitality, intelligence, dexterity and luck.
* Statistics or calculated stats. These are calclated from the rawstats. The statistics are; heat, attack, defence, magic, accuracy and speed.

'''My problem with the current use of stats or statistics'''

First of lets start with the word itself, [http://www.thefreedictionary.com/statistics The Free Dictionary] defines statistics as:
# (used with a sing. verb) The mathematics of the collection, organization, and interpretation of numerical data, especially the analysis of population characteristics by inference from sampling.
# (used with a pl. verb) Numerical data.

So basically statistics would mean ''numerical data'', I expect there will be a lot of that in the code base, as it nears completion. Especially ''statistics'' spring to mind, as in number_of_attacks, monsters_killed or beers_drunken to name a few. My point being: it is not precise enough.

Secondly, my work on equipment and attribute modifying items, has let me to conclude that four lists of attributes are needed to describe the characteristics of a single being:
* Base attributes - the character without equipment or items.
* Base modifiers - additions to or subtractions from the base, both time based and permanent (for example ''Gloin's Axe Of Glory And Increased Strength'' or ''Wicked Potion Of Double Intelligence For Two Minutes'').
* Derived attribute modifiers - the bonuses or maluses to the derived (calculated) attributes of the character. Originating from equipment and items (for example; simple weaponry, which increases attack; or quid-pro-quo items like an ''Amulet Of The Barbarian'' increasing attack and speed at the cost of defence an accuracy).
* Compound attributes - a list of all base and derived attributes after the modifiers have been applied.

And, quite frankly, I ran out of adjectives which could be used with statistics in a meaningfull way.

For additional information on naming conventions in RPG games I would like to direct you to [http://en.wikipedia.org/wiki/Attribute_(role-playing_games) A comprehensive Wikipedia page on the subject].

=== Renaming Player to Character on the account server ===

In my view ''Player'' should allways be the interpretation or representation of the physical human who's playing the game.
On the account server that would be the person owning an account, which has several characters. On the game-server that would be the playable character.
The main reason for my renaming proposal is the current PlayerData class. The game server's Player class inherits from both Being and PlayerData, these classes do not fit together. The base attributes of a being, for example, are reimplemented in the PlayerData class to be available to the account server. The implementation of inventory is simplistic, as it should be on the account server, which would cause multiple calls to ItemManager for every action of a Player on the game server. Concluding, the Player class needs specialisation which PlayerData can not provide.

I would therefore propose moving PlayerData to the account-server directory and renaming it to CharacterData, after which it can be modified to fit the specific needs of the account server. The Player class, or it's members, can then be modified to fit better and perform faster on the game server. I would propose (based on BjÃ¸rn's suggestion) renaming the Player class to Character for the sake of consistency.

I would welcome your thought and comments on both subjects. As a side note, I've completed the account server side of the Player to Character renaming in my working copy allready. [[User:Avaniel|Avaniel]] 19:06, 12 February 2007 (CET)

User talk:Avaniel

2007-02-12T18:06:15Z

Avaniel: Proposal for renaming stats->attributes and (on the account server) player->character

I have been working / thinking on how an inventory system might be implemented in the new server. While doing this, I came across some problems with naming conventions. To resolve these issues I would like to propose the following:

=== Renaming stats to attributes ===

The current use of these in the code are:
* Rawstats, defined during character creation and increased after level up. The rawstats are; strength, agility, vitality, intelligence, dexterity and luck.
* Statistics or calculated stats. These are calclated from the rawstats. The statistics are; heat, attack, defence, magic, accuracy and speed.

'''My problem with the current use of stats or statistics'''

First of lets start with the word itself, [http://www.thefreedictionary.com/statistics The Free Dictionary] defines statistics as:
# (used with a sing. verb) The mathematics of the collection, organization, and interpretation of numerical data, especially the analysis of population characteristics by inference from sampling.
# (used with a pl. verb) Numerical data.

So basically statistics would mean ''numerical data'', I expect there will be a lot of that in the code base, as it nears completion. Especially ''statistics'' spring to mind, as in number_of_attacks, monsters_killed or beers_drunken to name a few. My point being: it is not precise enough.

Secondly, my work on equipment and attribute modifying items, has let me to conclude that four lists of attributes are needed to describe the characteristics of a single being:
* Base attributes - the character without equipment or items.
* Base modifiers - additions to or subtractions from the base, both time based and permanent (for example ''Gloin's Axe Of Glory And Increased Strength'' or ''Wicked Potion Of Double Intelligence For Two Minutes'').
* Derived attribute modifiers - the bonuses or maluses to the derived (calculated) attributes of the character. Originating from equipment and items (for example; simple weaponry, which increases attack; or quid-pro-quo items like an ''Amulet Of The Barbarian'' increasing attack and speed at the cost of defence an accuracy).
* Compound attributes - a list of all base and derived attributes after the modifiers have been applied.

And, quite frankly, I ran out of adjectives which could be used with statistics in a meaningfull way.

For additional information on naming conventions in RPG games I would like to direct you to [http://en.wikipedia.org/wiki/Attribute_(role-playing_games) A comprehensive Wikipedia page on the subject].

=== Renaming Player to Character on the account server ===

In my view ''Player'' should allways be the interpretation or representation of the physical human who's playing the game.
On the account server that would be the person owning an account, which has several characters. On the game-server that would be the playable character.
The main reason for my renaming proposal is the current PlayerData class. The game server's Player class inherits from both Being and PlayerData, these classes do not fit together. The base attributes of a being, for example, are reimplemented in the PlayerData class to be available to the account server. The implementation of inventory is simplistic, as it should be on the account server, which would cause multiple calls to ItemManager for every action of a Player on the game server. Concluding, the Player class needs specialisation which PlayerData can not provide. I would therefore propose copying PlayerData to the account server and renaming it to CharacterData, after which it can be modified to fit the specific needs of the account server. The Player class, or it's members, can then be modified to fit better and perform faster on the game server.

I would welcome your thought and comments on both subjects. As a side note, I've completed the account server side of the Player to Character renaming in my working copy allready. [[User:Avaniel|Avaniel]] 19:06, 12 February 2007 (CET)

Servers

2007-01-19T18:58:50Z

Avaniel: Changed server address to server.themanaworld.org

Please add tmw servers here. To play on them you have to open the config.xml file in your The Mana World Directory and search for the line

<option name="host" value="animesites.de"/>

Replace animesites.de with the hostname of the server you want to play on. Save the file, start TMW and it should connect you to the server. Note that every server uses its own Database. So you have to register a new account on every server. For security reasons you should not use the same username+password combination on two different servers.

:''Uhm, I think it's much easier just to type the server into the server textfield of the login dialog.'' --[[User:BjÃ¸rn|BjÃ¸rn]] 15:09, 27 February 2006 (CET)

:''Yes, it would be, when it wouldn't be totally buggy'' --[[User:Crush|Crush]] 23:03, 3 March 2006 (CET)

== Official Server ==

*Hostname: server.themanaworld.org
*Homepage: http://themanaworld.org
*Admin Contact: platyna at platinum.linux.pl

The official public test server of the Mana World project.

== Matts Test Server ==

*Hostname: hackgrid.ath.cx
*Homepage:
*Admin Contact:

The testserver of Matt, isn't always running.

== Bears Server ==

*Hostname: bear8.no-ip.org
*Homepage:
*Admin Contact:

== Platyna's Test Server ==
*Hostname: platinum.linux.pl
*Homepage:
*Admin Contact: platyna at platinum.linux.pl

FAQ

2007-01-19T18:52:24Z

Avaniel: /* When I try to login using the account that usually works, I get following message: Unable to connect to Login Server */

This is the FAQ for The Mana World. If you have a question, search for it in the Table of Contents. If you cannot find it, please post it on the forums, previously having searched for similar threads.

== Support questions ==
=== Does TMW have an IRC channel? ===
Yes it does.
* '''Server''': ''irc.freenode.net''
* '''Channel''': ''#themanaworld''
For a direct link: [irc://irc.freenode.net:6667/themanaworld]

=== Is my platform supported? ===
Look in [[Ports]].

=== Where can I look for help? ===
The IRC channel is a good start for solving small problems or doubts. Is usually habited by sane people, ignore everything m[a]tt says. As most people are from Europe (GMT or GMT+1 timezones) you will have more success if you try to contact at a reasonable hour in the day.

For more complex problems (compilations problems, crashes...) is advisable to use the forums as it is a non-volatile way of storing your claims. If you do in IRC some people won't have the oportunity to read them and your oportunity of getting further help will be narrowed. At the same time posting long logs or reports on IRC is not polite.

=== When is this game updated? ===
This has several aswers. The general politics in the dev team is "When it's doneâ„¢". Expect new version to be released in a span of one to two months since the previous release.

Nevertheless, you can use SVN to fetch latest code from sourceforge's repository. That code usually has all of the bleeding-edge additions but it could also be broken and don't even compile. Althought usually it does work, is a fair warning to be done. Anyways, it doesn't imply any risk of breaking your system in any way or form.

A third update way are the automated updates. As the name says, the user doesn't have to do anything, just start the game and in the log-in screen the updates will be fetch. As a general rule it is advisable to fetch them but if you don't want to or you feel that such updates are conflicting with the (more up-to-date) data taken from SVN (like display of old maps or graphics when you're sure the ones in SVN has been already updated), you can parse the '-u' switch to the tmw executable. This will avoid any automatic update.

=== I want to help, how do I join the team? ===
First, if you are a developer read this: [[Joining the project]].

If you're a graphic artist is suggested you read the [[Guidelines]] and take a look at the '''Graphics''' section on the front page.

If you want to help coding some scripts or managing server content, read [http://forums.themanaworld.org/viewforum.php?f=9 this].

If you just want to suggest something, use the '''Suggestions/Feedback''' subforum.

=== I don't want to be rude but... I'm fed up with maggots!!! ===
One thing you'll notice if you invest hours every day into the game, is that you'll eventually run out of things to do. While we're constantly adding to the game with maps, quests, NPCs... we really can't keep up with demand.

If you'd like to help this though, just join the project! It's as simple as that; you play the games, not us, so we don't know what you'd like to see and your opinion matters to us.

== Game-related questions ==
=== I'm a bit lost... How do I start? ===
There is an article specifically about this: [[Getting started]].

=== What are the keyboard shortcuts in The Mana World? ===
See the README file that came with your install for the list or press F1 while in game to see the help. The keys are currently non-configurable.

=== How do skills work? ===
* Strength: Makes you hit harder with melee weapons.
* Agility: Makes your enemies hit you less often and increases your attack speed.
* Vitality: Increases your maximum HP and your HP recovery rate. Decreases the amount of damage you receive from hits.
* Intelligence: Increases your maximum MP and your MP recovery rate. this stat isn't that important yet because there isn't a way to spend your MP yet.
* Dexterity: Makes you hit harder with bows. Makes you miss your enemies less often with both melee and bow weapons.
* Luck: Makes you do critical hits from time to time.
For further reading see [[Stats]].

=== What are MP for? ===
MP stands for "Magic Points", thus are points used in magic spells. Currently they can't be used in the game, this is because we will be moving to our own server with its own protocol and coding stuff for our current server (eAthena) would be a waste of time.

== Common problems ==
=== When I try to login using the account that usually works, I get following message: Unable to connect to Login Server ===
This means that the game server is not online at the moment you try to login. Try again later.

If you really want to make sure, look for "host" to be equal some host (''host=server.themanaworld.org'') and "port" to be filled (''port=6901'') in config.xml. If that is the case and you still are not convinced it really is down, run "ping -c1 <host>" to check if the server's machine is up at or run "telnet <host> <port>" to also check if the server software is listening on the port you specified. Telnet should timeout after a while if it cannot connect to the specific port on the host. or (for the official server) just use the server link on the home page ;)

=== When installing under Debian GNU/Linux, I get the following libguichan error, and I can't find libguichan in the repositories. What can I do? ===

Package libguichan is not available, but is referred to
by another package
This may mean that the package is missing, has been obsoleted,
or is only available from another source
Package libguichan has no installation candidate

Download the Debian package [http://guichan.sourceforge.net/downloads.shtml here].