The Mana World Forums

I will be honest with you.

I don't like it at all that you are trying to tumble everything over we designed for years. We put a lot of thought into the systems we designed and most of what you wrote on http://wiki.themanaworld.org/index.php/ ... rp/Systems directly contradicts these thoughts. When you find a flaw in the the systems we brainstormed together during countless chat session then you are free to start a discussion about them. But your proposal seems to me like you haven't even read the existing design articles and now you want to take over the whole game system design and replace it with your own idea.

Here are the most important game system articles:

http://wiki.themanaworld.org/index.php/Attributes
http://wiki.themanaworld.org/index.php/Skill_system_2
http://wiki.themanaworld.org/index.php/ ... alculation
http://wiki.themanaworld.org/index.php/Magic_system
http://wiki.themanaworld.org/index.php/Rune_combination
http://wiki.themanaworld.org/index.php/Combat_system

People again and again discarding the design work of others to start their own ego trips instead of building on the foundation of their predecessors is one of the reasons this project is taking so long to get any visible results. We have the same problem with world design. How many perfectly good layouts for world designs did we have during the history of this project? And we still don't have a complete one because everyone who volunteers to do design work is unable to do it without tearing everything down the people created before and starting from scratch.

Sorry, but this pattern has to stop when this project is supposed to ever have a result. That's why I will from now on hold the following view: either you build upon the accepted design proposals on the wiki or you leave and start your own fork.

Hi Crush,

Just to be clear about my intentions:

Bertram wrote:and as my work is based on the current ManaServ status, to minimize the development time cost,

I don't want to throw out all the work done as I find it very usable as a first argument.
Let's keep the current base and finish it, filling the gaps along the way.

I didn't realise that Freeyorp's proposal meant throwing all the work done so far. Maybe he should clear that point out.

Best regards.

Hi Crush,

Freeyorp personally told me he didn't to erase any kind of work made so far. Please have a talk with him, I'm sure there were a misunderstanding.

Since we're slowly making it somehow, I propose to create a clone of the manaserv git repo, and push evolutions made on formulas so far.

What do you think?

Best regards.

Bertram wrote:Since we're slowly making it somehow, I propose to create a clone of the manaserv git repo, and push evolutions made on formulas so far.

OK for me, but before we do this we should document the new formulas on the wiki.

Crush wrote:

Bertram wrote:Since we're slowly making it somehow, I propose to create a clone of the manaserv git repo, and push evolutions made on formulas so far.

OK for me, but before we do this we should document the new formulas on the wiki.

Like this: http://wiki.themanaworld.org/index.php/ ... rp/Systems?

Weren't we talking about the modifications decided on the last 4 pages?

Hi,

OK for me, but before we do this we should document the new formulas on the wiki.
Weren't we talking about the modifications decided on the last 4 pages?

Crush is right, we were and it can be found here:
http://doc.manasource.org/manaserv_statistics_system

Crush, feel free to comment or upgrade as needed. This is something meant to be as a design tab for now, at least.

As for the manaserv clone, it's created and you've got commit and review access:
http://gitorious.org/~bertram/mana/mana ... ystem-test

Let's rock!

Best regards.

There seems to be some misunderstanding here, as I never intended to discard everything, nor did I neglect to carefully read through the articles you linked to (it would have been very rude of me to do so given that you had linked to the attributes article so early on)

Perhaps this might have been from interpreting the article as being a complete proposal? It was meant to be more of a sketchbook documenting new systems and systems that need to be updated; even that is still very much a work in progress. For example, there wouldn't be much in terms of documenting the skill systems since I would already agree that they would indeed work and work well and are documented very nicely elsewhere.

Or perhaps there is something in the proposed changes/additions that you specifically object to? I'll also include a list of some of the bigger ones and why I believe they are necessary should this be the case:

Much of damage calculation is indeed being reworked. The article itself explicitly states that one of the things yet to do was "Evaluation of possible balancing issues caused by the Attributes system, Equipment system and Skill system", so the reworking here hopefully shouldn't be too controversial:

Previous proposed systems wrote:damage = weapon_damage + strength + rand(0, weapon_skill)
HP loss = (Damage * element_modifier) - vitality - (equip_defence)

I strongly objected to the additive modifiers (both in attack and in defense) since when we would use a system that results in a contest between two in such a way we will have much of the same balancing issues we have with tmw-eathena right now. I objected to the way that strength is used directly in the calculation without the attribute or even the rate at which the attribute modifies the attack being part of the weapon. I objected to the way that weapon skill has such a little effect on the overall damage of the weapon.

With this in mind, after considerable testing I created the following alternative and added it to my sketchbook:

Sketchbook for additions and changes wrote:defense = (Sum of all current defense attribute modifiers) + 0.3 * Vitality
damage = damage * (1.0 - (0.0159375f * defense) / (1.0 + 0.017 * defense)) + random(damage >> 4)

Defensive reduction would be based upon vitality and active modifers (primarily from equipment). I justify vitality as being a hardcoded component in this calculation since this factor is target-specific combined with defense modifers as part of a secondary stat in the main calculation, so there is still a reasonable component of both item/stat builds here.
The formula used may be thought of as being in two parts:
The primary reduction (for 15/16th of the total attack) is based on a gompertz curve. While more computationally expensive then additive modifications, being event based and being a fairly crucial aspect of gameplay justifies this further expense.
A secondary component of reduction (for 1/16th of the total attack), consists of a single call to random for determining effectiveness and cannot be blocked through standard means.

While I won't rule out some small additive reduction (which I referred to as block type damage reduction), either as temporary effects or periodically proc'ing based on some chance as a passive effect, such things are outside the scope of CR1 for now; at least until a standard form of damage reduction has been implemented and thoroughly tested.

Other things covered by the Damage Calculation article are also outside the scope of CR1 and future planning for now.



Attribute effects and their calculations are being partially reworked, but their roles remain very close to what they were planned to be previously.

After [this] poll, I began making relatively small modifications to attribute calculation to fit the different type of curve.

Some of the more important modifications here include a non-constant attack speed; not implicitly scaling RHS attributes with level; and fixes to hp and hp regeneration to saner scales (natural regeneration reduced significantly, as such effects were externalized to active effects and passive item boni). I do not think that the first and third changes would be too controversial, and the second, being more of a conceptual change, was the main point of bringing up that poll - and the majority seems to agree there.



Modifier types for item modifers are being defined.

Making certain attributes non-stackable simplifies balance and makes more sense for certain attributes such as dodge, even given the clever hit system that was planned. In this manner, such types of attribute could be initially obtained with greater ease (as the cost for such things would be reduced given that they would become obsolete if not crafted into the next upgrade)
Since such handling hasn't been well documented, and this is more of addition more than a change, I would hope that it would not prove so objectionable to you either (though the current manner in which manaserv handles this isn't entirely sane anyway; it is quite impossible to increase max hp, for example, or to modify in a non-additive way)

Previous proposed systems wrote:To avoid unbalanced characters players should have some restrictions when distributing the stat points. Without any restrictions a level 18 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):

I simply disagree with this on principle. Given the results of [this] poll, should I assume that the majority also disagree? This is not covered by my sketchbook of proposed changes/modifications, but this is something I have been meaning to address very soon anyway. I also do not think the stats should be capped at 100; formulae posted on my sketchbook have been working from the assumption that characters have a hundred points to start for consistency with [Bertram's article].


Much of the discussion for this still takes place on IRC (which, ironically enough, was partially inspired by your method of discussion on IRC -> document on the wiki), it would be nice when you would be around when such things take place. (I don't think I've ever seen Crush join TMW's IRC?)


---Freeyorp