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

Ok, show us your AAA worthy game.! I have no problems with finishing a massive game in either CE or Unreal, CryTek would not provide support when there were major gamestopping bugs. That's neither the engines fault or our fault, Unity ground to a halt but we was using 4.6 (due to 32-bit limitations) Unity 5 addressed this issue but we'd moved on by then.

Finally Unreal 4 isn't an issue, it's just the slowest engine to work with. Got it? Make sense yeah?

 

No one said they weren't capable. Again, it doesn't mean there can't be showstopper issues for what you want to make.

 

Lee7 will no longer be with us in this thread, so there is no reason to reply to his inflammatory dialogue.

 

Last I tried UE4, which admittedly was about a year ago, C++ code took quite a while to compile. Unless your scripts are small and/or your code is generally low on errors you'll likely have to compile at least a couple times over the debugging process and it adds up pretty quickly with each script.

Unity is an entirely different beast though. They would need a very impressive implementation to pull me from C#.

 

They thankfully managed to fix the awful compilation times with a simple config setting.

 

In a closed engine sure, unless there's too many issues with said engine generally we can fix it (if we have access).. I won't deny that a lot of the issues we encounter is due to us biting off more than we can chew. I could of course just scale everything back to shear basics and release something in the next six months in any engine. Sounds a bit dull though..! Not really why I got into game development.

In the real world, in every day development all this talk is hardly ever relevant. What takes up 99% of our time is just the sheer amount of content, so were not developing a walking simulator.

It's just nice when dreaming big not have too many diversions, like water systems can take a while. We don't really need material editors, we can code stuff but it takes time.. Spline tools, decent terrain tools, cinematics and upgrades we can do but again it's just a time thing.

It's like buying a car you really wanted on a lease that puts you fiscally on a tight rope. You can afford it, but a big bill might come out of the blue and all of a sudden you have to stick it on a credit card and pay stuff off later.

 

The future of game development is visual scripting. For one, it appeals to a larger audience, mainly artists and beginners and of course the young. Why spend your time being a code jockey when you could be creating game play on the fly and have spare time for content creating? Beyond that we start implementing complete systems. Like ready made traffic systems, avionics and behavior systems. We can then focus on telling a story without the tech in the way. Of course there will still be the manual way, but by then is really pointless to reinvent the wheel. You'll be better off tweaking the system and adorning your game instead.
Unreal is rolling out the next gen blueprint which includes compiling the c++ similar to uscript for example. If they want to stay one step ahead of Amazon they will keep this paradigm from now until the end of time.
Otherwise if both systems can do the same thing and with plenty of documentation as well, then you have to have your head examined to stay with Unreal or any other engine for that matter.
Unity needs to see this sooner than later and stop feeding from the asset store. They need to make visual scripting and AI in a box a number the number one priority for the next wave of users coming on board.

 

What is and isn't a showstopper in an engine depends on the resources you have. If working around issue "X" needs more resources than you can afford (time, money) then it's a showstopper for you.

So yeah, I think we are in agreement. And that's why there is no single best engine, because one engine might fit your needs better than other and have solved more issues than others for your specific project and your specific resources.

So people need to take all that into account when choosing engines.

I originally chose Unity because of Beast. When 5 betas arrived I was trying to be optimistic. Sure there were issues, but the tech had potential, I thought.

But it doesn't. Even in a parallel universe where the implementation is flawless (and trust me, in this universe, we are FAR from that) I still think it produces bad results. Really. I see all those AAA games use enlighten and none of them has great gi. I see great materials, great reflections, great post processing, but the gi is meh at best. They look good in spite of Enlighten, not because of it. I think companies use it because their art directors like a challenge.

 

It seems to me it doesn't matter anymore "what resources you have". Look at Arkham Knight for example, got pulled from Steam due to the sheer amount of bugs and performance issues. With competition being as it is, if you want to get into commercial PC / console games in a bigger scope "indie" vain you have to be seriously careful about what you use. Because time, it's all about time..

Don't get me wrong, AAA's throw money at problems until it goes away. If you're ACTUALLY an indie, then that's not a possibility.

It's not a matter of making a game, that's the easy bit. Making a bespoke game that's good now that's the hard part..

I'm excited about Lumberyard, I think with the path they're going down it'll make certain types of games easier to deal with.

I also agree with @hippocoder, "all these new engines empower single developers to do more than they ever previously imagined could be possible." But on the flip side, you become more and more reliant on them..

 

Is it the Amazon Prime point?

 

This is the secret to shipping a good game. If you can control the time it takes by realizing how long it takes to produce every part of the game, you can ship. A lot of beginners learn, and complete tutorials, and think they can build anything, not realizing how much time it actually takes.

 

Yes my code is reliant on Unity's stuff. But you know, porting the code to UE4 probably would still be faster than porting the art. Being reliant is part of the territory. I don't think a design exists which couldn't both take advantage of an engine's strengths (to save you time) and at the same time be utterly neutral.

 

Nope and in a nutshell, that's why we have choices... Not that all of them aren't capable of doing whatever, but it's easier in some than others.

 

Ryiah, in C++, you do not work this way. You do not stop thinking when you compile the code. Also, you do not recompile stuff every 5 seconds. Now UE4 has a problem because its build system cannot just compile just one file (which not a problem with normal msvc solution), but compilation speed is not a factor. Editor speed IS a factor. Because you don't want anything to interrupt your work/thought process or get in a way. And mucking around with mouse is exaclty that - an interruption.

 

Umm not following you there chief.. What's this about a mouse and the editor?

 

Sounds like @neginfinity experiences the same kind of thing I've talked about. When I am developing a game I'll make the various content pieces in one session (whether that is my own data files, maps, images, models or whatever) in the appropriate tools. Then I go into programming mode and my mind is in a very different state focusing on programming only. Systems, functionality, etc. Continually clicking around in an editor is an interruption to the development (well programming anyway) process.

I have always kept them separate and would like to keep them separate still. I think it is why visual programming doesn't click for me and some other people. It's like left brain starts out... stop!... right brain activity required... next node left brain again... stop! right brain activity required.

On a somewhat related note that NeoAxis 3D 3 I mentioned earlier is not what I am looking for either. It's basically canned stuff. I did learn it is actually built on the Ogre3D for the 3D graphics system. So... the graphics in that demo are simply Ogre3D. And I am tired of checking things out now... been doing it nearly all day all over the net. So MOGRE it is.

 

Sounds like an artifact of crap tech. I noticed on certain web based video players shaking your mouse can cause the stream to freeze.

 

Hmm I see from @GarBenjamin response it's too "clicky", which I have to agree with.. I said before it's workflow ain't quick in anyway, sub-menu's of sub-menu's.. Freeze's for quite a while whilst converting to native engine format (saving import items), freezes when adding new mesh items to a scene, freezes when updating code, re-baking of lightmass constantly for new meshes added, adding correct physics components (usually just do complex to simple) which is in a submenu (in mesh components).. Umm I could go on quite a while there..

It did nothing for my coffee drinking habits, not exactly a showstopper in any way.. Just get's a bit annoying after you're in the editor 50 hours a week. Unity / CE is lightning quick in all regards..

Whilst Enlighten takes forever, you just kinda leave it in the background doing whatever.

I found my self faffing with lighting etc. far too much in Unreal as well.. Not sure if anyone agrees with me on that??

Apart from that, not got a bad thing to say about it..

 

@ShadowK wouldn't that just be because they didn't put the ui on its own thread, so the processes you've mentioned there are blocking? Or does every operation try to take up 100% of your cpu? Why do programs freeze?

Maybe there's a visual editor somewhere that enforces / encourages laying all of the nodes out first and then making them do something more specific after.

 

It's something I should probably look into, problem is I keep getting told off for going on tangents.. I'll get a task and a week later I've fixed bugs that annoy me then think... What was I supposed to be doing again? I have the attention span of a lemming on riddlin.

 

--CryTek.


-----

I suspect CE eaas is going free this next GDC; or at least CryTek will try and pretend they are more user friendly now, which won't work to keep eaas users after all this.

 

Or to put it another way... "We're stubbornly determined to drive ourselves into the ground".

 

That's roughly it.

Basically, the two things I hate about visual tools is that:
1. I see smaller portion of the problem compared to text file.
2. The systems tend to waste a lot of my time by making me click on stuff.

#2 is a big problem, actually, because workflow doesn't feel right.
In pure code you kinda have both your hands on keyboard, and can type, type, type, and maybe hit the flow if you're lucky and the stars are right.

In blender and manga studio, UI requires pointing device, but once again, workflow feels right. You keep one hand on pen/mouse, and another one on hotkeys. You just keep working, no interruptions, no distractions.

However, making programming tool that require a lot of mouse usage is waste of user's time. You can't quickly type with one hand, so every time you had to click through something, you waste a lot of time.

Also, #1 is very important too.
Maybe I'm too used to text, but when I see another blueprint spaghetti, I see a lot of wasted screenspace that was for some reason spent on making rounded corners, gradients, and nice-looking squiggles. In text form information is tightly packed, so usually at a glance I'll see more than when I see a screenfull of blueprint noodles. Once again, to figre out what that thing does in blueprints, I usually need to zoom in/out, and scroll around more than I would need with a text.

I honestly think that turning bottom-level operations, like addition and substraction into nodes was a very dumb move. Flowcharts and nodes may help, but it would be better if you were writing code within the node, instead of trying to do EVERYTHING with nodes.

In other word, I see no benefit from the system in current state.

The whole system looks like a lot of wasted user's time and a lot of wasted development time to me, without much benefit. Or an attempt to sacrifice user efficiency because they wanted a gimmick.

As I already said, I suspect that using lisp-style language or maybe even something functional in place of blueprints would probably be a better idea. That kind of structure will be highly similar to blueprints without of disadvantage of being visual.

A synchronous starts, takes longer to complete than expected, and blocks main/gui thread in the process.

That won't help. Instead of thinking "let's make a visual tool" people shoudl start about making efficient tool. They're too focused on it being "visual".

 

Yes and no. Previously I would have done that but IDEs started catching my silly typos and that mostly stopped.

 

My game is simple so I wouldn't have Shadow K's problem. My biggest problem is I'm lazy but lucky as far as Unity is concerned that is advantageous as I don't want to make typical game.

 

If they become free, they stay with a hard to use engine , workflow and stuck to Maya and Max, and a indie relation not so good.Lumberyard is trying to make the engine friendly , if they succeed they will get attention from beginners, artists and indies.
Perhaps Cryteck will propose source or a big feature, but i doubt they have something ready to show or will improve the workflow.

 

If they finally add official C# support to CryEngine, this is going to make an earthquake around game development communities.

 

"Spaghetti" sums it up.

I look at visual scripting as a nice way for learning or basic prototyping, but not production.

 

You can have "spaghetti" with normal code just as easily as with visual scripting. It usually means you're doing it wrong.

 

I think maybe it is another one of those things where there is no one right or wrong for it. On one hand I can see value in the visual scripting because you end up with a design diagram. And it could be a way to play around with several designs, spot outright errors as well as opportunities for improvement.

This wouldn't really explain @Ryiah or @ShadowK liking them since they both have been programming for decades just like we have... but I think for me anyway it is like I have done this kind of thing numerous times (diagramming, listing out the pieces, breaking them down, yada yada the standard practices of good software engineering) and it is the design phase. Once I have things designed (and often this is just a general "direction" of where I am heading along with a high level map of obvious pitfalls to avoid and such) I switch over to implementation mode.

It's kind of like @Frpmta said... the one is prototyping kind of work (which I see as a form of design R&D) and the other is the actual real production work.

And the goal with visual programming seems to be to wrap it all up so that the design is the implementation itself. I can see what they are thinking. Should be easier for non-programmers and should save time for programmers because you're eliminating the second half. But in reality, to express all of the logic, patterns and so forth available in an experienced programmer's toolbox it would make the blueprints toolbox just absolutely massive. And if you are already a programmer this becomes just one more thing to have to fiddle around and learn. And there is just not much motivation to do so because you can already accomplish the same end goal (and perhaps better with more flexibility) by simply pounding out the code.

Also, any experienced programmer is basically already doing the kind of thing to get the benefit of such visual tools. You'll have some design diagrams doodled out on a napkin or whatever. You'll have some stub classes and methods defined. You'll have components prebuilt that you can simply plug n play. It's not like we enjoy just typing in code just for the sake of typing in code and retype everything over and over for every project. That would be a complete waste of time.

What we do is build up a library of examples and components and even little utilities to automate various things. Establish patterns along the way and so forth. The focus is mainly on expanding out our toolbox so we can get more and more plug n play as we move forward.

Not sure if you folks will agree with that. But it is how it is for me anyway.

And now I need to get out of here and get my head stuck into the setup and api of MOGRE. I figure with a good amount of effort and luck I should have a display with a moving and perhaps even spinning(!!) cube in an hour or so.

 

Right. That's why I approach it as a glue language. Any complex functionality can be built as a reusable node and the visual language ties them together for each object's specific needs. Blueprint does have function support though so you can hide away the functionality that way too. It doesn't have to be a big mass of tangled wires.

 

There is a difference between following a sequence all based in the lines number order versus visual nodes.
One relies in your sense only, while the other also requires use of your eyes.

 

Visual scripting is to enable artists to power ahead with making games. The limitations for it are easily addressed with bricks from main programmers. I'd rather visually wire up and test a car, there's very little need for a ton of code. I could be coding AI instead.

 

its got some really cool stuff in it, UI is a bit more intimidating feels like ZBrush, everything's hidden behind something else, need to poke around for a while.
While there's not a lot of tutorials or large database of user help (same with stingray) like unity or Unreal some of the tutorials on cryengine should be transferrable as its pretty much the same, kinda. makes me wonder when cry engine will go under as this is free open source.
again I see great promise in Stingray and Lumberyard if they do it right as both companies have a lot of resources at their deposal.

I use Stingray as my realtime renderer now just because I can make all my shaders/ materials in maya and transfer them over but it lacks features for game developmet I like in unity.

Lumberyard I probably wont use but it looks very good

 

Whatever @neginfinity thinks, you can still do certain tasks much faster in BP than in code. That's not a matter of opinion.. Take a character controller which is what 150 lines of code in Unity? Well for a decent fleshed out one.

Here is the bog standard controller for a mouse / keyboard setup in BP's:



By the time you've got your variables typed, I'll of finished and moved on. Not that I'd do databases etc. using BP's but they do come in handy.

 

http://docs.unity3d.com/ScriptReference/CharacterController.SimpleMove.html probably slightly faster to script still. Maybe neck and neck?

 

There are definitely times when I feel like I could and maybe should have gone the route of artwork rather than spend so much time learning programming. At the time I got started though the tools were simply unavailable to me.

Both are the same for me. I don't simply memorize the order I have events taking place, I can visualize the code in my head to the point that I still remember code I have written years ago. I still remember the code I wrote for a text adventure game engine back in the 90s and I can tell you the mistakes and changes I would make now to improve it.

 

Sure, but a camera controller as well which doesn't dissapear through a wall (collision detection) it's about another ten BP's.. It is far quicker if you know what you're doing for general purpose stuff.

Not that I'm saying you can't do heavier components much quicker in C# / LUA, also Lumberyards FG editor takes many more steps than Unreals.. Thing is in Unreal the alternative is C++.. In Lumberyard you have LUA.!

 

It is a matter of opinion. There's short-term cost and long-term cost. You concentrate on short-term cost and ignore long-term one.

I know that code covers every need that could possibly arise in the project. I do not have this kind of guarantee with blueprints or visual programming tools in general. Therefore, blueprints need to offer significant advantage to consider switching to them. They offer nothing.

It is a decent crutch for non-programmers that can't code, but not a useful tool tool for someone who knows how to program.

It is not good enough.

Unity standard controller handles auto-crouching - yours doesn't.
Also you're working on top of ACharacter which is 200 kilobytes of code - that's not taking components in account.
As opposed to unity's 150 lines which only require Animator and Rigidbody.

----

Anyway, I propose to drop the subject.

 

Somehow I suspect the backends that allow Animator and Rigidbody to exist are around the same size.

Agreed. We are just discussing what works for ourselves after all. Nothing wrong with any of these approaches.

 

Thing is, you're coming across like it's one or the other.. In principal it's far from, you use whatever gets you there fastest. Sometimes it's BP's, sometimes it's C++ and sometimes a mixture of both.

Anyway yeah, doesn't matter suppose it's whatever someone prefers..

I know for a fact I'll mainly use Lumberyards component based LUA whenever that becomes a proper thing.

 

BPs and "mixture of both" doesn't seem to be working for me. Saw couple of people praising "mixture of both", tried it, it didn't work, experience wasn't good, and I don't want to touch BPs again. That's all there's it.

Anyway, let's just drop it.

 

I'm not sure how we got onto the topic of BP's, someone said something about having VS in Unity.. As this is a Lumberjack discussion, the beauty is there's many ways to approach it. We got FG's for beginners / artists, LUA for some component based fun / powerful coding and C++ as a backup if you need it.

All area's are well and truly covered irrelevant of preference. Unity became so popular due to the simple scripting architecture, so it's awesome on all fronts.

 

Visual scripting is used to make Unity mobile games by people that don't know coding or small PC games, why it is not good ?

Lot of people uses BP in UE4 , and some people make games 100% BP
https://forums.unrealengine.com/sho...rint-Only-Action-Hack-n-Slash&highlight=alice
Another 100% BP game

If your game is open world and it has some core streaming manager that manages what entities to spawn and destroy, than you could use entities using Blueprints only.

The only downside is BP are 10 times slower than C++ in UE4.

 

That's "ad populum"

It is not good enough because it only brings benefit to people who can't code instead of being useful for everybody. Classic mistake of concentrating too much on the newbies.

 

Or only about five times slower than Unity's C# without IL2CPP.

 

@zenGarden and @Ryiah Not to keep the BP conversation going, but they are making a BP2CPP https://trello.com/c/8Z0N60FR.

Anyways a little more analysis/opinion for lumberyard.

The good:
Components, also for the C++ the inheritance chains don't look terribly long.
Profiler

The bad:
The ocean shader still seems to have culling issues/being overly tessellated.
Integrated source control is limited to perforce.

The neutral:
Lua scripting(It's not that bad, LUA to me is a little funky but that didn't stop me from using it as a scripting language for a game engine I had made previously)

 

They are converting British Petroleum to C++?! Is there anything that can't be in C++ these days!?

 

There is lot of artists and people coming from other horizons able to make games because of visual scripting.
You can code in C++ your BP core components , than use BP to glue functionnality quickly when making level design, you should take a second look to Frosbite engine to understand why they use visual scripting for AAA games.
Anyway if you don't like it you can make full code projects without any visual scripting.

It could be fixed, because it is open source now, still i didn't see any issues using it on my test level.

 

In the pre-built test level, even when the ocean was only kinda in view the polys/draw calls seemed to spike. I haven't played with all the knobs so the quality settings probably could help.