17 replies to this topic

[StudentOfRubber]

Hello everyone, this is a question I've been thinking of, and one I don't think I've seen around.

I'm currently developing an old school turn based RPG using Flash and Actionscript 3.0. I've been marking my ideas and final thoughts down in a design document, though so far it's mostly story elements, smaller side mechanics and such. What I'm currently trying to wrap my head around is creating a list of stat categories for my character types, and having the knowledge of them work in-game (not necessary, but it works with the world).

From my history of both classic and modern RPGs, as well as tabletop gaming, they can range from four or five stat categories that have nothing to do with one another, or dozens that interact and determine secondary and tertiary stats.

For my RPG I want to to be basic, more so the "four or five" category, not so much the latter, though I'm not sure how to tackle this issue. If anyone has suggestions, or knows of a little trick they have to help with their own development, I would be very grateful.



Lastly, I would ask my own friends for help on this, but it contains subject matter they don't know I enjoy, and I don't want to alarm them. My current game design document can be seen HERE. I would ask that if you do look at the subject matter of the game I'm making, please do not let your opinion of the SUBJECT affect your discussion of the MECHANIC.

[rouncer]

just base it on some simple system, simple the better and just tack things on as you need it, i used to invent my own roleplaying systems when i was in primary school, i can still do it now. :)

[Gamer123]

What are "subs" and "doms"? Are these words short for other words?

I read the game design document linked above, but the two terms are unclear to me.

[Reedbeta]

They mean submissive/dominant, as in BDSM.

[StudentOfRubber]

I'm not sure if I should post updates in my thought process or not here, but if this isn't were I should, then please tell me so.

In any case, I started to think of my stats in how they would affect the battle, thinking that if I figure out how they work in relation to everything else, coming up with proper stats and stat levels would be fairly easy.

What I've come up with is: Moves, attack or defense, have their accuracy, their attack (maybe, as stat moves don't do damage), and secondary effects. The accuracy for a move is based on a predetermined stat, such as physical attack. The move would have a base percentage for hit rate, 50% in this case, and the stat is draws from for accuracy adds additional hit chance.

For instance: Move Acc = 50% +(character stat/(moveHitBase))%

So the base accuracy is 50%, plus a short equation that could possible make the attack 100% accurate if the stat is high enough. Of course, stronger moves would have a higher moveHitBase to stop moves from being super accurate.

The damage dealt by an attack could actually be determined by another stat, meaning that depending on the move and the character, an attach could be accurate, but weak, or strong and prone to missing, or just a balanced good hit, good damage move.

And again: Move Acc = 50% + (physAttack/(moveHitBase))%
Attack = baseDamage * (specAttack/moveDamBase)

The only reason I said all of this is so I can find a way to approximate what size the stats should be. I figured that if the base damage for an attack is, say, 20 for an early game move, HP for beginning characters could be 40-60, and stats could be around 15-30 to give a good ideas what the strengths and weaknesses of character types could be.

tl;dr I think I know where I'm going to start with stats, and if anyone wants to actual read the above to see what I mean, I look forward to the criticism and feedback.

[}:+()___ (Smile)]

Never understand why RPG/MMOPRG developers tend to use simple equations from board games. Personally I prefer smooth functions, for example for hit probability:

P_hit = 0.5 + 0.5 * tanh(Move_ACC + Char_ACC + Effects);

Also it is possible to use float (or double) variable for HP.

[StudentOfRubber]

Ooooh, that is a nice function there. But yeah, I kinda made that up on the spot, just trying to explain my reasoning. That should work much smoother.

Just proves I need to take a little time looking at other games for hit and dam formulas....

[StudentOfRubber]

Final able to take a look at the math used in the equation.

I'd probably drop the initial 0.5 from the equation and put the Move_ACC in it's place, as the Move_ACC in this case would be the 0.5.

P_hit = Move_ACC + (1 - (Move_ACC)) * tanh((Char_ACC + Effects) ACC_Mod);

I found that even with starting stats, a 20 in the Char_ACC multiplied by the 0.5 gives a boost of 18% in accuracy, so there's no need for an addition boost there. It's easy enough to boost the Move_ACC to a higher number if the attacks miss too often.

E: I saw that, with my jumbled way of looking at your formula, that if I wanted a low accuracy move to stay low accuracy, I needed a modifier for the inside of the tanh function. If a character had a special A of 241, even if the move only had a 10% base hit rate, he would still land the hit almost 100% of the time. If I stuck the modifier on there, say, reducing the pre-tanh number by 85%, or *.15, it brings the hit rate down to about 65%.

[}:+()___ (Smile)]

The 0.5 factor in the example formula is essential, formula designed to full range of ACC modifiers (-inf;+inf). With large negative argument hit rate goes to zero, and with large positive argument hit rate approaches one. Formula specially designed to avoid cases where total noob with lowest possible weapon has fixed nonzero rate (10% for example) to hit hilvl player.

For example, a human has Char_ACC = 0, an elf has Char_ACC = 1;
a sword hit has Move_ACC = 1 and a bow shot has Move_ACC = -1.
We have sword hit rate of 88% for a human and 98% for an elf;
bow hit rate of 12% for a human and 50% for an elf.

The 0.5 + 0.5*tanh(x) formula has exponentially decayed tails, so multiplying modifiers under tanh argument is overkill. Really important is the base value of modifier and its rate of change (and both are small, working area of argument is about [-3;3]). And don't be afraid of the negative values!

[alphadog]

'}:+()___ [Smile said:

']Never understand why RPG/MMOPRG developers tend to use simple equations from board games. Personally I prefer smooth functions.

StudentOfRubber said:

Ooooh, that is a nice function there.

I would totally expect a StudentOfRubber to prefer smooth functions...

[alphadog]

You are starting from the wrong end.

Don't start from the equations; start from the target player.

Is that player someone who wants to micro-manage stats or someone who wants to role-play? Given the topic, I think the latter would prevail, and forcing the player to be a micromanager will make them bounce away from your game. (Yes, pun intended.)

[StudentOfRubber]

I'm not sure, but we may be seeing the function using different variables.

When I wrote out my idea, the var you have as Char_ACC is not a set value for a character class, but a specified stat category of the character using the move. So when you say human may have a Char_ACC of 1, I'm seeing my what-have-you has a Char_ACC of Special_A, which for that character specifically at that point is 137.

This is my first time thinking about formulas, so maybe I'm just being dumb.

[alphadog]

You can't have other people give you the system you need. You have to work it out for yourself. You create a system, tune it, tune it again, and again, and...

[StudentOfRubber]

I understand. The feed back I received from everyone has been helpful, and just getting thoughts down has helped me tune them for myself. I even got to talk math, even though this isn't the right place for that. :3

[}:+()___ (Smile)]

The value Char_ACC I used in the formula is some general character accuracy measure in range about [-2;2]. In real game it can be something like

Char_ACC = DEX_to_ACC * (Race_DEX + Class_DEX + LV_to_DEX * Level) - Offset

where DEX_to_ACC, LV_to_DEX and Offset are fixed constants. My advice here is to draw a plot of the desired stats behaviour and then fit formula to it.

alphadog said:

Is that player someone who wants to micro-manage stats or someone who wants to role-play? Given the topic, I think the latter would prevail, and forcing the player to be a micromanager will make them bounce away from your game. (Yes, pun intended.)

I think elaborate micro-managing of stats in the design stage is necessary especially for roleplayers. In case of poor stats formulas micromanagers quickly discover some peculiar way to outrun roleplayers.

[alphadog]

'}:+()___ [Smile said:

']I think elaborate micro-managing of stats in the design stage is necessary especially for roleplayers.

"You can bring a horse to water, but you can't make him drink." comes to mind.

People who aren't interested in being made micromanagers simply won't play. That micromanagers will outrun roleplayers won't happen, because the latter won't be there to outrun.

There are also ways to reward roleplayers, if that's what you want to attract, that don't rely on forcing them to wear a shoe that doesn't fit.

[StudentOfRubber]

I never intended for there to be any micromanaging. I only want players to see that both damage AND accuracy increase when the character gets stronger. There's not going to be any min/maxing (hopefully), because the fluxuations between having a low stat and a high stat shouldn't make TOO much different.

Most attacks would be average, getting a spread of 5-10% accuracy from game start to game end, while some would be 100% from the get go, and strong moves, or moves that are intended to be risky, would stay risky and low accuracy until the char has ridiculous stats, where at that point, it's normal things would be overkill anyway.

I don't intent for a character to go into a fight with seven moves, ranging from 23% to 1000000% accuracy. Moreso, it would be 65 - 95%, which really isn't bad. I mean, you don't see the math behind it anyway, and the market I'm aiming for don't tend to be younger then, say 30, so they themselves aren't going to worry whether their 25% acc, or their 32% is better.

[Doubtless]

This thread has gotten a bit derailed, but I like the formula discussion.

Yes, you need to have your math ducks all lined up before release/playtesting, but at this broad-strokes phase in the design, lets start with what stats are necessary, fun, and what they do.

For example, the discussion has largely been about hit chance, which is probably the least fun statistic in gaming. Few things feel worse than whiffing your haymaker attack and losing.

The only reason hit should enter the equation is either:
a) as an entry barrier to higher-level play, i.e. raiding
b) to prevent lower-level players from being able to kill higher-level players

I think, perhaps a better idea is to figure out what you want your stats to do, then work backwards.

Should better equipped players be able to perform much better than worse equipped players?

Should there be entry barriers to performance to keep the "new" and "well equipped" players largely separated?

What is fun about your stats?

People love crits. I'd throw crit in there of course, which can be dictated by a wide variety of stats based on the character's class, gear, specialization, etc.

People love bigger numbers. Is the player stacking full crit going to outperform the player who stacks nothing but +damage? Is it going to be about even?

I'd recommend backing out and getting a broader scope on the problem than looking straight away at formulae