Cryengine Has Adopted a "Pay What You Want" Model

Just now, I believe, Cryengine has taken a “Pay What You Want” approach.

This new business model includes full source code access and the engine itself is 100% Royalty Free.

In fact, it seems Crytek has went the Epic Games route. There is now a marketplace you can buy and sell assets on and you are allowed to create commercial games with the engine.

Here’s an article courtesy of WCCFtech:

So what do you guys think? Is this a positive or a negative?

Disregard this post; I just saw that it was posted in the “General Development” Thread Section.

I seen C# , so this is a positive orientation, and there is no escuses for Epic not bringing C# to the engine now.
Coding with C++ is kinda hard , and Blueprints usage is not as fast as coding, so the best compromise is C#.

This is news for CryTek;
Their community now will grow. Given the fact that they charge no royalties and have added C# to the engine.

Coding in C++ is not that hard, but i agree with you, while Blueprints are powerful, having 3 screens of graph for code i could do in 5 lines is quite depressive. For example single loop that checks array for some value and sets some variable based on it, is whole screen in blueprints. This same code would be 1 line up to 3 lines when doing this very clear and petty formatted.

Worst aspect of blueprints is readability, those graphs are huge, remembering what i did and why 2 weeks ago is getting to be quite big waste of coding time. So while C++ is totally not needed, and blueprints are great we may code most of things we did in C++ anyway, just because of code maintenance and time wasted to “read” blueprints.

So script equivalent of blueprints would be .

I have big suspicions that my whole game code could fit in 2 screens of C++, so i did about 240 line of code (not counting all that includes etc here). But as blueprints i have like 20 graphs.

Blueprints are usefull for artists people, while they become very complex to make complex gameplay. Indeed C# would be the best compromise between C++ and Blueprints.

YES!!! I truly need c#, seeing as to how i literally studied hard to learn it.

Blueprints are great for non-programmers more so than for programmers.

If you know C++, and you know it well, C++ will probably always be the more productive option.

Is C# really that worth it?

I skipped right to C++ so I don’t really know what the deal with C# is…

Basically: people hate pointers/references.

Yeah, but most of the complaints I read for the last 5 years in dev communities are mostly by far because of pointers and refs :stuck_out_tongue:

To be fair, UE4 is making those quite easier than regular C++. You can ignore most of the usual memory management things because of the garbage collector - you just need to be aware of who owns your object. Once you stop referencing something, it’s GC, and that’s it.

Headers are painful, that I won’t deny, so I try to use forward declaration all the time.

The only, not problem, but…concern I have with changing to C# is that it isn’t as much of an industry standard as C++ is.

It’s used, sure, however isn’t as powerful and versatile (being practical instead) …

Or at least that’s what gathered.

Tim S. Is pretty much bang on, in terms of power and versitility? What exactly can’t you do in C# (in a game sense)? I mean complete engines have been built in C# like Paradox / Xenko, in terms of performance it’s lightning quick. Many get their idea about “C#” in games from Unity, in which C# isn’t the issue. It’s their old version of Mono that has a fair few problems, at this point it’s old, very old.

In terms of “industry standard”, well most game outfits don’t seem to care. They fritter between things like VS / C# and Lua… Technically speaking, if you can use C++ then there is no reason you can’t use C#.

But all this isn’t the real issue, from an engine developers perspective you have to ask what’s the point? Like as Tim S. said C# by itself is more akin to C++ than Unity’s component based model. It only makes sense to do it if it’s component based, or you’re essentially just doubling up the workload… It’s a lot of work for Epic whether or not they go component based.

Both CryEngine and Lumberyard are adopting a component based system though, so it makes perfect sense for them. Personally I prefer component based scripting systems, they are so much simpler to work with and I’d be happy if they dumped blueprints and replaced it with C# in this model. Ultimatley though, the way things are now doesn’t really stop me from getting stuff done even if the workflow is generally slower.

I don’t think the matter is “C++ programmers not able to use C# shouldn’t be an issue”;
It’s exactly the other way around. I don’t get why C# developers can’t get along with other langues and demand that C# must be everywhere while ~90% or more of the game industry is based on C++.

If you need it just because ease of use for your own gigs, fine, but later don’t bother asking why you can’t get any jobs in game companies that work on C++ frameworks (like I’seen again and again).

Well personally for me it doesn’t matter, I’ve been using C++ for a decade and a half and built game frameworks upon LWJGL and C# with OpenTK… I use whatever I’m given…

I’m not sure “90%” of the game industry being based on C++ is true in regards to scripting and game logic. I’ve always worked in a “lower level” context, but from what I’ve seen many of them use some sort of scripting language on top.

I don’t believe it’s a necessity, I see many on the Unity forums as you know won’t touch Unreal because of it and you know yourself I’ve told them time and time again that it’s not that bad in Unreal. Especially when things like Dynamic memory and GC is taken care of for you…

But you still have to ask yourself, if you don’t require C++ and Unity does what you need. Why make life harder for yourself?

The reason I use Unreal has nothing to do with its code architecture, it’s because it has many tools and time saving features that white wash any time benefits in game logic scripting.

Yeah, I was talking figuratively; when I say “you” most of the time I mean the guy who says “-please please add C#” in every thread.

I know, sorry just giving a little context. Because the first question in my mind is, why do you want C#? Do you understand what you want from C#? I.E. like Unity’s component based system, do you actually want C#? (Being figurative again for “you”)…

Again, personally if Epic wanted to put in a component based C# system I’d be very much happy with it but personally I believe they have a lot of core issues stemming from years back that need to be considered before it’s ever a thought.

It’s nice to have banter, but ultimatley it doesn’t matter. You weigh up the pro’s / cons of every engine and make the best of what you have, then stick with it for the long haul.

Another C++ vs C# thread. Come on guys.
UE4, like any other major engine is coded in C++. You code C++ in UE4 because right now, there is no scripting language, except the visual one - BP.
There are already projects by third parties for adding C# to UE4, so why are we still discussing this? I prefer the Epic staff focus their attention on continuing making UE4 the best engine.

If C++ is the only reason, people aren’t coming to UE4, then is because the C# people are constantly bashing C++ and saying how hard and unsafe is - “if you repeat a lie often enough it becomes the truth”.

If UE4 adds a non-visual scripting language, then I sure hope, is neither C# or any other existing language, but an entire new one, specifically fitted to UE4. And unlike in UDK, since we have the code source, we could easily expand and improve this new “Unrealscript”.

This was a much better way of putting my point.

C++ is what’s used nowadays.

Shouldn’t we stick to using the standard rather than something similar to, but not the standard?

Couldn’t care less about what’s the “standard” whether it’s C# / C++ or not, it’s whatever gets the job done quickest. Not to mention that scripting languages for major engines have been around for decades.

  @EvilCleric, as I said I agree the engine comes first and resolving long standing issues is a must. 

**“If C++ is the only reason, people aren’t coming to UE4, then is because the C# people are constantly bashing C++ and saying how hard and unsafe is - “if you repeat a lie often enough it becomes the truth””.
**
From feedback it’s not the only reason and not always the crux of the issue (although it usually crops up near the top). Simple fact of the matter is, there has been many successful games released without knowing a line of C++. If you can use a brain dead simple scripting system that’s productively efficient ( like component based C# (not C#)), then that’s not a bad thing right? Irrelevant of difficulty, time is always the most important asset and you’re not willingly going to make life difficult by using slower workflows? Well sometimes anyway.

If you’re a hobbyist or student none of this applies, but if you’re planning to sell a game then the end user doesn’t care what language you use. They don’t care how easy or difficult you think a language is, they certainly don’t care what’s an “industry standard”… Efficient workflow to make a polished overall experience for the end user is all that really matters end of the day and it’s time that dictates what you can do.

A language, just like a toolset or an engine for that matter is just a means to an end.

Why discuss this? Well need something to do whilst I’m waiting for lighting to bake.! :smiley: