The Role of Open Source Game Engines: Godot and O3DE

Announcer:

Today on Building the Open Metaverse

Royal O'Brien:

Really, it comes down to what the resources are, they have a familiarity. I mean, if you're a company that has been funded, you're building a game, you've got a lot of engineers that know Unreal or Unity, you should probably spend a bit of time there. Here's the thing. If I have the engineers and resources and funding, I have a time constraint that money has to be spent to build a product at the end of the day. I can't spend a ton of time trying to get into a new engine with engineers who aren't familiar with it and that kind of overhead. So it may not make sense for them in open source. But what they can do is if they decide that they want to use these engines, any of them, maybe there's a module that they like from Godot or a module that they like from O3DE that can serve their purpose. So the thing is, people think it's an all or nothing endgame, but it's not.

Announcer:

Welcome to Building the Open Metaverse, where technology experts discuss how the community is building the Open Metaverse together. Hosted by Patrick Cozzi from Cesium and Marc Petit from Epic Games.

Marc Petit:

Hello, everybody and welcome. Welcome to Building the Open Metaverse, the podcast. Where technologists share their insight on how the community is building the Metaverse together. I'm here. I'm Marc Petit from Epic Games. I'm here with my co-host, Patrick Cozzi. Hello, Patrick.

Patrick Cozzi:

Hi, Marc. Hi, everybody.

Marc Petit:

Today, we have two special guests. If ever we're going to be on message today because we want to talk about building the Open Metaverse, and we know how important game engines and graphics engines are to the metaverse, and how important open source and open standards will play to the Open Metaverse. So we're extremely lucky to have with us the two masterminds behind two open source game engines that I'm going to introduce to you. We'll start with Royal O'Brien representing O3DE. Royal, welcome to the show.

Royal O'Brien:

Thank you. Thank you for having me.

Marc Petit:

I think your title is GM of Digital Media and games at the Linux Foundation?

Royal O'Brien:

That's correct. That's exactly it.

Marc Petit:

You were formerly a Chief Evangelist in the Game Tech Division of Amazon, where you were involved with Lumberyard. So maybe you'll explain to us some lineage between Lumberyard and O3DE. Also I have the immense pleasure to have Juan Linietsky, who's the Head of our friends at Godot. You're actually the Creator and the Lead Developer of the Godot Game Engine. Welcome to the show.

Juan Linietsky:

Thank you.

Marc Petit:

So we're super happy to have both of you with us. So we would like you to describe your journey to the Metaverse. Patrick, who do we start with?

Patrick Cozzi:

Juan, do you want to start?

Juan Linietsky:

Sure. I'm not exactly sure what I could add to the conversation, but if you have any topic I could start with, that would be great.

Marc Petit:

Well, how did you get to create an open source game engine? Maybe that would be a good ... Understand your motivation and your background there.

Juan Linietsky:

Well, the story of Godot is a bit weird maybe. It used to be an in-house game engine for companies I had in South America. When I didn't do game development anymore, I just put it on GitHub as open source. It was quite major because it was used for like a couple dozen titles at the time. But it wasn't something that you could say it was more like a product. Right? It was more like an in-house tool. So people started working on it year over year. After a couple of years, it started getting really popular, like lots of downloads, like really huge community. It was a very little by little process of just like getting more and more people involved and trying to synchronize everybody. So they could have community reporting back and asking for features, and our contributors adding things.

Juan Linietsky:

No, it's a very community-developed project. I mean, there's not really any entity behind. It's very chaotic. I think probably the most interesting part you could say about the way all is developed in the open is that we don't really pay anybody to do anything. I mean, we have a lot of donations and a lot of higher people who contribute, but we don't really pay anyone to do anything. It's mostly like things happen just because there's so many people contributing down. Eventually somebody will work on what is needed, and then it will be integrated. It's not like, "Okay, we need this," and we decided. Right? It's more like somebody is like, "I made this place integrated." Of course it has to pass a lot of filters, and you have to make everybody agree.

Juan Linietsky:

Everybody has to be like, "Okay, we really want this." Right? So it's a very bureaucratic entities process and maybe getting something into the engine can take months. But it's very, very ... It works really well. It's very brute force, you could say, in the way it works. But it's very community-oriented. I mean, there's not really an authority deciding how things are going to be done or what the next steps are going to be. It's all very, you could say, organic. But I'm very happy to work this way. It's very, very interesting and very different to anything I've done before.

Patrick Cozzi:

Juan, I mean first, thank you for all your contributions to open source community. Congrats on all the success you had. It's quite, quite remarkable. As part of your origin story here, could you tell us a bit about the community and how it's grown and evolved and kind of the scale that you're executing at now?

Juan Linietsky:

Well, yeah. The community is really scaling a lot. It's very, very challenging to scale the amount of community because there's really way too many contributors. It's more than almost 2000 people contributing to the engine and probably a hundred doing it actively, like all the time.

Patrick Cozzi:

That's a great problem.

Juan Linietsky:

It's a very good problem to have, but it's very challenging. A lot of time, you are not able to give enough attention to people who want to contribute because you just don't have the resources. So that happens very often. We wish it didn't happen so much. But at the same time, we don't have the resources to just check what everybody's doing and what our contributions are done. So in the end, we focus more maybe on back fixes and these things, and then features take more time to get added because there really needs to be a lot of consensus to move forward with anything, a lot related. But it's a very interesting problem. I haven't really seen many of open source projects that are made this way. You could say most of them have a large company behind or something like that. But in the case of Godot, because it's so organic, it's very, very difficult to manage. But it's a good problem.

Juan Linietsky:

I mean, with everything like very brute forces, you could say. I mean, having myself many companies in the past, it's completely different because it's a way where you can't tell anybody. I mean, contributors to open source for a project like this work, who what they want when they want and how they want, and you have to get used to it and organize. So what they do is useful. So there's lots of discussions, lots of agreement, lots of like seeking for consensus. But in the end it works really well. You could say, it's like a market-developed open sourced project because it's all the little guys pushing together rather than just one big entity. So it works really well. To me, it's very, very interesting.

Marc Petit:

This actually reminds me of how the Blender Foundation is working, which is in contrast is very different to the Linux Foundation, right, Royal? Maybe, Royal, you want to give us a little bit of an apex of your personal journey and then kind of contrast how the Linux Foundation and all O3DE is approaching an open source game engine.

Royal O'Brien:

Certainly, certainly. So I started quite a few years over at Amazon. I came into the Lumberyard Division at the time when they were just basically showing different companies, "Hey, here's this 3D engine. You can use it. It's free. But if you want to build something that uses cloud services, you'll need to use AWS." So people are always looking for that hook. I said, 'Well, what other hooks are there?" So it made people really skittish of using it. A handful of places, I learned more, and I still learned to this day more companies that wound up using it, that we just never knew, projects like I'll talk to them. I go, "Yeah, we have this, this Rover program that actually simulates what it's like in going to caverns and Mars." I'm like, "Where's that been?" I've been working on that for years.

Royal O'Brien:

I'm like, "I never heard of that. Yeah. We never talked to anybody about it." So I spent a lot of time with them in the internal studios that were building games inside of Amazon, kind of championing that, taking a look at what do people really want. But really what it came down to was the adoption was still problematic because people were skittish about it, the licensing and things like that. So it came up in a conversation of, "Well, let's look at how do we open source this?" How do we get this to a larger market? Granted, I'm not part of Amazon. But at the time, it was look, "Amazon knows how to compete in the cloud space. So why try to compete in the engine space when they could just literally give it to everybody?"

Royal O'Brien:

So going open source was actually pretty easy. Understanding that if you can give it to everybody and everybody starts to use it, then you can compete what you're really good at, which is cloud services. They've done that. So the task was then put off to me, as a single-threaded owner, to take this and form everything around it and build this into an open source solution. You had to do the business fiscal marketing. How is it going to be from top to bottom? It's very different than what Juan's talking about because there was a lot to go through. So did all that, spent quite a bit of time. The first thing that really came out though was will it be viable technologically? Then will it be viable in the market? Technologically the problem was that it was so spaghetti coded from its origins, which remember, it's basically from the Crytech branch where you had games like Far Cry.

Royal O'Brien:

This is an engine that's had millions of games sold on it. Right? There's no question for its origins, but decoupling that make it to something more modular that the actual open source community can dive into was the viable thing. So that was the first part of it, getting it so that it was viable, putting it on standard open source tools, like CMIK, getting it off of the proprietary things, getting all of that out, and then putting it into a licensed model that anyone can actually do something with. That's why we went with the patching MIT. So that was the key. Then forming the strategy of not just how will we put it out in open source, but how will we work with other projects who want to use things that we've done or we may use some pieces that they've done.

Royal O'Brien:

The funny thing is people always ask with O3DE, "Are you competing?" In open source, you're not competing. You're actually free and freely giving everything away, including to other projects. Because if they enhance them and make them better, they wind up coming back. So after going through all that, I wound up talking to a handful of companies. I thought, "If we're going to get this engine off the ground and moving, let's look at how can we get it properly funded, get a team behind it." My background, I've built and exited from four different companies. So as an entrepreneur over 20 years, I kind of knew how to do this. So that's what I did, basically built it kind of like a company. Except it doesn't really have a customer that's selling to per se, it's being given to the world.

Royal O'Brien:

But how do you build that support system underneath of it to actually build a viable product that can grow rapidly? So that's what realistically happened. We built it, we put it out, we launched it. We made sure it was clear messaging as to where it was in its maturity, this way not to mislead anybody. From there, it's grown from where it started, at least tenfold of where we've been, where we have about 500 people that are online in Discord. That was one of the changes, instead of going to like mailing lists and traditional email, we actually put everything in Discord first because that's where you find a lot of communities now. By doing that, it created such rapid iteration. We had engineers and contributors that were coming in going, "Hey, there's a problem right here. Oh, I just fixed that," or a conversation. So it really allowed us to do fast iteration.

Royal O'Brien:

The other part about this was that instead of it being chaotic, I actually formed all the special interest groups around it because there's so many modules and pieces. Somebody's talking about build systems may not know anything about graphics or sound systems. So building those special interest groups, those micro communities was an essential piece so that the support structure when somebody comes in, and we see this every day, somebody come into general and say, "I have a problem with X." Instead of it becoming this tragedy of wall of text like Twitch, they say, "Go over to this sig and talk to them." They wind up getting about 15 people that respond exactly with what they're looking for in the tool. So that's been essential. Then putting together the technical steering committee behind it so that we can actually look at what are the features that we want to move forward. What are the features that people are looking for?

Royal O'Brien:

This is all driven by the community as well. That's the thing. So as much as we have companies involved, and they're funding it, they're not the ones that make the decisions on where the technology goes. That's driven by the community. But they support the marketing and fiscal so that we can grow that and attract more people. So that's why we've had so much growth so quickly. It's a very structured thing. You'll see that we have open calendars, anybody can jump on the meetings at any time, participate. There's a formal IRC process. So a lot of the formal pieces of building blocks of building a community, which in this case is very similar to kind of building a company that'll support itself was put in place so that we can have that rapid growth and allow people to do that.

Royal O'Brien:

As an example, Patrick was able to, they were able to stand something up incredibly fast on the platform and get exactly what they needed right there within minutes or hours of asking. By having that process of having that steering committee and the SIGs making those decisions, that means a feature comes in. We can do it really fast. We can have it come in inside of weeks or months where we know these are the modules that came in, the SIGs themselves approve these modules to come in. The TSC agrees that we're going to put all of these in on our next release, the release board does it. It happens in the testing cycle. So the big difference is that, yes, there's a lot of chaos going around, but it is organized into channels where those channels actually give us decision power to look at what do we want to do with the roadmap to move forward.

Marc Petit:

Yeah. You're leaning on the process and infrastructure of the Linux Foundation, right, which we heard from the academy software foundation on this podcast a few weeks ago, they also lean on that infrastructure. So I think it's-

Royal O'Brien:

That's right.

Marc Petit:

It's pretty beneficial to get up to speed quickly, in fact.

Royal O'Brien:

Yeah. Having the tools like the LFX tools that we use that give us all of the insight, what's happening with the project, who's contributing. The biggest thing about a project that it was at. You may have small pockets of your version where nobody's paying attention to it. A lot of those tools would tell us where the attention's going and where it's not going and where we need to raise some awareness so you don't have something gets built and it's doing wonderful. But then come to find out that it's underlying support system has been eroding out, and you'd have to wind up doing a rewrite.

Marc Petit:

So a little bit of a dive into the technology. How would you describe, I mean, we call those game engines. Are they really game engines? Maybe, Juan, how would you describe what your technology does, especially one thing ... A theme that comes back on this conversation is how as the web becomes more powerful in terms of graphics, how potentially do you see the role of Godot on the web or on future, on the web, all those kind of a new platform? So how do you describe Godot in the specificities of Godot?

Juan Linietsky:

So I think on the website, the actual technologies are coming along very nicely. I think there's going to be a turning point where you have technologies like Web Assembly and WebGPU are mainstream, and you can use them like everybody can use them. This will really allow to put really complex game engines on the web. I think unfortunately for now, Apple is kind of delaying this a bit because on their browser, some platforms, it's a bit limited. You're just going to use the latest things. Like Web Assembly with free support and everything, it's working very nicely on Chrome and Firefox, but Safari is still a bit behind. So I think we are still probably a year or two away. I mean, Apple is working on it, and they are doing their best. But you can tell that they are still a bit behind because they probably don't have as big of a browser team or something like that.

Juan Linietsky:

But I think at some point, it's going to be great because you will be able to put like a really complex game or game engine on the web and run anything you want. Right now, Godot works really well on the web. It uses WebGL2, and it uses well assembly without three support because that doesn't work in all browsers. It's okay. It's still a bit limited. I mean, there's lots of games being published with a lot, from using the HIO and everything.

Juan Linietsky:

But yeah, I think still, it's probably still maybe a year or two away from being a technology that can be used for something like this. On the other hand, like for example, one thing, we got asked a lot is that it's used a lot in schools. I think especially high schools. There's a lot of schools in the US using it for teaching programming, because Godot has a very, very strong focus on accessibility, and ease of use. It has its own scripting language, its own called editor and everything is very laid out in a way that is very easy to understand, very easy to use. So it's a great platform for learning and many schools in the US used it for this.

Juan Linietsky:

So for example, one thing they ask is that because they use it all in iPads and Chromebooks, that we can run it on the web. So we have a very nice grant from the Mozilla Foundation. Thanks to it, we could hire our networking and web contributors. So Godot Network, that you can make games on the web using Godot, which works really well. Of course, you can't do something super complex because running on the web, the editor of the engine is a bit limited. But for teaching programming, it works really, really good. So I think it's something that is getting there, on their respect of running complex content. I think WebGPU is amazing. It's a really well thought out specification. I think due to politics, it's probably took much longer than what would be nice. But on the other hand, the nice thing is that maybe the kind of hardware it's aiming for wasn't like widespread when it was proposed, but now it is.

Juan Linietsky:

So I think in the end, it's coming out at a good time because like the Direct Text 12 and Vulcan level hardware was not widespread before, and now it's everywhere. So I think it's like things are converging where I think what, you could say, was attempted like maybe a decade ago of making everything web. That didn't work back then. So most companies and everybody went to apps. I think it's probably when all these technologies are finalized, going to finally like give a second chance to all this. That's going to have like very deep implications because it's going to be much more accessible to just use anything that is out there, like any kind of game, any kind of platform, that will be really, really amazing. I'm very much looking forward to the next years.

Patrick Cozzi:

Juan, just a quick follow up for O3DE on the web, when Web Assembly and WebGPU are there, do you think that the existing C++ game engines will just be able to work on the web or do you think there's going to be a lot of changes that are necessary inside the main C++ baseline to get a great experience on the web?

Juan Linietsky:

I don't think there's need to be many changes from my experience. The main problem is, just to give you a very simple example, one of the main problems we have with game engines running on the current version of web assembly and WebGL2, is that on one side, for example, if you want to do mix audio and just do game audio, generally, you need to run audio on a thread and then mix. So we have very low latency with audio. With the current WebGPU, you can't really do it because it's just single thread. Then if you want to compensate, you have to either write your own backend in HTML5, which is very limiting because you can't use the engine one or you have to miss the audio on the same thread that you're running the game.

Juan Linietsky:

So you can have problems with the audio, like cracking or something like that. Then you have WebGL2, which is a very old standard, which is based on hardware that came out in maybe 15 years ago, which is really limiting. You can't do anything modern with it. You can do maybe those simple 3D on it, but it's like cell phone style from maybe five years ago at much. So it's very limiting what you can do with it. You come through like modern 3D graphics, very nicely with it. So right now, it's kind of limiting. But my feeling is that when we can get Web Assembly with proper threads, which for me I think ... I mean, this is not Apple's fault, what happened is that the specter vulnerability came up, and then suddenly like all versions first from HTML1 implementations were like prone to that attack.

Juan Linietsky:

So they had to block and re-write it in a way which were they were there with some boxes, and that was a huge investment for the browsers. All these delayed everything, like one. So I think now that things are finally getting together, I think it's going to be very, very great because you can pretty much do anything. You can import any application to the web. Now, that is really in C++ or any modern language like Rust or go or anything like that should run like perfectly, without any changes on the web. That's going to be really amazing. I think that's probably going to change a lot on the way we see the web.

Marc Petit:

Royal, how would you describe in contrast with O3DE and the platforms that you target? I mean, the web and the cloud, I think, go hand in hand. I'm sure you have some very specific there's views on that

Royal O'Brien:

So I mean, in regard with O3DE, the first part of it, it was targeted for Mac, PC, iOS, Android, Linux. But understand that it is CC++, but it's completely modular. So in other words, it's not like where I compile one module, and I have to eat the entire thing. The other part we're talking about here is that if you wind up looking at a lot of engines that are out there, traditionally the renderer is coded into everything on the engine. There's a lot of hooks that go along with it. So it's not like you can detach the render away from it without untying a lot of code. That's traditionally it, especially like within the editor. But that's the funny thing.

Royal O'Brien:

With O3DE, if somebody decides to build WebGPU renderer, you literally can shut off the rendering gem and turn on a Web Gem, WebGPU Gem, and you're still operational. So in other words, you don't have those kind of impacts. That's going to be really important when we're talking about modularity of pieces and making it as small as possible because somebody doesn't need all that excess code, all those excess pieces. You definitely don't want those to be linked altogether. So that's a big piece. Are we looking at web-based targets and such? Absolutely.

Royal O'Brien:

I mean, everything Juan's talking about is spot on. A lot of the stuff they're doing with the schools and stuff with Godot is fantastic because it's a great entry point when they come in. O3DE is a little bit different in that perspective where the scripting language between having like Lua or C++ or the visual scripting where you can just basically pull nodes and put them together, like what they do.

Royal O'Brien:

I think it's Minecraft where you can actually block logic together by tying nodes and lines together. It's a different area, but you're compiling it. It's made for different applications. It's where you use the right tool for the right job. So as we're moving towards web, the thing is, the other part is all of these different modules have got to be able to work asynchronously. Because if you have a lot of data flowing through just like Juan's talking about. As soon as you're talking about blocking threads, trying to pull things in or manipulate, it's going to fall over and die. If we're starting to talk about in the context of metaverse and for large scale, it's a lot of data that must be done asynchronously. I mean, I don't know about you, but when's the last time you saw an MMO that you were running around the field that locked up your entire screen because somebody with a level 50 horse came around level one area? These things pop in asynchronously.

Royal O'Brien:

So those are really critical. Having that as an underlying foundation for the entire engine is a big piece. So we've looked at some of these pieces to try and future proof what are the issues that are going to be coming around for what we can for right now? Then when you're also looking at the targets, I mean, you've got native, and then you're going to have web. I'm super excited as well with Web Assembly and WebGPU. But again, we have limitations that we're dealing within how to get there, and then of course the community embracing it. The other thing is going to be though how you're going to do interoperability with all the different 3D mesh formats and structures and things. Those are going to cause a lot of problems because now, we've got color space differences. We have texture format differences.

Royal O'Brien:

We have what it's on. So it's never just a simple problem of how it's going to come out because we've already seen even with the renderer, give it a couple different resources with different inputs, it's PBR, and I got six channels, but it can still come out wrong in every way, shape or form. So those are a lot of the pieces that instead of just looking at, okay, how can we get to the destination target? It's how can we make sure all of the tools of being able to build this experience are mature enough that somebody can build it? Because nobody wants to play the game of building a game. They want to build the game.

Marc Petit:

That's a good quote.

Patrick Cozzi:

Yeah. Well said. Look, I mean, congrats to both of you on all the community adoption and the momentum. When we think about game engines, we see them as really real-time 3D engines. With the metaverse, we see real-time 3D everywhere. Right? Maybe one day, it's your web browser. One day, it's your operating system. I'm curious, when both of you look at the landscape of these 3D engines, especially with Unity and Unreal, I mean, how do you see slotting in the open source? Are there certain use cases where the community kind of goes to the open source or certain markets? So maybe, Royal, do you want to start?

Royal O'Brien:

Sure. So really it comes down to what the resources are, they have a familiarity. I mean, if you're a company that has been funded, you're building a game, you've got a lot of engineers that know Unreal or Unity, you should probably spend a bit of time there. Here's the thing, if I have the engineers and resources and funding, I have a time constraint that that money has to be spent to build a product at the end of the day, I can't spend a ton of time trying to get into a new engine with engineers who aren't familiar with it and that kind of overhead. So it may not make sense for them in open source, but what they can do is if they decide that they want to use these engines, any of them, maybe there's a module that they like from Godot or a module that they like from O3DE that can serve their purpose.

Royal O'Brien:

So the things, people think it's an all or nothing end game. But it's not because you should be able to use the pieces from open source, build upon them and contribute back. That helps open source. It also helps accelerate your project. Or if you have a project that's out there, you want to cut the technical debt down of having to rewrite a stack, like a network stack. You could actually use one of the open source implementations, interfacing them in.

Royal O'Brien:

So how is that going to play in the future? I would say, try not to look at open source as an all-or-nothing game, but as the pieces that somebody actually needs to accomplish what they need to get done. Now, will it be mature, where it'll be the preferred thing or not? That's going to be an independent decision of who's out there. In my view, I love the idea of having commercial and open source working closely together at all times, doing modules that are compatible with each other. It helps everybody at the end of the day because there are strengths and weaknesses that are always going to come out. It's a cat and mouse game. It always is.

Marc Petit:

That's an interesting perspective. I think this idea, when the response is commercial or open source and the response is mix and match, it's actually a very interesting prospect. I'll need to think about that as the Unreal Engine guy on the show today.

Patrick Cozzi:

Royal, you know on the podcast, we're big fans of interoperability and open standards. I think we forgot to mention in your intro, but thank you for joining us at this last SIGGRAPH, the session that really kicked off this podcast.

Royal O'Brien:

Yeah. It was a lot of fun talking about the metaverse because it was interesting where you have a lot of people that are talking about all the technology in the metaverse. But the reality is that if you don't have that standardized format of how are you going to deal with intellectual property, how are you going to deal with interchange, the engine doesn't even matter to the metaverse because there's going to be some new and improved engine, “open 3D dot go“ engine that somebody will form out of somewhere that we never knew in three, four years, that can be used on the metaverse. So the reality is that it's how do we get the right interoperability to allow companies and open source and people to develop content rapidly in the metaverse and be able to share it in an orderly manner?

Royal O'Brien:

If you look at like what the studios are trying to do with intellectual property of what's out there, they're trying to find a way where they're able to share, but also make revenues where it is appropriate. This is going to be a resounding thing that happens over and over on the metaverse. So a lot of that standardization has to be, and I can say that I'm spending a lot of time in this specific area, looking at the open metaverse, how to actually build an open metaverse that's based around the standards where everybody can play in that sandbox, build what they want or make what they want. That's that sustained balanced ecosystem that has to exist and how we've wound up creating what we have today with the web on the internet.

Patrick Cozzi:

Juan, any perspectives you want to share on open standards, interoperability, and the open source and commercial game engines?

Juan Linietsky:

So I think there's a couple of things there that came to mind from the very interesting things that Royal said. So one thing I see a lot with Godot is that there really is a big demand for open source in the gaming community, game development community, you could say. If you compare maybe when Linux came out, it took a while until Linux was up to task to replace, you could say, a lot of the commercial offerings that you could say compete, but they don't really compete, but offer the same. It took like a long time to Linux, you could say, to be on the same level. On the other side, what we see is that there's a lot of companies approach us. They really want to use Godot and it's open source and everything mostly because what interests them is exactly what Royal said is like they can take the engine and they can't just modify it to feed whatever they need.

Juan Linietsky:

Then they don't have to because we use a very ... You could say, we. Godot is not copy left. It's MIT. So you can do just whatever you want with it, just like with O3DE. So like for example, you have example that that Sega came, and they took Godot. They just modify it, and they imported like Sonic colors to it. They're used to release a new Sonic game on it. They like these really heavy changes to it. They don't give them back, which is fine because that's what I believe that should be, because games are not software, I mean, are not in the same category. That worked really well. I mean, we don't expect especially the biggest companies to just use Godot and release a game. A lot of them do well. A lot of them just take whatever they need and release.

Juan Linietsky:

That's super, super important to me. It's just as Royal said. So the other things that are very interesting to me on the metaverse aspect is that I will give you an example. I think you would be pretty happy about it, Patrick, because you were very familiar with this. For example, I think when glTF 2 was released, you probably remember I wrote an article about why it's like the best format for exchange that I have seen in years, like lots of really good decisions in there, like way too many good decisions that were problematic. I work many years, like implementing COLLADA in commercial game engines and everything. There was so many things that made it so complicated that are not there in glTF 2. So it's very important.

Juan Linietsky:

So at the beginning, when we implemented glTF 2 in Godot, we just made it an import format. You put the file in there. The person uses the internal Godot files. So when you export, of course, going to use the Godot optimized file, that's going to be more optimized for a game. So we didn't really add any kind of support for just loading those files in realtime because adding the glTF to loader in real time wouldn't make any sense, just was an importer.

Juan Linietsky:

But the past few years, that completely changed. It's like, for example, just to give you very, very simple examples, from the guys making like NFT games, that let you own a piece of an asset, they really want to be able to just load and ensure glTF 2 files, because that can be something that has value and you can trade it. But even from their companies like Oculus with the new open XR APIs, when you want to download, like for example, the control model.

Juan Linietsky:

So you can see the controller that you're moving with your hand., All that is also real-time glTF 2. We continually see more and more demand for loading and sending these kind of formats in real-time. It has some really difficult challenges. For example, you don't use the same format for compress textures on mobile and on desktops. So you can't just use the same model. There are some interesting libraries. I can't remember the name of this, the one acquired by Google. There's this library that has like an intermitted format that you can convert to. I can't remember the name. But I think glTF 2 supports it.

Patrick Cozzi:

KTX 2.

Juan Linietsky:

Yeah, right. So that works really well. But right now, the quality is kind of poor. So it works okay. But not great quality, but it is getting there like little by little. So there are still some technical hurdles that need to be solve for this, but it has changes in the past few years a lot. We see that from our users that they really want to focus on format so they can just exchange and everything. So that's why I see that is ... It's super important to have assessed formats like that, that are like very easy to share, very optimized. If you open an FBX model in Godot, it may take like 30 seconds, but GI Institute takes like maybe one second because it's all optimized or really all binary.

Juan Linietsky:

So it's super important to have this open formats for this kind of metaverse, you could say, goals. So the other thing that I think may be a bit more problematic on the metaverse side is that in my experience, when you want to ... I mean, if you're looking, because there's lots of definitions of metaverse, I suppose, but if you are looking at the movie definition, like Ready Player One, where you have all these worlds connected and everything, I think the biggest problem that needs to be addressed by technology right now is that the problem. But when you make an experience where you have players that connect, there's always a problem of who has the authority on what's going on. Right?

Juan Linietsky:

That's kind of a problem because you need to tell who has the authority of what's going on. Otherwise, anybody can cheat or claim that they have something they don't have. This is a really difficult problem, but I think it's probably the key of what needs to be solved in order to move forward. Because with all the recent realization, and everything, you can solve a bit of that. But I believe that for now, it looks like there wasn't really a solution on how you can actually solve that. Because for example, if you make a multiplayer game, and you want to like make money out of it, the biggest problem is that you need to have an operative server, like something that is hosted on the cloud, in a computer that is controlled by the one who made the game.

Juan Linietsky:

So you can make sure that nobody's going to do something that is not supposed to do, like any kind of cheating or using any kind of something that's not. So everything needs to be validated. All the games, like all the Epic Games, like I don't know, League Of Legends or Fortnite or anything like that, that have this really multi-player experiences required is a really expensive servers in order to run. So it's very difficult to tell how we can achieve this.

Juan Linietsky:

So I think right now, the biggest challenge for something like an open metaverse, and this is I think very important as from the open source game engines is figuring how we can do how technologies that can let you have validate everything going on without actually requiring an actual server to do it that is element, like an entity. I think that's the biggest challenge, maybe for very simple games. Maybe you can solve it because you can have like a hash ownership or something like that. But for something more complex, it seems there isn't an answer yet for that. There's not a lot of research on it. I think that's where probably things need to be focusing more in the future.

Royal O'Brien:

Yeah. I think to kind of parlay on that too, if you take a look at the history of what we've done, we started out ... If remember Web 1.0 was where everybody's going to have a server and everybody was going to have a client. Right? We're going to decentralize everything. Come to find out people didn't want to host their own servers. So we wound up to Web 2.0, this is where we are now. But then you have Web3, which is part of that, going back to decentralization. But unfortunately, exactly what Juan's talking about, trying to do these servers. I can tell you right now, you can play the game, but your cellphone is going to burn up in fire if you decide to become a hash node for a crypto. That's the reality. So until you're able to get that kind of horsepower that's in a distributed manner that can be trusted.

Royal O'Brien:

There's a lot of security holes that are in there if you really poke around at it, that's going to be where we want the centralization. But the reality is that it's not possible right now. Will it be in the future? Sure. I mean, I can remember some of the fun stuff that I was writing with the ... We're talking about jumping from instance to instance, like world to world. We were having fun. We had this stuff we were working on, the Quake 1 at Quake 2 engine long time ago when it was really fun to do that. Where you would literally be playing on one map when we had a portal. As you approach the portal, it would actually replicate your state node to another server. When you hit the portal, it literally threw you to another server where you had a whole bunch of new players.

Royal O'Brien:

It was that idea that we were doing. This was what, the late 90s or early 2000 that we were doing that. So it's got to be how is that stuff going to exchange? But again, who's the authority? Because we were going from dedicated server to dedicated server. That's a whole different arena right there. The other part is that to kind of tee off with the glTF 2 is that if you look at it, having the kind of standard, like we're working really closely with The Khronos Group to make sure that a lot of the standards of like Vulcan and Open XR and things like that, that we're actually adhering to them to become like a reference where somebody can learn how to use it and to make sure that they're being continually updated with new and advanced things.

Royal O'Brien:

So it's that great feedback loop that we get. Because if you don't have that standards org or that formal body that's helping move it forward, I mean, let's look at it. Email is still unencrypted to this day 30 years ago. We just have layers on top of it. All right? But yet how long did it take WhatsApp to get something moved from no encryption to end to end encryption? Maybe a year. So understand that having these kind of standards bodies are really critical because technology inherently moves slow and community needs and demands are incredibly fast. So you've got to be able to keep up with them or else we will see what's happened. I mean, if you've watched people trying to share video on IRC, that's a fun one, and that's been around forever in a day. Yet you can go on Slack and pop a new emoji from your face in there and have a nice day. So having those kind of things that are in there are actually pretty critical for how this will succeed going forward.

Marc Petit:

Yeah. That's one of the things we're trying to champion. It's a theme that we're hearing around the role of Khronos and the potential of glTF. We're actually trying to ... Working with Khronos and accelerate, and trying to be very concrete, it looks like glTF is a very strong base that we can extend. There's another strong base, which is USD, which is not open standards, open source, but it's a brilliant piece of engineering.

Marc Petit:

So the question is, how do we get completely moving, like make progress in 2022 around that interoperability agenda and solving both technological problems, governance problems? Because as you said, proper governance is pretty slow, back to your point. So how do you create? So I think that's interesting, but from this, from our vantage point, Patrick and I, the amount of goodwill and the amount of interest for this to work, I think everybody understands the metaverse is bigger than any single one company.

Marc Petit:

So we feel there is a high level of energy. So if we can contribute to be a catalyst for the conversation, but there seems to be a unanimous agreement that glTF is such a strong base, got so many things right that advocate service community was making the case of adding properties and attributes and start to get beyond the geometry.

Marc Petit:

We talked to Martin Enthed from IKEA, he was telling us the loop problem is through the 3D commerce working group. Now you can drop an Ikea piece of furniture. It will look the same mostly or 99% the same in all renderers. So it's great to see that momentum. If you guys, the open source people can also throw your weight behind it, I think it'll contribute to the momentum.

Royal O'Brien:

Yeah. There'll be some interim pieces in between of what what's actually happening. One of the things you brought up was when somebody pulls into a file format, it has to be converted and things like that, doing it kind of on the fly. But having it an open source project where you have that kind of processor that can be severed away and made into its own node. I mean, if you remember, let's really rewind the clocks for a second. You remember when Web on Phone first came out? We had that intermediate layer in between that would crunch the images and shrink the page down so you could get it across that super slow dial-up connection that they called cellular? You still had those processing nodes that helped get us over that hump. We may run into that again, where you have a lot of data coming from a lot of sources, as you change experience to experience or players that have intellectual property that's not on your system, needs to be converted, brought in, operable on your system.

Royal O'Brien:

I mean, we already know that you can throw your hammer down on one solid standard. Okay? But that just seems to never really work because everybody has their own flight of it. That's part of the game. But if you have a lot of the tools that people can actually do and drive forward that are shared, that can help really get it there. So it's not the fact of how will we get to the destination. But what are some of the tools that we're going to need to get us through those interim stages where they're not feasible right now because of what's been proliferated.

Marc Petit:

Okay. The last thing that we want you to cover is around sustainability of open source and ... We love open source. We're supporting Blender, we're supporting Godot. Royal, you need to ask. You want a program, Royal, you need to ask. You'll get a positive response, I can guarantee you.

Royal O'Brien:

(laughs) Okay.

Marc Petit:

We don't proactively go to people with them and say, "Hey, please take some money." We're not there yet. Sorry for the shameless plug!

Royal O'Brien:

Right, right. Okay.

Marc Petit:

We'll talk. But how do you sustain your endeavor? I mean, you say it's like a company, as a company, the revenue acquisition is a very different model. So how do you see scaling up open source initiatives and source, how do you envision that? So maybe, Juan, what do you do to sustain your ecosystem? You need a minimum amount of money. Right?

Juan Linietsky:

Right. So in general, for Godot, it's very organic, I suppose. There's lots of companies or individuals that just donate. There's like many small people donating. There's many companies donating. There's a couple of good amount of sponsors. So for now, on the monetary side, it's okay. Our probably is mostly that because of the nature of Godot, this is a very, very community main thing. I mean, it is really difficult to describe, but it's very, very organic and very many little guys doing something rather than a few bigger guys.

Juan Linietsky:

For example, that what we try to do is when we ... I mean, so before somebody is hired, we have a good amount of donation.s So before somebody is hired, we try to look at which contributor is doing something the best. Usually these kind of contributors really will appreciate that they can just quit their day job and just contribute all day.

Juan Linietsky:

We know who the ones doing the most productive or the best contributions are. So generally, we try to look towards that. Then we offer them if they want to work for the project. Then we try to hire the ones, but we hire them just so they continue doing what they are doing and just get more time to it. It's not that we hire them. Okay. Now, we'll do something completely different, right? Because just by brute force, we have contributors working pretty much on everything. Everything that ... I mean, it's organic that everything that needs more work, eventually it's going to get somebody to do it again, just by brute force, just by sheer amount of contributors. So what we try to do is optimize that by just trying to finance the ones doing the work that they do really good, so they can continue doing it and then doing it better.

Juan Linietsky:

That really works really, really well. It's completely different to how a company works as I ... I can tell you that because I owned many companies in the past, and this is absolutely different. It took me a few years to understand how this ticks. It's really, really different to anything else. So what we try to do is mostly finance. I mean, there's so many working for free right now and doing incredible work that is, most of them are just donating their free time to the project and doing really good work and with the best intentions. But yeah, we try to use the donations to optimize their work, not really to have employees and tell them what to do. Right? It's very, as I tell you, I'm not sure there's so many open source projects that work the way Godot works.

Juan Linietsky:

I think probably Blender Foundation is similar to an extent, but because they are doing something which is more screenable and based, they don't have so many people contributing code to them. I mean, I understand. For them, it's more difficult to find people to do something specifically. But in our case, it's kind of the opposite. We have too many people who are doing things really, really efficiently and really well. Then we need to find the sponsors who want to donate to make this world better. Right? So it's a very, very interesting problem to solve, but very, very unique, I suppose, in the way we do things.

Patrick Cozzi:

Juan, I'm super impressed with the contributor community that you've built there and to have that many contributors, I mean, it just speaks to amazing vision, right? To have that many people rally around it. I'm curious, do you have even just like a ballpark idea of when you look at all the code that's been written, was 20% of that funded and sponsored? Was 70% of it? Do you have any idea?

Juan Linietsky:

That's really difficult. I would say that nowadays, probably like 80% was not funded, it was just contributed. There's lots of work that is being contributed. I mean, most of the work actually is ... Most of the bottleneck for us is reviewing the contributions because they are really happen, we want it or not. In fact, we created a proposal system because we had so many contributions that we run into a situation where we don't really know if this is something that we should integrate to the engine or not. I mean, we started doing like meetings with our contributors to decide whether this is wanted or not. In the end, in most cases, we didn't even know. People really need this. They don't need it. So what we need is change it to assist them where we have a proposal system.

Juan Linietsky:

So now, if you want to ask something you first create a proposal in a proposal repository. Then the community goes and can discuss proposals for months and agree what they want and how it needs to be added. This is very interesting because now other contributors look at the proposals after discussions were made and just create a proposal and contribute a request. Then we have to review it. This worked really well for the past years. But now again, the volume for everything. I mean, everything we do keeps scaling up all the time. So now we have maybe a thousand per request that we have to like go and review and see if they follow the proposal, if they are done properly. In most cases, they are probably not done properly. So we have to give them feedback on how it has to be done.

Juan Linietsky:

It's always a bottleneck on merging things. I mean, we have too much code contributed or difficulty is making it into the engine in the highest quality as possible. We do a lot of automatic testing and everything. So we are all the time bottlenecked by how we integrate new things. Even if we try to filter them better now, and we have a lot of very high quality contributions, and now we have to filter them again. So it's very interesting. We try to find ways all the time to improve.

Juan Linietsky:

I mean, every time we try to find a solution where one person is the filter, we fail because there's so much volume that we need to find ways. So all the time, it has to scale. When you do compute programming and you need to scale out of threats, we need to find ways for the contributors to get things into in a way that is as parallel as possible and as high quality as possible. That's super, super difficult. It's a really good problem, but it's very difficult.

Marc Petit:

Yeah. Well, I was going to say what a good problem to have. Royal, how do you plan to scale O3DE both from a financial and community perspective?

Royal O'Brien:

Sure. O3DE came from the perspective that for one, it's only been around for six months. So understand that the amount of velocity, the reason of why we actually pooled the companies and got the funding was so that we can create the marketing, so that we can create the awareness, so that we can actually get the resources because we weren't looking at ... I mean, we could do in a traditional means where we gave it a few years and let it slow roll and build. But the demand was enough there that actually building it into the structure of what it is and getting the backing of companies and foundation. That was an essential part to really accelerating it quickly, getting faster adoption, more people onboard. So it was really a resource versus time thing. So we have a lot of people that are actually contributing now that are not part of companies. We also have companies that are contributing.

Royal O'Brien:

So when we have partners join, they don't just join where we go, "Hey, here's some money." They actually have to also contribute a project, which means they're contributing back at the same time, which helps the open source project. So for us, it's growing. It's building all of the structure that was in place to handle the scaling issues of what we know we're going to run into. When you have a key community that's very, very enthusiastic, and they're growing fast, you will run into those problems.

Royal O'Brien:

So that's why we put a lot of that structure in place early to prevent that. We're looking forward to the onslaught, and we're starting to get some of that because there's a lot of it happening. So our means of growth is really getting more people, getting it in their hands, working with the different schools, working with different companies, working with Game Jams, getting more open source smaller projects that actually want to be able to do it, more demos, which in turn brings more people in to work on this and contribute back.

Royal O'Brien:

We have some people that are actually part of the community, which is funny. They have no interest in building a game. They have no interest in actually using the 3D side of it. But they have been the ultimate cleaners and ultimate code jockeys, going through line by line, going, "Yeah, this needs to be rewritten” or “this could be done better like this." You see just continual requests, requests, requests from the community. That's been tremendous even at this early of a stage six months out of the gate. So having those tens and, in some case, hundreds of thousands of lines that get changed in between iterations, it is tough when it can become volatile and refining all that. Then you have a roadmap where so many things are coming in at the same time that it becomes difficult. But getting some kind of semblance out of it is critical.

Royal O'Brien:

That's been the focus of where we're at right now, which is taking a look at here's all of our modules. Here's the maturity. If you want to build this type, you know that you'll need these particular features, modules and things. Here's the maturity on them. So that if somebody from the community says, "You know what, I know how to actually write that shader system," they can go in look and say, "Well, it's deficient, or it needs more work." They can write and contribute. Someone else can pick that up and run with it. So it's a matter of being able to expose where the weak spots are within it, coordinate them and make them really visible so that we can have more people who want to build things on it be able to build that, and then have all the demo and materials behind it.

Royal O'Brien:

So getting it funded is not a fact of hiring people into the project because we haven't hired any engineers into the project as O3DE. Everything that's come in is either through the companies who are already involved or through the community contributors themselves. The money itself is actually used to build community connections, awareness, training, and marketing. That's where most of the money actually goes, and of course, to maintain all the services so we can scale. So it's not used to develop core, but it's used to amplify. The relationships with the companies are used with the community to help build core. Having that structure of being able to handle the scale is what allows us to be able to move at that pace. So we're anticipating well ahead of what we're already seeing. All the trends that we see right now are exactly telling us. A lot of people are coming on board continuously.

Royal O'Brien:

There's more and more people that are pulling the forks down, more people that are contributing back into the code, the PRs. I mean, we started with just a handful. We have thousands now. Again, where will we be in six months later from where we are now? Where will we be in one year, if we're tenfold of where we are now, I'll be terrified by the year after of where we're at. That's where we're going to find out how good these systems and processes really work, but we'll be able to adapt and adjust to them because of all the different ways of it being used. So we've got a lot of big plans on how we'll scale with the community. That's part of driving that balance.

Marc Petit:

Amazing. We tend to forget it's only six months old, this project. So despite the moment in time. So we're going to try to wrap this up, but before, usual question that we'd like to go through any topics that near and dear to our heart, that you would want to cover or to have covered today? Maybe, Royal, we'll start with you.

Royal O'Brien:

I mean, topics just really, for me, the big things are making sure that people understand that open source is all about sharing, and about growth, of working together. That's one of the biggest things. We're super grateful for all the partners that have been involved. I, myself I'm even grateful, just working at the Linux Foundation and working with them. The amount of things that I see and learn every day are tremendous. My background, I come from the game industry, I've been in it for 25 years. I've got tons of software. I'm actually a developer by trade for well over 30 years. We're not going to talk about my age. I've written a lot of these things and built all kinds of IP.

Royal O'Brien:

But as an engineer, it warms my heart to see all of these people contributing their time and sharing as open source and finding ways on how we can work with other open source projects to make them better, to make ourselves better, and to working with different companies. So for me, that's really the biggest piece here is how do we all grow together and move forward without creating tribal knowledge or closed sandboxes?

Juan Linietsky:

Yeah. I fully agree with what Royal has said. I think one thing that we continually get asked at Godot is how do you compete with Unity or Unreal? The truth is that we don't really do any of that. I mean, we are just creating an open project where everybody who wants to contribute contributes. We are not really aware of any roadmap from any company like Unity or Unreal. I mean, we don't really care. We are not really trying to sell anything.

Juan Linietsky:

I mean, this is a community project where people very kindly donate their free time to create it. It has a lot of challenges. It has a lot of learning from our part and how this works together. But for us, it's not really a competition or anything like that. In fact, I have noticed that for example, both from the Godot side, we have implemented many things that Unreal and Unity have made because they are really, really smart choices on how they do things.

Juan Linietsky:

But we also have seen how over time, both Unity and Unreal have implemented things that were like inspiring how Godot to do things. So I think that in the end benefits the whole industry. So that's super, super positive to me. The fact that we do something open source in general means that we are never probably going to be at, you could say, forefront of trying things with innovations, like probably the way Epic does, the sort of way Unity does. Because what we do is something more, you could say, somebody needs something. Then it gets done with contributors.

Juan Linietsky:

We are not really trying new things that may work or not work. So in the end, we are just trying to do what people need. You can probably see that in other open source projects because it's rare that an open source project is trying to spearhead innovation because we are not really investing and trying new things that may work or may not work. We are mostly trying to create something that is community-owned, that is done in a way, like it's a very different type of development model to me. We are not really trying to compete or anything like that. It's something that happens in the background while everything else is happening, I suppose. It's very, very different to me than you just can't compare it to anything else.

Marc Petit:

Yeah. Thanks for saying that because I think it's a very important thing for people to understand. Open source is not designed to be the forefront of innovation. It's designed to drive commoditization and sharing and common platform for everybody. The commercial people, it's their job to innovate and be at the bleeding edge.

Royal O'Brien:

I think that'll be the critical differentiator for engines in the metaverse will be the innovators. They will stand out.

Marc Petit:

Juan, any person, organization you want to give a shootout to today as we conclude this podcast?

Juan Linietsky:

I wanted to thank all of you for inviting us. That has been very kind. I enjoyed my time a lot here with all of you.

Marc Petit:

All right, Royal, so is there anybody that you are, a person, organization you would like to give a shout out to today?

Royal O'Brien:

Well, for starters to reiterate, I would like to thank all of you here for having me. I definitely appreciate it. It's been fantastic. I really enjoyed when we got a chance to do it back in September as well. That kind of started off in this journey. I would say on top of that, I mean, really the ones that started this journey would be over to AWS between the Lumberyard Team, Bill Vass, Andy Jassy. From the giddy-up and go statement, we actually took this out. Because without it, it would've never happened and it's been an insane journey. All the partners that have joined in and contributed to this.

Royal O'Brien:

Most importantly, the community, because they're the ones who are actually running a lot of the day to day. Without them, it wouldn't even be a project. It would be nothing. It would be like throwing code over the fence. So those are the biggest ones. Of course, the (Linux) Foundation, for giving the ability to just drive and grow this. This is probably some of the most fun I've had in my life, and I've done a lot of weird things, even from my time in the Marines.

Marc Petit:

Well, thank you guys. Thank you for the generosity. It was amazing. Thank you for your contribution to the open source movement. We know how important it is. It takes a growing importance. It will be such a fundamental element of metaverse. You guys being that involved in the community, it's amazing to see. Thank you on behalf of everybody. Thank you for being there with us. Patrick, thank you. We're seeing good momentum. We have good feedback on the podcast. So I think we're going to continue. Right? You okay continuing?

Patrick Cozzi:

Absolutely.

Marc Petit:

We have an amazing lineup of guests coming up. We had Bill Vass on the show, Royal.

Royal O'Brien:

Did you?

Marc Petit:

Yeah, he was a very interesting, his perspective was very unique, interesting. It's fascinating for us. We're just holding the microphone in front of luminaries. So it's the simplest job I ever had in my life. One of the most rewarding. Yeah, it's good. So thank you. Thank you to everybody who's listening. Please reach us on social. If you have comments, remarks, rants, proposals, critiques, we're open to everything, reviews. We want to continue to move the conversations forward, to create an open and fair metaverse. Juan, Royal, thank you. Patrick, thank you so much too. Thanks to everybody. We'll be back soon. Bye.