Tuesday, 24 June 2014

Attacking and Defending

There's a stylistic divide between combat styles that I usually like to see represented - the difference between a light, nimble, agile warrior, and the heavy, slow, strong warrior. Since I'm currently thinking about a game called Thunder Hunters where you get to hunt dinosaurs, it's a topic that's been on my mind.

This is me talking through my current design problem, so it's going to get a little long and technical.

In my PowerFrame RPG, characters have Attack, Avoid, Damage, and Toughness ratings. Attack opposes Avoid to score a hit, and Damage opposes Toughness to figure out the severity of the hit. In PowerFrame, the attacker and defender make opposed rolls, so there's a total of four checks for a successful attack. For Thunder Hunters, I'd like to try and cut that down a bit.

I'm also currently working with a d6 dice pool system. Stats would be rated from 1 to 6, which represents the number of dice you roll. Your opponent's stat is the target number you need for success.
For example, with an Attack of 4 against Agility of 5, you'd roll 4d6 and count one Success for each die that rolls 5 or more.

Two Rolls


To capture the fast vs tough divide, my initial thought was to have four stats that determine basic combat performance:

  • Attack, from a skill you can develop.
  • Damage, probably defined more by the weapon than the wielder.
  • Agile, representing mobility.
  • Robust, representing resistance to damage.

That's pretty much the same setup as PowerFrame, but the system works a bit differently. The defensive Agile/Robust are static target numbers, so that halves the required number of rolls.

  • The attacker rolls Attack, counting Successes against their opponent's Agile.
  • If they score at least one Success, the Attacker adds the Successes to their Damage and rolls that many dice against their opponent's Robust.
  • Successes against Robust allow you to create advantages or wear down your opponent. Enough Successes allow you to inflict a Kill result.

Advantages


  • It's possible to model things that are hard to hit and accurate but weak and fragile, and at the other extreme model things that are easy to hit and dodge but strong and tough. It's also possible to model things that are other mixtures (accurate and damaging, but slow and vulnerable), or even good or bad in all categories.
  • It's easy to use different stats to deal with different attack types (for example, you dodge both a strike or a grapple with Agile, but use different stats to resist their effects).
  • This spread of stats provides more dials that can be fiddled with in combat, potentially resulting in a richer simulation.

Disadvantages


  • You still have to roll two dice pools.
  • Two rolls to resolve an attack might not be consistent with the rest of the system, reducing things outside of combat to a simple single roll.
  • With only 1 Success needed to result in a damaging attack, the chances of dodging outright quickly become very slim.
  • Perhaps in the end, making two rolls is just a longer way to arrive at a singular probability?


One Roll


I am also experimenting with a different approach. The only two stats are Attack and Defence, with Successes on a single Attack roll resulting in combat advantage.

Weapons, armour, and other equipment would let you modify your Attack pool or reduce that of your opponent.

Advantages


  • You only need to make one roll, so resolving an attack is fast.
  • It's consistent with other single-roll non-combat skill usage.

Disadvantages


  • You need different resistance stats to deal with different types of attack (wound, grapple etc). Since you need these stats in the two-roll system anyway, I'm not sure if it's a disadvantage. However, something irks me about having a bunch of monolithic defence stats rather than being able to see the separate components (Strike Defence and Grapple Defence would both contain a measure of agility).
  • You lose the fast/accurate/strong/tough divisions. There's only dangerous/tenacious. While I think this could work very well for a game where the expected opposition is similar in capability to the PCs, I think in a game where people hunt dinosaurs it may not offer enough scope to describe the capabilities of different creatures.



At first blush it seems like a reasonable approach to have small Theropods be low Danger and low Tenacity, and larger ones such as Tyrannosaurus be high Danger and high Tenacity. It seems fine to be able to kill smaller raptors more easily and struggle to overcome a T-Rex. However, something was bugging me.

Then I thought a bit about traps. Imagine a spiked log swinging through the jungle. It scatters a pack of raptors; if it hits them it'll kill them, but they are small and agile and have time to get out of its way. Now imagine it swinging towards a T-Rex. It probably doesn't have time to get out of the way, but the wounds inflicted may not be fatal.

Ideally, this is how I view combat: against small, fast opponents there should be a low chance of hitting for a lot of damage. Against larger, slower opponents there should be a high chance of hitting for a little damage.

Where the single roll falls down is that against small enemies a dangerous attack has a high chance of doing a lot of damage, and against larger enemies it has a low chance of doing a little damage. The accuracy probabilities are out of whack. If we consider it in relation to the log trap example, it'll probably work almost as well against the T-Rex, but it will obliterate the pack of raptors.

In the end, using one roll won't replicate the probability of the two-roll method if we care about the effects of accuracy and damage, agility and toughness. That said, in many cases even a high Agility won't allow you to evade an attack altogether. If you're either going to get 1 Attack Success + 4 Damage against Robust 3 (average 3 Wounds), or 3 Attack Successes + 4 Damage against Robust 5 (average 2 Wounds), it's almost worth reducing it to one roll for simplicity's sake anyway.

Options


I'm still mulling over the pros and cons, looking for options I might have missed.

It might be possible to apply damage and toughness as set numbers on top of the initial Attack roll, or based on it somehow. This would cut back on one of the rolls, but I'd have to make sure the numbers work and it's not too dull.

I might be able to define defensive stats by combining two other stats: Against strikes, use Agile + Robust. Against grapples, use Agile + Might. It would require me to rethink the way I'm setting up the stats, but that's not necessarily a bad thing.

There's this weird thing where I imagine an attack from a raptor and a T-Rex. The raptor is smaller and faster, but the T-Rex has much greater reach and a huge attack zone. Even disregarding the lethality of the hit, I can't see it being any easier to dodge the bite of a T-Rex than to avoid a man-sized raptor. So, it seems like Attack rating may actually go up with size, rather than down.

That also plays into my current Action Point system - I want to make being chased by a T-Rex daunting, by having it cost more to dodge its attacks. This sort of feeds into the feeling that I could reduce things to a single roll. If I reduce accuracy with size, it would be easier to dance around a T-Rex for days. If I reduce its attack rating, I'd have to come up with some other mechanism to drain AP.

Things are all up in the air at the moment, and I really need to get some stuff down on paper and see what happens. I think I'm probably going to work on the two roll system, but I'll keep an eye on it and see if I could somehow collapse the necessary stats to use the one roll method.

Sunday, 15 June 2014

Finished Writing PowerFrame

Today I have substantially finished writing the PowerFrame RPG!

That's not to say it's ready for release, though.

What next?

The document is currently 231 pages long, and I'm aiming for a total length of no more than 240 pages. Although I've written all the rules for the current content, I could add some more sample spells (or maybe take some out), and I'm considering whether or not to add some sample helicopters, lighter-than-air ships, and spaceships to the Vehicles section. If I do that, I will have to write a few additional paragraphs of specific rules for them. Apart from that, I also need to put together an index.

In addition to any content tweaks or additions, I need to go through line by line and do a final proofreading and editing pass. I know it's not that wise to edit your own work, but this is a labour of love so I can't afford to hire anyone else to do it. I'm pretty good at catching errors though, so hopefully there's not too much to fix. I think the main thing will be that, given the few years between starting and finishing, I may have changed the way I present certain information or use the formatting, so I'll need to audit the document for consistency.

The other major tasks are to produce good versions of several stand-in diagrams, and to draw and colour many illustrations. I suspect the illustrations will take a substantial amount of time, so it will be at least a few more months before it's ready for release.

Monday, 9 June 2014

Rolling Along

In further PowerFrame RPG vehicle work, I've pretty much written up the details for skates, skis, surf/snowboards, a variety of pushbikes, and also horse-drawn vehicles such as carts and wagons.

Skates/boards and pushbikes give the user a new Movement Rate based on one of their Abilities - Acrobatics or Bike. Although movement is potentially much faster than walking, you can't just change direction on the spot or necessarily come to a dead stop safely if you're travelling at speed. Another major factor for all these vehicles is the gradient. They are slower going uphill, and faster downhill. I haven't bothered creating a detailed range of grades - up, down, or flat is enough.

Carts and wagons are drawn by animals (or, in the case of hand carts, people). I know most people ignore encumbrance rules, but PowerFrame has a fairly simplified system. Wheeled vehicles reduce the effective weight of carried items, and pulling too much stuff reduces your speed of travel. While you can just quick-reckon it, when it's important you can figure out exactly how fast a pair of horses can pull your fully-laden wagon.

Still to come: motorised ground vehicles, sailing and motor boats, and aeroplanes!

Sunday, 8 June 2014

Power Armour in PowerFrame

I've been working on PowerFrame's Vehicles section - the final bit of writing. I'm presenting some basic templates for various types of vehicles, including skates, pushbikes, motorbikes, cars, tanks, boats, planes, and power armour.

I spent today writing up Power Armour. This is the first vehicle type I've completed. Although you might think it would be easier to start with cars and bikes, there are several factors that actually make powered armour relatively straightforward.

Oddly enough, I don't have all that many pictures of power armour.
This illustration of the Amethyst Warrior from the techno-fantasy PowerQuest setting is over a decade old!

Firstly, PowerFrame is built around the human average. Pretty much everything is rated based on how it compares to human capabilities. Since power armour basically just augments the pilot's own capabilities, it's not that hard to describe in game terms. Something like a car is trickier to model because it moves so much faster than a human (thus requiring a whole new Hex scale), can't turn on a dime, and takes more than one Turn to reach top speed or slow down.

Secondly, power armour has been in the game since its inception. The original PowerQuest setting (from which the PowerFrame system takes the inspiration for its name) was a fantasy world where the technology from a crashed spaceship had become integrated into culture and legend. Finding and reassembling the components of a suit of legendary power armour was the aim of the main campaign arc. The overwhelming power of this armour set the upper limits for equipment performance, and formed the basis for high-tech gear when I detailed more generic futuristic source material.

Lastly, I'd already done a lot of work running the numbers for power armour a couple of years ago. It took me a while to get around to, because I had to calibrate the stats for armoured vehicles so they'd make sense compared to personal firearms, and because I had to simultaneously revise the stats for heavy weapons. Once I'd eyeballed the numbers and floated them past the existing armour and weapon stats, I had a reasonable range in which to define powered armour and vehicles such as tanks and mecha.

Technically a small mecha, about Size 2 in PowerFrame terms.
(From District 9, image not mine!) 

Power armour has appealed to me for a long time, and its representation in PowerFrame is inspired by anime such as BubbleGum CrisisAppleseed, and Ghost in the Shell. In live-action movies, the power armour in District 9 is one of the coolest representations I've seen in years. Despite potential real-world battlefield issues, power armour gets to be the "katana" of the future - cool, exotic, and with unrealistic performance expectations.

I ran a very short game involving powered armour to make sure the rules were functioning as expected. I actually went really in-depth and made a detailed system for describing power armour and mecha in various sizes and configurations, and with mixed component weights. It creates good output, but it's pretty complicated and really requires a spreadsheet during the construction stage, even though the output is relatively straightforward. After the test game, I decided to remove the separate Structure values for each component, and just have a single Structure total.

In the Book


Unfortunately I don't think I have the space to include full power armour construction system in the main rulebook. For starters, if I did that I'd have to write similar systems for cars, bikes, ships, planes, and spaceships, and the page count would blow out. It's a bit of a shame to fall back on the assumption that all power armour is designed around humans, but to be honest PowerFrame does get a little awkward when dealing with creatures like centaurs from a Hit Location perspective.

The book will feature two pages detailing seven different "frame" weights, from Ultra-Light to Ultra-Heavy, all at Size 0. These are basic exoskeletons, but the players or GM can equip them with various types of armour, weaponry, and other systems to create a complete suit of power armour.

The listed suits are pretty advanced models, but it's a simple matter to dial them back a bit to represent older models, or boost them to represent truly over-the-top supertech armours.

There are also rules for increasing the suit's Size, so you can easily modify the existing templates to create "landmates" and mecha. I can also use the spreadsheet to work out reasonable baselines for other large vehicles such as tanks, ships, and spaceships.