The Mana World - User contributions [en]

Development:Image dyeing

2016-07-03T23:40:12Z

Modanung: /* Simple colors and palettes */

==Simple colors and palettes==

A pixel has a simple color if it is not black and if its non-zero RGB components are all equal. Or described in terms of the HSV color model: it has a hue divisible by 60, full saturation, and any value other than zero.

There are seven simple colors:

* '''R'''ed
* '''G'''reen
* '''B'''lue
* '''C'''yan
* '''M'''agenta
* '''Y'''ellow
* '''W'''hite (gray, that is)

For a given color, there are 255 different intensities (from 1 to 255). For RGB, the non-zero value is the intensity. For HSV, the volume is the intensity, scaled to 255.

A palette is a sequence of RGB colors, for example <code>#8c4b41,da9041,ffff41</code>. An intensity of 255 becomes color <code>#ffff41</code>. An intensity of 0 is left unchanged (as black, <code>#000000</code>). Intensities with no explicit color are linearly interpolated between the two closest value. Black is implicitly the first color of the palette. For example:
{|
! intensity
! color
|-
|50
|<code>#522C26</code>
|-
|85
|<code>#8c4b41</code>
|-
|100
|<code>#995741</code>
|-
|170
|<code>#da9041</code>
|}

Palettes can have from one to 255 colors.

Pixels with complicated colors or without any dedicated palette are left unchanged by the dye process. The system can dye up to 1785 different colors.

==Dye Channels==
==='''RGBCMYW''' Dyes===

Usage:
Single Channel Inline xml: image.png|R:#ColorCode
Multi-Channel Inline xml: image.png|R:#ColorCode;B:#ColorCode
Single Channel Preset xml: image.png|R
Multi-Channel Preset xml: image.png|R;B

==='''S'''wap dye===
This swaps a single specific color on a channel regardless of transparency for another

Use:
Inline xml: image.png|S:#StartingColor,#ResultColor;
Preset xml: image.png|S

Example:
image.png|S:#FF0000,#00FF00;
Starting color: #FF0000 (pure red)
Result color: #00FF00 (pure green)

==='''A'''lpha dye===
This swaps a single specific color on a channel taking transparency into account

Use:
Inline Xml: image.png|S:#StartingColor,#ResultColor;
Preset Xml: image.png|S

Example:
image.png|S:#FF000088,#00FF0088;
Starting color: #FF000088 (pure red with ~half transparency)
Result color: #00FF0088 (pure green with ~half transparency)

===One-channel example===
Here is a simple example taken from actual game data. The <code>data/monsters.xml</code> file contains the descriptions of all the monsters. For black scorpions, the definition begins with

<monster id="1009" name="Black scorpion">
<sprite>monster-scorpion.xml|#0d1313,435a5a,879999,ffffff</sprite>
<sound event="hit">scorpion-hit1.ogg</sound>
...

The <code>data/graphics/sprite/monster-scorpion.xml</code> then describes the animation of any scorpion, whatever its color. It contains this line:

<imageset name="base" src="graphics/sprites/monster-scorpion.png|W" width="48" height="45" />

The <code>monster-scorpion.png</code> file is a grayscale image, hence the '''W''' color specifier, so that all its pixels are blackened (or dyed to brown or red for other species of scorpions). If it contained some non-gray pixels, these would not be recolored by the palette specified in the <code>monsters.xml</code> file.

===Multi-channel example===
Here an example for multi-channel dyeing of an equipment sprite. This example recolors the gray sections of the image to green and the red sections to a gray-blue.

head-devcap.xml:
<imageset name="base" src="graphics/sprites/head-devcap.png|W;R" width="28" height="19" />

items.xml:
<sprite>head-devcap.xml|#22ff22,ffffff;#9999ff</sprite>

==Designing graphics to be dyeable==
The easy way to make an existing graphic recolorable is to select the parts you want to be recolored and run it through a convert-to-greyscale filter and voilÃ , you have a recolorable 'W' channel. For optimum results you should then adjust the levels of the grey area so that the darkest color is RGB 127, 127, 127 and the brightest color RGB 255, 255, 255. That way you can very simply define the darkest and the brightest color of the color ramp in items.xml.

When you want to use another dye channel than 'W' you can use "color channels" afterwards and remove one or two of the red, green and blue channel completely.

==Test dyes without restarting Manaplus==
===In-Game===
You can reload some of the client-data by typing the following command into chat.
You may have to unequip items then use the command then equip them again.
/cleangraphics

===dyecmd===
After version 1.3.10.27 of manaplus: the dyecmd is supported.

Usage:
dyecmd srcfile dyestring dstfile
dyecmd srcdyestring dstfile

examples:
dyecmd cottonshirt.png W:#a4b2b2,ffffff test.png
dyecmd "cottonshirt.png|W:#a4b2b2,ffffff" test2.png

From Source
get manaplus source git clone https://bitbucket.org/akaras/manaplus.git
autoreconf -i
./configure
make
src/dyecmd

[[Category:Development]]

User:Modanung

2016-02-17T01:46:08Z

Modanung: /* Gallery */

== Personal information ==
'''Nickname:''' Modanung

'''Full name:''' Frode Lindeijer

'''Occupation:''' Former pixel (and concept) artist for TMW

'''Location:''' Groningen, The Netherlands

'''Date of birth:''' 6th of July 1988

'''Website:''' [http://www.LucKeyProductions.nl www.LucKeyProductions.nl]

== Contact information ==
'''E-mail:''' frode at lindeijer dot nl

'''Telegram:''' modanung

== Gallery ==

<gallery>
Image:Woodenarmor.jpg
Image:Actionlayers.png
Image:Hairstyle mohawk.png
</gallery>

Photobucket: http://s6.photobucket.com/user/Modanung/library/TMW

User:Modanung

2016-02-16T23:02:34Z

Modanung: /* Personal information */

== Personal information ==
'''Nickname:''' Modanung

'''Full name:''' Frode Lindeijer

'''Occupation:''' Former pixel (and concept) artist for TMW

'''Location:''' Groningen, The Netherlands

'''Date of birth:''' 6th of July 1988

'''Website:''' [http://www.LucKeyProductions.nl www.LucKeyProductions.nl]

== Contact information ==
'''E-mail:''' frode at lindeijer dot nl

'''Telegram:''' modanung

== Gallery ==

<gallery>
Image:Tulimshar street.jpg
Image:Leapmonster.jpg
Image:Woodenarmor.jpg
Image:Desert foodchain.jpg
Image:Tulimshar-wall.jpg
Image:Tulimshar-map.jpg
Image:Actionlayers.png
Image:Hairstyle mohawk.png
</gallery>

Photobucket: http://s6.photobucket.com/user/Modanung/library/TMW

User:Modanung

2016-02-16T22:57:10Z

Modanung: /* Contact information */

== Personal information ==

'''Nickname:''' Modanung

'''Full name:''' Frode Lindeijer

'''Occupation:''' Former pixel (and concept) artist for TMW

'''Location:''' Groningen, The Netherlands

'''Date of birth:''' 6th of July 1988

'''Website:''' [http://www.LucKeyProductions.nl www.LucKeyProductions.nl]

== Contact information ==
'''E-mail:''' frode at lindeijer dot nl

'''Telegram:''' modanung

== Gallery ==

<gallery>
Image:Tulimshar street.jpg
Image:Leapmonster.jpg
Image:Woodenarmor.jpg
Image:Desert foodchain.jpg
Image:Tulimshar-wall.jpg
Image:Tulimshar-map.jpg
Image:Actionlayers.png
Image:Hairstyle mohawk.png
</gallery>

Photobucket: http://s6.photobucket.com/user/Modanung/library/TMW

User:Modanung

2016-02-16T22:56:06Z

Modanung: /* Personal information */

== Personal information ==

'''Nickname:''' Modanung

'''Full name:''' Frode Lindeijer

'''Occupation:''' Former pixel (and concept) artist for TMW

'''Location:''' Groningen, The Netherlands

'''Date of birth:''' 6th of July 1988

'''Website:''' [http://www.LucKeyProductions.nl www.LucKeyProductions.nl]

== Contact information ==
'''E-mail:''' f dot lindeijer at gmail dot com ...or... frode at lindeijer dot nl

'''MSN:''' modanung at hotmail dot com

'''GTalk:''' f dot lindeijer at gmail dot com

== Gallery ==

<gallery>
Image:Tulimshar street.jpg
Image:Leapmonster.jpg
Image:Woodenarmor.jpg
Image:Desert foodchain.jpg
Image:Tulimshar-wall.jpg
Image:Tulimshar-map.jpg
Image:Actionlayers.png
Image:Hairstyle mohawk.png
</gallery>

Photobucket: http://s6.photobucket.com/user/Modanung/library/TMW

User:Modanung

2012-07-14T15:46:43Z

Modanung: /* Frode */

== Personal information ==
'''Full name:''' Frode Lindeijer

'''Nickname:''' Modanung

'''Occupation:''' Pixel (and concept) artist for TMW

'''Location:''' Groningen, Groningen, The Netherlands

'''Date of birth:''' 6th of July 1988

== Contact information ==
'''E-mail:''' f dot lindeijer at gmail dot com ...or... frode at lindeijer dot nl

'''MSN:''' modanung at hotmail dot com

'''GTalk:''' f dot lindeijer at gmail dot com

== Gallery ==

<gallery>
Image:Tulimshar street.jpg
Image:Leapmonster.jpg
Image:Woodenarmor.jpg
Image:Desert foodchain.jpg
Image:Tulimshar-wall.jpg
Image:Tulimshar-map.jpg
Image:Actionlayers.png
Image:Hairstyle mohawk.png
</gallery>

Photobucket: http://s6.photobucket.com/albums/y203/Modanung/

User:Modanung

2012-07-14T15:46:34Z

Modanung: /* Frode */

== Frode ==
That's me

== Personal information ==
'''Full name:''' Frode Lindeijer

'''Nickname:''' Modanung

'''Occupation:''' Pixel (and concept) artist for TMW

'''Location:''' Groningen, Groningen, The Netherlands

'''Date of birth:''' 6th of July 1988

== Contact information ==
'''E-mail:''' f dot lindeijer at gmail dot com ...or... frode at lindeijer dot nl

'''MSN:''' modanung at hotmail dot com

'''GTalk:''' f dot lindeijer at gmail dot com

== Gallery ==

<gallery>
Image:Tulimshar street.jpg
Image:Leapmonster.jpg
Image:Woodenarmor.jpg
Image:Desert foodchain.jpg
Image:Tulimshar-wall.jpg
Image:Tulimshar-map.jpg
Image:Actionlayers.png
Image:Hairstyle mohawk.png
</gallery>

Photobucket: http://s6.photobucket.com/albums/y203/Modanung/

User:Modanung

2008-07-17T21:00:54Z

Modanung:

== Frode ==
http://i6.photobucket.com/albums/y203/Modanung/M5110059_edit.jpg

== Personal information ==
'''Full name:''' Frode Lindeijer

'''Nickname:''' Modanung

'''Occupation:''' Pixel (and concept) artist for TMW

'''Location:''' Groningen, Groningen, The Netherlands

'''Date of birth:''' 6th of July 1988

== Contact information ==
'''E-mail:''' f dot lindeijer at gmail dot com ...or... frode at lindeijer dot nl

'''MSN:''' modanung at hotmail dot com

'''GTalk:''' f dot lindeijer at gmail dot com

== Gallery ==

<gallery>
Image:Tulimshar street.jpg
Image:Leapmonster.jpg
Image:Woodenarmor.jpg
Image:Desert foodchain.jpg
Image:Tulimshar-wall.jpg
Image:Tulimshar-map.jpg
Image:Actionlayers.png
Image:Hairstyle mohawk.png
</gallery>

Photobucket: http://s6.photobucket.com/albums/y203/Modanung/

File talk:Trebuchet2.png

2007-12-17T23:28:54Z

Modanung:

I made one of those a few years ago... about 1/5 of the scale as the one on the image. With a trough of about 2 meters, a beam of 3-4 meters and about 30-40 bricks as a counter weight. It could throw 5 kilo boulders or snowballs with a diameter of .5 meters about 45-50 meters away. [[User:Modanung|Modanung]] 00:28, 18 December 2007 (CET)

File talk:Trebuchet2.png

2007-12-17T23:28:38Z

Modanung:

File:Elements wind.png

2007-10-13T14:25:24Z

Modanung: Wind... air... what's the difference.

Icon for the element air

Archive:Elements

2007-10-13T14:24:48Z

Modanung: Changed element icons

{{Status_yellow}}
{{Gaps|
*Calculation of damage for sub-elements
}}
==Elements==
The main elements in the mana world are:

[[Image:Elements_water.png]] Water

[[Image:Elements_wind.png]] Air

[[Image:Elements_fire.png]] Fire

[[Image:Elements_earth.png]] Earth

Every element got one element it is strong against and one it is weak against. These relationships form a circle:

*Fire is extinguished by Water
*Water is absorbed by Earth
*Earth is eroded by Air
*Air is consumed by Fire

Then there are four sub-elements:
*''Air + Fire'' = Lightning
*''Fire + Earth'' = Metal
*''Earth + Water'' = Wood
*''Water + Air'' = Ice

==Elemental Effect on damage==
Elemental damage is mainly inflicted by magic attacks and magic weapons. Normal weapons inflict damage that is not modified by elements.

Every being has an elemental damage modifier for each element. These modifiers are percentual modifiers that are applied to the elemental damage the being receives before the damage reductions by physical or magical defence are applied.

The system allows "composite damage" attacks of unelemental and different elemental damages. When a being receives a hit by an obscure multi-elemental physical attack that gives 100 unelemental damage, 50 fire damage, 50 water damage, 50 air damage and 50 earth damage, each elemental part of the attack is modified individually. The results are added and then processed as one attack by the other damage calculation mechanics.

==Elemental modifiers of player characters==
The elemental modifiers of player characters are influenced slightly by its race and mostly by its equipment. They can also be changed by temporary status effects.

Every piece of defensive equipment that got an elemental property lowers damage received from the element it is strong against but on the other hand increases the damage received from the element it is weak against by an equal factor. This means that every resistance against one element is cancelled out by an equal weakness against another element. A "rainbow equipment set" that mixes pieces of all elements results in no resistance at all because all the resistances cancle each other out. That way a character can never be completely invulnerable.

For calculating these resistances and weaknesses every defence item with an elemental property got an elemental property modifier that is a decimal number usually slightly larger than 1.0. All elemental damage of the element it is strong against is divided through this number and all elemental damage of the element it is weak against is multiplied with this number. The elemental property modifier is communicated to the player in the item description as a percentual modifier on both elements to make it easier for the player to understand the effect of the item.

This system only covers the 4 main elements. The combined elements, lightning, metal, wood and ice, aren't covered in it yet.

:'''Example''': A mage robe of earth would, in addition to raising the characters earth magic skill, have an elemental modifier of "Earth 1.25". This means it lower all received water damage by 20% (100% / 1.25) but increase all received air damage by 25% (100% * 1.25).

All elemental damage modifiers are applied one after another. This means that the total elemental modifier of a character is the multiplication of all its elemental modifiers. As long as there are no items with an elemental modifier of 0.0 no total elemental modifier of a character can reach 0 and thus garant complete immunity against an element. And such items should not exist as they would result in a division by zero when calculating the damage of the element it creates a vulnerability for (infinite damage?).

:'''Example''': A character wears two very powerful water items with a modifier of "Water 2.0" each and thus has two times a 50% resistance against fire and two times 100% more damage by earth. This does not result in 0% fire damage but in 25% fire damage (0.5 x 0.5 = 0.25) and doesn't mean 300% damage by earth but 400% damage (2.0 x 2.0 = 4.0).

===Formula===
Damage Modifier(element) = 100% * EP(element+1) / EP(element-1)
EP(element) = product of the elemental property modifiers for the element.

===Elemental resistances without coupling to an elemental weakness===
Equipment pieces or status effects that modify the resistance against one element without affecting the others (think "asbesto jacket" for fire resistance) are thinkable but should be rather the exception than the rule.

===Elemental modifiers < 1.0===
Elemental modifiers smaller than one would result in less damage by the element it is weak against and more damage by the element it is strong against. Such items are technically possible in this system without any problems when the content designers need such an effect.

==Elemental resistances and weaknesses of monsters==
I think we can take the freedom to set those arbitarily. In case of monsters that are clearly the incorporation of a specific element we should stay by the rule "strong against following element - weak against preceeding", but in case of other monsters we can set the resistances as they seem plausible to us (a hay golem can be vulnerable against fire without being invulnerable to earth, for example).

File:Elements wind.png

2007-10-13T14:21:43Z

Modanung: Icon for the element wind

Icon for the element wind

File:Elements water.png

2007-10-13T14:21:28Z

Modanung: Icon for the element water

Icon for the element water

File:Elements fire.png

2007-10-13T14:21:15Z

Modanung: Icon for the element fire

Icon for the element fire

File:Elements earth.png

2007-10-13T14:20:53Z

Modanung: Icon for the element earth

Icon for the element earth

Talk:Argaes

2007-10-09T19:22:45Z

Modanung:

I personally was thinking of this continent as pretty bare. Rocky with some ruins. The middle part being low and to the west and east the height would increase.
Watch out not to make a small enviroment too rich when it comes to variation in landscape. Desert, plains, forest, jungle AND mountains? I think that's way too much. I imagined this island to be a bit like Iceland. Mainly these parts of Iceland:
*[http://en.wikipedia.org/wiki/Image:NesjavellirPowerPlant_edit2.jpg]
*[http://en.wikipedia.org/wiki/Image:Gr%C3%ADmsey_Iceland.JPG]

Water in the middle and steep cliffs at the East and West coast.
Don't get me wrong, the map looks ok. But it's just way too much packed in a small enviroment if you ask me.
[[User:Modanung|Modanung]] 00:53, 13 September 2007 (CEST)

:I think such a landscape would result in pretty boring maps as there are few natural obstacles. --[[User:Crush|Crush]] 02:13, 13 September 2007 (CEST)
::Without mountains you can still have steep natural walls, just not that tall (1-3 tiles). And how about big slabs of rock and cravices? What's the difference between that and a desert? [[User:Modanung|Modanung]] 14:13, 26 September 2007 (CEST)

[http://i6.photobucket.com/albums/y203/Modanung/argaes1.png Here's] a quick and rough concept of how I think the continent should look like. Pretty barren except for some low vegitation, maybe savannah-like (warm Iceland).
[[User:Modanung|Modanung]] 21:22, 9 October 2007 (CEST)

User talk:Crush/Magic System Populous 3 style

2007-10-05T09:39:18Z

Modanung:

I'd say the persistent area of effect spells stay at the same area. I would refer to spells that move with the player as aura spells. [[User:Modanung|Modanung]] 11:39, 5 October 2007 (CEST)

Archive:Attributes

2007-10-04T19:30:14Z

Modanung: /* Attributes */

{{Category_gameconcept}}
{{Status_yellow}}
{{Gaps|
*Decide the exact role of intelligence and willpower in the magic system
*Decide on one skill system and delete the section about this question
*Formulas for more derived attributes that are important
*Nail down the attribute increase rules
}}
== Attributes ==

We have the following 5 attributes:

{| border="1" cellspacing="0" cellpadding="3"
! style="text-align: left; background-color: rgb(240,240,240);" | Name
! style="text-align: left; background-color: rgb(240,240,240);" | General effect

|-
|''Strength''
|
*damage with melee weapons
*inventory weight
*prerequisite for string-based ranged weapons
*prerequisite for heavy melee weapons
|-
|''Dexterity''
|
*chance to hit
*chance to dodge
*damage with ranged weapons.
*prerequisite for elegant melee weapons
|-
|''Vitality''
|
*maximum hit points
*hit point regeneration rate
|-
|''Intelligence''
|
Related to the magic system
|-
|''Willpower''
|
Related to the magic system
|-
|}

The effective value of attributes may never be below one. Even when modificators push it to zero or below the value used by formulas is always at least 1 to avoid divisions by zero.

===Derived Attributes===
;Hit points: (vitality + 10) * (level + 10)
;Hit point regeneration: (vitality + 10)Â² hp per minute

== Skills ==

Interesting notes about possible skill systems were made at [[skill system]], [[skill system 2]] and at the [[master skill list]].

:''I think that the [[master skill list]] is still a nice proposal, but I think we should leave out the "Stat skills".'' --[[User:BjÃ¸rn|BjÃ¸rn]] 11:53, 10 June 2006 (CEST)
::''I tweaked the [[skill system 2]] propoal to work together with this article. I hope you like it better now. It shouldn't be left out because it is the first well thought out proposal for exp gain of skills. The "1 exp per action" concept of the [[skill system]] is just too simple to work. When you want to have some skills from the master skill list you should think about how the concepts of skill system 2 can be applied to those.'' --[[User:Crush|Crush]] 15:34, 31 August 2006 (CEST)

=== Deriving level from skills ===

The character level depends mostly on the best skills of the character and less on the less good skills.

We multiply the skill level by a factor based on to what extend the skill is one of your top skills, and devide the sum by a given amount. When n is the index of the skill in the list sorted on skill level, 0.9^n could be the factor. An example with 10 skills for a typically average trained character (with skills and level going from 1 to 100):

<pre>
0 1.0 * 78 = 78.0
1 0.9 * 65 = 58.5
2 0.81 * 53 = 42.93
3 0.729 * 40 = 29.16
4 0.6561 * 40 = 26.244
5 0.59049 * 38 = 22.43862
6 0.531441 * 33 = 17.537553
7 0.4782969 * 23 = 11.0008287
8 0.43046721 * 20 = 8.6093442
9 0.387420489 * 15 = 5.811307335

Sum of factors: 6.513215599
Sum of skills * factors: 300.231653235
Character level: 46.0957646298544 (level 46, 10% progression to next level)
</pre>

When the character level is used in any formulas it is always rounded down to the next lowest integer. Should the character lose skill levels for some reason the level will never be reduced. That way we don't have to deal with loss and regain of attribute increase points.

The best thing the character can do to work towards the next level is to raise its highest skill. The downside to do this is that this will be the hardest thing to do because it will be exponentially harder to increase in a certain skill.

=== From level to character attributes ===

Every levelup the character receives a number of points that can be used to increase its attributes. Every point can at any time be exchanged in raising one attribute by one point. When we assume that every attribute starts at 10 and we have a maximum of 100 per attribute a maxed out character would need 450 points. When we assume that characters have a theoretical maximum of 100 levels then 4 points per levelup would be adequate.

Crush has noted that he'd like players to be able to decrease their attributes as well, in order to increase others and thereby allowing the players to "correct their mistakes" if they think they have previously made the wrong choices when distributing the points for their attributes. As a solution we could choose for a system where for each level increase, one or more points can be substracted before proceeding with distributing points amongst attributes.

More refined, the idea is now that for each level increase you get a certain amount of '-' points and a certain amount of '+' points. The '-' points can be used to decrease an attribute, and results in the gain of a '+' point. '+' points can simply be used to increase an attribute. To make sure that players cannot collect '-' points in order to make big changes to their character attributes later, the maximum amount of '-' points that can be accumulated should be restricted.

=== Attribute increase rules ===
{{Status_red}}
To avoid unbalanced characters players should have some restrictions when distributing the stat points. Without any restrictions a level 23 character could already have one stat maxed out under the conditions mentioned above. To make this impossible I would suggest to use one of the following restrictions (or a combination of several):
# The game design has to be made in a way that every character type needs a bit of every stat so unbalanced characters are unplayable (I would not suggest this because it is a) very hard to realize and b) very hard to combine with encouraging character specialisation)
# The highest attribute may not be higher than all other attributes together (not that good because it would work against single stat specialisation but not against double stat specialisation)
# Add a special penalty for unbalanced characters (I think this would just feel too artifical)
# Making attribute increase cost more points the higher the attribute is (That's the way Ragnarok Online does it. And as Ragnarok Online shows this works against maxing stats too early but not against one-sided characters)
# No attribute may be higher than the character level (would require all characters to start with all stats on 1)
# No attribute may be higher than double as high as the lowest attribute
# The difference between the lowest and the highest attribute may not be larger than the character level (I would favor this solution because it means more choices the further your character advances while inexperienced players with low characters have no possibilities to ruin their character and it is a good compromise between allowing specialisation and maintaining balanced characters)

''I think number one isn't hard to realize at all. Diablo 1/2 did the same, you got like 5 points each level and of course you could choose to maximize one of your attributes, but this wasn't particularly useful. A very strong character (strength) isn't useful when it can't hit anything (dexterity) and neither when it has very low health (vitality) or is hit all the time (agility), and I think this should go for any case where you max out just one attribute. Another reason not to max out just one attribute was that many items came with a minimum demand on a certain attribute before you could equip them. The problem with most of the other restrictions (except 4 and 5 I'd say), is that they're hard to communicate intuitively to the user.'' --[[User:BjÃ¸rn|BjÃ¸rn]] 14:03, 26 March 2007 (CEST)
:''Remember that Diablo had a strict class system while we give the player much more freedom in character creation. Attributes are the only thing that separates a warrior from a mage. So when every attribute is important for every character it would be very easy to create omni-characters that can do everything.'' --[[User:Crush|Crush]] 23:42, 11 July 2007 (CEST)

Talk:Argaes

2007-09-26T12:22:54Z

Modanung:

I personally was thinking of this continent as pretty bare. Rocky with some ruins. The middle part being low and to the west and east the height would increase.
Watch out not to make a small enviroment too rich when it comes to variation in landscape. Desert, plains, forest, jungle AND mountains? I think that's way too much. I imagined this island to be a bit like Iceland. Mainly these parts of Iceland:
*http://en.wikipedia.org/wiki/Image:NesjavellirPowerPlant_edit2.jpg
*http://en.wikipedia.org/wiki/Image:Gr%C3%ADmsey_Iceland.JPG

Water in the middle and steep cliffs at the East and West coast.
Don't get me wrong, the map looks ok. But it's just way too much packed in a small enviroment if you ask me.
[[User:Modanung|Modanung]] 00:53, 13 September 2007 (CEST)

:I think such a landscape would result in pretty boring maps as there are few natural obstacles. --[[User:Crush|Crush]] 02:13, 13 September 2007 (CEST)
::Without mountains you can still have steep natural walls, just not that tall (1-3 tiles). And how about big slabs of rock and cravices? What's the difference between that and a desert? [[User:Modanung|Modanung]] 14:13, 26 September 2007 (CEST)

Talk:Argaes

2007-09-26T12:13:40Z

Modanung:

I personally was thinking of this continent as pretty bare. Rocky with some ruins. The middle part being low and to the west and east the height would increase.
Watch out not to make a small enviroment too rich when it comes to variation in landscape. Desert, plains, forest, jungle AND mountains? I think that's way too much. I imagined this island to be a bit like Iceland. Mainly these parts of Iceland:
*http://en.wikipedia.org/wiki/Image:NesjavellirPowerPlant_edit2.jpg
*http://en.wikipedia.org/wiki/Image:Gr%C3%ADmsey_Iceland.JPG

Water in the middle and steep cliffs at the East and West coast.
Don't get me wrong, the map looks ok. But it's just way too much packed in a small enviroment if you ask me.
[[User:Modanung|Modanung]] 00:53, 13 September 2007 (CEST)

:I think such a landscape would result in pretty boring maps as there are few natural obstacles. --[[User:Crush|Crush]] 02:13, 13 September 2007 (CEST)
::Without mountains you can still have steep natural walls, just not that tall (1-3 tiles). And how about big slabs of rock and cravices? What's the difference between that and a desert?[[User:Modanung|Modanung]] 14:13, 26 September 2007 (CEST)

Talk:Argaes

2007-09-12T22:53:13Z

Modanung:

User talk:Axltrozz

2007-02-22T13:55:08Z

Modanung: Argh, preview

You know there's something like a preview button on every wiki, right?
I doubt you do because you made a lot of changes in a short timespan. [[User:Modanung|Modanung]] 14:55, 22 February 2007 (CET)

Archive talk:Old Races

2007-01-04T09:45:49Z

Modanung: Newline

I think this article is obsolete now that we decided to use the new [[races]] and the new [[backstory]] and should be deleted. --[[User:Crush|Crush]] 01:36, 4 January 2007 (CET)

I think it could be used for non-playable races. [[User:Modanung|Modanung]] 10:45, 4 January 2007 (CET)

Archive talk:Old Races

2007-01-04T09:45:23Z

Modanung:

I think this article is obsolete now that we decided to use the new [[races]] and the new [[backstory]] and should be deleted. --[[User:Crush|Crush]] 01:36, 4 January 2007 (CET)
I think it could be used for non-playable races. [[User:Modanung|Modanung]] 10:45, 4 January 2007 (CET)

Archive:Time system

2006-12-06T21:26:00Z

Modanung: Udated a link (and added one with the previous edit)

{{Status_red}}
== Time system ==

How long is a day in the Mana World, relative to a day in Earth time? Or does time pass in this world at all? These questions are to be answered later on...

'''Related Forum topics:'''
*http://forums.themanaworld.org/viewtopic.php?t=502
*http://forums.themanaworld.org/viewtopic.php?t=1434

== Day/night system ==
Day and night system would allow the game to have a day state and a nocturnal state.
Giving the possibility to add multiple monster spawn sets. All point mentioned below are merely possible effects.

Day would..
* Enable light mapping
* Enable Day time animals to appear
* Open all shops
* Give light magic more power
* Enable diurnal NPCs to appear

Night would..
* Enable nocturnal animals to appear
* Make ghosts appear? (what kind of ghosts? creatures or playerghosts?)
* Allow players to commit burglary
* Make magic and fire look even cooler
* Maybe give access to places hidden in daylight (doors that show only in moonlight)
* Be the perfect time for a secret clan meeting
* Make darkness magic more powerful
* Enable nocturnal NPCs to appear

Archive:Time system

2006-12-06T21:24:53Z

Modanung: /* Time system */

{{Status_red}}
== Time system ==

How long is a day in the Mana World, relative to a day in Earth time? Or does time pass in this world at all? These questions are to be answered later on...

'''Related Forum topics:'''
*http://themanaworld.org/phpBB2/viewtopic.php?t=502
*http://forums.themanaworld.org/viewtopic.php?t=1434

== Day/night system ==
Day and night system would allow the game to have a day state and a nocturnal state.
Giving the possibility to add multiple monster spawn sets. All point mentioned below are merely possible effects.

Day would..
* Enable light mapping
* Enable Day time animals to appear
* Open all shops
* Give light magic more power
* Enable diurnal NPCs to appear

Night would..
* Enable nocturnal animals to appear
* Make ghosts appear? (what kind of ghosts? creatures or playerghosts?)
* Allow players to commit burglary
* Make magic and fire look even cooler
* Maybe give access to places hidden in daylight (doors that show only in moonlight)
* Be the perfect time for a secret clan meeting
* Make darkness magic more powerful
* Enable nocturnal NPCs to appear

Archive:PvP Games

2006-11-06T16:54:38Z

Modanung: Fixed a typo

{{Status_red}}
TMW should have some PvP minigame types.
This is a great way of competition and killing time and above that a whole lot of fun.
With every game players are able to place bets. Bets for money, items, pets, women or maybe even realestate if they feel really lucky. Most games can also be played just for fun, but involving bets makes it more exciting.
All games need at least 2 players to be played. Some could be played with up to 4 players.

Add your own ideas for games we could implement if you miss something or come up with an idea.

==Out-in-the-field games==
These games can be played almost anywhere by challenging another player. After starting a game players automatically sit facing eachother with one tile in between them. In the middle lies the playing field where the cards are played, the dice are thrown or where the board is placed. Players walking by can magnify the playing field and follow the game. Ofcourse in case of a cardgame they cannot see the hand of the players if this is part of the rules.

===Cardgames===
Players that have a pack of the same sort of cards can challenge one another to play a game of cards.
We could use a standard pack of cards and implement existing games.

We could also (maybe aside from the normal pack) have a pack of cards we designed ourselves. Maybe a bit like Magic the Gathering?

===Dicegames===
If one player has a set of dice he can challenge another player to play dice with him. Dicegames are merely based on luck.

See also:

* http://boardgames.about.com/cs/dicegames/tp/dice-games.htm
* http://www.realbeer.com/fun/games/dice.php

===Combination games===

Combination games involve both dice and classic cards. Both players should carry a pack of cards and one player needs a pack of dice.

===Boardgames===

To play board games one player needs to carry a board game with him.
Some examples are:
* Backgammon
* Chess
* Draughts
* Hnefatafl (Anglo-Norse Boardgame: http://en.wikipedia.org/wiki/Tafl_games)
* Reversi

We could ofcourse also design our own boardgame. Also every region could have his very own boardgame. This would be designed by us, may it be based on an exsisting game. Every region would have an NPC called "[name] the [game] master" that can teach you about the boardgame. He is so masterfull he can play the game simultanious against a whole bunch of players. So they can all sit around and learn the game. If you win a best-out-of-three competition from the master you get a rulebook. You can buy the boardgame at the local (general) store.

==Place-bound games==
These games can only be played at places where the facilities allow them to be played.

===Darts===
In some inns there should be a dartboard (maybe our own version) so players could play darts. Throwing darts should take place in a special window. The player controls a cursor (with keyboard or mouse) and their dexterity influences their accuracy. There are two ways to do this:
The first way is to let the cursor sway around the spot where the player aims. The amount it sways and the speed with which it sways decrease with the dexterity's increase.
The other way is to have a stable cursor but have the dart fly in a slightly random direction. The randomness should decrease with the dexterity's increase. There is a circle around the target that shows the area in which the dart could end up.

The first way leaves the player with more influence on the actual direction of the dart eventhough a low dexterity makes it harder to hit the spot he wants. He sees where the dart will hit the board before he presses the button, it's all about timing and reflexes. Whereas the other way the player should just be lucky with where the dart hits the board.
Players should be able to add a handicap for themselves if they want to make it a fair game. Setting your handicap to 10 should decrease your dexterity with 10 during the game.

:i think any game of skill is not a good idea in an online game because it would be too easy to program a perfect playing bot which plays for you. --[[User:Crush|Crush]] 20:51, 16 Sep 2005 (CEST)
::What are you suggesting? Luck-based games only? Don't you agree that would suck fried peanuts? You will always keep bots, and they should be deleted. We should just make it hard to write bots. [[User:Modanung|Modanung]] 00:50, 17 Sep 2005 (CEST)
:::how about strategy games like chess variants? Or card games that have a luck component and a strategical component? --[[User:Crush|Crush]] 03:19, 13 March 2006 (CET)
::::Well people could write a chess bot as well, right? And pure chance games are boring, if there's nothing else. Besides, if you know someone is a bot/cheater you won't play darts with him. [[User:Modanung|Modanung]] 18:15, 13 March 2006 (CET)

===Ringfights===
Ringfights take place in an arena or at a fightclub. Any place with something that looks like a boxing-ring will do.
In a ringfight two players fight eachother without any equipment or items. Players are not allowed (and not able) to use any form of magic either. So it is hand-to-hand combat only. The goal is to knock-out the other player. Knocking a player out is easiest if your strength is high and your opponents vitality low. You can try to block or evade attacks. Both need good timing. Blocking an attack is most effective whith a lot of strength, but still makes you lose some health. The higher your strength, the less health you lose when hit while blocking. Evading doesn't always succeed. The chance to evade an attack increases with your dexterity. If you evade an attack you recieve no damage at all.
If a player loses a match he is placed outside the arena with 1/4 of his maximum health. Even losers get some treatment after the match.

Archive:PvP Games

2006-11-06T16:54:13Z

Modanung: /* Ringfights */

{{Status_red}}
TMW should have some PvP minigame types.
This is a great way of competition and killing time and above that a whole lot of fun.
With every game players are able to place bets. Bets for money, items, pets, women or maybe even realestate if they feel really lucky. Most games can also be played just for fun, but involving bets makes it more exciting.
All games need at least 2 players to be played. Some could be played with up to 4 players.

Add your own ideas for games we could implement if you miss something or come up with an idea.

==Out-in-the-field games==
These games can be played almost anywhere by Challenging another player. After starting a game players automatically sit facing eachother with one tile in between them. In the middle lies the playing field where the cards are played, the dice are thrown or where the board is placed. Players walking by can magnify the playing field and follow the game. Ofcourse in case of a cardgame they cannot see the hand of the players if this is part of the rules.

===Cardgames===
Players that have a pack of the same sort of cards can challenge one another to play a game of cards.
We could use a standard pack of cards and implement existing games.

We could also (maybe aside from the normal pack) have a pack of cards we designed ourselves. Maybe a bit like Magic the Gathering?

===Dicegames===
If one player has a set of dice he can challenge another player to play dice with him. Dicegames are merely based on luck.

See also:

* http://boardgames.about.com/cs/dicegames/tp/dice-games.htm
* http://www.realbeer.com/fun/games/dice.php

===Combination games===

Combination games involve both dice and classic cards. Both players should carry a pack of cards and one player needs a pack of dice.

===Boardgames===

To play board games one player needs to carry a board game with him.
Some examples are:
* Backgammon
* Chess
* Draughts
* Hnefatafl (Anglo-Norse Boardgame: http://en.wikipedia.org/wiki/Tafl_games)
* Reversi

We could ofcourse also design our own boardgame. Also every region could have his very own boardgame. This would be designed by us, may it be based on an exsisting game. Every region would have an NPC called "[name] the [game] master" that can teach you about the boardgame. He is so masterfull he can play the game simultanious against a whole bunch of players. So they can all sit around and learn the game. If you win a best-out-of-three competition from the master you get a rulebook. You can buy the boardgame at the local (general) store.

==Place-bound games==
These games can only be played at places where the facilities allow them to be played.

===Darts===
In some inns there should be a dartboard (maybe our own version) so players could play darts. Throwing darts should take place in a special window. The player controls a cursor (with keyboard or mouse) and their dexterity influences their accuracy. There are two ways to do this:
The first way is to let the cursor sway around the spot where the player aims. The amount it sways and the speed with which it sways decrease with the dexterity's increase.
The other way is to have a stable cursor but have the dart fly in a slightly random direction. The randomness should decrease with the dexterity's increase. There is a circle around the target that shows the area in which the dart could end up.

The first way leaves the player with more influence on the actual direction of the dart eventhough a low dexterity makes it harder to hit the spot he wants. He sees where the dart will hit the board before he presses the button, it's all about timing and reflexes. Whereas the other way the player should just be lucky with where the dart hits the board.
Players should be able to add a handicap for themselves if they want to make it a fair game. Setting your handicap to 10 should decrease your dexterity with 10 during the game.

:i think any game of skill is not a good idea in an online game because it would be too easy to program a perfect playing bot which plays for you. --[[User:Crush|Crush]] 20:51, 16 Sep 2005 (CEST)
::What are you suggesting? Luck-based games only? Don't you agree that would suck fried peanuts? You will always keep bots, and they should be deleted. We should just make it hard to write bots. [[User:Modanung|Modanung]] 00:50, 17 Sep 2005 (CEST)
:::how about strategy games like chess variants? Or card games that have a luck component and a strategical component? --[[User:Crush|Crush]] 03:19, 13 March 2006 (CET)
::::Well people could write a chess bot as well, right? And pure chance games are boring, if there's nothing else. Besides, if you know someone is a bot/cheater you won't play darts with him. [[User:Modanung|Modanung]] 18:15, 13 March 2006 (CET)

===Ringfights===
Ringfights take place in an arena or at a fightclub. Any place with something that looks like a boxing-ring will do.
In a ringfight two players fight eachother without any equipment or items. Players are not allowed (and not able) to use any form of magic either. So it is hand-to-hand combat only. The goal is to knock-out the other player. Knocking a player out is easiest if your strength is high and your opponents vitality low. You can try to block or evade attacks. Both need good timing. Blocking an attack is most effective whith a lot of strength, but still makes you lose some health. The higher your strength, the less health you lose when hit while blocking. Evading doesn't always succeed. The chance to evade an attack increases with your dexterity. If you evade an attack you recieve no damage at all.
If a player loses a match he is placed outside the arena with 1/4 of his maximum health. Even losers get some treatment after the match.

Archive:PvP Games

2006-11-06T16:52:37Z

Modanung: Changed the broken link into a different one

{{Status_red}}
TMW should have some PvP minigame types.
This is a great way of competition and killing time and above that a whole lot of fun.
With every game players are able to place bets. Bets for money, items, pets, women or maybe even realestate if they feel really lucky. Most games can also be played just for fun, but involving bets makes it more exciting.
All games need at least 2 players to be played. Some could be played with up to 4 players.

Add your own ideas for games we could implement if you miss something or come up with an idea.

==Out-in-the-field games==
These games can be played almost anywhere by Challenging another player. After starting a game players automatically sit facing eachother with one tile in between them. In the middle lies the playing field where the cards are played, the dice are thrown or where the board is placed. Players walking by can magnify the playing field and follow the game. Ofcourse in case of a cardgame they cannot see the hand of the players if this is part of the rules.

===Cardgames===
Players that have a pack of the same sort of cards can challenge one another to play a game of cards.
We could use a standard pack of cards and implement existing games.

We could also (maybe aside from the normal pack) have a pack of cards we designed ourselves. Maybe a bit like Magic the Gathering?

===Dicegames===
If one player has a set of dice he can challenge another player to play dice with him. Dicegames are merely based on luck.

See also:

* http://boardgames.about.com/cs/dicegames/tp/dice-games.htm
* http://www.realbeer.com/fun/games/dice.php

===Combination games===

Combination games involve both dice and classic cards. Both players should carry a pack of cards and one player needs a pack of dice.

===Boardgames===

To play board games one player needs to carry a board game with him.
Some examples are:
* Backgammon
* Chess
* Draughts
* Hnefatafl (Anglo-Norse Boardgame: http://en.wikipedia.org/wiki/Tafl_games)
* Reversi

We could ofcourse also design our own boardgame. Also every region could have his very own boardgame. This would be designed by us, may it be based on an exsisting game. Every region would have an NPC called "[name] the [game] master" that can teach you about the boardgame. He is so masterfull he can play the game simultanious against a whole bunch of players. So they can all sit around and learn the game. If you win a best-out-of-three competition from the master you get a rulebook. You can buy the boardgame at the local (general) store.

==Place-bound games==
These games can only be played at places where the facilities allow them to be played.

===Darts===
In some inns there should be a dartboard (maybe our own version) so players could play darts. Throwing darts should take place in a special window. The player controls a cursor (with keyboard or mouse) and their dexterity influences their accuracy. There are two ways to do this:
The first way is to let the cursor sway around the spot where the player aims. The amount it sways and the speed with which it sways decrease with the dexterity's increase.
The other way is to have a stable cursor but have the dart fly in a slightly random direction. The randomness should decrease with the dexterity's increase. There is a circle around the target that shows the area in which the dart could end up.

The first way leaves the player with more influence on the actual direction of the dart eventhough a low dexterity makes it harder to hit the spot he wants. He sees where the dart will hit the board before he presses the button, it's all about timing and reflexes. Whereas the other way the player should just be lucky with where the dart hits the board.
Players should be able to add a handicap for themselves if they want to make it a fair game. Setting your handicap to 10 should decrease your dexterity with 10 during the game.

:i think any game of skill is not a good idea in an online game because it would be too easy to program a perfect playing bot which plays for you. --[[User:Crush|Crush]] 20:51, 16 Sep 2005 (CEST)
::What are you suggesting? Luck-based games only? Don't you agree that would suck fried peanuts? You will always keep bots, and they should be deleted. We should just make it hard to write bots. [[User:Modanung|Modanung]] 00:50, 17 Sep 2005 (CEST)
:::how about strategy games like chess variants? Or card games that have a luck component and a strategical component? --[[User:Crush|Crush]] 03:19, 13 March 2006 (CET)
::::Well people could write a chess bot as well, right? And pure chance games are boring, if there's nothing else. Besides, if you know someone is a bot/cheater you won't play darts with him. [[User:Modanung|Modanung]] 18:15, 13 March 2006 (CET)

==Ringfights==
Ringfights take place in an arena or at a fightclub. Any place with something that looks like a boxing-ring will do.
In a ringfight two players fight eachother without any equipment or items. Players are not allowed (and not able) to use any form of magic either. So it is hand-to-hand combat only. The goal is to knock-out the other player. Knocking a player out is easiest if your strength is high and your opponents vitality low. You can try to block or evade attacks. Both need good timing. Blocking an attack is most effective whith a lot of strength, but still makes you lose some health. The higher your strength, the less health you lose when hit while blocking. Evading doesn't always succeed. The chance to evade an attack increases with your dexterity. If you evade an attack you recieve no damage at all.
If a player loses a match he is placed outside the arena with 1/4 of his maximum health. Even losers get some treatment after the match.

Classic:Maps

2006-10-28T13:02:58Z

Modanung: /* Existing maps */

{{Status_green}}
== Guidelines ==

You can build a map for TMW using [http://mapeditor.org Tiled]

* '''Size:''' around 200x200 tiles is good in practice, though the theoretical maximum is 2048x2048
* '''Tile size:''' 32x32
* '''Map border:''' you have to leave an empty border around the map of at least 20 tiles
* '''Walls/players proportions:''' a normal door for a player is 2 tiles in height
* '''Indoor/Outdoor proportions:''' it is not required that inside view of buildings has to fit the size in outside view
* '''Path reference:''' please use tmw folder structure to keep references to tilesets working
* '''Transparent color:''' tilesets use alpha so no need to set a transparent color
* '''Layers:''' each map uses 4 layers: ground, objects, over and collision (names are only suggested)
** ''Ground:'' used for everything below items and beings.
** ''Objects:'' this layer is drawn simultaneously with items and beings, where tiles above a being are drawn below the being and tiles below the being are drawn above. Hence this layer is suitable for adding static objects to a map like plants or statues.
** ''Over:'' usually used for walls or high objects. Each tile in this layer is always above items and beings.
** ''Collision:'' this is a special layer for which you have to use the collision tileset. Use the 'X' tile where you want a tile to be unwalkable. Be careful that even if a tile is not reachable, but it's walkable, the server can spawn monsters there, so you won't be able to reach them, or you can cause weird situations. For example fill a wall with 'X' tiles, not only the borders, or you could have monsters spawning inside the wall.

In a good style of mapping, please always use the lowest layer as possible (this is also in the interests of perfomance, since it keeps down overdraw).

==Existing maps==

Here a list of all existing maps:

{|
|-
|'''Filename'''
|'''Description'''
|-
| new_1-1.tmx.gz
| Desert south of Tulimshar
|-
| new_2-1.tmx.gz
| Desert Mine, level 1
|-
| new_3-1.tmx.gz
| Tulimshar City, outdoor
|-
| new_4-1.tmx.gz
| Hermits Cave, level 1 (Bat Cave)
|-
| new_5-1.tmx.gz
| Desert Mine, level 2
|-
| new_6-1.tmx.gz
| PvP Arena
|-
| new_7-1.tmx.gz
| Desert southeast of Tulimshar (Snake map)
|-
| new_8-1.tmx.gz
| Tulimshar City, indoor
|-
| new_9-1.tmx.gz
| Woodland, northwest (Red Mushroom Map)
|-
| new_10-1.tmx.gz
| Snow field (Rudolph Slime + Santa Slime map)
|-
| new_11-1.tmx.gz
| Snow Town, outdoor
|-
| new_12-1.tmx.gz
| Snow Cave
|-
| new_13-1.tmx.gz
| Snow Town, indoor
|-
| new_14-1.tmx.gz
| Woodland, southwest (Pink Mushroom Map)
|-
| new_15-1.tmx.gz
| Palm beach southwest of Tulimshar (transition to woodland)
|-
| new_16-1.tmx.gz
| Woodland, southeast (Fluffy Map, transition to desert)
|-
| new_17-1.tmx.gz
| Hermits Cave, level 2 (Lamp snake cave)
|}

== How to map ==

When you want to make maps for tmw but you don't know how to start, read the [[Mapping Tutorial]].

== Ideas for new maps ==

I suggest a village in the woods. You know, elders and shops. And tales about what
is lurking within. And more quests.

== Errors on existing maps ==

If you encounter a map error, big or small, please add it to this list so that eventually a mapper can pick it up and include it the next time the map gets updated. Also feel free to add suggestions.

Grey errors have been fixed but the fixed map file has not been released yet.

==== The desert area below town (1-1) ====

(no bugs reported in the current version)

==== Tulimshar (3-1) ====

* The large empty area at 44,34 in new_3-1 is reserved for the city's "palace", but we need a tile artist to start drawing the necessary tiles for this.

==== Desert Cave Level 2 (5-1) ====

(no bugs reported in current version)

==== The Eastern Desert (?) (7-1) ====

* Contains 2 cave entrances that lead to yet to determine caves.
* Exit to the south east determined?

==== Casino (8-1) ====

just this: http://img129.imageshack.us/img129/6658/casinobugih7.png

==== Woodland (9-1) ====

One picture is worth a thousand words: [[Image:Woodland_bug.png|100px]]

==== Snow Field ====

This tile here is soild (and also the wrong tile) 
http://i97.photobucket.com/albums/l231/QOAL/snow_field_map_error.png

==== Bat Cave ====

(no bugs reported in the current version)

==== Snow town ====

There is an error on the map as shown on the picture. 
A few of the rock face edge tiles are walk through with the soild tiles as the next tile. 
http://i97.photobucket.com/albums/l231/QOAL/ice_village_map_error.png

Classic:Maps

2006-10-17T16:20:14Z

Modanung: Reverted spam edit by Moira

{{Status_green}}
== Guidelines ==

You can build a map for TMW using [http://mapeditor.org Tiled]

* '''Size:''' around 200x200 tiles is good in practice, though the theoretical maximum is 2048x2048
* '''Tile size:''' 32x32
* '''Map border:''' you have to leave an empty border around the map of at least 20 tiles
* '''Walls/players proportions:''' a normal door for a player is 2 tiles in height
* '''Indoor/Outdoor proportions:''' it is not required that inside view of buildings has to fit the size in outside view
* '''Path reference:''' please use tmw folder structure to keep references to tilesets working
* '''Transparent color:''' tilesets use alpha so no need to set a transparent color
* '''Layers:''' each map uses 4 layers: ground, objects, over and collision (names are only suggested)
** ''Ground:'' used for everything below items and beings.
** ''Objects:'' this layer is drawn simultaneously with items and beings, where tiles above a being are drawn below the being and tiles below the being are drawn above. Hence this layer is suitable for adding static objects to a map like plants or statues.
** ''Over:'' usually used for walls or high objects. Each tile in this layer is always above items and beings.
** ''Collision:'' this is a special layer for which you have to use the collision tileset. Use the 'X' tile where you want a tile to be unwalkable. Be careful that even if a tile is not reachable, but it's walkable, the server can spawn monsters there, so you won't be able to reach them, or you can cause weird situations. For example fill a wall with 'X' tiles, not only the borders, or you could have monsters spawning inside the wall.

In a good style of mapping, please always use the lowest layer as possible (this is also in the interests of perfomance, since it keeps down overdraw).

== How to map ==

When you want to make maps for tmw but you don't know how to start, read the [[Mapping Tutorial]].

== Ideas for new maps ==

I suggest a village in the woods. You know, elders and shops. And tales about what
is lurking within. And more quests.

== Errors on existing maps ==

If you encounter a map error, big or small, please add it to this list so that eventually a mapper can pick it up and include it the next time the map gets updated. Also feel free to add suggestions.

Grey errors have been fixed but the fixed map file has not been released yet.

==== The desert area below town (1-1) ====

(no bugs reported in the current version)

==== Tulimshar (3-1) ====

* The large empty area at 44,34 in new_3-1 is reserved for the city's "palace", but we need a tile artist to start drawing the necessary tiles for this.

==== Desert Cave Level 2 (5-1) ====

(no bugs reported in current version)

==== The Eastern Desert (?) (7-1) ====

* Contains 2 cave entrances that lead to yet to determine caves.
* Exit to the south east determined?

==== Casino (8-1) ====

just this: http://img129.imageshack.us/img129/6658/casinobugih7.png

==== Woodland (9-1) ====

One picture is worth a thousand words: [[Image:Woodland_bug.png|100px]]

==== Snow Field ====

This tile here is soild (and also the wrong tile) 
http://i97.photobucket.com/albums/l231/QOAL/snow_field_map_error.png

==== Bat Cave ====

(no bugs reported in the current version)

==== Snow town ====

There is an error on the map as shown on the picture. 
A few of the rock face edge tiles are walk through with the soild tiles as the next tile. 
http://i97.photobucket.com/albums/l231/QOAL/ice_village_map_error.png

Kingdoms

2006-09-19T17:58:27Z

Modanung: /* Water race homeland; underwater or on the surface? */

{{Status_construction|come to the IRC channel #tmwart on irc.freenode.net}}
== Regions ==

===Homelands of the Races===
It should be assumed that the eight, single-element races will have a crystal located somewhere in the heart of thier native lands. They have all in their own way, taken up retainership to these crystals, which are now much smaller than they originally had been; the countless shards are scattered throughout the world.

{| border="0" cellspacing="0" cellpadding="5" width="100%"
! style="background:#efdead;" align="left" | Region
! style="background:#efdead;" align="left" | Terrain
! style="background:#efdead;" align="left" | Native race
! style="background:#efdead;" align="left" | Regional element
! style="background:#efdead;" align="left" | Description
|-
| Tulimshar
| Desert
| Demon
| N/A
| The great desert of Tulimshar is the largest in the world, serving as natural protection from most invaders. These harsh conditions also make life in the Tulimshar area quite challenging, for outsiders and natives alike.
|-
| ''--comments--''
| Tundra
| Human
| N/A
| Home of the humans
|-
| --
| --
| ''--comments--''
| Space
| --
|-
| --
| Wasteland, ancient Junkyard
| Chelonan
| Time
| A conglomeration of barren land and broken machinery.
|-
| --
| Caverns
| Talpan
| Earth
| A maze of caverns and open valleys through the southeast mountains.
|-
| --
| Above the clouds?
| Daedalon
| Light
| A place where land meets sky in an isolated setting, surrounded by a sea of clouds; A resort village / tourism should be their primary economic hinge.
|-
| --
| --
| ''--comments--''
| Darkness
| --
|-
| --
| Volcanic Plain
| Ifriton
| Fire
| A large plain with lava rivers and lakes, small volcanos and basalt cliffs.
|-
| --
| Underwater ''(--comments--)''
| Tritan
| Water
| --
|-
| --
| Canyon w/windy chasm
| Sparron
| Air
| --
|}

== old location / region names & descriptions ==
Please consider when viewing this and the following 'Landforms' sections, how incompatible most ideas are with the current [[Backstory]] and with the map in progress, by Pauan. In short, this is here for retrospective. We want to salvage what we can from these original ideas from the [[World backstory proposal 1|old story concept]].
===Other regions===
{| border="0" cellspacing="0" cellpadding="5" width="100%"
! style="background:#efdead;" align="left" | Region
! style="background:#efdead;" align="left" | Terrain
! style="background:#efdead;" align="left" | Key Locations
! style="background:#efdead;" align="left" | Description
|-
| [[Gispaa Island]]
| Volcano Island
| Crystal of Fire
| A small volcanic island.
|-
| [[Sonbrand]]
| Urbanized Island
| Great Library
| Island of Scholars
|-
| [[Frenshya Plains]]
| Plains
|
| A well watered plain between the Kaisei River and the southern seas. Mostly farmland or pastures.
|-
| [[Xartune]]
| Forests, Meadows
| [[Shimris]], [[Macabre]], [[Woodland Village]]
| An overgrown jungle continent to the northwest
|-
| [[KaziKazi]]
| Tundra
| [[Gloriana]], [[Desert of Glass]]
| KaziKazi is the coldest and most unforgiving terrain in the Mana world.
|-
| [[Gasaro]]
| Grassland, Canyons
|
| A region to the south upon the island of the same name. Gasaro is for a large part empty grasslands, spotted with some canyons and dunes.
|-
| [[Gaeas Hearth]]
| Jungle
|
| At the heart of the world, a dense bastion of mana energy.
|}

== Landforms ==
Center: 
* None. 
 North: 
* [[Sea of Dissonance]] - A perpetual, powerful ocean current combined with deadly shoals make this northern sea almost intraversable.
* [[Gloriana]] - A northern continent of snow and ice. Only inhabited by nomads.
North-east: 
* None.
North-west: 
* [[Motetshi]] - The last unexplored continent, due to its place beyond a number of harsh shoals and the [Sea of Dissonance].
* [[Amplar Deadlands]] - A large, poisonous muck on the edge of [[Motetshi]]. Another deterrent to tourists of the region.
* [[Moori Isthmus]] - A tiny land bridge that connects [[Xartune]] to [[The Great Continent]]. 
 South: 
* [[Sea of Abbana]] - connects to port city of Abanna to the rest of its neighbors via ocean.
* [[OsiruSea]] - A small body of water that separates the island of [Gasaro] from the rest of [[The Great Continent]].
* [[Merene Archipelago]] - A collection of nearly 100 small islands in the southern [[Sea of Abbana]].
South-east: 
* None.
South-west: 
* None. 
 East: 
* None. 
 West: 
* [[Kaisei River]] - A river flowing west from the mountains near [GeonsCrater] to the [[Sea of Abbana]] and the [[Sea of Dissonance]].
* [[Kaisei River Delta]] - An outlet of the Kaisei River that forms a large marsh. An ancient civilization thrived here which is believed to be a precursor to the civilization at [[Tulimshar]]. 
 Anywhere: (not categorized) 
* [[Gispaa Island]] - A small volcanic island, upon which the [[Temple of Fire]] sits.
* [[Blachet Sea]] - The sea beneath Aerol, usually a calm one.
* [[Collis Forest]] - A large deciduous forest that separates [[Shaede]] from the rest of [[The Great Continent]].
* [[Ivari Sea]] - The sea surrounding Veshrin. Filled with pirates and dangerous storms, due to its proximity with the [[Sea of Dissonance]].
* [[Issa Marsh]] - A marsh at the edge of [[Collis Forest]]. Valuable and interesting wildlife thrives there, but the terrain is treacherous.

[[Sea of Dissonance]], [[Motetshi]], [[Amplar Deadlands]], [[Moori Isthmus]], [[Sea of Abbana]], [[OsiruSea]], [[Merene Archipelago]], [[Kaisei River]], [[Kaisei River Delta]], [[Gispaa Island]], [[Blachet Sea]], [[Collis Forest]], [[Ivari Sea]], [[Issa Marsh]], [[Collis Forest]], [[Astra]], [[Shaede]], [[Aerol]], [[Geons Crater]], [[Tempus Keshlam]], [[Tonori]], [[Gispaa Island]], [[Gaeas Hearth]], [[Gasaro]], [[KaziKazi]], [[Frenshya Plains]], [[Xartune]], [[Toukai]], [[Shimris]], [[Abbana]], [[Sonbrand]], [[Mudoha]], [[Macabre]], [[Woodland Village]], [[Gloriana]]

==Questions & Comments About New World Map==

===human homeland===
Dabe and Pauan discussed swapping demons to Tulimshar and humans to the "other" side of the continent, which is a snow region. This was mostly for graphical / environmental obviousness.. (red skin in snow would look dumb and it seems to fit the desert setting..) 

''Would anyone have any problems with this change?'' 
''If it's an acceptable change, what should we call the human's snow kingdom?'' 

'Gloriana' was already intended to be a snow region and I sort of like the name. My second choice, just because I like the name; 'Sonbrand' - [[User:Dabe|Dabe]] 23:57, 18 September 2006 (CEST)

===Water race homeland; underwater or on the surface?===
The issue of placing the Tritan raised a question about playability underwater. Though there are a number of ways we could implement something like this, the question remains, "Should the water race's homeland be submerged, requiring foreign race's to use a waterbreath ability/item of some kind..?" 

I vote for an underwater town of some sort, regardless of the diving / swimming method - [[User:Dabe|Dabe]] 00:16, 19 September 2006 (CEST) 

Surely underwater, accesible by e.g. swimming skill... --[[User:Yosuhara|Yosuhara]] 18:09, 19 September 2006 (CEST)

It would not be logical for a waterbreathing race to build a city under a dome filled with air. I think it should be reachable for both Tritans and non-Tritans. Therefor I think we should either have a land based Tritan homeland or SCUBA-gears (or something limilar). I would prefer the Tritan homeland to consist of a lot of island with walkable shallows for non-tritans and more direct swimming for Tritans and skilled swimmers. [[User:Modanung|Modanung]] 19:58, 19 September 2006 (CEST)

Development:Joining the project

2006-09-10T20:28:28Z

Modanung:

So you want to join this project, but you have little or no idea how to get into? The Mana World development team is not a closed circle like other projects. You needn't apply to anyone or ask for "being taken into the team". You don't have to ask for permission to work on something or wait for someone to assign a task to you. A team member is basically everyone who volunteers to do something for the project. We do have a quality standard, and will not add game content that isn't good enough to the teams opinion. Also it might be good first to ask what is needed and what is being worked on to prevent people from wasting their time.

This page should provide you with the necessary starting points. It can always be rather difficult to know what to start with, especially when you're just jumping in. However, any help is most welcome and with some time you should be able to decide what you want to work on yourself.

== General organisation ==

To know what is currently happening or what could be worked on, we have a few important pages on the wiki. The [[roadmap]] provides a planning for upcoming releases, where sometimes tasks are assigned or listed to be picked up by somebody. There is a [[bugs|bugs page]] holding a list of known problems which are generally free for anybody to look into. Finally there is the [[suggestions|suggestions page]] where anybody can put his wishlist for the game, and where anybody can look for inspiration when looking for something to do.

These pages and others are linked from the organisation section on the [[Main Page|main page]].

It is very important for you to be available for discussion with other developers on [http://forums.themanaworld.org/viewtopic.php?t=747 our IRC channels] from time to time, as we do most of our discussions there. We also have two important mailing lists, one for development discussion and one that shows all changes made to the source code, that you should subscribe to:

* http://lists.sourceforge.net/lists/listinfo/themanaworld-devel The developers mailing list where discussion about the project happens.
* http://lists.sourceforge.net/lists/listinfo/themanaworld-commit The commit mailing list, so that you can easily stay up to date about the latest change to the source code.

Finally, although not required, you are invited to visit our forums:

* http://forums.themanaworld.org/

== Programmers ==

Our current projects include the existing client which is used with eAthena (a Ragnarok Online server emulator), and a new client/server combination which isn't used yet but is being worked on. Hence, check out both the Subversion module <code>tmw</code> as the module <code>tmwserv</code>. Try to browse the source to see if you can get a bit familiar with them.

Your first contributions could be in the form of patches submitted to the SourceForge patches tracker. If it turns out you like the project and you want to keep contributing for a long period, we'll consider adding you to the official team and from then on you can commit your changes to the source yourself.

== Artists ==

Our graphic design team can always use help. May it be just an inventory icon, a [[Monsterset development|new monster]] or a [[Tileset development|complete Tileset]]. Improving existing graphics is also always welcome. When you want to do a task, then you should announce it on the [http://forums.themanaworld.org/viewforum.php?f=8 Graphic Development Forum], post regular updates there and add yourself to the [[Assignments]] Page. But be sure to read our [[Guidelines|style guidelines]] first.

You should also hang out on our graphic design channel #tmwart [http://forums.themanaworld.org/viewtopic.php?t=747]. It is good for a little brainstorming session or for showing small pieces of work you don't want to show to the whole community yet.

== Mappers ==

Creating maps is a task that does not require much experience but is a great way to add more value to the game. More information about how to map can be found on the article [[Mapping Tutorial]]. Be sure to check out our [[Map development|Map development guidelines]], too.

File:Tmw races.png

2006-09-10T15:13:08Z

Modanung: The races for the Mana World as fitting the world's backstory. By 'Modanung'

The races for the Mana World as fitting the world's backstory. By 'Modanung'

Classic:Maps

2006-08-15T22:34:37Z

Modanung: My name is inferior in this case

{{Status_green}}
== Guidelines ==

You can build a map for TMW using [http://tiled.rpgdx.net Tiled]

* '''Size:''' around 200x200 tiles is good in practice, though the theoretical maximum is 2048x2048
* '''Tile size:''' 32x32
* '''Map border:''' you have to leave an empty border around the map of at least 20 tiles
* '''Walls/players proportions:''' a normal door for a player is 2 tiles in height
* '''Indoor/Outdoor proportions:''' it is not required that inside view of buildings has to fit the size in outside view
* '''Path reference:''' please use tmw folder structure to keep references to tilesets working
* '''Transparent color:''' tilesets use alpha so no need to set a transparent color
* '''Layers:''' each map uses 4 layers: ground, objects, over and collision (names are only suggested)
** ''Ground:'' used for everything below items and beings.
** ''Objects:'' this layer is drawn simultaneously with items and beings, where tiles above a being are drawn below the being and tiles below the being are drawn above. Hence this layer is suitable for adding static objects to a map like plants or statues.
** ''Over:'' usually used for walls or high objects. Each tile in this layer is always above items and beings.
** ''Collision:'' this is a special layer for which you have to use the collision tileset. Use the 'X' tile where you want a tile to be unwalkable. Be careful that even if a tile is not reachable, but it's walkable, the server can spawn monsters there, so you won't be able to reach them, or you can cause weird situations. For example fill a wall with 'X' tiles, not only the borders, or you could have monsters spawning inside the wall.
* TMW doesn't support layer data compression, so disable it in Tiled: Edit -> Preferences -> Saving -> Compress layer data should not be checked

In a good style of mapping, please always use the lowest layer as possible (this is also in the interests of perfomance, since it keeps down overdraw).

== How to map ==

When you want to make maps for tmw but you don't know how to start, read the [[Mapping Tutorial]].

== Ideas for new maps ==

I suggest a village in the woods. You know, elders and shops. And tales about what
is lurking within. And more quests.

== Errors on existing maps ==

If you encounter a map error, big or small, please add it to this list so that eventually a mapper can pick it up and include it the next time the map gets updated. Also feel free to add suggestions.

Grey errors have been fixed but the fixed map file has not been released yet.

==== The desert area below town (1-1) ====

(no bugs reported in the current version)

==== Tulimshar (3-1) ====

* The large empty area at 44,34 in new_3-1 is reserved for the city's "palace", but we need a tile artist to start drawing the necessary tiles for this.

==== Desert Cave Level 2 (5-1) ====


* [45:31] Tile incorrectly not covering sprites
* [59:89] Tile incorrectly covering sprites
* [85:65] Monsters sometimes appear/walk on the lake near

==== The Eastern Desert (?) (7-1) ====

* Contains 2 cave entrances that lead to yet to determine caves.
* Exit to the south east determined?

==== Casino (8-1) ====

just this: http://img129.imageshack.us/img129/6658/casinobugih7.png

==== Woodland (9-1) ====

One picture is worth a thousand words: [[Image:Woodland_bug.png|100px]]

==== Snow Field ====

(no bugs reported in the current version)

==== Bat Cave ====

(no bugs reported in the current version)

==== Snow town ====

You can walk on the roof at [64,70] (This is already fixed in SVN)

Classic:Maps

2006-08-15T17:36:39Z

Modanung: Map bug already fixed

{{Status_green}}
== Guidelines ==

You can build a map for TMW using [http://tiled.rpgdx.net Tiled]

* '''Size:''' around 200x200 tiles is good in practice, though the theoretical maximum is 2048x2048
* '''Tile size:''' 32x32
* '''Map border:''' you have to leave an empty border around the map of at least 20 tiles
* '''Walls/players proportions:''' a normal door for a player is 2 tiles in height
* '''Indoor/Outdoor proportions:''' it is not required that inside view of buildings has to fit the size in outside view
* '''Path reference:''' please use tmw folder structure to keep references to tilesets working
* '''Transparent color:''' tilesets use alpha so no need to set a transparent color
* '''Layers:''' each map uses 4 layers: ground, objects, over and collision (names are only suggested)
** ''Ground:'' used for everything below items and beings.
** ''Objects:'' this layer is drawn simultaneously with items and beings, where tiles above a being are drawn below the being and tiles below the being are drawn above. Hence this layer is suitable for adding static objects to a map like plants or statues.
** ''Over:'' usually used for walls or high objects. Each tile in this layer is always above items and beings.
** ''Collision:'' this is a special layer for which you have to use the collision tileset. Use the 'X' tile where you want a tile to be unwalkable. Be careful that even if a tile is not reachable, but it's walkable, the server can spawn monsters there, so you won't be able to reach them, or you can cause weird situations. For example fill a wall with 'X' tiles, not only the borders, or you could have monsters spawning inside the wall.
* TMW doesn't support layer data compression, so disable it in Tiled: Edit -> Preferences -> Saving -> Compress layer data should not be checked

In a good style of mapping, please always use the lowest layer as possible (this is also in the interests of perfomance, since it keeps down overdraw).

== How to map ==

When you want to make maps for tmw but you don't know how to start, read the [[Mapping Tutorial]].

== Ideas for new maps ==

I suggest a village in the woods. You know, elders and shops. And tales about what
is lurking within. And more quests.

== Errors on existing maps ==

If you encounter a map error, big or small, please add it to this list so that eventually a mapper can pick it up and include it the next time the map gets updated. Also feel free to add suggestions.

Grey errors have been fixed but the fixed map file has not been released yet.

==== The desert area below town (1-1) ====

(no bugs reported in the current version)

==== Tulimshar (3-1) ====

* The large empty area at 44,34 in new_3-1 is reserved for the city's "palace", but we need a tile artist to start drawing the necessary tiles for this.

==== Desert Cave Level 2 (5-1) ====


* [45:31] Tile incorrectly not covering sprites
* [59:89] Tile incorrectly covering sprites
* [85:65] Monsters sometimes appear/walk on the lake near

==== The Eastern Desert (?) (7-1) ====

* Contains 2 cave entrances that lead to yet to determine caves.
* Exit to the south east determined?

==== Casino (8-1) ====

just this: http://img129.imageshack.us/img129/6658/casinobugih7.png

==== Woodland (9-1) ====

One picture is worth a thousand words: [[Image:Woodland_bug.png|100px]]

==== Snow Field ====

(no bugs reported in the current version)

==== Bat Cave ====

(no bugs reported in the current version)

==== Snow town ====

You can walk on the roof at [64,70] (This is already fixed in SVN. [[User:Modanung|Modanung]] 19:36, 15 August 2006 (CEST))

User talk:HABARI

2006-08-08T13:54:50Z

Modanung: *sigh* Wiki noobs

When editing the wiki you can use the preview button to see the result of your changes without comitting them.

Player Groups

2006-08-07T11:56:25Z

Modanung: Did a little style cleanup

Please, try not to be chaotic when editing, try to keep the format, and don't create derived articles for your guilds. Here you have enough space to make your guilds. --[[User:Pajarico|Pajarico]] 11:01, 23 July 2006 (CEST)

== MUG (Macintosh Users Guild) ==
* Leader: TencheDesign (Not Tenche anymore)
* Lafaboune-G5
* godHead-G5
* Pudri-G4
* Criptos - G4
* Trucker-G3

== Grey Mana ==
Announcing the new clan "Grey Mana". Its members so far are:
* Leader: Dfert (soon to be DeathJoker but it will still be me)
* Moi1392-Knight
* Vally8-Knight
* Edix-knight
* Sanjd-Ranger
* Pete-Marksman
* Medicated-Wonderer
* Vince Armoire-Knight
* Yanl-Barbarian
* Shouto-Swordsmen

There are a number of brave men that the Grey Mana will give our respect to: Gorch, the entire MUG guild and any of the admins.

The perks of this clan are: inter guild loans and the support of anyone in the guild.

Ther Rules of conduct are:
* Any guild member must be respectfull to ANY person as long as they do not disrespect the clan or its members. OR is a member of an opposing clan (none yet).
* There will be no tolerence to member that refuse to help other clan member.
* We Will remain peacefull unless our services are requested and a reward is offerded.

Would love to join the Grey Mana Name- Haggar Level- 25 send me a message if im able to.

== The Elders Council ==
The first created guild on The Mana World. You must have been playing for at least 4 versions of The Mana World in order to join. PM Magick to register.
* Leader-Magick

== Teh Masonaries ==
* Leaders: Teh Akroh and Deviexx

== THE MANA WARRIORS ==

'''Our duty is to protect the Mana World from evil'''

===Rules===
*Be respectful to other ones
*Figth when ever posible to win level
*Help other players
*Answer when you are called
*Help other members when figthing against monsters
*Attack the ones that are not respectful with other players
*Encourage other ones to join us
*Say you are one of us when you log on
*Respect people with a higher level
*So far we have no enemies to destroy

===How to join the Mana Warriors===

*'''Anyone''' can join the clan
*Just follow the rules and you can be one of us
*Put your name on the member list

===More info===
*We have a meeting point next to the miners , our warriors can join there when wanting to talk to other warrior for help or advice.
* We will do the best we can to help other warriors.

===Members===
*JAMBO
*HABARI
*HABARI 2
*yomatsu
*smolik
*Tobias
*ellokofonker (Tole)
*Valquiria
*Shandokan
*Longshot
*maximus
*MiRz

Main Page

2006-08-05T12:17:38Z

Modanung: Added races page

{| cellspacing="3" cellpadding="5" width="100%"
|colspan="2" style="border: 1px solid lightgrey;"|
{| cellspacing="0" cellpadding="0"
| style="vertical-align: center; text-align: center; padding: 0px 20px 0px 20px; font-style: italic;"|Welcome to The Mana World wiki! This wiki is meant to provide information to our players, to provide an easy way to contribute to the development of certain parts of the game and to improve collaboration between people on the development team. We hope you will find what you are looking for. To be able to edit you have to login, but signing up is free and requires no activation.
|[[Image:World_sketch_by_Kyokai.jpg|100px]]
|}
|- valign="top"
|width="50%" style="border: 1px solid #e0c8b8; color: #000; background-color: #faeee6"|
== Project information ==
* [[Project description]]
* [[Screenshots]]
* [[Getting started]]
* [[Developers]]
* [[FAQ]]
* [[Dependencies]]
* [[System requirements]]
* [[Roadmap]]
* [[Ports]]
* [http://svn.sourceforge.net/viewcvs.cgi/themanaworld/tmw/trunk/ChangeLog?view=markup ChangeLog from SVN trunk]

==== References ====

* [[Servers]]
* [[Guilds]]
* [[Stats]]
* [[Monster reference]]
* [[Item reference]]

==== Organization ====

* [[Suggestions]]
* [[Bugs]]
* [[Design document]]
* [http://themanaworld.org/archive/galerie.php Gallery]
* [[Developer meetings]]
* [[Quotes]]
* [[Summer 2005 real life developer meeting]]

|width="50%" style="border: 1px solid #c9c9ff; color: #000; background-color: #f3f3ff"|
== Development ==

'''World'''
:[[World geography]], [[World backstory]], [[Organisations]], [[Races]]

'''Game'''
:[[Game systems]], [[Map development]], [[NPC development]], [[Important NPCs]], [[Finished NPCs]], [[Creature proposal]]

'''Graphics''' ([[:Special:Newimages|New images gallery]])
:[[Assignments]], [[Concept art]], [[Guidelines]], [[Tileset development|Tilesets]], [[Playerset]], [[Itemset development|Itemsets]], [[Monsterset development|Monstersets]]

'''GUI / Interface'''
:[[GUI development]], [[Menu interface system]], [[Keyboard usage]]

'''Sound'''
:[[SFX]], [[Music]]

'''Server'''
:[[Server development]]

'''RFCs'''
:[[Rendering]], [[Action layers]], [[Animations]], [[Improvement of the collision layer system]], [[Being movement system]], [[Logging]]

'''General'''
:[[Joining the project]], [[Making a new release]]

|}
__NOTOC__ __NOEDITSECTION__

Development:Animations

2006-08-04T00:27:52Z

Modanung: Added gender variable

{{Status_yellow}}

Each animation will be defined by an xml document, here follows an example:

<pre>
<sprite name="player" action="stand">

<imageset name="base" src="graphics/sprites/player_male_base.png" width="64" height="64" />

<action name="stand" imageset="base">
<animation direction="down">
<frame index="0" />
</animation>
<animation direction="left">
<frame index="18" />
</animation>
<animation direction="up">
<frame index="36" />
</animation>
<animation direction="right">
<frame index="54" />
</animation>
</action>

<action name="walk" imageset="base">
<animation direction="down">
<frame index="1" delay="50" />
<frame index="2" delay="50" />
<frame index="3" delay="50" />
<frame index="4" delay="50" />
<frame index="5" delay="50" />
<frame index="6" delay="50" />
</animation>
<animation direction="left">
<sequence start="19" end="24" delay="50" />
</animation>
<animation direction="up">
<sequence start="37" end="42" delay="50" />
</animation>
<animation direction="right">
<sequence start="55" end="60" delay="50" />
</animation>
</action>

<action name="sit" imageset="base">
<animation direction="down">
<frame index="7" />
</animation>
<animation direction="left">
<frame index="25" />
</animation>
<animation direction="up">
<frame index="43" />
</animation>
<animation direction="right">
<frame index="61" />
</animation>
</action>

<action name="dead" imageset="base">
<animation direction="down">
<frame index="8" />
</animation>
<animation direction="left">
<frame index="26" />
</animation>
<animation direction="up">
<frame index="44" />
</animation>
<animation direction="right">
<frame index="62" />
</animation>
</action>

<action name="attack" imageset="base">
<animation direction="down">
<sequence start="9" end="12" delay="100" />
</animation>
<animation direction="left">
<sequence start="27" end="30" delay="100" />
</animation>
<animation direction="up">
<sequence start="45" end="48" delay="100" />
</animation>
<animation direction="right">
<sequence start="63" end="66" delay="100" />
</animation>
</action>

</sprite>
</pre>

So if you want to load the playerset you just load player.xml and it takes care of loading all related images. Of course delays are defined in milliseconds.

== Specifications ==

=== <sprite> ===
A sprite is an object which can carry several animations, hence we call the root element the <code>sprite</code>. The sprite got two optional properties <code>variants</code> and <code>variant_offset</code>. These are required when there are multiple very similar versions of a sprite in one spriteset. One example for this are the hairset spritesets. <code>variants</code> defines the number of variants in the spriteset and <code>variant_offset</code> how many sprites are between the first sprites of the variants. When defining multiple variants you only define the animation sequences of the first variant. the engine then shifts the index parameters when it wants anotherone.

=== <action> ===
collection of the animation in different directions that belong to an action the character can perform. the properties are the imageset the animation phases are taken from and the name of the action.

possible names:
<pre>
use-item
|
attack-bow cast-magic
| |
attack-stab attack-throw
\ /
run attack-swing sleeping dead
| | | |
walk attack sit hurt
\ \ / /
stand
|
(no name attribute)
</pre>

this table also specifies the substitution precedence. when a specific name is requested but it is not defined the next lower name is used instead.

=== <animation> ===
Defines an animation sequence that should be displayed when the sprite object faces in a specific direction (attribute "direction").

the possible directions are:
<pre>
up
down
left
right
</pre>

when a specific direction isn't provided, the first defined direction is used instead. this can be overridden by defining an animation with the direction "default" for this action.

Every <code><animation></code> has one or more <code>frame</code> or <code>sequence</code> child elements.

=== <frame> ===

each of them defines one frame of the animation. the required properties are <code>index</code> and optional <code>offsetX</code>, <code>offsetY</code> and <code>delay</code>.

<code>index</code> defines the index of the graphic on the spriteset.

an optional property is <code>delay</code>. every frame is displayed for <code>delay</code> millisecounds and then replaced by the next frame in sequence. when the last frame is reached the sequence starts with the first frame again. when no delay is specified (or specified as "0") the animation doesn't continue when this <code>frame</code> is reached.

Each <code>frame</code> element can optionally have the properties <code>offsetX</code> and <code>offsetY</code> to specify an offset from the default drawing position for that frame. This allows the animation of for example the hairset (or any equipment) to reuse the same frames with different offsets.

=== <sequence> ===
<code>sequence</code> tag does not only define one animation phase but multiple phases. Its properties are <code>delay</code>, <code>start</code> and <code>end</code> which are all required. The delay is the delay in ms between each phase. the properties <code>start</code> and <code>end</code> define the first and the last index of the animation sequence on the spritesheet.

== Suggested additions ==

=== multiple delays in a <frame> with start and end attribute ===
in the bow animation I've chosen a shortcut to specify different delays for different frames. I am undecided yet whether this is a nice feature or whether it'll be better to require multiple <code>frame</code> elements in such cases.

=== <random> childtag for <animation> ===
Also, it includes an experimental suggestion on specifying that a random frame should be chosen. This should also have an exclude_current_frame thingy, to make sure a frame isn't shown twice or more in a row. Sometimes this may be wanted though.

=== sequences based on default sequences ===
After reflecting on this idea (and the above suggestion) I think a first issue to solve is to reduce the amount of duplicated definitions. For example, at the moment every monster uses the exact same frame size and animation frames. Hence, it would be interesting if the defined sprite could take the actual imageset it uses as a parameter instead of specifying this on its own. This way we can define a monster like:

<pre>
<sprite name="monster-walking-default">
<imageset name="base" />
...
</sprite>

<being name="Scorpion">
<sprite ref="monster-walking-default">
<with-imageset name="base" src="scorpion-base.png" width="60" height="60" />
</sprite>
</being>

<being name="Red Scorpion">
<sprite ref="monster-walking-default">
<with-imageset name="base" src="scorpion-red-base.png" width="60" height="60" />
</sprite>
</being>
</pre>

Defining an empty imageset (without <code>src</code> attribute) will make the engine require this imageset to be passed as a parameter whenever the spriteset is referenced.

I'm not convinced yet that the <code>name</code> attribute of the <code>sprite</code> element is really necessary. I think I would prefer each sprite to be defined in its own file. However it could be attractive to define multiple things in the same file, but in that case I think we will have to read everything when the client is launched, and only graphics and imagesets can be created lazily (only when necessary). Because the other data consists of just numbers and strings, this should not be really a problem.

== Implementation proposal of hairstyles by Modanung ==

I think the current system with an xml file for every hairstyle with an index and offset defined for every frame is a bit too much. It also takes a lot of work to correct small errors and to add new hairstyles that may have a different frame size and with it a different offset.
I suggest we split hairstyles up in three catagories:
* Static hairstyles
* Standard animated hairstyles
* Special case hairstyles
On top of the current system we need a variable that defines which gender can use which hairstyles, in every hairstyle's xml-file.
===Static hairstyles===
These are hairstyles which only have one frame for each direction and death, so five. All current hairstyles would be static hairstyles. Every individual static hairstyle needs nothing more to be defined then their bitmap, their size and their offset for each direction.
The offset for each seperate frame would be defined in a shared file (say hairoffsets.xml), this summed with the individual hairstyle's offset is the offset for that single frame with that hairstyle.
<pre>
hairstyle1.xml
<offsetfile="hairoffsets.xml", framefile="static_hairstyles_frames.xml">
<sprite variants="10" variant_offset="5">
<gender="male">

<imageset name="base" src="graphics/sprites/hairstyle1.png" width="40" height="40" />
<offsetX="0" offsetY ="0" />

End of file
</pre>

<pre>
hairoffsets.xml

<action name="stand" imageset="base">
<animation direction="down">
<offsetX="0" offsetY ="-29" />
</animation>
<animation direction="left">
<offsetX="-1" offsetY ="-29"/>
</animation>
<animation direction="up">
<offsetX="-1" offsetY ="-25"/>
</animation>
<animation direction="right">
<offsetX="1" offsetY ="-29"/>
</animation>
</action>

<action name="walk" imageset="base">
<animation direction="down">
<offsetX="0" offsetY ="-28" delay="75"/>
<offsetX="0" offsetY ="-29" delay="75" />
<offsetX="0" offsetY ="-29" delay="75" />
<offsetX="0" offsetY ="-28" delay="75" />
<offsetX="0" offsetY ="-29" delay="75" />
<offsetX="0" offsetY ="-29" delay="75" />
</animation>
...etc...
</pre>
<pre>
static_hairstyles_frames.xml

<animation direction="down">
<frame index="0" />
</animation>
<animation direction="left">
<frame index="1" />
</animation>
<animation direction="up">
<frame index="2" />
</animation>
<animation direction="right">
<frame index="3" />
</animation>

<action name="dead" imageset="base">
<animation direction="default">
<frame index="4"/>
</animation>
End of file
</pre>
===Standard animated hairstyles===
These are hairstyles that can be compared with hair in SoM or Chrono Trigger, they move as you walk and attack. They have three frames for each direction and death, so thirteen frames all together. These three frames can be devided in a relaxed frame and two extremes. Those two extremes either being up and down or left and right, depending on the hair style. A heavily greased Evil look would wobble up and down as you walk and a pony talk would wave from left to right.
Standard animated hairstyles hairstyles use the same offset as static ones only they have a different file for defining the frames.
<pre>
hairstyle2.xml
<offsetfile="hairoffsets.xml", framefile="animated_hairstyles_frames.xml">
<sprite variants="10" variant_offset="13">
<gender="both">

<imageset name="base" src="graphics/sprites/hairstyle2.png" width="40" height="40" />
<offsetX="0" offsetY ="0" />

End of file
</pre>
<pre>
animated_hairstyles_frames.xml

<action name="stand" imageset="base">
<animation direction="down">
<frame index="0" />
</animation>
<animation direction="left">
<frame index="3" />
</animation>
<animation direction="up">
<frame index="6" />
</animation>
<animation direction="right">
<frame index="9" />
</animation>
</action>

<action name="walk" imageset="base">
<animation direction="down">
<frame index="0" delay="75"/>
<frame index="1" delay="75" />
<frame index="1" delay="75" />
<frame index="0" delay="75" />
<frame index="2" delay="75" />
<frame index="2" delay="75" />
</animation>
...etc...
</pre>
===Special case hairstyles===
And then there are the odd ones, the hairstyles that need a little more freedom. Hairstyles that people want to make wave in the wind, even when the player stands still. Or a birdnest hairstyle with nestlings that constantly open and close their mouth in a random frequency nomatter what you do. I'll take as example a Medusa hairstyle.
<pre>
hairstyle3.xml
<offsetfile="hairoffsets.xml", framefile=0>
<sprite variants="10" variant_offset="13">
<gender="female">
<imageset name="base" src="graphics/sprites/hairstyle3.png" width="50" height="60" />
<offsetX="-5" offsetY ="-10" />

<animation direction="down">
<frame index="0" delay="100"/>
<frame index="1" delay="100"/>
<frame index="2" delay="100"/>
</animation>
<animation direction="left">
<frame index="3" delay="100"/>
<frame index="4" delay="100"/>
<frame index="5" delay="100"/>
</animation>
<animation direction="up">
<frame index="6" delay="100"/>
<frame index="7" delay="100"/>
<frame index="8" delay="100"/>
</animation>
<animation direction="right">
<frame index="9" delay="100"/>
<frame index="10" delay="100"/>
<frame index="11" delay="100"/>
</animation>

<action name="dead" imageset="base">
<animation direction="default">
<frame index="12"/>
</animation>

End of file
</pre>
This hairstyle showes a bunch of snakes on your head that always wave 'n wobble unless you're dead. The animation rolls asychronusly with the attack and walking animations and it also moves when you stand still. But the offsets are in sync. Special hairstyles might also use their own offsets ofcourse
I think this pretty much finished my proposal.

Development:Animations

2006-07-22T13:00:02Z

Modanung: /* Special case hairstyles */

{{Status_yellow}}

Each animation will be defined by an xml document, here follows an example:

<pre>
<sprite name="player" action="stand">

<imageset name="base" src="graphics/sprites/player_male_base.png" width="64" height="64" />

<action name="stand" imageset="base">
<animation direction="down">
<frame index="0" />
</animation>
<animation direction="left">
<frame index="18" />
</animation>
<animation direction="up">
<frame index="36" />
</animation>
<animation direction="right">
<frame index="54" />
</animation>
</action>

<action name="walk" imageset="base">
<animation direction="down">
<frame index="1" delay="50" />
<frame index="2" delay="50" />
<frame index="3" delay="50" />
<frame index="4" delay="50" />
<frame index="5" delay="50" />
<frame index="6" delay="50" />
</animation>
<animation direction="left">
<sequence start="19" end="24" delay="50" />
</animation>
<animation direction="up">
<sequence start="37" end="42" delay="50" />
</animation>
<animation direction="right">
<sequence start="55" end="60" delay="50" />
</animation>
</action>

<action name="sit" imageset="base">
<animation direction="down">
<frame index="7" />
</animation>
<animation direction="left">
<frame index="25" />
</animation>
<animation direction="up">
<frame index="43" />
</animation>
<animation direction="right">
<frame index="61" />
</animation>
</action>

<action name="dead" imageset="base">
<animation direction="down">
<frame index="8" />
</animation>
<animation direction="left">
<frame index="26" />
</animation>
<animation direction="up">
<frame index="44" />
</animation>
<animation direction="right">
<frame index="62" />
</animation>
</action>

<action name="attack" imageset="base">
<animation direction="down">
<sequence start="9" end="12" delay="100" />
</animation>
<animation direction="left">
<sequence start="27" end="30" delay="100" />
</animation>
<animation direction="up">
<sequence start="45" end="48" delay="100" />
</animation>
<animation direction="right">
<sequence start="63" end="66" delay="100" />
</animation>
</action>

</sprite>
</pre>

So if you want to load the playerset you just load player.xml and it takes care of loading all related images. Of course delays are defined in milliseconds.

== Specifications ==

=== <sprite> ===
A sprite is an object which can carry several animations, hence we call the root element the <code>sprite</code>. The sprite got two optional properties <code>variants</code> and <code>variant_offset</code>. These are required when there are multiple very similar versions of a sprite in one spriteset. One example for this are the hairset spritesets. <code>variants</code> defines the number of variants in the spriteset and <code>variant_offset</code> how many sprites are between the first sprites of the variants. When defining multiple variants you only define the animation sequences of the first variant. the engine then shifts the index parameters when it wants anotherone.

=== <action> ===
collection of the animation in different directions that belong to an action the character can perform. the properties are the imageset the animation phases are taken from and the name of the action.

possible names:
<pre>
use-item
|
attack-bow cast-magic
| |
attack-stab attack-throw
\ /
run attack-swing sleeping dead
| | | |
walk attack sit hurt
\ \ / /
stand
|
(no name attribute)
</pre>

this table also specifies the substitution precedence. when a specific name is requested but it is not defined the next lower name is used instead.

=== <animation> ===
Defines an animation sequence that should be displayed when the sprite object faces in a specific direction (attribute "direction").

the possible directions are:
<pre>
up
down
left
right
</pre>

when a specific direction isn't provided, the first defined direction is used instead. this can be overridden by defining an animation with the direction "default" for this action.

Every <code><animation></code> has one or more <code>frame</code> or <code>sequence</code> child elements.

=== <frame> ===

each of them defines one frame of the animation. the required properties are <code>index</code> and optional <code>offsetX</code>, <code>offsetY</code> and <code>delay</code>.

<code>index</code> defines the index of the graphic on the spriteset.

an optional property is <code>delay</code>. every frame is displayed for <code>delay</code> millisecounds and then replaced by the next frame in sequence. when the last frame is reached the sequence starts with the first frame again. when no delay is specified (or specified as "0") the animation doesn't continue when this <code>frame</code> is reached.

Each <code>frame</code> element can optionally have the properties <code>offsetX</code> and <code>offsetY</code> to specify an offset from the default drawing position for that frame. This allows the animation of for example the hairset (or any equipment) to reuse the same frames with different offsets.

=== <sequence> ===
<code>sequence</code> tag does not only define one animation phase but multiple phases. Its properties are <code>delay</code>, <code>start</code> and <code>end</code> which are all required. The delay is the delay in ms between each phase. the properties <code>start</code> and <code>end</code> define the first and the last index of the animation sequence on the spritesheet.

== Suggested additions ==

=== multiple delays in a <frame> with start and end attribute ===
in the bow animation I've chosen a shortcut to specify different delays for different frames. I am undecided yet whether this is a nice feature or whether it'll be better to require multiple <code>frame</code> elements in such cases.

=== <random> childtag for <animation> ===
Also, it includes an experimental suggestion on specifying that a random frame should be chosen. This should also have an exclude_current_frame thingy, to make sure a frame isn't shown twice or more in a row. Sometimes this may be wanted though.

=== sequences based on default sequences ===
After reflecting on this idea (and the above suggestion) I think a first issue to solve is to reduce the amount of duplicated definitions. For example, at the moment every monster uses the exact same frame size and animation frames. Hence, it would be interesting if the defined sprite could take the actual imageset it uses as a parameter instead of specifying this on its own. This way we can define a monster like:

<pre>
<sprite name="monster-walking-default">
<imageset name="base" />
...
</sprite>

<being name="Scorpion">
<sprite ref="monster-walking-default">
<with-imageset name="base" src="scorpion-base.png" width="60" height="60" />
</sprite>
</being>

<being name="Red Scorpion">
<sprite ref="monster-walking-default">
<with-imageset name="base" src="scorpion-red-base.png" width="60" height="60" />
</sprite>
</being>
</pre>

Defining an empty imageset (without <code>src</code> attribute) will make the engine require this imageset to be passed as a parameter whenever the spriteset is referenced.

I'm not convinced yet that the <code>name</code> attribute of the <code>sprite</code> element is really necessary. I think I would prefer each sprite to be defined in its own file. However it could be attractive to define multiple things in the same file, but in that case I think we will have to read everything when the client is launched, and only graphics and imagesets can be created lazily (only when necessary). Because the other data consists of just numbers and strings, this should not be really a problem.

== An implementation idea by Peoro ==

An idea to manage the animations should be a class based on a timer which choose automatically the current frame.
Who needs animations (players, monsters and npcs) has only to start the animanion and to request the frame to draw it.
Each instance of Animation class keep its own start-time (or a personal timer), its total time, number of frames, and the time of every frame.
The Animation class has to provide at least a function to start the animation and another one to get the current frame; other usefull functions should pause and restart the animation and allow to jump to a random frame.

Here a simple example of a prototype of an Animation class:
(I mutilated my original Animation class to simplify and summarize it cutting a lot of other functions and vars and using the most possible of standard items)

<pre>
class Animation
{
int nframes;
Img **frames;
int *times;
int totalTime;
int startTime;

public:
Animation ( int n, Img **i, int *t )
{
int c;

nframes = n;
frames = new Img* [n];
times = new int [n];
totalTime = 0;

for ( c = 0; c < n; c ++ ) {
frames[c] = i[c];
times[c] = t[c];
totalTime += t[c];
}
}

inline void start ( int t = clock() )
{
startTime = t;
}

Img *getFrame ( int t = clock() )
{
int i;
int it

if ( ! totalTime ) {
t = 0;
} else {
t = (t-startTime) % totalTime;
}

// searches the current frame
for ( i = 0, it = 0; (it + times[i]) < t; i ++, it += times[i] );

return frames[i];
}

};
</pre>

And here how to use this class:

<pre>
Img * imgs [] = { img1, img2, img3 };
int times [] = { 20, 20, 30 };

Animation a ( 3, imgs, times );

a.start ( );

while ( 1 ) {
draw ( a.getFrame() );
}
</pre>

An advantage of this class is that the animation speed is indipendent to FPS and it's very easy to use.

This is a simple way to manage a lot of animations for who needs more than one:

<pre>
class AnimationsList
{
// ltstr is only a const char* comparison function
map<const char*, Animation*, ltstr> animations;
int startTime; // now Animation::startTime is no more usefull
Animation *currentAnimation;

public:
AnimationsList ( ) : currentAnimation(0) { }

inline void addAnimation ( const char *n, Animation *a )
{
animations[n] = a;
}

int setAnimation ( const char *n, int t = clock() )
{
map<const char*, Animation*, ltstr>::iterator ai;
Animation *a;

ai = animations.find ( n );

if ( ai == animations.end() ) {
// error... animation not found
return 0;
}
a = ai->second;

if ( currentAnimation != a ) {
a->start ( );
currentAnimation = a;
startTime = t;
}

return 1;
}

Img * getFrame ( )
{
if ( currentAnimation ) {
return currentAnimation->getFrame ( );
}
return 0;
}
};
</pre>

Using a multimap instead the map it's possible to keep more than an animation bind to the same string. This would be a good way to make AnimationsList choose a random animation.

And here how to use AnimationsList class:

<pre>
AnimationsList al;

al.addAnimation ( "walking" "south", anim1 );
al.addAnimation ( "walking" "north", anim2 );
al.addAnimation ( "anim3", anim3 );

al.setAnimation ( "walking" "south" );

while ( 1 ) {
draw ( al.getFrame() );
}
</pre>

I hope not to had make a mistake writing... Anyway these are only theorical bases.

== Implementation proposal by Doener ==

This proposal is incomplete regarding how new sequences are added to the
Animation (which is not the right name for this type of class *g*)... Anyway,
you should get the idea...
The Frame class encapsulates images and are used to create a single linked list that
creates an animation. The idea behind the linked list is that you can easily create loops,
by having the last element of the animation pointing to the first one. Also, you can easily
prepend a "starting animation" before the loop, like in an animation of a running player.
He starts out with one animation and then loops the real running... The Animation class is
responsible for mapping animation names to their starting frame and for disposing the encapsulating
Frame objects, thus a std::map and a std::list is used to keep track of those objects.
The next frame is simply calculated from the time that has passed since the last run of the
logic method. The case that a whole animation loop can be skipped is not taken into consideration,
because a) we cannot do this with frames linked together arbitrarily and b) animations will probably
take around 100ms or longer, ie. we'd have less than 10fps for that case to happen and then
there's nothing left to gain by that simple optimization anymore anyway ;)

For the linked list features, of course the xml format needs to be adjusted to support that.

<pre>
/*
* Frame class, stored information about frames in an animation
*/
struct Frame
{
Image *mImg; // Image for this frame
int mDelay; // Time in ms for how long this frame is shown
Frame *mNext; // Next frame in sequence
};

class Animation
{
public:
Animation():mCurrentFrame(0);
~Animation();

void setSequence(const std::string &);

void logic(int timePassed);

Image* getCurrentImage()
{ return mCurrentFrame ? mCurrentFrame->mImg : 0; }

private:
Frame *mCurrentFrame;
typedef std::map<std::string,Frame*> FrameMap;
typedef FrameMap::iterator FrameMapIterator;
FrameMap mStartFrames;
std::list<Frame*> mFrames;
int mRemain;
}

Animation::~Animation()
{
for_each(mFrames.begin(), mFrames.end(), make_dtor(mFrames));
}

void Animation::setSequence(const std::string &name)
{
FrameMapIterator i = mStartFrames.find(name);
mCurrentFrame = (i == mStartFrames.end()) ? 0 : i->second;
mRemain = 0;
}

void Animation::logic(int timePassed)
{
mRemain += timePassed;
while (mRemain >= mCurrentFrame->mDelay) {
mRemain -= mCurrentFrame->mDelay;
mCurrentFrame = mCurrentFrame->mNext;
}
};
</pre>

== Implementation proposal of hairstyles by Modanung ==

I think the current system with an xml file for every hairstyle with an index and offset defined for every frame is a bit too mutch. It also takes a lot of work to correct small errors and to add new hairstyles that may have a different frame size and with it a different offset.
I suggest we split hairstyles up in three catagories:
* Static hairstyles
* Standard animated hairstyles
* Special case hairstyles
===Static hairstyles===
These are hairstyles which only have one frame for each direction and death, so five. All current hairstyles would be static hairstyles. Every individual static hairstyle needs nothing more to be defined then their bitmap, their size and their offset for each direction.
The offset for each seperate frame would be defined in a shared file (say hairoffsets.xml), this summed with the individual hairstyle's offset is the offset for that single frame with that hairstyle.
<pre>
hairstyle1.xml
<offsetfile="hairoffsets.xml", framefile="static_hairstyles_frames.xml">
<sprite variants="10" variant_offset="5">

<imageset name="base" src="graphics/sprites/hairstyle1.png" width="40" height="40" />
<offsetX="0" offsetY ="0" />

End of file
</pre>

<pre>
hairoffsets.xml

<action name="stand" imageset="base">
<animation direction="down">
<offsetX="0" offsetY ="-29" />
</animation>
<animation direction="left">
<offsetX="-1" offsetY ="-29"/>
</animation>
<animation direction="up">
<offsetX="-1" offsetY ="-25"/>
</animation>
<animation direction="right">
<offsetX="1" offsetY ="-29"/>
</animation>
</action>

<action name="walk" imageset="base">
<animation direction="down">
<offsetX="0" offsetY ="-28" delay="75"/>
<offsetX="0" offsetY ="-29" delay="75" />
<offsetX="0" offsetY ="-29" delay="75" />
<offsetX="0" offsetY ="-28" delay="75" />
<offsetX="0" offsetY ="-29" delay="75" />
<offsetX="0" offsetY ="-29" delay="75" />
</animation>
...etc...
</pre>
<pre>
static_hairstyles_frames.xml

<animation direction="down">
<frame index="0" />
</animation>
<animation direction="left">
<frame index="1" />
</animation>
<animation direction="up">
<frame index="2" />
</animation>
<animation direction="right">
<frame index="3" />
</animation>

<action name="dead" imageset="base">
<animation direction="default">
<frame index="4"/>
</animation>
End of file
</pre>
===Standard animated hairstyles===
These are hairstyles that can be compared with hair in SoM or Chrono Trigger, they move as you walk and attack. They have three frames for each direction and death, so thirteen frames all together. These three frames can be devided in a relaxed frame and two extremes. Those two extremes either being up and down or left and right, depending on the hair style. A heavily greased Evil look would wobble up and down as you walk and a pony talk would wave from left to right.
Standard animated hairstyles hairstyles use the same offset as static ones only they have a different file for defining the frames.
<pre>
hairstyle2.xml
<offsetfile="hairoffsets.xml", framefile="animated_hairstyles_frames.xml">
<sprite variants="10" variant_offset="13">

<imageset name="base" src="graphics/sprites/hairstyle2.png" width="40" height="40" />
<offsetX="0" offsetY ="0" />

End of file
</pre>
<pre>
animated_hairstyles_frames.xml

<action name="stand" imageset="base">
<animation direction="down">
<frame index="0" />
</animation>
<animation direction="left">
<frame index="3" />
</animation>
<animation direction="up">
<frame index="6" />
</animation>
<animation direction="right">
<frame index="9" />
</animation>
</action>

<action name="walk" imageset="base">
<animation direction="down">
<frame index="0" delay="75"/>
<frame index="1" delay="75" />
<frame index="1" delay="75" />
<frame index="0" delay="75" />
<frame index="2" delay="75" />
<frame index="2" delay="75" />
</animation>
...etc...
</pre>
===Special case hairstyles===
And then there are the odd ones, the hairstyles that need a little more freedom. Hairstyles that people want to make wave in the wind, even when the player stands still. Or a birdnest hairstyle with nestlings that constantly open and close their mouth in a random frequency nomatter what you do. I'll take as example a Medusa hairstyle.
<pre>
hairstyle3.xml
<offsetfile="hairoffsets.xml", framefile=0>
<sprite variants="10" variant_offset="13">
<imageset name="base" src="graphics/sprites/hairstyle3.png" width="50" height="60" />
<offsetX="-5" offsetY ="-10" />

<animation direction="down">
<frame index="0" delay="100"/>
<frame index="1" delay="100"/>
<frame index="2" delay="100"/>
</animation>
<animation direction="left">
<frame index="3" delay="100"/>
<frame index="4" delay="100"/>
<frame index="5" delay="100"/>
</animation>
<animation direction="up">
<frame index="6" delay="100"/>
<frame index="7" delay="100"/>
<frame index="8" delay="100"/>
</animation>
<animation direction="right">
<frame index="9" delay="100"/>
<frame index="10" delay="100"/>
<frame index="11" delay="100"/>
</animation>

<action name="dead" imageset="base">
<animation direction="default">
<frame index="12"/>
</animation>

End of file
</pre>
This hairstyle showes a bunch of snakes on your head that always wave 'n wobble unless you're dead. The animation rolls asychronusly with the attack and walking animations and it also moves when you stand still. But the offsets are in sync. Special hairstyles might also use their own offsets ofcourse
I think this pretty much finished my proposal.

Development:Animations

2006-07-22T12:57:54Z

Modanung: Finished hairstyle animation proposal

{{Status_yellow}}

Each animation will be defined by an xml document, here follows an example:

<pre>
<sprite name="player" action="stand">

<imageset name="base" src="graphics/sprites/player_male_base.png" width="64" height="64" />

<action name="stand" imageset="base">
<animation direction="down">
<frame index="0" />
</animation>
<animation direction="left">
<frame index="18" />
</animation>
<animation direction="up">
<frame index="36" />
</animation>
<animation direction="right">
<frame index="54" />
</animation>
</action>

<action name="walk" imageset="base">
<animation direction="down">
<frame index="1" delay="50" />
<frame index="2" delay="50" />
<frame index="3" delay="50" />
<frame index="4" delay="50" />
<frame index="5" delay="50" />
<frame index="6" delay="50" />
</animation>
<animation direction="left">
<sequence start="19" end="24" delay="50" />
</animation>
<animation direction="up">
<sequence start="37" end="42" delay="50" />
</animation>
<animation direction="right">
<sequence start="55" end="60" delay="50" />
</animation>
</action>

<action name="sit" imageset="base">
<animation direction="down">
<frame index="7" />
</animation>
<animation direction="left">
<frame index="25" />
</animation>
<animation direction="up">
<frame index="43" />
</animation>
<animation direction="right">
<frame index="61" />
</animation>
</action>

<action name="dead" imageset="base">
<animation direction="down">
<frame index="8" />
</animation>
<animation direction="left">
<frame index="26" />
</animation>
<animation direction="up">
<frame index="44" />
</animation>
<animation direction="right">
<frame index="62" />
</animation>
</action>

<action name="attack" imageset="base">
<animation direction="down">
<sequence start="9" end="12" delay="100" />
</animation>
<animation direction="left">
<sequence start="27" end="30" delay="100" />
</animation>
<animation direction="up">
<sequence start="45" end="48" delay="100" />
</animation>
<animation direction="right">
<sequence start="63" end="66" delay="100" />
</animation>
</action>

</sprite>
</pre>

So if you want to load the playerset you just load player.xml and it takes care of loading all related images. Of course delays are defined in milliseconds.

== Specifications ==

=== <sprite> ===
A sprite is an object which can carry several animations, hence we call the root element the <code>sprite</code>. The sprite got two optional properties <code>variants</code> and <code>variant_offset</code>. These are required when there are multiple very similar versions of a sprite in one spriteset. One example for this are the hairset spritesets. <code>variants</code> defines the number of variants in the spriteset and <code>variant_offset</code> how many sprites are between the first sprites of the variants. When defining multiple variants you only define the animation sequences of the first variant. the engine then shifts the index parameters when it wants anotherone.

=== <action> ===
collection of the animation in different directions that belong to an action the character can perform. the properties are the imageset the animation phases are taken from and the name of the action.

possible names:
<pre>
use-item
|
attack-bow cast-magic
| |
attack-stab attack-throw
\ /
run attack-swing sleeping dead
| | | |
walk attack sit hurt
\ \ / /
stand
|
(no name attribute)
</pre>

this table also specifies the substitution precedence. when a specific name is requested but it is not defined the next lower name is used instead.

=== <animation> ===
Defines an animation sequence that should be displayed when the sprite object faces in a specific direction (attribute "direction").

the possible directions are:
<pre>
up
down
left
right
</pre>

when a specific direction isn't provided, the first defined direction is used instead. this can be overridden by defining an animation with the direction "default" for this action.

Every <code><animation></code> has one or more <code>frame</code> or <code>sequence</code> child elements.

=== <frame> ===

each of them defines one frame of the animation. the required properties are <code>index</code> and optional <code>offsetX</code>, <code>offsetY</code> and <code>delay</code>.

<code>index</code> defines the index of the graphic on the spriteset.

an optional property is <code>delay</code>. every frame is displayed for <code>delay</code> millisecounds and then replaced by the next frame in sequence. when the last frame is reached the sequence starts with the first frame again. when no delay is specified (or specified as "0") the animation doesn't continue when this <code>frame</code> is reached.

Each <code>frame</code> element can optionally have the properties <code>offsetX</code> and <code>offsetY</code> to specify an offset from the default drawing position for that frame. This allows the animation of for example the hairset (or any equipment) to reuse the same frames with different offsets.

=== <sequence> ===
<code>sequence</code> tag does not only define one animation phase but multiple phases. Its properties are <code>delay</code>, <code>start</code> and <code>end</code> which are all required. The delay is the delay in ms between each phase. the properties <code>start</code> and <code>end</code> define the first and the last index of the animation sequence on the spritesheet.

== Suggested additions ==

=== multiple delays in a <frame> with start and end attribute ===
in the bow animation I've chosen a shortcut to specify different delays for different frames. I am undecided yet whether this is a nice feature or whether it'll be better to require multiple <code>frame</code> elements in such cases.

=== <random> childtag for <animation> ===
Also, it includes an experimental suggestion on specifying that a random frame should be chosen. This should also have an exclude_current_frame thingy, to make sure a frame isn't shown twice or more in a row. Sometimes this may be wanted though.

=== sequences based on default sequences ===
After reflecting on this idea (and the above suggestion) I think a first issue to solve is to reduce the amount of duplicated definitions. For example, at the moment every monster uses the exact same frame size and animation frames. Hence, it would be interesting if the defined sprite could take the actual imageset it uses as a parameter instead of specifying this on its own. This way we can define a monster like:

<pre>
<sprite name="monster-walking-default">
<imageset name="base" />
...
</sprite>

<being name="Scorpion">
<sprite ref="monster-walking-default">
<with-imageset name="base" src="scorpion-base.png" width="60" height="60" />
</sprite>
</being>

<being name="Red Scorpion">
<sprite ref="monster-walking-default">
<with-imageset name="base" src="scorpion-red-base.png" width="60" height="60" />
</sprite>
</being>
</pre>

Defining an empty imageset (without <code>src</code> attribute) will make the engine require this imageset to be passed as a parameter whenever the spriteset is referenced.

I'm not convinced yet that the <code>name</code> attribute of the <code>sprite</code> element is really necessary. I think I would prefer each sprite to be defined in its own file. However it could be attractive to define multiple things in the same file, but in that case I think we will have to read everything when the client is launched, and only graphics and imagesets can be created lazily (only when necessary). Because the other data consists of just numbers and strings, this should not be really a problem.

== An implementation idea by Peoro ==

An idea to manage the animations should be a class based on a timer which choose automatically the current frame.
Who needs animations (players, monsters and npcs) has only to start the animanion and to request the frame to draw it.
Each instance of Animation class keep its own start-time (or a personal timer), its total time, number of frames, and the time of every frame.
The Animation class has to provide at least a function to start the animation and another one to get the current frame; other usefull functions should pause and restart the animation and allow to jump to a random frame.

Here a simple example of a prototype of an Animation class:
(I mutilated my original Animation class to simplify and summarize it cutting a lot of other functions and vars and using the most possible of standard items)

<pre>
class Animation
{
int nframes;
Img **frames;
int *times;
int totalTime;
int startTime;

public:
Animation ( int n, Img **i, int *t )
{
int c;

nframes = n;
frames = new Img* [n];
times = new int [n];
totalTime = 0;

for ( c = 0; c < n; c ++ ) {
frames[c] = i[c];
times[c] = t[c];
totalTime += t[c];
}
}

inline void start ( int t = clock() )
{
startTime = t;
}

Img *getFrame ( int t = clock() )
{
int i;
int it

if ( ! totalTime ) {
t = 0;
} else {
t = (t-startTime) % totalTime;
}

// searches the current frame
for ( i = 0, it = 0; (it + times[i]) < t; i ++, it += times[i] );

return frames[i];
}

};
</pre>

And here how to use this class:

<pre>
Img * imgs [] = { img1, img2, img3 };
int times [] = { 20, 20, 30 };

Animation a ( 3, imgs, times );

a.start ( );

while ( 1 ) {
draw ( a.getFrame() );
}
</pre>

An advantage of this class is that the animation speed is indipendent to FPS and it's very easy to use.

This is a simple way to manage a lot of animations for who needs more than one:

<pre>
class AnimationsList
{
// ltstr is only a const char* comparison function
map<const char*, Animation*, ltstr> animations;
int startTime; // now Animation::startTime is no more usefull
Animation *currentAnimation;

public:
AnimationsList ( ) : currentAnimation(0) { }

inline void addAnimation ( const char *n, Animation *a )
{
animations[n] = a;
}

int setAnimation ( const char *n, int t = clock() )
{
map<const char*, Animation*, ltstr>::iterator ai;
Animation *a;

ai = animations.find ( n );

if ( ai == animations.end() ) {
// error... animation not found
return 0;
}
a = ai->second;

if ( currentAnimation != a ) {
a->start ( );
currentAnimation = a;
startTime = t;
}

return 1;
}

Img * getFrame ( )
{
if ( currentAnimation ) {
return currentAnimation->getFrame ( );
}
return 0;
}
};
</pre>

Using a multimap instead the map it's possible to keep more than an animation bind to the same string. This would be a good way to make AnimationsList choose a random animation.

And here how to use AnimationsList class:

<pre>
AnimationsList al;

al.addAnimation ( "walking" "south", anim1 );
al.addAnimation ( "walking" "north", anim2 );
al.addAnimation ( "anim3", anim3 );

al.setAnimation ( "walking" "south" );

while ( 1 ) {
draw ( al.getFrame() );
}
</pre>

I hope not to had make a mistake writing... Anyway these are only theorical bases.

== Implementation proposal by Doener ==

This proposal is incomplete regarding how new sequences are added to the
Animation (which is not the right name for this type of class *g*)... Anyway,
you should get the idea...
The Frame class encapsulates images and are used to create a single linked list that
creates an animation. The idea behind the linked list is that you can easily create loops,
by having the last element of the animation pointing to the first one. Also, you can easily
prepend a "starting animation" before the loop, like in an animation of a running player.
He starts out with one animation and then loops the real running... The Animation class is
responsible for mapping animation names to their starting frame and for disposing the encapsulating
Frame objects, thus a std::map and a std::list is used to keep track of those objects.
The next frame is simply calculated from the time that has passed since the last run of the
logic method. The case that a whole animation loop can be skipped is not taken into consideration,
because a) we cannot do this with frames linked together arbitrarily and b) animations will probably
take around 100ms or longer, ie. we'd have less than 10fps for that case to happen and then
there's nothing left to gain by that simple optimization anymore anyway ;)

For the linked list features, of course the xml format needs to be adjusted to support that.

<pre>
/*
* Frame class, stored information about frames in an animation
*/
struct Frame
{
Image *mImg; // Image for this frame
int mDelay; // Time in ms for how long this frame is shown
Frame *mNext; // Next frame in sequence
};

class Animation
{
public:
Animation():mCurrentFrame(0);
~Animation();

void setSequence(const std::string &);

void logic(int timePassed);

Image* getCurrentImage()
{ return mCurrentFrame ? mCurrentFrame->mImg : 0; }

private:
Frame *mCurrentFrame;
typedef std::map<std::string,Frame*> FrameMap;
typedef FrameMap::iterator FrameMapIterator;
FrameMap mStartFrames;
std::list<Frame*> mFrames;
int mRemain;
}

Animation::~Animation()
{
for_each(mFrames.begin(), mFrames.end(), make_dtor(mFrames));
}

void Animation::setSequence(const std::string &name)
{
FrameMapIterator i = mStartFrames.find(name);
mCurrentFrame = (i == mStartFrames.end()) ? 0 : i->second;
mRemain = 0;
}

void Animation::logic(int timePassed)
{
mRemain += timePassed;
while (mRemain >= mCurrentFrame->mDelay) {
mRemain -= mCurrentFrame->mDelay;
mCurrentFrame = mCurrentFrame->mNext;
}
};
</pre>

== Implementation proposal of hairstyles by Modanung ==

I think the current system with an xml file for every hairstyle with an index and offset defined for every frame is a bit too mutch. It also takes a lot of work to correct small errors and to add new hairstyles that may have a different frame size and with it a different offset.
I suggest we split hairstyles up in three catagories:
* Static hairstyles
* Standard animated hairstyles
* Special case hairstyles
===Static hairstyles===
These are hairstyles which only have one frame for each direction and death, so five. All current hairstyles would be static hairstyles. Every individual static hairstyle needs nothing more to be defined then their bitmap, their size and their offset for each direction.
The offset for each seperate frame would be defined in a shared file (say hairoffsets.xml), this summed with the individual hairstyle's offset is the offset for that single frame with that hairstyle.
<pre>
hairstyle1.xml
<offsetfile="hairoffsets.xml", framefile="static_hairstyles_frames.xml">
<sprite variants="10" variant_offset="5">

<imageset name="base" src="graphics/sprites/hairstyle1.png" width="40" height="40" />
<offsetX="0" offsetY ="0" />

End of file
</pre>

<pre>
hairoffsets.xml

<action name="stand" imageset="base">
<animation direction="down">
<offsetX="0" offsetY ="-29" />
</animation>
<animation direction="left">
<offsetX="-1" offsetY ="-29"/>
</animation>
<animation direction="up">
<offsetX="-1" offsetY ="-25"/>
</animation>
<animation direction="right">
<offsetX="1" offsetY ="-29"/>
</animation>
</action>

<action name="walk" imageset="base">
<animation direction="down">
<offsetX="0" offsetY ="-28" delay="75"/>
<offsetX="0" offsetY ="-29" delay="75" />
<offsetX="0" offsetY ="-29" delay="75" />
<offsetX="0" offsetY ="-28" delay="75" />
<offsetX="0" offsetY ="-29" delay="75" />
<offsetX="0" offsetY ="-29" delay="75" />
</animation>
...etc...
</pre>
<pre>
static_hairstyles_frames.xml

<animation direction="down">
<frame index="0" />
</animation>
<animation direction="left">
<frame index="1" />
</animation>
<animation direction="up">
<frame index="2" />
</animation>
<animation direction="right">
<frame index="3" />
</animation>

<action name="dead" imageset="base">
<animation direction="default">
<frame index="4"/>
</animation>
End of file
</pre>
===Standard animated hairstyles===
These are hairstyles that can be compared with hair in SoM or Chrono Trigger, they move as you walk and attack. They have three frames for each direction and death, so thirteen frames all together. These three frames can be devided in a relaxed frame and two extremes. Those two extremes either being up and down or left and right, depending on the hair style. A heavily greased Evil look would wobble up and down as you walk and a pony talk would wave from left to right.
Standard animated hairstyles hairstyles use the same offset as static ones only they have a different file for defining the frames.
<pre>
hairstyle2.xml
<offsetfile="hairoffsets.xml", framefile="animated_hairstyles_frames.xml">
<sprite variants="10" variant_offset="13">

<imageset name="base" src="graphics/sprites/hairstyle2.png" width="40" height="40" />
<offsetX="0" offsetY ="0" />

End of file
</pre>
<pre>
animated_hairstyles_frames.xml

<action name="stand" imageset="base">
<animation direction="down">
<frame index="0" />
</animation>
<animation direction="left">
<frame index="3" />
</animation>
<animation direction="up">
<frame index="6" />
</animation>
<animation direction="right">
<frame index="9" />
</animation>
</action>

<action name="walk" imageset="base">
<animation direction="down">
<frame index="0" delay="75"/>
<frame index="1" delay="75" />
<frame index="1" delay="75" />
<frame index="0" delay="75" />
<frame index="2" delay="75" />
<frame index="2" delay="75" />
</animation>
...etc...
</pre>
===Special case hairstyles===
And then there are the odd ones, the hairstyles that need a little more freedom. Hairstyles that people want to make wave in the wind, even when the player stands still. Or a birdnest hairstyle with nestlings that constantly open and close their mouth in a random frequency nomatter what you do. I'll take as example a Medusa hairstyle.
<pre>
hairstyle3.xml
<offsetfile="hairoffsets.xml", framefile=0>
<sprite variants="10" variant_offset="13">
<imageset name="base" src="graphics/sprites/hairstyle3.png" width="50" height="60" />
<offsetX="-5" offsetY ="-10" />

<animation direction="down">
<frame index="0" delay="100"/>
<frame index="1" delay="100"/>
<frame index="2" delay="100"/>
</animation>
<animation direction="left">
<frame index="3" delay="100"/>
<frame index="4" delay="100"/>
<frame index="5" delay="100"/>
</animation>
<animation direction="up">
<frame index="6" delay="100"/>
<frame index="7" delay="100"/>
<frame index="8" delay="100"/>
</animation>
<animation direction="right">
<frame index="9" delay="100"/>
<frame index="10" delay="100"/>
<frame index="11" delay="100"/>
</animation>

<action name="dead" imageset="base">
<animation direction="default">
<frame index="12"/>
</animation>

End of file
</pre>
This hairstyle showes a bunch of snakes on your head that always wave 'n wobble unless you're dead. It moves asychronusly with the attack and walking animations and it also moves when you stand still. Special hairstyles might also use their own offsets ofcourse
I think this pretty much finished my proposal.

Development:Animations

2006-07-21T15:45:17Z

Modanung:

{{Status_yellow}}

Each animation will be defined by an xml document, here follows an example:

<pre>
<sprite name="player" action="stand">

<imageset name="base" src="graphics/sprites/player_male_base.png" width="64" height="64" />

<action name="stand" imageset="base">
<animation direction="down">
<frame index="0" />
</animation>
<animation direction="left">
<frame index="18" />
</animation>
<animation direction="up">
<frame index="36" />
</animation>
<animation direction="right">
<frame index="54" />
</animation>
</action>

<action name="walk" imageset="base">
<animation direction="down">
<frame index="1" delay="50" />
<frame index="2" delay="50" />
<frame index="3" delay="50" />
<frame index="4" delay="50" />
<frame index="5" delay="50" />
<frame index="6" delay="50" />
</animation>
<animation direction="left">
<sequence start="19" end="24" delay="50" />
</animation>
<animation direction="up">
<sequence start="37" end="42" delay="50" />
</animation>
<animation direction="right">
<sequence start="55" end="60" delay="50" />
</animation>
</action>

<action name="sit" imageset="base">
<animation direction="down">
<frame index="7" />
</animation>
<animation direction="left">
<frame index="25" />
</animation>
<animation direction="up">
<frame index="43" />
</animation>
<animation direction="right">
<frame index="61" />
</animation>
</action>

<action name="dead" imageset="base">
<animation direction="down">
<frame index="8" />
</animation>
<animation direction="left">
<frame index="26" />
</animation>
<animation direction="up">
<frame index="44" />
</animation>
<animation direction="right">
<frame index="62" />
</animation>
</action>

<action name="attack" imageset="base">
<animation direction="down">
<sequence start="9" end="12" delay="100" />
</animation>
<animation direction="left">
<sequence start="27" end="30" delay="100" />
</animation>
<animation direction="up">
<sequence start="45" end="48" delay="100" />
</animation>
<animation direction="right">
<sequence start="63" end="66" delay="100" />
</animation>
</action>

</sprite>
</pre>

So if you want to load the playerset you just load player.xml and it takes care of loading all related images. Of course delays are defined in milliseconds.

== Specifications ==

=== <sprite> ===
A sprite is an object which can carry several animations, hence we call the root element the <code>sprite</code>. The sprite got two optional properties <code>variants</code> and <code>variant_offset</code>. These are required when there are multiple very similar versions of a sprite in one spriteset. One example for this are the hairset spritesets. <code>variants</code> defines the number of variants in the spriteset and <code>variant_offset</code> how many sprites are between the first sprites of the variants. When defining multiple variants you only define the animation sequences of the first variant. the engine then shifts the index parameters when it wants anotherone.

=== <action> ===
collection of the animation in different directions that belong to an action the character can perform. the properties are the imageset the animation phases are taken from and the name of the action.

possible names:
<pre>
use-item
|
attack-bow cast-magic
| |
attack-stab attack-throw
\ /
run attack-swing sleeping dead
| | | |
walk attack sit hurt
\ \ / /
stand
|
(no name attribute)
</pre>

this table also specifies the substitution precedence. when a specific name is requested but it is not defined the next lower name is used instead.

=== <animation> ===
Defines an animation sequence that should be displayed when the sprite object faces in a specific direction (attribute "direction").

the possible directions are:
<pre>
up
down
left
right
</pre>

when a specific direction isn't provided, the first defined direction is used instead. this can be overridden by defining an animation with the direction "default" for this action.

Every <code><animation></code> has one or more <code>frame</code> or <code>sequence</code> child elements.

=== <frame> ===

each of them defines one frame of the animation. the required properties are <code>index</code> and optional <code>offsetX</code>, <code>offsetY</code> and <code>delay</code>.

<code>index</code> defines the index of the graphic on the spriteset.

an optional property is <code>delay</code>. every frame is displayed for <code>delay</code> millisecounds and then replaced by the next frame in sequence. when the last frame is reached the sequence starts with the first frame again. when no delay is specified (or specified as "0") the animation doesn't continue when this <code>frame</code> is reached.

Each <code>frame</code> element can optionally have the properties <code>offsetX</code> and <code>offsetY</code> to specify an offset from the default drawing position for that frame. This allows the animation of for example the hairset (or any equipment) to reuse the same frames with different offsets.

=== <sequence> ===
<code>sequence</code> tag does not only define one animation phase but multiple phases. Its properties are <code>delay</code>, <code>start</code> and <code>end</code> which are all required. The delay is the delay in ms between each phase. the properties <code>start</code> and <code>end</code> define the first and the last index of the animation sequence on the spritesheet.

== Suggested additions ==

=== multiple delays in a <frame> with start and end attribute ===
in the bow animation I've chosen a shortcut to specify different delays for different frames. I am undecided yet whether this is a nice feature or whether it'll be better to require multiple <code>frame</code> elements in such cases.

=== <random> childtag for <animation> ===
Also, it includes an experimental suggestion on specifying that a random frame should be chosen. This should also have an exclude_current_frame thingy, to make sure a frame isn't shown twice or more in a row. Sometimes this may be wanted though.

=== sequences based on default sequences ===
After reflecting on this idea (and the above suggestion) I think a first issue to solve is to reduce the amount of duplicated definitions. For example, at the moment every monster uses the exact same frame size and animation frames. Hence, it would be interesting if the defined sprite could take the actual imageset it uses as a parameter instead of specifying this on its own. This way we can define a monster like:

<pre>
<sprite name="monster-walking-default">
<imageset name="base" />
...
</sprite>

<being name="Scorpion">
<sprite ref="monster-walking-default">
<with-imageset name="base" src="scorpion-base.png" width="60" height="60" />
</sprite>
</being>

<being name="Red Scorpion">
<sprite ref="monster-walking-default">
<with-imageset name="base" src="scorpion-red-base.png" width="60" height="60" />
</sprite>
</being>
</pre>

Defining an empty imageset (without <code>src</code> attribute) will make the engine require this imageset to be passed as a parameter whenever the spriteset is referenced.

I'm not convinced yet that the <code>name</code> attribute of the <code>sprite</code> element is really necessary. I think I would prefer each sprite to be defined in its own file. However it could be attractive to define multiple things in the same file, but in that case I think we will have to read everything when the client is launched, and only graphics and imagesets can be created lazily (only when necessary). Because the other data consists of just numbers and strings, this should not be really a problem.

== An implementation idea by Peoro ==

An idea to manage the animations should be a class based on a timer which choose automatically the current frame.
Who needs animations (players, monsters and npcs) has only to start the animanion and to request the frame to draw it.
Each instance of Animation class keep its own start-time (or a personal timer), its total time, number of frames, and the time of every frame.
The Animation class has to provide at least a function to start the animation and another one to get the current frame; other usefull functions should pause and restart the animation and allow to jump to a random frame.

Here a simple example of a prototype of an Animation class:
(I mutilated my original Animation class to simplify and summarize it cutting a lot of other functions and vars and using the most possible of standard items)

<pre>
class Animation
{
int nframes;
Img **frames;
int *times;
int totalTime;
int startTime;

public:
Animation ( int n, Img **i, int *t )
{
int c;

nframes = n;
frames = new Img* [n];
times = new int [n];
totalTime = 0;

for ( c = 0; c < n; c ++ ) {
frames[c] = i[c];
times[c] = t[c];
totalTime += t[c];
}
}

inline void start ( int t = clock() )
{
startTime = t;
}

Img *getFrame ( int t = clock() )
{
int i;
int it

if ( ! totalTime ) {
t = 0;
} else {
t = (t-startTime) % totalTime;
}

// searches the current frame
for ( i = 0, it = 0; (it + times[i]) < t; i ++, it += times[i] );

return frames[i];
}

};
</pre>

And here how to use this class:

<pre>
Img * imgs [] = { img1, img2, img3 };
int times [] = { 20, 20, 30 };

Animation a ( 3, imgs, times );

a.start ( );

while ( 1 ) {
draw ( a.getFrame() );
}
</pre>

An advantage of this class is that the animation speed is indipendent to FPS and it's very easy to use.

This is a simple way to manage a lot of animations for who needs more than one:

<pre>
class AnimationsList
{
// ltstr is only a const char* comparison function
map<const char*, Animation*, ltstr> animations;
int startTime; // now Animation::startTime is no more usefull
Animation *currentAnimation;

public:
AnimationsList ( ) : currentAnimation(0) { }

inline void addAnimation ( const char *n, Animation *a )
{
animations[n] = a;
}

int setAnimation ( const char *n, int t = clock() )
{
map<const char*, Animation*, ltstr>::iterator ai;
Animation *a;

ai = animations.find ( n );

if ( ai == animations.end() ) {
// error... animation not found
return 0;
}
a = ai->second;

if ( currentAnimation != a ) {
a->start ( );
currentAnimation = a;
startTime = t;
}

return 1;
}

Img * getFrame ( )
{
if ( currentAnimation ) {
return currentAnimation->getFrame ( );
}
return 0;
}
};
</pre>

Using a multimap instead the map it's possible to keep more than an animation bind to the same string. This would be a good way to make AnimationsList choose a random animation.

And here how to use AnimationsList class:

<pre>
AnimationsList al;

al.addAnimation ( "walking" "south", anim1 );
al.addAnimation ( "walking" "north", anim2 );
al.addAnimation ( "anim3", anim3 );

al.setAnimation ( "walking" "south" );

while ( 1 ) {
draw ( al.getFrame() );
}
</pre>

I hope not to had make a mistake writing... Anyway these are only theorical bases.

== Implementation proposal by Doener ==

This proposal is incomplete regarding how new sequences are added to the
Animation (which is not the right name for this type of class *g*)... Anyway,
you should get the idea...
The Frame class encapsulates images and are used to create a single linked list that
creates an animation. The idea behind the linked list is that you can easily create loops,
by having the last element of the animation pointing to the first one. Also, you can easily
prepend a "starting animation" before the loop, like in an animation of a running player.
He starts out with one animation and then loops the real running... The Animation class is
responsible for mapping animation names to their starting frame and for disposing the encapsulating
Frame objects, thus a std::map and a std::list is used to keep track of those objects.
The next frame is simply calculated from the time that has passed since the last run of the
logic method. The case that a whole animation loop can be skipped is not taken into consideration,
because a) we cannot do this with frames linked together arbitrarily and b) animations will probably
take around 100ms or longer, ie. we'd have less than 10fps for that case to happen and then
there's nothing left to gain by that simple optimization anymore anyway ;)

For the linked list features, of course the xml format needs to be adjusted to support that.

<pre>
/*
* Frame class, stored information about frames in an animation
*/
struct Frame
{
Image *mImg; // Image for this frame
int mDelay; // Time in ms for how long this frame is shown
Frame *mNext; // Next frame in sequence
};

class Animation
{
public:
Animation():mCurrentFrame(0);
~Animation();

void setSequence(const std::string &);

void logic(int timePassed);

Image* getCurrentImage()
{ return mCurrentFrame ? mCurrentFrame->mImg : 0; }

private:
Frame *mCurrentFrame;
typedef std::map<std::string,Frame*> FrameMap;
typedef FrameMap::iterator FrameMapIterator;
FrameMap mStartFrames;
std::list<Frame*> mFrames;
int mRemain;
}

Animation::~Animation()
{
for_each(mFrames.begin(), mFrames.end(), make_dtor(mFrames));
}

void Animation::setSequence(const std::string &name)
{
FrameMapIterator i = mStartFrames.find(name);
mCurrentFrame = (i == mStartFrames.end()) ? 0 : i->second;
mRemain = 0;
}

void Animation::logic(int timePassed)
{
mRemain += timePassed;
while (mRemain >= mCurrentFrame->mDelay) {
mRemain -= mCurrentFrame->mDelay;
mCurrentFrame = mCurrentFrame->mNext;
}
};
</pre>

== Implementation proposal of hairstyles by Modanung ==

I think the current system with an xml file for every hairstyle with an index and offset defined for every frame is a bit too mutch. It also takes a lot of work to correct small errors and to add new hairstyles that may have a different frame size and with it a different offset.
I suggest we split hairstyles up in three catagories:
* Static hairstyles
* Standard animated hairstyles
* Special case hairstyles
===Static hairstyles===
These are hairstyles which only have one frame for each direction, for every animation. All current hairstyles would be static hairstyles. Every individual static hairstyle needs nothing more to be defined then their bitmap, their size and their offset for each direction.
The offset for each seperate frame would be defined in a shared file (say hairoffsets.xml), this summed with the indicidual hairstyle's offset is the offset for that single frame with that hairstyle.
...To be finished...

Development:Animations

2006-07-21T15:33:43Z

Modanung: Exclude_current_frame thingy

{{Status_yellow}}

Each animation will be defined by an xml document, here follows an example:

<pre>
<sprite name="player" action="stand">

<imageset name="base" src="graphics/sprites/player_male_base.png" width="64" height="64" />

<action name="stand" imageset="base">
<animation direction="down">
<frame index="0" />
</animation>
<animation direction="left">
<frame index="18" />
</animation>
<animation direction="up">
<frame index="36" />
</animation>
<animation direction="right">
<frame index="54" />
</animation>
</action>

<action name="walk" imageset="base">
<animation direction="down">
<frame index="1" delay="50" />
<frame index="2" delay="50" />
<frame index="3" delay="50" />
<frame index="4" delay="50" />
<frame index="5" delay="50" />
<frame index="6" delay="50" />
</animation>
<animation direction="left">
<sequence start="19" end="24" delay="50" />
</animation>
<animation direction="up">
<sequence start="37" end="42" delay="50" />
</animation>
<animation direction="right">
<sequence start="55" end="60" delay="50" />
</animation>
</action>

<action name="sit" imageset="base">
<animation direction="down">
<frame index="7" />
</animation>
<animation direction="left">
<frame index="25" />
</animation>
<animation direction="up">
<frame index="43" />
</animation>
<animation direction="right">
<frame index="61" />
</animation>
</action>

<action name="dead" imageset="base">
<animation direction="down">
<frame index="8" />
</animation>
<animation direction="left">
<frame index="26" />
</animation>
<animation direction="up">
<frame index="44" />
</animation>
<animation direction="right">
<frame index="62" />
</animation>
</action>

<action name="attack" imageset="base">
<animation direction="down">
<sequence start="9" end="12" delay="100" />
</animation>
<animation direction="left">
<sequence start="27" end="30" delay="100" />
</animation>
<animation direction="up">
<sequence start="45" end="48" delay="100" />
</animation>
<animation direction="right">
<sequence start="63" end="66" delay="100" />
</animation>
</action>

</sprite>
</pre>

So if you want to load the playerset you just load player.xml and it takes care of loading all related images. Of course delays are defined in milliseconds.

== Specifications ==

=== <sprite> ===
A sprite is an object which can carry several animations, hence we call the root element the <code>sprite</code>. The sprite got two optional properties <code>variants</code> and <code>variant_offset</code>. These are required when there are multiple very similar versions of a sprite in one spriteset. One example for this are the hairset spritesets. <code>variants</code> defines the number of variants in the spriteset and <code>variant_offset</code> how many sprites are between the first sprites of the variants. When defining multiple variants you only define the animation sequences of the first variant. the engine then shifts the index parameters when it wants anotherone.

=== <action> ===
collection of the animation in different directions that belong to an action the character can perform. the properties are the imageset the animation phases are taken from and the name of the action.

possible names:
<pre>
use-item
|
attack-bow cast-magic
| |
attack-stab attack-throw
\ /
run attack-swing sleeping dead
| | | |
walk attack sit hurt
\ \ / /
stand
|
(no name attribute)
</pre>

this table also specifies the substitution precedence. when a specific name is requested but it is not defined the next lower name is used instead.

=== <animation> ===
Defines an animation sequence that should be displayed when the sprite object faces in a specific direction (attribute "direction").

the possible directions are:
<pre>
up
down
left
right
</pre>

when a specific direction isn't provided, the first defined direction is used instead. this can be overridden by defining an animation with the direction "default" for this action.

Every <code><animation></code> has one or more <code>frame</code> or <code>sequence</code> child elements.

=== <frame> ===

each of them defines one frame of the animation. the required properties are <code>index</code> and optional <code>offsetX</code>, <code>offsetY</code> and <code>delay</code>.

<code>index</code> defines the index of the graphic on the spriteset.

an optional property is <code>delay</code>. every frame is displayed for <code>delay</code> millisecounds and then replaced by the next frame in sequence. when the last frame is reached the sequence starts with the first frame again. when no delay is specified (or specified as "0") the animation doesn't continue when this <code>frame</code> is reached.

Each <code>frame</code> element can optionally have the properties <code>offsetX</code> and <code>offsetY</code> to specify an offset from the default drawing position for that frame. This allows the animation of for example the hairset (or any equipment) to reuse the same frames with different offsets.

=== <sequence> ===
<code>sequence</code> tag does not only define one animation phase but multiple phases. Its properties are <code>delay</code>, <code>start</code> and <code>end</code> which are all required. The delay is the delay in ms between each phase. the properties <code>start</code> and <code>end</code> define the first and the last index of the animation sequence on the spritesheet.

== Suggested additions ==

=== multiple delays in a <frame> with start and end attribute ===
in the bow animation I've chosen a shortcut to specify different delays for different frames. I am undecided yet whether this is a nice feature or whether it'll be better to require multiple <code>frame</code> elements in such cases.

=== <random> childtag for <animation> ===
Also, it includes an experimental suggestion on specifying that a random frame should be chosen. This should also have an exclude_current_frame thingy, to make sure a frame isn't shown twice or more in a row. Sometimes this may be wanted though.

=== sequences based on default sequences ===
After reflecting on this idea (and the above suggestion) I think a first issue to solve is to reduce the amount of duplicated definitions. For example, at the moment every monster uses the exact same frame size and animation frames. Hence, it would be interesting if the defined sprite could take the actual imageset it uses as a parameter instead of specifying this on its own. This way we can define a monster like:

<pre>
<sprite name="monster-walking-default">
<imageset name="base" />
...
</sprite>

<being name="Scorpion">
<sprite ref="monster-walking-default">
<with-imageset name="base" src="scorpion-base.png" width="60" height="60" />
</sprite>
</being>

<being name="Red Scorpion">
<sprite ref="monster-walking-default">
<with-imageset name="base" src="scorpion-red-base.png" width="60" height="60" />
</sprite>
</being>
</pre>

Defining an empty imageset (without <code>src</code> attribute) will make the engine require this imageset to be passed as a parameter whenever the spriteset is referenced.

I'm not convinced yet that the <code>name</code> attribute of the <code>sprite</code> element is really necessary. I think I would prefer each sprite to be defined in its own file. However it could be attractive to define multiple things in the same file, but in that case I think we will have to read everything when the client is launched, and only graphics and imagesets can be created lazily (only when necessary). Because the other data consists of just numbers and strings, this should not be really a problem.

== An implementation idea by Peoro ==

An idea to manage the animations should be a class based on a timer which choose automatically the current frame.
Who needs animations (players, monsters and npcs) has only to start the animanion and to request the frame to draw it.
Each instance of Animation class keep its own start-time (or a personal timer), its total time, number of frames, and the time of every frame.
The Animation class has to provide at least a function to start the animation and another one to get the current frame; other usefull functions should pause and restart the animation and allow to jump to a random frame.

Here a simple example of a prototype of an Animation class:
(I mutilated my original Animation class to simplify and summarize it cutting a lot of other functions and vars and using the most possible of standard items)

<pre>
class Animation
{
int nframes;
Img **frames;
int *times;
int totalTime;
int startTime;

public:
Animation ( int n, Img **i, int *t )
{
int c;

nframes = n;
frames = new Img* [n];
times = new int [n];
totalTime = 0;

for ( c = 0; c < n; c ++ ) {
frames[c] = i[c];
times[c] = t[c];
totalTime += t[c];
}
}

inline void start ( int t = clock() )
{
startTime = t;
}

Img *getFrame ( int t = clock() )
{
int i;
int it

if ( ! totalTime ) {
t = 0;
} else {
t = (t-startTime) % totalTime;
}

// searches the current frame
for ( i = 0, it = 0; (it + times[i]) < t; i ++, it += times[i] );

return frames[i];
}

};
</pre>

And here how to use this class:

<pre>
Img * imgs [] = { img1, img2, img3 };
int times [] = { 20, 20, 30 };

Animation a ( 3, imgs, times );

a.start ( );

while ( 1 ) {
draw ( a.getFrame() );
}
</pre>

An advantage of this class is that the animation speed is indipendent to FPS and it's very easy to use.

This is a simple way to manage a lot of animations for who needs more than one:

<pre>
class AnimationsList
{
// ltstr is only a const char* comparison function
map<const char*, Animation*, ltstr> animations;
int startTime; // now Animation::startTime is no more usefull
Animation *currentAnimation;

public:
AnimationsList ( ) : currentAnimation(0) { }

inline void addAnimation ( const char *n, Animation *a )
{
animations[n] = a;
}

int setAnimation ( const char *n, int t = clock() )
{
map<const char*, Animation*, ltstr>::iterator ai;
Animation *a;

ai = animations.find ( n );

if ( ai == animations.end() ) {
// error... animation not found
return 0;
}
a = ai->second;

if ( currentAnimation != a ) {
a->start ( );
currentAnimation = a;
startTime = t;
}

return 1;
}

Img * getFrame ( )
{
if ( currentAnimation ) {
return currentAnimation->getFrame ( );
}
return 0;
}
};
</pre>

Using a multimap instead the map it's possible to keep more than an animation bind to the same string. This would be a good way to make AnimationsList choose a random animation.

And here how to use AnimationsList class:

<pre>
AnimationsList al;

al.addAnimation ( "walking" "south", anim1 );
al.addAnimation ( "walking" "north", anim2 );
al.addAnimation ( "anim3", anim3 );

al.setAnimation ( "walking" "south" );

while ( 1 ) {
draw ( al.getFrame() );
}
</pre>

I hope not to had make a mistake writing... Anyway these are only theorical bases.

== Implementation proposal by Doener ==

This proposal is incomplete regarding how new sequences are added to the
Animation (which is not the right name for this type of class *g*)... Anyway,
you should get the idea...
The Frame class encapsulates images and are used to create a single linked list that
creates an animation. The idea behind the linked list is that you can easily create loops,
by having the last element of the animation pointing to the first one. Also, you can easily
prepend a "starting animation" before the loop, like in an animation of a running player.
He starts out with one animation and then loops the real running... The Animation class is
responsible for mapping animation names to their starting frame and for disposing the encapsulating
Frame objects, thus a std::map and a std::list is used to keep track of those objects.
The next frame is simply calculated from the time that has passed since the last run of the
logic method. The case that a whole animation loop can be skipped is not taken into consideration,
because a) we cannot do this with frames linked together arbitrarily and b) animations will probably
take around 100ms or longer, ie. we'd have less than 10fps for that case to happen and then
there's nothing left to gain by that simple optimization anymore anyway ;)

For the linked list features, of course the xml format needs to be adjusted to support that.

<pre>
/*
* Frame class, stored information about frames in an animation
*/
struct Frame
{
Image *mImg; // Image for this frame
int mDelay; // Time in ms for how long this frame is shown
Frame *mNext; // Next frame in sequence
};

class Animation
{
public:
Animation():mCurrentFrame(0);
~Animation();

void setSequence(const std::string &);

void logic(int timePassed);

Image* getCurrentImage()
{ return mCurrentFrame ? mCurrentFrame->mImg : 0; }

private:
Frame *mCurrentFrame;
typedef std::map<std::string,Frame*> FrameMap;
typedef FrameMap::iterator FrameMapIterator;
FrameMap mStartFrames;
std::list<Frame*> mFrames;
int mRemain;
}

Animation::~Animation()
{
for_each(mFrames.begin(), mFrames.end(), make_dtor(mFrames));
}

void Animation::setSequence(const std::string &name)
{
FrameMapIterator i = mStartFrames.find(name);
mCurrentFrame = (i == mStartFrames.end()) ? 0 : i->second;
mRemain = 0;
}

void Animation::logic(int timePassed)
{
mRemain += timePassed;
while (mRemain >= mCurrentFrame->mDelay) {
mRemain -= mCurrentFrame->mDelay;
mCurrentFrame = mCurrentFrame->mNext;
}
};
</pre>

Development:Guidelines

2006-07-17T16:36:32Z

Modanung: Zoggle's site seems to be down.

== In general ==
*Don't be afraid to show us your unfinished pieces, we are there to guide and help you through the process.
*If possible, hang around the #tmwart channel on irc.freenode.net 24/7.
*When you're available / doing work on tmw related stuff, please contact me on the previously mentioned channel.
*We're soon going to have a centralized repository for all the art related stuff where we're going to archive all of your versions, so you can just start to contribute there without the need to track down a dev. The details on the repository and the preferred version numbering are coming soon. EDIT(20050419): Ask me for details, it's up now.
*Preferred formats: .png and .ogg

== Concerning conceptual art ==
*You can always come up with new ideas to present to the team. Actually that's preferred and we like that.
*With conceptual art you might want to define important places, capture the generic atmosphere, look, and color scheme of a certain place or define the looks of an important NPC.

== Concerning tiles ==
*We REALLY need a LOT of these, so if you think you can do ANYTHING, please give it a shot.

*Especially on these actively seek out our attention so we can assign new tasks to you. The fact that we won't contact you personally every day doesn't mean we don't need your efforts.

*You can find the technical specifications of tilesets here: [[Tileset development]]

*Please keep in mind that a mapper has got only 3 layers: 2 of them are always displayed below players and monsters while the other one is displayed always above. The lowest layer is usually used for ground tiles/walls, and since the limited number of layers, ground tiles should be non-transparent even if this increase a lot the number of tiles in a tileset. Transparent tiles should be only used for objects you can place in different places with different backgrounds such as plants, barrels, ... It is preferrable that cups, and food and whatever else stands on a table is drawn with the table tile below it. Paintings shouldn't have transparent borders, but wall behind them. (if you plan to use for example paintings in different tileset, save them elsewhere as transparent objects and then reapply them to another tile).

*Although we prefer high quality tiles over low quality ones, please keep in mind that we try to resemble the look of old SNES games. So please try not to make the tiles too realistic. This mean please don't use textures you get from reality, such a picture of a wooden piece and use it for your tiles. We strongly encourage you to manually pixelate every tile and avoid to use gradients or filters such as blur too excessive.

*All the tileset should use some coherence:
**The direction of the light: south-west for outdoor tilesets (of course there will be exceptions: different (or special) areas could have a different direction of light to give it a subtle different feeling, such as lava caves with subtle orange light from the bottom, and deep in the dark forest with glowing mushrooms), diffuse light for indoor tilesets diffused light is nice, but overusage could lead into problems with contrast between the inside and the outside.
**The perspective: top-down 45Â° view angle (if in doubt, take a look at current screenshots or search for Secret of Mana screenshots).
**The proportions: a character is one tile wide and two tiles high.
**The color style: try to use the same color palette for the whole tileset. the selection of color is important for the feeling of the tileset. weak colors with a high amount of grey for example are good for a sad and cold feeling while bright colors create a happy and warm atmosphere. whatever atmosphere you choose: it should be consistent through the whole tileset. avoid using weird "alien" colors (keep saturation low :P).
**The tiles in one tileset should be able to be put together in as many different ways as possible to allow the mapper to express his creativity. This is the base requirement for:
*** Borders between different heights: http://www.enterbrain.co.jp/digifami/digiweb/dot_teck/3nen/05/8.gif
***Fences http://www.enterbrain.co.jp/digifami/digiweb/dot_teck/3nen/04/053.gif http://www.enterbrain.co.jp/digifami/digiweb/dot_teck/3nen/04/052.gif http://www.enterbrain.co.jp/digifami/digiweb/dot_teck/3nen/04/054.gif
(please note that the above pictures are only for demonstrational purpose. they are copyrighted and not part of the mana world project).

== Tutorials ==
When you are not very experienced at creating pixel art, you should take a look at the following tutorials. You can learn many interesting tricks from them.

*[http://www.petesqbsite.com/sections/tutorials/tuts/tsugumo/ So You Want To Be A Pixel Artist] by Tsugumo.
*[http://translate.google.com/translate?u=http%3A%2F%2Fwww.enterbrain.co.jp%2Fdigifami%2Fdigiweb%2Fdot_teck%2F3nen%2F3_01.html&langpair=ja%7Cen&hl=en&ie=UTF-8&oe=UTF-8&prev=%2Flanguage_tools Enterbrains Tutorial (translated from Japanese by Google)]. all the above images have been taken from this tutorial.

Talk:Player Groups

2006-07-15T10:15:44Z

Modanung:

I want to create a guild, to be accepted, nedd my permission, how much nedd to pay? I pay max 1kk to create the guild, the current members:
>>>>>>>>>>BraziL-ElitE<<<<<<<<<< [ Guild Name ]
BraziL-KnighT [LeadeR]
BraziL-DiablehI [Member]
BraziL-FaldeoN [Member]
BraziL_BruninhU [Member]
BraziL-Ryane [Future Female Player]

Well we don't have a guild system yet. So guilds can just be created by getting people together and naming your little gang. No need for paying anyone. [[User:Modanung|Modanung]] 12:15, 15 July 2006 (CEST)

Development:Playersets

2006-06-20T16:23:08Z

Modanung: Updated information on the female playerset

{{Status_yellow}}

== General specs ==
* '''Frame size:''' 32x64
* '''Color depth:''' 32 bpp (including alpha layer)
* '''Directions:''' 4 (north, south, east, west)
* Action list
** Current basic needs
*** Standing (1 frame)
*** Death (1 frame)
*** Sitting (1 frame)
*** Walking (6 frames)
*** Attacking with punch/single-hand thrusting weapon
*** Attacking with bow
*** Casting spell
**Extra sequences
*** Running (6 frames)
*** Skim-floating (amulet movement) (3 frames)
*** Waving (3 frames)
*** Picking up item (3 frames)
*** Getting hit (2 frames)
*** Attacking with single-hand slashing weapon
*** Attacking with two-hand thrusting weapon
*** Attacking with thrown weapon
*** Attacking with two-hand slashing weapon
*** Attacking with two-hand smashing weapon
*** Targeting spell on self
*** Targeting area of effect spell
*** Targeting spell on single target

== Current state of development ==

The male spriteset with all the animations that are currently needed is finally completed now. Thanks to all the artists who contributed to this fine piece of art. The next big challenge will be the female spriteset.

When the players will gain additional posibilities like using spells or skills or when we will implement new ways of moving (like swimming or climbing) we will have to work on the spritesets again.

=== Current Male Playerset by Talaroc and Modanung ===

[[Image:Player-sheet.png | thumb | 600px]]

=== Current Female Playerset by Modanung ===

[[Image:Player-sheet-female.png | thumb | 600px]]

[[Image:Femsprite_2.png]]

== Drafts and Suggestions ==

=== [[User:moltheni|moltheni]]'s modifications ===
26/07
*I think eyes are too much big, what do you think of these? 
http://lev.altervista.org/tmw_eyes.GIF
*I've also made three 'getting hit' frames 
http://lev.altervista.org/tmw_chara_getting_hit.GIF 
08/08
*I've tried to improve the side standing pose and walkin animation (two versions of the walk, short or long arms..), I still haven't colored them :P 
http://lev.altervista.org/tmw_charasidestand.GIF standing pose 
http://lev.altervista.org/tmw_charasidewalk.GIF walks

=== Old animation by Talaroc ===

The first (on the left) image is the "standing" sprite.

[[Image:Playerset south talaroc.png]] [[Image:South walk by talaroc animated.gif]]

=== Sprite mods by Kyokai ===

http://img109.exs.cx/img109/9112/kyokai7yv.png My character for TMW (someday)
http://img76.exs.cx/img76/6519/kirin7bf.png The NPC KirinDekagen

=== Necromus ===

http://www.filehigh.com/serve.php?u=1823&i=5825&t=.gif

Side view walking frame (incomplete).

=== Old animation by Neko-mon ===

http://www.geocities.com/cless_alv/walking4.gif
http://www.lindeijer.nl/~bjorn/walking3_6frames.gif
http://www.lindeijer.nl/~bjorn/walking3_4frames.gif

12, 6 and 4 frame versions.

== Comments ==
* [[User:BjÃ¸rn|BjÃ¸rn]]: I've made the 6 frame versions by simply deleting all even frames in your animation. In my opinion it's still a fine animation and it's saving quite a bit of work. For the 4 frame version I have created a single neutral stand frame and used the two leg extremes, so it's actually only 3 different images.

* [[User:Neko-mon|Neko-mon]]: I made little fixes in the 12 frames image.

* [[User:moltheni|moltheni]]: Can I make some sprites too? If you tell me what is needed (and what others are doing) I can help! p.s.: Aren't the eyes of the sidewalk sprites too much.. ehm... on the bottom (sorry for the english)? and the shadow of the legs of the back-standing-pose-frame is inverted.

* [[User:Bear|Bear]]:If you want to do something in Graphics, contact Rotonen, OR you can ask me about a few things. It might not be my part to lead graphics, but it would be good to get some monsters done. *just a critic* :D

* [[User:ElvenProgrammer|ElvenProgrammer]]: moltheni, you can contact me as well. Feel free to propose improvements to the spriteset by Talaroc, especially on side walking and sit pose.
----

File:Player-sheet.png

2006-06-20T16:16:31Z

Modanung:

Male player spriteset by Talaroc, Jetryl and Modanung.

Project description

2006-06-07T09:37:42Z

Modanung: Reverted Ohmygushdud0's changes

{{Status_yellow}}
The Mana World is a project that tries to create a free and open source MMORPG game with the looks of "old-fashioned" 2D RPG games such as those released for the SNES / Super Famicom in the early 90's. The game itself will be free to download and will also have no monthly fee.

The Mana World aims to be a unique place for people to interact by not only fighting but also forming a community, a microcosm inside the game. Although the game is dynamic and does not have a linear story, it should include background story such as countries, tribes, culture, climate, etc. Quests should lead to other quests. Quests should also encourage forming groups/parties so as to promote the community feel.

Additionally, the developers care about cross compilable source code and efficient resource management in order to make the game playable on as many platforms and operating systems as possible. Low end hardware such as x86 PIIs or G3 PPCs should be the minimum requirement.