What do you think of the scale of Ubers Mega-bot.

Are you discussing balance or scale?

I can never quite tell if pawz is being serious or not when he posts. Another unique style of posting... not quite sarcasm

He plays devil's advocate a lot.

Nanolathe, you should get a job at Uber.

Maybe there needs to be a baseline for units? I wonder if the rule should be that the commander should beat ANY unit 1v1, and work from there?

*Just Brainstorming for a solution*

So this translates to scale, as...?

Let's look at this another way. The lore states the reason for 1 faction is due to determining the optimum units over time. Does a megabot fit this?

Most definitely not.

Firstly, it's an expensive, giant war machine with massive weak spots (legs). It's lightly armed for it's size and expense, cannot be hidden and is an "all your eggs in one basket" strategy. As a fact, it is simply a bad machine to wage war with (Smaller versions work because of the mobility gains and because they are individually cheap).

So lets look at the possible ways this unit will play out in game.

1. It can kill lots of small units. Result? People won't build small units. Game is no longer about large battles but rather just a few uber bots.
2. It can't kill lots of small units. Result? Laughably UP for it's size. Breaks in-game consitancy and also breaks lore (in addition to it being a large mech).
3. Either way, power scales really, really, well in numbers, making a few megabots of any description incredibly powerful, and pretty much surely broken.

and 4, a point I raised earlier in the other thread, where are the in-between units? That makes no sense. Several units half way between the uber bot and normal units would be better in all respects (and the half again, and so-on). Individually cheaper, greater mobility, able to assemble firepower as the units are built, rather than in one "lump sum" at the end, and they are able to kill the larger bot more cost-efficiently (because you can't make experimentals cost efficient, or it's the only thing that will be built). Ergo, Uber bots are useless, as they are supersceded by regular units.

So in short, the uber bot is neither good for gameplay nor fits with the lore of the game.

Ah, you are right. I was getting carried away with people talking about "balancing" the Uberunit, which they somehow linked with scale compared to the commander/ other units.

I guess, if the size=firepower and the commander is the baseline unit (As-In "most powerful weapons"), an Uberbot would be around the size of a Commander.... Which is around twice to size of a t1 unit.

I, personally, prefer the giant-lumbering-behemoth that is in the whitebox test.

Great post!

I don't have a problem with a large robot. But I do have a problem, if the large robot has a to big impact on the gameplay mechanics.

In TA I build lots of robots and tanks to kill the enemy.
In SC I build lots of experimental units to kill the enemy.

And this is logical: You will automaticly choose what is stronger or better.

I loved the idea of super units. But the fact is: You will use them if they are available. And the other fact is: You don't use all the other units, because you don't need them anymore.

I think the only sensible use of mega units is to add value to other units or to support the other units. For example, as a transporter.
Who has used the transporter in CS? Why building all the "weak" units and put them in a transporter, if you could build an experimental unit instead?

Spoken like someone who's never had to deal with a difficult problem. Especially in programming. It's extremely common to scrap a poor solution in order to come up with a completely different, better one.

Why should the commander be able to take any unit 1v1? That doesn't really make any sense. The commander has always primarily been a construction bot with some offensive capabilities.

The only thing you can safely assume about the Mega-bot is that it will be expensive. You just made up everything else. It's hard to criticize it's use when we only have a picture to go by.

SupCom made this possible (at least in T1 and Technically in T2) just by making the ACU a tough target, it has 40x the HP of a single Striker, so even if it had a weak attack, it has the time to still kill the unit. Being able to kill a single unit, in a game where armies number in the hundreds, is not a balance issue for the commander. It should be able to defend itself, and how effective it needs to be at this will depend on how the gameplay pans out.

Mike

Both? I'm talking about how the design and size of the unit is indicating that the suggested role is as a scaled up combat unit. I find that kind of thinking to be detrimental to the balance of the game. And therefore, in thinking of better roles (interplanetary assault, planetary defense), you are talking about weapons that need to scale WAY up. Not four times larger than a tank, but FORTY times larger.

A simple example - to shoot stuff on the ground a 'big' gun (battleship) today shoots around 40km. To shoot stuff in orbit, a gun needs to shoot 2,000km.

Um no, that is all fact. It does have legs, and it is putting all eggs in one basket (as opposed to spending the resources on many smaller, easier to hide units). The lore of this game says that all units are refined to their best, and a bipedal, massive walker IS VERY, VERY BAD. In no way is that a good configuration for a war machine. You are literally better off in every respect building many smaller units. If that's not the case in PA, then they are not only going against their own lore, but the rest of my post which you've ignored shows how bad for gameplay that is.

So as you can see it's pretty easy to criticize just based on it's looks.

If I might give an example of bad scale?

The king kriptor, a large and powerful experimental, but it's scale is too big when compared to it's balance.

Say for instance, a king kriptor is as powerful as 20 rock head tanks, that's all well and fine but the problem is the unit is scaled to be as powerful as 30, and that's not good.

So that's my problem with scale, when they don't portray the balance well.

You don't know what you're talking about. The contradiction in your own post is evidence of that.

PA is itself an example of scrapping the old Supcom engine to make a new one.

That's not the same thing. BM is referring to "fixes" like changing your math everywhere in the program because your addition function makes 1+1 = 3.

Sounds like a problem that should be fixed to me.

Thats more because Uber doesn't have access to the Moho Engine and that it's not a good fit for PA's Scale/Scope.

A Better Example is SupCom2;

Oh people think the Eco is too confusing? Instead of streamlining the current Eco, Lets Scrap it and do something completely different!

Oh, People hated the management of Teching up Mexes and Factories? How about we implement a Research System That does something completely Different!

Frankly, Even GPG's Balancing played out like this;

New Unit! Aeon Mercy!

Release - OP as ****

Next Patch - UP as ****

Mike

I welcome rationalism back.
Thank you very much.

Regardless of how good the pathfinding is, there will be a role for a unit that concentrates power if your economy is much stronger and your enemy is turtling quite effectively. The only way to "solve" needing a way to concentrate firepower is to remove collision detection altogether. (Which is why air was so good in the late game in TA)

Also, often "problems" in programming are not always caused by bugs or failures to "fix" the design, (usually by coding different behaviour for exceptional cases) they are caused by the design decisions being wrong in the first place, and parts of the design need to be scrapped and replaced. (or at least, it's often faster to scrap and replace the whole feature than to kludge the solution by coding the necessary exceptions in) This is far more common in programming than in engineering because a lot of bad or improvable design in software only becomes apparent in use, because of how relatively little experience we have in using software compared to say, buildings and machines, and because pretty much the only costs are labour costs.