RPGs: Who does what?

The last post talked about initiative systems. I’m going to use the same systems to talk about how actions shape encounters, so here’s a quick recap:

  • Ironclaw: Team-Based. The team that initiates goes first. Each team chooses the order of characters to act.
  • D&D: Character-Based. Order of characters to act is randomly chosen for the combat.
  • Shadowrun: Character-Based. As D&D, initiative is per round and higher initiative characters can have multiple turns in a round.
  • Arcanis: Active Time. Characters are on a clock, and actions advance that clock. Characters at the current “time” act.
  • ParagonActive Time.  Characters have a priority, that actions increase. Lowest priority characters act before higher characters.
  • Mouse GuardDeclare and Resolve. All sides declare their actions secretly, then actions are resolved.

I want to talk about Action Economies. Each system has different ways of expressing how a player gets to act when their “turn” comes up. Each system also handles actions differently.

Systems like D&D and Shadowrun lump their actions into different categories. Generally, things like attacking or casting a spell or some other “I do a thing to someone else” action is considered more valuable than repositioning or interacting with an object. Thus, while players can generally “trade down” and move twice instead of attacking, generally this is only done when the “Major” or “Standard” action won’t fit here.

Ironclaw and Mouse Guard give their actions equal weight. All available actions are always able to be substituted for other actions, whereas in D&D you wouldn’t be able to substitute “interact with a door” action with an “attack that guy” action. Here, you can. This causes a new host of balance issues, where every action has to be balanced around every other potential action.

Arcanis and Paragon use the Active Time system, so they’re somewhat locked into balancing actions based on the delay they cause. Someone swinging a sledgehammer is going to take longer to act again compared to someone slashing with a knife. However, Captain Sledgehammer is going to be way more effective if he hits (ideally, slightly disproportionately more) than the knife-swinging slasher.

As a contrived example: The Knife attack may take 2 delay, and do 3 damage if successful. The Hammer may take 4 delay, and do 7 damage if successful. This is balanced. The Knife attacker may do less damage per hit, but has twice the opportunity to do any damage. The hammer user must have stronger hits, but quicker enemies may be able to constantly dart away before the hammer user can act again. Or: consider if an enemy has 9 health. The dagger kills it in 3 hits, which uses only 6 delay, where the hammer user kills it in only 2 hits but uses 8 delay.

This Economy of Actions is what makes encounters interesting.

Action Economics are Fun!

The way in which players decide what to do, what’s valuable, and what’s presently useful is what makes these encounters fun. Is dodging in D&D better than attacking? Maybe! If you’re surrounded by nothing you can disable, it’s probably better to live another round and Dodge and hope your party can assist. Has your monk gotten himself surrounded, again? You probably want to Attack and help him out (again). Shoving someone 5 feet away from you: probably less useful than attacking. Shoving someone 5 feet away from you off a ledge: probably better than attacking.

Where the game designer can shine is the available choices for the party. Sure, trying to Scare someone in Ironclaw might immediately end your turn and make you vulnerable to attacks, but that won’t matter if you terrify everyone into running away. Varying the power (more damage, potential to incapacitate) with the drawback (takes longer, possibility of being vulnerable) makes for interesting choices. Do I want to try and remove this guy from combat, knowing that if I fail I’ll be very vulnerable? It depends.

Players might have different philosophies on how they want to play. Some like high-risk high-reward. Others value consistency. Often, players want to access both. Sometimes the knife user needs an all-out attack to end it now before it ends them next turn. Sometimes the hammer player throws a quick punch to knock someone out so they can get back into the fight quickly.

The types of actions that the players can perform, and how often they can perform them, shapes how the system informs the narrative. The nimble rogue darting in and out slicing quickly with his dagger is more visible in Arcanis (more chances to act) than D&D (Standard action to attack, maybe a bonus action to off-hand strike). The raging barbarian shattering his enemies with raw fury is better shown in D&D (each attack crushing a foe) than Arcanis (more impressive hits, but less flashy due to the slower time).

What players want to do should be what they can do (within reason). The better a system can reflect that, the more the players will enjoy it.

RPGs: Who goes first?

Initiative Systems are one of those mechanics that don’t seem complicated. Like most things in games, they’re an abstraction . Trying to model everyone going all at once in the middle of a fight would end poorly. What’s interesting is how different systems handle this.

Team-Based Turns

Determine the order of teams to act. Each team decides how their characters will act, and in what order.

Ironclaw does this most notably. The side that initiates combat goes first, in whatever order the players choose. Then, the other side goes. While simple, this leads to two main problems:

  1. Larger groups make this system harder to manage (Who’s gone already?  Who hasn’t? Who’s going right now?)
  2. Whoever goes first has a massive advantage.
    • This problem is made even worse but the first problem

Ironclaw solves problem 2 fairly well. Each side rolls Initiative, but instead of determining the order, it determines readiness. One of the possibilities of readiness is to be “Focussed” which allows the character to perform an action outside of his turn. This makes the first round unpredictable instead of a steamroll.

Character-Based Turns

Determine the order of characters to act. Each character then gets to take a turn, in order, often performing multiple actions.

D&D is most known for this. At the start of combat, everyone rolls for initiative. Order it from highest to lowest, and those characters go in that order. Faster characters tend to go closer to first but can vary in the exact order. Unprepared characters may still go first, in contrast to the previous example.

Shadowrun uses a modified version of this; each round initiative is rolled. After each character has gone (one “Pass”) subtract 10 from everyone’s initiative, people with positive initiative get another turn. Continue until no one has a positive initiative.

This type of system scales well but doesn’t allow for as much on-the-fly strategizing as Team-Based systems. Additionally, characters built to always go first can get screwed over with the die rolls, meaning they may not go soon enough to trigger what they need. Similarly, reactionary characters (like healers) may end up going first, and have nothing good to do.

Shadowrun’s system provides an additional problem: slow characters don’t get to do much. The mage gets to do 1 thing per round, but the cybered-out lunatic gets to take 2-3 turns.

Active Time Systems

Players have an initiative value. Actions modify this value by an amount dependent on the action. The initiative value determines who acts. 

These systems are a lot more interesting since there’s no turns. When the character is up to act, they act, then someone else has priority. I’ve seen two systems that do this, Arcanis and Paragon.

Arcanis does this with a clock system. Everyone rolls one or more d10 and writes down the lowest number as their clock value. There is a master clock that starts at 1 and advances one “hour” at a time. Each action advances each character’s clock value by a different number (Swinging a massive axe might advance it by 4, whereas swinging a one-handed sword might only advance by 2). This allows for a little more accurate combat, where characters doing slow things take fewer (but often more impactful) turns.

Paragon does a priority system. Your roll initiative, and assign increasing priority in decreasing initiative roll (if A, B, and C roll 8, 12, and 2, the priority would be B=1, A=2, C=3). Each action increases your priority similarly to Arcanis. However, each reaction also increases the priority. This can create interesting strategies where one character can be pinned down by spending time to dodge attacks, without ever getting a chance to react with an attack of his own.

This is my favorite system but also has a few problems. From a design standpoint, it’s trickiest to balance since you now need to weight actions against how impactful they can be. Additionally, it’s also the hardest to keep track of. Arcanis’s clock worked well but Paragon required a shared whiteboard to adequately keep track of.

Declare and Resolve (Simultaneous) Systems

Everyone decides ahead of time what they will do. After everyone has declared, resolve the set of actions. Repeat until combat is over.

Mouse Guard (and, I assume, other Burning Wheel games) has both sides declare a number of actions at the same time, and resolve everything simultaneously. This system has only 4 abstract actions (Attack, Defend, Feint, and Maneuver), and have a sort of rock-paper-scissors effect (Attack beats Feint, Feint beats Defense).

Unfortunately, that’s also why this system works. Attempting to declare specific actions (I’m going to move here, then I’m going to attack that guy) doesn’t work as well as more abstract actions (I’m going to do a Maneuver, then I’m going to Attack). It works for some games, usually more narrative-heavy, but not ones that work better with tactical combat.

Which System works?

Cop out answer: all of them do, in their own systems.

The reason for this is mostly thematic. D&D has a particular battle style largely because it grew out of wargames. Mouse Guard has a battle style that’s thematic. Ironclaw has a system that reflects how its action system works. Modeling combat is hard, so go with the next best thing: something close that fits the game’s style.

But really, which one do I use?

It very much depends on the game. Tactical combat works better when the players know the order of events, either the order of the Characters or Teams. Thematic games with more abstract combat are better with a Declaration method since that’s somewhat close to how a combat would play out. Active Time systems are good when the system is trying to highlight the differences : between actions.

What if I want something different?

Other ideas for initiative systems that I’ve heard about or thought of:

  • Nomination: the current character chooses the next character to act, but it can’t be on their team.
    • Upside: Sides are usually balanced, and can create interesting tactical choices of who to choose next.
    • Downside: somewhat easily gamed, especially by a GM that can obscure information. Weird with unbalanced sides.
  • Card Draw: Each character has cards to represent them. Shuffle the cards together in a deck, and draw. That character gets to act.
    • Upside: Good simulation of chaotic combat. Have to make tough decisions on who acts when. Easy to use regardless of systems.
    • Downside: Requires another game component. Can be too unpredictable.
    • Possible Modification: Have the top 3-5 cards be visible to allow for some planning.
  • Order Declaration: Like team based, but instead of randomly choosing who goes first, each side secretly chooses the order for characters to act. Alternate sides as characters act.
    • Upside: Interesting choices but hard to “game.” Characters can’t get screwed over by randomly bad initiative rolls.
    • Downside: Most of the other problems as Character-Based systems. High potential for Analysis Paralysis.

What even are blogs

I’m bad at blogging. Last post was a year and a half ago. Since then, I’ve gotten a new job, I’ve started prototyping an RPG, I’ve done a small amount of tools development. Professionally, I’ve been trying to make Good Tools for Good Websites and generally make sure everything runs smoothly.

I’m going to try blogging again. Almost two years ago it was helpful to organize my thoughts using it, and now that I’m working more actively on my RPG I’m going to try it again. The next posts will be talking about tabletop RPG mechanics and why I find them interesting. Occasionally I might post about something like why I like React.js or some other software thing, but I have RPGs on the mind right now.

Job Search Organization

A few days ago I talked to a friend about what the best way to go about searching for jobs. Career Fairs used to be the way I found good job leads, but that works less well when you’re not a college student.

He gave me a few good tips (most of which were checking with friends for job leads) but the big one was how to organize everything. Organizing everything into a spreadsheet helps quite a bit for keeping track.

Excerpt from the job search spreadsheet I use.

Application and response date are helpful if you get rejected and they tell you when you can re-apply. Location helps with comparison (e.g. one offers you 80k but you’d have to move vs 70k and it’s a short distance away). The main thing is the Action column; it’s used for at a glance “do I need to email/call someone?” That one is particularly helpful if you get a response with enough time to update the spreadsheet but not enough time to prepare a proper response.

Other columns that may get added later, as needed.

  • Desirability: Rating scale of how much I want to work there
  • Qualification: Likelihood I’ll get a positive response
  • Interview Date: Helpful in case multiple interviews get scheduled, although this is also solved with a calendar.
  • Contact: Who’s been talking with you through the main process (including Contact Email and/or Phone).
  • (Expected) Salary: If you can find this information.

Creating a Tabletop RPG

The first project I want to work on is probably my oldest unfinished project. A few years ago I ran an Independent Study with a group of other students to try and make a Tabletop RPG. We ended up having 8 members instead of 3, which meant that we could do more more. So we divided up the components (classes, spells, items, mechanics) and set off.

It turned out to be a total mess. The mechanics felt like 4th edition D&D, the classes felt like 3.5 D&D, the spells didn’t feel like either, none of the items really fit the mechanics, the entire system way just a disjointed mess.

So I’m trying this again. Instead of shooting for a complex system, I’m going to go for a simpler system. I want the entire thing to be contained in 5-10 pages (which includes everything from items to rules to character creation). I want it to give a coherent view of the setting (Future Earth; Cyberpunk setting, no magic this time). I want it to have a themes or ideas that the person running the game can easily use. For example: you could replace your human limbs with mechanical ones to enhance your abilities, but at what point do you stop being human?

At this point, it’s just a matter of putting the thoughts to paper and just doing the work. Then endless playtesting and revisions until the game’s in a good place.

Making Good Art

About a year ago (at what I imagine is the same time everyone else discovered him) I ran across a comic with a Bill Watterson quote done in Watterson’s style. I started at the beginning of Gavin Aung Than’s Zen Pencils and started reading. Eventually, I came across a comic for a quote by Neil Gaiman titled Make Good ArtYesterday’s post was inspired by the first five panels:

Life is sometimes hard. Things go wrong, in life and in love and in business and in friendship and in health and in all the other ways that life can go wrong. And when things get tough, this is what you should do.

Make good art.

I took everything I was feeling and channeled it into something besides feeling bad for myself. Now that I’ve done that, I feel so much better for it. Everything that I’ve kept bottled up has been impeding me likely more so than the original problems I talked about then.

This is the reason that I started posting to this blog again. I’ve went out removed a lot of out of date or sub-par quality posts. I’ve updated my resume and professional presence.

I’m going to go back to trying to be the person I want to be instead of settling for the person it’s easy to be. I’m going to make good art.

Why am I even doing this?

Yesterday, I was let go from the company I’ve been with since I graduated college a little more than a year ago. While this sucks, I did get some opportunity to think about the past year about working there and its effect on me. I’ve pushed myself to become better at development given tasks that often seemed impossible at first, but the most important thing I discovered was its effect on my free time programming.

Specifically: I now hated development work.

This was one thing I was warned about going to work at doing what was effectively a hobby: that I’ll grow to hate it. But that wasn’t the case. At first.

What happened was that I repeatedly ended up venturing into the “Deep Code.” This “Code” was basically legacy code that hasn’t been around that long but is just as bad. Missing comments, massive functions, horrible naming schemes, unnecessary events or delegate or whatever else that makes it impossible to track down. This was fine; I could deal with this. Then I ran into this gem of an error message:

“Only task that a in fact list of task implement his method”

This is not the result of a previous employee’s poor grasp of English. This was not an issue with translating one language to another.

This was the result of not caring.

I could always see the cracks in the company, but everything held together. Inconsistent punishments and rewards, light gossip, lackluster management, the standard stuff in a Dilbertian office environment. It wasn’t that bad. I could deal with that. I could go home and unwind. I’ve got a lot of great games to de-stress, there are some shows I can watch, everything’s great.

One day after work, I opened up Unity and started working on a small script to start off some of the functionality. A vague feeling of unease came over me. I wanted to do literally anything besides code. I couldn’t bring myself to even begin thinking about how the code would work. This was my project that I wanted to do, and just couldn’t do it.

When I encountered that error message some months later, it was so strangely worded that it almost seemed like a Zen Koan. It wasn’t, but ironically, it did cause some introspection. When I ran into the Koan Error, in sheer frustration I asked:

“Why am I even doing this?”

I realized that this was the question I needed to answer. Why was I still doing this? I hated this. I could do it for money, but as soon as I got home from work I would be damned if I was going to do anything that reminded me of work. Much like the author of the Koan Error, I had stopped caring.

hated programming.

The first time I touched code was on a TI-83. For our Algebra 2 class, the teacher had us program a few things (solving intersection of a line, quadratic formula, etc). This merely consisted of putting the code on the overhead and telling us to input it in order exactly as shown. No explanation of what individual lines did or what their purpose was.

I learned from it anyway. This was the only outlet I could reliably use to learn programming, since our school had no coding class and my parents had no knowledge of it. Every time we had an algebra lesson (and later, chemistry), I had a new program ready to go to automate whatever the lesson was that day. I brought a link cable and distributed it to classmates for homework help. I accidentally ended up getting programs on the calculator banned during tests (unless you were the one who wrote them).

I shortly realized that what I was doing was taking input, manipulating some numbers and showing some output. I thought, isn’t this basically what a video game is? Could I make that?

As it turns out: Yes, I could. I made a simple RPG called “Bunny World” (due to the turn-based combat using the only two ascii sprites I could make, a stick figure and a bunny), and my friends loved it. I kept improving, cranking out a dungeon crawler and a pure text-based adventure game in my last year in High School.

About six years later, I hated programming. I would wonder, why am I even doing this? I had lost sight of what to me into it in the first place: expression. Not only could I make games, I could make tools. I could make basically whatever I wanted if I only spent the time to.

I was so caught up in all of the nonsense of my day job, I couldn’t bring myself to move beyond it and create. I missed creating.

Creating awesome content is why I’m still doing this.

KeySmith: A New ActionScript 3.0 Keyboard Manager

Every time I need keyboard input in a flash application, I have three options:

  1. Use the built-in event handler
  2. Use what’s supplied (usually only for certain programming assignments)
  3. Make my own

Option 1 is not an option if I need to do anything better than check if it’s down at all. I can’t use it for anything to detect a simple button press (up this frame and down last frame) or anything more complicated than detecting if a button is down or released.

Option 2 is usually not much better and only available on a few assignments. Usually it’s only slightly better than normal and functionality can vary widely from program to program. I want a certain degree of consistency.

Option 3 has so far been the best, but is usually time consuming. I had one that I would reuse, but it was very limited without having to go and touch the base code. As the programs got more complex, it became more cumbersome as I had to work around the limitations.

I decided to make another keyboard manager, and this time with every feature I could ever practically seeing myself needing. I’ve made it as extensible and optimized as I could make it and made sure to fully document it as well.

I would like to present the KeySmith Keyboard Manager.

You can download and use it on my Projects page. It’s free for anyone to use under a Creative Commons license.

Greetings to the Internet

This blog is currently under construction (in fact this post’s purpose is so I can test a few things), but I hope to have it up and ready soon.

Anyway, This site covers everything about my interests in programming and Game Design, as well as my portfolio and resume for any prospective employers.

I’ve always had an interest in Game Design in one form or another, constantly tweaking the rules of existing games to make them “better.” It wasn’t until High School that I seriously considered it, when I made my first game on the TI-84 calculator: Bunny World. It was a simple Turn-Based RPG, but people liked it, and now here I am. I have since expanded my area of expertise to ActionScript 3, C#, and C++, with some basic Java.