Game Discussions Star Citizen Discussion Thread v12

That's interesting you bring up Turbulent. You're the first person in this thread to bring up the fact Turbulent helps build and design playable areas in SC and SQ42 -- can I ask where you heard that? Normally they've been looked at as the "website" guys, but have grown to be much, much more than that.
 
Yes, I pull data from the same job postings. I meant that not a whole lot of backers understand Turbulent's very, very key roll in SC. It's just interesting that you brought this up. I was wondering if Reddit or another site mentioned it, or if you found it on your own.
 
You can make the networking "right" before anything by following good requirements specifications. Except that if you have some sort of requirements specifications before all engines creating/moving datas are released, they are just very vague and imprecise estimates, not one real data exist yet. The estimations are most of the time false and your networking engine had to be redone again and again at each release of main engine creating a new set of datas. Each new engine in SC come with a lot of data.

The more important, for long term projects in need to handle quickly a lot of datas, the tech you use at the beginning of the project may be at risk of being completely overtaken by a new technology during the development. For instance if CIG had started to work on a worldwide big data transfert service in 2014, Amazon had released AWS Snowball (the exact same service) for USA+Europe in 2016 : https://docs.aws.amazon.com/snowball/latest/ug/whatissnowball.html . In this case, working on this tech from the beginning of the project would have been a big mistake.
You want to connect a number of players dynamically. Surely there can be made a couple of models of which a scalable one is to be preferred. However, the points where data is exchanged should be identified and considered for the format of how it all is stored.
 
That's interesting you bring up Turbulent. You're the first person in this thread to bring up the fact Turbulent helps build and design playable areas in SC and SQ42 -- can I ask where you heard that? Normally they've been looked at as the "website" guys, but have grown to be much, much more than that.

Let's talk about what Turbulent has brought to the table over the years (I'm not going to source all these, if you really want you can go through my SA post history for sources and direct links):

Turbulent's HEAP Platform: designed entirely by Turbulent, this is where the whale fracking begins. Unfortunately the original white paper is gone from their website (but remnants can be found across the web) but it does discuss how to fully engage your audience and make them spend, spend, spend. They got in on the ground floor of Star Citizen and have helped "engage" players or alpha-testers or backers or whatever you want to call them since the very beginning.

Website improvements, including Spectrum and an award-winning 'verse browser.

Video editing, creation and content: Turbulent at some point began to handle most of CI's marketing videos (not cinematic trailers, below) such as Calling All Devs.

Cinematic Team: some cinematics were handled directly by Turbulent, mainly marketing videos for ship sales. After some time, this would come to include non-marketing in-game cinematics as well, most likely for SQ42.

Tools and UI design: more and more postings and openings directly for Star Citizen on the Turbulent website suggest that they are now in charge of a large amount of backend support tools, including the new UI designs for Star Citizen.

Server improvements: Recent job postings indicated Turbulent also has a hand in the fabled server meshing and netcode improvements

World creation, including map and level design: job postings also indicate that Turbulent is working on building levels, including playable areas in SQ42 and SC

Unverified but highly probable: Looks like some of the demo reels we've seen of SQ42 were handled by Turbulent as well, including postings for time-limited contracts (six month positions) to build specific gameplay demos.

They started as a pretty small company, but have grown immensely since the SC kickstarter. They also have direct ties to CI, as two of the top members of Turbulent are on the CI board as of 2019 (and vice versa).

I've been talking about this for years, but Turbulent seems to do just about every damn thing for CI, Star Citizen and Squadron 42.

Doesn't CIG also now have a rather large (financial) stake in Turbulent?

Where did the money for that come from if all backer money goes to development? Sure, they could use backer money to hire turbulent to do dev work (not marketing work mind), but i don't recall them ever saying backers funds would be used to invest in other companies.
 
It's just an example about the risk of starting to work too early on those sort of tech in long term projects.
EDIT : you know that CR want only ONE server worldwide ?
I'm...not sure what you mean? How would Snowball help with server meshing? I mean, maybe as a dedicated physical backup system in case of catastrophic failure, sure.

Also, a single "server" isn't actually a single server (hence the server meshing). You'd need a wide net of dedicated servers presenting a single, unified front. What the players see is a single server (to use MMO terminology, a single shard), but in the background a highly complex network of computers is humming away and constantly sending data back and forth to each other and the clients.

It's why a game like EVE has to use time dilation in order to function when many hundreds or thousands of players enter a single area. Games like PlanetSide 2 use interesting prediction code to keep low reaction times when hundreds of players are in the same area, although I think they had a 1,500 player battle at one point (which was an insane lag fest, of course).

Having a lot of players in a single area isn't hard to do, really; but keeping the end user experience pristine during those high volume conditions is extremely hard and in some cases, impossible.
 
However, the points where data is exchanged should be identified and considered for the format of how it all is stored.
Alas no. Small example, I'm in charge to switch some old systems from XML to JSON and this sole change in data's format make a HUGE difference in the whole system performance. A good tech (XML) can become a bad one 2 years later (I was here when JSON made its appearance ;-) ).
 
Because server meshing is not here (and other elements I described in my post)... Server meshing is not a savior, but it's a mandatory step to have more systems.
There is absolutely zero connection between server meshing and the ability to have multiple systems. Neither is in any way a requirement of the other.

Server meshing isn't a savior for the simple reason that it doesn't actually address any problem they're having. Its proposed to be a workaround to instance limitations, but at no point have they been able to verbalize how it would in any way circumvent the fundamental issue with (and raison d'etre) of instances.

That's all it is: a fake solution to a problem that they have not been able to define or even demonstrated that they understand properly.
 
I'm...not sure what you mean? How would Snowball help with server meshing?
I am not saying that snowball is useful for server meshing. It's just an example with comprehensives dates that developping a storage engine too early in a long term project can be an error with ever evolving technologies making giant leap in short times.
 
There is absolutely zero connection between server meshing and the ability to have multiple systems. Neither is in any way a requirement of the other.
I would add that different systems can indeed reside on different servers, with a really weak interaction as in game they are only connected through warp gates. It means there is no interaction between players or other actors in different systems, apart from the action of moving through the said warp gates. So adding systems means just adding server instances (which can be in turn limited to 50 concurrent players, as per usual). They did not implement this quick-win (which would have granted them a lot of bragging points, lets be clear that CR and co. will seize any opportunity to do so), because they have no second system.
Also the figures for creating a system with its moons, is currently multiple years (i believe 3 years total), with a team of 50+ if we look at their development diaries. Everything is hand made to the smallest detail.
 
That's interesting you bring up Turbulent. You're the first person in this thread to bring up the fact Turbulent helps build and design playable areas in SC and SQ42 -- can I ask where you heard that? Normally they've been looked at as the "website" guys, but have grown to be much, much more than that.

Let's talk about what Turbulent has brought to the table over the years (I'm not going to source all these, if you really want you can go through my SA post history for sources and direct links):

Turbulent's HEAP Platform: designed entirely by Turbulent, this is where the whale fracking begins. Unfortunately the original white paper is gone from their website (but remnants can be found across the web) but it does discuss how to fully engage your audience and make them spend, spend, spend. They got in on the ground floor of Star Citizen and have helped "engage" players or alpha-testers or backers or whatever you want to call them since the very beginning.

Website improvements, including Spectrum and an award-winning 'verse browser.

Video editing, creation and content: Turbulent at some point began to handle most of CI's marketing videos (not cinematic trailers, below) such as Calling All Devs.

Cinematic Team: some cinematics were handled directly by Turbulent, mainly marketing videos for ship sales. After some time, this would come to include non-marketing in-game cinematics as well, most likely for SQ42.

Tools and UI design: more and more postings and openings directly for Star Citizen on the Turbulent website suggest that they are now in charge of a large amount of backend support tools, including the new UI designs for Star Citizen.

Server improvements: Recent job postings indicated Turbulent also has a hand in the fabled server meshing and netcode improvements

World creation, including map and level design: job postings also indicate that Turbulent is working on building levels, including playable areas in SQ42 and SC

Unverified but highly probable: Looks like some of the demo reels we've seen of SQ42 were handled by Turbulent as well, including postings for time-limited contracts (six month positions) to build specific gameplay demos.

They started as a pretty small company, but have grown immensely since the SC kickstarter. They also have direct ties to CI, as two of the top members of Turbulent are on the CI board as of 2019 (and vice versa).

I've been talking about this for years, but Turbulent seems to do just about every damn thing for CI, Star Citizen and Squadron 42.
Wait... CIG is 500+ big, got rid of most contractors it used to work with to make and control everything in-house, yet they now need to externalize more and more things to Turbulent? What the what?!
 
You can make the networking "right" before anything by following good requirements specifications. Except that if you have some sort of requirements specifications before all engines creating/moving datas are released, they are just very vague and imprecise estimates, not one real data exist yet. The estimations are most of the time false and your networking engine had to be redone again and again at each release of main engine creating a new set of datas. Each new engine in SC come with a lot of data.

The more important, for long term projects in need to handle quickly a lot of datas, the tech you use at the beginning of the project may be at risk of being completely overtaken by a new technology during the development. For instance if CIG had started to work on a worldwide big data transfert service in 2014, Amazon had released AWS Snowball (the exact same service) for USA+Europe in 2016 : https://docs.aws.amazon.com/snowball/latest/ug/whatissnowball.html . In this case, working on this tech from the beginning of the project would have been a big mistake.
What you are saying here is basically that CIG/CI/CR don't understand development at all and have either lied or misled everyone since the beginning and any dates or technologies they put out there are wild guesses at best and will end up big failures at worst and there is no way to know.

This is just insane to defend.

They had a target initially. They revised the target when the moniez rained on them. They still don't share good requirements and specifications with achievable goals. It is still all "new technology, not sure when done but we estimate". The Cart was put 100 miles in front of the Horse, i.e. this is all being done backwards and contrary to all statements CR make and the so-called roadmaps and pipelines and such.

FD released a full procedural galaxy with deep valleys and shallow valleys able to scale from 1 to tens of thousands of simultaneous players in 3 years flat. Infinitity Battlescape has deep valleys and a tiny team working 3-4 years on their game that will hold 100 players in a seamless solar system at full 1:1 scale like ED. No Mans Sky has valleys and 25 or fewer employees and released in less time than SC fully working game with many fully working updates and thousands of players and regularly releases functional patches that add to the game and just work.

No game company takes 7-8 years to release the buggy craptastic stuff that currently makes up Star Citizen. And certainly they don't constantly retrench publicly shared roadmaps and so-called "project plans". It's all crazy kindergarten level bullshottery that no-one else in the industry does.

CI is mired in mis-management, scope creep, technical debt, changing terms, constantly missed deadlines and moved goalposts, myths and obfuscation of their real issues. Outsourcing Arena Commander worked so well they are now outsourcing again, and with only 500 employees they surely need to outsource creation of Procedurally Generated systems given the advanced state of their PG Planet Tech 18.2 piple-line? The game may well yet become a functional release after $450 MUSD and 12 years of development. That would not change massive waste and mismanagement cluster-cluckery of the most expensive and longest in development laughter-inducing game development ever.

Why is this so difficult for anyone to see? I just don't get it. Red flag, green flag, whatever flag, there is tons of obvious bullshottery and wasted money and puffery at CR palace. It's just obvious even if excited one slows down and uses their own logic.

[Edit, didn't mean Arena Commander, meant the amazing FPS module, Star Marine. https://www.kotaku.co.uk/2016/09/29/what-happened-to-star-marine-star-citizens-missing-module.]
 
Last edited:
I am not saying that snowball is useful for server meshing. It's just an example with comprehensives dates that developping a storage engine too early in a long term project can be an error with ever evolving technologies making giant leap in short times.
I was going by your "EDIT : you know that CR want only ONE server worldwide ?" and was unsure how that fit into Snowballs use or technology.

Anyway, it doesn't matter. We've seen zero progress on server meshing, the servers are still capped at 50 players and they can't even get a 40 person Battlefield clone working without insane amounts of client/server latency.
 
Wait... CIG is 500+ big, got rid of most contractors it used to work with to make and control everything in-house, yet they now need to externalize more and more things to Turbulent? What the what?!
Turbulent are the only guys who have consistently been able to deliver working features that fit CIG's needs and are so enmeshed into the core components of the company's functionality (the store most notably, but far from exclusively) that CRobber hasn't been able/tempted to frame his management failures as contractor incompetence and gotten rid of them. Aside from that, they're really no different from any of the myriad of third parties that have done work for CIG over the years, only for that work to be dumped and the contract terminated.

The graveyard of CIG contractors is pretty large, and very little of that is a matter of the contractor doing a bad job...

As mentioned earlier, the whole "gotta build the company" excuse is bunk, and this is yet another reason why that's so.
 
Doesn't CIG also now have a rather large (financial) stake in Turbulent?

Where did the money for that come from if all backer money goes to development? Sure, they could use backer money to hire turbulent to do dev work (not marketing work mind), but i don't recall them ever saying backers funds would be used to invest in other companies.
Yes, that was part of the deal in 2019. CI got some of Turbulent, Turbulent founders got some of CI. There were rumors that Turbulent was unhappy doing a ton of work and getting stiffed on some key bonuses; this "merger" or stock swap with board expansion and placement was probably a way of placating that.
 
Server meshing isn't a savior for the simple reason that it doesn't actually address any problem they're having. Its proposed to be a workaround to instance limitations, but at no point have they been able to verbalize how it would in any way circumvent the fundamental issue with (and raison d'etre) of instances.
Perhaps you don't know exactly what they want to do. A "dynamic" server meshing that "shrink or expand" the area of the instances to limit the amount of entities inside them.
Example with an instance max capacity of 10 :
  • 10 players in the Stanton system (5 in planet A + 5 in planet B) in one instance for the whole system.
  • 10 new players enter the system in a caterpillar and go to planet C, the first instance is divided in instance1 for planet A+B and instance2 for planet C
  • 10 new players enter the system in a 890 Jump and go to planet C, instance2 is divided in instance2a for the caterpillar (yes, one instance only for the ship) and instance2b for the 890 Jump.

Don't ask me how they want to achieve this, for me it's a dream, they will try and fail. The system in the end will certainly be the classic one with one static instance by planets with a limit of (I hope) 200 or 300 players by instances.
 
Let's just say they do manage to make it 250 players per planet and surrounding space; how do you restrict other players from getting there when the player cap is full? Can you simply not quantum travel to it? Do you spin up another empty instance of that area, losing the whole "single shared universe" design?

How do you stop an Org from simply moving their entire fleet to an area and staying put, effectively making that area unplayable and unable to be accessed for the rest of the playerbase? Since some capital ships have large crew compliments, only a few ships could block out an entire playable area.

If there's 1 million players with 100,000 on at any given time, you'd need 400 areas (planets and space) and you'd still hit max capacity per planet. That means you'd probably need 1,000 different areas in order to accommodate your playerbase (planets, moons, asteroid belts, all with spaces between them).

What happens when someone loads up a hauler in one area, but is unable to offload their cargo because their destination area has full player capacity?

What happens when a player logs out on a planet, but when they relog, the area is at the max player count? Do they get sent to another area or a different planet? What determines that?

So many, many, many questions. All of this needed to be answered and designed years ago.

If there is one thing I learned in my time working in games (specifically MMOs), its that players are extremely crafty and will find and ultimately abuse even the best designed systems. The above are simple questions that have complex ramifications for players.
 
Last edited:
Perhaps you don't know exactly what they want to do. A "dynamic" server meshing that "shrink or expand" the area of the instances to limit the amount of entities inside them.
Example with an instance max capacity of 10 :
  • 10 players in the Stanton system (5 in planet A + 5 in planet B) in one instance for the whole system.
  • 10 new players enter the system in a caterpillar and go to planet C, the first instance is divided in instance1 for planet A+B and instance2 for planet C
  • 10 new players enter the system in a 890 Jump and go to planet C, instance2 is divided in instance2a for the caterpillar (yes, one instance only for the ship) and instance2b for the 890 Jump.

Don't ask me how they want to achieve this, for me it's a dream, they will try and fail. The system in the end will certainly be the classic one with one static instance by planets with a limit of (I hope) 200 or 300 players by instances.

Based on the network experience they delivered on top of the crytek implementation built in, I bet if they do deliver any of this it will be "alpha tier 0" for the first ten years while they work out the kinks. With varied frame rates locked to different instances/servers and variable lengthy wait-times between changing instances - go from your ship (10fps) and wait to enter the system instance (15fps) then move to a new system (long wait, 9fps) but hey "It's Alpha ha ha look at the 10 players that manage to get in the same instance dancing and saluting at each other when not clipping through the floor"

A less forward looking developer would have figured out critical path POC stuff at the start of the project, they probably would have foolishly done it without crowdfunding hundreds of millions of dollars and leaving it until nearly a decade later to sort out.
 
Last edited:
All of this needed to be answered and designed years ago.


What techniques or technologies have you developed that weren’t feasible seven years ago, when you started this project?

When I first started this, I didn’t think we’d be able to realize the planets and walk around them in first-person any way you want, but as we went on, the power of computers and GPUs has been getting better. The cloud’s become sort of ubiquitous, we run all our servers in AWS at the moment. The power of those machines continues to increase. When we first start the game, I thought we’d have to have all these different instances, so people would play in their instance and not be able to join with their friends because they might not be on the same server. But with the new cloud power, we’re gonna be able to do this thing we call “server meshing” which allows a whole bunch of servers to run in the cloud and talk to each other. So instead of having 400 servers and each server has 100 or 200 people on it, and those people can’t see [players on other servers], if they all mesh together you could have all 4,000 people or 40,000 people in the same world at the same time. We’re not the only people that are working on that. That’s the sort of thing that you won’t be able to get on a single-player game that I think can be really compelling. That definitely wasn’t something people were talking about when I first pitched this in 2012.

So you’re envisioning world-scale environments that have thousands of people in them at once?

Absolutely, and we’re quite far along on the tech to deliver that. I know Amazon has been working on some of this behind closed doors, [Google] Stadia is perfectly situated to do that because their whole setup is in the cloud, including the clients. For an online multiplayer game, that’s really interesting. One of the problems you have in traditional multiplayer games is that you always have a client [the machine the player controls directly] and the servers and there’s always a distance between the two. Even if you have fast internet it will maybe take 20 milliseconds for the message to get from your client to the server and the server has to simulate what’s happening, which could take another 15 milliseconds or 30 milliseconds. Then it has to send that message back to your client and tell you what the results are, plus telling you what everyone else is doing, that’s another 20 milliseconds. And this is only if you’ve got fast internet and are close to a data center. So you’ve already got a lag that’s anywhere from 70 to 100-plus milliseconds. In multiplayer games, people can get slightly out of sync and it gets laggy. The cool thing with Stadia is if everything’s in the cloud, there’s almost no time difference to talk between servers and clients and there really isn’t any difference between the two. The quality of a multiplayer experience will increase because you’ll have much less latency, you won’t have any issue of cheating, you eliminate the issues you get with lag.

 
Back
Top Bottom