[QUOTE=paindoc;52619593]The netcode in CryEngine is currently really bad because of how much it updates: if someone is off fighting and playing with physics props way off in the distance from you in the current PU, you get those packets and those updates. This applies to nearly everything on the server, iirc, including things like NPCs and events that other players are involved in. This is a tremendous fucking quantity of overhead, and is why performance tanks as players join.[/QUOTE]
Now this makes more sense than the "Your computer is bored waiting for it." bullshit, the issue is less the netcode.
Its the terrible handlers of both the server and client, handler gets overloaded and stuggles to manage the workload.
But that still doesn't really answer as to why FPS gets shat on so hard, that would be more a CPU hit than GPU (which I will admit, cause a bottleneck and effect GPU performance but not to the degree we've seen, its too big of a hit to be just the data handling overhead).
For GPU it'd be more likely the lack of certain items, mostly ships. Not having LOD models so they're rendered in full detail regardless of distance.
I also remember they had a big issue with culling in the past, did that ever actually get resolved?
[editline]27th August 2017[/editline]
Think their next goal after clearing up the network handling would be to look into just general graphical optimizations because of what was mentioned.
I think building their own engine would've set them back longer than the rewrites have taken, but who knows.
[QUOTE=Gmod4ever;52619372]I would think that delta patching would be one of the very first things they implemented, once they had a build ready to go live.
Especially since I'm sure they fully expected having to push a lot of fixes and updates.[/QUOTE]
This involved completely rewriting how CryEngine/Lumberyard packs and encrypts its data files. It's kind of not a small task.
[QUOTE=Megalan;52619472]So my friend tried to play it today and got 25 fps on lowest settings on pretty beefy PC.[/QUOTE]
[QUOTE=Reagy;52619505]It really sounds like a load of bullshit, and considering it comes from a reddit post, I'll take it as pure bullshit.
...
But the whole netcode effects FPS makes no sense, it's just data responses.
That shouldn't be effecting the GPU and it really shouldn't be hitting the CPU that hard either, so even if they're using the stock netcode, I don't really understand how its crippling performance, at most it'd be bottleneck on processing the data, especially if they've got no form of compression or interpolation currently, but even then thats something of a cakewalk for the CPU to do, it's just handling and sending responses afterall, its not actually doing calculations and if it is, its not related to the netcode.[/QUOTE]
It sounds dumb, and it is dumb, but the netcode is definitely at fault.
And to prove it, I'd ask Megalan to have that friend try SC slightly differently:
1. Create a shortcut to (SC install path)\StarCitizen\Public\Bin64\StarCitizen.exe and edit the shortcut target to have " +map DFM_Crusader" at the end, like:
[QUOTE]"(INSTALL PATH)\StarCitizen\Public\Bin64\StarCitizen.exe" +map DFM_Crusader[/QUOTE]
2. Open the launcher and log in, but don't launch the game.
3. Run the shortcut. The game will load Crusader, the PU map, without any other players. I can get 60fps+ on an R9 270X at Very High settings when I do this. If I load Crusader the "correct" way and get into an online instance, fps tanks to ~20 if it's more than half full.
A total revamp of the netcode is in progress because they're very aware of just how awful it is.
[editline]27th August 2017[/editline]
[QUOTE=Reagy;52619624]Now this makes more sense than the "Your computer is bored waiting for it." bullshit, the issue is less the netcode.
Its the terrible handlers of both the server and client, handler gets overloaded and stuggles to manage the workload.
But that still doesn't really answer as to why FPS gets shat on so hard, that would be more a CPU hit than GPU (which I will admit, cause a bottleneck and effect GPU performance but not to the degree we've seen, its too big of a hit to be just the data handling overhead).
For GPU it'd be more likely the lack of certain items, mostly ships. Not having LOD models so they're rendered in full detail regardless of distance.
I also remember they had a big issue with culling in the past, did that ever actually get resolved?
[editline]27th August 2017[/editline]
Think their next goal after clearing up the network handling would be to look into just general graphical optimizations because of what was mentioned.[/QUOTE]
The GPU is not the bottleneck in this case. Playing offline instantly boosts fps well into the realm of playability. It's just not a permanent solution because the game's meant to be an MMO. :v:
And they definitely have working LODs.
The network culling is [URL="https://robertsspaceindustries.com/schedule-report"]included in the improvements slated for 3.0.[/URL] Work is ongoing beyond this patch because it's still unacceptable.
Really does sound like its less the netcode its self being the problem, its how the engine handles it.
The handlers are getting overloaded much like trying to run high pressure water through a small hole.
Hopefully once culling gets in it'll stop it trying to eat all the resources to its self.
I've discussed this before and been told that I just "don't understand game development".
Basically, the reason why they stuck with CryEngine was because it made making the original prototypes easier, things like the FPS module, the racing module and the dogfighting module, with the side benefit of also making it really easy to make stuff look pretty. It however is completely unsuited for a planetary simulation, for many, many reasons. If you're going to be making something in a scale that nobody else has made before, you cannot use prebuilt solutions, you have to come up with a way to make rendering at planetary scales work, you have to work out a way to instance entire planets and allow objects to persist in them.
Instead, by sticking to CryEngine and not discarding their prototypes they've generated an absurd amount of tech debt, the likes of which I've never seen before. Their implementation for ships relies on some very fucky stuff that is the reason why it breaks all the time, ship movement is coded into the player, the networking requires the server to run a full simulation of the game because of default CryEngine networking and thus resulting in the FPS drops because the game tries to sync the server with the game.
This is compounded by the just atrocious project management in this game. Features are constantly being added when cuts are desperately needed, delays are basically a given, and in general the long term planning has completely fallen apart. There's outsourced developments that had to be completely thrown away. There's hilarious amounts of effort being put into minute, aesthetic details when massive features are still to be seen. This is not because the teams are incompetent or because they're slacking off, from what I hear they're in near constant crunch time, working weekends, trying desperately to stick to deadlines while working with code that is just a patch over another patch.
The game is being developed the opposite way that other companies would approach a development of this scale. This is a case where, if you need your game to contain an entire solar system, you gotta have the solar system first before you do ship fights. You gotta have networking for thousands of clients before focusing on small scale FPS battles. They're doing bottom-up instead of top-down and it's just causing things to have to be shoehorned in, in a way that is resulting in extra effort being needed every step of the way.
I think this Gamescom presentation showcases their problems quite clearly, they have this impressive, excessively detailed world where not even the inventory is allowed to be simplistic, everything has to be elaborate and intricately detailed. But if you try to deviate a bit from the script, the whole thing falls apart. If you were to instead spend all the effort making sure the damn thing won't crash and that people can do absolutely whatever they want in it, even if it's ugly, it would have had mass appeal. I don't understand why everything must be polished to such a crazy degree when there are such massive pieces still missing.
[QUOTE=Big Bang;52619714]It however is completely unsuited for a planetary simulation, for many, many reasons. If you're going to be making something in a scale that nobody else has made before, you cannot use prebuilt solutions, [B]you have to come up with a way to make rendering at planetary scales work, you have to work out a way to instance entire planets and allow objects to persist in them[/B].[/QUOTE]
And they have. It's the magic of streaming object containers and nested grids.
Star Citizen's worldspace is a series of nested object containers. The entire playable space is one volume, and if a planet is added to the system that is its own object container, and then if a pre-built base sets placed on a plain, that base becomes an object container within the planet. Land a spaceship on the landing pad and now you have an object container (the ship, for its persistent inventory and its physics grid) inside an object container (the base) inside an object container (the planet) inside an object container (space). This allows a system to have hundreds of planetary locations on a few dozen navigable surfaces (including moons) without requiring users to have 128GB of RAM.
The object container concept has been taken one step further to make the actual Cryengine level file be a streaming object container, and they have called this feature the Mega Map. This allows them to avoid the huge overhead of a complete CryEngine map change, which essentially destroys and recreates the world from scratch, by creating effectively an empty holodeck and then streaming in the appropriate level environment around you. Here's an explanation of the Mega Map and, as part of discussing it, how they use the object containers.
[video=youtube;0B0QUFSCUgo]https://www.youtube.com/watch?v=0B0QUFSCUgo[/video]
(segment begins at 14:00)
I just don't get what the alternative would be but to stay committed to CryEngine and rewrite things. Would you have them scrap everything and start over on UE4 in 2015? I'm sure that would've gone over [I]great[/I]. If they'd written their own engine from scratch they'd be further behind than they are now, and hindsight is great but they had no idea they were going to exceed $150 million when they made their plans in 2012.
Development has been far from optimal but they've also been dealing with a highly unusual situation: a budget that is constantly and incrementally increasing and it [I]could[/I] stop at any time but hasn't so far. If you're trying to set your budget and make plans for two years, that shit makes your life really difficult.
[QUOTE=elixwhitetail;52619792]And they have. It's the magic of streaming object containers and nested grids.
Star Citizen's worldspace is a series of nested object containers. The entire playable space is one volume, and if a planet is added to the system that is its own object container, and then if a pre-built base sets placed on a plain, that base becomes an object container within the planet. Land a spaceship on the landing pad and now you have an object container (the ship, for its persistent inventory and its physics grid) inside an object container (the base) inside an object container (the planet) inside an object container (space). This allows a system to have hundreds of planetary locations on a few dozen navigable surfaces (including moons) without requiring users to have 128GB of RAM.
The object container concept has been taken one step further to make the actual Cryengine level file be a streaming object container, and they have called this feature the Mega Map. This allows them to avoid the huge overhead of a complete CryEngine map change, which essentially destroys and recreates the world from scratch, by creating effectively an empty holodeck and then streaming in the appropriate level environment around you. Here's an explanation of the Mega Map and, as part of discussing it, how they use the object containers.[/QUOTE]
Right, so that's what instancing ultimately is. The thing is, if they had built a proprietary engine, you wouldn't need a level file, you wouldn't need a hack to be able to load maps additively, you wouldn't need to force the engine into working that way, the engine would be built to the specifications of the game and would suit it accordingly so that the same general idea of having layered containers doesn't exist as an abstraction on top of an engine that doesn't work that way. There's a ton of ways to do this but they require very, very fundamental changes in the approach to levels, how positions are even calculated, and how to network them. There's no games that can do this out of the box, but there's prototypes, it can be done.
[QUOTE=elixwhitetail;52619792]I just don't get what the alternative would be but to stay committed to CryEngine and rewrite things. Would you have them scrap everything and start over on UE4 in 2015? I'm sure that would've gone over [I]great[/I]. If they'd written their own engine from scratch they'd be further behind than they are now, and hindsight is great but they had no idea they were going to exceed $150 million when they made their plans in 2012.
Development has been far from optimal but they've also been dealing with a highly unusual situation: a budget that is constantly and incrementally increasing and it [I]could[/I] stop at any time but hasn't so far. If you're trying to set your budget and make plans for two years, that shit makes your life really difficult.[/QUOTE]
I know you're going to hate that I'm going to say what I'm about to say, but this is the sunk cost fallacy in action. If you had discarded the prototypes that were made early on as just proofs of concept for the overall system, instead of literally parts that will be in the final game, work on the engine could have started on 2013-2014. If the process of bringing everything together is not going well (And it wasn't, requiring years and years of bugfixing), then the logical decision would be to cut and start over rather than continuing to burn resources on it. This is one of the hardest things to do in project management, it's very literally where most projects fail. Sometimes, the most logical decision is to throw away things that may have taken years in man hours, just for the sake of the overall project. And with a userbase patient enough that they're willing to wait until 2020 for a release, it makes perfect sense to try and go for a tailor made solution.
As for the cash, this is one of the biggest problems that I find on the entire business model. At what point are ship sales going to become profit instead of just more stuff tacked onto the budget? Why not just say, "OK we're feature locking the game, we're not adding anything new, we're gonna finish what we've got". Make the 80 million dollar game first and then expand it.
While I agree that a purpose built engine would've suited Star Citizen much better than CryEngine (or UE4 / Unity / Frostbite / etc) could, I can't agree with the statement that they would've been further along if they'd gone that route.
Writing an engine from scratch is not a simple task, nor is it a quick one.
Using an already existing engine means that they are able to just start throwing in game content at day one, while leaving their programmers free to actually work on the game itself, not the tooling necessary to start building an engine to host said game.
Just look at the amount of complaints about the pace of development they get at the moment, when they've gotten to the point of having an actual, playable, client with FPS components, arena components, hangar components, and even a PU component that's been out for several years already. (The hangar was playable inside of a year, arena commander a year after that, PU the next year, and then Star Marine the year after that, with 3.0 looking like it'll keep the yearly schedule going)
Imagine how much public uproar it would be if it instead had been several years of silent development before even the very first prototypes would start to appear.
[QUOTE=Big Bang;52619882]Right, so that's what instancing ultimately is. The thing is, if they had built a proprietary engine, you wouldn't need a level file, you wouldn't need a hack to be able to load maps additively, you wouldn't need to force the engine into working that way, the engine would be built to the specifications of the game and would suit it accordingly so that the same general idea of having layered containers doesn't exist as an abstraction on top of an engine that doesn't work that way. There's a ton of ways to do this but they require very, very fundamental changes in the approach to levels, how positions are even calculated, and how to network them. There's no games that can do this out of the box, but there's prototypes, it can be done.
I know you're going to hate that I'm going to say what I'm about to say, but this is the sunk cost fallacy in action. If you had discarded the prototypes that were made early on as just proofs of concept for the overall system, instead of literally parts that will be in the final game, work on the engine could have started on 2013-2014. If the process of bringing everything together is not going well (And it wasn't, requiring years and years of bugfixing), then the logical decision would be to cut and start over rather than continuing to burn resources on it. This is one of the hardest things to do in project management, it's very literally where most projects fail. Sometimes, the most logical decision is to throw away things that may have taken years in man hours, just for the sake of the overall project. And with a userbase patient enough that they're willing to wait until 2020 for a release, it makes perfect sense to try and go for a tailor made solution.
As for the cash, this is one of the biggest problems that I find on the entire business model. At what point are ship sales going to become profit instead of just more stuff tacked onto the budget? Why not just say, "OK we're feature locking the game, we're not adding anything new, we're gonna finish what we've got". Make the 80 million dollar game first and then expand it.[/QUOTE]
the system described for streaming levels isn't hacky at all though? This seems pretty standard in for the most part, with a couple twists otherwise: twists always required when you're working with a prebuilt engine.
Its clear they're using 1. some kind of spatial partitioning octree, given how things are split into boxes 2. positions aren't going to be terribly affected by this, so I'm not sure how that's relevant: getting large scale rendering working is going to already require a flexible system just to get rendering relative-to-eye to work (and this process is documented in numerous places, along with a few textbooks) and 3. making a map a streaming container itself instead of some kind of psuedo-singleton object is honestly fairly brilliant imo (and such approaches are suggested/demo'd with things like Streaming CDLOD). That should make it easier to write high-performance memory management code since fragmentation and rebuilding memory pools can be issues with conventional load in and load out level setups. Plus, I imagine it makes async asset handling easier since you have several smaller chunks to stream in vs one fuckhuge level at a time.
The sunk cost fallacy [I]doesn't[/I] apply here, though. They're definitively already too far: they've invested so many hours into just building much of the infrastructure (like level streaming, new item system, better animations, improved netcode, large-scale rendering, persistent inventory, etc) that throwing all of that away is daft. Can you name any game that has ever tried to reach the scale Star Citizen has? Of course things are going on and on: this isn't like previous attempts with some kind of corporate/publisher breathing down CIG's neck saying "nah lol u release now m8".
I can be sharply critical of CIG's project management, but not for the reasons you mentioned. I think feature creep is a problem, but thats been less of a thing lately as they focus more on building solid/better core systems for their game.
[editline]27th August 2017[/editline]
[QUOTE=ace13;52620194]While I agree that a purpose built engine would've suited Star Citizen much better than CryEngine (or UE4 / Unity / Frostbite / etc) could, I can't agree with the statement that they would've been further along if they'd gone that route.
Writing an engine from scratch is not a simple task, nor is it a quick one.
Using an already existing engine means that they are able to just start throwing in game content at day one, while leaving their programmers free to actually work on the game itself, not the tooling necessary to start building an engine to host said game.
Just look at the amount of complaints about the pace of development they get at the moment, when they've gotten to the point of having an actual, playable, client with FPS components, arena components, hangar components, and even a PU component that's been out for several years already. (The hangar was playable inside of a year, arena commander a year after that, PU the next year, and then Star Marine the year after that, with 3.0 looking like it'll keep the yearly schedule going)
Imagine how much public uproar it would be if it instead had been several years of silent development before even the very first prototypes would start to appear.[/QUOTE]
I don't think it makes sense to completely rebuild now, but I'm more just pondering what things would've been like: given the money available to CIG and the patient userbase, I would've loved to see some kind of new homebrew engine just for this kind of game. Buuuuuuut... I'd certainly never get my hands on it so that kind ruins part of the appeal, tbh.
agree about using pre-existing engine, especially now that it seems they've got so much of the infrastructure code finally nearing a state that works for them. and they've done lots of work at making content creation easier: their tool for making planets and planet bases is pretty damn neat and looks easy to use.
[QUOTE=Reagy;52619505]Same, netcode streaming has nothing to do with actual FPS.
They're doing something really really wrong if the game is getting that hammered to produce a FPS count that low.
The excuse "Your computer is bored waiting for it." means nothing, if your computer isn't doing shit to the scene then it shouldn't be 25fps max, it should be shitting out the most it can.
Now if you took what was said and basically applied it to just the server side, then it'd start to make sense, but for a client - server model? I'm sorry but netcode shouldn't be impacting the processing power of your gpu and cpu, that's server and connection bound, not client.
It really sounds like a load of bullshit, and considering it comes from a reddit post, I'll take it as pure bullshit.
[editline]27th August 2017[/editline]
What also likely isn't helping them is the fact CryEngine its self has basically jackshit documentation, they're working on it as it goes and I would assume, rebuilding parts of the engine as they're working on it (I remember them talking about rebuilding the entire section related to world handling to remove the limits that CryEngine has with world handling, which obviously makes sense).
But the whole netcode effects FPS makes no sense, it's just data responses.
That shouldn't be effecting the GPU and it really shouldn't be hitting the CPU that hard either, so even if they're using the stock netcode, I don't really understand how its crippling performance, at most it'd be bottleneck on processing the data, especially if they've got no form of compression or interpolation currently, but even then thats something of a cakewalk for the CPU to do, it's just handling and sending responses afterall, its not actually doing calculations and if it is, its not related to the netcode.[/QUOTE]
The "your computer is bored waiting for it" is true. Testing reveals your gpu and cpu aren't actually being fully utilized, this is a ton of issues stacked on top pof eachother, including the "everything is being loaded anywhere in the PU". But this is compounded by an issue where your computer essentially has to wait on specific ticks in sequence, and when one thing coming over the network is delayed the whole render stack gets delayed (cryengine netcode design is not smart). If i recall they had a video specifically about this issue getting fixed for the new versions but i don't have the link.
[QUOTE=ace13;52620194]While I agree that a purpose built engine would've suited Star Citizen much better than CryEngine (or UE4 / Unity / Frostbite / etc) could, I can't agree with the statement that they would've been further along if they'd gone that route.
Writing an engine from scratch is not a simple task, nor is it a quick one.
Using an already existing engine means that they are able to just start throwing in game content at day one, while leaving their programmers free to actually work on the game itself, not the tooling necessary to start building an engine to host said game.
Just look at the amount of complaints about the pace of development they get at the moment, when they've gotten to the point of having an actual, playable, client with FPS components, arena components, hangar components, and even a PU component that's been out for several years already. (The hangar was playable inside of a year, arena commander a year after that, PU the next year, and then Star Marine the year after that, with 3.0 looking like it'll keep the yearly schedule going)
Imagine how much public uproar it would be if it instead had been several years of silent development before even the very first prototypes would start to appear.[/QUOTE]
Ok, this is where it gets counter intuitive. The pace wouldn't have been 'faster', but the game would have released before the current timelapse that people are expecting. The thing is, they're [I]not[/I] working on nothing but game content, they're working on adapting the engine. Changing engine code at the scale that they want to do implies a lot of cross dependencies, and in general, more work that is less maintainable. If you are to instead, make things work the way you want them to in the first place, rather than make an existing thing work the way you want them, it may seem like it takes more time, but it generally doesn't. It isn't just a "refactor" because it's changing scope and function, and this sort of thing adds a lot to the tech debt, the result of which is the thousand upon thousands of glitches the game now has and that have to be fixed, all amounting to extra work.
I know it's not an easy task or a simple decision, but they had 80 million dollars. Believe me, it's more than enough to write the engine and tools to support it. If you create detailed specs you could have artists work at the same time the engine is being built so that their work can be implemented effortlessly.
[QUOTE=paindoc;52620240]the system described for streaming levels isn't hacky at all though? This seems pretty standard in for the most part, with a couple twists otherwise: twists always required when you're working with a prebuilt engine.
Its clear they're using 1. some kind of spatial partitioning octree, given how things are split into boxes 2. positions aren't going to be terribly affected by this, so I'm not sure how that's relevant: getting large scale rendering working is going to already require a flexible system just to get rendering relative-to-eye to work (and this process is documented in numerous places, along with a few textbooks) and 3. making a map a streaming container itself instead of some kind of psuedo-singleton object is honestly fairly brilliant imo (and such approaches are suggested/demo'd with things like Streaming CDLOD). That should make it easier to write high-performance memory management code since fragmentation and rebuilding memory pools can be issues with conventional load in and load out level setups. Plus, I imagine it makes async asset handling easier since you have several smaller chunks to stream in vs one fuckhuge level at a time.
The sunk cost fallacy [I]doesn't[/I] apply here, though. They're definitively already too far: they've invested so many hours into just building much of the infrastructure (like level streaming, new item system, better animations, improved netcode, large-scale rendering, persistent inventory, etc) that throwing all of that away is daft. Can you name any game that has ever tried to reach the scale Star Citizen has? Of course things are going on and on: this isn't like previous attempts with some kind of corporate/publisher breathing down CIG's neck saying "nah lol u release now m8".
I can be sharply critical of CIG's project management, but not for the reasons you mentioned. I think feature creep is a problem, but thats been less of a thing lately as they focus more on building solid/better core systems for their game.[/QUOTE]
It's not an octree? If all it's just a tree, there's no reason for a constrained tree when the amount of objects on the same level within a container can be infinite. It's also hacky precisely because of "twists", every "twist" you add is a potential avenue for bugs, every bug you introduce is extra bugs that need to be fixed.
The thing about the level loading scheme is that it's exactly one of those things you could have designed the game around. To me, just having the actual planetary scales in the game makes infinitely more sense than developing all the other things they did first, because if you can make a planet work (Like an actual planet, not just a really big level) in multiplayer and have some sort of persistency, then smaller stuff becomes feasible, ships become feasible, FPS becomes feasible, base building, so forth. This is what I meant by top down, and it's generally more efficient because you're tackling the big problems first, and then moving your way to smaller ones. This is in direct opposition to how the game was planned.
And note, I'm not saying they should throw it all away [I]now[/I]. That was a call that should've been made years ago. It doesn't make any sense to ditch it now because the sunk cost is larger than the remaining budget. I don't see what you mean with how there isn't feature creep when they just announced a webcam for doing live facial animations on characters, that's a feature. The feature creep doesn't go away when they stop announcing features by the way, not unless you cut, and nothing has been cut.
Anyhow, I know how these threads end, so I'm just gonna stop it here.
[QUOTE=Big Bang;52621177]I don't see what you mean with how there isn't feature creep when they just announced a webcam for doing live facial animations on characters, that's a feature. The feature creep doesn't go away when they stop announcing features by the way, not unless you cut, and nothing has been cut.[/QUOTE]
[IMG]http://i.imgur.com/CGwzDX5.png[/IMG]
I just thought you'd like to know that I was recently reminded that CIG has in fact been talking about the webcam face-scanning idea since 2013, before they even hit their one-year anniversary. I knew it'd been previously discussed but 2013 is before I paid attention to SC and I wasn't aware it was that deeply embedded.
If this Gamescom was the very first time we'd heard of CIG's intentions to have a facial scanning feature I would, improbably enough, agree with you that this was crazy scope creep, BB. That'd be a pretty big focus distraction, for no good reason, when they need to be devoting engineering resources to advancing the state of the game. But that's not what happened. Instead, this is them putting a darker line on pencilled-in promises to backers.
There's also the fact that, if you pay attention to the interview with the Faceware guy, [I]they[/I] developed the webcam, not CIG. You also don't [I]need[/I] to use their device, any consumer-grade webcam capable of 720p@60fps should do just fine according to them. Their branded solution includes, so they claim, superior low-light capability.
-snip, lets not get into that-
Why would you think I'm accusing you of being Smart? Try actually addressing the rest of my post instead of getting hung up on the most minor detail of the post.
I regret even bringing it up, that's a recipe for a shitshow. I'll just add this, this facescanning thing, that's one of the features I would cut, even if it was promised. That's one of the things where I would say "don't allocate engineering resources on this, focus on what matters". There's too many small tidbits like that in the game's design, which legitimately are better implemented as incremental patches rather than things to add before the core game, as planned, can be played.
Even if it seems like it could be added without breaking anything, you still have to consider that if large swaths of the game are incomplete, a highly coupled feature like this will likely break if some other lower level component (Like, say, networking or player animation) is changed, requiring additional engineering efforts. Maybe it won't add any extra time, maybe the programmer who made it is Code Jesus and it happens to be the most decoupled feature in the entire code base and it would work even if you change the engine, the point is that their planning is excessively optimistic, and it has caused many problems in the past that seem to be repeated.
Dude no engineering time was wasted on this.
Faceware did the tech, all cig had to do was take the data sent by the faceware program, relay it over the network and apply it to the facerig in cryengine.
I'm willing to bet it's like 200-300 significant lines of code max
Buying the tech from faceware probably wasn't cheap tho, but it seems that sc is helping faceware out with that hardware crap (all they have to do is give a bit of air time)
Sorry, you need to Log In to post a reply to this thread.
