• Advertisement

Unity What advantages Lumberyard/Cryengine has over UE4?

Recommended Posts

I come from UE4 community , Its a great and powerful engine , very easy to learn and use and you could build nearly any type of game with it quite easily. Its main strong points are complete set of mature tools , a very strong architecture and large community support.

 

Last year Cryengine went free in the form of lumberyard, later it itself became free to use releasing as cryengine 5.

 

So I decided to take a peek into both, the latest I see of lumberyard is its going the same route as Unreal engine in its architecture (components,reflection,events etc etc) and improving tools and usability overall (might end up as UE4 clone with lua and forward renderer in a few years  :P  )

While I don't know much about cryengine 5 but it seems to be going more towards graphical enhancement route rather than improving usability and docs.

 

 

I wish to know about things that community thinks is different in CE5/Lumberyard that is something a UE4 user would desire but cannot get in UE4. Something positive that is exclusive to CE and has no proper alternative on UE4.

Share this post


Link to post
Share on other sites
Advertisement

I think your lack of replies kind of shows the problem =)  I's new.  That's great, but new means it doesn't have the userbase.  Whether that means Yet or Ever, remains to be seen.

Share this post


Link to post
Share on other sites

Its still a bit new but a quick peek at it showed me that it supports both batching and instancing on the same level.

 

This is interesting because Unity is more batch focused and Unreal is more instancing focused, with Cryengine adopting both, on more or less the same level. Batching is better for unique 3D, making it a good choice for indie games and instancing is better for a modular workflow as used by most large games.

 

Creating assets to take advantage of both batching and instancing is a pain, the easiest is plants. Things like foliage is hard for the player to remember the exact details, if it changes it wont be noticed as often as other assets.

Considering this I think we will be seeing even more large open world games with lots of good looking vegetation from Cryengine.

 

But with its bulky interface and with how difficult it is to make assets of that level, I don't think it will be such a large contender in the indie market.

Edited by Scouting Ninja

Share this post


Link to post
Share on other sites

On using Lumberyard you need to read the license agreements carefully because Amazon made some restrictive parts in it for example you are not allowed to use an other than Amazon's or partnered cloud services and so on

Share this post


Link to post
Share on other sites

On using Lumberyard you need to read the license agreements carefully because Amazon made some restrictive parts in it for example you are not allowed to use an other than Amazon's or partnered cloud services and so on

 

So what the hell is the point of using Lumberyard.

Anyways... in my experience. Cryengine's Editor has a lot of problems. It's incredibly prone to crashing. it has some bad performance issues. And even some weird non-sensible glitches. It's also awkward to use at times, and tries too be too close to home with old Autodesk software.

Unreal is more modernized. I wouldn't say it's streamlined as everything is in one place. But you can easily find the most commonly used tools. And there's very little that's condoluded about using it.

Share this post


Link to post
Share on other sites

 

So what the hell is the point of using Lumberyard.


Lots of people are happy being tied to Amazon's cloud services.

 

yeah I don't think its a severe limiting factor or anything , also I wanted to discuss pros and not cons.

Like is there a special advantage for lumberyard renderer when compared to UE4 which can justify anyone using it instead of UE4. Or any other quality

Share this post


Link to post
Share on other sites

Like is there a special advantage for lumberyard renderer when compared to UE4 which can justify anyone using it instead of UE4.

Lumberyard should be better for large static scenes, allowing for some stunning screenshots. It is also build with networking in mind so maybe it would be better for MMO games. 

 

 

The license is maybe worth it, however that can be argued. At 5% royalty for unreal you would pay $50 for every $1000 you make, and its per product, that is less than the price of a single game.

 

If you consider that the average indie developer earns less than $750 per month, normally from more than one game, then most indie developers should be able to use any of the engines for free. Also Unity, Unreal, Cryengine/Lumberyard are all such complicated engines that no matter which of the licenses you pay for, it would be vastly cheaper than making your own engine of that level. 

 

For the license to be part of the justification for using Lumberyard you must be able to guarantee you will make more than $3000, for example if you did some crowdfunding.

Share this post


Link to post
Share on other sites
At 5% royalty for unreal you would pay $50 for every $1000 you make

Note that the Unreal percentage is on the retail price, not your own profits.

Digital retailers typically take about 30%, and the tax man typically takes about 30% in income tax.

So (ignoring the $3k threshold) if you sell $1000 worth at retail, Steam keeps $300, the tax man takes $210, Unreal take $50, and you get to keep $440.

 

For a more interesting example, say you want a decent gamedev salary of $3k per month. That means you need to sell about $6200 per month at retail, meaning Steam keep $1860, tax man takes $1302 and you keep $3038.

Per quarter, you make $9114... but your per quarter retail revenue is $18600, so subtract the $3k threshold, and Unreal want 5% of $15600, which is $780 (or $260 per month).

So your final per month income drops back down to $2778 - below our target salary of $3k.

If I go back and adjust my estimate to set a retail sales target of $6800, then you end up keeping $3042/mo and Unreal costs you $290/mo.

In comparison, Unity Pro is less than half that, at only $125/mo, and Lumber/Cry are free :)

 

So tl;dr, if you're planning to pay yourself a full time gamedev wage, the difference between Lumberyard and Unreal is ~$300/month :lol:

Share this post


Link to post
Share on other sites

Like is there a special advantage for lumberyard renderer when compared to UE4 which can justify anyone using it instead of UE4.

CE was intended to have only dynamic lighting, while UE used mainly baked lighting.

I don't know if CE supports baked lighting nowadays, but if not this point might be the most important.

Share this post


Link to post
Share on other sites
So tl;dr, if you're planning to pay yourself a full time gamedev wage, the difference between Lumberyard and Unreal is ~$300/month :lol:

 

I agree, however you should factor in the value in productivity gained from using the engine, plus the small army of developers already skilled in the engine that you can potentially tap into (note that lumberyard and for the most part cryengine do not have this large, established userbase to recruit from ...yet :rolleyes:).

 

That $300 may be worth it to you, if you'd have spent more than that $300 of time and/or budget per month making something comparable to UE4 and constantly enhancing and maintaing that code as the industry changes. As UE4 has millions of man-years of development behind it, chances are this is a reasonable trade-off unless you're an AAA studio with the budget to write your own engine.

 

Just my own personal experience and 0.02p.

Edited by braindigitalis

Share this post


Link to post
Share on other sites

So tl;dr, if you're planning to pay yourself a full time gamedev wage, the difference between Lumberyard and Unreal is ~$300/month

Well if you put it that way maybe the price should be considered, if you feel that a good interface and user base isn't worth $300 or more then using Lumberyard is the better deal.

 

I Downloaded Lumberyard again, a pain as it is huge and there are a few hoops you have to jump before it runs, just to see how it is again, underneath it has almost everything Unreal has, I would go so far as to say that they are infact on par with each other.

The size is annoyingly large Unreal is >15 GB and Lumberyard is > 40 GB Most of that is pre-made assets that will be great for testing; but developers never use these for there actual games just as no artist sells a model with the 3ds max pre-made materials attach.

 

Underneath it has most of the same things Unreal does, there is nothing that I feel justifies switching.

 

 

Digital retailers typically take about 30%

How is that not considered theft, 30% for retailers 30% for tax, you get less than half of the money you earned.

As a artist our retailers gets a 10% cut, even then we consider it too much.

Share this post


Link to post
Share on other sites

How is that not considered theft

 

Doesn't matter what you consider it, since you can't really change it. You can distribute for free via itch.io or similar but the value of the stores (physical and digital) is as much about exposure as it is about anything else.

Share this post


Link to post
Share on other sites

 

So tl;dr, if you're planning to pay yourself a full time gamedev wage, the difference between Lumberyard and Unreal is ~$300/month

Well if you put it that way maybe the price should be considered, if you feel that a good interface and user base isn't worth $300 or more then using Lumberyard is the better deal.

 

I Downloaded Lumberyard again, a pain as it is huge and there are a few hoops you have to jump before it runs, just to see how it is again, underneath it has almost everything Unreal has, I would go so far as to say that they are infact on par with each other.

The size is annoyingly large Unreal is >15 GB and Lumberyard is > 40 GB Most of that is pre-made assets that will be great for testing; but developers never use these for there actual games just as no artist sells a model with the 3ds max pre-made materials attach.

 

Underneath it has most of the same things Unreal does, there is nothing that I feel justifies switching.

 

 

 

 

Digital retailers typically take about 30%

How is that not considered theft, 30% for retailers 30% for tax, you get less than half of the money you earned.

As a artist our retailers gets a 10% cut, even then we consider it too much.

 

 

 

What I see is that lumberyard and UE4 are nearly same under the hood , but the Edge Ue4 has is it takes 100x less effort than Lumberyard or CE to get the same thing done. For example the animation system in UE4 . Also CE and lumberyard are less performant than Ue4.

 

Also Lumberyard seems to be taking a direction to improve its usability and toolset, while CE5 is still focusing majorly on Graphics performance. 

 

The one edge I see here is that rendering of hard metallic surfaces seems a bit better in CE/Lumberyard while everything inherently looks plastic or teflon in UE4. But again that depends on the assets and how they're used.

 

Does anyone thinks that CE/Lumberyard being a forward renderer has some advantage?

Share this post


Link to post
Share on other sites

Careful on saying 'free' for any engine - especially Lumberyard. If you host on AWS, you better have in-game purchases designed into the game because you will need serious cash to keep it online if it's successful. There is a free tier on AWS, but that will probably support 2 or 3 people playing online to test it. If you're true MMO with 2000+ concurrent users, you're in for a world of hurt when the massive bill comes. Now, keep in mind, a company like Supercell made $924M in profits on $2.3B (yes, B is for Billion) in revenue in 2015 on just 3 games. They can afford the infrastructure to support the game. If you are not immediately making sales, stay on a hard server ISP rental until you get going. If your app flies, you will not be able to exist without AWS cloud services - nothing can scale like they have proven they can.

Edited by devfingers

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Advertisement
  • Advertisement
  • Popular Tags

  • Advertisement
  • Popular Now

  • Similar Content

    • By Alexander Nazarov
      Hello. I'm newby in Unity and just start learning basics of this engine. I want to create a game like StackJump (links are below). And now I wondering what features do I have to use to create such my game. Should I use Physics engine or I can move objects changing transform manually in Update().
      If I should use Physics can you in several words direct me how can I implement and what I have to use. Just general info, no need for detailed description of developing process.
       
      Game in PlayMarket
      Video of the game
    • By GytisDev
      Hello,
      without going into any details I am looking for any articles or blogs or advice about city building and RTS games in general. I tried to search for these on my own, but would like to see your input also. I want to make a very simple version of a game like Banished or Kingdoms and Castles,  where I would be able to place like two types of buildings, make farms and cut trees for resources while controlling a single worker. I have some problem understanding how these games works in the back-end: how various data can be stored about the map and objects, how grids works, implementing work system (like a little cube (human) walks to a tree and cuts it) and so on. I am also pretty confident in my programming capabilities for such a game. Sorry if I make any mistakes, English is not my native language.
      Thank you in advance.
    • By Ovicior
      Hey,
      So I'm currently working on a rogue-like top-down game that features melee combat. Getting basic weapon stats like power, weight, and range is not a problem. I am, however, having a problem with coming up with a flexible and dynamic system to allow me to quickly create unique effects for the weapons. I want to essentially create a sort of API that is called when appropriate and gives whatever information is necessary (For example, I could opt to use methods called OnPlayerHit() or IfPlayerBleeding() to implement behavior for each weapon). The issue is, I've never actually made a system as flexible as this.
      My current idea is to make a base abstract weapon class, and then have calls to all the methods when appropriate in there (OnPlayerHit() would be called whenever the player's health is subtracted from, for example). This would involve creating a sub-class for every weapon type and overriding each method to make sure the behavior works appropriately. This does not feel very efficient or clean at all. I was thinking of using interfaces to allow for the implementation of whatever "event" is needed (such as having an interface for OnPlayerAttack(), which would force the creation of a method that is called whenever the player attacks something).
       
      Here's a couple unique weapon ideas I have:
      Explosion sword: Create explosion in attack direction.
      Cold sword: Chance to freeze enemies when they are hit.
      Electric sword: On attack, electricity chains damage to nearby enemies.
       
      I'm basically trying to create a sort of API that'll allow me to easily inherit from a base weapon class and add additional behaviors somehow. One thing to know is that I'm on Unity, and swapping the weapon object's weapon component whenever the weapon changes is not at all a good idea. I need some way to contain all this varying data in one Unity component that can contain a Weapon field to hold all this data. Any ideas?
       
      I'm currently considering having a WeaponController class that can contain a Weapon class, which calls all the methods I use to create unique effects in the weapon (Such as OnPlayerAttack()) when appropriate.
    • By Vu Chi Thien
      Hi fellow game devs,
      First, I would like to apologize for the wall of text.
      As you may notice I have been digging in vehicle simulation for some times now through my clutch question posts. And thanks to the generous help of you guys, especially @CombatWombat I have finished my clutch model (Really CombatWombat you deserve much more than a post upvote, I would buy you a drink if I could ha ha). 
      Now the final piece in my vehicle physic model is the differential. For now I have an open-differential model working quite well by just outputting torque 50-50 to left and right wheel. Now I would like to implement a Limited Slip Differential. I have very limited knowledge about LSD, and what I know about LSD is through readings on racer.nl documentation, watching Youtube videos, and playing around with games like Assetto Corsa and Project Cars. So this is what I understand so far:
      - The LSD acts like an open-diff when there is no torque from engine applied to the input shaft of the diff. However, in clutch-type LSD there is still an amount of binding between the left and right wheel due to preload spring.
      - When there is torque to the input shaft (on power and off power in 2 ways LSD), in ramp LSD, the ramp will push the clutch patch together, creating binding force. The amount of binding force depends on the amount of clutch patch and ramp angle, so the diff will not completely locked up and there is still difference in wheel speed between left and right wheel, but when the locking force is enough the diff will lock.
      - There also something I'm not sure is the amount of torque ratio based on road resistance torque (rolling resistance I guess)., but since I cannot extract rolling resistance from the tire model I'm using (Unity wheelCollider), I think I would not use this approach. Instead I'm going to use the speed difference in left and right wheel, similar to torsen diff. Below is my rough model with the clutch type LSD:
      speedDiff = leftWheelSpeed - rightWheelSpeed; //torque to differential input shaft. //first treat the diff as an open diff with equal torque to both wheels inputTorque = gearBoxTorque * 0.5f; //then modify torque to each wheel based on wheel speed difference //the difference in torque depends on speed difference, throttleInput (on/off power) //amount of locking force wanted at different amount of speed difference, //and preload force //torque to left wheel leftWheelTorque = inputTorque - (speedDiff * preLoadForce + lockingForce * throttleInput); //torque to right wheel rightWheelTorque = inputTorque + (speedDiff * preLoadForce + lockingForce * throttleInput); I'm putting throttle input in because from what I've read the amount of locking also depends on the amount of throttle input (harder throttle -> higher  torque input -> stronger locking). The model is nowhere near good, so please jump in and correct me.
      Also I have a few questions:
      - In torsen/geared LSD, is it correct that the diff actually never lock but only split torque based on bias ratio, which also based on speed difference between wheels? And does the bias only happen when the speed difference reaches the ratio (say 2:1 or 3:1) and below that it will act like an open diff, which basically like an open diff with an if statement to switch state?
      - Is it correct that the amount of locking force in clutch LSD depends on amount of input torque? If so, what is the threshold of the input torque to "activate" the diff (start splitting torque)? How can I get the amount of torque bias ratio (in wheelTorque = inputTorque * biasRatio) based on the speed difference or rolling resistance at wheel?
      - Is the speed at the input shaft of the diff always equals to the average speed of 2 wheels ie (left + right) / 2?
      Please help me out with this. I haven't found any topic about this yet on gamedev, and this is my final piece of the puzzle. Thank you guys very very much.
  • Advertisement