Star Citizen - The E.L.E.

[Motto]

Sorry, my bad in explaining the humor. Maybe it wasn't that obvious to others as I thought it was (and English isn't my native language).

Don't read it as a review of ME:A, but read it as if someone tried to do a copy of SC in it's current state. The similarities are amazing then. That's what I meant by "if you read it the right way". 

[dsmart]

Sorry, my bad in explaining the humor. Maybe it wasn't that obvious to others as I thought it was (and English isn't my native language).

Don't read it as a review of ME:A, but read it as if someone tried to do a copy of SC in it's current state. The similarities are amazing then. That's what I meant by "if you read it the right way".

Yeah, I understood what you meant. Which made the whole thing even more hilarious.  :smuggo:

[Narrenbart]

The Agent (https://forums.somethingawful.com/showthread.php?threadid=3800238&userid=0&perpage=40&pagenumber=832#post470635538)

What we are rolling out now is a complete rewrite of core and branched systems. It has nothing to do with Lumberyard integration. Early 2016 the decision was made to scrap almost our entire codebase and start anew. Whilst this means years of potential new coding, our animation and art teams have continued to refine and refactor. What they produce now is purely and simply momentous. No other studio has the capacity for such amazing work. There has been thousands of custom animations and facial expressions that rival the top Hollywood computer graphics companies.

Then what is heading back to redesign? I used refactor the correct way, before I get poo poo for that. Everything you see currently is gone. 2.6 no longer exists. The beta we are getting out this year, and I mean this year, is a total rebuild -- not refactor, har -- of code. Flight models, first person feel, networking, persistence, items; all of what's in 2.6 is completely gone.

The foundations and creative tools for new content are in place are nearly complete. They are decades ahead of what other companies have, even AAA studios. Chris bet big on big ideas and now our entire team is starting to see that investment pay off.

I'm not afraid to say 2020 or later is release. I'm unafraid because our backers are unafraid; every single one of them continue to walk-the-walk and not just talk-the-talk. Chris made the right call to wipe out what was previously in place. Things were too fractured; now everything is under one house, one rule, one idea. No more outsourcing. No more wondering what company added or subtracted.

Beta is a turning point for the entire project. I won't comment on Amazon. The air here is different. The feel of the company is different. Progress, rapid progress, is being made now, more than ever before. Designers are putting in systems and testing them within the same week. If I can sum up in one word what we all feel: joy. To not only be a part of this project but to truly go where no one has gone before.

You don't post positives, not from what I've seen. Maybe this will be different.

It would be hilarious if this renders to be true and not only sarcasm by The Agent.
Basically it means millions of man hours down the drain.

Dear Backers, we have started over, please donate again cause well we wasted 100Mil Dollars to learn it the hard way.
But good news everyone, the facial animations look pretty good and we have some good toolsets ... after 6 years ...

[Scruffpuff]

It's just TheAgent taking the piss.  Indications:

- 2 separate claims directly referencing Chris's "vision" (wiping out old code, betting on "big ideas" - the kinds of decisions actual developers make every day)

- The claim that the studio is "decades ahead" of other studios - a literal impossibility without a time machine, since every developer in the world has been butting up against current hardware limitations since gaming began

- "No other studio has the capacity for such amazing work" - provably false, since CIG has bled all but the bottom-of-the-barrel talent - nearly every other studio is superior to CIG in nearly every way

- "animations and facial expressions that rival the top Hollywood computer graphics companies." - This one sealed the deal for me that this was a fake post.  "Hollywood Computer Graphics Companies" is not what any game developer would call CGI workshops - ever.  "Hollywood" has nothing to do with CGI.  They use it, sure - but they aren't the best, nor do they represent a high water mark for quality.  This is a callout to the common belief that Chris Roberts is simply trying to get back into Hollywood.

[AlsoSmart]

The Agent (https://forums.somethingawful.com/showthread.php?threadid=3800238&userid=0&perpage=40&pagenumber=832#post470635538)

What we are rolling out now is a complete rewrite of core and branched systems. It has nothing to do with Lumberyard integration. Early 2016 the decision was made to scrap almost our entire codebase and start anew. Whilst this means years of potential new coding, our animation and art teams have continued to refine and refactor. What they produce now is purely and simply momentous. No other studio has the capacity for such amazing work. There has been thousands of custom animations and facial expressions that rival the top Hollywood computer graphics companies.

Then what is heading back to redesign? I used refactor the correct way, before I get poo poo for that. Everything you see currently is gone. 2.6 no longer exists. The beta we are getting out this year, and I mean this year, is a total rebuild -- not refactor, har -- of code. Flight models, first person feel, networking, persistence, items; all of what's in 2.6 is completely gone.

The foundations and creative tools for new content are in place are nearly complete. They are decades ahead of what other companies have, even AAA studios. Chris bet big on big ideas and now our entire team is starting to see that investment pay off.

I'm not afraid to say 2020 or later is release. I'm unafraid because our backers are unafraid; every single one of them continue to walk-the-walk and not just talk-the-talk. Chris made the right call to wipe out what was previously in place. Things were too fractured; now everything is under one house, one rule, one idea. No more outsourcing. No more wondering what company added or subtracted.

Beta is a turning point for the entire project. I won't comment on Amazon. The air here is different. The feel of the company is different. Progress, rapid progress, is being made now, more than ever before. Designers are putting in systems and testing them within the same week. If I can sum up in one word what we all feel: joy. To not only be a part of this project but to truly go where no one has gone before.

You don't post positives, not from what I've seen. Maybe this will be different.

If this is just even partly true then  :lol:

But the best part from a psychologycal/rhetorical point is IMO:
"I'm not afraid to say 2020 or later is release. I'm unafraid because our backers are unafraid; every single one of them continue to walk-the-walk and not just talk-the-talk. "

[Narrenbart]

It's just TheAgent taking the piss. [...]

most likely this ^ :)
But if true we've got a 2nd DNF

[dsmart]

It's just TheAgent taking the piss.  Indications:

Yeah, most definitely the case. I mentioned that on Discord last night. It's hilarious.  :lol:

[dsmart]

Alpha 2.3 was released exactly one year ago today.

Meanwhile, 2.6.2 just went to Evocati.

[dsmart]

https://www.reddit.com/r/starcitizen/comments/62tbtw/hype_and_reality_check_27_patch/dfp63xn/

So say we all...

I've gone from: kickstart backer -> avid fan -> optimistic -> pessimistic -> I now shit on the game whenever I can and tell people not to buy it, IF it happens...sure pick up a small package..but don't touch it until then.
You probably think I'm being harsh.. But when I backed this game I didn't even know I was going to have a 2nd kid, my 2nd kid is now turning 4 in a few weeks... and he'll probably be 8 or 9 before the game is in a "released" state.. That is unacceptable IMO, even for a "ground breaking blah blah blah"

[dsmart]

LOL!! this is great

Unpacking why SC is doomed from a technical perspective is conveniently (for chris roberts) very tough because it's extremely hard to get people's attentions long enough to elaborate on why making games is hard and you can't just ideas-guy development teams into doing the impossible. let's try to break Star Citizen down by starting from the abstract:

game engines are, at their core, real time operating systems (RTOS)

you have disparate systems that need to be scheduled, informed of things like user input or network activity, share state + somehow send messages to each other (or, more dangerously, directly reference each other), be maintained to respect logical contracts etc. there's not a lot of shortcuts you can take between these systems without introducing serious consequences to your runtime stability or overall code maintainability, you need to design it Right™ and early and not let it slip when other people start helping you maintain/grow the engine.

the above outlines the overall concepts an "engine developer" has to maintain and grapple with. this is explicitly distinct from a "game developer" which I'll outline next.

engine development is all very complicated and often way more brittle than you expect. How many "complete" racing games have you seen on the Source engine compared to FPS games? The answer is obvious and influenced strongly by the products the original engine developers were aiming for. Some engines, like Unity, have done a great job at not being married to any one framework of gameplay but that ultimately results in a larger conceptual gap that a "game developer" might need to fill if they aren't an experienced "engine" developer or aren't good at building their own operating frameworks for the kind of game they want to make. In something like Unity there's no built in concept of guns or inventory or reticles or chat systems or existing game-like behavior. unity bridges this gap a bit with an asset store but then you are banging differently shaped puzzle pieces made by strangers together that might not fit nicely

The following are questions you need to answer and grasp the implications of when making any game and picking an engine that will suit your development style: first person? racing? strategy? turn based? multiplayer? single player? local multiplayer? physics a part of the gameplay or just aesthetic? persistent centralized accounts (ie: an MMO or something like it)? ad hoc p2p player servers? the list goes on, but you need answers to every question you can think of that is a core component of your game.

The answers to these questions will influence what kinds of problems you're signing yourself up to solve. If I know I'm making a 20 player arena based FPS shooter, I might as well go with UDK because out of the box it has templates and a lot of community discussion surrounding making FPS games and it has a history of being for that, the engine will present low friction for this problem set. If I try to make an FPS game in game maker or from scratch in C++, I'm going to be miserable and have to basically reinvent every single wheel.

Every system your game needs, that your engine may or may not make easy on you, needs to interact well with its dependent systems & providers at run-time and also be maintainable and ideally compartmentalized, you don't want to realize half way through development that upgrading your engine to the latest upstream (which comes with features you've been begging for) will break literally everything because you were coding around undocumented potentially-is-actually-a-bug behavior in the engine because you didn't really grok the intent outlined in the documentation and naively code-bashed your way into a solution. developers in all software need to develop a 6th sense for what "smells bad" when trying to make a framework do something it wasn't meant for, leading you to overarchitect some things in some cases, but also make extreme but convenient and well-weighed short-cuts in others. this specific skill along with the ability to set expectations reasonably (  ) is at the crux of being a good software developer.

Realistically it is impossible to design perfect game systems in a vacuum that you can plug and play together with any sort of configuration, there's always a compromise or some sort of edge case you're introducing with other systems and you end up having to write a bunch of special edge case marshalling to do things like: translate between one spacial system to another, or have one set of physics objects follow one set of rules while another set of physics objects follows another. and the way you implement these systems will concrete you into behavior that will exclude other potentialities for designs in the game.

Now let's talk about Crytek and Cryengine. Cryengine specifically set out to solve one very specific set of problems in game development: rendering huge amounts of space & geography efficiently and having such large space also work sanely in multiplayer. This made it naturally suited for cool homebrew games like Mechwarrior: Living Legends. The engine already had existing frameworks for things such as controlling vehicles, rendering day/night cycles, complex shader techniques for mapping textures onto bump maps in a way that doesn't stretch, conveniences in the editor for editing large amounts of geometry and placing & rendering roads (entire white papers exist for rendering/editing roads sanely in bump-map engines lol).

That said, it's clear why at first glance Cryengine seemed like a good fit for SC, you have huge swathes of space as a game problem you need to solve, lo and behold Cryengine offers a partial solution at first glance. Cryengine also featured some zero-g segments at times, which I'm sure made Chris Robert's eyes pop out of his fucking sockets on one of his major coke fueled gaming benders in a sad poorly furnished mcmansion somewhere.

It's not insanely difficult, if you have any game programming experience, to hop into an engine like Cryengine and start prototyping some things. Let's create a blank level, let's make the skybox be a nice starry sky texture, let's set gravity to 0, let's subclass the vehicle class and drop in one of our models. The engine is very low friction for this hello world smoke test. So you start flying around in your shitty 3d mesh and are feeling like a programming/game development god, zooming around thinking "Wow this is gonna be EASY", then you fly to far down on the Y axis and start drowning. "what the fuck" you whisper as you squint. It's too late though, your boss, Chris Roberts, saw this early smoke test of assets and quickly started drafting up earnest estimates on how long OTHER systems will take, as if the demo you threw together is actually complete (when it's not). If you dont know how to hire devs you might put a senior dev in place who also doesn't grok how much actual work is left to be done and enforces your boss' stupid promises based on what isn't real game development. Guns are now pointed at you to fix the "small" issue or you'll be holding up the schedule (that no one consulted you about). so you work a weekend and dive into wtf happens when Y axis < CRY_WATER_LINE_HEIGHT. You find an instance in the base player controller logic and fix it, thinking you're done, but -- fuck it turns out the physics subsystem also uses that same CRY_WATER_LINE_HEIGHT constant to do some optimizations, so you start grepping the code for that code instance and try flipping it off, except you don't realize there are some extra subsystems hidden somewhere that don't reference that constant like they should also do their own weird rendering tricks or optimizations when Y approaches that magic value.

there's a phrase in software development and especially games: 90% of the time is spent on the last 10% of polish. the last mile problem is super fucking real in gamedev, seemingly tiny things in the grand scope of what you're delivering can make or break your game experience for players, and it's always those "tiny" things that are the results of weird edge cases from literally hundreds of subsystems interacting with eachother through the engine.

now, take the water example and apply it to basically everything. most likely every single system in cryengine has some kind of limit to what it was built to do originally and there are always unexpected results when you push engines into territory they werent developed for or tested for. now if you consider how Chris is pushing people to ship shitty demos and move on instead of developing a strong foundation for the rest of the game: you start to imagine how one could half ass a system for an effect in demo and how "ok but it wont work outside of this or with any of the other things we talked about" might fall on deaf ears to a demonstrable cant-actually-delegate-or-listen-to-reason dingus like CRoberts.

now i want to introduce the final nail in the coffin. I could write like an essay on the basic MMO problem space but I wont, i'll keep it simple: MMOs are one of the hardest possible problems to tackle in a game development context from a resource management perspective. the amount of resource expertise (developers, architects, planning) and continued cost of servers and CPU/network time are as big as it gets in game development, and not only that but your game needs to be architected incredibly precisely to fit into the featureset your MMO imagination describes. you really can spare no unnecessary complexity when attempting an MMO, your scope needs to be VERY specific for your first release (  )

Even on a basic employee headcount level, Star Citizen doesn't employ nearly the number of experienced developers required for a project of this size, not only that but we all have plenty of evidence as to CRobert's awful management styles given how many rewrites and "refactors" occur for even the existing unfinished systems. there are clear, glaring signs of bad software development planning and inexperienced game developers rushing a product (while senior ones seem to keep leaving , weird!! ).

absolutely none of this is conducive to shipping the PU as shitizens imagine. they will never see their game. making games is really complicated, making multiplayer games is even MORE complicated, making MASSIVELY multiplayer games is THE most resource intensive & complicated from a project management perspective.

[Phraccy]

LOL!! this is great

Unpacking why SC is doomed from a technical perspective is conveniently (for chris roberts) very tough because it's extremely hard to get people's attentions long enough to elaborate on why making games is hard and you can't just ideas-guy development teams into doing the impossible. let's try to break Star Citizen down by starting from the abstract:

game engines are, at their core, real time operating systems (RTOS)

you have disparate systems that need to be scheduled, informed of things like user input or network activity, share state + somehow send messages to each other (or, more dangerously, directly reference each other), be maintained to respect logical contracts etc. there's not a lot of shortcuts you can take between these systems without introducing serious consequences to your runtime stability or overall code maintainability, you need to design it Right™ and early and not let it slip when other people start helping you maintain/grow the engine.

the above outlines the overall concepts an "engine developer" has to maintain and grapple with. this is explicitly distinct from a "game developer" which I'll outline next.

engine development is all very complicated and often way more brittle than you expect. How many "complete" racing games have you seen on the Source engine compared to FPS games? The answer is obvious and influenced strongly by the products the original engine developers were aiming for. Some engines, like Unity, have done a great job at not being married to any one framework of gameplay but that ultimately results in a larger conceptual gap that a "game developer" might need to fill if they aren't an experienced "engine" developer or aren't good at building their own operating frameworks for the kind of game they want to make. In something like Unity there's no built in concept of guns or inventory or reticles or chat systems or existing game-like behavior. unity bridges this gap a bit with an asset store but then you are banging differently shaped puzzle pieces made by strangers together that might not fit nicely

The following are questions you need to answer and grasp the implications of when making any game and picking an engine that will suit your development style: first person? racing? strategy? turn based? multiplayer? single player? local multiplayer? physics a part of the gameplay or just aesthetic? persistent centralized accounts (ie: an MMO or something like it)? ad hoc p2p player servers? the list goes on, but you need answers to every question you can think of that is a core component of your game.

The answers to these questions will influence what kinds of problems you're signing yourself up to solve. If I know I'm making a 20 player arena based FPS shooter, I might as well go with UDK because out of the box it has templates and a lot of community discussion surrounding making FPS games and it has a history of being for that, the engine will present low friction for this problem set. If I try to make an FPS game in game maker or from scratch in C++, I'm going to be miserable and have to basically reinvent every single wheel.

Every system your game needs, that your engine may or may not make easy on you, needs to interact well with its dependent systems & providers at run-time and also be maintainable and ideally compartmentalized, you don't want to realize half way through development that upgrading your engine to the latest upstream (which comes with features you've been begging for) will break literally everything because you were coding around undocumented potentially-is-actually-a-bug behavior in the engine because you didn't really grok the intent outlined in the documentation and naively code-bashed your way into a solution. developers in all software need to develop a 6th sense for what "smells bad" when trying to make a framework do something it wasn't meant for, leading you to overarchitect some things in some cases, but also make extreme but convenient and well-weighed short-cuts in others. this specific skill along with the ability to set expectations reasonably (  ) is at the crux of being a good software developer.

Realistically it is impossible to design perfect game systems in a vacuum that you can plug and play together with any sort of configuration, there's always a compromise or some sort of edge case you're introducing with other systems and you end up having to write a bunch of special edge case marshalling to do things like: translate between one spacial system to another, or have one set of physics objects follow one set of rules while another set of physics objects follows another. and the way you implement these systems will concrete you into behavior that will exclude other potentialities for designs in the game.

Now let's talk about Crytek and Cryengine. Cryengine specifically set out to solve one very specific set of problems in game development: rendering huge amounts of space & geography efficiently and having such large space also work sanely in multiplayer. This made it naturally suited for cool homebrew games like Mechwarrior: Living Legends. The engine already had existing frameworks for things such as controlling vehicles, rendering day/night cycles, complex shader techniques for mapping textures onto bump maps in a way that doesn't stretch, conveniences in the editor for editing large amounts of geometry and placing & rendering roads (entire white papers exist for rendering/editing roads sanely in bump-map engines lol).

That said, it's clear why at first glance Cryengine seemed like a good fit for SC, you have huge swathes of space as a game problem you need to solve, lo and behold Cryengine offers a partial solution at first glance. Cryengine also featured some zero-g segments at times, which I'm sure made Chris Robert's eyes pop out of his fucking sockets on one of his major coke fueled gaming benders in a sad poorly furnished mcmansion somewhere.

It's not insanely difficult, if you have any game programming experience, to hop into an engine like Cryengine and start prototyping some things. Let's create a blank level, let's make the skybox be a nice starry sky texture, let's set gravity to 0, let's subclass the vehicle class and drop in one of our models. The engine is very low friction for this hello world smoke test. So you start flying around in your shitty 3d mesh and are feeling like a programming/game development god, zooming around thinking "Wow this is gonna be EASY", then you fly to far down on the Y axis and start drowning. "what the fuck" you whisper as you squint. It's too late though, your boss, Chris Roberts, saw this early smoke test of assets and quickly started drafting up earnest estimates on how long OTHER systems will take, as if the demo you threw together is actually complete (when it's not). If you dont know how to hire devs you might put a senior dev in place who also doesn't grok how much actual work is left to be done and enforces your boss' stupid promises based on what isn't real game development. Guns are now pointed at you to fix the "small" issue or you'll be holding up the schedule (that no one consulted you about). so you work a weekend and dive into wtf happens when Y axis < CRY_WATER_LINE_HEIGHT. You find an instance in the base player controller logic and fix it, thinking you're done, but -- fuck it turns out the physics subsystem also uses that same CRY_WATER_LINE_HEIGHT constant to do some optimizations, so you start grepping the code for that code instance and try flipping it off, except you don't realize there are some extra subsystems hidden somewhere that don't reference that constant like they should also do their own weird rendering tricks or optimizations when Y approaches that magic value.

there's a phrase in software development and especially games: 90% of the time is spent on the last 10% of polish. the last mile problem is super fucking real in gamedev, seemingly tiny things in the grand scope of what you're delivering can make or break your game experience for players, and it's always those "tiny" things that are the results of weird edge cases from literally hundreds of subsystems interacting with eachother through the engine.

now, take the water example and apply it to basically everything. most likely every single system in cryengine has some kind of limit to what it was built to do originally and there are always unexpected results when you push engines into territory they werent developed for or tested for. now if you consider how Chris is pushing people to ship shitty demos and move on instead of developing a strong foundation for the rest of the game: you start to imagine how one could half ass a system for an effect in demo and how "ok but it wont work outside of this or with any of the other things we talked about" might fall on deaf ears to a demonstrable cant-actually-delegate-or-listen-to-reason dingus like CRoberts.

now i want to introduce the final nail in the coffin. I could write like an essay on the basic MMO problem space but I wont, i'll keep it simple: MMOs are one of the hardest possible problems to tackle in a game development context from a resource management perspective. the amount of resource expertise (developers, architects, planning) and continued cost of servers and CPU/network time are as big as it gets in game development, and not only that but your game needs to be architected incredibly precisely to fit into the featureset your MMO imagination describes. you really can spare no unnecessary complexity when attempting an MMO, your scope needs to be VERY specific for your first release (  )

Even on a basic employee headcount level, Star Citizen doesn't employ nearly the number of experienced developers required for a project of this size, not only that but we all have plenty of evidence as to CRobert's awful management styles given how many rewrites and "refactors" occur for even the existing unfinished systems. there are clear, glaring signs of bad software development planning and inexperienced game developers rushing a product (while senior ones seem to keep leaving , weird!! ).

absolutely none of this is conducive to shipping the PU as shitizens imagine. they will never see their game. making games is really complicated, making multiplayer games is even MORE complicated, making MASSIVELY multiplayer games is THE most resource intensive & complicated from a project management perspective.

Darn, even if I am no longer an avid member of the SC acid community and my faith bubble burst a long time ago, this write up just burst the last bubble of hope, small as it may have been, that SC might actually see the light of day at some point.

Damn good write up. Good bye SC!

[Ghostmaker]

LOL!! this is great

(extensive discussion of engines and coding)

The term 'engine' is something of a misnomer, isn't it? It's more like... you have the VERY basic framework for a car. You have an engine, steering system, wheels, and maybe a transmission.

Everything else, from brakes to lights to the sound system and the car body, is on you.

Software complexity and interactions also factor into this. Even well-written code can have unexpected interactions when it's meshed to something else (this is what makes beta testers and QA employees cry a lot). To continue our car analogy, it's as if putting headlights in suddenly means your transmission becomes reversed.

And then you square and cube all these problems when you move to MMOs, since you have multiple players interacting in often unusual ways.

You know what I'm weirdly reminded of? The 'auteur' era in Hollywood. It seems like we're going through the exact same thing here.

[dsmart]

$145+ million + 6 years

[dsmart]

For those who don't know where to start in my Tweets today, there are 13. Start here

[dsmart]

Star Citizen streamer, BadNewsBaron on Star Citizen being his career.

Gee, it's almost as if...