computer games forum

That was an interesting post peregrin. Please forgive me if my reply might sound a bit rough, I still have trouble hitting the right tone in English.

My definition for attributes is a bit different then yours.
An attribute is a numerical value characteristic for a specific character that measures her ability to alter the gamestate.

A primary attributes value is inherent to the attribute, so it does not depend on other attributes.
A secondary attributes values is derived from one or several primary attributes.

A comperative attribute is used in attribute comparisons. It's value only has meaning in relation to the opposite attributes value. (Damage for example, 40 Damage is nice against an 100 HP enemy, but pretty insignificant against an 1.000.000 HP enemy.)
An absolute attribute on the other hand has inherent meaning. (Number of attacks for example.)

A path dependent attributes value depends on the way it has been raised. So the same number of points invested in the attribute can lead to different values. The opposite are of course path independent attributes.

Mixing a path dependent attribute in a group of otherwise path independent attributes can make sense if the former has low desirability in the beginning. That way you can increase the incentive for spending resources on the attribute even if the short term return is low. So in other words path dependent attributes make sense if the character advancement itself is path dependent.
Though it does increase the advancement systems complexity, which may not be desirable.

Raising attributes is not that exciting

Agreed, that's why I like selecting abilities on level up more.

Your third point sounds interesting but I'm not convinced that it will result in that much of a difference to the other two approaches most of the time. And in the instances where it will it might be quite frustrating for the player since she has to indirectly steer the character in the required direction.
It would also requite a fair bit of refactoring, while we do have a common interface for all attribute requests it's also used for predictions. Though that's only a minor problem.
The actual questions is how to reach a conclusion from that data, since the accumulated information lacks context.
While I think that the idea sounds interesting in theory, I'm not convinced that it will work that well in practice.

Merging skill levels

Just some comments.
Right click is reserved by the engine we use. A different way would of course be possible. It's a pain for the AI though.
We're doing interruptible actions in the new framework.

Final suggestions

• Autocast is a good idea, might be a bit difficult in the details.
• Agreed
• Agreed, though my rationale is that fewer item slots will make item choice more interesting.

jack1974 wrote:Sorry forgot to say that I plan to put class restrictions or tweaks, for example if you picked warrior your attack would be strength *5 + level *5, while if was a thief would be strength *3 + level *3 (something like that). I obviously need to make some tests to avoid the situation you just described

Whatever formulas you decide to use in the end, please be sure to publish them somewhere that's easy to find.

I didn't think raising attributes was much of an issue, especially in Loren since there were not many to begin with. Personally, I like having control/choices over the growth of my party.

P_Tigras wrote: Whatever formulas you decide to use in the end, please be sure to publish them somewhere that's easy to find.

Well they were in Loren tooltips But I forgot to update them when I released the game and that caused some confusion. This time I'm going to keep the text updated!

Jaeger wrote:I didn't think raising attributes was much of an issue, especially in Loren since there were not many to begin with. Personally, I like having control/choices over the growth of my party.

Yes that's the problem, some people like it and others not. I think the best solution is to have an "auto" button where you can let the CPU do auto-level up (not just the attributes but also the skills). I like to assign the attributes too but when you are testing or replaying the game for the 10th time, it does get a bit tedious indeed

Hi again,

jack1974 wrote:

P_Tigras wrote: Whatever formulas you decide to use in the end, please be sure to publish them somewhere that's easy to find.

Well they were in Loren tooltips But I forgot to update them when I released the game and that caused some confusion. This time I'm going to keep the text updated!

There's actually a technical solution to this (which you may or may not be aware of; people coming from a static language background tend to consider this to be a more obscure language feature): if the tooltip is in a Python string, you can use Python's `eval' function to make sure that you use the exact same formula that you display as the one you use to compute:
Hope that helps,

-- peregrin

PS: Only just learned (or inferred, rather) that Anima is again doing the statistical bits. This is very good to hear.

Ah yes true! I was indeed thinking as I typed the response if there was a way to show the code directly
And yes Anima is doing it for Planet Stronghold 2, since I think he'll do a better job than me with numbers. I'll be busy anyway designing all the battle encounters, testing, balancing, etc. To each one his own

Did the class selection screen today:

you can choose also the "other twin" class as long as is not the same of your main character, and in the next screen you'll be able to automatically assign his / her skills or pick them yourself
You might notice I reused Loren class icons, I plan to have new ones done, but for now they'll be enough!

It's looking good so far. I think that second line should be "You can also change your twin brother's class but his can't be the same as yours." (The part at the bottom should say "twins' classes".)

Thanks will correct the texts

Looking good!, really looking forward to being able to play this