Ideas from Zero-K

Very nice features, i'd like to see them in PA

Updated OP with many of fairly small UI features. They add up to make the UI a lot more powerful.

Those are quite some elaborate UI functions, if this gets included, I think I am going to learn some hotkeys for PA for the first time with an rts . These hotkeys would remove the need for a very high apm. (I am a quite lazy RTS player, Total war like)

also since Zero-K is open source, wouldn't it be relatively easy for the devs to include these kind of features? (depending on the language of ZK)

Uhhh.... porting code is really time consuming. I can't think of anything in these features that would be worth porting code. That is ignoring possible legal issues with GPLed stuff.

Most of these features have little complexity algorithmically. There is a bit in custom formations to decide the ordering of units along the line to minimise path length and command insert also has to decide where to insert the command. But is it not even close to worth porting that, I'm sure if they wanted to they could figure out. I think the algorithms would only be particularly interesting if, for example, the area mex command had a polynomial time TSP solver.

Even the question of what ZK is written in is a funny one. ZK is a bunch of content and lua scripts running on the Spring engine. Apparently the seam between ZK scripts and engine features is hard to spot which I suppose is a good thing. The engine is written mostly in C++ and directly implements about a third of the things in that list of features.

Everything else is in lua which of course must use spring specific functions and callins. Most of the other features in the list are implemented by lua widgets which are basically locally run (unsynced) UI scripts. They can see and do everything a player can see and do, that is they can read things like unit positions and give any kind of command. Some of the features here are implemented with lua gadgets which are effectively addons to the synced simulation. Gadgets can do basically anything, the api is pretty complete. Gadgets are more for game mechanics coding which I have not really mentioned.

So yea, it's complex.

Ok I understand, I think...

I am not a pure programmer my self (only knowing C#, JS and *Ahem* Action script XD)
I am only starting to learn, but I find it really interesting, thx for sharing

All really great ideas. I especially like targeting stuff for long range weapons and the economy breakdown. Build times are a must as well, but I feel those will be included by default because there's no real reason not to.

One more thing from Zero K worth mentioning is the energy grid and overdrive system.

There are no metal makers in ZK (in TA these directly transmute energy stocks to metal), as these reward porc too much while ZK favours territory acquisition and metal extractor coverage as the primary determinants of resource income.

However there is a system in ZK by which energy can boost metal production. All energy producing buildings (wind, solar etc.) have a radius over which they can transmit energy, shown as a green circle when you build or select them. Connecting the green circles of nearby energy buildings links their energy transmission (there is also an 'energy pylon' building with a large radius but no production).

Linking a metal extractor to an energy network allows that metal extractor to use the energy produced by the linked buildings in the connected network to increase its metal production (with an inverse exponential relationship so that a reasonable amount of energy gives +50% metal and a late game very high amount of energy might give +120% metal).

Furthermore, some of the largest turrets and superweapons in ZK need to be linked to an energy grid with a specific (fairly high) minimum energy output. Raiders can then disable superweapons by taking out the energy grid supplying them instead of destroying the weapon itself.

This system is maybe a little complex but it works really well, as there is a fight to maintain both metal extractor and energy grid coverage in your territory.

Also there's a similar linking system for shields where nearby shields can replenish the charge of a depleted shield (charge transfer is not instant so focused fire can still take out a single shield on the edge of a network).

ZK needs some more tutorial videos regardless. They can take a bit to make though.

The resourcing system that thefirstfish outlined is more of a game design thing than a basic UI feature or unit AI so it is a lot more debatable. The economy is an important topic though. There needs to be some way to economically invest in the future

In TA and supcomm there were 3 main ways to invest in a future where you have higher metal income. I think this sums it up:

• Capture more mexes.
• Upgrade your mexes.
• Spam metal makers.

Note that while reclaim is a way of gaining metal it is not a sustainable method. Anyway capturing mexes runs out fairly quickly but allows you to upgrade mexes. Once all the safe mexes are upgraded you can work on a never-ending exponential metal maker economy. I don't like this because eventually territory control is meaningless compared to your metal maker economy if the game goes for long enough.

Territory is kept relevant in ZK by letting energy multiply your base mex income with diminishing returns. There are more details (such as the energy grid system which does this) but they are unimportant here. Basically it is a system that both allows large investment in your economy and keeps territory relevant. I don't expect or suggest PA use this system because it was tweaked over years specifically for the gameplay of ZK.

What I would like is some discussion about the economy. Supcomm didn't seem to rethink the economy at all, it just added another tier to it. PA will need new ideas for the economy because the play field has changed significantly. If bases are more easily destroyed then metal makers are less powerful. If there are high yield but hard to reach asteroids then metal makers may not be the only way to really ramp up economies. I don't know exactly how it worked out in FA so some feedback from there would be great too.

FA economy

About SupCom:FA economy:

Metal makers were more efficient than upgraded mexes in SupCom. So you basically just needed more and more space and abit of micro to make farms of metal makers in SupCom.

In FA the metal maker economy was nerfed while highest tier of mexes had increased output.
Players would then grab mexes as fast as they could and fight over reclaim. Wrecks left 81% of their metal value when killed so wreck fields became very important. Rather than spending 900 metal on upgrading mexes the same metal could be spent to push the enemy and secure the wrecks.

In bigger maps such as Fields of Isis you could usually choose if you wanted to move out and take some extra mexes or if you wanted to upgrade all in your base first. Since that t3 mexes were almost as effective as t2 mexes you could upgrade all your mexes up to t3 before moving out therefore making territory less important since Fields of Isis had few mexes in the mittle while it was easy to defend the one choke point near your base. In competitive matches you would also have to find a way to prevent the enemy from fully utilizing the mittle mexes and gaining all the featured reclaim on the mittle of the map.

After all "safe" mexes had been upgraded going for a metal maker economy would usually be a bad idea since of how volatile and inneffective they are. Then it is better to win some territory or deny it from the enemy.

Zero-K sounds awesome!

And I love your ideas!

I love pretty much most of these ideas (well, except for the flat tech tree). Thanks for posting these and I hope at least a few of these can get implemented!

I am in support of a lot of the features you suggest, however, there is one which I dislike.

Automated Micro:
While I definately agree, that Micro should be simplified for a game focusing on strategy and macro, I think your suggestions go too far.
Automatically dodging projectiles makes smaller engagements unpredictable, since e.g. 3 tanks could win against 4, if they have enough luck with dodging. Without player involvement, an advantage in a battle should always translate into winning the engagement.
Automatic kiting could even become a big balance issue, since kiting extends the time in which you can utilize your higher range to deal free damage. This makes a range advantage more powerful and could spell doom for anything which happens to have a rather low range.
As for repair zones, I dislike the automatic retreat. Retreating from a battle imo is a big decision, since you can utilize a retreat to get into a better position, or you can retreat key units in order to lure the enemy in, because he wants to focus them down. Those are just examples, but still, retreating in my opinion has too many aspects to make it automated.

As a sidenote on the flat tech tree, I personally would prefer a more limiting branched out one, since it forces you to think more about which direction you take with your strategy and gives you different high level things to work to, instead of just one arbitrary barrier.

Cause all tanks are using the same micro mechanism, it is not more random than two players using the same way to out-micro the opponent.
And the randomicity isn't important once there is enough units, before that, the player can always out-micro the tactical AI easily.

It is just a balance problem, you can fix it with some value alteration.

Automatic withdraw the units with low hp is quite useful, and that's enough, it doesn't need to be a tool to replace human decision about retreat just because it has that name.

No if 2 players micro the better player should usually win. Not much randomness about it.

How about a player and his clone, not only body, but also mind?

If an algorithm dodges 3 shots the same way as it dodges 4, then I claim that it has an error. Small scale engagements are also an important part of the game, since being able to kill a small scouting group can be a huge deal and therefore randomness has to stay out of that as much as possible.

It isn't only a balance problem, it makes balancing a problem, because it amplifies the effect of speed and range buffs/nerfs. And the effect isn't even consistent, since it depends on the speed differences between the different units.

My point is, that it is too useful, since it can also accomplish feats on a higher tactical level than simple unit micro. And that's too much.

Total annihilation like rts games always have that kind of randomness, cause the projectiles aren't accurate, it is not very different with or without auto-micro, auto-micro is consistent and very predictable, the main random elements are the projectiles.
This randomness is same with human management too, if two players just keep their units moving in a battle, one of the players' units might dodge more projectiles simply out of luck.

Even in a accurate style rts games such like starcraft, there is still randomness, 12 zerglings vs 12 zerglings without human management, the outcome would be a bit random, depends on zerglings' positions and the terrains as well as the map features around them.

Then values the ranges and the speeds of the ranged units a bit more when balancing things.
The same property always have different effect for different units in a RTS game, a unit's usefulness is partly depends on the connections between its all properties, include the AI behavior. If you improve a rts game's pathfinding, that would have inconsistent effects on units too.

Nothing is too useful for a game unless it makes the game less interesting.
And I don't think auto-retreat would make the game less interesting.
Constantly select units with low hp and withdraw them in a battle is very repetitive and not very intellectual thus should be simplified.
And with the auto-retreat, the tactical and intellectual part is still accomplished by the player, he has to activate this behavior and appoint retreat zones, he won't do this if he haven't decided to withdraw the units with low hp.

Then just balance the unit with smartness in mind? Otherwise you set yourself up for a game which breaks when played by people with high apm.

Automatic micro is needed else it will just be another tactic game where ppl with extreme apm win automatically.

The problem with automatic retreat for low-HP units is that it's not always the best tactical decision. If you would like to sacrifice your low HP units to take fire away from other more important ones, or if the enemy force has dwindled enough that you wouldn't want to waste time, then retreat isn't the best decision.

You should automate micro only in the cases where the computer can make the correct decision faster and better than a human can most of the time.

Having a "retreat if you're dying" command could be a good tool to give the player so they can preserve dying units, but it's still unclear which direction they should retreat to. I suppose it could be a "move if you're dying" where the player specifies the destination.

Perhaps what we're looking for is a way to cluster units based on various properties. I already suggested we be able to select units based on type, perhaps you would like to sub-select units based on remaining hitpoints so you can tell them to retreat. Maybe that's too many shortcut keys to allocate and remember. It would really be handy for healing aircraft, though.