Crytek sues Star Citizen devs for copyright infringement, breach of contract
scribd.com
scribd.com
>25. On February 14, 2016, Defendants moved forward with their plan for Squadron 42 notwithstanding their failure to obtain a license and began offering the video game for separate purchase. As a result, Defendants are intentionally and willfully using CryEngine without a license and in violation of copyright laws.
This seems to be the main point. They're claiming Star Citizen is using CryEngine for their new game, and haven't licensed it out to do that, along with the company behind Star Citizen distributing assets of Cryengine in various ways. They were also supposed to help in developement of Cryengine in way of bug fixes, and did not comply.
Crytek's GLA appears to be pretty far reaching.
>38. On December 23, 2016, Defendants announced that they were using the Amazon Lumberyard video game engine for Star Citizen. The GLA did not permit Defendants to use any other video game engine in Star Citizen except for CryEngine.
>50. On May 6, 2015, Defendants began posting a series of videos online titled "Bugsmashers." The videos contain excerpts of information from CryEngine that were confidential, in breach of the GLA, and should not have been shown to the public. The series continues today.
I'm not a big follower of Star Citizen and frankly even with all of the evidence presented I'm not sure what the outcome should rightfully be, but it sounds to me like CIG is knee deep right now.
> 50. On May 6, 2015, Defendants began posting a series of videos online titled "Bugsmashers." The videos contain excerpts of information from CryEngine that were confidential, in breach of the GLA, and should not have been shown to the public. The series continues today.
> 51 On August 26, 2017, news reports announced a partnership between Defendants and a third party developer, Faceware Technologies. Upon information and belief, as a result of the partnership, Faceware received access to the underlying technology for CryEngine (including computer source code). Defendants did not disclose this third party developer's involvement to Crytek, let alone obtain Crytek's prior written approval. This was entirely in breach of the GLA.
"Section 2.1.2 of the GLA states that Defendants have a license only to 'exclusively embed CryEngine in the Game.'"
The term "exclusive" means what in this case? They can only use CryEngine in this game (and not embed it in other games) or they are forced to only use CryEngine in this game to the exclusion of all other game engines. The second interpretation is not common in my opinion.
There are a lot of other provisions that may be more solid. This particular one seems suspect.
Ie: the couldn't start on CryEngine, get free demos, then actually use Unreal Engine for the rest of the game.
The second interpretation is the only that makes sense, as the sentence is qualified for just Star Citizen. It's pretty clear in legal terms, and very clear in context that the exclusivity refers the there being a single, exclusive, engine.
This is from the banner at the top of CryEngine's home page:
"Full engine source code. All features. No royalties. No obligations. No license fee.
I'm speculating (yay internet!), but for Enterprise components developers profit from there's often a "buy the cow up front" option along with a "free cow today for a sip of the milk tomorrow" model.
Star Citizen, particularly before the crowd funding, wouldn't have wanted to give them a lot of cash up front, and got some really nice concessions in the deal (free promos and development).
> In that Agreement, Defendants promised, among other things,
> (i) to use the CryEngine game development platform exclusively and to promote that platform within the video game,
> (ii) to collaborate with Crytek on CryEngine development, and
> (iii) to take a number of steps to ensure that Crytek's intellectual property was protected.
> Defendants utterly failed to follow through on those promises, and their actions and omissions constitute breaches of contract and copyright infringement and have caused substantial harm to Crytek.
Legal challenges from a game engine is something that can scare away new projects in that engine. This wouldn't affect most developers as Star Citizen signed with CryEngine but it won't be attracting people to use CryEngine over others anytime soon.
Crytek is one of those companies that has great game engine tech but got high-centered when Unreal and Unity went free in 2015. Crytek is from the age of game development where licensing per game could run up above 300k for licenses and/or percentages that were much higher than today (Today Unreal is free but 5% royalties of gross over 3k quarterly -- but previously was 300k for the license -- Unity free up to 100k revs and $35/$125 Pro with no royalties, previously it was $1500 a year minimum). Crytek has been in a reactionary mode since 2015 when they also had to significantly change their model due to Unity/Unreal competitive moves.
Unreal at 5% royalties over 3k a quarter, Unity at free to 100k annually and $35/$125 Pro after that and even Crytek at $50/mo, all are very helpful for game development skills. Previously when engines were hundreds of thousands for a license it was hard to even gain skills beyond modding tools for engines and game companies had to shoulder all the training costs of even good game devs. Today, Unity/Unreal skills are much easier to find because of the low cost of entry. Ultimately the change to subscriptions and low cost (relatively) of the licenses allows a good market for developers investing in skills that will immediately translate at the game company they are working at, much easier to hit the ground running. Ultimately access to the engines is more valuable than the up-front costs of the past. Crytek is still dealing with that competitive pressure most likely.
You are waiting for another Copyright suit, aren't you? :)
Seriously. I can't imagine anyone seeing this lawsuit and reading about the terms of these contracts and thinking, "Yeah, CryEngine sounds like a good idea."
Lumberyard is far more likely to have good licensing terms, plus Amazon integration, and Unreal Engine is a serious competitor with very clear licensing terms and pretty extreme access to the engine code itself.
IMO, Crytek should take a deal as soon as its offered, here.
And why is Amazon developing a game engine?
Unity and UE4 really are the current leaders in game engine technology, CryEngine, while great, has suffered in the last four years or so and isn't a significant competitor.
So, not the greatest uptake, but Amazon was always willing to give things time to mature. We'll see if they can take market share of UE4/Unity.
Because of the Amazon services integration potential. That's how they make money.
Back when Lumberyard was announced, I wondered if Amazon would buy out Crytek. Figuring it's payroll issues, I thought it would be a bargain if Amazon really wanted to seriously get into game development. Since it's been two years, I don't think that it will happen. Now I'm thinking that Amazon will buy the scraps during liquidation.
As a "concierge-level" backer (I'm embarrassed about it too, don't worry), I have a lot of concerns Crytek may end up with some or all of my money. That being said, I've never assumed a "purchase" with CIG was more than a crowdfund, and if it dies, that's how things go sometimes. I'm not angry, I'm not panicking, and I'm not joining the "demand a refund from CIG" party that a few people like to obsess about.
I can't speak for everyone else, but I backed an idea. I gave money to someone who wanted to assemble a game with an unprecedented amount of flexibility and realism. Whether or not that actually makes a "good game" in the end. I invested in something I want to see happen. If it does not happen, that will be unfortunate, and I will be sad. But given that what they are trying to do is borderline insane, it will not be totally shocking if they fail.
- Publishing Squadron 42 as a seperate game (licence was only for one game, Star Citizen)
- CIG fiddled with/remove Crytek's branding in loading screens etc (they weren't supposed to)
- Cryengine was not exclusively used for Star Citizen (apparently it also leverages Lumberyard)
- CIG did not provide bug fixes and optimisations for Cryengine (they were supposed to)
- CIG disclosed Cryengine "secrets" without permission via online videos, and also via collaboration with a third party
Not sure on the amount, the only dollar figure quoted is 'in excess of $75,000'. Not sure if that means $76,000 or $1mil though - IANAL!
Specifically-
> In that Agreement, Defendants promised, among other things, (i) to use the CryEngine game development platform exclusively and to promote that platform within the video game, (ii) to collaborate with Crytek on CryEngine development, and (iii) to take a number of steps to ensure that Crytek's intellectual property was protected.
That's what I meant with my assumption that there should be some clear consequences already defined in the contract.
In addition, the requirements of the CryEngine have always been high, the FPS drops and a lot of other performance problems probably have to do a lot with that.
I am not sure if the Unreal Engine would have allowed the detailed modeling of the ships, but to be honest, I can see no advantages of CryEngine compared to Unreal Engine.
If you have any, please let me know, I've been racking my mind over this.
If they wanted to hit their original launch window they probably would have had to have gone with UE3. And if they had still ended up slipping as bad as they now have they would be on something that was really outdated (though they probably would have announced a switch to UE4).
As far as modelling goes it makes no difference - they're all made in 3dsmax/maya and then imported and both engines would be heavily optimised for that pipeline.
There's no reason you can't (in most games) have a segregated coordinate system. For example, where each star is the center, the (0,0,0) point. And when you warp from one star system to another, the new star is the new (0,0,0) point.
Floats are great for huge distances, and tiny distances. They are horrific at BOTH at the same time... like say... adding a tiny fractional velocity vector per frame to an object millions or billions of units away. (There is a minimum amount you can add to a float without rounding down to the same original number, and the minimum change gets bigger the bigger the number is.)
http://blog.reverberate.org/2014/09/what-every-computer-prog...
IIRC, KSP does the same thing and coordinates are to the nearest "planet of influence"--which has the affect of removing Lagrangian points for orbits but otherwise works great without needing custom math types which are much much slower than native types, and it doesn't require ripping out all of the assumptions that an entire engine (Unity in the case of KSP) runs on.
When I created my own 2-D KSP, I ended up encountering all of these issues first-hand, and simply adding more precision didn't help nearly as much as segregating my coordinate system when we're talking about "astronomical" scales.
So if they're actually using non-native types, or having to change the engine, then they better have damn good reasons to do it. You don't change something that fundamental unless you're insanely brash, or, you've got a very-carefully-thought-out hard requirement that cannot be worked around.
If they really "need" space ships to have huge precision at any point in the universe regardless of proximity to a star, I would rather create "false/invisble stars" (almost like a quadtree/octree tree) where ever they are needed. Like when a huge fleet is moving around in free space, it would have a coordinate system following the capital ship. And if two groups of capital ships are attacking, you merge the coordinate systems.
Are you saying that Star Citizen is using 64-bit doubles for their GRAPHICS pipeline? That's pretty much insane for the exact reason you mention--single (and half) precision float units are in the GPU.
Or are you saying "most games" use 32-bit floats for their PHYSICS calculations? Because that's also not a requirement and game dependent. Doubles are faster on many CPUs. There's a tradeoff for memory packing efficiency (using more cache and alignment issues), but floats are upgraded to doubles before being operated on on x86 and x64.
So for physics: Doubles are faster, and, they've been hardware accelerated for decades (even when CPU's were "32-bit").
But you mention both physics and graphics and seem to be conflating the two. The graphics and physics pipelines don't have to have related at all. Drawing with 64-bit natives is almost unheard of and would be incredibly slow on a GPU.
So what are we actually debating here?
I'm talking about GPU support here for accelerated graphics and physics, not CPU. Obviously, CPUs have had native double support for a long time.
Doubles have been hardware accelerated for some time for both graphics and physics, BUT: until recently you paid a heavy price for doing double calculations on the GPU (20x slower or more typically), especially on lower-end hardware and obviously increased memory requirements. Most game engines have until relatively recently used 32-bit floats for pretty much everything, although often selectively using 64-bits or multiple scaled reference frames for positioning over larger scales.
From what I understand, Star Citizen converted their game engine to use 64-bit floating point for worldspace positioning in both their graphics and physics pipelines, so they can have a single coordinate system for positioning at the scale of an entire solar system, without having to worry about precision issues. My understanding is that Star Citizen uses the GPU heavily for graphics, physics, procedural generation, and simulation using graphics shaders (vertex/fragment, etc) and compute shaders.
You're right of course that graphics and physics can be implemented independently, but they have to share coordinates and data at some level, and if you have to convert between multiple precisions, coordinates systems, and frames of reference, you are potentially making things more difficult and negatively affecting performance.
From the Star Citizen interviews I've seen, my understanding is that the conversion to 64-bit worldspace simplified their development (all their components can share worldspace data) at only a small cost to performance on modern hardware, and they obviously felt it was worth the trade-off. However, technical detail in many of the videos I've watched has been rather lacking, and some articles have clearly misinterpreted what they've done. I doubt their entire engine has been converted to use 64-bit for everything, which is probably wasteful, and would severely limit the hardware capable of running it.
https://starcitizentracker.github.io/
As you can see, development has stalled and very little progress is being made.
To answer your question: they chose a game engine to create shiny demos and carefully crafted videos. They have no intention of releasing a fully playable game. They just need to keep the hype going to keep selling virtual spaceships and virtual land.
I never tried it.
0. https://www.newyorker.com/tech/elements/desert-bus-the-very-...
Fool me once...
I've heard people say "the technology didn't exist back then!", which is true. But the technology doesn't exist today either. Games have gotten a lot better at drawing convincing pictures, but in terms of simulating worlds and generating content, we've mostly stood still.
No Man's Sky already showed that, with its demo scene derived trickery. You can't entertain people with random seeds for very long. You need intent, storytelling and reactive, interacting systems.
I'm not sure how much Chris Roberts had to do with the final product but I don't think Freelancer was a failure when it was released.
I dunno if you've played it recently btw, but it hasn't aged that well either.
Ambition and wild ideas are fine, but you shouldn't make promises you can't deliver on.
Of course "Freelancer" (hyped like "Star Citizen" today, and basically the very same game idea) came out late and most announced features were missing - actually the same features are now announced again by Chris Roberts for Star Citizen.
And another game of "Digital Anvil" never got released thanks to Microsoft, it was called "Loose Cannon". It was announced in 1998 and it would have been the first 3D open world game in the very same sense of Grand Theft Auto 3, just released 1-2 years before GTA 3 !! Nowadays we could be playing Loose Cannon V and no one would play GTA. Anyway "Loose Cannon" was very good looking for it's time, and the actual gameplay video footage back then looked really promising. Barely any media can be found online today, but much more is on CD-ROMs of old PC Game mags (1998-2001 era):
https://www.unseen64.net/2008/04/15/loose-cannon-xbox-cancel...
http://www.ign.com/games/loose-cannon
https://en.wikipedia.org/wiki/Digital_Anvil
Like the poster above me, I say the same: "Fool me once..." to both Chris and Bill.
For instance, Crytek claims that Squadron 42 was announced to be offered as a stand-alone game in 2016 but I remember this being the public stance of CIG far before that.
It sounds like Crytek failed to secure a comprehensive agreement covering the situation as it has developed over the years and is now attempting to make up for that lapse.
And I imagine it's driven by the desperation that Crytek must feel being so close to insolvency. From what I remember they were also pretty peeved that CIG picked up some of their senior CryEngine engineers when Crytek was missing payroll.
I think the last I heard of them they were almost into bankruptcy-mode, so yeah it does seem like they did this out of desperation. Still short-sighted, though.
http://www.nasdaq.com/press-release/crycash-announces-its-to...
For example, McDonalds could have refused to give St. Jude winnings for one of their Monopoly games because pieces were given to St. Jude in such a way that broke the rules. Or asked for the money back once it was found to be part of a fraud scheme.
Is McDonald's going to back out of paying the winnings and eat the bad PR of "Refuses to give money to hospital known for saving dying children." just because they have the legal right to do so? Hell no.
Consider this, though, if the only protection of one's income came from a license - it makes sense to enforce that license against people who didn't pay substantially over $75,000, after contacting them several times.
https://knowledge.autodesk.com/support/stingray/learn-explor...
Is Havok really mandatory? Wouldn't it be possible to replace Havok with Bullet or some other related system?
--
[1] https://www.youtube.com/watch?v=YTC0V0LWeGI
[1] http://media.steampowered.com/apps/valve/2014/Sergiy_Migdals...
[1] http://media.steampowered.com/apps/valve/2015/Migdalskiy_Ser...
I heard they used to use an decade old physics library that just got bought by Havok company in the meantime and has nothing to do with the Havok physic engines everyone knows.
For example they are sueing that they only licensed cryengine for one game, and yet RSI was planning on using it for two games. However the second game has never shipped, and RSI has switched both games over to the Amazon Lumberyard engine. This particular claim seems like it’s going to get thrown out.
My guess is that we’ll see a settlement in this. It doesn’t seem like this going to hurt RSI very much.
If in discovery, they can prove CryEngine is still in use, as opposed to actually being properly rebased on Lumberyard...
There's a lot here, and Crytek has a lot of different claims. They only need one or two of the claims to stick for it to hurt.
EDIT: It gets more confusing, Lumberyard is apparently a hard fork of CryEngine that Amazon paid for. My guess is they switched to Lumberyard for better licensing terms, but kept all the enhancements made to CryEngine post-fork.
I only mentioned CryEngine being more mature because they have more dedicated resources working on it, and from what I understand dev studios contribute fixes back to the engine as well.
> 36. Section 2.1.2 of the GLA contained a critical promise from Defendants that they would not develop the Star Citizen video game using any other video game engines.
If you don't want to get sued, don't sign contracts and breach them.
https://www.polygon.com/2016/12/10/13908156/crytek-employees...
They're more of a struggling company. But hey, at least they deliver a product.
Maybe they should have rebranded it, but in any case they seem to have done something wrong about their business in comparison to, say, Unity.
https://www.pcgamesn.com/crytek-wage-crisis-black-sea-studio
This is just another attempt at keeping cash flow positive, not by making games but by any other means possible. I wouldn't be surprised to see news in a few months or half a year saying Crytek are yet again not paying their employees.
Look at how the pricing has come down on UE4 and Unity.
Sounds very much like CIG. Maybe they should merge.