Texte vergleichen

Finden Sie den Unterschied zwischen zwei Textdateien

Real-time diff

Unified diff

Collapse lines

Highlight change

Syntax highlighting

Onlinewerkzeuge

Diffchecker Desktop The most secure way to run Diffchecker. Get the Diffchecker Desktop app: your diffs never leave your computer!Get Desktop

DKS changing stuff again.

Created 5 years agoDiff never expires

94 lines

archive.today

webpage capture

Saved from

http://dereksmart.com/2016/12/star-citizen-irreconcilable-differences/

history←priornext→

15 May 2018 16:36:59 UTC

26 Jan 2020 19:40:41 UTC

All snapshots from host dereksmart.com

WebpageScreenshot

sharedownload .zipreport error or abuse

Smart Speak

home

about

discuss



Star Citizen – Irreconcilable Differences

 December 27, 2016 by dsmart

 dsmart

1 Comments

 No comments yet

“Noun

Differences of opinion or will that cannot be brought into harmony, or cannot be brought into agreement through compromise.

A relationship that has become relentlessly hostile.”

The TL;DR recap on how I got involved in this farce and why I’m going to keep going until the very bitter end

The TL;DR recap on how I got involved in this farce

TRIPPING THE MEMORY LANE

With 2016 coming to a close, and arguably the most disastrous year for the Star Citizen development in terms of development & deliverables, PR & marketing, backer goodwill & dissent, legal ramifications, State & Federal involvement etc, it should come as no surprise that the most surprising (at least to those not paying attention) event was buried in an end of year update during the busy holiday period. In fact, while 2016 funding for the project is on track to exceed $35 (!) million by end of this month – regardless of the inaccuracy of the funding chart – it’s easy to see that the development pace and deliverables have not kept in line with the funding received. My previous Oct blog, Shattered Dreams, encapsulates the failures of 2016 in general, while shedding more light on how CIG/RSI has treated backers worse than a publisher would a developer.

But let’s back up a bit here, and take a trip down memory lane.

Back in July 2015, I wrote a highly controversial blog, Interstellar Citizens, about the project, it set off a chain reaction of events which led to an all-out war between hardcore backers of the project, paid marketing shills (Shillizens), the anti-social misfit backers (Shitizens) who are raging a war of attrition against dissent, and well, everyone else with a brain which has concluded that the project is a catastrophe. In that blog, and several others which followed, I had maintained – consistently – that the game as pitched could never be built, not only due to the engine they chose, CryEngine 3 (aka CE3) and which was unsuited for the increased scope of the game, but as I also pointed out that even if they somehow managed to find people with the talent and expertise to pull it off, coupled with a robust custom engine, that it would still be a major undertaking and not likely to cost anything less than $150 million.

As of this writing, at the end of project’s five year (if you are counting 2011 during which Chris Roberts stated the game was already in development) anniversary, the project is not only two years late, but has also raised over $140 million in funding through the most devious of fundraising schemes ever seen in gaming; even as the technical debt and lies continue to pile up.

dsmart-backer-tier

My Backer Tier

THE GAME

This is what Star Citizen promised back in Oct 2012. I invite you to read everything on that page, including all the FAQ entries. By the time the campaign closed on Kickstarter, I was among an elite group of 1509 backers at that tier, and who expected the games (Star Citizen multiplayer, & Squadron 42 single-player) to be completed and delivered by the promised Nov 2014; and for which the ToS allowed a 12 then 18 month delay period.

Somewhere along the line, once Chris Roberts figured out that they could continue adding stretch goals post-Kickstarter, as a way to keep raising money associated with them, the original game ballooned out of proportion, and completely out of the scope of the CE3 engine. And in doing so, as part of what I believe to be a worthy effort to show some progress, backers ended up with the promise of several game modules which were to serve as testing platforms for both Star Citizen and Squadron 42. First, there was Arena Commander, the dogfighting and space racing module, which was first launched in June 2014. The Persistent Universe (PU), which launched in Dec 2015, isn’t a stand-alone module per se, but is the core of the Star Citizen multiplayer game. Then there’s Star Marine, the first person shooter module, which just launched this Dec 2016 in the 2.6 update.

Here’s the thing. Six years later, neither of these is complete. While visually impressive in some regard, they’re all in various stages of pre-Alpha, even as the company focuses on selling ships (some mere concept images) in a bid to continue fundraising. Even looking at the getting started guide, you don’t see a complete game, but rather “promises of the game to come”, along with a set of game modules which are neither connected to, nor part of the cohesive whole of the promised Star Citizen and Squadron 42 games.

To the extent that, as someone who has been in videogame development for over 30 years, having developed and shipped over a dozen games (some very large and complex), I am finding it hard to point out anything innovative, ground-breaking, or worth $140 million in this project. Like, at all. There are those who would discard this sentiment out of hand, because let’s be fair, I can’t be regarded as being unbiased, given the circumstances. That’s why I always invite people to look at the facts and the evidence of what’s there, regardless of what I am saying and/or writing. Nothing that I do or say is going to make Star Citizen a good or bad game, let alone a finished game delivered and with all expectations met.

THE ENGINE

For some time now, even as they struggled to create a custom engine from CryEngine 3.x, I have followed their engineering challenges, failures, and successes over the years. We already knew that, as with all game engines, they were already building a custom game engine dubbed Star Engine; and which was based on CE3. This engine would be the core for both Star Citizen and Squadron 42. What we didn’t know until a few months ago, was that they had not only stopped taking CryEngine build updates from CryTek, but also that they had modified their base CE 3.7x by over 50% in coming up with their Star Engine derivative.

Part of their customization of the engine is in the increase of the game world size. At one point, they claimed that Star Engine was a “64-Bit engine” – something that is still written on their website features page. I first sounded the alarm that this was patently false; then subsequently wrote posts (1, 2) about it, as well as mentioning it in my Fidelity Of Failure blog. I had stated that not only was it shocking for them to even be doing that level of work, four years in, but also that there was simply no way they could create a 64-Bit custom engine, from a base engine like CryEngine which was 32-Bit. In the end, the narrative switched to “64-Bit positioning” which made more sense; though – as I wrote- they were still cheating regardless. And in the past few weeks, it has now emerged that – as I had stated then – they are actually using a 32*2 conversion aka “floating origin” in order to support the increase their world size. Note that they still haven’t even built a single star system to completion. So there is that.

Dealing with CryEngine which wasn’t designed for anything resembling the scope (especially in terms of world size, networking, open-world MMO structures etc) of Star Citizen vision 2.0 – at least not without extensive customization – has been an on-going challenge according to various past and present sources working on the project. Arguably, as most of us writing these massive games tend to do, developing an engine from the ground up (similar to what Frontier did with Elite Dangerous) would have been the more prudent way forward. But as we all now know, the original vision 1.0 of the game would have probably been farther along by now with some CE 3.x customization. But the more the scope of the game increased, so too did the requirements of the Star Engine. Which is precisely why – as of this writing – the game is still session + instanced based and has zero implementations for an MMO game; and certainly not with their target of 1000 client server games. Star Citizen itself – to date – isn’t even 15% of what was promised; and Squadron 42 is still unseen (as of this past Oct, sources were claiming that it doesn’t even exist as a game) in playable form.

There are various methods of building and maintaining an MMO game. Most MMO games use instances (copies of the game world with clients) which host a certain number of clients. Others use a whole server to represent a “persistent” world copy, while limiting the number of clients on the server. They are only similar in the sense that while several instances can be spawned on a single powerful server (or cluster of servers), the server cluster tends to limit the number of clients based on the power of the server itself.

For example:

#1 an MMO game can spawn a 16 client (aka players) instance01, an 8 client instance02, and a 4 client instance03. None of the players in any of these instances can ever meet, nor interact with other clients in the other instances. To add more players, the game just spawns new instances.

Depending on the game, player stats can also be saved on a server database so that when you join the game again, regardless of which instance you are spawned in, your stats are reloaded; then saved again when you quit.

Scaling (for more clients) a game like this involves either setting up additional hardware or cloud servers which then spawn the required instances. So e.g. if your instances can only support 16 clients, and you have 256 more players, then you have to spawn 16 more instances via either server or cloud sessions.

#2 Another MMO game can setup a server cluster which supports up to 32 clients (e.g. a combination of all the clients in the above instanced example); and all those clients can see and interact with each other because they are in the same world space.

As with instanced servers, depending on the game, player stats are saved and restored via a server database.

Scaling for this type of game requires setting up additional hardware servers depending on the capacity of the clients. And when clients desire to play on other servers, they either have to create new characters and/or accounts, or pay for a server switch. NOTE: In Line Of Defense, which isn’t instanced, our networking tech allows us to host a scene/world on a separate server, then dynamically and seamlessly transition clients between servers on-demand.

All things considered, session based games in which a group of players join a game, then when the game ends, they’re all kicked out as the game session is reset, are also a form of instancing. Which is precisely what the GameLift module in Lumberyard is and does.

Both of the above methods have their pros and cons, and each type is carefully chosen based on the game being developed. In terms of performance (visual + networking), due to the sheer amount of networking data that needs to be passed between clients and the server (dedicated or not), twitch based games in the fps, flight and driving genres are the most difficult genres to develop in a MMO format. Especially if the goal is for an open world universe where all clients on the server can interact with each other at some level or another. In terms of visuals, games tend not to render (display) objects which are not within a certain vicinity of another player. This technique is also employed in some networking games whereby packet data is only sent to players within a certain range of each other.

In the MMO space, the Planetside games are the most famous twitch based games which have aerial, ground and fps combat. And even though they are designed to support up to 2000 clients per continent (the game has 3 continents) for a total of 6,000 (!) clients per server (the game is not instanced), in addition to culling visual and network data, they also use “population lock” techniques in order to keep those client numbers within those parameters. What this means is that if there are already 2000 clients in a continent, no additional clients can go to that continent unless and until the client count goes down due to clients leaving the server or moving to another continent.

As anyone who has played either of the two Planetside games can attest to, anything above 128 clients, tends to be a sub-par experience; especially in times where you have massive 50+ client battles in close proximity. In fact, here is a write-up of how/why they had to even limit these numbers for the PS4 version of the game which released earlier this year. Our own upcoming MMO game, Line Of Defense, which supports both MMO and session based multiplayer, also uses a similar multiplayer model as it is the most efficient, and gives the best of both worlds.

Developing multiplayer games is very complex. Developing MMO games is super complex. Developing twitch based MMO games is ultra complex.

Thinking about developing a twitch based MMO game, with a custom engine that uses a core engine that wasn’t designed for it? Well, as any CTO will attest to, you were fucked at “Hello World“. And that sums up Star Citizen. Which is precisely why currently all three (Arena Commander, Star Marine, PU) modules are a sub-par mess that struggle with anything more than 16 clients in an instance. Not to mention the fact that, up until they increased the scope of the game, it was never – ever – billed as an MMO. Says so right here and various public statements quoted in my blogs.

“Is Star Citizen an MMO?

No! Star Citizen will take the best of all possible worlds, ranging from a permanent, persistent world similar to those found in MMOs to an offline, single player campaign like those found in the Wing Commander series. The game will include the option for private servers, like Freelancer, and will offer plenty of opportunities for players who are interested in modding the content. Unlike many games, none of these aspects is an afterthought: they all combine to form the core of the Star Citizen experience.“

And they built their server instancing backend using Google Compute. Before I delve more into this, please read this response from 2014 by Chris Roberts to backer angst about having servers in Australia. Then read this response from 2015, again in response to Google Compute, and a good measure of DX12 (Star Engine is still DX11 btw) thrown in. And if you’re in the mood, watch this video interview in which he was talking about player hosted servers and how cloud computing takes that into account. Then there was that time when Chris was commenting on Shinra’s cloud computing implementation for games.

“Shinra’s business plan may be what really sets it apart, Roberts says. Shinra could achieve for a variety of games what Roberts’ company has built one game to accomplish.”

Some backers are of course confusing the Star Engine networking implementation – which as they know sucks – with the Compute powered server instancing backend. Thing is that it doesn’t matter how robust the server is, whether it is hardware or cloud based. What matters is the networking layer used by the game. If the layer sucks, that’s basically the end of that discussion. And that is precisely why – for over a year now – they have been touting an all new networking layer which is supposedly going to be capable of hosting 1000 client instances. Let me repeat that: 1000 client instances. For a twitch based combined arms game that’s supposed to have space and planetary combat in air/space craft, vehicles, fps. And be able to host client ships capable of carrying over 100 passengers. In a “persistent” universe. Here is what he said in an interview during the GamesCom this past August. “…thousands of players in the same area, all at the same time”

It’s all lies. And they aren’t even trying to hide the lies anymore. They just throw it all out there, knowing that some of the backers will just accept it and move on, even as the Shitizens continue to shout down any backers who question such things.

Here’s the thing; if by now at the end of year five (now going into six, but who’s counting?) they still haven’t even got that far yet into breaking the 16-24 client (note that 24 clients in Star Citizen instances, is akin to what happens with 50 clients in a Planetside session) barrier, releasing the new networking layer that’s going to be based on fairy dust and magic etc, what makes anyone think that it’s ever going to happen? It’s bad enough that right up to build 4.0 which Chris claims is coming in Q4/2017, there is now no mention of the magic networking layer; having been removed from all the recent talking points these past months.

THE SWITCH

A few months ago, there were some insider rumblings that due to on-going challenges of building the game that Chris Roberts envisioned, an engine switch was inevitable. I had discarded that out of hand, much like I discarded the recent talk of a console port of the game because let’s face it, this far along into development, it would be pure madness to make such a switch. Not to mention the furor that it will cause with the backers who, while entrenched in Sunk Cost Fallacy, are still throwing money into a burning fire. And when you think about it, short of a custom engine built from the ground up, even with their major advancements, Unity5 would be a stretch. Not to mention the fact that it’s C# based. So only Unreal Engine 4 is actually capable of building something like Star Citizen; even with some design compromises. And it would be a major re-write either way.

I had forgotten about the engine switch nonsense until it sparked up again earlier this year. Seeing as some people (who I don’t even know, due to sources being anon) have reportedly been fired from CIG/RSI for being sources to myself and the media (e.g. see Kotaku’s recent slew of Star Citizen research articles, or The Escapist article from last year), I tend to now pick and chose what I share publicly. And with very few people close to something like an engine switch, it would be trivial for CIG/RSI to go on a witch hunt to seek out who was leaking (the most open development ever!) information to backers and the general public.

Despite at least two sources claiming they were in fact switching to Lumberyard, I had forgotten about the engine switch nonsense until it sparked up again earlier this year. Seeing as some people (who I don’t even know, due to sources being anon) have reportedly been fired from CIG/RSI for being sources to myself and the media (e.g. see Kotaku’s recent slew of Star Citizen research articles, or The Escapist article from last year), I tend to now pick and chose what I share publicly. And with very few people close to something like an engine switch, it would be trivial for CIG/RSI to go on a witch hunt to seek out who was leaking (the most open development ever!) information to backers and the general public. So, my stance is that I’ll believe it when I hear more. I mean, with all their show broadcasts, no way they would keep something like that quiet, unless they are concerned about backer reaction.

So this past April, I made a comment as part of what I believed – at the time – would be madness for them to do. I said “I can’t wait to read the part where they decide to either port to Unity5 or to Lumberyard, Amazon’s version of CryEngine4. Not to mention CryEngine5 which is more advanced/modern than CryEngine4.”

In fact, this past April, I made a comment as part of what I believed – at the time – would be madness for them to even do. I said “I can’t wait to read the part where they decide to either port to Unity5 or to Lumberyard, Amazon’s version of CryEngine4. Not to mention CryEngine5 which is more advanced/modern than CryEngine4.”

Yup.

Like clockwork, the backer community was ablaze with all kinds of speculation. Just as things were about to reach fever pitch, CIG/RSI quickly pushed out a revised (you can tell because the just released 2.6 was mentioned in the “Top Stories This Week” section) newsletter mentioning it at the top. That section reads:

Then, obviously the media (1, 2, 3, 4, 5, 6) got wind (there was the official press release that went out shortly after) of it, and just like that, it was news; and the speculation and confusion continued to spread like wildfire. Shortly after, knowing that the newsletter was insufficient, as it didn’t address most of the questions being asked, Chris Roberts – whose last post on the game’s forums was over two years ago – posted a missive about the switch.

NOTE: There is speculation that he didn’t even write that, because shortly afterwards, a CIG community staff member, Zyloh, edited it, as seen in the top right part of the image.

With talk about an Amazon “partnership” (the term used by Chris Roberts) running rampant, Kotaku-UK were the only outlet that bothered to even seek clarification on what this actually meant. This is their update:

“Updated: I’ve had a response from CIG director of communications, David Swofford, to say that the relationship between CIG and Amazon is that of them being a regular licensee of Amazon’s technology. The reason for the announcement today was that it was turned on with the release of 2.6. He also confirmed that all the work CIG had done to expand the CryEngine has been transitioned to the new engine.“

Shortly after, another publication received a statement from Erin Roberts, brother of Chris Roberts and head of the Foundry 42 studio in the UK:

“Thanks for getting in touch. As you’ve (correctly) surmised, any suggestions that the engine switch would have a major impact on our development couldn’t be further from reality. Lumberyard is completely based on Cryengine, yet with a lot of improvements. As a consequence, we do not have to change the fundamental core engine at all which is why this change has had absolutely no effect on our development of Star Citizen.

The advantage of Lumberyard is that we get great ongoing support on the cloud / networking side from Amazon as well as great tools support while continuing uninterrupted development on what we have built up over the last 4 years. As we’ve tried to explain many times before, we have pretty much rewritten 50% of what we licensed 4 years ago now, even in core systems from Cryengine. What is great is that everything we have reworked, also now seamlessly integrates into Lumberyard, and the engine switch has not required any extra engineering time. We are actually very lucky that this opportunity presented itself to work with a powerful and committed company like Amazon that is investing heavily in its tech. This collaboration will effectively allow us to do more for our community going forward without costing us really anything in terms of engineering time or otherwise, so it is a win-win situation and good news all around.“

And in typical CIG/RSI fashion for revisionist history, burying dissent etc, a forum thread in which backers were speculating about switching to Lumberyard earlier this year, was deleted shortly after the news broke. Of course Goons saw that one coming and were able to archive the thread before it was deleted and merged into another thread in a bid to bury it. And sure enough, the Shillizens and Shitizens promptly proceeded to start altering the votes in order to skew the results in which 70% had previously voted no.

THE OBFUSCATION

Below is my blunt synopsis of what has now been written by Chris Roberts who, since the very start, has a storied history of blatantly lying to the very backers who, to date have given him all this money, while not having a game they paid for.

Amazon’s Lumberyard game engine, which was released free in Feb 2016, like the CIG/RSI Star Engine, is a custom engine built on top of CryEngine 3.x for which they acquired (1, 2, 3, 4) a license back in early 2015. What is still not clear is whether or not the license was for all versions of the CryEngine. According to public and anon sources, what Amazon has is 99% CryEngine, but with

Amazon’s Lumberyard game engine, which was released free in Feb 2016, like the CIG/RSI St

Gespeicherten Diffs

Original text

Datei öffnen

archive.today
webpage capture
Saved from	
http://dereksmart.com/2016/12/star-citizen-irreconcilable-differences/
history←priornext→
15 May 2018 16:36:59 UTC
All snapshots	from host dereksmart.com
WebpageScreenshot
sharedownload .zipreport error or abuse

Skip to content
Smart Speak
home
about
discuss

Star Citizen – Irreconcilable Differences
Star Citizen – Irreconcilable Differences
 December 27, 2016 by dsmart
 dsmart
1 Comments

“Noun
Differences of opinion or will that cannot be brought into harmony, or cannot be brought into agreement through compromise.
A relationship that has become relentlessly hostile.”
The TL;DR recap on how I got involved in this farce and why I’m going to keep going until the very bitter end
TRIPPING THE MEMORY LANE
With 2016 coming to a close, and arguably the most disastrous year for the Star Citizen development in terms of development & deliverables, PR & marketing, backer goodwill & dissent, legal ramifications, State & Federal involvement etc, it should come as no surprise that the most surprising (at least to those not paying attention) event was buried in an end of year update during the busy holiday period. In fact, while 2016 funding for the project is on track to exceed $35 (!) million by end of this month – regardless of the inaccuracy of the funding chart – it’s easy to see that the development pace and deliverables have not kept in line with the funding received. My previous Oct blog, Shattered Dreams, encapsulates the failures of 2016 in general, while shedding more light on how CIG/RSI has treated backers worse than a publisher would a developer.
But let’s back up a bit here, and take a trip down memory lane.
Back in July 2015, I wrote a highly controversial blog, Interstellar Citizens, about the project, it set off a chain reaction of events which led to an all-out war between hardcore backers of the project, paid marketing shills (Shillizens), the anti-social misfit backers (Shitizens) who are raging a war of attrition against dissent, and well, everyone else with a brain which has concluded that the project is a catastrophe. In that blog, and several others which followed, I had maintained – consistently – that the game as pitched could never be built, not only due to the engine they chose, CryEngine 3 (aka CE3) and which was unsuited for the increased scope of the game, but as I also pointed out that even if they somehow managed to find people with the talent and expertise to pull it off, coupled with a robust custom engine, that it would still be a major undertaking and not likely to cost anything less than $150 million.
As of this writing, at the end of project’s five year (if you are counting 2011 during which Chris Roberts stated the game was already in development) anniversary, the project is not only two years late, but has also raised over $140 million in funding through the most devious of fundraising schemes ever seen in gaming; even as the technical debt and lies continue to pile up.

Since that first blog, through various sources (on and off the project), observation of the project, as well as through other avenues, I have been able to not only accurately chart and track the course of this development, but also managed to maintain a relatively high rate of being more right, than wrong. To the extent that in addition to my extensive blogs, I’ve also had to setup a discussion section (particularly my musings and scoops) on my blog page in order to host all the stuff that keeps happening. And when that data exceeded the capacity of that resource, I installed a separate stand-alone forum in order to continue hosting the data. I do this because, as with all things related to video gaming on the Internet, eventually either it will all be lost, buried in disinformation, or simply mired in inaccurate rhetoric as the years go by. For good, bad, or ugly, the sole purpose of my involvement – vindication aside – is because it is my hope that, as we are now seeing in crowd-funding in general, that a scam like this never happens again. At least not to this extent. For me, it’s no more an obsession, than it is a hobby.
dsmart-backer-tier
My Backer Tier
 
THE GAME
This is what Star Citizen promised back in Oct 2012. I invite you to read everything on that page, including all the FAQ entries. By the time the campaign closed on Kickstarter, I was among an elite group of 1509 backers at that tier, and who expected the games (Star Citizen multiplayer, & Squadron 42 single-player) to be completed and delivered by the promised Nov 2014; and for which the ToS allowed a 12 then 18 month delay period.
Somewhere along the line, once Chris Roberts figured out that they could continue adding stretch goals post-Kickstarter, as a way to keep raising money associated with them, the original game ballooned out of proportion, and completely out of the scope of the CE3 engine. And in doing so, as part of what I believe to be a worthy effort to show some progress, backers ended up with the promise of several game modules which were to serve as testing platforms for both Star Citizen and Squadron 42. First, there was Arena Commander, the dogfighting and space racing module, which was first launched in June 2014. The Persistent Universe (PU), which launched in Dec 2015, isn’t a stand-alone module per se, but is the core of the Star Citizen multiplayer game. Then there’s Star Marine, the first person shooter module, which just launched this Dec 2016 in the 2.6 update.
Here’s the thing. Six years later, neither of these is complete. While visually impressive in some regard, they’re all in various stages of pre-Alpha, even as the company focuses on selling ships (some mere concept images) in a bid to continue fundraising. Even looking at the getting started guide, you don’t see a complete game, but rather “promises of the game to come”, along with a set of game modules which are neither connected to, nor part of the cohesive whole of the promised Star Citizen and Squadron 42 games.
To the extent that, as someone who has been in videogame development for over 30 years, having developed and shipped over a dozen games (some very large and complex), I am finding it hard to point out anything innovative, ground-breaking, or worth $140 million in this project. Like, at all. There are those who would discard this sentiment out of hand, because let’s be fair, I can’t be regarded as being unbiased, given the circumstances. That’s why I always invite people to look at the facts and the evidence of what’s there, regardless of what I am saying and/or writing. Nothing that I do or say is going to make Star Citizen a good or bad game, let alone a finished game delivered and with all expectations met.

THE ENGINE
For some time now, even as they struggled to create a custom engine from CryEngine 3.x, I have followed their engineering challenges, failures, and successes over the years. We already knew that, as with all game engines, they were already building a custom game engine dubbed Star Engine; and which was based on CE3. This engine would be the core for both Star Citizen and Squadron 42. What we didn’t know until a few months ago, was that they had not only stopped taking CryEngine build updates from CryTek, but also that they had modified their base CE 3.7x by over 50% in coming up with their Star Engine derivative.
Part of their customization of the engine is in the increase of the game world size. At one point, they claimed that Star Engine was a “64-Bit engine” – something that is still written on their website features page. I first sounded the alarm that this was patently false; then subsequently wrote posts (1, 2) about it, as well as mentioning it in my Fidelity Of Failure blog. I had stated that not only was it shocking for them to even be doing that level of work, four years in, but also that there was simply no way they could create a 64-Bit custom engine, from a base engine like CryEngine which was 32-Bit. In the end, the narrative switched to “64-Bit positioning” which made more sense; though – as I wrote- they were still cheating regardless. And in the past few weeks, it has now emerged that – as I had stated then – they are actually using a 32*2 conversion aka “floating origin” in order to support the increase their world size. Note that they still haven’t even built a single star system to completion. So there is that.

Given the dearth of meaningful releases and progress this year, it came as no surprise that the 2.6 patch has been widely anticipated. Not only because Star Marine was back on the menu obviously due to legal liability (it was promised and promoted for years) issues, but because aside from being over six months late, the patch was supposed to contain a plethora of much needed fixes and revisions to Arena Commander and the PU.
Dealing with CryEngine which wasn’t designed for anything resembling the scope (especially in terms of world size, networking, open-world MMO structures etc) of Star Citizen vision 2.0 – at least not without extensive customization – has been an on-going challenge according to various past and present sources working on the project. Arguably, as most of us writing these massive games tend to do, developing an engine from the ground up (similar to what Frontier did with Elite Dangerous) would have been the more prudent way forward. But as we all now know, the original vision 1.0 of the game would have probably been farther along by now with some CE 3.x customization. But the more the scope of the game increased, so too did the requirements of the Star Engine. Which is precisely why – as of this writing – the game is still session + instanced based and has zero implementations for an MMO game; and certainly not with their target of 1000 client server games. Star Citizen itself – to date – isn’t even 15% of what was promised; and Squadron 42 is still unseen (as of this past Oct, sources were claiming that it doesn’t even exist as a game) in playable form.
There are various methods of building and maintaining an MMO game. Most MMO games use instances (copies of the game world with clients) which host a certain number of clients. Others use a whole server to represent a “persistent” world copy, while limiting the number of clients on the server. They are only similar in the sense that while several instances can be spawned on a single powerful server (or cluster of servers), the server cluster tends to limit the number of clients based on the power of the server itself.
For example:
#1 an MMO game can spawn a 16 client (aka players) instance01, an 8 client instance02, and a 4 client instance03. None of the players in any of these instances can ever meet, nor interact with other clients in the other instances. To add more players, the game just spawns new instances.
Depending on the game, player stats can also be saved on a server database so that when you join the game again, regardless of which instance you are spawned in, your stats are reloaded; then saved again when you quit.
Scaling (for more clients) a game like this involves either setting up additional hardware or cloud servers which then spawn the required instances. So e.g. if your instances can only support 16 clients, and you have 256 more players, then you have to spawn 16 more instances via either server or cloud sessions.
#2 Another MMO game can setup a server cluster which supports up to 32 clients (e.g. a combination of all the clients in the above instanced example); and all those clients can see and interact with each other because they are in the same world space.
As with instanced servers, depending on the game, player stats are saved and restored via a server database.
Scaling for this type of game requires setting up additional hardware servers depending on the capacity of the clients. And when clients desire to play on other servers, they either have to create new characters and/or accounts, or pay for a server switch. NOTE: In Line Of Defense, which isn’t instanced, our networking tech allows us to host a scene/world on a separate server, then dynamically and seamlessly transition clients between servers on-demand.
All things considered, session based games in which a group of players join a game, then when the game ends, they’re all kicked out as the game session is reset, are also a form of instancing. Which is precisely what the GameLift module in Lumberyard is and does.
Both of the above methods have their pros and cons, and each type is carefully chosen based on the game being developed. In terms of performance (visual + networking),  due to the sheer amount of networking data that needs to be passed between clients and the server (dedicated or not), twitch based games in the fps, flight and driving genres are the most difficult genres to develop in a MMO format. Especially if the goal is for an open world universe where all clients on the server can interact with each other at some level or another. In terms of visuals, games tend not to render (display) objects which are not within a certain vicinity of another player. This technique is also employed in some networking games whereby packet data is only sent to players within a certain range of each other.
In the MMO space, the Planetside games are the most famous twitch based games which have aerial, ground and fps combat. And even though they are designed to support up to 2000 clients per continent (the game has 3 continents) for a total of 6,000 (!) clients per server (the game is not instanced), in addition to culling visual and network data, they also use “population lock” techniques in order to keep those client numbers within those parameters. What this means is that if there are already 2000 clients in a continent, no additional clients can go to that continent unless and until the client count goes down due to clients leaving the server or moving to another continent.
As anyone who has played either of the two Planetside games can attest to, anything above 128 clients, tends to be a sub-par experience; especially in times where you have massive 50+ client battles in close proximity. In fact, here is a write-up of how/why they had to even limit these numbers for the PS4 version of the game which released earlier this year. Our own upcoming MMO game, Line Of Defense, which supports both MMO and session based multiplayer, also uses a similar multiplayer model as it is the most efficient, and gives the best of both worlds.
Developing multiplayer games is very complex. Developing MMO games is super complex. Developing twitch based MMO games is ultra complex.
Thinking about developing a twitch based MMO game, with a custom engine that uses a core engine that wasn’t designed for it? Well, as any CTO will attest to, you were fucked at “Hello World“. And that sums up Star Citizen. Which is precisely why currently all three (Arena Commander, Star Marine, PU) modules are a sub-par mess that struggle with anything more than 16 clients in an instance. Not to mention the fact that, up until they increased the scope of the game, it was never – ever – billed as an MMO. Says so right here and various public statements quoted in my blogs.
“Is Star Citizen an MMO?
No! Star Citizen will take the best of all possible worlds, ranging from a permanent, persistent world similar to those found in MMOs to an offline, single player campaign like those found in the Wing Commander series. The game will include the option for private servers, like Freelancer, and will offer plenty of opportunities for players who are interested in modding the content. Unlike many games, none of these aspects is an afterthought: they all combine to form the core of the Star Citizen experience.“
And they built their server instancing backend using Google Compute. Before I delve more into this, please read this response from 2014 by Chris Roberts to backer angst about having servers in Australia. Then read this response from 2015, again in response to Google Compute, and a good measure of DX12 (Star Engine is still DX11 btw) thrown in. And if you’re in the mood, watch this video interview in which he was talking about player hosted servers and how cloud computing takes that into account. Then there was that time when Chris was commenting on Shinra’s cloud computing implementation for games.
“Shinra’s business plan may be what really sets it apart, Roberts says. Shinra could achieve for a variety of games what Roberts’ company has built one game to accomplish.”
Some backers are of course confusing the Star Engine networking implementation – which as they know sucks – with the Compute powered server instancing backend. Thing is that it doesn’t matter how robust the server is, whether it is hardware or cloud based. What matters is the networking layer used by the game. If the layer sucks, that’s basically the end of that discussion. And that is precisely why – for over a year now – they have been touting an all new networking layer which is supposedly going to be capable of hosting 1000 client instances. Let me repeat that: 1000 client instances. For a twitch based combined arms game that’s supposed to have space and planetary combat in air/space craft, vehicles, fps. And be able to host client ships capable of carrying over 100 passengers. In a “persistent” universe. Here is what he said in an interview during the GamesCom this past August. “…thousands of players in the same area, all at the same time”
It’s all lies. And they aren’t even trying to hide the lies anymore. They just throw it all out there, knowing that some of the backers will just accept it and move on, even as the Shitizens continue to shout down any backers who question such things.
Here’s the thing; if by now at the end of year five (now going into six, but who’s counting?) they still haven’t even got that far yet into breaking the 16-24 client (note that 24 clients in Star Citizen instances, is akin to what happens with 50 clients in a Planetside session) barrier, releasing the new networking layer that’s going to be based on fairy dust and magic etc, what makes anyone think that it’s ever going to happen? It’s bad enough that right up to build 4.0 which Chris claims is coming in Q4/2017, there is now no mention of the magic networking layer; having been removed from all the recent talking points these past months.
THE SWITCH
A few months ago, there were some insider rumblings that due to on-going challenges of building the game that Chris Roberts envisioned, an engine switch was inevitable. I had discarded that out of hand, much like I discarded the recent talk of a console port of the game because let’s face it, this far along into development, it would be pure madness to make such a switch. Not to mention the furor that it will cause with the backers who, while entrenched in Sunk Cost Fallacy, are still throwing money into a burning fire. And when you think about it, short of a custom engine built from the ground up, even with their major advancements, Unity5 would be a stretch. Not to mention the fact that it’s C# based. So only Unreal Engine 4 is actually capable of building something like Star Citizen; even with some design compromises. And it would be a major re-write either way.
I had forgotten about the engine switch nonsense until it sparked up again earlier this year. Seeing as some people (who I don’t even know, due to sources being anon) have reportedly been fired from CIG/RSI for being sources to myself and the media (e.g. see Kotaku’s recent slew of Star Citizen research articles, or The Escapist article from last year), I tend to now pick and chose what I share publicly. And with very few people close to something like an engine switch, it would be trivial for CIG/RSI to go on a witch hunt to seek out who was leaking (the most open development ever!) information to backers and the general public.
So this past April, I made a comment as part of what I believed – at the time – would be madness for them to do. I said “I can’t wait to read the part where they decide to either port to Unity5 or to Lumberyard, Amazon’s version of CryEngine4. Not to mention CryEngine5 which is more advanced/modern than CryEngine4.”

With 2.6 already several months late, and still delayed this month amid lots of controversy; aside from the fact that 3.0 is the patch that was touted as coming this month, imagine my surprise when having released the buggy (just like the end-of-year 2.0 release in Dec 2015), 2.6 patch on Dec 23rd, some backers got wind of the Amazon Lumberyard engine logo in the game. All this time, such a fundamental and material change was neither mentioned in the release schedule, nor in the 2.6 patch notes.
Yup.
Like clockwork, the backer community was ablaze with all kinds of speculation. Just as things were about to reach fever pitch, CIG/RSI quickly pushed out a revised (you can tell because the just released 2.6 was mentioned in the “Top Stories This Week” section) newsletter mentioning it at the top. That section reads:

NOTE: There is speculation that he didn’t even write that, because shortly afterwards, a CIG community staff member, Zyloh, edited it, as seen in the top right part of the image.
With talk about an Amazon “partnership” (the term used by Chris Roberts) running rampant, Kotaku-UK were the only outlet that bothered to even seek clarification on what this actually meant. This is their update:
“Updated: I’ve had a response from CIG director of communications, David Swofford, to say that the relationship between CIG and Amazon is that of them being a regular licensee of Amazon’s technology. The reason for the announcement today was that it was turned on with the release of 2.6. He also confirmed that all the work CIG had done to expand the CryEngine has been transitioned to the new engine.“
Shortly after, another publication received a statement from Erin Roberts, brother of Chris Roberts and head of the Foundry 42 studio in the UK:
“Thanks for getting in touch. As you’ve (correctly) surmised, any suggestions that the engine switch would have a major impact on our development couldn’t be further from reality. Lumberyard is completely based on Cryengine, yet with a lot of improvements. As a consequence, we do not have to change the fundamental core engine at all which is why this change has had absolutely no effect on our development of Star Citizen.
The advantage of Lumberyard is that we get great ongoing support on the cloud / networking side from Amazon as well as great tools support while continuing uninterrupted development on what we have built up over the last 4 years. As we’ve tried to explain many times before, we have pretty much rewritten 50% of what we licensed 4 years ago now, even in core systems from Cryengine. What is great is that everything we have reworked, also now seamlessly integrates into Lumberyard, and the engine switch has not required any extra engineering time. We are actually very lucky that this opportunity presented itself to work with a powerful and committed company like Amazon that is investing heavily in its tech. This collaboration will effectively allow us to do more for our community going forward without costing us really anything in terms of engineering time or otherwise, so it is a win-win situation and good news all around.“
And in typical CIG/RSI fashion for revisionist history, burying dissent etc, a forum thread in which backers were speculating about switching to Lumberyard earlier this year, was deleted shortly after the news broke. Of course Goons saw that one coming and were able to archive the thread before it was deleted and merged into another thread in a bid to bury it. And sure enough, the Shillizens and Shitizens promptly proceeded to start altering the votes in order to skew the results in which 70% had previously voted no.

THE OBFUSCATION
Below is my blunt synopsis of what has now been written by Chris Roberts who, since the very start, has a storied history of blatantly lying to the very backers who, to date have given him all this money, while not having a game they paid for.
Amazon’s Lumberyard game engine, which was released free in Feb 2016, like the CIG/RSI Star Engine, is a custom engine built on top of CryEngine 3.x for which they acquired (1, 2, 3, 4) a license back in early 2015. What is still not clear is whether or not the license was for all versions of the CryEngine.  According to public and anon sources, what Amazon has is 99% CryEngine, but with some caveats. Also, whereas Amazon focused on improving the base engine, while implementing its own AWS and Twitch services in order to use their free CryEngine implementation to sell AWS services and ads via Twitch to game devs, the Star Engine customized version was focused on specific game elements for Star Citizen and Squadron 42.
Looking at the Lumberyard changelog it is easy to see the massive improvements and tweaks they have made to their custom implementation of CryEngine. Note that right off the bat with their first Beta release in Feb 2016, within one year of obtaining the license, they had already implemented support for both XBox One and PS4. And they now have VR support as well. Though it must be noted that all of this is in Beta still.
Now take a look at the changelog for CryEngine 3.x.
Statements from CIG/RSI in the past indicated that they stopped taking builds from CryTek back in late 2015. But without them being specific, it has been difficult to pinpoint precisely which version they last pulled from CryTek. One source had informed me that it may in fact have been 3.8.3 (Aug 2015). The last version that CE3 gen was released in Dec 2015. Note that CE4 was never released publicly; instead it was folded into what became the core of CE5.
Now also while we’re on the subject, this is a comment from Ben Parry, one of the devs, when asked about CE5. In fact, this is the second (the first was my mention in April 2016) time that Lumberyard was ever mentioned by any CIG/RSI dev in this context.
“Re: CryEngine 5, I’m not actually certain what the license situation is there, whether we’re 3.8.X only? 5 as well? Lumberyard? Obviously someone knows and I’d check before I started rooting around in the wrong codebase. When it comes to integrations, I’d imagine we’re past the point where we could click a button and then work through the conflicts, but doing that was always fraught with difficulty because it can (for example) introduce bugs in systems that haven’t officially been changed according to the release notes. While it’s more time consuming up front, it’s better to compare their old files to their new ones, make sure you understand them, then make the same changes to your own codebase. “
From the FAQ and changelogs, what Amazon have done with CE3 in order to create Lumberyard, is as mind-boggling as it is exhausting to read. For example:
“Q. Is Lumberyard based on CryEngine?
Lumberyard is made up of proven technology from CryEngine, AWS, Twitch, and Double Helix. We’ve hired some of the best game technologists in the world, who have already made over 996 additions, fixes, and improvements to Lumberyard. For example, we’ve integrated a brand new networking layer, GridMate, so your engineers can more easily build low-latency multiplayer games with large numbers of players. We’ve introduced Cloud Canvas, which enables your engineers and technical designers with little to no backend experience to build live online game features, such as community news feeds, sharing scores, and server-side combat resolution, in minutes using Lumberyard’s visual scripting system. We’ve also integrated Lumberyard with Amazon GameLift, so you can deploy, scale, and operate session-based multiplayer games. We’ve built a new component entity system so that you can easily populate and define the behaviors of the game world by creating entities and defining their behavior by adding components using drag-and-drop workflows in the Lumberyard Editor, and added a new code generation system to allow you to annotate your C++ code and generate the code you need. We’ve advanced the engine to include support for mobile devices, including support for Metal. We’ve created a new launcher and project configurator so your team can get set up without engineering help. We’ve also created new workflows so your artists can iterate faster and create higher-quality content, including a new particle effects editor, new FBX mesh importer, 2D/UI editor, and cross-platform asset pipeline. “
And they did all that in less than 18 months. Let that sink in.
So if CIG/RSI have modified CE3 by over 50% – which assuming it’s true (it’s probably false) is no mean feat btw – what exactly, besides 64-Bit positioning, could they have possibly done to for it be so heavily modified by 50%? As of this writing, there is absolutely nothing in any of the released Star Citizen game modules which would indicate such a drastic customization or improvement to the engine. Heck, especially when you consider that the game – according to CIG/RSI – is still in pre-Alpha stage!!! By all accounts, just looking at the Lumberyard changelog, it’s easy to see the drastic improvements that Amazon made since obtaining the 3.x license. And as of this writing, sources tell me that they have no intentions of adopting CE5 or later.
That said, so now we have a heavily modified CE3.x from both Amazon and CIG/RSI. And as a CTO level dev, I can safely say that it’s completely inconceivable that both of these dev teams have made exactly the same revisions (tweaks, fixes, improvements etc) to CE3.x, and to the extent that both engines are comparable to each other. Notwithstanding the fact that Lumberyard not only has support for both XBox One and PS4, but also according to Amazon execs, they implemented the networking layer from Double Helix; thus replacing the sub-par networking layer in CryEngine proper. And that networking layer btw, is still not suited for MMO games like the one CIG/RSI are aiming to build.
Now fast forward to Dec 23rd and CIG/RSI in the form of both Chris & Erin Roberts, are using words like “partnership” and “collaboration”. Then there’s this excerpt from Chris’s statement above:
“We stopped taking new builds from Crytek towards the end of 2015. So did Amazon. Because of this the core of the engine that we use is the same one that Amazon use and the switch was painless (I think it took us a day or so of two engineers on the engine team). What runs Star Citizen and Squadron 42 is our heavily modified version of the engine which we have dubbed StarEngine, just now our foundation is Lumberyard not CryEngine. None of our work was thrown away or modified. We switched the like for like parts of the engine from CryEngine to Lumberyard. All of our bespoke work from 64 bit precision, new rendering and planet tech, Item / Entity 2.0, Local Physics Grids, Zone System, Object Containers and so on were unaffected and remain unique to Star Citizen.“
In the above excerpt are three big Red flags in bold lettering. Given the facts of both engines, and the nature of game development in general, there isn’t a single game dev on this planet, who will look at those statements and find anything factual in them. There is simply no way on this God’s Earth that they switched from their core CE3 to the Lumberyard CE3 implementation, in two days, swapping like for like parts, while not throwing away or modifying their own CE3 implementation. I mean, seriously?
Then there’s this gem from the aforementioned press release:
“We’ve been working with Amazon for more than a year, as we have been looking for a technology leader to partner with for the long term future of Star Citizen and Squadron 42“
As these things go, quite a number of people are misinterpreting that to mean that they started this Lumberyard switch/integration a year ago. As expected, a very trusted source has informed me that it’s not the case. As written, the text is quite accurate in that “working with Amazon” doesn’t imply that they started this integration a year ago. Lest we forget that Chris then – following the press release – went on the record as saying it took all of two days to do. And on the face of it, if they were in fact doing this integration this entire year, then, for a project that keeps touting “open development”, they basically undertook a major technical effort in 2016 without ever disclosing it to backers. Not even once. In any of their dev updates, broadcasts, newsletters etc.
So no, they didn’t start doing this a year ago. They probably started looking into it, going back and forth with Amazon engineers, testing things out etc, before deciding to make the leap. That’s the same process that any studio looking at such a major shift would have done. And it won’t have taken a year of going back and forth; unless you were waiting for the right time to make the switch, while still evaluating Lumberyard, and the implications of such a switch.
Here’s the kicker. While I have yet to verify it myself, seeing as I am away on holiday and without access to my tools, others with access to both Lumberyard and Star Citizen 2.6, have confirmed and posted that the patch doesn’t appear to contain any of the Lumberyard runtime components. This implies that they haven’t switched from their core CE3 implementation to Lumberyard’s version at all. What has been confirmed is that they are no longer using Google Compute. Instead, they have switched to using some AWS services (e.g. EC2 which is the Compute equivalent) – a condition for using Lumberyard. So it’s safe to say that – as of the 2.6 patch at least – this transition is currently restricted to the switch from Compute to EC2; and quite possibly some internal copy pasta (due to them having the Lumberyard source code). Thing is, EC2 is a standalone component that’s part of AWS core – and you don’t need Lumberyard in order to use it.
— UPDATE —
Shortly after this blog went live, the link (start here) was posted on the Frontier Dev (makers of competing game, Elite Dangerous) forum where Ben Parry, a low-level Star Citizen visual effects programmer who used to work for Frontier, but now works for Foundry 42 (one of the CIG/RSI subsidiary companies in the UK), frequently posts. Taken to task over various inconsistencies in the CIG/RSI  explanation for the Star Engine to Lumberyard switch, his eventual meltdown (all captured to static images, seeing as they are likely to disappear) is an eye-opener, and further evidence as to just how messed up this whole project is now.
Basically, they can’t explain how it is possible for them to have merged a 50% modified derivative CE3.x (Star Engine) with a heavily modified derivative CE3.x (Lumberyard) in two days – and without losing any prior work. So he created a graphic to illustrate what he believes took place.

For the programmers reading this, yes, a programmer is claiming that what Chris Roberts wrote, is what happened. Then said programmer comes up with an illustration that proves otherwise. It needs no explanation, seeing as it clearly proves that they didn’t do any core Lumberyard integration – and especially not in two days. So basically, the claim to be using Lumberyard is currently restricted to basically the swap from Google Compute to Amazon EC2 (as abstracted in Lumberyard), as well as adding the required Lumberyard logo due to them using the Lumberyard implementation of EC2.
Further along the discussion, he finally admitted it.

Basically not only proving me right, but also – once again – proving that Chris Roberts is either a liar, or clueless as to what is actually going on with his project.
Ben also had this to say about Sean Tracy, the Technical Director for the project when someone pointed out that Ben is claiming that even Sean had no clue what CE3.x version they were actually using in Star Engine.
“Sean’s an artist, he doesn’t have much incentive to care about exact version numbers. Despite this, he’s basically right that it’s a branch of 3.7-3.8-ish, and he’s talking openly about it.”

Ben was last seen updating his resume.
After all is said and done, this was Ben’s stance on such an engine switch, back in Sept 2015. This was also pointed out to him in the discussion thread.

THE FUD SQUAD
There is no Amazon “partnership” or “collaboration”, Amazon didn’t pay them for this, nor buy their backer data list. And given the extensive amount of work that the Lumberyard team has done to CE3, I can’t think of any reason why they would even entertain a Quid Pro Quo by gaining access to Star Engine’s (an engine they somehow can’t even make a compelling FPS module out of, despite the core engine being designed specifically for that) modification. But these are some of the hilarious and ludicrous theories and speculations being offered by Shitizens and Shillizens who are – once again – shouting down backer dissent in an attempt to make light of the gravity of this engine switch.
So no, NONE of that is true. CIG/RSI are just a licensee (as they later verified to Kotaku UK), subject to the same licensing terms that those of us with access to Lumberyard, are bound by. Fact: it takes you all of 5 mins to become a Lumberyard licensee, partner, collaborator. For the record, yes, I have had several exchanges this year – including conference calls – with Lumberyard devs as we were also evaluating both Unreal Engine 4 and Lumberyard for our Line Of Defense console path, having lost our path in our own custom engine which is based on Havok suite of engines. Like Amazon did with Lumberyard, Havok too had bought (not licensed) a third-party game engine, Trinigy, and integrated their own tools and engines (Physics, Cloth, AI etc) into it, in order to have a full game engine suite. Microsoft later bought Havok.
So basically – in a nutshell – CIG/RSI traded one CryEngine licensor (CryTek) for another (Amazon). That’s it.
Seeing as there are currently no completed, let alone shipped Lumberyard games, nor any notable ones in development, I’m sure that Amazon would love to have a high profile project – even one with a tarnished rep as Star Citizen – associated with it. And using a game engine as a Trojan horse to sell AWS – their top earner – makes perfect sense in the general scheme of things. I mean, do you know how big each of the Star Citizen patches is, let alone the sheer amount of data they’re pushing when the game is running? It’s amazingly inefficient – which is precisely why, aside from planning to gut out the entire networking kernel – they’ve been talking about finally doing a game patcher. Now they don’t need to, because Lumberyard has done that work for them.
It should also be noted that the financial troubles going on with CryTek, have no bearing on CIG/RSI moving to Lumberyard; and they have gone on the record saying so. Seeing as they stopped taking builds from CryTek over a year ago, this should be obvious; but I think it still needs to be stated.
By all accounts, either they are currently working on the full switch to Lumberyard – which, given the massive undertaking – is going to take the better part of 2017 if you ask me – or this was a publicity stunt in order to use Amazon (a well regarded company, with world class devs and a stellar reputation) as part of the “confidence” game they’re playing as they continue to bilk backers for millions, without ever completing, let alone delivering on promises made back in 2012. Even looking at the wording they have used in these announcements and statements, the intent to leverage Amazon into that narrative is clear and present.
In addition to that, let’s play devil’s advocate again. If they have modified CE3 by 50%, and Star Engine modifications are on parity with Lumberyard to the extent that they could still keep all their modifications (e.g. Lumberyard currently has no implementation of 64-Bit positioning), then why do they need to switch? They don’t need Lumberyard in order to switch from Compute to EC2. So what they do need Lumberyard + AWS for are the following:
On-going updates to CE 3.x kernel
XBox One and PS4 support
VR support
DX12 support
Vulcan support
End user game modding support
End user private server support
Robust client patching support
I am hesitant to add EC2 here because Compute is comparatively priced; though Google traditionally keeps losing cloud business to Amazon due to infrastructure, robust implementation of cloud tech, and because well, for the most part, given the choice between Google and Amazon, my guess is Amazon will run out of tents to house defectors
Amazon devs doing most of the heavy lifting in on-going support for the engine; seeing as Chris Roberts has burned the bridge with CryTek
In order to gain access to most of the above, they have to either copy and paste Lumberyard implementation, throw away all their own Star Engine modifications, and adopt Lumberyard in its entirety, or adopt Lumberyard in its entirety, then merge in the important parts (localized physics grids, 64-Bit positioning, Scaleform etc) from Star Engine. You know the hilarious part? The thought that, after getting $140 million from backers, and stuck with a half-assed engine that’s never going to power the game Chris envisioned, those clowns are now going to toss most (keeping the 64-Bit positioning part is trivial; it’s not rocket science) of it out. Thus switching engines – five years later. And that rubbish about “I think it took us a day or so of two engineers on the engine team” is just that. Rubbish. They’re downplaying the implications of this because they know that no matter how optimistic you are, it’s just bad news. Period.
All of a sudden, those rumors of an inevitable console port aren’t looking so far-fetched now after all, are they?
The kicker in all this is that Lumberyard is still not going to help them build Star Citizen as an MMO; seeing as there is nothing in it that would give them that capability. An engine doesn’t give you a good game. A competent design and experienced team, gives you a good game. Not to mention all the reasons not to use AWS for these sort of games. And while it is possible that the Double Helix networking engine will probably help them with multiplayer in some regard, not only was it not designed for MMO games, but it’s also going to be a sizable undertaking if they choose to adopt it. Which – hilariously – means that all that ground-breaking networking they are no longer touting – is going to get ripped out.
Seriously, if you’re playing 2.6 right now, if you didn’t see the Lumberyard logo, or read about all this drama, would you have noticed anything different in terms of performance, let alone in networking? At all? Yeah, that’s because it’s all mostly the same Star Engine crap that’s in there. Hence all the same (and new) bugs, the same performance issues, the same networking issues etc. Some people will probably experience improved pings due to the move from Google Compute to Amazon EC2 cloud server clusters in their regions. Just ask this guy or go on YouTube right now and watch any number of videos from people playing 2.6. While you’re at it, did you hear that the 2.6 installer is likely to now stall; and the CIG/RSI recommended solution is to install a VPN in order to complete the download? I wish I was joking.
Regardless, as an Amazon stock holder – which means that Shitizens are now making me money through CIG/RSI paying for AWS – I am sure that the Amazon devs (they all came from the game dev industry proper) – who are probably reading this for the first time – can see precisely the sort of people that we’re dealing with. The narrative that CIG/RSI have now started promoting is likely going to be the same premise under which they have either cast other partners in a poor light, or made public statements which have allowed the toxic backers to attack third-party devs (e.g. the Illfonic guys who started developing Star Marine, CryTek etc) if they perceive them as being the cause of the project’s shortcomings. And it’s not like CIG/RSI are strangers to controversy with their partners, be it third-party studios, or companies like CryTek, AMD, Saitek etc. It never goes as expected; and all Chris Roberts does is talk the big talk, even as he rides the entire project, and millions of backer money directly into a furnace, while he along with family members and close friends (most from past failures), get rich doing it.
None of this matters anyway; the game is never getting finished, let alone as pitched. And if by some miracle (which seldom happens in video gaming; most especially if your game happens to make Wired’s vaporware game awards) something does get shoved out as final – sometime in 2020 or thereabouts – it’s still going to be an instanced mess of game that is going to be hard pressed to handle 32 clients (have fun flying around in your empty 100 player ships) per instance, let alone the “thousands in a persistent universe” that Chris has been touting since 2012.
While you’re at it, please, just watch this re-invent talk (also more on that here on AWS dev site) that Frontier, the developers of Elite Dangerous, gave about using AWS for their instanced game. And they built their game engine from scratch; and continued to improve on it so that it was capable of powering that game. Yet somehow these clowns who have seemingly scammed over $140 million from gullible backers, after five years in development, are making an engine switch, that’s somehow going to build something that nobody has ever done before in the history of MMO games. OK then.
And if you are thinking that at some point they’re probably going to end up selling the game to Amazon as some are now speculating; let me put it this way, I don’t believe there is a single entity that’s going to be willing to take on this huge liability after doing the due diligence that such deals require. And this is not like in the past whereby Chris Roberts has been saved more than once by publishers. The industry has changed, times have changed – and even the State and Fed officials have become very strict on companies that end up scamming consumers. Anyone even thinking of buying Star Citizen from CIG/RSI is going to inherit an incomprehensible world of hurt. Then there’s me.
The other side of this is that by moving to Lumberyard – assuming the transition gets completed in time – they are paving the way that makes it possible to dump the whole thing into the public domain and bailing. This is key because Chris Roberts even mentions people with Lumberyard experience in his recent statements. This despite the fact that very few devs are actually using it; favoring either Unity or Unreal Engine instead. In fact, now that I think about it, prepping to dump the game is a more plausible end-game scenario. They run out of money, then they dump the game. Since Lumberyard is free, the community can grab it and do what they want. Sounds crazy, right? Well, this is Star Citizen. Moving to Lumberyard also means that they can justify the rumored layoffs and downsizing that are coming; seeing as Amazon is going to be picking up the slack of doing all the base engine work – for free.
Aside from even more recent high profile exits from the project, something more is going down at CIG/RSI; and as I posted on social media back on Dec 15th, sources are saying all kinds of things; some of which I have yet to vet or verify with other sources.
Regardless of how this turns out, all we can do is wait and watch for what comes next. From what I’ve heard, it’s just as bad as doing an engine switch five years into a game’s development. Until then, we’ll just keep watching to see at which point backers (e.g. this recent $5K backer is out) making a run on the bank, stop getting refunds approved.

ALL STAR CITIZEN BLOGS
Share this:
EmailFacebook81TwitterPocket
Post navigation
One thought on “Star Citizen – Irreconcilable Differences”
Dsmart Dsmart says:
June 7, 2017 at 3:39 pm
Comment on this story
Comments are closed.
Copyright Derek Smart 2016
     
About /Account /Activate /Activity /Contact /Login /Logout /Members /Password Reset /Register /User

Design by Smartcat 

0%
 
10%
 
20%
 
30%
 
40%
 
50%
 
60%
 
70%
 
80%
 
90%
 
100%

Geänderter text

Datei öffnen

archive.today
webpage capture
Saved from	
http://dereksmart.com/2016/12/star-citizen-irreconcilable-differences/
history←priornext→
26 Jan 2020 19:40:41 UTC
All snapshots	from host dereksmart.com
WebpageScreenshot
sharedownload .zipreport error or abuse

Skip to content
Smart Speak
home
about
discuss

Star Citizen – Irreconcilable Differences
Star Citizen – Irreconcilable Differences
 December 27, 2016 by dsmart
 dsmart
 No comments yet
“Noun
Differences of opinion or will that cannot be brought into harmony, or cannot be brought into agreement through compromise.
A relationship that has become relentlessly hostile.”
The TL;DR recap on how I got involved in this farce

TRIPPING THE MEMORY LANE
With 2016 coming to a close, and arguably the most disastrous year for the Star Citizen development in terms of development & deliverables, PR & marketing, backer goodwill & dissent, legal ramifications, State & Federal involvement etc, it should come as no surprise that the most surprising (at least to those not paying attention) event was buried in an end of year update during the busy holiday period. In fact, while 2016 funding for the project is on track to exceed $35 (!) million by end of this month – regardless of the inaccuracy of the funding chart – it’s easy to see that the development pace and deliverables have not kept in line with the funding received. My previous Oct blog, Shattered Dreams, encapsulates the failures of 2016 in general, while shedding more light on how CIG/RSI has treated backers worse than a publisher would a developer.
But let’s back up a bit here, and take a trip down memory lane.
Back in July 2015, I wrote a highly controversial blog, Interstellar Citizens, about the project, it set off a chain reaction of events which led to an all-out war between hardcore backers of the project, paid marketing shills (Shillizens), the anti-social misfit backers (Shitizens) who are raging a war of attrition against dissent, and well, everyone else with a brain which has concluded that the project is a catastrophe. In that blog, and several others which followed, I had maintained – consistently – that the game as pitched could never be built, not only due to the engine they chose, CryEngine 3 (aka CE3) and which was unsuited for the increased scope of the game, but as I also pointed out that even if they somehow managed to find people with the talent and expertise to pull it off, coupled with a robust custom engine, that it would still be a major undertaking and not likely to cost anything less than $150 million.
As of this writing, at the end of project’s five year (if you are counting 2011 during which Chris Roberts stated the game was already in development) anniversary, the project is not only two years late, but has also raised over $140 million in funding through the most devious of fundraising schemes ever seen in gaming; even as the technical debt and lies continue to pile up.

Given the dearth of meaningful releases and progress this year, it came as no surprise that the 2.6 patch has been widely anticipated. Not only because Star Marine was back on the menu obviously due to legal liability (it was promised and promoted for years) issues, but because aside from being over six months late, the patch was supposed to contain a plethora of much needed fixes and revisions to Arena Commander and the PU.
Dealing with CryEngine which wasn’t designed for anything resembling the scope (especially in terms of world size, networking, open-world MMO structures etc) of Star Citizen vision 2.0 – at least not without extensive customization – has been an on-going challenge according to various past and present sources working on the project. Arguably, as most of us writing these massive games tend to do, developing an engine from the ground up (similar to what Frontier did with Elite Dangerous) would have been the more prudent way forward. But as we all now know, the original vision 1.0 of the game would have probably been farther along by now with some CE 3.x customization. But the more the scope of the game increased, so too did the requirements of the Star Engine. Which is precisely why – as of this writing – the game is still session + instanced based and has zero implementations for an MMO game; and certainly not with their target of 1000 client server games. Star Citizen itself – to date – isn’t even 15% of what was promised; and Squadron 42 is still unseen (as of this past Oct, sources were claiming that it doesn’t even exist as a game) in playable form.
There are various methods of building and maintaining an MMO game. Most MMO games use instances (copies of the game world with clients) which host a certain number of clients. Others use a whole server to represent a “persistent” world copy, while limiting the number of clients on the server. They are only similar in the sense that while several instances can be spawned on a single powerful server (or cluster of servers), the server cluster tends to limit the number of clients based on the power of the server itself.
For example:
#1 an MMO game can spawn a 16 client (aka players) instance01, an 8 client instance02, and a 4 client instance03. None of the players in any of these instances can ever meet, nor interact with other clients in the other instances. To add more players, the game just spawns new instances.
Depending on the game, player stats can also be saved on a server database so that when you join the game again, regardless of which instance you are spawned in, your stats are reloaded; then saved again when you quit.
Scaling (for more clients) a game like this involves either setting up additional hardware or cloud servers which then spawn the required instances. So e.g. if your instances can only support 16 clients, and you have 256 more players, then you have to spawn 16 more instances via either server or cloud sessions.
#2 Another MMO game can setup a server cluster which supports up to 32 clients (e.g. a combination of all the clients in the above instanced example); and all those clients can see and interact with each other because they are in the same world space.
As with instanced servers, depending on the game, player stats are saved and restored via a server database.
Scaling for this type of game requires setting up additional hardware servers depending on the capacity of the clients. And when clients desire to play on other servers, they either have to create new characters and/or accounts, or pay for a server switch. NOTE: In Line Of Defense, which isn’t instanced, our networking tech allows us to host a scene/world on a separate server, then dynamically and seamlessly transition clients between servers on-demand.
All things considered, session based games in which a group of players join a game, then when the game ends, they’re all kicked out as the game session is reset, are also a form of instancing. Which is precisely what the GameLift module in Lumberyard is and does.
Both of the above methods have their pros and cons, and each type is carefully chosen based on the game being developed. In terms of performance (visual + networking),  due to the sheer amount of networking data that needs to be passed between clients and the server (dedicated or not), twitch based games in the fps, flight and driving genres are the most difficult genres to develop in a MMO format. Especially if the goal is for an open world universe where all clients on the server can interact with each other at some level or another. In terms of visuals, games tend not to render (display) objects which are not within a certain vicinity of another player. This technique is also employed in some networking games whereby packet data is only sent to players within a certain range of each other.
In the MMO space, the Planetside games are the most famous twitch based games which have aerial, ground and fps combat. And even though they are designed to support up to 2000 clients per continent (the game has 3 continents) for a total of 6,000 (!) clients per server (the game is not instanced), in addition to culling visual and network data, they also use “population lock” techniques in order to keep those client numbers within those parameters. What this means is that if there are already 2000 clients in a continent, no additional clients can go to that continent unless and until the client count goes down due to clients leaving the server or moving to another continent.
As anyone who has played either of the two Planetside games can attest to, anything above 128 clients, tends to be a sub-par experience; especially in times where you have massive 50+ client battles in close proximity. In fact, here is a write-up of how/why they had to even limit these numbers for the PS4 version of the game which released earlier this year. Our own upcoming MMO game, Line Of Defense, which supports both MMO and session based multiplayer, also uses a similar multiplayer model as it is the most efficient, and gives the best of both worlds.
Developing multiplayer games is very complex. Developing MMO games is super complex. Developing twitch based MMO games is ultra complex.
Thinking about developing a twitch based MMO game, with a custom engine that uses a core engine that wasn’t designed for it? Well, as any CTO will attest to, you were fucked at “Hello World“. And that sums up Star Citizen. Which is precisely why currently all three (Arena Commander, Star Marine, PU) modules are a sub-par mess that struggle with anything more than 16 clients in an instance. Not to mention the fact that, up until they increased the scope of the game, it was never – ever – billed as an MMO. Says so right here and various public statements quoted in my blogs.
“Is Star Citizen an MMO?
No! Star Citizen will take the best of all possible worlds, ranging from a permanent, persistent world similar to those found in MMOs to an offline, single player campaign like those found in the Wing Commander series. The game will include the option for private servers, like Freelancer, and will offer plenty of opportunities for players who are interested in modding the content. Unlike many games, none of these aspects is an afterthought: they all combine to form the core of the Star Citizen experience.“
And they built their server instancing backend using Google Compute. Before I delve more into this, please read this response from 2014 by Chris Roberts to backer angst about having servers in Australia. Then read this response from 2015, again in response to Google Compute, and a good measure of DX12 (Star Engine is still DX11 btw) thrown in. And if you’re in the mood, watch this video interview in which he was talking about player hosted servers and how cloud computing takes that into account. Then there was that time when Chris was commenting on Shinra’s cloud computing implementation for games.
“Shinra’s business plan may be what really sets it apart, Roberts says. Shinra could achieve for a variety of games what Roberts’ company has built one game to accomplish.”
Some backers are of course confusing the Star Engine networking implementation – which as they know sucks – with the Compute powered server instancing backend. Thing is that it doesn’t matter how robust the server is, whether it is hardware or cloud based. What matters is the networking layer used by the game. If the layer sucks, that’s basically the end of that discussion. And that is precisely why – for over a year now – they have been touting an all new networking layer which is supposedly going to be capable of hosting 1000 client instances. Let me repeat that: 1000 client instances. For a twitch based combined arms game that’s supposed to have space and planetary combat in air/space craft, vehicles, fps. And be able to host client ships capable of carrying over 100 passengers. In a “persistent” universe. Here is what he said in an interview during the GamesCom this past August. “…thousands of players in the same area, all at the same time”
It’s all lies. And they aren’t even trying to hide the lies anymore. They just throw it all out there, knowing that some of the backers will just accept it and move on, even as the Shitizens continue to shout down any backers who question such things.
Here’s the thing; if by now at the end of year five (now going into six, but who’s counting?) they still haven’t even got that far yet into breaking the 16-24 client (note that 24 clients in Star Citizen instances, is akin to what happens with 50 clients in a Planetside session) barrier, releasing the new networking layer that’s going to be based on fairy dust and magic etc, what makes anyone think that it’s ever going to happen? It’s bad enough that right up to build 4.0 which Chris claims is coming in Q4/2017, there is now no mention of the magic networking layer; having been removed from all the recent talking points these past months.
THE SWITCH
A few months ago, there were some insider rumblings that due to on-going challenges of building the game that Chris Roberts envisioned, an engine switch was inevitable. I had discarded that out of hand, much like I discarded the recent talk of a console port of the game because let’s face it, this far along into development, it would be pure madness to make such a switch. Not to mention the furor that it will cause with the backers who, while entrenched in Sunk Cost Fallacy, are still throwing money into a burning fire. And when you think about it, short of a custom engine built from the ground up, even with their major advancements, Unity5 would be a stretch. Not to mention the fact that it’s C# based. So only Unreal Engine 4 is actually capable of building something like Star Citizen; even with some design compromises. And it would be a major re-write either way.
Despite at least two sources claiming they were in fact switching to Lumberyard, I had forgotten about the engine switch nonsense until it sparked up again earlier this year. Seeing as some people (who I don’t even know, due to sources being anon) have reportedly been fired from CIG/RSI for being sources to myself and the media (e.g. see Kotaku’s recent slew of Star Citizen research articles, or The Escapist article from last year), I tend to now pick and chose what I share publicly. And with very few people close to something like an engine switch, it would be trivial for CIG/RSI to go on a witch hunt to seek out who was leaking (the most open development ever!) information to backers and the general public. So, my stance is that I’ll believe it when I hear more. I mean, with all their show broadcasts, no way they would keep something like that quiet, unless they are concerned about backer reaction.
In fact, this past April, I made a comment as part of what I believed – at the time – would be madness for them to even do. I said “I can’t wait to read the part where they decide to either port to Unity5 or to Lumberyard, Amazon’s version of CryEngine4. Not to mention CryEngine5 which is more advanced/modern than CryEngine4.”

With 2.6 already several months late, and still delayed this month amid lots of controversy; aside from the fact that 3.0 is the patch that was touted as coming this month, imagine my surprise when having released the buggy (just like the end-of-year 2.0 release in Dec 2015), 2.6 patch on Dec 23rd, some backers got wind of the Amazon Lumberyard engine logo in the game following my flurry of Tweets which confirmed they were using it. All this time, such a fundamental and material change was neither mentioned in the release schedule, nor in the 2.6 patch notes.
Yup.
Like clockwork, the backer community was ablaze with all kinds of speculation. Just as things were about to reach fever pitch, CIG/RSI quickly pushed out a revised (you can tell because the just released 2.6 was mentioned in the “Top Stories This Week” section) newsletter mentioning it at the top. That section reads:

Ben was last seen updating his resume.
After all is said and done, this was Ben’s stance on such an engine switch, back in Sept 2015. This was also pointed out to him in the discussion thread.

ALL STAR CITIZEN BLOGS
Share this:
EmailFacebookTwitterPocket
Post navigation
Light Reading…
Battlecruiser 3000AD - 22yrs Ago
Line Of Defense - The Road Ahead
Battlecruiser 3000AD - The Legacy
Society Of Professional Journalists - Gamergate Debate
Star Citizen - How I Got Involved
Derek Smart - The Gaming Urban Legend
Polygon - The Redemption Of Derek Smart
Hyper - Derek Smart On Social Media Battleground
Archives
Archives
Star Citizen News
Star Citizen Blogs
Star Citizen Musings
Star Citizen Scoops
Join The Discussions
Forums
EFF Bloggers Rights
Copyright Derek Smart 2018
     
About /Account /Activate /Activity /Contact /Login /Logout /Members /Password Reset /Register /User

Design by Smartcat 

0%
 
10%
 
20%
 
30%
 
40%
 
50%
 
60%
 
70%
 
80%
 
90%
 
100%

Words removed	78
Total words	4355
Words removed (%)	1.79

Words added	72
Total words	4349
Words added (%)	1.66