I’m having difficulty following this. Is the Crytek/CIG contract still in force or not? If it is, then CIG can’t use another game engine “for the Commercial Life of the Game”. The non-compete clause is through the end of the contract plus two years.
Developing a Game =/= developing an Engine. Building the “Star Engine” they teased before officially moving to Lumberyard, THAT would be the real breach of the non-competition clause.
I recommend to look up some standard Game Engine Licence Agreements, like for Unreal4 / Unity5. You will find that the GLA of the Cryengine is pretty much standard and very little fancy custom language. Imho, a lot of paragraphs get overinterpreted.
Ah, I was assuming breach of contract at that point, not sure why/
Not particularly, provided CIG were supplying that code back to Crytek, as per the GLA, as the “Star Engine” name seems to have been largely recognised more as an internal codename. If they hadn’t been doing that, that would be a pretty serious breach. The point is that any further engine work outside of that done against Lumberyard would be developing against a competing engine, which would, I would have thought, also constituted a breach.
They are not entirely compareable, cause newer and for free versions of the Engines while the Cryengine GLA is a standard royalty based pay-for-full-package licence, but here are the Eulas for Unreal 4 and Unity 4.x for reference and comparison:
https://www.unrealengine.com/en-US/eula
http://download.unity3d.com/company/legal/eula
A better comparison would be with another Cryengine licence of another game studio. But as A: that would be confidential and B: Nobody actually uses the Cryengine, i dont think we will see one to compare. 
EDIT: If they still used Cryengine, they would have had to call Starengine still Cryengine publicly, as per the credit & accnowledgements rules. If they used Lumberyard, i am sure that contract would have a similar rule. Building their own, independently named engine based on Cryengine’s technology and calling it Star Engine would be breach without a doubt. But they dodged that by going Lumberyard i think.
This video is pretty excellent, live PU piracy. Balance issues are obvious and some visual bugs EMP needs tweaking so that you can only disable a ship after combat, not during it, but yeah, successful starfarer disable, breach, boarding action, crew neutralization, and it was full of cargo. (also the guy is using a user.cfg tweak that sets texture resolution and some other settings below the low setting, resulting in more visual problems than usual like the flat fog layer)
So…broken game mechanics, frame rate that makes me nauseated (even with setting below the in-game minimum), and questionable network performance given how jumpy all other player movement was.
I seriously don’t understand how anyone finds the development stage acceptable, given the size of the teams and the time they’ve had to work on it.
1 Like
Setting below the in-game minimum doesn’t improve framerate right now, only the loading stutters. In my opinion setting it as low as he did is a little pointless unless you’re on like 6gb of memory, but he did it. Current framerate is limited by the CPU network related concerns, not the GPU (which is what is affected when you set texture resolution or memory pool so low).
Nobody is happy with delays red_syns. If your own evaluation says they should have been done and perfectly polished last year, good for you man, but you’re probably forgetting how long a big team takes to come into existence and ramp up production, develop internal tools, etc etc. most AAA studios already have that stuff built and still have very long development processes for non-iterative games.
1 Like
The fact that a networking issue impacts frame rate is astonishing. By that, I mean astonishingly shitty programming. Networking causing the micro-teleportation (“stutter”) of other objects? Sure, okay, I have a hard time understanding why it’s still so bad but whatever. Causing legitimate frame rate issues? The two shouldn’t even be correlated.
And no, I don’t think I’m "underestimating"anything about how long it takes to get a team assembled and running. I forget where the image was, but it showed development times for all sorts of other games, such as GTA5. Star Citizen has managed to stretch past virtually everything else, and you can’t even say “it’s because of the scope of the game!”
The “game” in its current state has only one thing going for it compared to, say, GTA5: scale of the environment. In every other aspect, GTA5 has superior performance, more features, and fewer bugs.
Grand.
Theft.
Auto.
Online.
Has fewer bugs.
Do you comprehend the absurdity of that statement? You can’t tell me it was an iterative engine thing: the RAGE engine was a brand new engine when GTA5 was made. You can’t even tell me it’s an iterative style thing: after what, six years? You still don’t have a product that can even be called feature complete? I’m not even asking for it to be bug free, just capable of steady 30FPS and actually have some implementation of all the features.
My sense of time is not what is skewed. I don’t even have money in the project anymore, although I have a couple friends who do. I just want to understand what makes this abortion of a project so easy for others to continue to say “well, it’s okay, something of this scale just takes time” when the demonstrations, separated by an entire year, showed nothing of actual progress?
1 Like
I mean, you didnt respond to my full argument and it wasn’t even that long. Unless you’re claiming rockstar studios didn’t exist before the development of gta5, creating studios, hiring, creating collaboration systems and the internal tools even outside the engine takes time.GTA already had all the gameplay design done, cars with third person shooting isn’t exactly innovative, and gta online is unimpressive in scope for a “MMO” as it’s entirely mechanically inferior to the player made mmo mods for san andreas and for god’s sake it’s peer to peer, im surprised you’d think this is a sane comparison, it isn’t.
i’ve seen a lot of misguided people create “lists of development times” both that are very favorable to or very unfavorable to cig, it depends on how long before the kickstarter you count and which games you pick but neither of us would say that infinity battlescape has been in development for 15 years. “Bug number” is also a bizzare way to guess at game development progress, bugs arent on linear curve with development time. Looking at how buggy something is to evaluate progress pre-release is… incorrect at best.
Personally i believe the “we have to include the players along the way” method has also lead to additional delay due to dev time spent polishing pre-release versions when in the long runs its easier to leave components broken until those entire systems get replaced (they’ve started doing this more with 3.0, though, which is good for long term dev time but bad for PR, for example, you) and before you start foaming at the mouth and say but “that hasn’t happened” we’ve had updates and modules to play since 2014, settling on stable builds when every game system is in flux and releasing them takes a substantial amount of effort. It’s easier when you’re working on one system at a time, but one system at a time doesn’t work for big studios, only small teams. You’d probably delete your post in embarrassment if you were picking builds out of indev versions of other big games, they dont even bother creating widely stable versions until release.
Also on netcode: It’s an issue because every object on the server, every npc, every ship, everywhere in the MMO instance is sent to every player, and those kind of processes are very CPU heavy. Their fix for this (called bind culling) was originally intended for 3.0 but got pushed back because it wasn’t ready yet. Netcode is the hardest part of game development by far so it’s hard for me to get the foaming at the mouth going over that, but you’ll probably find it easier than i do… There are a number of other related optimizations in the works they’ve gone into detail on in various posts and videos.
In general i subscribe to “delays are better than releasing crap and being unable to wipe the game to fix it”, i’ve seen countless “mmo” gaming projects take the release too early route, getting stuck with bad decisions that cant be fixed and im tired of the unwillingness to keep putting in effort. CIG continuously puts in that effort, they’re just obviously taking their sweet time. Like, i think its irrational to equate delays with “project is an abortion” but you know, once people are on the hate-wagon there’s no convincing them. Also, i herd battlescape is ded because it’s over twice the dev time as the alpha release estimate, i guess we can all stop using this website! Or, no.
1 Like
This being the only active thread on the site is not doing much for my enthusiasm for Battlescape in general. Not because the thread is about a different product, but because of its lack of civility. It is showing a darker side to some of the folks in the Battlescape community.
4 Likes
This is almost worthy of being moved to the lounge…
1 Like
What was it the little green alien said?
“Fear leads to anger, anger leads to hate, hate leads to suffering…”
I sense the dark side at work in this thread!
1 Like
Network bind culling was originally intended for 2.6. (23. November 2016) Link.
Lots of people lost faith in CIG exactly because it takes them years to implement such features they originally plan to deliver within weeks/months.
Obviously this is not an easy task, it also took Inovae months to implement a complete network rework with bind culling, way longer than anticipated.
2 Likes
I got the vague impression their original plan for 2.6 bind culling was within the original networking and itemport systems and then after putting devs on the problem they decided to wait on those systems being re-made and a number of other systems because they’d have to implement most of it twice if they did it before and after. Often it’s only after you put devs on researching problem that you get the full list of dependencies and re-order your development schedules. The solution to this would likely be not telling anyone anything unless a feature had already been locked in, but that would mean features only getting discussed very close to release. Probably would be for the best PR wise, but thats not what they’ve been doing.
On bind culling in particular, i find it a kind of interesting problem. Im not an expert programmer so i likely don’t even understand the full extent, but the Issue is they need to classify every object, npc, object on the fly, and they keep adding more types of objects, all of which can be on various parts of the trees of various physics grids while hopping between branches seamlessly without introducing new glitches worse lest even more bad PR. Additionally they need to make sure each and every item back-calculates or get updates from the server for each of the ship systems, damage states, character animation states and so on upon re-load. Certainly sounds fun.
This is the part that makes me laugh at the argument “it takes time”: a team of…four? With a game that doesn’t artificially limit speeds? On an engine that is brand new and probably lacks much of the necessary documentation?
But “it’s the hardest part of programming” and “it takes (years) off work” xD
1 Like
I mean, netcode gave us a pretty big unexpected delay here too. As complexity increases difficulty in implementing new fully integrated systems increases exponentially. Netcode systems for all of these systems combined increases even more than that and really is considered the most difficult field in game development, i think you’re making your level of relevant knowledge clear at least…
Well, to be fair, the interpolation and physics systems gave me much more work than “bind culling”. Which retrospectively was a matter of a few days to implement. The network property parameters system took far more time, maybe a week or two.
But by far the reason it took so much time was rewriting most of the game from scratch to utilize the new ECS design. This allows multiple levels of multithreading, while the previous version was, for most of it, single threaded. This is what allows us to (hopefully) scale up to hundreds of ships per battle.
I certainly wouldn’t like to be the guy to retrofit bind culling / network parameters into an existing engine. It sounds like a real pain, so I don’t really blame CIG for taking time to do it. What is more worrying IMO is that they admitted, quite recently, that they haven’t done any work on the MMO side yet ( server meshing ), and so late into the project… well… I definitely wouldn’t want to be hired as a network programmer by CIG; it sounds like an herculean task awaits them. It’s putting the cart before the horse, because there are a lot of architectural consequences that will waste a lot of time and code if you’re not doing it early in the project lifetime.
9 Likes
Agreed. I rarely look at this thread anymore, but from time to time things get flagged and I have to relive the experience…
3 Likes