Amazon open-sourced Lumberyard, renamed to O3DE

It's harder if the engine has to run on 3 different operating systems to author with, and has 20+ build targets, but all said and done, Unity does still struggle with software stability with Windows + build target windows, and that's less about drag and drop modules or gems (which package manager actually is) and more about Unity's own code quality, frankly.

The reason for this is Unity has to learn the lessons of what happens when everything becomes a moving part, including staff, apparently.

 

I'm torn on this, so it's bankrolled by a lot of companies.. For what purpose exactly? Games, general 3D rendering, film, simulation? What's the vision / priority? Are they working on this cooperatively or is going to be a free for all? Who's the main benefactor here?

What I'm alluding to is the engine just going to end up being a complete mess? In an ideal scenario with the companies involved and amount of potential funding they could make this all things to all dev's. Question is will that happen? Going by the track records of other game engines so far, probably not.

Where's the support past Amazon saying they'll do minimal crash fixes? If community based software or open source is the key why isn't Godot miles ahead of Unity? Why is Xenko abandonware? Why does UE have long standing issues? Who does the re-fit when the engine gets outdated and how does that fit into the pipeline of existing projects or toolsets? Again, who is leading the charge here?

So many questions about how this is going to actually work, it's fine taking the core engine to fork off for AAA dev but in that situation it might as well be Frostbite. Down in indie land, what's the benefit exactly? I know LY is a good engine but so is UE and Unity..

 

Blender is also bankrolled by lots of huge companies. Godot, for whatever reason wasn't to the magnitude o3de is and this is part of the author's annoyance.

The reasons companies do this is usually because they have some skin in the game. Ask a company if they want to invest in the future direction of something better than cryengine 3 and your answer is usually yes, vs Godot.

 

I know and the Blender foundation is also a member of the Linux foundation, it's just nothing has been attempted on a scale this large before in terms of game engines. Although even blender has a governing body as such with a small team actively working on it, that would be Ton Roosendaal and his team.

In projects this large there does need to be someone holding the reigns, accepting what gets into the main branch, deciding its focus, actively working to improve said engine and keeping a track of all this. Again Blender has that function, who is running it on the O3DE side? Amazon?

 

Linux Foundation with input from everyone who wants to input, including you. Providing you commit source (self made, or funded) and have a good rationale and everyone agrees.

If you don't like it then just copy and change it. Make your own open source O3DE+ ... that's how it works.

 

I haven't looked into it does it have more features for 2D than Unity?

 

It does not. I find Godot to be pleasant to play around with, but people who say it is superior to Unity for 2D are most likely just uncomfortable with Unity. The biggest difference between how Godot and Unity present 2D is Godot defaults to pixels-as-units when you're creating a 2D scene. It has given people the false impression that Godot has a 2D renderer while Unity, with its arbitrary units, has "fake 2D", even though they both use quads with textures to represent sprites. If anything, I'd say the major draw for Godot is that it has very few features compared to Unity, so there is a lot less to learn in order to get started.

 

I was a little excited until I read that their scripting language of choice is LUA. Can't take such engine seriously :\
Which is shame because it have potential.

 

LUA is an ideal scripting language. Dramatically better than trying to lump everything into C#.

 

Care to explain? Is it about performance? Lack of a comprehensive framework?

 

Lua is battle tested and has been used by huge number of games. The syntax is halfway between python and pascal. Should be a ecent embedded language, as far as I'm aware.

 

Here's the thing, it's language is actually C++, not LUA. In this case when they mean scripting, they mean REALLY just artist or lightweight scripting - same as AAA games that use it for scripting.

It's only Unity's usage of the word that's normalised it. Scripting has never classically meant (and still doesn't outside of Unity, Godot and friends) making the whole game in it.Scripting is just behaviour fluff. Sure you can make a game in it, or you can make a game in Visual Scripting, but it's not actually "the" language for it. That would be C++, and any half decent studio using o3de is going to default to C++.

Unity used to have Boo, C# and JS, and these were really not optimised, and only escaped JIT in part when they had to properly compile AOT, at which point it kinda stopped being mere scripting and had to take things seriously.

In any case LUA means modding.

 

I actually started out with iOS dev and used Cocos2D back then. I'm exactly the kind of person who'd use an Engine for 2D. I didn't actually use Godot, but I briefly looked into the 2D capabilities of Godot vs Unity a couple years ago. I've read about some people that prefer Godot because it feels more "actually meant to really work in 2D" as opposed to Unity's "it's all flat 3D quads, but let's pretend we're a proper 2D engine, ok? ". I thought all of Unity's 2D stuff was confusing, awkward and weird, and I thought about the same for the game logic stuff in Godot. In the end, I didn't even start on that 2D project, too much of a headache and too little motivation. Last I checked Unity still was missing 2D features that Cocos2D already had over 10 years ago. You can probably get everything on the assetstore, but that can be its its own can of worms.

Afaik the Blender foundation has enough non-corporate revenue streams through private donations and things they sell, the corporate sponsorships simply allow them to move faster in the direction they were headed already. The skin in the game that the the big game studios have is that they (as far as I know) still mostly have their art pipelines built around Autodesk software that is subscription only and Autodesk is free to raise the prices as they please. Autodesk are probably legit scared of losing users to Blender, at some point they might want to squeeze out whatever money they still can from the studios that haven't made the jump to Blender yet. In the long term, the financial support of Blender could save those big studios a lot more money in Autodesk subscriptions that they no longer need. Also the next generation of 3D artists probably will come with a higher percentage of artists that are already familiar with it.

 

Yeah but blender got a big boost a few times from AAA, even Epic threw money at them. Unity might've too. I don't think blender is short of that but it's not me, but others saying words like "the blender of 3D engines", and they're not wrong because it's still the linux foundation's official 3D engine. I think it will be big.

Will it harm Unity? nah.

 

See, that's the thing that really gets me.

Lua's blazing fast. It tears ass through everything even in its most unoptimized form. If you're using LuaJIT, it's gonna be so performant that it's not even a concern. It also absolutely wipes the floor with Python in unoptimized states. A comprehensive framework is also kinda a weird one because Lua is, by design, entirely extensible, something that becomes near trivial using C 'em Up languages.

 

I don't understand how you'd use an untyped language for any major project whatsoever. Scripting is only viable for tasks with small scope (games generally aren't). Anything bigger and you need compile time checks. Otherwise refactoring will be complete nightmare.

Very excited about the engine but have no interest in Lua or using C or C++ for game development.

 

Writing scripts for a video game is not exactly a "major project", normally. Majority of indie games aren't major projects. Scripting languages are made for designers in the first place. So they can be untyped.

And if you want strict compile time checks, C++ is the way to go. Although you "have no interest in it"

 

Why are you writing your core engine code in your scripting language? Because this sort of thing only happens if you're writing your core engine code in your scripting language.

 

With how many people want C# I'd be surprised if someone doesn't add it in at some point.

 

Emphasis mine - exactly. As @hippocoder says, "scripting" in the traditional sense is specifically intended for tasks of small scope. Unity and a few followers moving major functionality into "scripting" is abnormal, and arguably it isn't "scripting" any more. Some major engine features are developed in C# and run through Mono or whatever. That is what is unusual and weird (but not necessarily bad).

Normally, "scripting" is used for stuff like "when this collider hits this trigger, open this door", or "when the player selects this dialog option, and this other dialog option to the tree" or "if the player has collected these 5 objects, show the win screen". It's what designers use to "glue" bits of game together, rather than what dedicated programmers use to build new functionality.

Outside of Unity and co, new functionality is usually made by extending the engine, then providing some hooks for your scripting language to integrate it into scenes.

 

I do think there are some benefits to having a scripting language that extends to the point Unity's does, but most of it is quality of life stuff. Not having to go through a whole build process to change how the rendering is handled is nice, but it's also something that can make things an absolute nightmare.

Honestly, I feel that Gems have already reached a great starting point for a well balanced scripting/engine extension system.

 

Oh, I don't have an issue with Unity's approach. I'm not saying it's bad. I'm saying it's unusual. Or, at least, that it used to be.

 

Zero-k (RTS) is using lua core engine (Spring). Very moddable.
Supreme Commander: FAF (RTS) made hugely on lua. Specifically for modding.
From The Depths has lua for extensive programming of blocks in game.
Roblox uses own variation of lua.
Even minecraft using lua for scripting in ComputerCraft mod.

None of these are simple small games, or additions.

There is also lua JIT, which has massive performance boost, in respect to lua 5.x
https://luajit.org/performance_x86.html



So yes, lua has plenty of valid in game dev usage.

 

Factorio too is very heavily dependent on Lua with nearly 6 MB of scripts (one of the smaller files at 125KB has over 5,500 lines of code).

 

Isn't most of WoW's front end LUA or something, including all mob encounters / boss logic? I recall blizzard doing substantial work on that + giving back so maybe that's why there's a lot of fast stuff here.

 

I used to mess around with the MIT X11 System source back when it wasn't quite 100% ported to x86 and did cheats like decompile AT&T SYS V X11 System source executables I had access to so I could figure out missing functionality. It was pretty massive amount of code and a lot of setup. It was a bit of fun but nothing to take seriously.

I think the messing with open source Lumberyard would be a bit of fun too, but it's so massive in scope it's something I won't mess with until I upgrade to have much more speed so my CPU needs to go to a Ryzen 5950X, double my RAM, and at least get an nVidia RTX 3000s series video card. That much new hardware adds up. I will wait though until the price gouging is finished on the RTX and other video cards generally. So, maybe by end of spring 2022.

 

Afaik, the UI interface is. Addons are written in LUA. No idea about boss logic and such, though.
.

 

I'm looking at O3DE for a while. It seems that LUA/Script Canvas (their visual script) has been designed for artist and game designer. Programmer might use it to quick test something but I think it would be better to write a component in C++.

Components in O3DE have been written in C++/LUA and can communicate each other. Instead of using "gameObject.GetComponent<Component>()", they use event bus (EBus) to communicate between component.
https://o3de.org/docs/user-guide/components/development/ebus-integration/

Lua components are activated after all C++ components have been activated. https://o3de.org/docs/user-guide/scripting/lua/ebus/

 

https://en.wikipedia.org/wiki/Category:Lua_(programming_language)-scripted_video_games

 

Lua's popularity is mostly about it's so easy to embed not because it's such a great language. Being a limited language it does fit modding well. For an internal language not so much, until you see how complex embedding almost anything else is and then constrained use of lua seems like a reasonable thing.

Which is probably often done by having a set of C++ api's that do the bulk of the work and just expose via lua what designers need. Be able to set encounter params. Fetch data about what hit what every frame and then set the damage/healing done etc...

 

I'm literally using Lua as the scripting language in my engine because of how robust it is and easy to extend to fit my needs. Lua is a popular language because it's easy to embed, fast as hell, easy to extend, and interfaces well with C through existing standard libraries that anyone can throw in a project without having to worry about licensing concerns.

edit: also it's easy to embed

edit 2: i have it on good authority that it's easy to embed

edit 3: i accidentally said "language" instead of "engine"

edit 4: i took a nap but i'm back now and just wanted to say that lua is easy to embed

 

O3DE stemmed from Lumberyard that had roots in Cryengine and guess where it originally came from? Crytek on a game we all know as Crysis..

Lua is like one of the most used AAA scripting languages out there, no discussion to be had.. It's good, it gets used a lot, simples..

 

Just adding to that lua train, i hear it's easy to embed.

 

I'm surprised that unlike JSON and Python, Unity hasn't provided a proper LUA integration. It seems to me a baseline feature of a modern engine and very much not the same scope as C# (nor should it ever be).

 

I think, that can (should) be left to the game developer in order to support game modding. Doesn't make much sense to me to support an additional language... Unity has been there and done that...

 

Here's why it shouldn't, and one of the reasons why it's a problem to keep leaving things up to the developer: it never becomes part of the engine, it never becomes prevalent. It's always a nothing that's... well, left to the developer while everyone talks about greener pastures with good reason.

 

Speaking of which I'm surprised no one else mentioned this but Lua is very lightweight at around 200 KB so you're not just adding in a very easily embedded language that has high performance. You're adding in one that will barely increase the size of it too.

 

Having full access to the entire Unity domain from lua no matter what is a big deal. Unity shouldn't do that. They have C# for that, it's more than enough to maintain. C# is Unity's Lua.
Having a restricted API for your own game is your responsibility to develop as the developer of the game.

If anyone is looking for 'greener pastures' because Unity has C# instead of Lua, they don't know what they are talking about. They do not worth maintaining another scripting language in Unity. It wasn't worth it with UnityScript or Boo either.

 

Agreed.

 

Given how much trouble some people seem to have with the existence of a Package Manager just imagine the utter pandemonium which would come with having multiple scripting environments.

This isn't a reasonable comparison. US and Boo are essentially just different sets or rules for writing Mono / .NET IL, and used the same framework to spit out executables identical to what would have been generated by equivalent C# code, with all of the same limitations. In the context being discussed here Lua would be a fundamentally different type of code being executed at a different layer of abstraction, and with a different set of limitations.

One of the major benefits of stuff like Lua is that you can use it to live modify stuff in the game. Because it's an interpreted language you don't need to recompile anything or unload/reload DLLs or go through a serialisation loop. You can just send a new text file to the device and re-run that part of the game. If you're working on large projects with long deploy times that's a massive time saver, without even thinking about the quality benefits it can give.

And that's not even thinking about other funtional benefits such as moddability, either.

 

It's pretty amazing for adding more levels/functionality to a game that's shipped. You can even deploy levels over the air, or new gameplay / bosses / UI / anything that's usually forced to be bolted down or worked around awkwardly in Unity land when actually shipping things.

DLC becomes trivial.

I think a live game is the biggest modded thing ever, really, and I would not want to touch the source code / binary unless I 100% absolutely had to.

The separation of responsibility is really powerful between C# and LUA, for most parts of game development. This entails understanding why LUA should never be given full engine access, but you should still be able to wire those parts up if you wish to, via your game.

This is also not even touching on 3rd party modding. I'm saying the dev themselves are the original and greatest modder - if they care about how much it costs to keep a game going.

It's not a big deal - most people in Unity land don't really seem to get as far as completing things.