Discussion: Game Mechanics

buzzz. next turn. it should be obvious, but there is another vowel in there.

no "C, O, T"

Turn 13 (started at 10)
S _ _ _ _ I _

 

V

 

buzzz. next turn.

no "C, O, T, V"

Turn 14 (started at 10)
S _ _ _ _ I _

 

Is that such a bad thing? Otherwise you would have to spend XP on a skill you only use during certain missions. We've ran into that problem before in the past. I find this to be a simpler solution.

Skwi guessed "A". correct! you have another guess.

no "C, O, T, V"

Turn 14 (started at 10)
S A _ A _ I _

 

N is correct. Should be easy now.

no "C, O, T, V"

Turn 14 (started at 10)
S A _ A _ I N

 

"Bingo bango. You got. Jimmy, tell him what he's won!"

In-game, that took 5 turns to solve (or 50 secs). I think that's pretty reasonable. If I keep the words short, I don't think it is a herculean task. And for those who have trouble, you can always do a google search for "hangman solver". It is the easiest to implement system I have come up with that still rewards player "skill".

 

I understand. As a GM, though, my reasons for this have nothing to do with personal preference and everything to do with practicality. This is by far the simplest solution I've come up with. Like you said, if hacking was an actual skill, it means some players could be excluded from contracts that required hacking... which means i would need to make more non-hacking contracts... nevermind the work needed to track said skills... etc. etc. etc. I have lots of reasons for doing it this way. Everything here is very mindful of the fact that I'm starting nursing school in the fall; less work for me is better for everyone. Trust me.

Also to be clear, your character is not hacking anymore than it could be considered hacking to rip off an access panel and plug in a wifi-equipped zip drive. Your job is just to give the real hacker access to do his job. If someone needs RP reasons, consider the players to be the "hacker team"; the character pilots are just there to get the uplink established and keep it open.

 

Next Topic: Surveying

Whereas Hacking will be a key feature for Raids and (some) Sieges, Surveying will serve a similar function for Recons and (some) Patrols. However, unlike hacking which will usually target a specific point, Surveying will emphasize speed as you move to various point on the battlefield collecting recon data. Simply put, it will function similarly to point capture.

In the case of a Recon mission, there will be FOUR survey (capture) points. The defender begins the mission owning all four. The attacker must succeed in deploying sensor beacons at 3 /4 of the points. Most likely, there will be one point positioned near each corner of the map. This will achieve triangulation of the area.

Placing the beacon will involve a minigame of sorts similar, but also different to Hacking. Admin will roll 1d6 each time a surveying attempt is made. A team will have one guess to guess the right number (1-6). If they get it wrong, the admin will tell them "higher" or "lower". This is meant to simulate "calibrating" the sensor. If all goes well, each sensor should only take 2-3 turns to deploy (I recommend making your first guess 3 or 4). Like Hacking, players must sacrifice their movement for each turn they are attempting to deploy a beacon. However, just like Hacking, they can still fire as normal.

Victory is determined if the attacker succeeds in surveying 3 points or not. If the attacker succeeds in destroying/routing all defenders, but is disabled in the process, the mission is considered a draw. If the attacker succeeds in surveying all points, but fails to exit the map, it is also considered a draw. If the attacker has only drones (all bots) and an admin cannot stand in to capture points, the mission changes to that of a simple Patrol (destroy targets of opportunity). It is assumed that in this case, the drones' AI have prioritized destroying nearby hostiles before continuing with their previous objectives.

Recons (especially for the attacker) will cater to pilots with fast mechs... as it should.

 

Next Topic: Secondary Skills

Secondary Skills in the Skjaldborg campaign have evolved overtime and are generally much more balanced than when we first started this. However, I'm still not completely satisfied with them for the purposes of the Prometheus campaign. The biggest limitation currently is that important secondary skills are spread out between each member of a lance. This works fine in theory as long as all members remain active. However, take even one member out, and the lance drops significantly in effectiveness. This can be mitigated by players doubling up on required skills, but there is still a very large selection of secondary skills that are needed and no single person can reasonably be good at them all. Again, for the Skjaldborg campaign where players are intended to work in groups, that's fine. But for the Prometheus campaign, where players are just as likely to operate alone as with teams, it is not.

Therefore, I am experimenting with a new setup for skills. In the 34th century, Lancers are indeed the elite soldiers of known space; single man armies if you will. However, even they can't work entirely alone. Just as a pit crew supports their driver, a logistics crew must also support each Lancer. Here's the basics on what you need to know:

• Each player will control a "Lancer" (as expected) - this PC will predominantly be used for all combat missions and will use skills related to that role
• Each player will also control a "Handler" - effectively a PC Tech (with crew) that uses support skills to aid their Lancer in all non-combat jobs (and occasionally in combat roles).
• In MekHQ, Handlers will be viewable as a single "PC", but will represent roughly 6-12 support staff; this also includes crew members for a Lancer's dropship.
• Both the Lancer and Handler will have a separate set of skills
• Both Lancer and Handler will have separate XP pools and earn XP independently.
• Your Lancer may "gift" XP to your Handler at any time (with GM approval).
• Handler crews will not only repair but also maintain all owned units.
• If your Lancer dies in combat or retires, your Handler may remain active and a new Lancer will be assigned to it.
• Handler crews do not suffer from "permadeath".
• Handlers may be traded or bought. Some contracts may even award new Handlers.
• New Handlers ALWAYS replace old ones (ie. you can only own one at a time).

A breakdown of skills for Lancers:

...and Handlers:

NOTE: the general function of each skill has not changed; only who uses said skills

 

Here is the most current build I have for our Skill Events table:
https://docs.google.com/forms/d/1xikpCi_cJ18Fh-ZZdqgZiwhgdwFhPOpdMoQBizxei-8/viewform

The idea is that if two players face off in combat, their skill rolls would be against each other.

For example:

However, I am loathe to keep the event bonuses as they are because I'm concerned that some give too great of an advantage to a player who rolls very high (such as bonus BV for deployment). Also, what happens if there are more than 2 players? What happens if there are 3 players on the attacker side, but 1 player on the defender side? (the BV would remain the same)

In regards to the latter, I think the best decision would be to allow each side to make only one roll for each skill. Obviously, it would be up to each side to choose who should make the roll. This would reduce the advantage of forming player "gangs".

I am open to suggestion on how teh Secondary Skills should be changed to address PvP.