.com.unity Forums - OT: Making a Game System (part 2)

.com.unity Forums (http://forum.shrapnelgames.com/index.php)

- Dominions 3: The Awakening (http://forum.shrapnelgames.com/forumdisplay.php?f=138)

- - OT: Making a Game System (part 2) (http://forum.shrapnelgames.com/showthread.php?t=41368)

Re: OT: Making a Game System (part 2)

Omni, you mean logarithm again, not exponent. A logarithm flattens for increasing arguments, which is what you're describing. In this case, since its argument is going to be base statistics, you're not going to get into the problem of negative values.

Now, on to the big point that you really need to decide, for definite, before you continue to generate and refine models. What scale of statistics are you looking at? Not only the best parameters for an equation, but even the best equation, is strongly affected by the range of possible input values.

Consider the Gompertz curve that you suggest. You have defined restrictions in the form of an upper asymptote of 1.5 and an intercept of 1, but the Gompertz function is not easily fixed for a specific intercept (The most basic Gompertz function with asymptote 1.5 has intercept 1.5/e = 0.552). One thing I would suggest is that you construct the sigmoid function such that you can adjust the point along the 'shape' of the function which occurs at x=0. By doing this, and incorporating the skill into this parameter of the equation, you can make skilled characters suffer less for lacking physically and benefit more from being stronger and more dexterous than the unskilled fighter. But this depends largely on what possible range of inputs you need the function to be relevant over.

The big balancing act is essentially going to be between 'weapons' and 'tactics'. If they use different equations there will always come a point where it is better to be cunning than accomplished, or vice versa. By incorporating skill into the equations in different ways you may make it easier to control balance, by making a more skilled fighter benefit differently than an unskilled fighter.

Re: OT: Making a Game System (part 2)

OK!!! I've got a working app written that simulates the model. I've described the model in the app, but I copy-paste it here for you to see.

Please try out the app. It's source code only right now. You will need Python, Pygame, Numpy, and maybe PyObjC to run it. I may later make into a stand-alone executable. Included in the file is a package called "Glyph" that I'm kinda proud of and have GPL licensed. Glyph is a very basic typsetter for use in Pygame.

OK, now for the instructions and model:

Code:

#  This file isn't licensed.  However some if its libraries are.  See those files for more info.

#

#  Instructions: click on the stats or the weapon to change them.

#  Left click forward, Right click back.  On the right hand side is

#  a list of weapons and their stat requirments and arms value.  There

#  is also a listing of the stats used and their descriptions.  Click

#  'TEST' to run the simulation.  The results are printed to the shell.

#

#  Model: The Weapon's requirements are subtracted from the corresponding

#  Combatant's stats scores: Dex, Str, and Skill.  The difference is

#  subjected to a logit function.  This result is then multiplied by

#  the required value.  This first represents the intrinsic handling of the

#  weapon that is brought out by possessing the salient skill or stat

#  (represented through the stat difference put into the logit function.)

#  This second represents the way in which possessing stats or skills

#  in deficiency or excess is compounded due to the nature of the weapon:

#  weapons needing strength benefit more from having lots of strength,

#  but not having it is penelized severely (represented by multiplying logit

#  result by required value).  The difference of these values between the

#  two combatants is then taken and subjected once again to a logit function.

#  This represents the interaction between the two weapons in combat:  A dagger

#  vs. a maul is different from a dagger vs. a club, or another dagger.

#  This makes the assumption that the strength of the weapon is in the degree

#  of talent required to weild it, thus low stat requirement weapons will

#  ultimately be trumped by high stat requirement weapons.  However, this

#  also has the effect of making the low stat requirement weapons typically

#  superior if their requirements are met when the more powerful/difficult

#  weapon's requirements are not.

#

#  Lastly, the Per, Psy, and Skill scores are simply added together.

#  This the 'tactics' portion of combat.  This amount is then geometrically

#  averaged with the 'weapon' portion.  As weapons become very powerful

#  (with high arms value), the 'tactics' portion is then going to present

#  a large drag on the score.  This is intended.

#

#  Well, OK, one more thing.  There will somehow be a random roll component.

#  I simply havn't decided where it should go.

#

#  Please play with this and provide your opinions on its model, and report

#  any unusual behaviors with the model.  Thanks!!!

Re: OT: Making a Game System (part 2)

Apparently Dominions has already recently been made into a D&D 4e setting... see http://forum.rpg.net/showthread.php?t=426089

Re: OT: Making a Game System (part 2)

part 2: game system

there is a very distinct focus on 'power' vs. 'technique' in ALL handheld weapon design and usage. I'm simply finding it impossible to capture this without using a system that gives each weapon two additional values: 'power' and 'technique'. The examples are inumerable, but consider the following two classic ones: 2h-sword v estoc and chinese saber v chinese sword are only two, but these are both weapons which are deliberately compared by both users and weapon historians as 'power' v. 'technique'. However, it is wrong to assume technique = skill just as it is wrong to assume power = strength; power can also be related to skill and technique can be related to intrinsic ability to handle weaponry. The word 'dexterity' is actually defined as a measure of expertise or technique. strength and dexterity, power and technique; these are not things you simply have, nor are they things that are simply trained. we know that there are some people who genetically can get stronger faster, just as there are some people who get more 'technique' faster. we can see then that there is really a strong connection between these 'attributes' and the _way_ we learn things. the game system that most notably has utilized this is EVE, which makes a direct relationship between the rate at which you learn skills, and the rating of the relevant attribute. I like this, but I don't like that the attribute has no other effect; it works OK for EVE in which it can literally take years to master a set of skills, but not for an RPG in which players should see a little more affect.

Therefore, my system will have the 'power' and 'technique' weapon parameters. The relationship between the player's attributes and this will be a logit curve of the attribute minus the parameter, multiplied by the parameter; the power parameter of a weapon will be related to strength, and the technique to dexterity. however, a player's skill level is also a logit curve. base skill is x=-5, which is like y=0.01. the effects of str and dex are multiplied by this. therefore, a very strong or dextrious character with no skill facing a weaker, clumsier character with even a little skill may be outmatched. Lastly, each weapon has an 'arms' value. Heavy military weaponry such as the 40 pound polearms may have huge strength requirments, but also have a high arms value. Their is typically a correlation between 'power' and 'arms' value, but not always. However it is hard to escape the fact that military weapons for fighting against heavy armor and horses are very heavy themselves, while civilian and concealable weaponry are typically designed with technique in mind. The logit's constants can be modified to get a desirable curve. they are likely to be flattned a little for str and dex, and even more for the effect of skill on them. it will look a little like this:

Code:

y=((logit(str-pwr) * pwr) + (logit(dex-teq) * teq)) * logit(skill)

actual combat can have more such skill checks included, the details can be worked out and even added on if for some reason it becomes necessary; although I'd like to keep it simple. there may be some indirect skill effects too, like skill for wearing armor or something.

the beautiful thing about this is that ALL skills will use this same system. All skills have some relevant attributes, and the skill level, and they will all use this type of formula to determine applied effect. this means combat is seperated from some kind of level or experience, and is rather just a skill. further, spells will just be skills too. so a spell might involve cognition, or psyche, or spirit, or whatever. but what's more, maybe that spell involves strength too! or dexterity or constitution, and these can be a part of the skill check. the downside is that all these extra parameters have to be assigned, but I think the affect is clear enough and the system simple enough that it should all be very straightforward; and in the end satisfying and elegant.

part 3 is on the way