The Tech of Planetary Annihilation - ChronoCam

Hey guys,

I did a huge write-up on some of the tech for PA. I've hinted at it in the past on the forums and now it's live. If you're into learning some dirty details I think you'll enjoy it.

http://forrestthewoods.com/the-tech-of-planetary-annihilation-chronocam/

This kind of thing tends to generate a lot of questions. My plan is to round up questions and answer them all at once in a follow up post. So ask away in this thread and I'll do my best to respond.

There's also a reddit thread if you're into that. http://www.reddit.com/r/programming/comments/1o35i3/the_tech_of_planetary_annihilation_chronocam/

Read this on the bus to work this morning. Fantastic reading. <3

Turns out this curve business is a massively suped-up version of something I made for my honours project. Never thought to keep a history of old events - I just discarded them when I was done with them. That would have been a really cool feature to help demonstrate what I was working on.

Nice. Even though most of it is over my head.

Question: Do you have a curve for acceleration? I figure that one is kinda' important.

That was a great read. It's awesome to see some innovation in the RTS simulation. Can I just confirm a TL;DR on the actual client-server interaction?

Traditional RTS: Players send inputs -> Server sends those inputs to other players -> Each players client updates the simulation on their own machine -> Screen is rendered from simulation.

This RTS: Players send inputs -> Server updates simulation, stores points where simulation curves start, finish or change -> Players request parameters (unit position/velocity/actions) at any particular time instance -> server interpolates values from stored curve points and sends parameters to client -> Screen is rendered from received parameters.

Is that correct?

The article states velocity curve is stored. You can integrate that to get the acceleration if required.

EDIT: Position is stored. Integrate to get velocity. And again for acceleration.

Regardless all the client requires to render the screen is the position/orientation of units. The server will probably use velocity/acceleration of units to calculate the position of unit, but it doesn't need to be stored.

EDIT 2: I meant differentiation. Derp.

NapoelonSolo,

Very close! The server sends curve data to the client and then the client performs the interpolation. This is how clients can efficiently run ChronoCam in slow motion. The client has all the curves, it just updates the time instance slowly and gets the interpolated values with no extra data coming from the server.

v.1337

Pretty nice read, even though not as much new and unexpected stuff as I hoped for. Neutrino's teasers over the last few month build a picture in my mind that you confirmed. I am kind of sad you have no awesome general solution to offer for the animation problem thing, as it was one of the things I had no idea how it could be done myself.

I am mostly interested in the parts you have left out due to them being not finished: replays over different versions and replay compression on disc.

Q. 1)
What sort of compression could be done on disc?

Q. 2)
What will you do when textures/effects/unitsize(I guess the size of the 3d models is not part of the curves as some uber posts stated that they cant be changed that easily)/etc change between versions that are not represented in a curve? Do you keep old versions of them around or do you just ignore it and render the old replay with the new look? Especially if properties exist that alter game mechanics but are not part of the curves (because they are static all game) this could be a problem because it might look weird in the end. Unit model sizes might be a thing here. If you suddenly reduce the tank size by 70% units will suddenly keep a weird distance to each other in an old replace. In the other way around units will clip a lot into each other. The game outcome will be the same, but it won't look very nice.

So you are actually targeting only 1 mbit/s and not the 2mbit/s I read somewhere. Nice! 1 mbit/s really is pretty reasonable already for a 6 player game imho. It's pretty damn good actually for the client part. Servers however will need a pretty decent connection, as upload speed is kind of low on most connections. More than 8 player game wont be possible with any kind of normal connection that people have. 8mbit/s upload is already a lot and not available to that many people I guess. Dedicated cloud servers ofc wont have much problems here as 100 mbit/s+ is common. 100 players is already too much for any kind of CPU I assume.

On that regard a random question about the server: I assume it will be able to run headless? Some pretty beefy servers I know are headless.

@NapoleonSolo, I think you have it backwards.

You'd differentiate to get acceleration from velocity. If you had a single acceleration curve, I think you could just integrate client-side and get velocity and position - and throw across initial condition pulse curves for position and velocity. My experience with that tells me it often leads to sketchy results unless you tell everyone to do discrete integration with fixed step sizes (though I don't believe that's a problem here).

I think an acceleration curve would matter the most on projectiles (because they are always accelerating).

Saying most of it is over my head is an understatement.






In all seriousness though.
The anti-cheat just sounds wonderful.


I love, love, LOVE that you guys are releasing the server software and that you will have LAN support.
You have described this the client/server model to be highly intensive for PA, do you feel that bandwidth and server costs will be sustainable in the long term?


To me, the ChronoCam tech is a technical marvel, but I think it's a very core piece of tech you have that you can do much more with it.
Do you have any thoughts on being able to properly leverage the it into the ultimate eSports casting tool?


Production Manager:
One of my hopes for the PA will be a very robust "unit production manager" system.
SupCom is already a nightmare for a caster to track the action as well as the production of units/buildings.
The "unit production manager" would be similar to the Starcraft 2 system that is in the replay viewer, but something that is live and interactive. (click the GUI thread in my sig to see more info). Since it would be interactive, the viewer can click a factory or unit to see where it is being built. If you can link the ChronoCam tech to a tool that brings up when I unit was started production, then maybe you use it as a timestamp or bookmark to viewing a past event. "I started this artillery piece right after they crushed my left flank", then you can remember it and go back to review the enemy unit composition.


Future Events:
A player/caster could potentially "tag" something as a vital future interest for the ChronoCam to pop-up a window.
ie. The completion of a Superweapon or the ETA for an asteroid impact.
They can maybe add it to the notification system, and have the ChronoCam remember this predicted future event, and pop-up a new picture-in-picture window.


Dual Casting/Live Replays:
This game will have fighting on multiple fronts, much worse than SupCom.
For example, using the same client/server models, you can have multiple casters log view a replay together.
Have you though about how you could essentially replay the game, do picture-in-picture replays from the feeds of multiple computers and do live instant replays?
Have 1 caster manage the main feed of the front line battle, while the other caster scrubs through to do detailed slo-mo analysis of a skirmish that just happened.



In short.
Technical genius.
Powerful tools will allow for innovative use.

Cool! That makes sense. So throughout a game, the client will receive updates to the curves from server-side simulation every tick and have an entire games worth of curves in memory?

So, the anti cheat system can only send curve data for units your client can see. Should you want to scrub back the game, post annihilation, and see what your enemy did to win - can the server send past data to the client requesting it or would the player have to request the entire replay in a separate session?

I am loving all the information about the development of the systems. I find it absolutely fascinating. Thank you for sharing!

Woops, my bad. Confusing the words not the maths, I promise!

The server runs the simulation and has the acceleration data, start position and direction. It'd be able to calculate the position of the projectile up until the point it hits another unit. Integration on the client end, while trivial for a single unit, just means more to do before it can render the scene. The article kinda says that the client literally is just a dumb system that renders what it's told.

Yes.

Yes again. Exactly correct.

The server can "fill the gaps" of missing data if you've been annihilated and become an observer. Data could be missing because it was an enemy, on another planet, or because a bandwidth throttle was hit. Doesn't matter what is missing or why it's missing, the server knows and can fill it in.

It's dynamic. When you request data you tell it at what time you want the data from and it sends you what's needed. You actually tell it position in game world, time and playback rate.

How similar is Chronocam to the method SMNC used to playback it's games? I know very little but I do know they weren't video playbacks of the matches.

At the end of the game, we get a score screen.

While it's very standard to show
Buildings: built, killed.
Units: built, killed.
Resources: collected, wasted.


Does the the ChronoCam technology have the ability to track and summarize which specific units were lost similar to SC2?



This is a very power replay/Casting tool.
I have heard mention of "clicking on a unit and seeing how it died", and inversely, each of it's kills?
Is it a highly taxing on the server to track each and every single one of these unit instances and events?

For example.
Score screen shows a portrait of a "hero tank" that managed to score 17 kills before dying.
If the ChronoCam can timestamp each of those kills in the game-log.
Then the player could potentially just replay all of the tank's kills, and watch how it died.

Would make the Score Summary screen pretty outrageous.
Techwise, file storage and computing power, is this even possible?

Since for each unit that ever existed the server needs to have a curve it could probably gather all curves of all units that ever existed till a given point in time and list them. You could then determine how many of what type of units died. You could even create some sort of diagram of when units died or when they were created or where they moved or how their hitpoints changed.
Basically it means no extra workload on the server at all while the game runs, as long as the data-curve is already necessary for the general functionality of the game.

... I think

Great article, very clear and in-depth. That said, I have a very basic question that I imagine others will be interested in as well. If I recall correctly, in one of Uber's livestreams it was stated that this game (upon release of the complete game) will support LAN games. My question is, if I get a bunch of my buddies together for a LAN, say 6 or more of us, will we need to have our own dedicated server to run a game smoothly? I suppose I should also ask, will we be able to run our own servers, or will we always be required to play off a dedicated Uber server? Thanks in advance!

EDIT: and I answered my own question- sounds like you guys will be releasing a server for such applications, and no, it will not require one to connect specifically to an uber server.

PS: I like your curves

The server software will be released once PA is out of beta. So you can make your own game server on your own machine on your lan. No need for any internetconnection. That's btw in the article, if I recall correctly.

Sorry, I couldn't find it, but read this which made me worried:

"Servers will need to support 1 Mbit per connected player. For large games with many players this can add up quickly. This is why Uber is running dedicated servers so players never have to worry about it."

Aww, you got me, it's in the references!

"[18] The game is DRM free and server binaries will be released with retail so players can host their own servers. This includes LAN support where bandwidth is of little concern."

Good attention to detail!

DeadStretch, it's a much more fundamental part of the game engine than SMNC. I was never super familiar with all the details but I believe SMNC basically saves out what network packets are sent and then later you can connect to a "server" which re-sends sends those packets. I could be mistaken though so don't hold me to it.

Culvern, all the data for stats and analysis is there for the taking. It's just a matter of being able to query the dataset for the information you need and having a way to display it. There currently isn't anything like that being shown in the post-game stats screen, but I wouldn't be surprised if it shows up down the road.