The Artifact RPG

Yup, I’m thinking about computers and hacking again. I’ve been wrestling with some technology trends that are on the horizon. One is AI. Another is quantum cryptography. I have tried to avoid these technologies or explain them away as “like what we have but amplified” but I think I’m going to change tactics for fourth edition.

When asked about why there are no fully autonomous robots on The Artifact, my answer has been that autonomous systems are dangerous because they could be turned against you by the Chezbah. I think that’s still the right answer but I’m thinking of making some changes.

For one, it’s important to recognize that E-Suits are semi-autonomous AI. I haven’t delved into that much in the past but I’ve had some thoughts that might make that come front and center and make hacking a more comprehensible process.

I’m thinking that Artifact computers operate under a different security paradigm than ones developed on Earth. Since these are advanced computers, their software might appear intelligent to us. Not a human level general intelligence but something on par with a dog, horse or cat, sculpted to a purpose. They recognize their owners for access control and can carry out some tasks on their own.

These AI only respond to other AIs they recognize for security. They can be tricked however. I’m thinking that Comm Officers might have an AI that can make itself appear like a recognized AI, an AI doppelgänger if you will.

From there a hacker can deploy viruses, but the AIs all have their own immune system. They can overcome the effect of a virus in time (possibly in a few turns for example) and then become immune to it. This fixes the problem I was having with a virus taking over all the Rall4s in the fight. It enables limited use hacks in a short amounts of time (combat turns) but makes them temporary effects.

Another change I think I want to make is making hex mainframes and Hosent follow this kind of logic also and that you’d have to convince them to work for you. The other thing hex mainframes have to do is to have a sense of what is going on inside their hex. There’s a technology called conduction mapping in the players handbook that would fit this bill nicely. This would make talking to a hex mainframe very useful and also might make destroying the mainframes very important when you want to hide.

The Artifact has always been a heavy game there’s no reason to shy away from that. Because of that though, I have to be careful to not let it get worse.

For 4th edition, I’m trying to tie a lot of individual rules into a single set of rules called stunts. They tie the results of successes into sets. That allows me to put them on the character sheets for players to easily reference.

I’m contemplating a slightly different system though. My thought is that each success can cut a number in half. Any number the player wants. That simple rule would handle most of the things stunts do. The down side is that it could lead to some analysis paralysis. It’s so open that a player might not be sure what option to pick, especially if they’re not familiar with how the mechanics of the game works.

There might be another effect or two that I need to include to do everything that stunts do so it might not be exactly that simple in the end.

It’s an interesting choice. What’s easier to handle? A list of specific mechanical options? Or a few flexible rules that don’t by themselves offer any guidance.

The Artifact is a very cyberpunk inspired game. As such, there are hackers that can be played in the guise of Comm Officers. Opposing them is the Chezbah Priest with their ability to connect to any computer they want to.

Sadly, I followed a model of hackers that is realistic but a failed model for RPG play. In my defense, many games followed the model of the hacker acting at a different time than the rest of the players.

So that needs to change. The question is how? I have several ideas but I want a clear concept of what the actual mechanics of the computer infiltration is and how the game mechanics support the action. Some of them might work together.

The first method is a stored virus method. The Comm Officer equips themselves with software tools that only work on a specific system. For example, a Rall 4 and Hunter E-suits would be good bets. I could even justify the fact that the character has the viruses with the idea that they’re part of their standard kit, supplied by the military. The question is, if the characters have this kind of software, why not just infect all the vehicles they run into? It would come down to the ability to deliver the virus.

In that situation each virus has it’s own pre-defined target and action. Something like “Rall 4 target change” would work. It would require a lot of writing out what each virus does.

Another option is to allow the character to steal actions from a vehicle. It’s an interesting option but it doesn’t say how the character is performing the hack. I’m sure that a lot of players wouldn’t really care how this happens but it’s something I want to know because it can change how the players use the ability.

Then there’s the idea of giving them an even more powerful tool than they currently have. The idea being the long range communicators have some kind of data teleporter in them. They would have an ability similar to the Chezbah Priest’s. Maybe there would be a kind of targeting skill check to start with to make things interesting.

It might be a good approach to switch from a denial of access model to simply gaining access. I mention this in the Comm Officer’s Guide but it hasn’t collected any attention. Moving it front and center might be the better model with denial of access being the coup de gras.

I would be okay with the Comm Officer being able to disrupt the function of one or two combat vehicles. What I don’t want is for all the vehicles to be disrupted because of a few good rolls.

It comes down to the idea that hacking has to happen in combat turns. I’m a little uncomfortable with that because it’s not usually how hacking really happens. Realism is not on the player’s minds though. They want to all jump into action and pull off a plan. Making hacking follow a longer time frame requires planning and forethought which most players aren’t super excited about.

We have been discussing moving 4e from a d100 scale to a d10 scale but it came up that a d20 would give all the benefits of a d10 and mitigate the problems with the lack of granularity. This fixes a large number of problems and would only slightly make math in the system harder. This math most frequently includes adding a skill value to an attribute value.

Only then it became apparent that even that math could be eliminated if skills became an Advantage roll. Currently in 3e an advantage is a percentile value. You roll against your attribute and if you have an advantage, you roll to get under it’s percentage. If you make it, you get an extra success.

Skills have always had the problem that they don’t really integrate well with the success columns. Making them an advantage roll means they’d dovetail in nicely.

But isn’t that too many rolls? (It’s not like there are any shortage of rolls here) Yes, that’s going to slow things down too much. Unless…

Rolling looks like it’s going to change a lot here. This is where I think it’s going to be. We already talked about rolling a d20 for your attribute. You’d then collect anything that gives you an Advantage while your opposition collects anything that would give you an Impairment. For each Advantage you pick up a d10. For each Impairment your opposition picks up a d10. All the dice are then thrown.

Here’s were it gets a little weird, but a good weird. You know what Advantages you’re using. They’re simply values of 1-10. For example, a TF E-Suit pilot scanning with their sensors, they’d have one Advantage at 2 for their skill (1d10) one for the TF’s sensor array 4 (2d10). The player rolls a d20 and 2d10. On the d20 they get a 19 and fail that roll. On the 2d10 they get a 7 and a 3. The seven doesn’t do them any good, but they assign the 3 to their sensor advantage of 4 and get one success!

At the same time the opposition (The GM or maybe another player) rolls for any Impairments and gets to assign the dice values just like the player got to assign the Advantage rolls.

I like how that looks at the table. The difference in dice sizes indicates which die goes to the attribute roll and stacking a bunch of Advantages just makes them more and more valuable. In one toss, the values are compared and the task is resolved.

Then there’s the talk about guaranteeing an Advantage by spending an action. I was debating if you could do that with the main attribute check but with skills being an Advantage, an action can guarantee that as a success. It’s elegant and fits.

The other thing I’m working on is possibly making stunts and consequences universal across different situations (personal combat, vehicle combat, social interaction, tech challenges, hacking etc). It would reduce the need to memorize different lists but it would generalize a lot of the descriptive and prescriptive value of the stunts though. Right now, harmonizing personal and vehicle combat is something I definitely want, the others may have to remain separate but I think they can follow along similar lines of each other. I don’t know if that makes things any easier though.

In all Stunts will require some look up (which would be on the back of the character sheet) or memorization but they’re intended to remove the need to roll on charts or tables while in play.

I have the feeling that I want to move hacking to something more immediate and have it follow something like the social interaction conditions that I’ve talked about before. I haven’t done any real work on that yet though. It just seems promising.

Something I haven’t figured out yet for weapons is the effect that firing a lot of shots ought to increase your chances of hitting a target. I tried to figure this out in previous editions but never found an effect that I thought was proper.

The things you can buy with a successful roll, I’m starting to call stunts. I may change that up later but at the moment we’ve been debating the half damage stunt and it’s effect. I’ve been going back and fourth on if it applies to burst firing weapons. If it does, can you use it to count a target hit? I’m starting to think it should after all even with a beam weapon, it should mean that it’s at least possible to use a reduced dwell time to find the target. Why would that not be the case with a burst weapon?

So I’m thinking I need to re-write the stunt again to add this as a possibility.

A little bit ago I wrote about spending an action to get a success. The biggest problem I have with that is it circumvents the stress system for getting successes. In theory that’s could be ok but design wise, having multiple paths to get the same effect causes confusion.

I still think we should play test that but I have an alternative that might be ideologically more pure. It wouldn’t interfere with anything to say that spending an action could ensure a success from an Advantage. In theory an opponent could spend an action to remove a success if you have an Impairment. That second one might be a more rare circumstance but it’s still interesting.

I’m getting ready to run our first game with all these tweaks. This will be interesting!

Hacking in the current edition has a problem. Although it works, not many players use it. In short, it requires patience. The time scale for hacking is much longer than combat and that means it’s ineffective in a crisis. Because of that, it’s not a skill players fall back on.

I don’t have a good idea of what I want to do yet. I have the intuition that I want to do something like where I’m going with social conflict where the hacker picks conditions to put on the hacked system. Instead of trying to take control of the system, the player uses their skill to either gain from the system or limit it’s use.

I don’t have a full idea of what that’s going to look like yet but I have some ideas. The two conditions I’m thinking of are as follows.

Information – The hacker can get information on what is happening on the system or what happened in the past. I’m almost thinking that I’d like two separate conditions, one for current monitoring and another for reading what happened in the past just to make them distinct but that may not be needed.

Complication – This takes a lot of forms but the thought is that the hacker does something to make the system harder to use. This could include making it harder to use sensors or aim weapons. The hacker would put an impairment on using a skill that would be used on that system. Again, I’m trying to figure out if this should be multiple different conditions or just one.

I would like to have more so I’ll keep working on this and try to expand it. There’s still the problem of time scales. I might have to relent on that, maybe changing the framework of hacking. I’m not sure about that. Playtesting might illuminate that.

Interestingly, the consequences in the equipment building section of the 3.1 Player’s Handbook worked out better than I thought. I did intensify one (the time consequence) which was a surprise to me. It was always the option chosen which means it’s too weak. I’m also looking at weakening the energy consequence because it’s always avoided, meaning it’s too strong. I’m not sure how to state the consequence eloquently yet though, I’m working on it.

The other change is that builds are starting out with a number of Challenge Points (CP). In playing with the rules, very small builds came out too small. I needed to introduce a curve to the mass and energy use in very small builds and giving a base CP does that nicely.

I’ll re-release the 3.11 ashcan when I figure out what I want to do with the Energy consequence.