I can't even stop laughing. Now, OCS and NBC are being touted as "tier 0" (aka tech demo) implementation. On the client side. And the server side - the most critical - is in the "future".
Watch @ 10:15
ps: I love it when I'm right (
02/20/18,
12/11/2017,
10/18/2017,
05/24/2017)
Key points in video:
t=281 what OCS is
t=467 whats the difference between other game implementations and SC implementation
t=550 adapting the wheel to scale unheard off, continues to lando talking about bind culling like its thing that is coming far away future
t=869 what is bind culling
t=1166 what is serializable variable
t=1413 full client streaming, All of OCS wont be done for 3.3
t=1535 "its very much kind of traditional level streaming that you see in many games" talks about making things async
t=1685 what is the time sink. Talks about async
t=2047 talking about how new additions might kill the performance gains of OCS
t=2157 all the components had to be made thread safe.
t=2253 removing Lua
t=2456 they cant predict performance gains.
t=2574 server load is going to be heavier
t=2879 what has been biggest challenge with OCS, Lando starts talking about how bad their scheduling is.
t=3111 its going to improve Ram,Cpu. Clive talks about being more careful than chris about promising things.
t=3421 its been 3 years since they started working on OCS.
Because it's always good to get other informed perspectives, this post by another dev was posted on Discord, FDev and on SA. It pertains to the video above, as well as my
recent article about this latest revelation.
Right off the bat - 2015 is when OCS was originally started development. This will be important later.
9:00 - "we're not reinventing the wheel, we're adapting the wheel to a scale previously unheard of"
So after miss characterizing most multiplayer games as not requiring streaming we hear this gem. But in modern engines, it's pretty much mandatory simply because there is so much detail now that is constantly loaded and unloaded - his statement was true for Goldeneye 64, not so much for the latest FPS. We can argue semantics all day as to what exactly counts as an "object" and "streaming" so let's address the crux of the matter, characterizing what SC is doing as "previously unheard of". I suppose they've never heard of a little game called Elite: Dangerous. Or No Man's Sky. Or the original Elite, even. That's the beauty of streaming systems - something like Skyrim doesn't actually care how big the entire playable area of the game is, because it only cares about the chunks that are currently loaded. It's only relevant in the context of coordinates - if that was properly designed (which we've established is not), then the streaming system simply would not care what the maximal bounds of the total playable game area are, in any way.
10:00 - And they're not even working on it yet? WHAT? And the mention of "server-side object container streaming". As discussed, this is stupid: It doesn't make sense in the context of their description because it was all "we're streaming content FROM our SERVERS to YOUR PC", which makes sense. Then they just casually drop "oh ya and we're doing it on the servers too lol", so where the is that data coming from? Other servers? If so, what's their intra-server architecture look like? Are they just streaming it from disk? Where will the data be processed, is this the magical server meshing that will enable 100k players??
11:00 - We can't make any promises about performance because there's so many variations of CPUs and motherboards
Massive cop out. Technically correct, but imagine how unsure of yourself that you'd have to be to be pre-emptively blaming players' motherboards for performance variations rather than stating "yeah, performance will be way better, though obviously people on i9s will probably perform better than on i3s".
11:30 - Currently, everything is loaded into memory from yella to port olisar
We knew this. And it's just as surreal hearing them fully admit it for the first (?) time as it should be. I cannot overstate how backwards this design is. It's been repeated ad nauseum but it encapsulates CIG's design process as a whole: they want to develop a motorcycle, so they start out with a car, then they try hacking apart the frame, engine, and suspension while it's running into something vaguely motorcycle-shaped.
14:00 - Different classes of ship will be streamed in at different distances
Contemplate, for a moment, the enormous level of griefing that this will enable. Just think about it. I'll wait. I'll help: start by imagining the shenanigans made possible by E's P2P architecture.
14:30 - Wait, now they ARE working on OCS? Which is it??
16:00 - What are C++ pointers? This is literally basic entry-level C++ programming practices he's describing - when you null an object, all pointers to that object are no longer valid. Obviously, you have to handle that. The fact that they're struggling with this concept is 1) baffling and 2) indicative that they're continuing to bolt one ugly hack job onto another instead of having a coherent, well-designed engine architecture from the beginning.
17:30 - "going to be a big one for server FPS" - in the context of marker streaming on player's clients. How on earth would that improve server performance? Unless servers are exclusively bottlenecked by upload bandwidth (which should never, ever happen in the context of a true client/server architecture run on a not-completely-incompetent datacenter). They also contradict this later on.
18:00 - Wait, but they're also undoing all of those performance optimization gains for radar lol
20:00 - Serialized variables are indeed what I had described ages ago. Search the channel for them. I had to implement something similiar a year or so ago, it took me an afternoon. This was not for a tiny project. There is no reason that this should be a multi-year endeavour for them.
21:00 - "like save games"
What?? No, that's not how this works, that's not how any of this works. Are they trying to describe converting to a binary format? If so, that sort-of makes sense, if we disregard the fact that a true save game will require a ton more data about the overall context of objects and state, and can safely disregard a ton of data about the current game session (e.g. it would be super important to sync the current cooldown timer for reloading the player's handgun in a network session, but there is no need to clutter up a save game with weird state data like that - it will just add even more edge cases to test for later).
21:50 - "converts from the game's format to a normal format"
I have no idea what they're talking about unless this is the most painful way ever of describing "we take objects in memory and convert them to a binary format that's easier to read and write with file I/O". Boom, I just saved you three of the most painful minutes of my life with this one weird sentence, interviewers hate me.
22:58 - Serialized variables track which have changed and don't need to be re-sent.
DEAR GOD
WHY HAVE YOU FORSAKEN ME
This means that currently, every single frame, every single flag and counter and variable and absolutely any field whatsoever having to do with players is sent over the wire. Instead of doing the not-completely-bat-insane thing and only sending them when they change, like pretty much every other game has done forever.
They're just now fixing this though, woo. I can't wrap my poor little brain around this one.
26:20 - "When you want to spawn an entity, it happens on the main thread"
Ah yes, multithreading. Search the channel for my meltdown on the last time multithreading entity spawning came up and why it's ridiculous that they're having this discussion in year eight of development.
27:10 - "bind culling comes in by replicating those server side decisions"... "and controlling OCS on the player's client".
This almost makes sense if you forget, for a moment, that the player client does not have access to all of the information that the server does. Or at least, shouldn't in any sane design - otherwise, what's the point of having a server if you have access to all data all the time on every client? Ignoring the security implications for a moment (or not, and recall Star Marine getting hacked to pieces within days of release), this means that naively 'replicating' server decisions is impossible.
Unless, once again, they're just trying to describe "the server sends the data the client needs", but that would just be too pedestrian for the BDSSEWTFBBQ.
28:00 - "Q: What's the time sink if we have bind culling?" "A: We have them working, but now we have to fit them together"
So they're not actually working, gotcha.
All of those things are useless because they are bespoke solutions to problems specific to SC. Unless and until they are functioning in SC, they have zero value and effectively do not exist. "Fitting them together" is almost always the biggest challenge in any nontrivial project, because it's very easy to make things work fine and dandy in isolated silos, and significantly less easy to make things work fine and dandy in the lumbering monolith of an existing codebase.
30:00 -
I lost the plot of what they were talking about, this sounds like a list of dreams because you can't do any of that ingame right now AFAIK?
32:50 - Claim to be using headless clients for stress testing
33:21 - Player limit is 50, good times for the 100k player single shard persistent MMO
35:00 - Everything has to be converted for OCS?
36:00 - Oh, that's because the entirety of their codebase was apparently not designed with multithreading in mind. WELP
38:30 - More dreams about what the gameplay experience will be like, "amazing!"
40:30 "OCS is not the answer to everything, it's the foundation" what
41:40 - "If you go to Lorville your framerate will still be really low" okay lol
42:50 - "Hedge bets" - OCS won't increase player counts, server load is actually going to be heavier?
43:40 - "The load on our server side is going to increase pretty dramatically when this comes online"
46:20 - "Some of us can't even load the maps because the format is too big" What lol
Okay so zooming back out to look at all of this -
They're 100% (removed). They just admitted what we all called to varying degrees (mostly Derek ) years ago. They originally designed the game for small session and small maps. Around 2015 they decided "yeah throw that all out and buckle yourselves in, we're making an MMO now baby". Except instead of doing the only sane thing and re-architecting everything to support an MMO, they started bolting one shoddy hack on top of another. OCS is a fancy name for map streaming, which ANY open-world game needs. Bind culling is a fancy word for "only send stuff that clients need", which every single online internet multiplayer video game has done in some form. And by crobberts' wavy hands, why on earth did anyone architect their game for single-threaded, non-asynchronus content loading and object spawning in this decade? They should never have done that, even for Freelancer 2 or whatever the initial pitch was for, it was bad then, it's terrible now.
And now they've been trying to fix all of these systemic design flaws and antipatterns over the last 3 years as the scope has continued to increase and no apparent progress has been made. Three YEARS, by their own admission, and they are still at what is effectively negative progress for MMO networking, in their MMO.
Also, who were these people they that were being interviewed? Why did they sound like they were struggling with simple concepts (lol @ nullptrs in their content unloading system designed to null out pointers being a surprising thing)? Are there really only like 5 interns trying to write networking code? Because I can't come up with any plausible reason as to why some of the things are taking so long, like serialized variables, which almost anyone, not even a great programmer should have been able to bang out in a week, tops.
And yeah, most programmers are bad at talking to people and being interviewed, but usually the problem is getting them to shut up about inane trivialties that no one else will understand, not having them stumble around from a cheat sheet.
