PA's server really needs to be multicore.

do we know anything at all about the gameplay?
I can imagine A LOT of things based on the few things we know so far.

Well there are zones you must capture to get some resource (I think it was energy, idk) Base building is pretty limited afaik. Mostly large armies.

Check the website.

I did read the website, I didn't see any statements about base building. They mention that you need to control zones, but I can think of many implementations of that and having zones to control doesn't necessarily say anything about base building.

Eh I suppose, it just doesn't seem to be a base building kind of game, I'd be please try suprised if it were though. =)

They say you need to control power generators to get resources that are around on the planet and you need to capture them. That could describe mex points or it could describe flags you need to capture by putting units close.
The only hint about how units are constructed is this sentence I think:

Doesn't really say who constructs the armies.

In the tech demo there are some things that look like structures of a base though.

EDIT:
Also the FAQ says this:

So you need to build *some* structures. Doesn't say how many though, and I have no idea what they mean with logistics.

If you read through a bit more, it states that you get a 'seed' on the planet, and that all supply lines must route back to that. It elaborates explaining that for this to occur, you have to own adjacent sectors forming a chain back to the seed- and to capture a sector you capture the power generator within it.

Essentially it functions like solar systems in sins, where each links to the next. It means there will be some serious strategy in trying to capture sectors close to your opponents seed, thus cutting off entire chains of resources (but also harder to hold as assuredly it will be closer to the production centers).

From the game website, they only have 1v1, 2v2, and FFA multiplayer modes planned...

guys chill your butts.

what you see now in Ashe's of the Singularity is THIS:



in PA terms.

pre-alpha.

if you look closely not a single unit ever blws up or even looks damaged. they're just shooting at each other. no unit death effect exits yet. not many or no building model exists yet. there looks to be about 4 different units in this demo (big *** ship, generic tank 1 generic tank 2, bomber)

we don't know anything about gameplay, we don't know anything about the mechanics.

we don't know if there will be bases or even flow-based economy o if the terrain will be different, the units look different.

but the wise thing would be to assume that all of that will change, since it did for PA.

all we know is :

• big scale
• simulated projectile
• 64bit
• potentially MAC and linux support
• two races
• probably will be released in 2016

personally I'm now a bit less naive then I was back in the day for PA.

probably by the time it comes out it will suck and PA will have turned out amazing to me and then it itself will have to get through the process of getting better and turning from awful into a good game.

keep in mind alpha access will probably only start in 2016 so all of this is a long ways off.

Alpha starts this summer, wat? :l

well i stand corrected. ^=^

On the multicore sim.

Edit/Removed: Sorry for bumping, see the other thread on this topic.

That's a different thread =P

Yep, but it contains additional information about AOTS's threading I which had duplicated by mistake.

Just as an aside since I saw some people commenting on Mantle and how the original video was effectively funded by Mantle, it was. Oxide made several tech demos for Mantle, most notably the star swam one. They were used to showcase the efficiencies of the API over dx11. Long story short, M$ and OpenGL are nearly releasing their completed new APIs, DX12 and Vulkan respectively. AMD has more or less discontinued Mantle as they were working directly with M$ and Khronos (guys who make OpenGL) to implement a similar approach in the next gen APIs.
I'm exited for them as they are generally improving performance from 30%-60% in some instances solely in software and it allows for much better utilization of CPU resources overall. However, the PA team would have to incorporate all of that into the engine along with proper threading to give anything close to those performance gains. It's unlikely at best but incredible if it gets done. Realistically, most every game out there is only ever going to really use two cores. That's excluding some of the very new ones, eg. far cry 4. Even then it struggles to use three despite their poor optimization that preventing it from working with dual core machines.
The only engine I'm aware of that uses multiple cores properly is cryengine3 and most notably in star citizen where it can use a ton of ram and cpu, pending optimizations of course since it's still in alpha.

I would have put the links here but the forum won't let me post them for reference so just do a search at anandtech for the following if you're interested.
Next Generation OpenGL Becomes Vulkan: Additional Details Released
and
AMD Lays Out Future of Mantle: Changing Direction In Face of DX12 and glNext

I hadn't realized that mantle was basically dead. What's cool though is that it effectively forced DX12 and OpenGL to improve. It's a real shame that AMD isn't going to get to capitalize on the improvements like the other two will.

Basically the Khronos group rolled most of what Mantle did directly into Vulcan, so there's little point them pushing it further.

As for multi-threading, the hype isn't quite as good as it sounds.

Current API's *do allow multi threading* and in fact PA *is already multi threaded for rendering*. The current limitation is you can only have *one dispatch thread* that feeds the draw calls to the GPU. However that doesn't prevent you using a load of threads to build all the draw calls stuff, whilst the 'primary' thread dispatches it all. That's what PA does and it can use 3 - 4 threads quite well.

The main limitation for PA is actually the simulation- which only uses a single thread, and the graphics API will make no difference to that as it's totally propitiatory and made by Uber. Ideally down the line they will multi thread the simulation, as that will greatly increase the number of units you can simulate without slowing it down (currently circa 5000 units is probably your limit for full speed play). The reason Uber haven't done so yet is that there are inherent issues with this as many parts of the simulation rely on many others- however it isn't *impossible* so I'm hopefully they may look at it down the line.

By multi threading the sim, do you mean the original mentionned multi threading model (1 thread per planet) or are you really expecting the sim to be multi-threaded on a single planet ? The second option is unlikely to occure soon unless they have started to work on this months ago. I know multi threading the sim is not impossible, but it's a tough task.

AMD will definitely capitalize on the new APIs as it means that their APUs will be much better equipped to handle new games and applications. AMD has been struggling since the Athlon 64 days to keep pace with Intel in raw CPU performance and as everyone knows clock for clock the Intels are always stronger in performance. That's why AMD bought ATI. With that they don't have to have the fastest CPU when they could build in a GPU. AMD's big push for HSA, directcompute, and Mantle were all geared towards the same goal which is to reduce the load of the CPU and improve overall performance by leveraging the GPU. A lot of normal everyday applications can utilize the GPU and it generally makes the machine "feel" more responsive. Professional applications, eg. 3dsmax, maya, vegas, photoshop, have been using the GPU for years but now even everyday things like office 2013, openoffice, firefox/chrome/IE, can all take advantage of the GPU. For the end user that means they can but a $150-$200 APU that will run everything they need and do some light gaming or at lower settings than they could with an Intel chip for a similar cost. From a performance standpoint, AMD's GPUs have been at the top for a couple of years now, not in gaming performance necessarily (looking at you Titan X even though the 295 is roughly equivalent for half the price) but in compute performance. Remember when all of the AMD GPU cards were either impossible to find a year ago or ungodly expensive? That's because all the cryptocurrency miners were using banks of them instead of the nvidias which for all intents and purposes outside of CUDA are not nearly as good at gpgpu.

The biggest thing on AMD's side is HSA and their graphics architectures which are significantly better than the embedded Intel GPUs and generally cheaper than the Nvidia competitor while offering general purpose benefits. In short, if the new APIs reduce load on the CPUs, AMD is back in the game for their chips for the general consumer. That's of course pending the new architecture they're working on with the new engineers that finally came back, the same ones that designed the athlon XP and athlon 64 that finally beat Intel chips years ago.

The sim thread is a seperate process in the engine of the game. So to draw everything on the screen there are multiple threads for that as it can be broken down into different stages to distribute the load. The sim thread runs into a similar problem as most RTS games, there's only one and it's responsible for keeping track of everything clicked, built, destroyed, moved, or otherwise. Trying to break that down into multiple stages or sections is difficult because you can't just have one thread be responsible for everything the player clicks, every projectile, every unit's pathing, they're all connected in the same thread. Seperating it out would require tremendous work and very clever thinking to split the duties of the sim thread into multiple. Once you do, they now have to communicate and keep things in sync while updating the rendering threads to tell the GPU what to show you. Spliting the threads into different planets may not work because if you have 1000 units on one planet and nothing on the others, the sim thread is still single threaded for where it counts.
I'm not 100% on how PA handles it's sim thread but I remember how supcom was and I believe it's pretty similar. I'll never forget those days of have 4 players with a 500-1000 unit cap and having the sim run at -2 speed while everything still looked great and ran at 60fps. People tried all kinds of snake oil from the dual core optimizer to making the .exe 3GB aware. If it isn't built into the engine, it can't really happen.

The sim and the rendering are quite far apart. The sim is inside the server. It does not know the game is rendered at all, that is done in the client. So changing the sim to be multithreaded won't need changes in the rendering at least.
In that regard PA is quite different from SupCom: SupCom uses p2p where all clients simulate the state of the game, PA has a server that simulates the game and sends the game state to the clients in a form that allows for the chronocam.

In that sense PA is as prepared as it gets conceptually, server client definitely has advantages when you want to multithread the sim. You don't even have to be perfectly deterministic, as the server is the only program that decides what happens and replays via the chronocam do not need the simulation again.