Currently, The build time of a unit is directly dependent on it's metal cost, divided by the amount of metal fabbers or factories may throw at it, based on this simple equation: build_time = metal_cost / nanolathing_per_second While pretty understandable and logical, this induce an unwanted coupling between metal_cost, and build_time. Adding the fact that there is a wanted coupling between metal_cost and the unit efficiency per metal (this coupling is in fact implicit, as the global efficiency - which may take in account all unit parameters like health, speed, dps - per unit of metal should be equivalent for each unit unless wanting an overpowered unit), this means that the build_time is directly correlated with the global unit efficiency. While this ensures that the global army efficiency growth is a constant for a given nanolathing_per_second (which itself is derivating from territory control), it introduces the following problem: given sufficient nanolathing_per_second to a single spot (like when assisting something) literally everything will virtually have no build time cost; that's why a player with a sufficient economy can literrally spam turrets when detecting an army approach (this is even worse since combat fabbers were introduced, with their high nanolathing). There was suggested many times to introduce a build time factor for each unit. There is three implementations that I can think of: 1. Introduce a simple build_time_factor build_time = metal_cost / nanolathing_per_second * build_time_factor This won't solve anything: it's almost the same as setting a higher metal cost for the unit because it introduce the notion of "wasting" metal. To be honest I though this simple solution would work until I saw the flaw. 2. Introduce a maximum for nanolathing_per_second build_time = metal_cost / max( hard_limit, nanolathing_per_second ) This solution introduce the notion of "fabber" wasting: when the hard_limit kicks in, additional fabbers will not help anymore when building. At least, the player won't waste metal like in the first solution. 3. Some building, like turrets, can't be assisted This solution would permit specializations in fabbers: imagine a fabber that is sturdy, but real slow to build (a new kind of a combat engineer) or one that is real fast and fast to build. Perspectives for this options are encouraging, but I didn't think about them longly, as it would completely redefine fabbers in general. Can you think about others solutions? The second option is seducing, however, without visual clues about fabber wasting, it's clearly a no go (I don't want to send 10 fabbers on a turret knowing that out of ten, x fabbers will do literrally nothing). I suppose that they could literrally ignore assist orders, which would make some use for them of the patrol command (being limited in assisting, they will by themselves divide in all possible assistable factory / construction in the area instead of focusing on the first factory / construction they find).
Basic economic management. There is no point assisting the production of units with more or less build power than you regain during factory cool down What do I mean by that? Say your unit costs 100. Factory roll off time is 5 seconds. If you spend 25 metal per second on the unit, you gain 25 extra metal every cycle. If you spend 15 metal per second on the unit, you lose 25 metal every cycle. Both of those scenarios are not optimising your economy. Stuff doesn't have virtually no cost. There is always a cost. There is a cost to wasting buildpower during downtime. Personally I think the metal cost as a product of build output and time is neat. It has limitations, as you identify. But ultimately I quite like it.
Use TA's system of having an independent buildTime property for units (and an independent build power for builders) [UNITINFO] { UnitName=CORACV; Version=1; Side=CORE; Objectname=CORACV; Designation=COR-CV1; Name=Adv. Construction Vehicle; Description=Tech Level 2; FootprintX=3; FootprintZ=3; BuildCostEnergy=4504; BuildCostMetal=455; MaxDamage=1220; MaxWaterDepth=18; MaxSlope=16; EnergyUse=0.2; BuildTime=10806; // Determines how long the unit takes to build WorkerTime=200; // Build Power, rate at which unit builds other units So if a Adv Construction vehicle was going to build another adv construction vehicle (ignoring that it can't do that without a factory) $realBuildTime = $buildTime / $WorkerTime = 10806 / 200 = 54.03 (in game ticks) Metal Cost Per Tick = $metalCost / $realBuildTime = 455 / 54.03 = 8.42 Metal Per Tick Energy Cost Per Tick = $energyCost / $realBuildTime = 4504 / 54.03 = 83.36 Energy Per Tick This will allow you to have cheap units that take a while to build, or expensive units that build quickly. The down side is you could have 1 builder using a crap ton of resources on an expensive fast building unit while a cluster of builders working on a cheap slow building unit could be using next to nothing. This makes it harder to keep track of where your resources are getting spent. #2 Maximum nanolathing per second seems like it would require too much paying attention to, in the middle of a game i can't keep track of making sure each of my priority constructions has the max number of builders but no more. #3 Disallowing assiting on some buildings. No offense but that seems horrible. I can get behind not being able to assist nukes in a nuke launcher, so it's more like a catapult (TA did this) but allowing some things to be assisted and others not seems confusing, and doesn't seem to jive with the whole style that these type of games use (TA like RTS games)
Roll-off time for factories is the limiting factor, which does alter the 'optimal' way of doing things depending on the factory, even for different units from the same factory. Assisting air factories is better than any other as the roll off time is low, so build efficiency is higher. To maximise build efficiency, assist two factories with a single fabber. To show the build time differences between units, here's tests showing the speedup by assisting with 60 metal/second throughput (aka 6 fabbers). This is taking into account rolloff time using pte v64758 (same as now except these tests show air fabbers costing 200 metal, and combat fabbers costing 720): Air fabber: 4.8x Firefly: 2.85x Hummingbird: 4.28x Bumblebee: 4.57x Bot fabber: 3.36x Combat fabber: 4.75x Stinger: 2.41x Dox: 2.41x Boom bot: 2.41x Vehicle fabber: 2.57x Skitter: 1.76x Inferno: 2.90x Spinner: 2.35x Ant: 2.35x Naval fabber: 1.875x Sun fish: 2x Narwhal: 2.38x Orca: 2.25x For buildings, movement time is the limiting factor. You wouldn't have a group of a dozen fabbers building mex.
There was a reason this obfuscated mechanic for handling how things were built was taken out. Planetary Annihilation's Economy System For those newer members that weren't around when this was a hot-topic, hidden/obfuscated buildtime and buildpower multipliers are considered by Uber to be a major barrier for entry into the TA-like genre of games. Thus, buildtime or arbitrary "max metal per second" limitation is highly unlikely to be put into PA.
I know why it was taken out, I just think the benefits of TA's system outweigh the complexity. Something else that could be done is to shorten nanolathe ranges, so that way you can only fit so many units around a construction. That would probably just shift power building to air fabbers though since they can stack.
This was absolutely true for Supcom. But then again... Supcom made more mistakes that made a bad system even more difficult to manage. Supcom's economy was quite simply bad. Economy had its problems in TA. However most economic drains were kept inside sane boundaries and storage was big enough to handle the rough edges. It was tricky but a new player can learn it fairly quickly because TA was forgiving of mistakes. PA simplifies the system, which is fine. Unfortunately it's TOO simple, which creates new problems. The discrepancy between mobile vs. immobile construction will remain impossible to rectify. The game also makes a HUGE mistake by doing away with forgiveness. Economy is the hardest part of any RTS to learn, and PA decides that sticking broken glass into dark places every time you mess up is a good idea.
I don't necessarily disagree on any particular point @nateious & @bobucles. All I'm doing is referring you to the stated reasoning given by Uber. If you like, I can try to get a little more information and context on the subject next time I have the chance to talk to a developer. Is that something anyone here would like me to do? However, from what I can tell so far from what's been stated on the forums, in livestreams and in at least one meeting already it seems to be that Uber's main concern with PA in this regard is the removal of much of the complexity that they would view as an unreasonable barrier for the audience.
I understand about factories roll-off times. However my point is still valid when constructing turrets or other buildings that can be assisted (mexes, energy generators), and that was the main reason I first posted this topic.
Very interesting topic, i'll take an extensive look at it. However like said, I think balance (at least build time) may never be achieved due to this... let's see how Uber will handle this situation .
Hmm what if energy was constant but metal usage was based on a buildTime. On one hand it might be more difficult because you'd have to remember 2 different methods, but on the other hand you'd only have to keep track of (variable) metal usage instead of metal and energy. Maybe give the user an eco heat map to show high usage metal hot spots so they could quickly identify where it was being spent.
Nope. Games should be simple to play but difficult to master, adding in "hidden" variables here and there is not good.
TA had plenty of hidden variables for its economy and few of them were any critical detriment to gameplay. Indeed few of them even mattered because they weren't very dramatic in scope. Did you know that TA dirt provided an amount of metal that could be harvested by extractors? It's not a big deal because you'll never make an economy off of it. Constructors spent different things on different projects, yet it still wasn't that difficult to keep your metal low and your energy healthy. It was Supcom that showed how badly it could screw up. But don't take my word for it, go see it for yourself. Build a RAS upgrade on your Commander 2 minutes into a match. Or try repairing him after he takes some damage. Let me know what happens. The simple fact is that Supcom took a system that TA never let get out of control, and then let it get out of control. Throwing around orders of magnitude without any regards to the consequences tends to do that. The devs allowed players to make bad decisions that would kill them, some of them through inexperience and some of them secret enough to screw over veterans. It was not good. Before explaining how a build time mechanic would work, it would be better to explain what you would use it for. Is there some project that could be better served by being available faster or slower? Is there some oddity in infrastructure or unit costs that you can't fix any other way? I know that TA used build time mostly so that base construction could be fast and easy(if expensive), while factory construction was much more throttled. While Supcom defnitely screwed it up, TA's build time allowed mobile constructors to be more useful when they were being mobile, rather than as factory slaves.
If my 12 year old self could figure out TA's economy then it can't be that hard to learn @bobucles I think the best advantage TA's system has over PAs is you can adjust how effective assisting is. Lots of people complain about powering out nukes (the missiles, not the launcher), if PA keeps allows you to assist a nuke, the only thing they can do to make it take longer is up the cost. With TA's system you can give the launcher a very high build rate and the missile a very high build time, then the amount of build power the fabbers are adding will be negligible compared to what the launcher itself is adding so assisting won't work as well. I'm pretty sure that's what they did going from SupCom -> FA.
There's really nothing I can think of that Uber could.... Wait, yes. I want to know easy it would be to mod in.
This is definitely true. Keep in mind that TA did not allow nuke assisting at all. Everything was processed and built by the nuke facility entirely on its own. That's not an unreasonable thing to do in PA. One stacking concern with the nuke is not so much with its build cost but rather with the time you have to respond. Both TA and Supcom deliberately kept the time slow, so that the defender would always have adequate time to deal with it. With assisting allowed the only other metric is to alter the nuke's cost, which creates an issue of dangerous overpricing, which means you need to make the nuke stronger, and so forth in a happy cycle of never finding the sweet spot. But nukes are just one thing. It is not a big deal to say that nuke assisting is or isn't allowed. Are there any other things that could benefit from a change in build time? The other games seemed to think it was very important for base building to be quick and easy, yet limited in growth at the same time. Does that matter here?
Yep I remember . Honestly I'd prefer TA's style nuke / anti-nukes where you can't assist at all (but you can store as many as you want in the launcher, oh and it tells you on the nuke button UI how many nukes are ready ), however many people (in other threads) have said they want to keep it assistible because it will be more consistent, this way is a compromise, a way to fix assisting w/ out removing it, of course in this case PA would need a different eco system to use this compromise. I used nukes as this one example but it pretty much applies to anything, want to keep base defenses at a reasonable metal priced but don't want them spammed as quickly? raise the build time but don't touch the costs. Want make having more factories better than a huge blob of units assisting one factory? Give the factories better build speed vs units (of course PA manages this in a different way) Want less T2 units and more T1, do that to just T2 factories but not T1 so T1 can be spammed in large numbers with assisting, but T2 can't as effectively. If we ever do get megabots, and you want to keep their numbers lower (so you have to bring a supporting army rather than just an army of megabots), same deal give the megabot a crazy high build-time, the gantry a high build speed and suddenly your 250 aircraft fabbers are only increasing the build speed by 25% instead of 250% (or whatever)
I don't think it really works that way. Players will always work to spend all of their income. The effect of build time is mostly with how many workers are needed for some project. So if something takes twice the time to build, you simply send twice as many workers at the project to bring the metal back to zero. In PA, workers soak down the energy so needing more workers means you need to spend lots more on infrastructure. Early game is a bit annoying because early game involves a lot of structure spam. Structures take fabbers to build, and fabbers are designed to be the most expensive constructors in the game. So there is this initial spike where you have to build everything all at once and it takes a long time to settle down.
Straight up it might not, but if workers didn't have as long as a nanolathe range then you could only fit so many around a factory, unless I suppose, you used all air fabbers (which in TA had half the build rate of a equivalent construction vehicle) . I guess one of the other limiting factors in TA was the unit count, in PA since there isn't one (yet?) you can spawn hundreds of workers with no worries that it will limit how many unit slots you have left for a real army.