Confirmed features and suggestions

Hello Uber (or at least I hope you see this ),

I realize that you are not at the stage of balancing but I think its still important to think about that ahead especially if you are primarily focused on a multilayer game. I come to realize that the team you have working on PA is very similar to the one that worked with supreme commander 2. Being a descent player at supreme commander 2 I notice some imbalances. I know that with one faction some of these imbalances will be eliminated because everyone is going to have the same stuff but I will mention one as an example. Going air in Supreme Commander 1v1 is generally a good idea (at least if you are at the top level). If your opponent goes land there is just little that he can do to stop it (especially on a larger map). This is also true for many other games (air just seems OP). I hope that especially this imbalance will be fixed in PA.

Some other imbalances of SC2:
Aeon Teleport is a bit too strong
P-Shields vs non artillery force is a bit OP
Aeon Experimental are underpowered in 1v1 (and in other match ups too)

Thank you for reading,
yours, NiteOfMisfortune

P.S. Play some Supreme Commander 2 people before PA; we are still here!

Wrong, The guys at Uber that originated from GPG left during the Development of Demigod, and thus had no hand in SupCom2, many of the key personnel(such as Neutrino himself) did work on Total Annihilation and Supreme Commmander and Supreme Commander: Forged Alliance.

Mike

We have some of the engineers that worked on SupCom2 but none of the designers.

Am I correct to assume you mean Sorian and Eli?

Mike

Hello guys.

Sorry if this has been named before... But what about an Anti-Cheat system?

You left out that they confirmed 64bit Executable support for memory sizes upwards of 16+GB.

64-bit is also the recommended way to play the game.

Finally no allocation crashes on 16+Gb RAM.
By the way, you once mentioned that you expect community to run most of the servers. Hovever, you also stated that the servers is unlikely to have decent GPUs so you'll not concentrate on GPGPU support. If community are to host most of games, then probably most games will be hosted from more or less decent gaming PCs, ~94-98% of raw TFLOPS computing power of which are GPUs. If there's a contradiction here like I see it, doesn't it mean that GPGPU support priority should be reconsidered as a high priority target? I still don't expect that enough people will buy a dedicated Xeon-based servers to maintain a decent number of high-speed hosts in a lobby - those things are very expensive, power-hungry and noisy like an old vacuum cleaner.

I expect people to mostly run dedicated servers that are on all the time. These are typically on secondary boxes that lack decent GPUs. If you do happen to be running a server on your main box while you also run the game you want to have the GPU free to render the game for you (remember, multiple windows and all that stuff).

There are more reasons though. One of them is that there isn't a good mapping between the GPU and the simulation work that needs to be done. Just because GPU's have flops doesn't mean you can make effective use of them. Synchronization and latency issues of getting large amounts of data back from the GPU are also a headache. IMHO it would significantly increase engineering effort.

Another is that doing this in a cross platform way with the state of opencl drivers is basically impossible. It would destroy the reliability of the servers. Not to mention I want to run multiple server processes at the same time on boxes and the GPU doesn't work well as a shared resource.

In addition GPGPU can't be used as the "base" set of functionality because many of the servers in the cloud simply don't have a decent GPU. So the server would have to be written to scale well to CPU's anyway.

IMHO GPGPU is a gimmick, a mess and a hack that's sort of interesting in some cases but not when you are trying to write a reliable cross platform server.

not sure if someone said this but i think PA should have 4 races: the humans, the aliens (i am thinking for aliens like "self replicating" robots and by self replicating i mean like constructing themselves fast, not strong) and the 3rd race would be rock people , the last one would be energy beings. these are suggestions so please dont shoot down my idea completely. i do believe that they arent the best ideas so

I assumed that simulation mostly built upon math equations (ballistics, fluid simulation for pathfinding, etc.), and that's where GPUs ate traditionally strong. Looks like my assumption missed the point. Anyway, I have enough time to think about sound isolation of a server rack ahat allows for good heat dissipation. Thanks for explaination.

It is confirmed that PA will have only one race, closely resembling second from your suggestion, but instead of being aliens those robots are creations of mankind who has been long since extinct. Decision to have just a single race is mostly budget-realted, it is so to reduce production time and costs.

How difficult would it be to enable the player to save a control group to a factory menu? IE: I select six infantry bots, two artillery bots and an AA bot, save the control group, and export it to the land factory's build menu. Then, when I go back to order more, I can queue all the units at once with a single click. Or assign it a hotkey.

This seems like it would be a handy way to minimize micromanagement when you're standing up a new base on an asteroid or another planet, especially if you find yourself ordering units in predictable ratios. And it scales nicely: by the endgame you could find yourself saving entire army groups and regiment-sized formations to be replicated on distant planets.

That's how you play lame RTSs from the 90s.

In TA/SupCom/FA, you just set your factory to continuously build whatever mix of units you want.

Mike

but.. isnt that quite expensive for players?

i hope someone will make a highres-texture pack. it would be really cool if there are photorealistic planets etc. with star trek class effects!

Might need reconstructive facial surgery from the magnitude of my *Facepalm*

It will require a lot more than just high-resolution textures, and some of requirements are engine-dependent, like support for modern shader model, bloom/HDR/GI, bump/displacement mapping, volumetric particle system, tesselation and so on. As the graphics is not primary focus, that's highly doubtful that all such requirements will be ever met.

I have a htpc here on 50 mbit full duplex fiber.
Currently it has a sandy celeron, but I can insert an ivy or sandy i5 with some extra ram and have a decent server for PA.

Not really, that is how all dedicated servers work usually.

I translated this topic to german for all the german members here.
viewtopic.php?f=62&t=41922