Sounds like Warmachine, on it's smaller scales. If you're looking for urban combat specifcally you might run into the walking bricks problem. Maybe the inclusion of a commander/warcaster equivalent would be importnat?
Also the splitting of 'heavy' and 'light' warmachines has to be balanced, but significant. How do you want to diferentiate the two? Defense vs. Armor, speed, power, to hit, stuff like that. In urban combat or close quaters it would be easy for big thing to squish small thing unless it had something over on the big machines.

I did the beginnings of a tank game customization system. Each tank had a grid, and the attack resolution method was to roll dX+dY (grid dimensions) and do damage in a pattern according to the weapon (1 square, 3x3 square, 3 high/wide cross, etc) to the spot. All components had to fit in the grid. Components that got wiped out battleship style stop working.

I mean, that was it, but feel free to steal that.

>>16762476
Sounds more like Infinity than Warmachines. Though Infinity uses their TAGS (mechs) like modern armor in that they require infantry support. Infantry from light to heavy augmented power armor users as well as advanced unmanned drones.

That's would be an interesting damage system, but the probelm I could see with that is confirming a hit then wiffing out by hitting already blacked out boxes.

>>16762571
Oh, I had a solution to that too. Hitting black boxes = HP damage. Attack the same spot enough times -->krbloo.

>>16762524
I've never played Warmachine. Tell me more about this "warcaster"?

The armor/speed/weapons loadout split is definitely going to be a thing. Thanks for pointing it out. Off the top of my head: Light, Medium, and Heavy classes of mechs (or small/med/big). Increasingly more points to split between these aspects, but also increasingly easy to hit and less able to take cover. Maybe I can even work it out so that's enough of a balancing factor that they can cost the same...

>>16762552
Maybe... It's a cool system, but I don't know if I'm feeling it for this project. Complexity v. awesomeness... Definitely considering it.

>>16762561
Infinity's fun, but building and customizing mechs is my main focus here and Infinity doesn't do that. I have no doubt that many mechanics will bleed over though.

Ah, in the Warcaster. In Warmachine the main units are steam/sorcery powered giant robots called Warjacks, 'jacks for short. Each 'jack has a central cortex that links the Warcasters mind to it, allowing him to control it. Kill the Warcaster and all of the 'jacks he was controlling go inert. So while you need the Warcaster close enough to control the 'jacks, and he is an offensive piece, he has to be protected or you lose.
I was thinking if you have lighter machines then they could play the moblie assassin role, or try and get around the big 'jacks to try and kill the commander. On the other hand big machines have big guns and armor.

If you're looking for a lot of custimization then a point based system that uses 'upgrades' might work. Basic model is 5pnts, adding a cannon is 2 more, extra armor is two points or one point and a loss of speed, better sensors is another.... Stuff like that.

>>16762690
That was my initial thought. If I go with >>16762552 's suggestion though...

I could give bigger mechs bigger grids, and skip the point system entirely. Bigger weapons simply take more slots. More advanced support systems maybe have weirder shapes to fuck up your tetris. Points can be taken out entirely...


>>16762661
That's a cool idea. I don't know how much I like the eggs-in-one-basket approach, but this is giving me ideas for electronic warfare and teamwork mechanics . Like a "spotting" bonus to accuracy the more mechs you have in LOS of your current target. Perhaps a chance to dodge if a mech on your team can see someone lining up that shot behind you. Also possibly drone controllers that DO work like that but don't necessarily collapse the whole army...

Well, thanks for the ideas. I'll try to have something more concrete next week. I'm keeping this thread open so I can at least read anything else you add before the thread 404's

One last giant robot bump before I go to bed.

>Like a "spotting" bonus to accuracy the more mechs you have in LOS of your current target. Perhaps a chance to dodge if a mech on your team can see someone lining up that shot behind you. Also possibly drone controllers that DO work like that but don't necessarily collapse the whole army...

This is good. Just make the group buff/debuff abilities dependent on the leader to organize them. Indirect fire-bot+spotter-bot would be awesome, but if radio-relay-bot or counter-radio-jammer-bot gets blown up, it's not going to work as well.

How realistic are you shooting for? Melee bots?

>>16763113
Actually, expanding on this, some kind of communication relay range stat would be interesting. Could lead to bot placement being really important, and allow leaderbots to matter.

So, for example, Bot A can see Enemy Bot X. Bots B and C are far away, but Bot D can pick up Bot A's transmissions regarding Enemy Bot X and pass them on to Bots B and C, allowing them to all simultaneously blow it up from different directions.

Or replace one of A, B, C, and D with a sensorbot, or something.

If there's some kind of terrain based motivation to spread out to go along with this, it could be kind of cool.

it's amazing that no one in this thread has mentioned heavy gear yet, the books are on /rs/ and demonoid and isohunt, the game does alot of what you need, including electronic warfare and different classes of mechs, as well as skirmish scale warfare

Oh hey, thread's still up.

>>16763740
I'll definitely check it out. Thanks. Still gonna make a new game, though. I'm in a game-designey mood.

>>16763113
Any game too "realistic" for melee has no place in my heart.

>>16763523
I like it. Transmission ranges. Jamming. Sensitive relay equipment. Laser-based LOS data transmission?

You'll want to stay in dense cover to not get shot, but if you're in the open your team can communicate better and get lots of fire bonuses to compensate. You can only transmit let's say half as far through buildings and rubble, so twinking exactly optimal transmitter range will be more difficult.

This could work especially well with an Infinity-style reaction order system. Especially if electronic warfare can affect turn priorities.

Oh shit, you have no guns left. You gamble everything to jump out into the courtyard and get a visual on the mech pinning you down. He turns to face you, bringing his autocannon to bear. In those tense seconds as the barrels spin up your finger sits just above the emergency eject, but you think you hear a beep. A round of superheated tungsten tears through the enemy mech from your team-mate's railgun on the other side of the building. Turns out he was in range to receive your target lock after all.

>Laser-based LOS data transmission?
Oh, this is clever. Do you go for the nice, reliable, un-hackable route with the massive drawback in positioning, or the radio that allows more flexibility but can backfire on you hugely?

>>16767009
Ah cool, when you get up I'm going to sleep. When I got up I saw this thread.

Awkward timing, aye?

Either way, I got a suggestion.

Instead of proper infatry troops, you could have small squads of exo-skeleton warriors.

Then have normal mechs, and GIANT mechs as special units.

Also it'd totally use those spider mechs all day errr day.

>>16762476
>skirmish scale
>1-5 mechs per battle
>Mech customization
>Less complicated than Battletech.

you are talking about battleforce. download strategic operations or the battleforce quick start rules and you will see how easy battletech can be

pic related, record sheet of battleforce

I've always wanted to make a Front Mission table top wargame with full customization. Mixed in RPG elements like Mordhiem, but with Wanzers.

>>16768679
Oh god if they're compatible and relayable this opens doors for all kinds of dickery.

"Scoutbot reporting! I see enemybot! Relaying coordinates via laser, over!"
"Commbot here, coordinates received. Relaying to Artillerybot on a short range transmitter, over."
"Artillerybot here. Just chilling in an impenetrable mass of cover. I see you would like all of the explosions. Lol, over."

In contrast with Team Rubegoldbergian here, you'd have Team Balance, where each bot is capable of ramboing around on its own, and each loss fucks up the team as a whole much less.

>>16768731


Allmymoney.jpg

>>16768753
Honestly I think I could churn out basic rules, but number crunching to keep it all balanced is where I'd have a tough time since I SUCK with math.

I'm thinking some 'mechs need detachable or deployable drones, to help with spotting and targeting. Doubly so for urban environments, giving you a sky-view.

I really like the grid idea proposed earlier., and can see getting shot in your drone bay or drone "backpack" to suck, as you would not be able to reattach your drone and download lots of information about...something.

I'm big on the electronic warfare aspect of sci-fi. I like Infinity for this, but it keeps it rather simplified. The first step for e-war and for any sci-fi involving battlesuits or 'mechs is to pick which sensors you want your setting to have.

For example, your 'mechs may be able to see infrared and ultraviolet, allowing it to see heat signatures. It may be able to project x-rays and see through buildings and certain rubble. An idea I like: if your 'mech can see infrared, you'll be able to tell when an infrared laser is flittering about you. More advanced lasers may use different spectrums to be harder to detect, but achieve better, similar, or worse effects.

>>16769061
About the drones mentioned earlier, deploying a little flying eyeball may turn on your 'microwave cam' monitor and let you see in that spectrum, which could allow you to see a target hidden behind terrain or something further than another spectrum. Perhaps the drone also has an automatic radio interceptor, automatically tuning to different frequencies like it's forever stuck on Search. Perhaps it also has a small radar jammed onto it that can pick up other nearby objects, but gets lit up really bright on anyone else's radar.

Then you get to the audio senses, like radar, sonar, possibly some kind of tremorsense. Good for omnidirectional detection. I can also see a sci-fi version of a "blood sense," where you can pick up on how much electricity or power is flowing inside an object or in an area. It could be like bleeding, where if you're hit in a power cable and spew sparks, a purpose-build 'mech could home in on that signal. In gameplay terms, any of these could affect where you hit an enemy and if your shots do anything to them.

The sensors are important because that's how your computers will receive the input data required to tell you what angle and type of shot you need to hit a target at your current distance, through any obstacles. Without the sensor suites and computer fire control, you're stuck in World War 2. But so far as e-war goes, it's important to know what you can scramble and ruin -- what sensors you can force an enemy to turn off and what you can hide from him.

I dunno, might be cool.

>>16769067

just a solid andcheap as hell is churning blind to worry about the audacity, dieing to get out the house i am glad i helped me so

So, drones are what? Little floating things that go "womwomwom" deployed by mechs?

Giving them a profile that's, like, two to four grid squares would be pretty fun. If sensors, a gun, and a brain all took up space, it would lead to interesting choices and list variety. Do you want to have a blob of floating guns orbiting you that rely on your directions to hit anything? Or do you want a spotter that you can put in dangerous locations and not give a fuck about because you have ten spares? What about a pile of shittily equipped drones that you can leave to defend an area and forget about, since they have their own sensors and brains and can work fine once you shit them out?

>>16768734
Oh absolutely. That's the entire point.

>>16768731

Front Mission/Armored Core is kind of the feel I'm going for here. Currently trying to decide how leg type affects the grid-based customization. So far I'm thinking leg types should all have pros and cons that balance out. Quad/spidermechs are slow, but unaffected by terrain and always stable. Standard bipeds are fastest, but only stable when they brace. Reverse-joints are somethingelseidunno.

Don't know if I want to get into the whole energy requirement thing. Probably want to skip heat management, too.


Having skill rolls and such would make room for some RPG lite progression. Aiming. Reaction time. Maneuvering.

Should an Ace Pilot make all the difference?

>>16769456
That is exactly what I was thinking. Though having deployable turrets or minitank drones would be cool too.

>>16769061
>>16769067
I like the idea of different sensor types. The trick is simplifying and balancing it. Some have lower range but wider arcs, some don't care about LOS, that's all well and good, but how specific do I want to get with sensor jamming? This will need playtesting. I am relegating the concept to Phase Two.

>This will need playtesting. I am relegating the concept to Phase Two.

Feature creep kills /tg/ projects. I think the thing to do is have a list of every single thing that could potentially go in the game, playtest, and then cut shit from the list that isn't fun or interesting.

So the general list is:
Weapons
Chassis of various sorts, including drones, mechs, and possibly SPEHS MARENS of some sort
Armors maybe
Sensors
Communications
Drone bays

...right? I'm down for listing specific parts and/r statting them if you want help getting to a playable state.

Oh, mechanics idea: every unit fits in a 10x10 (or XxX, whatever) grid. Attack rolls are d10s. This makes smaller units harder to hit, since the shot can land on parts of the grid not occupied by the unit. Not sure if this is a good idea.

>>16770033
Well the Front Mission game I was going to work on legs would basically have different movement speeds, armor and HP. Some would have flaws(like treads not being able to move as well as legs), but they'd all share the basic speed, armor, HP set-up. So based on the legs you put on your Wanzer they might be faster, but be able to take less hits and thus you have to worry about having them get blown out quicker. Or you can take heavily armored legs with high HP, but they're slow as fuck and cost a fortune.

Oh and they'd have a weight value like in the video games. Of course my idea wasn't to use a grid system, but to be more free-form.

d20 mecha?

>>16770264
I like to have a bare minimum playable skeleton and add features from there, but then again that only works if you build that skeleton with all the potential flesh in mind.

I like the simplicity of giving grids simple size catagories (small mech 3x3, large 5x5, something like that), but I'm bouncing between that and something like what you just suggested (I was actually thinking of Galaxy Trucker before I came back to this thread). If I were to go that route, I'd definitely want a bellcurve instead of a straight d10 roll so that specific placement is more important.

Simple size-category-based modifiers would streamline things nicely, but that sort of graphicaly-represented to-hit roll has its own elegance to it.

The other thing I like about the more simple grid is that it's obviously and abstraction. Having Galaxy-Trucker style mech construction would cause me to invision Galaxy-Trucker style mechs, which is as silly as it is ugly.

The OTHER other nice thing about the grid is that it's easy to call drones 2x1 or 2x2 and be done with it. With the other version I'd need a seperate system for drones, or some weird limitations.


That list looks pretty complete. I think melee and limited rocket jumps have a place in this game too, though.

If you feel like coming up with parts I won't stop you (in fact you will have my gratitude!), but I do plan on getting around to it myself and obviously I won't guarantee I'll use all/any of it.

>>16770367
>Or you can take heavily armored legs with high HP, but they're slow as fuck and cost a fortune.

I've got a love/hate relationship with this style of mech construction. Understand that I've purchased every Armored Core game up until 4 (and probably would have gotten that and 4answer too if I had the money but now I'm holding out for V...) and I tend to spend half my time fiddling about in the garage for hours, but I if I wanted to do that with five mechs it would take forever and I want this to play faster than that (including prep time). ALso, when you really think about it, having heavily armored legs and a light torso is incredibly silly.

I think it makes much more sense to have Armor and HP separate, possibly even speed if engines take up grid space, and leave legs purely a function of the TYPE of mobility (the flaws and perks you mentioned).

Unless, of course, you're going with a battletech/gurps/frontmission style hit location system, which would include weapons and sensors and mean the grid is right out. The simple grid pretty much replaces weight AND cost with a single, simple abstraction.

So basically we have two valid directions this could go.

zhuk all up in this thread

>>16770878
Yeah; my idea is more or less the first Front Mission game in miniature wargame form. More than likely players would buy generic Wanzers, and as they progress they can buy new parts(legs, arms, body, backpack, weapons and CPU). Like I said; I'm really trying to go for more of a Mordhiem with robots feel, so high customization between games is something I'm aiming for while keeping the basics of the actual gameplay quick and simple.

>a bellcurve
This is something that didn't occur to me and it's kind of brilliant. That said if you're going with the grid and having each axis be a bell curve, the most likely result is that the mech gets shot directly in the middle of its abstracted torso, which is a little bit weird. It seems like glancing blows to the outer bits would be more common. Maybe a 2d20 spread or something. I guess the final system needs a way to make the drones shootable, but also a way to make sure that the big mechs don't get hit in exactly the same spot every turn.

I'll stat things if you make a base mechanics system to fit things into.

And I included melee in "weapons" and support rocket jumps despite having forgotten them somehow.

If you go with a bell curve route, you'll need some higher-level math application skills than simply doing a d#xd# grid. However, if you had a working bell curve framework, it'd be easy to represent loss of accuracy over range (or lack of proper sensors or whatever) with a static addition or subtraction value. That would pull the shot from the center to the edges, or not on the 'mech at all.

What if there was one big grid for each object to shoot at, and the object only occupied so much of the grid? For example, an 8x8 grid with a light 'mech that only takes up 5x5 would leave 3 blank spaces all around, somehow representing how hard it is to hit?

...The idea needs to be refined. Something with 'grid squares that "turn on and off" depending on if you can see the target or how far away you are from the target' is coming to my mind. Maybe a little drone with a radar on would be a 2x2 target against an 8x8 grid when shot at with a gauss rifle or laser, but a 6x6 against an 8x8 grid target when shot at with a radar-seeking missile.

>That would pull the shot from the center to the edges, or not on the 'mech at all.
So, the center of the mech is (0,0) and you're rolling 2d6-7?

I was thinking that attack/defense modifiers could let the attacker/defender move the shot around, which would work called shots/cover/dodge into one unified thing.

>>16763740
This. It's more or less exactly what you're looking for, just be aware it doesn't have a large playerbase so finding opponents may be difficult.

>a little drone with a radar on would be a 2x2 target against an 8x8 grid when shot at with a gauss rifle or laser, but a 6x6 against an 8x8 grid target when shot at with a radar-seeking missile.

I think this is a great idea but there's no reason to do this AND modifiers because it's pretty much the same thing.

Unless you're doing "I target (2,0) with my laser." And then 2,0 gets an appropriately sized grid centered on it and the bell curve usually directs the shot to the right place sort of, no modifiers from anybody. That sounds kind of hard, short of using tons of transparencies set to scale with the visual character sheet.

>>16771363
We could simply print out pictures of the 'mechs on 8.5"x11" paper, put a penny where we want our shot to land, and roll a scatter die.

>>16771246

I love how every time I go to mull over this idea, I come back to this thread to find another version of the solution I came up with. I can only hope this means we're on the right track.

My current thinking is to combine the large grid and size category ideas. Grid representing the entire spread gives you a simple mech customization combined with a to-hit roll and I just fucking love how smoothly this works out. Size categories, easily shown as smaller grids in the main grid, are simply a function of how much stuff you end up loading your mech with, and allows me to set up simple modifiers for armor and speed and such that don't require the player to do any math.


>>16771027
>make drones shootable.
I've been considering them separate targets this entire time, with drone controllers taking up grid space in your mech. With the big grid notion, making the drones outliers on the bellcurve is quite tempting, but potentially messy...


I'm running out of robot pictures!

>>16771346
seriously, all you want is built into heavy Gear blitz...
Why bother with anew system, look it up first, eh? Might even just gahve some elements uoy want!

>>16771574
I actually did download the books, as per the suggestion of the first anon to mention it, and will look through them. I'm sure it will gahve[sic] at least some elements I want.

>Why bother with anew system,
Because it's fun? Besides, if everyone thought like you there wouldn't be any old systems to look up.

If the concepts of work or creativity bother you, then just sit back and let me handle it. If you don't like the result, ignore it (or even criticize it!).

That is all the fucks I give about this question and all its variants.

>>16771574
Some people enjoy creating things. I play Blitz, but doesn't mean I don't want to make my Front Mission game.

Made up any sketches of your grid plan yet? Prototypes are fun!

33333333333333333333333333
cat on keyboard
bump!

>>16775112
Yeah, I'm waiting too.

>>16775112
Juggling a few ideas ATM.

The rate at which mechs get huge is bugging me here. Expanding a 3x3 grid concentrically means 5x5 is medium and 8x8 is large. If I do a pyramid (which would work out nicely for 2d6 distribution) mechs go from 4 squares to 9 to 16.

The other problem is that I can think of two ways to deal will rolling against the grid and they both seem clunky.

1. A roll for each axis. One die each means it can be done reasonably in one roll, but there's no bellcurve and thus placement doesn't matter (you can't prioritize parts). 2-3 dice means we can have that nice bellcurve, but rolling twice for damage might be clunky (though it might be okay since it also functions as a to-hit)

The size issue could potentially be mitigated somewhat by making bigger guns and more advanced systems fuckin' huge.

2. One roll, hitting the first thing on the outside of the grid, using the actual attack direction. Galaxy Trucker style. This unfortunately removes most of the abstraction from the grid system and gives the impression that your mech is some hastily cobbled together horseshit. I don't want the grid to be an actual physical representation of your advanced killing machine.

NEW IDEA!?
Let the victim choose. This weapon does 1x4 damage, and when you get hit you place that anywhere on your grid you want.

ALSO: Thinking of naming the game Gridiron. Too cheesy, or absolutely perfect?

>>16777698
>ALSO: Thinking of naming the game Gridiron. Too cheesy, or absolutely perfect?
Neither, but good enough for a name.

>>16777698
I can imagine this well as an old sprite-based game with your grid status indicator on one side (like Star Control II) and watching squares flash from an armored-looking square to white, yellow, red, then black.

Not helping, just stating.

>>16777750
Yeah, this. The grid based hits thing seems to go well with those 80s wireframe greenscreen model things. You can imagine individual parts flashing yellow/orange/red pretty easily.

rolled 4, 5 - 7 = 2

>>16777698
>rolling for damage
>other wonderful crunchiness

You don't necessarily need to roll for damage, weapons can have fixed damage, after all, a bullet hole is a bullet hole.

I do kinda like the previous called shots + overlay where the weapon type determines the scatter rules. Then you could have fun bell-curve functionality with (two) 2d6-7 or even just a 1d3-2. Maybe some weapons might scatter 1d3-2 horizontally and 2d6-7 vertically.

The other benefit of a called shot + scatter is it makes a miss virtually impossible when trying to shoot the side of a barn, and doesn't place any game restrictions on the size and shape of the grid-mechs.

>>16777940
Yeah, something like this, but not exactly. Rolling for damage isn't really necessary.

My thought is to have weapons' stats be mostly determined by their shape. So, a gatling laser would attack four times and hit a single square each time. A rocket would hit a 3x3 square. A melee attack with a giant saw would hit a 1x4 area, oriented whatever way the attacker chooses. A mass driver would hit one square three times (destroying that square's contents and doing 2 points of HP damage, or doing 3 HP damage if that square was already destroyed). Etc.

After a few minutes of brain switching rolling for hit location is pretty much the same as rolling for damage. If you hit an important area its the same as doing more damage, if you hit mostly useless crap that wasn't that important you did less damage.

SOMEWHAT related:

In, um...one of those tabletop miniature spaceship wargames people always say have flying penises while conveniently not thinking 40k's ships look like flying penises as well, there are humans and then different alien types. Health charts for ships are arrays of boxes, basically used as markers. Big ships will have 3 or 4 rows of a number of boxes. Normally damage goes off a track -- you take 3 damage, you mark off 3 boxes in the top-most row, like a normal person would expect. One of the aliens uses railguns, and to show their penetration power, they damage ships in a "line" rather than ticking off boxes horizontally. Or perhaps I have this wrong and they only do this to another alien race's "shell" shields...Yeah, I think I have it wrong.

Anyway, might be helpful.

>>16778195
Pretty much this. Hence my thought that maybe two rolls for hit location isn't so bad since it covers to-hit and damage at the same time.

>>16778280
Certain areas will be more armored than others...

>>16778869
You could have a 4x4 armor block hits to the inner bits until destroyed completely.

Or, by example: Murderbot has a 1x1 armor chunk at 6,6. It gets shot there, destroying it's 1x1 armor chunk. Then Murderbot gets shot at 6,6 again, and with its armor down, it takes internal damage.

Deathbot has a 4x4 chunk of armor at 3,3, 3,4, 4,3, and 4,4. It gets shot at 3,3 twice. The first shot does damage, the second does nothing. Or the second gets put in the armor chunk box of the player's choice.

Point is, damage to specific locations handles plenty of stuff that's normally done by abstract accuracy/damage rolls. It's ok to have the fluff/crunch convergence handled back end, or de facto, or however you want to put it, rather than MY ARMOR LEVEL IS THREE I HAVE THREE ARMORS.

>>16779037
Intriguing. Not sure if its the best rule, but if a hit square is next to an armor square you could eliminate the adjacent armor instead of the hit square. Probably best if the player is forced to mark off an adjacent armor, but gets to choose which of the 8 squares to mark off.

So if you had a 2x2 component ringed by armor the armor would protect the component from the first initial hits, but subsequent hits on the same side will damage the component even though there remains some armor on the far side of the component.


Oh, short question. What is the plan in gridbuilding to enforce the robot looks robotish?

>Not sure if its the best rule
Yeah I'm just shitting ideas in the hope they will spawn better ones. Your way is probably better.

>Oh, short question. What is the plan in gridbuilding to enforce the robot looks robotish?
I didn't remotely have one, but it's a good idea. It's probably best to keep it semi-abstract, since drawing a nice looking robot in a 3x3 grid of pixels is going to be impossible.

There's also the issue of deciding whether to put legs or treads on the same model. If each chassis can have legs or treads or wheels stapled to it, trying to draw legs, treads, or wheels as part of the chassis is a bad idea. Same with arms.

I guess the question is how much is going to be hard built into the frame?

I don't see any point in the grid unless it's completely abstract. If you want a physical representation of your mech on paper it's better to go with a diagram with hardpoints and hit locations. I think the grid is nice because it abstracts weight, size, to-hit, and critical systems damage into one roll.

My current thoughts on the grid are as follows:

7x7 grid with a 3d6 bellcurve distribution. Central 3x3 is a Small mech, 5x5 is Medium, and the full 7x7 is obviously Huge. Huge mechs are hard to miss. I am okay with this. The most common rolls, 8-13, would result in a hit to the central 3, which might lead you to wonder what possible advantage there is to being a Small mech. This is where modifiers come in.

Defense Modifiers will be +-. Since dead center is your general goal, variation in either direction is equally detrimental to the attack. Defender chooses whether it's a + or a - depending on what they want to risk. Defense Modifiers will be referred to as -# for clarity.

Attack Modifiers are applied after the Defense Modifiers, to pull in the opposite direction. They will be referred to as +#

The following numbers are pulled completely out of my ass. -4 to hit a Small mech behind cover; -3 to hit a mech moving fast; -2 for trying to hit anything at all while you're moving.

Little fuckers are hard to hit.
Good thing you've got +2 for every linked mech in your squad with LOS on the little bastard even if they choose different targets.

Shitty .gif of number lables on a 7x7 grid related

>Since dead center is your general goal, variation in either direction is equally detrimental to the attack. Defender chooses whether it's a + or a - depending on what they want to risk. Defense Modifiers will be referred to as -# for clarity.

Oh, this is nice. I didn't really know how you were going to make the whole bell curve thing work, but it's good. Has a nice "BWEE BWEE BWEE BWEE BWEEBWEEBWEEBWBWBWBWBWBW 'Target: Locked.'" feel to it.

>>16779869
Leg type will be independent of the Grid and provide static modifiers.

Quad/spider legs let's say always count as stationary and ignore rough terrain but are -3 to movement.

Reverse Joint legs don't need to stop and brace before boosting or after landing.

Standard Bipeds are standard. I can't think of anything else yet. This can easily change as more mechanics are figured out.

Caterpillar/Treads mean you are a tank I guess. Can't turn as fast, difficulty with terrain, but have the best straight-line speed of anyone and always count as stationary like the quads.

It's assumed that your legs are the fastest ones that can carry a mech of your size and loadout.

>>16783259
My initial thought was to have armor simply be a function of mech size. I want more customization of it than that, though. Maybe +1 armor for each empty space on your grid?

I like the notion of having armor as an item on the grid specifically. Maybe protecting adjacent squares? Seems kind of clunky though.

In either case, extra armor should be ablative.

>>16779552
>Oh, short question. What is the plan in gridbuilding to enforce the robot looks robotish?
I kind of almost answered it before, but I left out the bit where I emphasize that this game is intended to be played with models. Ideally these rules will be flexible enough to represent/be represented by and cool models you have laying around from other games and/or build out of legos.

Bumping because I like the ideas in this and want to see where it goes. Too late for me to contribute much else.

>>16777698
>ALSO: Thinking of naming the game Gridiron. Too cheesy, or absolutely perfect?

Are you aware that 'Gridiron' is what American football is often called outside of the US? Well, sounds like you are.

I explained before in such a way that walkers would be viable.

Global EMP/Blackout of all communications beyond visual. That can be distorted (REAL) lasers that distort the light waves around them to blur their surroundings at a distanced onlooker. (yes it's actually real, but not advanced enough right now to be useful in 360degrees)

Cannot be AI robots, or get a signal to them for remote control, those get hacked easily too. They must be big to have all the weapons they need. They must have all artillery class weapons on par with WMD's, nuclear weapons, and so on. Firing can be traced back to their location so they always must keep moving. If a satellite tracks their footprints after they got a beat on one, it's a matter of time before a nuclear artillery shell from another walker nails him.

Think superedge warfare over new planets to mine. Lasers destroy missiles, so it's all shell and laser combat, reducing the size of nuclear warheads used in the game. (there's a limit to EVERYTHING, full circle)

Full on mech combat. Large scale so it would be pins on a large map instead of actual minis.

>>16783447
Nuclear shells can be limited if one sneaks up on another. You can have a battleship themed game trying to track the enemy forces and the way the war is waged they all must be lone wolves hunting each other down.

Sometimes friendly fire happens. So add that in too. (blackout conditions just like WW2 lack of communications)

>>16783405
I did not know that. Goddamn handegg always slightly inconveniencing me occasionally.

I was thinking in terms of urban planning, what since this is a game about urban mech combat.

Apparently it was also the name of a novel about an evil AI in a robot skyscraper.

Meh. It's still the name until I think of something better. Worst case scenario this is the first thing called Gridiron that doesn't suck.

>>16783386

>>16762476
Less complicated than Battletech.

>Complicated...
>Battletech...

WTF am I reading... OP Battletech is NOT that complex... ok, well maybe alot of the more super advanced stuff is, but why are you trying to get into that without first playing 3025 era battletech? If you're looking for skirmish games of 1-4 mechs with decent rules, Battletech IS the way to go OP...

Seriously, normaly I wouldn't say this, but... PICK FUCKING RELATED

>>16783591
>implying I don't love Battletech
see
>>16771614
and
>>16774724

Makers gonna make.

>>16783447
Cool concept. Of course logically you'd use submarines in that situation, so it still boils down to the same question and answer every time

Why are there walking tanks in my game/setting? Because fuck you, that's why.

How would that game play, though? All I can think of is Battleship.


Anywho. Thread is now archived for my convenience, and and obviously that of the few others in this thread who aren't me but are still interested.

http://suptg.thisisnotatrueending.com/archive/16762476/

I was thinking a larger grid than 4x4 for something like pic related.

>>16783526
Hell, it could even be fitting given how much American football is kinda like trench warfare.

We could really use more tabletop-style wargames and RPGs for mechs and spaceships, especially ones not tied to hyperexpensive minis or ancient rulesets.

I've had my own ideas for a giant robot pen and paper system with literal point buy- as in, your points are cash and your force is determined by your budget.