Observer support, spectator UI

Are there plans to make observer support and a spectator specific UI for PA?

By spectator specific UI, I'm referring to a modified player UI that shows all players' resources, tech, units, buildings (possibly with options to only show those of types the spectator finds interesting atm) and so forth. StarCraft 2 had a pretty good implementation of this, particularly for showing resources, though it would have been nice in that game to make the different spectator information displays into movable dockable windows.

I hope so. This feature should be pretty basic honestly.

Yes. It's really needed for this kind of game.

That's really great. I was disappointed by the replay system in Supreme Commander 2, you couldn't see what techs the players had researched etc which made it quite difficult.
Honestly I don't think a proper replay system is hard to design, and that kind of polish just makes it so much better.

I was suprised to see this bought up.

Coming from Battlefield 3 as my most recent game, spectator options were a pie in the sky.

Which is annoying, because I'm a commentator for game events and stuff!

Replays can really help boost hte life of the game and help newbies and others analyze game play. For Starcraft 2 for example, it's slet us shoutcast matches at anytime if we can't be there live - it's just that good of a ui that we have no problem with it. The hardest feature to do is a Rewind and I understand the difficulty of network traffic, but worth bringing up.

The other is having a nice interfaace

Sorry for the rambling there!

Super MNC had already a pretty good working replay system, I was actualy impressed at how bug free it is, the SC1 replay system was really buggy at first when I used to play at SC :lol:

Yeah, replaysystems are apparently a really tricky thing to get right, as it seems common for games to have consistency issues with them.

And yes, having the spectator UI in the replays is also something desired, or as an option. With the RTS I currently play now, Achron, I set up the replay UI so that you can click a button to change between spectator stats and current selected player stats (for resources, tech, etc.). Note that I had to set up the observer support and associated UI in that game, since the mod support there has been miles better than the base game UI.

Thread a few days old, but I really need to ask. Will spectators be able to chat with one another while watching? I know chatting with the players could lead to easy cheating, but I don't see anything wrong with it between the spectators. Would also keep it from feeling like you are always watching a replay, even when watching it live (or a few minutes before it happens, to keep people from cheating). That's the kind of feeling I get in a lot of modern games with spectating, like League of Legends. Too lonely. Plus it might make for an interesting way to teach new players.

If spectators can only talk to all players and spectators at once (not any player specifically) or just to spectators/individual spectators it should work. Any potential cheating would be seen as spectators would have to publicly address players.

I was assuming it would be non live - as in a saved recording file can be played back. That would be the most efficient and least draining on developer resources, but still allow for communities to spring up. It would also be helpful for development for modders.

The fact of the client/server arch brings up that live is possible though, which is a cool idea.... Maybe a stretch goal to allow for unused slots to be a spectator maybe.

It's nearly identical, actually. The easiest way is just to have player slots that are "observers", allied to everyone, and unable to affect anything, and receiving statistical information for all players. The trickiest part is designing the stats UI.

Replays are actually harder, or at least consistent replays seem to be a pervasive problem for many games.

Replay compatibility over versions is actually a pretty tricky technical problem to solve.

In a synchronous RTS a replay is simply a list of all the inputs into the game from all the players. Then a replay is basically the same thing as running a network game, you feed in the inputs and the sim is identical.

Now change how many hitpoints a unit has. That unit is going to get killed earlier and you have the butterfly effect and the simulation explodes. The same thing would effectively happy to the server part of a client/server game. If you change something fundamental to the game it's generally not going to play back correctly just using the inputs. The only known way to solve this problem is to archive old versions of the game and use the appropriate version for playback. Messy at best although doable.

The next level is to just record everything that happens in the game and not try to resimulate. This is fairly trick itself. Luckily it's almost exactly the same as the problem you have to solve for client/server networking. Basically if you just record what would get sent to a client you should be able to replay a game from that perspective. Clients don't necessarily get all gamestate though so you just have the server create a virtual client that sees everything and record this to a file. That file becomes your replay file that can be fed into a client who can then see any part of the battle. You could also livestream this virtual client to recreate a broadcast/replay server instance.

Again though, you don't have something perfect. Any large change to the game could still potentially cause odd looking bugs. At some level if you are letting the game change at all some stuff is just going to not look correct. At least with this kind of replay having things broken doesn't effect the parts that are working correctly. There is no butterfly effect that causes an explosion but it's more like playing back a movie.

Of course you need to architect these streams such that they are versioned and have fault tolerance across versions. For example using something like google protocol buffers.

Hi Neutrino,

Blizzard "solved" this problem in Starcraft II by keeping older versions of the game executable. When you launch a replay the game and older version of the executable is launched if needed.

Activision Blizzard has (literally!) a billion dollars to spend on making stuff perfect every year. They can make a simple hack & slay and take 12 years to polish it if they feel like it. They are the perfect opposite to an indie studio.

I think the benefit of keeping replay compatibility is overrated; though there are many ways, such as distributed version control systems, that could quickly be used identify and then to patch / rollback a game to a certain changeset. If you don't lump everything into huge .WAD (or .SCD) files, you'd probably be able to very comfortably switch between versions using an established DVCS, such as mercurial or git.

If I made an indie RTS with replay functionality, I'd actually put all my release builds in a DVCS (mercurial is nice because it works well and is space efficient without being too arcane) and have people's clients update and patch using that. It'd also totally rock for modders, who'd have a chance to merge their local changesets with new incoming changesets/branches, saving them a lot of work updating their mods. You could also clean up broken installs easily with the DVCS's inbuilt clean / clone functions, offering dummy users an easy way to fix their crap they broke by installing bad mods etc.

Just because Blizzard is damn rich doesnt mean that the concepts they use are forbidden for indies. Keeping replay compatibility is really very important feature. I like my replay-archive with thousands of replays and I want to be able to play them, even after the next patch.
Actually I cant see why it should be so hard to implement it, too.
Just keep older versions of changed game-files around and start the old version. In Supreme Commander this is addable by 3rd-person software and a bit of modding.
If PA is equally modable, it should easily be able to use the same approach.
Like this tool: http://forums.gaspowered.com/viewtopic.php?f=50&t=24738

But keeping an units.scd, textures.scd and env.scd for every version I might possibly encounter in a replay is several dozen gigabytes of overhead!

I don't want that on my SDD.

So you need to rollback to an old version every time, and that's probably most feasible using a DVCS, because that's one of the use cases these things were made for. It requires the game to be broken up into smaller files though, big monolithic binary files don't work too well.

That said, the DVCS thing could be community-run, obviously.

You don't have to keep all the texture file etc., it doesn't take so much space

You do if a patch contains a new unit or a fixed texture.
You could keep diffs and whatnot for every changeset, but that's essentially what a DVCS does.

Just support spectators, forget replay. This would help with professional game play, making machima films, and just seeing what your friends were up to. I can imagine the scene now.

"Man, I haven't heard from Brian in ages. Oh - facebook says he's in the crab nebula. Let me check it. .....whooooaaaahhhh" Brian's friend has his mind obliterated by the epic battle. Now he'll be skipping school for three days just like his friend. Maybe he'll call all of his friends and tell them to sign on and watch the epicness unfold. Or maybe just buy the full version of PA.

This would be awesome for a limited free release version. The feature is just a read-only client that can join an ongoing session. It'd be even easier if multicast were used. That'd support a large number of read-only clients. A lot of people could sign up as spectators and watch as the action unfolds. They would be able to see the game in action and decide if they wanted to buy it for themselves.

That's a pretty fascinating insight. I always assumed that the UI would be the main difficulty in programming a replay system that integrates with the game. Any ideas which of the above PA will implement? Is it too much overhead to implement a system that records every event regardless of the version, sort of a verbose list of events (using the engine for animations/models only), or is the advantage of using on-the-fly engine calculations too valuable?

It appears that the Asynchronous model causes more problems for you guys. However, I wonder whether the server/client model, in a sort of "cloud" capacity, provides a greater ability for a replay system with a greater ability to cope with all the above mentioned problems. I'm not sure whether you'd want it Internet connection dependant, but even having that ability for post processing may make a more exhaustive approach more viable. Though you have to develop it first I guess!