A story game and a tactical game in one

[Onix]

I'm hitting a new stage in development for The Artifact. We've just ran though two games that use a that i've been futzing with and I'm starting to really like the results. The thing is it does something meta and weird to the game. It creates one class of characters that play in a very story driven way and another that plays tactically. Not that any individual couldn't cross over that divide but they'd at least start off very differently.

Techy characters start to become more story oriented, which makes sense. The fighters stay very tactically driven. So far my players haven't noticed that, but they're not used to thinking in design terms so they just accept it. The story aspect isn't quite free form, and actually it could be played wrong by the GM and made into a dice game (I'll work on some structure to attempt to prevent that).

The question is, would you see anything wrong with that? Are there any tripping hazards to avoid that occur to you?

[Rubbermancer]

Ah, I remember reading about this juicy monster a while ago. I'd say the biggest pitfall would be Linear Fighter, Quadratic Wizard. The old D&D problem, superimposed. What are the limits with "Story Points" or Narrative power, when compared with hard, tactical limits? How do the two progress and evolve over time, and what sort of veto does the GM have on that?

[Onix]

That's an interesting comparison. I think the difference is at the moment the linear fighter handles one type of challenge while the quadratic techy faces something entirely different. To keep with the inspiration for this system, it would be Mr. Scott trying to fix the warp drive while Kirk dukes it out with the Klingons. However the lines may blur here and I'll talk about that in a minute.

In the most recent game, the players made two engineers. There was no fighter player so it was all tech challenge. They had a early warning system being constructed for a base camp when they started getting anomalous readings. They had to use a half built system to discover the true nature of the readings.

The narrative power is the players when they're planning what skill to probe the problem with. If they are able to explain, even generally how the skill would apply, they get a bonus to the skill actually being able to address the problem. Then once they roll to reduce the Story Points (SP) of the problem the narrative is guided by the transform. At the moment I've been interpreting the transform and it's effects. That's mainly because I'm not sure my players would know how to narrate that but also because I'm still refining the transforms so that they're easier to apply.

How certain skills apply can also get really hard to interpret. A player can just throw a skill at the problem even if they don't know how it would work. It makes their plan less likely to work but if the dice are kind, weird things can happen. I give the GM veto power to say "No First Aid cannot be used to hack this computer." but encourage them to at least make an effort to imagine how the skill might apply.

Now back to Mr. Scott finding a phase inversion that would bypass the Klingon's shields so Kirk can blast them. There are some skills that when fully implemented would make the techy characters rather powerful. However I'm working to make these skills slow acting. That is, if the characters have an abundance of time, the techies can pull some powerful tricks with them. But on the scale of a combat turn, those kinds of tricks just can't be done. Hacking an enemy E-Suit (mecha) or building a pit trap would be these kinds of slow skills.

To be completely honest, time is something I'm trying to nail down with these. So far, I just narrate the time away. If the player says "I'm going to use my Electronics Engineering to design a new circuit board and etch it." Well, that would take hours to days dependent on what they're trying to do. If they say "I'm going to use my Electronics Engineering to better tune this input." then that might take a minute to ten minutes.

So in the end, the narrative power is not unlimited. There is a bit of squish factor but it's handled in a regimented fashion.

[Rob Lang]

[Onix]

Those are good considerations. I could see me mismanaging the group so that half are twiddling while others are busy but that would be a GM management problem more than a system problem. Hmmm. I'll think if there's anything I can do mechanically to encourage the GM to manage integrating the two challenges simultaneously. I think the time management would be critical to that.

I'm also thinking that there needs to be a way for a character to declare that they're taking up a tech challenge. Like if a Comm Officer declares he's going to try hacking a computer or an Engineer deciding he's going to go and repair a downed vehicle in the middle of combat.

As for the hacking to support combat, I wish I recorded a game of Cyberpunk me and a friend sat in on at the local university. There were two netrunners and the way they drove the session was a thing of beauty. I should ask those guys how they got the game to that state, I'm not sure if they're computer science majors and things just came naturally to them. They were the eyes and ears of the group and were taking ICE from another hidden netrunner at the same time. It just ran amazingly smoothly. I re-wrote the Comm Officer's guide with that session in mind.

[Rob Lang]

[Onix]

You're right, they weren't using the system as written. It was more realistic and updated to account for things like WiFi etc. They used only portions of the system of it and just narrated what they wanted to accomplish, the GM would assign difficulty numbers and they'd roll.

The thing that made the group gel was that they were tied into the CCTV systems in the area and could freely talk to all the other characters, either by radio implants or cell phone. The hacking had a real world influence and mattered to the other players. While the Solos and Rouge were in combat they were concerned about strategy, trying to look up who these people were in databases and websites that were attacking them. They also were trying to identify more people in the area that were acting suspiciously. I'm kicking myself for not talking to the GM later and finding out what guided them in making the changes they did.

So no, they weren't doing anything mechanically that would tie the group together, they just knew how to work together and how to take dissimilar tasks and make them gel. I saw it as the fact that the techies had a real world influence instead of some esoteric net dive modeled on a dungeon crawl which is what Cyberpunk normally does. They also had a relatively free form system that allowed them to use their imagination and what I can only imagine is real world computer experience to model the hacks.

I guess that's vaguely what I'm trying to accomplish with a little more structure to help a player with less real world experience to be able to perform the same kind of action. I had one player that is not overly technical and one that's a cowboy diesel mechanic (in real life that is) play Engineers doing complex math and manipulating self aware AIs and making it sound like they knew what they were doing. Mind you the rules to do that kind of thing were always there before but it was too complicated for them. Saying "Tell me what skill you're going to use and how you think it would help." made a big difference. Now, the problem I have with that, is that too often the techy rolls once, succeeds, and then twiddles his thumbs. It seemed to really engage the players that the problem was reacting to their efforts even as they were making progress.

The key to integration with other fighters, I imagine, is making the physical and the tech challenges tied together where progress can be made on both at the same time. I was also lax on play order and turn timing during the playtest but there's really no reason I should have been.

[thedroid]

To get away from the "one roll success" part of it, maybe you could com up with a way to track progress on the techy problem, but no "one-hit kill." In movies it seems like they always put a time limit on tech problems to raise suspense. Scotty has to fix the warp drive before the Klingons attack. If there's no logical time factor, maybe you give the computer five tries before the system locks him out. within those five tries, he has to get at least three successes. The best he could do is get three in a row, which still keeps him occupied.

Another possibility is to play it like tennis where they need four successes, but they also have to win by two, so if they get four wins and three losses, it's not over. Like a tennis game, that could play out for a long time if the odds are about even.

Then there's what I think of as my "tug-of-war" or "car chase" system, which I'm using in that social game post: You set a number for success and a number for failure and start them somewhere in the middle. Every failure moves the player one point or several points toward the failure amount. Every success moves the player one point or several to the positive. It's a mechanic I originally devised for car chases: You set the distance they need to get ahead of pursuit to escape, and the distance the cars are apart at the beginning, then you start rolling and lengthen or shrink the distance with each roll until either the cars are right on top of each other and combat takes place or the lead one gets away. I could see it working for any task you don't want to resolve too quickly. If it becomes to protracted, you can increase the number of potential points a failure or success can move you or you can establish a "death spiral" where successes lead to a great chance of successes and failures lead to a great chance of failures.

[thedroid]

I'm obviously assuming here that you're not just writing a game for computer programmers. I know zip about.

It seems like most mechanical and electronic tasks are a matter of guesswork: is it this? No. Ok is it this?

With that in mind, how about this. You roll 4d6: the numbers that come up are the solution to the problem. The players have to guess the numbers, but not in order, and a correct guess reveals all the dice that have that number. So they are looking at a max of 6 guesses. Now, they could actually guess numbers, or they could propose a fix and you roll 1d6. If the result matches any of the dice, that much of the problem is fixed. Once a number is rolled it can't be rolled again. So the players never roll dice. They just narrate. You can set difficulty by changing the number of dice.

[Onix]

The system for tech challenges is in place and works so no worries there.

My old system for hacking was from the perspective of a IT guy. It was reasonably simplified but still too complex for non IT people. Now the system can be played by non IT people and it works fine or knowledgeable programmers and they can tell a complex story but the underlaying mechanics work the same. Rob could weave quite the tale about his intrusion methods.

I'm nailing down how much of my old system I'm chucking and how much will stay right now. There is some granularity that I'd like to keep but I don't know if I'm just fooling myself into thinking keeping the old is a good idea.

I'll probably be updating the file soon to a beta, I thought about sending you to the link to the draft but the system has changed enough for the rough draft that you'd probably be looking at the clunky parts I've already torn out and replaced and saying "hey this doesn't work". Which wouldn't get either of us anywhere.

The underlaying idea here is a system that allows the high tech characters to be played telling a story while the fighters follow a more tactical set of options while using the exact same dice mechanic. That part is already done. I was just asking if there was a more meta concern that could come up. I think Rob's answer that if mismanaged it could split the group and leave half of the players sitting around doing noting is probably the main concern.