Lumberyard: Amazon's CryEngine-based engine with free source code

I don't understand why Amazon felt the need to go to these lengths in the first place. Surely they'd make a bigger impact providing the AWS plugins for Unity, UE4, CryEngine <insert future tech>?

Trusted Back-End services for games are hard to find. GameSpy, Parse, Yahoo, etc etc etc... Big names, limited shelf life, and you're screwed if you get into bed with them (first hNd experience in more than a few of these).

AWS is so established across the internet that it's one of the few services I'd feel confident in recommending to anyone.

So why bottle up dedicated services in a middleware that only a selection of people will ever use (this is not going to become as ubiquitous as Unity, it's too low level/high spec)?

My guess is we'll see the Cloud Canvas stuff surface as plugins for Unity et al eventually. Amazon wants to sell AWS after all. This feels like a pet project/lab conditions experiment.

 

Well that's not correct. I've been looking for alternatives to Unity for a long time now, because lack of c++ sources is a gargantuan disadvantage. I'm still halfway between Unity and UE4, but the problem with UE4 is that it is extremely limited in terms of writing your own shaders, lacks a proper scripting language, and is very heavy. Still waiting on Source 2 to save the day....

And you don't have to convince me about VR. I am making a VR game afterall, because I think there's interesting potential in it. It's just that I don't see it becoming a commercial success. It seems to be going completely against the natural evolution of things. Games have been becoming increasingly lightweight, portable and social over the years. But here comes VR offering you to play a with a big headset on your face, cutting you off from everything. VR will never be well-suited for esports, for the kind of mobile games that people really play, for games that you play for more than 30 minutes, etc, etc...., or any game that would break the #1 golden rule of VR game design which is to never ever affect or restrict the camera's movement unless the movement was made directly by the player's head.

Sony is supporting it, yes. But Sony also made a push for 3DTVs not so long ago. And I think VR will partly have the same problems 3DTV had: wearing something on your head is too inconvenient for most people. It works once in a while (when going to the cinema for example), but not on a regular basis. I very rarely put the headset on while developing, it just gets too irritating.

I do think AR will be starting to get big in 5 years though

 

Hmmm not as much as Unreal, yeah it has its "quirks", but it runs well on older hardware. I was developing on a Radeon 6850 when using CE and it ran 60FPS maxed out. All they really need to do is simplify the crap out of the workflow and hey presto!. My game (smaller than it was in CE) struggles to hit that on a 980TI with Unreal...

At the time, it was lighter than Unity was..

Plus it's quick to develop, my major bugbear with Unreal is you import a new mesh and it takes a while to convert the format. You add said mesh to scene, you wait for a minute again until it appears, you bake lightmass 50 times, then bake the AI, then twiddle with this / that and the other.. You never really seem to get much done..

CE has a LOT going for it, probably more than Unreal has. If there's any basis you want to work from it's CE, but that's the issue it's still only a basis and it completely depends on what Amazon do with it.

Doing it this way, Amazon can do whatever they want without licensing restrictions / revenue shares and can gain through other channels like asset stores, cloud based services for different platforms. All in all, it's just less of a headache..

 

I think the biggest thing this announcement has done for me is to make me consider taking a look at the various tech components freely available out there. And do some R&D to estimate scope of work for building a game engine/framework out of them.

It seems like a person could take something... let's say Panda3D just for example (I have no idea if it's any good just that came to mind) combined with OpenAL for sounds and music and so forth. Approaching it this way it seems like it would greatly decrease the time needed to roll a custom solution from "scratch".

 

There's no need, seriously I'm going to go out on a whim and actually say for once (instead of whining) I recommend CE (well Lumberyard) if you're doing a PC / Console game.

The learning curve is like this ----------------, instead of like a flight of stairs like other engines. So you'll open it up, try to do something and feel instantly overwhelmed, your brain will almost scream saying what are you doing?

After a couple of months, you'll start to get used to it.. Then realise how many things that would take you months, are just a couple of clicks. You don't worry about fourier transforms in water (with all the simply stunning river / ocean tools), you don't worry about AI solution bolt on's like RAIN, you don't worry about having to use stuff like APEX, you don't worry if you want to do a little cutscene, you don't worry if you need some cool particle effects, same goes for time of day systems, you'll never worry about anything graphically.

Even in artwork, it has a LOD generator so nothing to worry about there. Do your art and stick it in, you can prototype levels and some of it's good enough to use as a final product. It has Wwise, sound and audio is well taken care of the animation and character systems are AAA worthy no other way to describe them.

Finally, you don't have to worry about peformance it has always been lightning quick even with a GI solution switched on. It's the only engine that uses MSAA with deferred rendering, there's no instancing or compression / batching to worry about as it's all streamed / automatically taken care of..

Now with AWS, you don't even need to worry about multi-player (well they removed the stream compression alg and it doesn't seem to be strictly multi-cast so err). I'm sure they will improve it..

I mean nearly every complex techy bit is covered for you..

There's only two things you need to worry about, learning how to use a stereotypical AAA engine (which it is in all regards) and finally making your game.

 

I didn't invest 6+ years into Unity just to traipse off to whatever fancy new hipster engine young people are making random with.

There's a lot to be said for tool mastery. If an engine game out twice as good as Unity, it's not guaranteed I'd get twice as good results without spending at least half the time on learning all the ins and outs!

So anything "roughly equivalent" really isn't good enough.

Just had to be said.

 

Alright. I don't need to make a game because I am having a lot of fun playing D3. But I do like game dev in general. And need a break from D3 from time to time.

You're right. If everything is in Lumberyard already and is mainly all code driven vs editor driven that is what I am looking for. I can always write wrappers around the code if I see a need to.

I'll make this my pet hobby project starting this weekend. First getting it all installed and setup. Traditionally with older kits that was the hardest part so I am thinking this will be about the same.

Thanks!

 

Wow, you make it sound so good! Tempting.

I love Unity, but I really hate having to integrate all the parts from the asset store or get my programmers to do that. It is a pain and wastes a lot of time. And we are not using a lot of fancy stuff, just a time of day/weather system, AI, terrain system stuff to fix Unity's broken terrain, UMA for characters, etc.

The fact that I have two C++ programmers and we are making multiplayer makes it even more tempting.

However....what would I do with the asset store items I have spent so much money and time on? LOL

 

Don't leave us though. I would miss your insightful posts.

 

I'd also add that in general, I think ease of use is one of the most important features of an engine, because I believe it has an almost direct impact on how fun your game is in the end (due to rapid iterations, ease of trying out concepts, etc, etc...). And Unity excels at that, while still having a pretty serious and flexible API to satisfy programmers.

It's just such a shame that the sources aren't available for free, or for an acceptable price. If we had that, I think I'd stop looking for alternatives and stick with Unity for good

 

It's actually pretty simple and straightforward. First, you "install" the engine by directly extracting the .zip anywhere you want (ugh...), and then you run the .bat to launch the editor (UGGHHH....)

Just make sure you extract the engine directly into your C drive, and not in a protected folder like program files, to avoid permission problems. Took me a while to figure that out

 

A lot can be reused, depending on the seller's conditions for it... the fact is if you are doing open world, cryengine probably solves this a lot better than Unity does.

 

Well, you might want to hold on to them for a little bit.. They confirmed they are implementing a proper .FBX pipeline, it's fine if you have Maya / Max as you can use CryTools.

Also there is a few "arbitrary" limitations they are working on, like 4KM2 map size limitation for err some reason..

I suppose you could get around the map size by connecting caves or something, then loading different maps in different levels? Or just y'know add it yourself.

Apart from that, terrain based MP game? Sure, it's a dream in a basket.

 

Yes, the requirements of a project help to determine which engine would be best to use.

This leads us to one of the great strengths/weaknesses of Unity. Thanks to its open-ended structure, Unity isn't strictly designed to be best at any one game type. This makes it fantastic for prototyping and experimentation. But it makes it sub-optimal for more focused development tasks. If you want to make a FPS title, you can make it in Unity. But you'll probably get there faster and more effectively in Unreal Engine 4. If you want to make an open-world title, you can make it in Unity. But you'll probably get there faster and more effectively in Lumberyard.

Unity's free-form structure makes it ideal as a general-purpose engine. But this advantage also means that it will never be the best at anything other than being flexible. There will always be other, more focused engines that are better suited by default to the tasks they are trying to tackle. To attempt to change this would be to change the core structure of Unity. Some trade-offs you just have to live with.

 

But there are several things Unity could do, that would make life considerably easier while remaining game-neutral. For instance automagic compression and lod / merging for distant objects in open world would benefit pretty much all titles and is one of the core problems for Unity open world.

A city, a space station, a terrain, they all share same performance and authoring problems, both solved by UE4 and Cryengine by varying extents.

Culling groups is a good start, but managing assets in a rule based way is where Unity is falling behind. We would love to tag a whole bunch of objects as lod-mergable and just have it happen for us.

Open world heaven tbh - streaming is only required if you have memory issues, and for a lot of people that's not an issue.

If Unity properly integrated simplygon as a service that did all this, it would be a valid and very cool reason to pay for pro for many people who are below the 100k threshold.

Can this be solved with more staff? yes. But that's not democratising the process

 

Yeah, but still, it is starting over..again. New engine. lol

Thanks for the info though.

 

Ha ha. Well that sounds pretty straightforward I agree. Most of them are these days but occasionally something takes a bit. When I checked out HaxeFlixel last summer it was that way. Again not major just everything you installed and setup and built via command line.

I did find an editor (a simple text editor) that handled the building though so that was nice.

 

10 GB download size, deal breaker!

 

Get a bigger pipe ..

 

Plus I can't possibly think any game engine can outshine Unity in UX, workflow and editor, it's just the pinnacle. or more like the highest mountain but not quite the summit, there is room for improvement but no engine can get close. But Lumberyard is OK, better than Cry.

 

And apparently a bigger factory is needed also

 

That's because it "clicks" for you. For whatever (and mainly personal) reasons the way Unity works matches your own workflows and so forth.

It isn't that way for everyone. I wish it was. Most folks (well here anyway unsurprisingly) like the UI, the Editor usage and the worflows. And that's awesome! If it works for you then definitely it is the best engine for you.

I think Unity is a very good game engine. It just doesn't click for me personally for whatever reason. And maybe Lumberyard won't either. I will give it a test and see though. If it doesn't then I guess I'll see if I can cobble something together using various free components out there.

 

This is one of those things that sound logical, but in reality there's no reason it has to be so. It's entirely possible there could be one engine that's both general-purpose and best at a lot of genres / tasks, or theoretically, even all tasks. There is no universal "balancing" rule that controls how these things must play out.

It's easier to get if you consider that there some are engines that are just all-round bad, and which are made to be highly specialized, yet fail do work very well for even what they're specialized at.

So logic can't really be used to say anything about anything. Only actual experiments / experience can.

Unreal, Cryengine, Lumberyeard etc. might be better suited for some things indeed, but it's just something that's due to a multitude of factors, not something as simple as a rule that more general = worse for specific purpose.

And indeed, lots of studios with competent people have chosen Unity for first person shooters, open world games etc, even though they could have chosen otherwise. With these genres/requirements too, it varies which engine might be overall best suited for your goals.

 

You're kidding, right?

Editor needs major improvement, and placing large number of objects into scene is pain.
Unity's habit of placing anything you dragged into scene in the middle of nowhere at random offset is infuriating.
Rectangle select is slow, and selecting few hundred objects at once can produce LONG delays.

That's not even close to "nothing can't outshine this" level.

 

I happen to agree with this.

Unity is not perfect for all things wanted in a game, but it has some very nice features. For me, it is ease of use since I am not a programmer and the nice pipeline to other software, like Maya and PS and Substances. I like the asset store..and yeah, I buy models and then take them into Maya and modify them to match my other artwork. In the process, I learned to model my own stuff. So...keep putting models in the asset store please, developers! Whether for placeholders or for learning or for modifying or even for using in the game...like how many crates look all that different?

My programmers know C++ but they LOVE C#.

And most of all, the community. I have made some fabulous friends here, people who have lifted me up and made me feel like I can do things I never thought I could do. Many of them are asset store developers and some are like me, making games. I would be lonely elsewhere.

As for the open world thing, you are right, @hippocoder. But we have ideas that I think will work in Unity for our game. Maybe it won't be as easy or as perfect and there might be players that complain, but honestly, I think it will work great for our game, make it unique and fit our goal of immersion and interaction. Had we stuck with our original plan, our game would be less interesting than I think it will be in the end.

Without Unity...those ideas never would have happened because the ideas came from the community, the sharing of information. That is very very valuable.

Now...doesn't mean we wouldn't consider another engine for another project but not right now, and probably for quite some time since part-time programmers work very slowly.

 

That isn't the statement I was trying to make. I wasn't pointing out that Unity was "worse." I was pointing out that its nature gives it a natural disadvantage against more focused projects. You can use Unity to make an exceptional FPS game. But if you fire up a copy of the Quake 3 engine, you'll get to the point of creating a competent FPS game a lot faster. And that's because Quake 3 was a FPS from the get-go. Any branch you make of that engine is going to start off with absolutely everything you need for an FPS game right there.

And as you pointed out, simply making a more focused engine does not necessarily mean that the engine will be good. There are plenty of engines that are all-around bad, no matter what type of game they were designed to produce. Unity is a good engine. It is well-designed and well-maintained. But it was designed to be a general-purpose engine. And because of that, it will always be at a disadvantage when compared to more focused engines.

There's nothing wrong with that. The market is flooded with more focused engines. The industry spent the past thirty years making engines geared toward very specific game types. Unity represents one of the best and most capable general-purpose engines in existence. And it's popularity and widespread adoption demonstrate that there is a real need for exactly that type of general-purpose engine. As someone who enjoys experimenting with gameplay, Unity is an easy choice for me.

 

Not necessarily. It depends a lot on what kind of FPS game you want to create. Any time you want to add a new feature, you might be lucky that it suits the engine great, or you might be unlucky that it goes against the assumptions made in that specialized engine.

I think one thing we can agree on is that you start with a "more blank sheet" in Unity, and that itself can be a barrier to entry. I think some excellent FPS or open world templates or example projects - designed and battle-tested to work well enough for shipping games - could bring some of the same advantage over to Unity. But that's ideas for the future, not something we have right now in an ideal form.

 

The current game I am working on would have been more difficult to realise if I had started it in UE4 or Lumberyard. The reason for this is because I didn't know precisely what I wanted. This meant I had room to explore, experiment, try things. Unity is amazing at quick starts and experimentation.

Unity is best for beginnings, but I do struggle to finish in Unity because its only later on do you encounter problems with performance or authoring that other engines do tackle better (lod merging, management of large scenes, perf issues).

This is something I think Unity can fix though, and ultimately will mean I backed the right horse.

 

This is precisely the reason I love Unity. Other engines seem to force so much stuff down my throat that I'm not even interested in.

 

Just started the extraction of the 160,563 files contained in the archive.

Starting out with insanity. Hopefully with all of this "stuff" it means there are few holes. 160,563 files...

 

Yes, I would readily agree to that. This is why there's a balance, a trade-off. If you started off building an FPS in an FPS-focused engine, and then wanted to add some distinctly non-FPS elements later, you would have to crack the engine over your knee in order to make that happen. In Unity, mixing and matching different mechanics and systems is way, way easier. While Unity's lack of specialized focus is a disadvantage for getting to a specific end quickly, it's flexible nature makes it far better for expanding into other design disciplines.

This is why I'm not in a hurry to see Unity drastically change. Unity doesn't need to be chasing the feature-sets of more focused engines. There is incredible value in what Unity is right-now, and I feel strongly that producing a solid, well-designed general-purpose engine is a real boon to the development community. While there might be a slight barrier to entry for leaping ahead on specific tasks, the benefits of a flexible, multi-use engine far outweigh that minor quibble.

 

Can I gratuitously take this opportunity to ask what is Unity's motivation for not releasing the source code? With UE4, Lumberyard, and eventually Source 2 offering free source code, do you think this could motivate Unity to release it too?

I dunno if it's because Unity is worried that this will break the "knowledge base" of Unity's community by fragmenting the engine versions, but that certainly didn't happen with UE4. Source code access would just allow the 10% who need it to do their thing, and the rest of the community would keep using the regular Unity.

I 100% agree with that. It may sound silly, but one of the things I hate the most about UE4 is that their 'Actor' class (their version of Monobehaviour) contains functions for handling damage and such. What are gameplay-specific functions doing in a class that is supposed to be generic? Arrrgh! I want a game engine to provide me with tools to create my own structure and tools, not to provide me with an entire pre-made gameplay framework that pollutes my project

 

Well this is the way how you pay for the engine, but would you prefer to have your game on the cloud anywhere or on your own server ? I know this will be a no go for some people about multiplayer games.

I want universal fbx support so i could export static and rigged models from the majority of 3D software.
We have the same problem with textures, you must pay a Photoshop subscription because of CryTiff while i just use Paint and Gimp.

If Source 2 with great terrain features pops up, will you want to swicth again ?
It is not better to stick to one engine than swapping each time a new engine pops up ?
Or we won't be able to play your game

Non sense.
Shaders are easy to create in UE4 with the shader editor, you find thousand of example over internet for anything like advanced terrain , ice , lava , wet floor system, glass, SSS, SSAO, special effects and more.
It is not so heavy depending if you make some open world or a different game with a smaller scale that can run smoothly on lower hardware.

The downside is that users will only make FPS and you'll never see a big diversity of games like you see made with Unity for example.

 

The node-based shader editor is insanely limited compared to the way shader creation works in Unity (and also limited compared to writing shaders in an actual shading language). You can't access scene lighting information, for one. So any stylized lighting model (toon lighting, volumetric lighting, for example) is impossible. Only one person so far has managed to do toon lighting in UE4 after a crazy amount of work, and it breaks after each engine update, because they had to modify the engine's sources, plug the shader in all kinds of different obscure places, and recompile the engine in order to do that.

Epic has publicly commented on this during one of their live twitch sessions, and they said that unfortunately, allowing custom shader creation would simply require too much work because of the way the engine is made, so it will most likely never happen

 

This a really specific need. The majority goes for realistic PBR and some other styles.

 

The maximum map size is 4km x 4km = 16 km squared not 4 km squared.

Dream in a basket, do you work for amazon?

 

The closest equivalent is GameObject, not Monobehavior. Monobehavior doesn't have direct equialent, closest is UComponent.

And damage function is general-purpose, not gameplay specific, because AActor does not have health. It also checks for cover handles falloff, radial and point attacks. It is possible to define multiple damage classes, and It is possible to define multiple damage classes (even through blueprints), define different reaction for each (like different animation when hit by bullet or set on fire), and pass custom data into damage function. If you don't need it... you can just ignore it. It is something you'll end up writing yourself a lot in unity.

Speaking of shaders, as far as I'm aware it is possible to define custom hlsl code generators, basic material system covers most cases where you'll need custom shader, and if you need something VERY unusual, it is possible make something custom. That one will take a bit more time.

You have Guilty Gear Xrd which is toon shaded, Kingdom hearts has cartoonish look and is using UE4, and there's pending pull request on github that implements toon shading model.

Also, here's non-photorealistic rendering for you:
https://docs.unrealengine.com/latest/INT/Resources/Showcases/Stylized/index.html


Failing that you have full source code access. And multiple forum discussions regarding this particular topic.

 

GGXrd is using UE3, not UE4.

 

That's just an "outline and paper texture" as a post-process. All the rest is actually PBR.

And Guilty Gear is UE3, which is different

 

Are you serious? LMFAO. Do you work for crytek or amazon? Seriously, its either that or you are ill informed.

Cryengine 3 is terrible for open world multiplayer games, it is only good(even this is debatable) for FPS shooters e.g.(cs go) and games of that nature.

They are promoting the engine (marketing etc) and claiming it is optimized for first-person shooters, survival & sandbox games, racing games, sports games, and MOBAs, MMO's when it clearly is not.

These are the facts as to why that is the case.

Lumberyard is 99.9% cry engine 3.8 vanilla.

No 2d support.

Forced to use max or maya and photoshop paid subscription (mayalt doesnt work and neither does blender).

The networking layer is completely replaced. The new one has less latency, but also increases bandwidth (doesn't use the network compression system), and still transfers all data to all clients, so it will not scale well.

Steam integration has been completely removed and you are forced to use all of amazons services for leaderboards, achievements, messaging, storage.

All current CE limitations are still in place - memory restrictions, map size restrictions, AI system, and so forth.

The streaming terrain solution is called "Segmented Worlds" and it only works in single player not to mention it is unavailable/experimental and requires that you have a full licence to cry engine 3 which costs millions of dollars and you have to integrate it yourself.

Most indie developer don't have the resources to modify the cry engine source code to support large worlds (single or multiplayer) the latter being much harder. Unity and Unreal supports 20 x 20 km squared out of the box, unreal has practically infinite terrain for single player with level streaming.

Due to the complexity and overall mess of a code base, the only people fully capable of modifying the cry engine to support new complex features are the cry engine developers, since even if indie developers where some how capable, you can't distribute the modifications according to the license, only in .dll format, so community engine modifications are a no go.

Star Citizen uses cry engine 3, they purchased a full license and they had to hire a lot of former developers from crytek to help them.

The documentation is nearly non existent, I do not understand your reasoning about the learning curve, the engine is straight up hard to use and has so many limitations, its hardly worth it. The forum is a 1 page board, without any technical staff present, just the usual amazon support morons.

The lumberyard developers are posting change logs and claiming the work as their own, when it was actually fixes and changes made by crytek.

This engine is bad, there is no reason to use it.

 

If that means you don't need to install a load of stuff and other frameworks that the engine is depending on and it means you can safely test/use multiple different versions of the engine next to each other and easily tranfer projects to other computers then... that actually sounds like a near perfect solution to me. Why the "ugh"?

Stroooooongly disagree!

Exactly. Blender for example has so many neat features that would help with placing assets, moving stuff around etc.. I wonder, have you ever considered making an editor extension that mimics a bunch of blenders features like the transform axis locking, auto rotating things on surface normals while placing, snapping to vertices etc. etc.? I could imagine that to be a highly useful asset for all blender users (of which there seem to be quite a few in the community), if it is possible at all. With all the same functions, hotkeys and mouse navigation, it would make using the Unity editor a whole lot more intuitive for all the blender veterans.

 

So?

You have source code access. Make a fork and hack the lightning model to suit your needs.

Also, important thing is final look, not how you achieve it. Forcing specific tecihnique might not be a good idea.

 

You don't even have to hack the lighting model. Just pass some fake light direction info into the shader. It's actually trivial to do this in UE4

 

Well let's compare Unity and UE4 in that respect.
In Unity, I right-click->Create Shader, write my shader in a few hours or days, and I'm done
In UE4, I spend weeks trying to figure out where to "plug" the shaders in the source code and how to make them work with the defferred renderer, recompile the engine, and now my engine isn't compatible with future versions. Just for a simple shader.

Also, the end result of that "stylized rendering" demo does not look like what I'm looking for. The shading is clearly UE4's default PBR on the surfaces of the objects

But then don't you lose the ability to use UE4's light objects and have them affect the world correctly?

 

And in unity: finish the scene, find unfixable glitch in GI system or have important feature broken in the next update. Yay.

Learn "git rebase". You are supposed to be familiar with version control if you're planning to do any work in either engine.

Also there are at least five threads with people posting cartoon shaders without hacking the engine source.

 

I think you're confusing what a fact is, we never really had any trouble.. Well not with the engine anyway.!

Not sure what your point is there? Like that matters.

I'll care about that if I ever do a 2D game, which I never will.

I don't do MP games, but I gather you read that from the CE forums yeah? If it's a problem contact Lumberyard about it or make your own. Did you miss the bit where they said they're finishing off the .FBX pipeline?

Since when did Unity support large open worlds outside the box, @tatoforever and @hippocoder plus myself all tried it and it was a real PITA!.. In 4.6 the bloody editor wouldn't even open.

Plus were talking about a different "streaming" solution here, by default all textures / meshes are streamed irrelvant of whether or not you're trying to make a streaming terrain solution. Yes we all know CE had random arbitrary limits and I already mentioned it, hopefully Amazon will do away with all that rubbish..

Also saying no "indie" developer has the resources, well you'd be wrong about that.

Still are you just repeating that from the CryDev forums? I never said CE was easy to use, they will improve the documentation.. etc.

Look it's been out two days, give them some time and hold off before you know the score.

 

That somehow sounds profoundly correct to me... Especially with 5.x, Unity has given me the "almost there but not quite" feeling quite strongly.

Maybe we'll finally find a workflow which is something like do half of the development in Unity, so you get to a point where you know what you're doing, then start from scratch in Unreal.

 

It's like you are saying UE4 shader editor is bad while Unity don't have one out of the box
I don't know about shaders code, but with the shader editor i was able to make very special effects and the default assets example are really good to learn some tricks.

The subject is Amazon engine, about Unity and UE4, you should take Unity that suits your cartoon needs, because saying UE4 is bad for specific cartoon game won't help you a lot.

 

Which specific part of my post is not a fact? Let me know and I'll rectify it.

It matters, because they are claiming that that they have made VAST improvements on cry engine, when they haven't.

Its still a fact and limitation, your not the only game developer in the world.

They said they have no plans to support blender or any other DCC expect subscription based maya and max and photoshop.

Tell that to rust or the countless other large world games that use Unity.

They won't do away with it, they are not arbitrary limits, cry engine just does not have the technology implemented to go beyond its limitations, they basically said so on their own forums, the answer was, do it yourself.

I never mentioned anything about asset streaming, not sure what your point is.

I said Most indie developer, but seriously, that's your argument? (I edited the post before you posted to say "Most" instead of "no" as it was a mistake.

Why does it matter where a piece of information comes from? you said the learning curve was better than other engines, which is a not true. 2 days? They have had years working on this and this is all they can do? Not saying I can do better, in my opinion there is no reason to use lumberyard, even the name is terrible and you didn't really offer any counter argument to my post, you just picked holes in the wording and complained about where the information came from, instead of discussing the issues.

 

Jeez, you got a wedgie that woke you up on the wrong side of the bed?

We made sandbox FPS / RPG protoypes about three years ago in CE, it was well optimised and there was nothing wrong with it. Sure it took an un-reasonable amount of time to do basic things that in other engines you wouldn't blink an eyelid at, but the point was a lot of things that take ridiculous time in Unity / Unreal aren't an issue in CE due to the toolsets.

I'm not sure what part of .FBX pipeline you don't quite understand? If you can import animations etc. from the .FBX pipeline why does it matter what DCC they use? It's things like this that shows how little knowledge you have on the subject. I personally asked them for a collada import as well, if you know anything about the .FBX SDK it's an ass to work with.

I was talking about CE's compressed texture / streaming alg all along, I never mentioned anything about terrains. So where are you pulling that from?

Were not the only developers in the world? Yeah because nobody but us do 3D games, knock it off champ.

How the hell do you know they won't do away with it, seen their roadmap? Any clue what they're doing, I spoke to them and they are looking into it.

There's a million reasons to use Lumberyard, just because you can't doesn't mean many others can't. Come of FFS, people work on Irrlicht and Ogre which says it all..