Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Sadist]

once you're done with the rule could you make a sumary of stuff a player need to know?

  I'll try. The original intention was for the rules to be separated into 'what a player needs to know' and 'what a player might want to know' sections but it didn't work out last time.

I read the game itself, but some of the more gigantic rule changes and logs were a bit tl;dr

  I don't seem to have a knack for brevity, I know. So far I've been trying to post rules so that anyone could conceivably use them to run a game independent of me but I think I'll try just posting player-side concerns next time.

  Also, you do know that the rules in the opening post are my failed first attempts? I literally considered editing them out of existence but decided that revisionism wasn't the way to go.

[Sean Mirrsen]

You should spoiler them in a discreet (and by extension, discrete) block, and add the other rules to the top of the post for ease of viewing.

Technical details like damage calculations are all fine and good if they don't interfere with the player's understanding of the rules. To the players, the rules are a BIOS, and they make the inputs and receive the output. You should outright state what inputs the players must make, and what outputs they'll get, without the inbetween technicals.

Also, keep the inputs as simple as possible. Like I said, simplicity is often as good as complexity.

For example, the TU costs for action, calculation, recovery. Unless there's some hidden purpose for this, why not just use the one cost? Also, 100*X%=X, you do know that, right?

I can thusly condense the rules, like this:

The parameter (Str+Dex+Int) can just be labeled as the Ability Sum.

Each player starts with 100 HP.
Each player can spend 100 Power each round.
No one action can use less than 5 Power.

Deals damage to target.
Implement: Weapon in hand.
Duration = X TUs.
Cooldown = X TUs.
Potential = AS*X/100
Effects:

• If Potential exceeds opponent's Defence, deal the difference as damage.
• If opponent's Defence exceeds Potential, add the difference to Cooldown TUs.

Provides additional defence against an incoming attack.
Implement: Weapon in hand.
Duration = .75*X TUs.
Cooldown = .75*X TUs.
Potential = AS*X/100
Effects:

• If Potential is positive (y'know, I have a hunch that there's little to no way it's going to be negative), add Potential to Defence

Review the above. I think it manages to represent your current rules fairly accurately.

[Sadist]

Preface:
  Sorry if it seems that I'm nitpicking over details that aren't in the current rules but I tried to set things up so that I could introduce subsequent changes with minimal disruption. It'll probably be more efficient to make a version that needs heavier modification later if it's easier to understand.

Body:
  It looks fairly accurate, though some of the term changes you made seem inconsistent with my plans. I'll try a piece-by-piece breakdown of the relevent parts of your post.

Technical details like damage calculations are all fine and good if they don't interfere with the player's understanding of the rules. To the players, the rules are a BIOS, and they make the inputs and receive the output. You should outright state what inputs the players must make, and what outputs they'll get, without the inbetween technicals.

  I figured that including a formula that would work for 95 or so variations of a command was the simplest way to present the information they would need. Regarding the inputs a player makes, see my reply to the next quote.

Also, keep the inputs as simple as possible. Like I said, simplicity is often as good as complexity.

The current order format is Action(Intensity). I expect to add targeting to that in the near future but I'm currently handling it on the GM side. I meant to mention it plainly in the rules but I think I decided that it would be redundant. Looking back it wasn't obvious enough.

For example, the TU costs for action, calculation, recovery. Unless there's some hidden purpose for this, why not just use the one cost?

  Execution is the time between an action being initiated and when it takes effect (eg the time between starting to swing a sword and hitting the target). The calculation phase is when calculations (eg amount of damage done) take place. Recovery is the time until you can use the resources (eg intensity, weapon etc) in a new action (eg the time it takes you to pull your sword out of your enemy). Also, the phase of an action may affect other action's effects (like a defend action only working on an attack in the execution phase). While it isn't apparent in this rule set, some actions might not have the same set of phases (eg a 'double smash' might go 'execution1, calculation1, execution2, calculation2, recovery). I figure that breaking it up into multiple phases makes things easier to understand (if I explain them properly at least).

Also, 100*X%=X, you do know that, right?

  I assume you're referring to the formulae for effectiveness. If so then the 100 is actually (Strength+Dexterity+Intelligence). While it will consistently add up to 100 in this ruleset, that will change when it is applied to characters with additional customisation or 'bosses'. I figured phrasing it this way now would reduce the changes I'd need to make later.
  If you're referring to the calculations for TUs required for attacking, the current formula is a simplification, with balancing that takes that simplification into account. The main goals were to keep it simple while making sure that a defence took less time than an attack of equivalent power to offset its inability to do direct damage. The full formula would include speed (currently all characters are assumed to be the same speed), weapon requirements (this might just affect the minimum intensity a character could assign to weapons using that action) and 'trade-offs' (a quicker execution time in exchange for a longer recovery time as an example), probably more (though I'll set up a simulation program to handle thing if it gets that far).

The parameter (Str+Dex+Int) can just be labeled as the Ability Sum.

  For this ruleset, yes. Problem is that this is a simplified formula, with the actual calculation involving weapon requirements and character statistics relative to those requirements. Due to the simplification it is assumed that a character's weapon's requirements are equal to the character's stats, without the limitations that would normally impose. That's why I went with the neutral names of Subtotal etc. Even when the formulae change, the variable names remain valid.

No one action can use less than 5 Power.

  Accurate, though I'm thinking I'll put that in each action's section instead of as an overarching rule (makes it easier to modify appropriately when I bring in some of the rules). Also, I support Intensity over Power because Intensity seems to me to suggest using all of your abilities (Strength, Dexterity, Intelligence in this case) better than Power.

Deals damage to target.
Implement: Weapon in hand.
Duration = X TUs.
Cooldown = X TUs.
Potential = AS*X/100
Effects:

    * If Potential exceeds opponent's Defence, deal the difference as damage.
    * If opponent's Defence exceeds Potential, add the difference to Cooldown TUs.

  Looks good, though I prefer execution and recovery to duration and cooldown. I think Potential is a good term though. Regarding Implement: Weapon in hand, that could also include unarmed combat, so I'm not sure that that's the best way to state it.

Provides additional defence against an incoming attack.
Implement: Weapon in hand.
Duration = .75*X TUs.
Cooldown = .75*X TUs.
Potential = AS*X/100
Effects:

    * If Potential is positive (y'know, I have a hunch that there's little to no way it's going to be negative), add Potential to Defence

  I'm not sure if you were alluding to this when you said 'Provides additional defence against an incoming attack' but a Defend is only effective against the attack it is initiated against.
  Your hunch is right, Potential won't be negative in this ruleset. There were several possibilities before I got the public version up where it could have been:
 

• Feinting and searching for weak points. They might have resulted in a penalty being applied to defensive actions. I cut them out due to possible balance issues, aesthetic issues (a successful feint would have forced the target character to take a certain action, which might have been detrimental to their experience) and randomisation (I didn't want a random component in the first ruleset).
• Originally a defence was almost guaranteed to intercept an attack (this is before I properly implemented the execution, calculation, recovery phases). If the attack was stronger than the defence, the difference would be applied as a delay effect to the defender. I stopped because I thought it was silly to offset damage after the attack had hit.
• Before I made the minimum intensity rule it would have been possible (though pointless) to defend at 0 intensity. I don't remember details but I did some fiddling with the formulae, some of which involved division, so I thought 'divide by zero' and put something there. I'm guessing I subsequently erased that something because I figured it would only confuse people.

Review the above. I think it manages to represent your current rules fairly accurately.

  Accurate as far as it goes. I hope you don't mind but I think I'll try and use your work there as a base for my next attempt at explaining the rules.

[Sean Mirrsen]

Of course I don't mind. What good would it be if it wasn't used?

Can you please elaborate on the "calculation" phase? I can't currently think of any instances where there'd be an intermittent phase between action's execution and the beginning of cooldown. (I prefer cooldown, since "recovery" would be better used on the character itself - as in, recovering after an attack)

"Implement" is for things that require an implement. If you're using the same formulas for unarmed and weapon attacks, use "(optional) Weapon in hand".

I once tried to make a sort of a detailed combat system. If you succeed, I might want to use your system in the (hypothetical) reincarnation of FATAL (as LETHAL, without as much XXX and with more common sense).

[Sadist]

Note1: I've currently got a bit of a bug which is affecting my thinking, so if anything seems illogical that could be the reason.
Note2: I only just got around to checking a dictionary. Discrete is the challenging bit, since just about everything feels connected to me.

Can you please elaborate on the "calculation" phase? I can't currently think of any instances where there'd be an intermittent phase between action's execution and the beginning of cooldown. (I prefer cooldown, since "recovery" would be better used on the character itself - as in, recovering after an attack)

  In its present usage the calculation phase can be thought of more as a marker indicating where in an action's lifetime the calculations are supposed to take place. Also, the three phases currently in existence might not be the only phases possible (eg a poison effect might not have execution or recovery phases in the normal sense, instead having a calculation and time_till_next_calculation phase). So each 'phase' could probably be considered to be a countdown and/or 'trigger' (at this point do x). The triggers can set off conditionals as well as simple calculations so I figure this will probably be flexible enough that I won't have to replace large chunks of the system if things get more complicated.
  Regarding cooldown, my primary experience with the term in gaming that I can remember would be either Starcraft or Warcraft 3, where it would mean the amount of time that had to pass before you could use an ability again even though you still had enough energy/mana/other stuff. As an example, imagine in CRS you are firing a laser machine gun. Ignoring some factors (like the unimplemented 'letting go of weapon' feature') we'll assume that it has an execution time of 10 TUs (time to fire one shot), a calculation time of 0 TUs (damage would probably be a separate calc done when/if the projectile hit, this would be something like heat generation), a recovery phase of 5 TUs (time for the capacitor to charge for the next shot or other technical stuff), and a cooldown phase of 500 TUs (if the gun overheats, safety mechanisms prevent it from firing, even if the capacitor is charged). While the terminology isn't what determines the gameplay effect, I think the above is indicative of the sort of scenario that goes through my head when I'm trying to come up with terminology which is part of the reason I settle on it.
  Regarding 'a character recovering after an attack' - I think what I have planned might make that a bit indefinite. For example, a character will be able to start an attack and movement action independent of each other. Would the character be considered to have recovered at the end of the recovery phase of the attack or the end of the movement? The attack would use one weapon and some intensity during its lifetime, while the movement would use some intensity and 'that which facilitates locomotion' (left vague to allow legs for walking, arms for crawling etc).
  Since I'm not sure I made it clear above, the interpretation of terminology can be affected by what it is applied to (eg a recovery phase for an attack can have a different meaning to a recovery phase for a character).

"Implement" is for things that require an implement. If you're using the same formulas for unarmed and weapon attacks, use "(optional) Weapon in hand".

  It could be a good idea to have a section called 'Requirements' with appropriate sub-sections (like required implements, possible alternatives (like the armed/unarmed situation) etc). Might not be as important with only one or two lines of requirements but should probably be used anyway for consistency.
  I'm still trying to work out how to handle unarmed combat. I plan to get armed combat more developed first before tackling it. The problems I can see are that if I try to use the same formulae, I'll need length, weight and other values for limbs and other body parts which is probably a bad idea due to complexity vs gain. Coming up with a whole other set of formulae could cause issues when the lines blur (eg punching with a gauntlet, without spikes, shouldn't require completely different calcs).

I once tried to make a sort of a detailed combat system. If you succeed, I might want to use your system in the (hypothetical) reincarnation of FATAL (as LETHAL, without as much XXX and with more common sense).

  I started this in the hope that other people would find use for it. I'll try and include design decision explanations for you (and try not to mix them into the rules proper) but I'm not sure exactly when I'll start (could be next version, with a lot of 'this is just filling in' and 'preparation for upcoming feature', could be a while later when I expect to do just fine tuning for the most part).
  You'll probably have some work to do to get the system to do what you want (I'm guessing you're aiming for realism or complexity, probably the former). As an example I don't plan to have left or right, instead having limbname1, limbname2 etc. Also, while I haven't settled on specifics, I might have collision detection (will be needed when movement and weapon ranges are in) with each character (possibly other objects like weapons) having collision spheres, with a blow that hits just the edge having a chance of hitting any part of the target. I'm not planning on locational damage in the Dwarf Fortress sense, probably I'll decide on a penalty that might result from the attack and optionally add a location as flavour. Once again, this is far from final.

[Sadist]

  I've rewritten the rules and I think I've got something normal people can understand. If no-one offers to criticise it I'll post the (non-exhaustive) rules up in about a week but I think it could still do with some improvement that I can't figure out.

[Sean Mirrsen]

Sure, put them up. I'm always ready to do some criticizing.

[Sadist]

  This is what I've got. The primary focus is on giving the player what they need to know to place orders and approximate their effects, so the formulae aren't included which would allow for more in-depth analysis.

Spoiler: Explanation of terms (click to show/hide)

  Hitpoints are how much damage you can take. 0 means non-operational.
  Intensity works as a combination of strength and risk.
  Delay increases the time that you have to wait before you can give orders to your character.
  Stamina affects your ability to do stuff. No stamina means no new actions.
  Time is measured in Time Units (TUs).

Spoiler: Context sensitive order system (click to show/hide)

Order syntax:
  Use [Object] on [Target] at [n Intensity]
    [Object] can be your weapon.
    [Target] can be your opponent, your opponent's weapon or yourself.
    [n Intensity] is the intensity you perform the action at (n is a number).


The interpretation of your order depends on the circumstances.

Code: (Targeting opponent) [Select]

  Use [Weapon] on [opponent] at [50 Intensity];
    This will result in an attempt to deal damage to the opponent (Attack).


Code: (Targeting opponent's weapon) [Select]

  Use [Weapon] on [opponent's weapon] at [60 Intensity];
    If your opponent is Attacking you, you will attempt to parry it (Parry).
    If your opponent is Batting your weapon, you will Bat back (Bat).
    Otherwise, you will attempt to deal delay to your opponent (Bat).


Code: (Targeting yourself) [Select]

  Use [Weapon] on [self] at [40 Intensity];
    If your opponent is Attacking you, you will attempt to block it (Block).
    If your opponent is Batting your weapon, you will attempt to move your weapon to safety (Flit).
    Otherwise, you will wait for your opponent's action (Wait).


Spoiler: General guidelines (click to show/hide)

  No action can have less than 10 intensity assigned to it.
  The order of actions, from fastest to execute to slowest:
    Block(1)
    Flit(2)
    Bat{3)
    Parry(4)
    Attack(5)
 
  The more intensity assigned to an action, the faster it executes, the faster it uses stamina.
  An action's power builds up as it executes. As an example, a strong attack can be beaten by a weak parry if the parry competes with it before it can build up much power.
  An action at 100 intensity does not have 10 times the potential power of one at 10 intensity; diminishing returns basically.
  The order of actions, from highest potential power to lowest:
    Parry(1)
    Attack(2)
    Block(3)
    Bat(4)
 
  If you run out of stamina during an action, you start accumulating delay as the action runs.
  You regain stamina at a rate proportional to the intensity you aren't using in an action.
  The order of actions, from highest stamina cost to lowest:
    Block(1)
    Attack(2)
    Parry(3)
    Bat(4)
    Flit(5)

 

Spoiler: Action specifics (click to show/hide)

  Attack:
    Attacking is the only way to damage your opponent and win the match.
  Parry:
    Parrying is the optimal way of defending against an incoming attack on your character. It is considered to have intercepted the targeted attack when the parry has reached half of its potential power.
  Bat:
    A Bat is an attempt to knock away an opponent's weapon to interfere with their use of it. Can cause delay to your opponent, giving you a time advantage. If the opponent Flits their weapon after you start to Bat it your Bat will automatically miss.
  Block:
    Blocking is when you interpose your weapon between yourself and an incoming attack. It is considered to have intercepted the attack it was started against when the block reaches 10% of its potential. Due to its high consumption-of-stamina-to-potential-power ratio it is only recommended as a desperation manouever.
  Flit:
    Flitting is simply moving your weapon around in front of you, which interferes with an opponent's previously initiated attempts to Bat it away. It doesn't do anything to hurt your opponent or defend your character though.
  Wait:
    All you can do when you are out of stamina is Wait. Automatically takes the minimum possible intensity.

Ask if anything is unclear. I prefer answering questions to losing prospective players.

[Sean Mirrsen]

Well, so far so good. We'll have to see how well it'll work as an actual system though.

It seems to rely on a sort of strategic combat (something I don't think you usually see, but whatever). Like some really advanced version of R/P/S, with timing thrown in. You could try to run a test in a quick-flowing medium (such as RL or IRC), it'll be much too slow on forums.

[Sadist]

It seems to rely on a sort of strategic combat (something I don't think  you usually see, but whatever). Like some really advanced version of  R/P/S, with timing thrown in.

  Yes. I wanted to describe it as 'like paper, scissors, rock, with varying degrees of paper/scissor/rockness, with timing' but figured that would probably be too confusing and probably uninformative. I was also going to say that the order-giving system was like from text-adventures or point-and-clicks but figured that that should only be included if there was evidence that it would help people understand it better.

You could try to run a test in a quick-flowing medium (such as RL or  IRC), it'll be much too slow on forums.

  I don't know anyone in real life who'd be interested and I'm unfamiliar with IRC. Having a day or three between each player's moves (or me being online) won't be a problem on my end, gives me a chance to double-check the calcs at my leisure and possibly fix behind-the-scenes rules if an error comes up. I gather some people play games by email, so I expect there are players who will find the speed acceptable as well.

[Sean Mirrsen]

No, it'll be fine for playing eventually, but you'll want some speed for testing.

If you can play fair, you can play yourself. For example, I put an action into the spoiler here, and you tell me how it goes against you - you'll have to write down your action before you see the spoiler.

Spoiler (click to show/hide)

Use (weapon) on (opponent's weapon) at (30) intensity.

Speaking of which, now that you have the "basic hookup" of the rules, you can start putting in details of combat. Define how many TUs will be spent on any given action, in proportion to the intensity. For starters, presume that both players are equal.

[Sadist]

Code: (My action) [Select]

Use [weapon] on [self] at [100 intensity]

Code: (Sean's action) [Select]

Use (weapon) on (opponent's weapon) at (30) intensity.
  For clarification:
    The 'match' starts at 0 TUs
    Both characters start with their maximums of 100 hitpoints and 100 stamina.
    Sean's character will be referred to as Red, with Sadist's character referred to as Blue
    Who's order was received first was decided by RNG, which chose Red.

  Red started a Bat at 30 intensity.
  Blue started a Flit at 100 intensity.

  Blue's Flit finishes at 0.25 TUs into the match.
  Red's Bat automatically fails but won't finish executing until 0.4 TUs into the match. (EDIT (18 March 2010): I think a copy-and-replace went awry and I ended up using the wrong formula for calculating execution time. The incorrect formula had Red's Bat continue until 1.3(recurring) TUs)

Code: (Status at 0.25 TUs into the match) [Select]

  Both character's hitpoint's remain at 100.
  Blue's stamina is at 90 (expended 10 stamina, recovered 0 stamina).
  Red's stamina is at 100 (expended 3.75 stamina, recovered 8.75 stamina).


If you can play fair, you can play yourself.

  I'll do that over the next couple of days. (EDIT(18 March 2010): Maybe a bit longer. Some of the old rules and formulae seem to have been mixed up in the same file so I'll be trying to sort them out and retest the balance.)

Define how many TUs will be spent on any given action, in proportion to  the intensity.

  One of the simplifications is that the time required for each action is instead affected by a (currently constant) speed value. So for this version of the rules I'll be able to give an absolute TU cost, then go into more detail when speed becomes variable. (EDIT(18 March 2010)

Code: (Prior text) [Select]

I'm thinking the simplest way would be to say the TUs needed at 1 intensity. Then players could multiply that value by the amount of intensity they were thinking of using to get the appropriate value (behind the scenes, the current actions don't have a TU cost but some of the simplifications mean that that won't impact on the game at present).)

For starters, presume that both players are equal.

  Both player's characters and their weapons are equal. I've assigned some values to them but haven't revealed them because the player's couldn't do anything with them and I expect I'll be doing some tuning before allowing customisation.

  Hopefully that was everything I wanted to say. The hour grows late and my eyes grow blurry. I think I got the example clash right, if I find otherwise I'll edit a correction in in the future.

[Sadist]

  Concise version: reviewing rules and balance, taking longer than expected, unsure of completion date but still dedicated.

Spoiler: Slightly less concise version that no-one will be interested enough to read all the way through (click to show/hide)

  I've scrutinised the rules again and I think I've got just the current ones in the appropriate file. I'm trying to include a 'beginner's section' which helps players get the basic info needed to play without getting bogged down in details. I haven't worked out whether to go for an 'encapsulated' approach (ie having all the "beginner's guide" stuff in the beginner's section), a 'directory' approach (ie have the beginner's section contain references to specific parts of the more in-depth sections and expect a prospective player to jump back and forth) or a combination of the two.

  As I've alluded to previously, there is a fair bit of detail that is hidden from player view at present. For example, that 'minimum intensity per action' rule is actually based on the character's strength and weapon requirements, though that part of the system is quite WIP. Anyway, while most of this complexity is hidden from player view while they have no control over it, I'm still using the more detailed rules where possible to increase the chances of finding errors before bringing the players in on them. As a result it hasn't been a simple case of balancing time and stamina costs for each action, since I also try to make sure that changes I make will still be valid when another couple of features get introduced.

  Ironically one of the simplifications has contributed to this extended period of non-public activity. When it was suggested that I provide a time cost for each action as a guide I figured it wouldn't be a problem, since Action Points are currently accumulated at a constant rate it is a valid conversion but in testing I consistently failed to do the conversion when writing up status reports. Because of this and other potential issues I've started working on the simulation program so that I won't need to remember the calcs. Problems I've had so far:

• It involves file I/O, to facilitate data entry and presentation. I find file I/O difficult and usually try to avoid it, which is probably part of the reason my projects keep on dying. I think I've got at least part of a solution worked out this time but I won't know until I run into a problem with it.
• Planning the format of the file is problematic. The choice as I see it is to only do a basic thing that will need redoing after the first feature change/addition, or to try and come up with something that will be easily expandable as features develop. I'm leaning towards the former, which still leaves the question of whether to do it at player-level complexity or GM-level.
• I admit it, some of the time that I could have spent coding has instead been spent playing Master of Orion, a temptation that will probably persist for a while yet. Thing is, the days I set aside for play are when I come up with most of my solutions, it's just that I don't get around to implementing them on the same day.

I think that's all for now from me. I realise it's probably boring to go through but it helps me think so I'm likely to continue doing it.

[Sean Mirrsen]

What's your problem with file I/O?

[Sadist]

What's your problem with file I/O?

Note: I'm coding in C++

  I think a large part of my problem with it is parsing a file to get the data back out of it. Up until a couple of days ago I thought that I would basically have to read a line into a character array, break it up into individual words, then do a test involving strcmp() on each word against a set of known words, variable names etc. Then I figured I would have to use another method for dealing with numbers (something like atoi() for integers, something else for floats and so on), all of which seemed like too much effort, especially when I kept on making mistakes like treating a non-zero return from strcmp() as a match.

  Since then I've found out that std::string seems to go in and out with little trouble and has an equivalence operator which does the comparison in a more foolproof manner and even automatically handles both char* and other string arguements. The other problem I have/had was with possible confusion with reading numbers in - telling whether it was an integer or a double for example (I guess that proper planning is supposed to ensure that you always know but due to exasperation at the previously mentioned mistakes I didn't get around to testing that theory). I've made a little class which I think will fix that problem (a template<T1> class with a std::string as a 'variable name' and a T1 for the value) but have yet to put it through practical testing.