Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Yoink]

Roll to Yoga
This is, like, a game about yoga practitioners going on an epic quest through space and time, and it gets updated quite regularly.

It all sounded quite doable and exciting 'til the last part, then I realised it couldn't possibly be a serious idea.
You got my hopes up La. Man I still need to get on the waitlist for that, don't I. So good.

[IronyOwl]

Roll to Cop
The players are, like, cops.

I don't think it'd translate well to a forum game, but I was recently amused by the idea of a "supernatural police" type setup where the cops are of the bumbling small town variety, and thus fairly out of their depth for petty theft let alone murderous werewolf cults.

Alternatively, where the cops are similarly inept but not actually expected to do anything, so they have to investigate noise complaints that are hopefully not the screaming of the damned while assorted vampire hunters and supernatural investigators pass through doing their considerably more hardcore thing. At that point it'd probably be more fun to play as the actual guys, though.

Roll to First Aid
The players are first aiders in a busy office, and have to respond to first aid requests – paper cuts, falls, heart attacks, that kind of thing. It’s also PVP competitive play, as whoever successfully treats an incident gets a pay rise and a level up.

So Surgeon Simulator: The Forum Game?

"I bash open his sternum with a hammer, cut out the heart, put the new heart in, and, uh, glue the ribcage back together?"
"You bash open his sternum with a hammer, cut out his stomach, fumble the heart into a nearby trash can, and accidentally glue the utensil tray into his ribcage. He is now armored, gutless, and still has a bad heart."

Roll to Yoga
This is, like, a game about yoga practitioners going on an epic quest through space and time, and it gets updated quite regularly.

Well that just doesn't sound feasible.

[Egan_BW]

At that point it'd probably be more fun to play as the actual guys, though.

Yeah, but that's the central joke, see.

[lawastooshort]

That reminds me, IO, of this famous surgeon pioneer back in the good old days when surgery was done in public for people to observe. He was renowned for his speed in amputating legs, and in one demonstration he achieved a 300% mortality rate. He accidentally sliced off his patient's testicles, and with a backswing of his knife stabbed his assistant - he later died of the infected wound - and an observing woman was so horrified by the dying amputee's suffering she fainted to death.

[AoshimaMichio]

That reminds me, IO, of this famous surgeon pioneer back in the good old days when surgery was done in public for people to observe. He was renowned for his speed in amputating legs, and in one demonstration he achieved a 300% mortality rate. He accidentally sliced off his patient's testicles, and with a backswing of his knife stabbed his assistant - he later died of the infected wound - and an observing woman was so horrified by the dying amputee's suffering she fainted to death.

Robert Liston.

Amputated the leg in under 2 ½ minutes (the patient died afterwards in the ward from hospital gangrene; they usually did in those pre-Listerian days). He amputated in addition the fingers of his young assistant (who died afterwards in the ward from hospital gangrene). He also slashed through the coat tails of a distinguished surgical spectator, who was so terrified that the knife had pierced his vitals he dropped dead from fright.

That was the only operation in history with a 300 percent mortality.

[piecewise]

So I've been thinking of doing a homebrew for a while and I've got enough of an idea for how it would function to ask for some opinions before I start doing the more in depth stuff. Keep in mind that I've got nothing in terms of actual numbers for any systems or anything, I just have the idea of how they'll work.

The idea is a pacific rim style mech vs giant monster game. I know some of these exist already but none of them quite do what I want them to. The basic mechanics here are pretty simple, sort of an Xcom deal where the players start with a small base, low level tech and primitive mechs, and then via winning fights against stronger and stronger monsters, they level that base up, develop new tech and get better machines.

The Mechs themselves are based around a "Frame" a sort of base skeleton that is then customized. I've played with several ideas of how to make these things, from whole body frames to individual part frames (Ie you can switch off the leg or arm part of a frame and keep the torso, or something similar), but regardless of that decision, the frames determine the base stats of the mech, as well as things like available load and number of part slots.

From there players "slot in" the parts they want on the frame. So a basic frame might have 3 chest slots, 3 arm slots per arm, 2 leg slots per leg and 1 head slot, all of which act as places to put parts. Some parts, like the reactor and the cockpit are critical and have to be there, and generally in certain places, while others are completely optional. A cockpit has to be in the head or chest slots, a reactor has to be in the chest, but a flamethrower could go just about anywhere. The frame and the part both have HP which is added together to create the HP of that section of the mech. Armor can then be added on top of this, which effectively adds more HP and protects the function of parts from damage, so that sections can be damaged without losing functionality.

Once functional parts start taking damage, they have a chance to malfunction or fail when you try to use them. For instance, if I have the previously mentioned flamethrower embedded in an arm slot and it's been badly damaged, I'll roll each time the player uses it. If the roll comes up bad I'll roll again on a malfunction chart and see what happens. These effects could be many things, from a simple jam to a catastrophic and explosive failure. It should be noted that these "Malfunction rolls" apply not only to use of the functional part but also to the part of the machine its in. So if that part was in the left arm, any use of the left arm would have a chance of malfunction, albeit with a different chart of failures. For instance, it could have a power connection failure and the arm could go dead because the power was severed. These failures can sometimes be fixed "On the fly" if the players have the right cockpit parts installed. Like frames, cockpits have slots that can be filled with optional addons. For instance, a power control panel would allow them to take a turn to try and reroute power around the failure and fix the arm. Where as a Blast Bolt panel would allow them to sever the dead arm and gain enhanced movement because of the lighter weight.

Weight and power work much the same, though inverted. For power, you have your reactor outputting a specific amount of power while each part has a Min, Optimal and Max power it needs. For instance, I might have a laser rifle that requires 5 power at optimal, 3 min and 8 max. Below 3 it won't function, and at 3 it will have a -2 penalty to damage. At 5 it will do normal damage while at 8 it will do +3 damage over normal. If they have the right parts they can overload it, putting more than 8 in and getting higher bonuses at the cost of damaging the laser. For weight it works the same, but opposite; Frames have a optimal and max weight, with higher weights slowing them and lower weights making them faster.

Part of piloting the mech is controlling where the power is currently routed to, sort of like FTL. So you can shift power around to increase damage or speed or just get it away from parts you're not using. There's also the option to shift it to sections in order to increase specific stats, such as to the arms to increase strength and to the legs to increase speed.

The giant monsters will be handled in much the same way; with a "Skeleton" base and then organic addons such as horns, fire breath and the like, with different skeletons and parts locked off in "Tiers". I intend to also make a random generation system for the monsters that can be used to generate random monsters to fight rather than having to custom build every one of them.

Combat will be grid based and fairly standard in terms of the basic mechanics of how to hit and dodge and such. Simple opposed rolls with the difference between rolls acting as a bonus to set weapon damage. The more tactical aspect of the combat comes from targeting parts and limbs in order to destroy or incapacitate them. Each slot as a location on the frame (see shitty paint image), so destroying the shoulder slot of a mech will sever the whole arm, and likewise with a creature. Mechs have the benefit that they can only truly be stopped by destroying the cockpit or reactor while creatures can bleed out and die from limb loss and the like.

[IronyOwl]

So I've been thinking of doing a homebrew for a while and I've got enough of an idea for how it would function to ask for some opinions before I start doing the more in depth stuff. Keep in mind that I've got nothing in terms of actual numbers for any systems or anything, I just have the idea of how they'll work.

The idea is a pacific rim style mech vs giant monster game. I know some of these exist already but none of them quite do what I want them to. The basic mechanics here are pretty simple, sort of an Xcom deal where the players start with a small base, low level tech and primitive mechs, and then via winning fights against stronger and stronger monsters, they level that base up, develop new tech and get better machines.

The Mechs themselves are based around a "Frame" a sort of base skeleton that is then customized. I've played with several ideas of how to make these things, from whole body frames to individual part frames (Ie you can switch off the leg or arm part of a frame and keep the torso, or something similar), but regardless of that decision, the frames determine the base stats of the mech, as well as things like available load and number of part slots.

All of my yes.

From there players "slot in" the parts they want on the frame. So a basic frame might have 3 chest slots, 3 arm slots per arm, 2 leg slots per leg and 1 head slot, all of which act as places to put parts. Some parts, like the reactor and the cockpit are critical and have to be there, and generally in certain places, while others are completely optional. A cockpit has to be in the head or chest slots, a reactor has to be in the chest, but a flamethrower could go just about anywhere. The frame and the part both have HP which is added together to create the HP of that section of the mech. Armor can then be added on top of this, which effectively adds more HP and protects the function of parts from damage, so that sections can be damaged without losing functionality.

What's the point of restricting certain things to certain slots? If I want my cockpit located in my robot's dick and its head to be nothing but an electrified grappling hook launcher, is there a reason not to allow that?

For that matter, have you considered generalizing parts more? Instead of having humanoid and arachnoid frame types, for example, you could just take a torso/large frame with an appropriate number of connection slots- or connection slots could be a regular slot you're using to bolt a new limb into rather than a component- and then start attaching limb frames topped with walker pads or hands or gatling guns or whatever you're after. Presumably weight and power requirements act as the primary balancing mechanism here, so a centaur with four arms ends up being slower and devoting more internal space to reactors than a similarly proportioned humanoid. But on the other hand, it's got four legs, which should be boosting its speed or stability or just letting each leg frame be cheaper than the humanoid's have to be, and four arms which should similarly be giving it arm-appropriate benefits, and if its lower body frame is larger that gives it more space for those reactors.

It'd be a lot more work, but you love complex do-it-yourself bullshit. Plus everyone would immediately make some kind of tauric crab-millipede abomination, which gives you more opportunities to blow their many, many limbs off. It also means the enemies don't have to be stuck as upright lizards either.

Once functional parts start taking damage, they have a chance to malfunction or fail when you try to use them. For instance, if I have the previously mentioned flamethrower embedded in an arm slot and it's been badly damaged, I'll roll each time the player uses it. If the roll comes up bad I'll roll again on a malfunction chart and see what happens. These effects could be many things, from a simple jam to a catastrophic and explosive failure. It should be noted that these "Malfunction rolls" apply not only to use of the functional part but also to the part of the machine its in. So if that part was in the left arm, any use of the left arm would have a chance of malfunction, albeit with a different chart of failures. For instance, it could have a power connection failure and the arm could go dead because the power was severed. These failures can sometimes be fixed "On the fly" if the players have the right cockpit parts installed. Like frames, cockpits have slots that can be filled with optional addons. For instance, a power control panel would allow them to take a turn to try and reroute power around the failure and fix the arm. Where as a Blast Bolt panel would allow them to sever the dead arm and gain enhanced movement because of the lighter weight.

If I might suggest, those actions might be better as general actions your specific rig could be more or less suited to, rather than either/or choices made in the hangar. Having your arm damaged and not being able to (try to) reroute power or sever it or overload the weapon in it or something sounds boring and uncinematic.

It would also, if you were so inclined, give you another few stat axes to screw around with.

Weight and power work much the same, though inverted. For power, you have your reactor outputting a specific amount of power while each part has a Min, Optimal and Max power it needs. For instance, I might have a laser rifle that requires 5 power at optimal, 3 min and 8 max. Below 3 it won't function, and at 3 it will have a -2 penalty to damage. At 5 it will do normal damage while at 8 it will do +3 damage over normal. If they have the right parts they can overload it, putting more than 8 in and getting higher bonuses at the cost of damaging the laser. For weight it works the same, but opposite; Frames have a optimal and max weight, with higher weights slowing them and lower weights making them faster.

Part of piloting the mech is controlling where the power is currently routed to, sort of like FTL. So you can shift power around to increase damage or speed or just get it away from parts you're not using. There's also the option to shift it to sections in order to increase specific stats, such as to the arms to increase strength and to the legs to increase speed.

The giant monsters will be handled in much the same way; with a "Skeleton" base and then organic addons such as horns, fire breath and the like, with different skeletons and parts locked off in "Tiers". I intend to also make a random generation system for the monsters that can be used to generate random monsters to fight rather than having to custom build every one of them.

Combat will be grid based and fairly standard in terms of the basic mechanics of how to hit and dodge and such. Simple opposed rolls with the difference between rolls acting as a bonus to set weapon damage. The more tactical aspect of the combat comes from targeting parts and limbs in order to destroy or incapacitate them. Each slot as a location on the frame (see shitty paint image), so destroying the shoulder slot of a mech will sever the whole arm, and likewise with a creature. Mechs have the benefit that they can only truly be stopped by destroying the cockpit or reactor while creatures can bleed out and die from limb loss and the like.

This looks good, but what would the decisionmaking process be for targeting various parts? You probably don't want "stab it in the face" to be the answer every time, but it's hard to make dynamic decisions unless they're based on changing conditions.

[Egan_BW]

Please let me put my robot's cockpit in its crotch.

[Draignean]

My Programming fancy has been tickled. I have spare time for the first time in a long time, so I might have some fun with this...

Well, nearly no one reads edits, but if you do, here's the frame of what I'm doing...

Each robot/kaiju is composed of a series of sections. Each section has a frame/skeleton attribute. Each frame/skeleton then also has at least one module slot (exactly 1, for current testing)

In order to make this somewhat simple, I've made a relatively easy set of commands to string these things together.

Code: (testArm) [Select]

new frame base arm1
new frame base arm2
new frame base arm3

load module baseRocket arm1
load module basePlating arm2
load module baseHand arm3

con arm1 arm2
con arm2 arm3

EOF
So, block by block. First this little snippet constructs three sections.
Second, it loads a rocket module into the first section, heavy plating into the second section, and a hand into the third section.
Third, it connects the three sections together into one long strand.

So, in essence, it build one arm. That's nice, but it's going to get messy and really, really repetitive for long structures Making a spider monster with six legs or a mech with four 'wings' that are all the same would be tedious and unnecessarily error prone. That in mind, we give you the make functionality. Take a look at this,

Code: ( testBody) [Select]

new frame base head
new frame base lChest
new frame base core
new frame base rChest
new frame base lhip
new frame base rhip

load module baseCockpit head
load module basePlating lChest
load module basePlating rChest
load module baseReactor core
load module baseLaser lhip
load module baseLaser rhip

make larm testArm
make rarm testArm
make lleg testLeg
make rleg testLeg

con head core
con core lChest
con core rChest
con lchest lhip
con rchest rhip

con lchest larm
con rchest rarm
con lhip lleg
con rhip rleg

EOF
What this does is it builds the torso of the mech Piecewise sketched out. All the commands are familiar up until you get to the 'make' function. Think of this sort of like #include, with a bit of a twist. It copies the contents of the file defined as the second argument, where every section name is given the first argument as a tag- with the very important exception of the first section of the new file.

The first section of the new file is forcibly renamed to the first argument, which enables it to be linked in the base file without knowing what it was called in the called file.

So, basically, what this version does is it sets up the entirety of the body, builds two arms (in such a way that each section is still uniquely identified, which will be crucial later), and then builds two legs. That done, it connects the chest together, then binds the known first element of the arms to the sides of the chest and bind the first element of the legs to their respective hips.

The parsed version then looks like this,
 

Code: [Select]

new frame base head
new frame base lChest
new frame base core
new frame base rChest
new frame base lhip
new frame base rhip

load module baseCockpit head
load module basePlating lChest
load module basePlating rChest
load module baseReactor core
load module baseLaser lhip
load module baseLaser rhip

new frame base larm
new frame base larm_arm2
new frame base larm_arm3

load module baseRocket arm1
load module basePlating larm_arm2
load module baseHand larm_arm3

con arm1 larm_arm2
con larm_arm2 larm_arm3

new frame base rarm
new frame base rarm_arm2
new frame base rarm_arm3

load module baseRocket arm1
load module basePlating rarm_arm2
load module baseHand rarm_arm3

con arm1 rarm_arm2
con rarm_arm2 rarm_arm3

new frame base lleg
new frame base lleg_leg2
new frame base lleg_leg3

load module baseBooster leg1
load module basePlating lleg_leg2
load module baseFoot lleg_leg3

con leg1 lleg_leg2
con lleg_leg3 leg4

new frame base rleg
new frame base rleg_leg2
new frame base rleg_leg3

load module baseBooster leg1
load module basePlating rleg_leg2
load module baseFoot rleg_leg3

con leg1 rleg_leg2
con rleg_leg3 leg4


con head core
con core lChest
con core rChest
con lchest lhip
con rchest rhip

con lchest larm
con rchest rarm
con lhip lleg
con rhip rleg

EDIT 2: Base commands are now surrounded by brackets in order to minimize naming issues.

EDIT 3: Ugh. Design decisions. Everything was going so smoothly up until the module level.

[Draignean]

*Several hundred lines later.*

Okay, so the frame assembler works. The module loader works for weapon, armor, and utility type modules, but still needs to have power, feet, and cockpit type modules added.

After that loading is tested, then we can start adding on the diagnostic panels, getting the logic for activating a module of arbitrary type operational, then we can work out power flow and module damage.

Once we have that done we can work on pilot input strings, and proceed from there into testing.

Because of how its shaping up, it seems rather likely that a portion of the players will be staying behind, acting as engineers trying to design viable mecha and mecha modules, while the active duty players used the fruit of the engineer's labors to do battle. Waiting list people would likely love that idea.

 While no one step is terrible complex, it can add up quickly. The syntax for assembling a mecha, as shown above, is really quite simplistic when properly partitioned into various units and assembled using the make command.  Modules, are, unfortunately, a bit more complicated. This is an example of the Basic Booster. No numbers are thought out, it's just there to make sure things load when they're asked to load.

Code: [Select]

utility
[name] Basic Booster
[module_hp] 10
[module_ap] 10
[module_wt] 5
[module_pw] 5
[max_malfunction] 0.5
[malfunction_threshhold] 0.7
[power_drain] 3
[malfunction_damage] 5
[bleed_rate] 2
[bleed_chance] 1
[glitch_chance] 2
[explode_chance] 1
[skip_chance] 3
[disable_chance] 2
Utility Specific
[optimal_power] 7
[power_modifier] 0.4
[redline] 10
[redline_malfunction] 0.35
[global_shield] 0
[boost_damage] 0
[boost_accuracy] 0
[boost_evasion] 0.5
[capacity] 3
[current_charges] 3
[spool_cost] 10
[spool_unit] 1
EOF
It'll naturally need some comments before I send the mecha engineers to wreak havoc trying to design new things, but it has the ability handle pretty much anything that it needs.

Weapons are similarly large (see below), but armor is nice and concise.

Code: [Select]

weapon
Basic Laser
[name] Basic Laser
[module_hp] 10
[module_ap] 10
[module_wt] 5
[module_pw] 3
[max_malfunction] 0.3
[malfunction_threshhold] 0.5
[power_drain] 5
[malfunction_damage] 3
[bleed_rate] 1
[bleed_chance] 1
[glitch_chance] 3
[explode_chance] 1
[skip_chance] 3
[disable_chance] 2
Weapon Specific
[max_damage] 5
[min_damage] 3
[armor_pierce] 1
[accuracy_mod] 1
[optimal_power] 5
[power_modifier] 0.3
[redline] 8
[redline_Malfunction] 0.2
[capacity] -1
[current_ammo] 0
[spool_cost] 0
[spool_unit] 0
EOF
Because a mecha is liable to have at least 6 modules that aren't armor, the amount of work it takes to construct a mecha with a large number of unique or custom made parts increases dramatically.

Still, be fun to be an engineer and see the fruit of your labors blast apart Kaiju.

I'm going to close my eyes for a little while, but this is an interesting problem.

[TheBiggerFish]

*lightning crackles*
*there is a sound as of a keyboard being furiously typed upon*
IT'S HAPPENING

Also, Draignean and piecewise, in the same game?  How are you going to keep literally everybody from trying to join?

What language are you coding in?

[Draignean]

*lightning crackles*
*there is a sound as of a keyboard being furiously typed upon*
IT'S HAPPENING

Also, Draignean and piecewise, in the same game?  How are you going to keep literally everybody from trying to join?

What language are you coding in?

What? No, I'm just playing with the system. He's welcome to use what I come up with (you know, it being his idea that I'm riffing on), but we haven't talked about running a game together.

I'm just using plain old java. It's easy to set people up with a jar and an archive so they can do their own module prototyping and play with stuff that way.

[Tiruin]

I've been a fish these past months x_x
Good news is planning to revamp my RtD and run another one before the end of this year. Hopefully
And send NAV the RtD Formatting guide and stuff. Because I'm finally free from academics other than OJT next year \o/

Do we still have a mechanics testing thread? I'm trying to find out if HP based games run better with armor being an additional to HP or if it's better to remove damage from rolls. The former seems better since it covers the general idea of being armored while the latter seems better for more lighthearted games that aren't that mechanics heavy.

...And I haven't been that exact with how heavy I'm even planning >__> I'd love tips though.

[Harry Baldman]

Do we still have a mechanics testing thread? I'm trying to find out if HP based games run better with armor being an additional to HP or if it's better to remove damage from rolls. The former seems better since it covers the general idea of being armored while the latter seems better for more lighthearted games that aren't that mechanics heavy.

You could take a page out of Numenera's playbook and make damage fixed, with rolls required to dodge the entirety of the damage (which is a property of each weapon/enemy), and armor subtracting from the fixed damage.

...And I haven't been that exact with how heavy I'm even planning >__> I'd love tips though.

Don't write any lore. Just make up the starting scenario, and riff on the premise from there.

Also do let me know if you manage to get a game together, I'd like to give making a sheet a shot.

[GiglameshDespair]

Do we still have a mechanics testing thread? I'm trying to find out if HP based games run better with armor being an additional to HP or if it's better to remove damage from rolls. The former seems better since it covers the general idea of being armored while the latter seems better for more lighthearted games that aren't that mechanics heavy.

...And I haven't been that exact with how heavy I'm even planning >__> I'd love tips though.

Well, armour as damage resistance wirks easily with other mechanics like armour penetration, abilities that decrease or increase armour, etc.
I guess it depends how light you want your system to be, but I'd say it's better than straight armour as hp.