Nothing inherent to gameworks, rather when devs implement gameworks nvidia is prone to asking them to turn up features that will hurt AMD and older nvidia cards without any increase in performance. With the fallout 4 example the ray lighting, in other games it's unnecessary tessellation. Nvidia has even asked devs to disable features that don't negatively impact nvidia, but positively impact AMD like async compute.
It's easy for nvidia users to see these practices as okay because they are only hurting other people, but given a new generation of cards these measures will be leveled against them too until they upgrade. Nvidia has no qualms about fucking over their own customers so long as it fucks over amd customers more.
Kotlin is build with interoperability with Java in mind from the beginning. This is not the case in Ceylon. In fact some base types (Int, Long) in Ceylon don't match the corresponding Java type. Kotlin has extension methods which Ceylon has not. Ceylon has reified types, which Kotlin has not. Ceylon went 1.0 in November 2013. So far Ceylon seems not have caught any traction, which is unfortunate as it also is a language well-made in many ways. Kotlin has at least Android development to create some initial traction.
As far as I can tell this is more about orchestrating builds, to actually build your game you'd need to run jenkins on an EC2 instance and connect it to CodePipeline.
I'd lay the blame on Unreal here. It's possible to bundle the mono runtime with your game, it's just that Unreal has done it in a way that doesn't satisfy the LGPL. As long as the runtime is a separate binary for which all source is available, you're fine. This can be made completely invisible to the end user.
Maybe there's some difficulty I'm not seeing here, though.
See my response to ilolu - I most recommend diving in and experimenting yourself - maybe build something that is on the CPU first since it is easier to work with. Voxels are really intuitive, you are just manipulating a 3D array of data (more complex once you get into compression and things like that). I learned everything just by playing around with code. :)
There was a collection of DRM stories i read a few years ago. People (businesses, architects, professionals that should know better) calling for tech support over corrupted files was memorable (but apparently not memorable enough). I imagine there was some grim joy in informing people they were not using a legitimate copy, and thus their program was failing.
Degredation as a DRM mechanism sounds clever, and lots of developers think of it at some point (and many games have actually done it). It's actually a really bad idea, though, for a couple of reasons:
* Your support site will be flooded by pirates experiencing the degredation if it is severe enough to be noticed
* People will just assume it is a bug and your game sucks if it's subtle
* If it's very blatant it will be removed in the pirated versions. Meanwhile you run the risk of it happening to legitimate customers due to bugs in the DRM.
Why should you care that pirates think your game sucks? Well, for one, on the great democracy that is the internet, pirates' game reviews have just as much weight as legitimate purchasers. Also a pirate is not necessarily always a pirate, they may be trying before they buy, or may convert to a paying customer later in life and remember their experience with your company.
Not to mention that a huge amount of games are using Gameworks PhysX.
Unreal Engine, Unity etc also use PhysX.