Ideas from Zero-K

2560x1600 is gonna be pretty widespread by mid/late 2013.

I will be at that res, for sure. (currently at 1920x1080 or 1650x1080 or 1440x900 or 1280x1024 or 1280x800 or 1024x768 depending on my device, not counting smartphones or the iPad 3 :lol: ).

I'm running 7680x1440 right now. Any modern game that fails to run at high res in standard aspect ratios is doing it wrong. Well implemented games detect unusual aspect ratios and optimise the UI for them.

I have this problem with DOTA 2. I hope it gets patched.

As a keen Zero-K'er I hope the PA devs look at this post googlefrog and get in contact with you

The UI in ZK is awesome!

Has there like ever been a commercial RTS which had anything as sweet in controls as those?
If not then I hope PA to be the first.

I added a page about "retreat zones" to the wiki.

It has a video demonstration:

@googlefrog Sorry if i had misunderstand your post but its imo little bit misleading. Or you at least could add some more info about your presentation of features on this game/mod. I thing almost all are original implemented widgets in standard TA:SPRING engine. does not matter which mod. And i had feel you are describing them as zero-k only(topic name?).

Anyway i am very glad some1 bring up those epic mechanics.(yep ta:s player )

That's right, but some of those widgets(auto-kiting, auto-swarm and maybe auto-retreat)were specially developed for complete annihilation, the predecessor of zero-k, and the most of widgets are not default for other spring games.

When describing the features of a game it is stupid to go in to where they are implemented. Most people both don't care and don't have the background knowledge for it to be meaningful.

I could go through and point to the features which are implemented by the engine, those implemented by widgets and those implemented by gadgets. I could even do a full attribution even though all the code is GPL or opener. That would detract from this thread.

You can make your own thread of 'spring features' if you want but I bet a lot of people will be confused if you try to explain the technical details. But you seem confused yourself because

is not actually a thing. Spring is not a game, it does not come with widgets. You can't play an engine.

I'd rather not respond because this is really off topic but qwerty3w already responded so I hope this clears things up.

Yeas thanks and hopefully most of them will get in game.

For what it's worth, I'll just voice my agreement for a few items, as I've finally played enough ZK to judge it:

Area commands are good, and I think Mavor already suggested they were looking into this.

Custom formations are an interesting concept, but I think they could be implemented better. The current implementation only calls for one row/line of units. What if you want a box, with artillery in the back, tanks front, etc. Formations as implemented in FA make it quicker and easier to do this than a custom formation command. It's a good idea, but there's room for improvement.

With regards to construction priority, I was never really a fan at running any resources to zero. I always considered it important to balance your economy so that your income was balanced with your spending, and you had a bit of a buffer for emergency situations, both for energy AND metal. Running either to zero penalized you in that you lost control of the efficiency of your economy. Maybe this is noob thinking, but I always found that balance to be more of an art than just draining things to zero.

I've already expressed my support for A-Move++ here:
viewtopic.php?f=61&t=37369
In an game like PA, it seems like that level of unit intelligence is a must if you want to be able to get things done on a grand strategic scale.

Uniform constructor drain/unit costs is something I am NOT a fan of. I'm sure I posted an argument somewhere, but it just decreases the situation for when you would build certain units. For example, in TA, on metal poor maps, it was generally advantageous to start out with air, due to their reduced metal to energy cost ratio. It also helps dictate what units you may want to build later. If your economy is running fine, the choice is yours. But if you've been hit by an attack that took out your main energy field, you'll want to grab units that are low in energy cost. The converse is true for metal.
I think what we need to do is retreat back and define the overall problem that a non-uniform system might have. I think that the overall problem is that it's hard to visualize the expected drain for a unit depending on their cost. With a uniform system, it's very definitive what unit costs more. But with a heterogeneous system, it takes a moment of looking at big numbers to figure out which is bigger. So solve this problem. Maybe adjust the display of the unit cost to show scaled meters that give you a visual representation of the metal, energy, and time costs. The implementation of this is something that will need to be considered, but overall the problem is NOT that it's hard to think about these unit costs, but that it's hard to visualize them.

Armor classes . . . not sure what this is all about, but if it's done like TA, I'm fine with it.

Flat tech tree I do not agree on. I already expressed my thoughts on the advantages of the 2 tier tech tree here:
viewtopic.php?f=61&t=34187&start=40

The economy breakdown is good, and to some degree it was done very well in FA. (The economy overlay was especially handy.) In this case, I think FA's method, with some minor additions, is the way to go.

Drawing on terrain is good, although I'd suggest it be implemented as a Strategic Whiteboard layer that can easily be hidden in one click.

A movement independent attack command is handy, but I feel it's superfluous. I really think this could be streamlined into other commands, rather than making it an extra command. (Keep that in mind, googlefrog. I feel it would help ZK's interface if you did a bit of streamlining with stuff like this . . .)

Factory queue insert has been suggested elsewhere, and Mavor's looking into it, so I think this will come through nicely. Same goes for command insert.

Build ETA was implemented in FA and was MUCH easier to see. (In fact, ZK could use some visibility tweaking in that area.) Also, FA had unit movement ETAs as well, so I'm pretty sure these items will be in PA.

Configurable initial states is good. Implemented somewhat in TA and FA, but there's always room for improvement.

Multiple building placement is good. Several mods implemented it in TA, FA implemented a good portion of it. FA actually surpassed some elements with build templates, so that's definitely something to keep.

The drawn radar was implemented very well in FA, with excellent visibility. I feel that ZK's radar draw is very difficult to see in comparison. I suspect the additive blend mode used in drawing is no help. (The same goes for fog of war.) That's something to tweak in ZK.

Retreat zones are good, especially on PA's scale. The video does all the explanation there. I'll need to search through the posts to find thepear's concerns though. I'm interested in why he's against the idea.

Weapon spread and AOE display seems like a must.

Persistent scouting was done in FA, so I'm sure PA will have it.

Defense range visualizations were also done to some degree in FA, especially with UI mods. I don't see why this would be a source of contention. If it's only displayed for scouted buildings, it makes perfect sense. After all, the US military has a good idea of the ranges of Russian SAMs, and they don't use the same technology. In PA the technology is homogenized, so it makes sense. Besides, on PA's scale, you don't want to have to focus on babysitting your units and pulling them out of range if you send them in too close to defenses. This way if you've scouted, you know where you can send your units, and can concentrate elsewhere without needing to follow them and make sure you didn't click a little too close to that Penetrator.

Again, FA had a degree of smart radar shooting, and it was implemented well.

:shock: @ the content in this thread.

Having a truly advanced GUI would be a dream come true.

googlefrog, I hope the devs get in contact with you.

This is the most important thread in this forum.

Yep this can make or break the game.

I must disagree.

Fantastic ideas. I for one often found myself frustrated by a lack of 'area load' function for transports. For large assault drops, I either had to invidually load each transport with my units (difficult when you had 22 transports and over a hundred units) or use the ferry function to load up all the troops, and then cancel the function before the transports could reach that destination so that I could group them up, and control them properly for my attack.

a problem I would sometimes have with unloading with large groups of transports, is that they would bumble around trying to find space that wasn't occupied by another transport offloading its troops.

Total Annihilation spring had a repeat function and a load, and unload, area commands. The un/load area commands solved my transport problem, and if I wished to ferry, I would use load area and unload area and set it to repeat: it seemed like a very clever design solution.

I actually find the build time eta in 0K is easier to see, since you don't need to hold shift to know it, and 1m23s is easier to understand than 1.23 for newbies, the only problem is that it can't be enlarged with zooming.

How is the Achron scene these days, Google?

I was against the various micro automation/supplementation widgets from the outset, but for those that fear such advanced unit AI might lessen the experience, it is really a matter of design and perspective. Without exposing information inaccessible to the user, it is quite difficult to make advanced unit AI generally superior to manual micromanagement, and if such is universally distributed, there is no player to player access gap.

On a side note, it is Spring, not TA: Spring. With time, all things change.

This seems like a game pitch then a suggestion for ideas.

I thought a pitch was an explanation of an idea which is not yet implemented.

What do you mean by "player to player access gap"?

Achron seems to have stagnated. I am not that active any more because the UI has been too bad for too long.