Demo rewind feature - is that possible?

(digibob) #21

[QUOTE=SockDog;212488]I was just throwing out GTA IV as I expect they saw an opportunity there to build something around the game/engine.

Engine limitations aside surely there is scope to include in game features that others have had to mod or use third party apps to do. I shudder to suggest it but even something like the ability to upload a demo to youtube via the game is something consoles commonly do and would increase Brink’s exposure.
[/QUOTE]

I wouldn’t call it an ‘engine limitation’. It is merely a side-effect of the way a specific feature is implemented, in this case, the demo system. As I have mentioned before in another thread, the way features are implemented have pros and cons, and the pros are usually heavily weighted towards the core part of the game/feature set.

The major pro for us, for the demo system is that it is tied into network recording, so requires very little maintenance to keep it working, as it mainly works the same way as a regular network game, just being fed from disk instead of the network.

In ET:QW the network system really did not like jumping around in time, especially backwards, thus rewinding tended to be rather unstable. The network stream is also delta compressed, so relies on the previous frame’s data to generate the next frame, this makes going backwards impossible, as an individual frame’s data doesn’t contain the information to generate that frame. I’m not going to comment on Brink’s system right now though :slight_smile:

Time is always a huge factor for us, and re-writing entire systems to support what is (in this case anyway), a relatively minor feature is generally not going to happen.

(3Suns) #22

I love it when you talk tech.

(SockDog) #23

Cheers for taking the time to explain. I know we’ve bounced around the killcam stuff before so I guess this is a similar engine thing.

Low priority aside though couldn’t there be some features added which enable better control without having to rewrite the whole system?

How fast could the game read the network data forwards? So if someone clicked back 30secs the game, in the background just played forward fast until 30secs before the click?

Sorry if I’m being dumb there.

(digibob) #24

It’s certainly possible, though the ET:QW network system has the horrible requirement of needing the entities which the state describes around to actually parse the network stream itself, which complicates matters. That isn’t a blocker as such, just makes the whole process slower than it could be.

Aside from the that, the main problem is that it doesn’t scale at all, which is a far bigger problem in my eyes. The further you get away from the start of the demo, the longer it will take to FF to that point. This is partially solved by the keyframe generation, as this stores full state at frequent intervals, so you can jump to the nearest one.

Again, I’m not going to discuss how things work in Brink, but we are aware of these issues :wink:

(And killcam is a whole different issue)

(SockDog) #25

[quote=digibob;212586]Aside from the that, the main problem is that it doesn’t scale at all, which is a far bigger problem in my eyes. The further you get away from the start of the demo, the longer it will take to FF to that point. This is partially solved by the keyframe generation, as this stores full state at frequent intervals, so you can jump to the nearest one.

Again, I’m not going to discuss how things work in Brink, but we are aware of these issues ;)[/quote]

Again cheers. I’ll await with tempered enthusasm to see whats cooking. :slight_smile:

BTW - Is there any chance SD will release some more technical blogs as Brink nears completion. Marketing focus is always on the actual game but I enjoy someone explaining in idiot how the game actually works.

(And killcam is a whole different issue)

Yes, lets not start that one again. :slight_smile:

(Ashog) #26

[quote=digibob;212507]I wouldn’t call it an ‘engine limitation’. It is merely a side-effect of the way a specific feature is implemented, in this case, the demo system. As I have mentioned before in another thread, the way features are implemented have pros and cons, and the pros are usually heavily weighted towards the core part of the game/feature set.

The major pro for us, for the demo system is that it is tied into network recording, so requires very little maintenance to keep it working, as it mainly works the same way as a regular network game, just being fed from disk instead of the network.

In ET:QW the network system really did not like jumping around in time, especially backwards, thus rewinding tended to be rather unstable. The network stream is also delta compressed, so relies on the previous frame’s data to generate the next frame, this makes going backwards impossible, as an individual frame’s data doesn’t contain the information to generate that frame. I’m not going to comment on Brink’s system right now though :slight_smile:

Time is always a huge factor for us, and re-writing entire systems to support what is (in this case anyway), a relatively minor feature is generally not going to happen.[/quote]

Thanks for taking care to explain!

Unfortunately, this still doesn’t explain why playjumpstartdemo works without a problem. How does it work and why not using it for skipping back the demo replay in a similar way?

(Ashog) #27

I think it is wrong to talk like that. If people continue saying this, there is NO way that SD will even bother to implement things like that. Don’t begin to justify SD for not trying to make Brink even better by “saving them time” at expense of worser demo support. Not the correct way imho.

SD GOT time - the game was anyway delayed, and they certainly got moneys now, with ETQW and Bethesda in place - IMHO more money than before ETQW. So please :wink: This is in the end their job to make Brink better, come on :slight_smile:

(Nail) #28

re-writing entire systems to support what is (in this case anyway), a relatively minor feature is generally not going to happen.

miss that part ?

(brbrbr) #29

cuz it have tremedous impact on performace.
so i agree, its valid decision in that tradeoff.
until six-cored CPU’s is common[year ahead, i guess].

(Voxie) #30

Giving the blogosphere something tech-related would be nice… Hint, hint.

(brbrbr) #31

i guess, sooner or later(about 4-6 years, appx)games and blogs/micro-blogs converge together.
as well with some other things. such as video services, broadcasting[including commercial. and including commercial broadcasting by players ingame], Second Life-alternatives gateways, offline services[including emergency ones], digital marketplaces.
so sooner or later its become not matter, to which part of online you appeal, both functions become available anywhere.

(stealth6) #32

[QUOTE=brbrbr;212822]i guess, sooner or later(about 4-6 years, appx)games and blogs/micro-blogs converge together.
as well with some other things. such as video services, broadcasting[including commercial. and including commercial broadcasting by players ingame], Second Life-alternatives gateways, offline services[including emergency ones], digital marketplaces.
so sooner or later its become not matter, to which part of online you appeal, both functions become available anywhere.[/QUOTE]

doubt it, also we don’t have 4-6 years we want tech info NOW :stroggbanana:

(brbrbr) #33

you don’t get MANY tech stuff, technically available for production, for about 12-15 years, just because curve of Return of Investment not so tight on some market, you know.
and hunger for money damage market much more than infantile management[as opposed].
because segments become victims of success and so on and so on.
so in short, Strategy is about Planing[carefully and far-far-far], Balance and plenty of common sense/experience/perception.
thats why you don’t have “right now” so many things, as you can[in theory].

p.s.
aside other reasons