EPISODE 1632

[INTRODUCTION]

[00:00:01] ANNOUNCER: A game engine is a system used to build and run games. Game engines let the programmer work at a high level of abstraction by providing interfaces for graphics, physics and scripting. Godot is an open-source and free-to-use game engine, which makes it unusual. Its first release was in 2014 and its features in user base have grown steadily since then. 

Emilio Coppola is the Executive Director at the Godot Foundation and he joins the show to talk about the design of Godot, its scripting language, open-source and game development and more. 

Joe Nash is a developer, educator and award-winning community builder who has worked at companies including GitHub, Twilio, Unity and PayPal. Joe got a start in software development by creating mods and running servers for Garry's Mod, and game development remains his favorite way to experience and explore new technologies and concepts. 

[INTERVIEW]

[00:01:01] JN: Hello and welcome to Software Engineering Daily. My name is Joe Nash, and I'm your host for today. And I'm joined today by Emilio Coppola, the Executive Director of the Godot Foundation. Emilio, thank you so much for joining me today.

[00:01:13] EC: Thank you for having me here.

[00:01:15] JN: Well, I'm very excited to talk about Godot. Funnily enough, I mentioned before the show my path to this podcast came through Godot. I've been looking forward to this conversation. Before we get into your background and how you came to be where you are, I think we kind of have to set some context for listeners who aren't familiar. Can you tell me briefly what is Godot? 

[00:01:31] EC: Godot is an open-source game engine to make video games or apps. And it's everything that you need for it. It's the editor but also the engine that it runs and everything in it. There has a programming language. It has the entire package for you to build a game or an application. 

[00:01:49] JN: Perfect. Getting into you and your background, as I said, you're currently the Executive Director of the Godot Foundation. How did you get here? What was your journey with Godot? 

[00:01:59] EC: I started actually making videos on YouTube, tutorials and stuff like that. I really wanted to cover – like when I started, it wasn't so popular. There wasn't a lot of resources. And I wanted to teach people how to use it. Because I came from using other proprietary software. And I found, yeah, that they had so much better learning material and all that. And I prefer to watch videos. I said, "Okay, it's my time to do the community of service," and started with that. 

But after making videos and all that, I also got more involved into the production of the engine itself. I started joining the different communities where the developers hang out. And, yeah, one thing led to another, and I ended up like working a lot.

[00:02:43] JN: That's fantastic. Some of the things you mentioned there, you mentioned working on other proprietary engines and you mentioned being able to get involved with the community. Of course, one of the things about Godot is it is open-source. Can you talk to us a little bit about how that works for the engine? 

[00:02:55] EC: Yeah. Yeah. Generally speaking, I was surprised actually to find out like how closed-source the game engine world is in general. The gaming industry is not so used to dealing with open-source project. I think this is – it's not the only one, but it's a very popular option. 

But yeah, the cool thing about open-source on game engines is that you actually own all the code that is in your game. You don't have to be licensing the engine to other companies, to send it, to ship it, to modify it, to do anything you want. And that's an extra layer of flexibility that not a lot of other engines give you. 

Before being in games, I was in web development, and this is like the standard in everything web-related. You don't even notice. But everything is open-source. Yeah, this is aimed to be like I guess the first mainstream open-source project in the game developer world for most people that are studying making games and things like that. 

[00:03:52] JN: Yeah. I think that's a really great point, especially the comparison to web dev. I think this is jumping forward to some topics we'll cover in a bit. But with the recent discourse, I think one of the messages that I saw quite frequently said was like, "Oh, this is gaming's moment to catch up with web development and like how open-source has kind of redefined other tech-related industries. And so, I think it's a fantastic point.

[00:04:12] EC: Yeah. 

[00:04:13] JN: You mentioned other engines. If you were speaking to someone who is new to game development and is still looking at building out their first game and has all this landscape in front of them, all these different options, what would you say aside from being open-source, of course, sets Godot apart from those engines?

[00:04:28] EC: Well, it's very easy to use, and I think that's the biggest thing at least for me and for many other people I know. That even if open source usually has this reputation of not being very approachable, it's like mostly built from software developers to other software developers. But Godot engine is very easy to use. The editor itself has everything you need. 

And as I said before, it contains the whole package. You don't need to go to add any extra libraries or things like that. Because there are like open-source frameworks that you can use to make games. But need to use other programs to make the levels or things like that. I think that Godot is very approachable. It's very easy to pick up and start playing around with it. 

And it also has its own programming language, which it's only used in Godot. It's very similar to Python. And I actually recently noticed that nobody complains about it being hard. People have of course complaints. But nobody complains about it being hard. You can actually start working on it. If you already do any sort of programming in other language, you almost don't notice, in a week, you're already up to speed. And I think, yeah, that's the biggest advantage of Godot. How quickly you can get things done. And it's very easy to learn.

[00:05:39] JN: Yeah. I mean, as someone who's come to Godot this year, I would totally, totally agree with that. Especially, the GDScript thing is interesting. And I think it's worth spending some time on it now. And I know this has been a constant topic for everyone in the project for the last couple of months. But why does Godot have its own language? 

[00:05:54] EC: Well, at the beginning, it wasn't the case. I believe the first thing that was implemented was Lua for scripting and things like that. But after some time, what happens with general purpose languages is that they are meant to be that general-purpose to do many other things. And the advantages of having something like GDScript is that the language is completely built into all the functionalities you need to build games. 

If you compare it with Python, which is the one that has the similar syntax and the ethos, you see that it's actually faster to write GDScript because you don't have to do a lot of the stuff that Python requires from you. I remember making games in Pygame before and you have these classes that you start to need to specify itself in front of every variable that you're referencing and a lot of things like that that you don't really need to do in GDScript. And the integration with the editor and everything also make it very easy to also extend the editor. 

I think it's very nice to control that and to make it really focus on making games, not on anything else. It's not for making web servers. It's not for making – even if you could do those things, right? It's for making games.

[00:06:59] JN: Yeah. Absolutely. I'm sure someone out there has deployed Godot in headless mode to act as a web server. That definitely exists. 

[00:07:07] EC: For sure. Yeah.

[00:07:08] JN: You mentioned a couple things there that I want to jump on because I think they're really interesting. The integration with the editor. Again, I know there has been discourse here. One of the things, one of, I guess, the misconceptions I've seen swirling about this year is like, because there is such tight integration with the editor, because the editor has everything built in, it's that you need to fundamentally use Godot in mouse and keyboard mode. You can't just go – you can't start from code. You can't start developing your game in a text-only mindset. My understanding, and I haven't tried this myself yet, is that that's not the case. Is that accurate? 

[00:07:37] EC: Yeah. Yeah. You can use it as a framework if you want to. And it has been used – you can use different parts of the project. And since it's open-source, you can just take away stuff from it. Yeah, you can do everything with code if you want to. And the editor is optional if you want to really go into like all the structure of what Godot does is to simplify that process for you. It's kind of like a supercharge IDE for you. 

But it's not required that you use it. Some people use external editors to manipulate with files. You can even extend it with other programming languages like C++. You can do a lot of things with it. It's really, really flexible.

[00:08:15] JN: You've mentioned extension a couple of times as well. From within GDScript directly in the editor. You've also now mentioned C++. On the topic of C++, we've spoken about GDScript, but there are other supported languages, right?

[00:08:27] EC: Yeah. Yeah. At the moment, built-in. You can have like a GDExtension, which is like the C++ kind of like bridge. You can build some part of your logic with C++ and use it. But you can also use GDExtension to do bindings to other languages. And there are community-built ones. And there's also another built-in language other than GDScript, which is C#, which is at the moment very popular in game development world because it's the language most use for making games like in engines like Unity. There were a lot of also XNA developers around that also wanted to use C#. Those are the main ones. But there's a very popular community, like binding for Rust for instance and things like that. Yeah, there's a lot of options out there that you can use. 

[00:09:15] JN: Cool. Speaking of extensions. There's GDExtensions. And then there's other abilities like the ability to declare a script as a tool script, for example, which was one of the things that like blew my mind the most when I started getting into Godot. Can you briefly explain the extension functionality and what the different options are? 

[00:09:33] EC: Yeah. The editor itself is built in with some things that we call nodes. And nodes are elements that you can reuse in different parts of your games. And those nodes, the control nodes, which are creating the UI, are the same ones that use for also making the editor. 

The same way you're building the UI in your game, you can build tools for the editor itself that you can use to extend it. You can create functionalities for other members of your team that might need to modify something. And you want to make it easier, for instance, to import some things in the editor or things like that. You can write all that logic and extend the editor with it. 

The cool thing about having those two together is that you don't really need to learn how to extend the editor. If you already making games with Godot, you already know how to modify the editor itself. And yeah, my goal in the future would be to make it as good as possible for you to even contribute to the engine with GDScript only because it's very easy to use. But yeah, maybe it's a bit going on a tangent there. 

But yeah, you can extend any part of the editor with simple code. And if you don't want a button somewhere, you want to move it somewhere else, you can do it. You can modify all of it. And it's not that you need to recompile the entire thing. It's very, very easy to plug on play any of those plugins. 

[00:10:50] JN: Okay. Fantastic. You said a key thing there, which again is one of the most fascinating things about Godot, which is itself is built in Godot. I'm really interested in so much about this. How this decision came about? How this happened? Lots of people have heard of dogfooding. Trying your product to build your product. But this is a game engine and that's a desktop application. How does that work? 

[00:11:11] EC: Yeah. Well, it's actually when you're building the tools for making the sort of things, I don't think it makes sense to do a different set of tools for the editor and for the games. The biggest inspiration for the project for the UI side was Qt. The idea was to do something similar to Qt to build the tools for making the games. 

But after you have perfected those tools and those UI elements, why not reuse them in the rest of your projects, right? That was a little bit more like an organic growth. From getting those sort of tools available to make the games to also providing a way for users to use those tools. And if you want to have a drop-down, you don't have to code one from scratch, right? 

I learned how to make video games in GameMaker. And I don't know how it is at the moment. But at the moment, didn't have any sort of UI tool. But the entire GameMaker editor is like a UI application. What Godot does is exposes those libraries for you to use. And it makes it really easy to get quite good quality UI already there without you having to implement everything from scratch or having to depend on a third-party library. 

And same as everything else. Everything is under the MIT license. It's very permissive and you can do whatever you want with it with options like Qt, which is very popular for making desktop applications. The license is a little bit more restrictive. And you might need to license it if you want to do a commercial project. Otherwise, you need to release on an open-source license. Yeah, I think like it was more like an organic thing. I don't think it was as planned as other stuff. But yeah. 

[00:12:52] JN: Interesting. Okay. I mean, I guess one question I had about this from the start, and this is coming from I've worked on electron apps. And so, I've been deep in the desktop performance discourse, is what this means performance-wise? Because is it rendering the desktop applications in the same way as like a game? Is it pushing out a frame? is it concerned with like frames per second throughput and this kind of thing? Or is there a desktop-optimized mode? Does that make sense?

[00:13:16] EC: Yeah. There is a desktop – you can refresh it in different ways. By default, everything is built for making games. It's not going to be like that. If you're building an application, you might want to look into not refreshing the screen on every frame because you might not need to do that. But the primarily goal of the Godot engine is to make games. All the defaults are going to be for games. Yeah.

[00:13:38] JN: Perfect. Absolutely. Going back to making games and talking about actually using Godot as a game developer, and you mentioned this already, one of the things you're going to encounter as you start using Godot for the first time is these concepts of nodes and signals, which I guess are, for lack of a better word, Godot primitives. Can you talk to us a little bit about what those are and how they affect your development flow as a game developer in Godot? 

[00:14:01] EC: Godot are like the building blocks of the engine. You can do a lot of things with the nodes. And they are all inheriting from different nodes. You have like the family of the 2D nodes for everything 2D. The 3D nodes for everything that's 3D. And the control nodes for everything that's UI. You can start using them also extending them and reusing them in other projects or in the same project as well. 

Many times, when you're starting building something, you get – for instance, if you want a character, there's already a character that you can throw in there and modify very quickly. You get already the physics interactions with other elements and things like that. With the 3D as well, you have like the different sort of things you might need. Even like a car controller. A lot of high-level stuff as well. 

The cool thing about those is that you can create your own nodes. And once you get used to that, you can reuse them. You can have these units that are very, very easy to customize from the editor as well. And you don't really have to think a lot about the structure of how you're going to make your game. Some engines have a very clear idea how they want you to build these things. But in Godot, you can figure out a way that works better for you and your team, right? You can have part of the team working on some set of nodes and sharing them or doing tools on top of them so you can use them in whatever way you want. 

One thing that's really common is that, at the beginning, when you don't really know the built-in nodes, you might implement something and then you realize there's already a node that does that for you. 

[00:15:40] JN: I've done that.

[00:15:41] EC: I mean, it happens to everybody. It's quite nice to at least try them out and read a little bit about them. Because you have a lot of things already built in. That's also what's helping making games with Godot faster, right? You don't need to reinvent the wheel many times, but you can do so if you wish to.

[00:15:58] JN: Yeah. Absolutely. You mentioned the really interesting thing there of some engines are more opinionated and how you structure things. And you can kind of do it your own way. To make sure I understand what you mean there, I guess an example of that might be, for example, entity component system, which is like a way of structuring stuff that many engines use. And you can do that in Godot. You can totally use nodes to do that but it's not opinionated about that by default. Is that accurate? 

[00:16:18] EC: Yeah. Yeah. That's at least what I feel. I have a particular way of building games. But the thing about this sort of general-purpose engines is that a lot of people have their own workflows. And as we said before, you can even make a game that only has one node and that node does everything. You could do that. But it's quite flexible enough so you can do entities if you want. 

There's also a branch, a fork of Godot to do ECS if you want to actually. But I really like the nodes. I wasn't too familiar with it. It wasn't really – you usually don't go too much into object-oriented stuff. And I think this is object-oriented done the right way. Or at least it doesn't feel really bad to use, so that it's interesting to try. 

I think that, at the beginning, it's a bit confusing because it's not something you're used to seeing. But everybody I hear about, they like the system once you get used to it. And doesn't take too long. It's giving it a try.

[00:17:15] JN: Yeah. No. I'd agree with that. There's definitely a – as you start to realize how and why you should compose nodes into scenes. And you can throw scenes into scenes. And what flex does give you the structure stuff? It becomes contagious very quickly. 

One of the things you mentioned earlier was you didn't start with – GDScript didn't exist at the beginning. It was like a change that came along the way. And I think another area that's similar to that that's really interesting is the evolution of the physics engine. 

My understanding of the history here is originally using an engine called Bullet, which is a third-party engine. And then as part of Godot's philosophy of everything being [inaudible 00:17:49] being inclusive. For Godot 4.0, due to reasons, you made your own engine. And now we're kind of coming back to like the dawn of a third-party engine might be coming back in, which is Jolt. Can you run us through, I guess, like the ethos here? Why go for your own engine? Why skew third-party stuff? And then the change in ideals while we going back to third-party?

[00:18:10] EC: Yeah. Of course, one thing we want to do is, if there's already some something popular that works for everybody, use that. It's better than just having to make something from scratch. And what we used before, it worked for the Godot 3 version of it. And it was generally okay. but there were some things that we would like to improve on it. And there wasn't any flexibility for our use cases. 

The thing about this being a community-driven project and an open-source project is that sometimes you get people that come in and help. And then you don't know what might happen to them. They might disappear after a while. With the physics engines, when we were building Godot 4, that's something. There was a very active contributor that helped a lot into shaping that to be what the Godot 4 physics are. But he's no longer contributing to the project. He got like a different job. And this happens very often. 

And the problem with the physics in particular is that it's something that is not so common to find a physics engine programmer that can do something really well in this area. Because it's not only like you need to do the physics that are fun or like realistic enough. But it also needs to happen so quickly. You can do physics in a very poorly performant way and you should be fine in a lot of cases. But if you want to make it for a video game, they need to run super quick. And finding some compromises there into making it good for a game engine is really difficult. And if you know how to do that, you're probably already working on a AAA company on a proprietary engine and something like that. And it's a very relatively small budget that we have for these sorts of things. And we cannot offer super competitive salaries. 

We depend a lot on those contributions. And at the moment, there isn't a lot of active members of the community who know or who are interested in contributing there. After a while of trying to patch and to fix what Godot 4 physics engine was, there was this new physics engine that got released on MIT, which is Jots Physics. And since the license is the same as with Godot, a community member did an integration. And that's after trying it out and people using it and giving it good reviews and all that, it was a validation. Maybe this is the way to go, right? 

We get this physics engine who was using a AAA game that is already battle-tested and it's very performant. If we can use that instead, it will be better than what we can do ourselves. And the cool thing about it is that we only need to code the glue thing between Godot and this physics engine. We don't need to implement the physics ourselves, which is the difficult part. We have a lot of people that are like proficient enough to make the glue. But we don't have enough people that are proficient enough to make the physics. 

I also found out doing this – I'm not very good at physics. But I found out that some of those algorithms are also patented. Yeah. You need to kind of reimplement some things that are doing the same but are not the same implementation as some other people did. And it gets a little bit trickier. This is the story of why we ended up. Now we are considering in the future, I don't know if it's going to be 4.3 or 4.4. But we're going to be shipping Jolt probably as the default physics engine. And you'll still have the Godot physics there just in case for legacy reasons or if you want to do it. But yeah, generally speaking, it's much better than ours. I think it still has a couple features that need to be implemented in Jolt for it to be all the features that we provide. But it shouldn't be much longer to get there.

[00:21:54] JN: Yeah. That physics algorithm patent issue I feel like has been really prominent recently. Because Studio patented a really obvious and long-running way of making characters move with platforms or something. It's been a lot of that.

[00:22:06] EC: Yeah. Yeah. Yeah. It's all these sorts of things are very tricky once you get into these licenses. And since they've been operating in proprietary engines for a very long time, there's a lot of things you cannot do. But yeah, I think we're getting there. People are starting to get out of the hole. 

[00:22:24] JN: Excellent. You mentioned future versions of Godot, 4.3, 4.4. At the time of recording, 4.2 is just around the corner. Can you tell us a little bit about what's new in 4.2 and what you're most excited about? 

[00:22:36] EC: This is way too many things actually. Yeah. Actually, one of the problems, there's too much stuff to add there. I think for 4.2 in general, it was a continuation of what 4.1 was. Just getting like a better experience for developing. There's lot of features you can read on our blog post. We highlight and we show a lot of the individual features. Some might interest you more than others. But what I like is that it's getting easier also to know sometimes like what things are going wrong. How can you make them better? Before, at the beginning, it was a bit – things failed for no reason. That's at least my experience. I'm mostly making tools. And it greatly improved the workflow as well. There's a lot of things. We had to do a lot of code just to get access to some of the editor functionality that we can now get easier. 

But again, there's – the list is too long. Honestly, if you want to check the blog post, you have all the information with nice graphical animations and all that that it makes it better. Because if you say – let's say like the FSR update that you can get more frames with the same quality, unless you see it working, you don't really – yeah. 

[00:23:50] JN: Yeah. That makes a lot of sense. We'll make sure that links in the show notes as well. I guess to jump onto that a question I'm interested in here is you know you have folks who are paid and some form or another. Either through grants, or from the foundation, or from other supporting organizations. You have community contributions and you have these huge version bumps coming out. How do you decide as a project, as a community what work is making it into each release? Is that a practically planned thing? Or was it like whoever gets – there's a deadline, get it through the door and it comes through the door? How does that work? 

[00:24:21] EC: There's different ways. But mostly, our goal from the foundation side is that the people – the foundation hires will work on things that the community want. If we see there's a lot of interest from the community, for instance, in the Godot 4, there was like a rebuild of some of the areas of the engine. Because community wanted better versions of it. We can dedicate those resources there. 

But some other companies have their own interest. And sometimes those things don't align. Those features get left out. What we really want to get into the engine itself is what will benefit most of our users. That depends on the moment, right? Sometimes we get up to a point where we don't hear about the future anymore. Not because people don't like it, but because it's already working and there isn't any big issues. But sometimes the current events influence also the community to request some other things. 

 Recently, with all the controversy around Unity and other things like that, a lot of people jumped to Godot. And they are being very vocal about wanting better C# support for instance. In this case, our plan of course, C# was on our road map. But since there's a new batch of people coming in and a lot more interest that also like how can we make the experience of using C# better with the engine itself? 

But there is a group of people at the production team which actually decides what things get in and what doesn't. But it's not really the final say. It's mostly like if the feature is in line with the goals of the project and if it makes sense for a general-purpose kind of thing, it generally gets merged. 

But also, if it aligns with the road map that the teams have, if you want to add a feature, that's a very controversial thing. A lot of people want to have like a built-in 3D map editor. And it's a big feature that, before merging something like that into the project, we need to make sure that we can also support it like long-term. We need to make sure that it's good enough for people to use. 

And if you meet all the criteria and there's people interested in maintaining it and it makes sense for a general-purpose engine, we merge it. But it really is on case-by-case depending on each PR. There's too many things that come our way that might be good for one person for their workflow. And it's good to identify when those things can be a plugin or an extension for that person or studio. And what can benefit everybody. But yeah, it really depends.

[00:27:00] JN: Yeah, that makes a ton of sense. You mentioned that the recent situation of Unity and the response, which we've alluded to a couple times. And we'll come back to that in a minute. But before we get to there, I want to kind of talk about the Godot Foundation at like a higher level. Lots of open source projects go through the challenge of being like a little scrappy operation maintained in free time to having to mature and find funding. What was that journey like for Godot? What was the Inception of the Godot Foundation? 

[00:27:28] EC: Before they got a foundation, the project was operating through the Software Freedom Conservancy, which is an organization, a nonprofit organization from the US whose goal is to do just that. Being the legal entity for these open source projects. Because when you have an open-source project at the beginning that nobody like knows about, you don't have a lot of problems in terms of like getting donations, getting grants, getting those things that doesn't happen. 

But when it does happen, you suddenly need like a bank account where to receive that money. A proper document of like ownership. Who's going to be owning the project or things like that. All that was being done by the Software Freedom Conservancy. 

But once the project got bigger, and bigger and bigger, we got even too big for them to manage. And it was really nice for us to have a little bit more independence in terms of what we can do with the project itself. And there was this need of also doing other things that requires a little bit more of independence. 

For instance, if we wanted to do an asset store, which is something that people really want, it didn't fit the model that the Software Freedom Conservancy had in mind. We ended up going with our own organization. It's been quite challenging because not everybody wants to – a bank doesn't care about your open-source project. Why will they want to open a bank account for your foundation that actually has two days since it'd been open? 

It was a lot of paperwork to go through and all that. But also, we wanted to make sure that everything was done properly so that we can continue with the operations and the needs of the project. But the goal is only to support this – we are now making a few changes internally also for how we operate in terms of like we're considering making more people be part of the process of like taking decisions for the foundation and things like that. But yeah, the goal is just to make the Godot engine better. Everything we do is to structure that. Getting the donations from the companies or individuals and hiring people to work on the engine on the features that people want. And other than that, the foundation doesn't aim to do much more than this. 

I know that other foundations in open-source groups have also education programs and many other things. But ours is very small. It's very tiny. We are less than 10 people like working full-time or part-time. And our goal is just to make the engine better. I don't know if I went a little bit more on a tangent. But yeah. 

[00:30:06] JN: No. No. That's absolutely perfect. In fact, you kind of led into my next question which was going to be, with that slice of things that you take care of, the funding, possible assets or hiring people, et cetera, you mentioned some things that are explicitly things you don't touch. Are there other responsibilities or tasks that you look to other organizations in the ecosystem to support? What kind of things do you say, "Oh, we don't do that. But there's this great company we work with over here who look after that." 

[00:30:31] EC: At the moment, we've been looking a lot at other organizations to get inspiration from how they are doing things. Because it's really difficult to find what's like a good way of operating in this space. Everybody knows how the private sector works. It's kind of easy when you have a product to sell and investors or things like that. The path is really obvious. But here we look after other organizations that we admire. For instance, Blender. How they do things. And try to get for instance our funding platform, it was basically a fork of what they had. 

If you look at the designs, they're very, very similar. And also, we internally use as much open-source as possible. Our stack in general, everything that we use to work on a daily basis is open-source. We of course try to give back to those projects as well. But yeah, it's a bit tricky because each organization has their own history and their own goals, right? And even if we do like to go through like what Blender does in terms of like all this, right? The funding and how they communicate and all that, it's a different organization with a different set of users, with a different goal. And sometimes we need to improvise a little. 

[00:31:51] JN: You mentioned Blender. This is a question I've been wondering about that might be far too in the weeds but I'm going to go for it. You mentioned paperwork issues and starting up, which I imagine really varies country by country. Both Godot Foundation and Blender are registered here in the Netherlands. Is there like something in particular about the Netherlands stichting which is good for open-source foundations? Or is that a coincidence? 

[00:32:11] EC: It was honestly a coincidence. The board member who was able to do all these things was a Dutch and was living in the Netherlands and offered to do this kind of work. But I also believe it's easier to do some sort of thing especially if you have an online organization. 

I know from experience, right now I'm living in Spain, and in Spain there's a lot of things that for a foundation like this would be really hard to do when you have an online sort of organization. The paperwork and things that you have to go to very – a lot of offices all the time. And there's not a lot of things you can do online. I think it was a little bit of those. But there isn't any particular reason what I can tell you like it is better or not. But yeah. 

[00:32:53] JN: No. Thank you for scratching that itch for me. That's been really bothering me. 

[00:32:55] EC: There's also the [inaudible 00:32:56] guys who are also based in the Netherlands. 

[00:32:58] JN: Oh, really? That's fascinating. Okay. Excellent. I've got lots of new podcast guests to chase. Going back to Unity. You mentioned all the feedback that you'd received and lots of comments. And one of the things that like immediately struck me about the core Godot team and your response was like how level-headed you were all being. How the level of humility, the level of like focus on your existing vision and not bowing to the temptation to like drop everything to jump on this moment. And so, I have like a load of questions about that, which is like, firstly, how does that culture made? How do you create a team that's likeable to say we're getting like the most press we will probably get for a long time? But we're going to stay – we know what we're doing and we're staying focused on that. How did that happen? 

[00:33:44] EC: Well, I think it was like internally something that was in the making for a long time. It's not the first time that a big company screws up and we get a lot of attention. We've kind of been here before. It wasn't as big as this one. But yeah. And also, a lot of people – most of us came from making our own games or making games in companies. And we know people who work in all the other companies. We have colleagues, ex-colleagues and friends. It's kind of like the game dev community is not as big as one might think even if it's like a huge industry. 

Whenever you see something that's going wrong for game developers, the first thing that we think is this sucks. And then we think like, "Okay, it might be an opportunity for us." But the general feeling is that it's not a good thing to happen in the industry. Same with like the layoffs that are happening on AAA companies right now and all this. Our goal is not to replace what was there. Our goal was always to make Godot better. And it's a bit unfortunate sometimes that people jump to other things because they are being kicked off of what they were using, right? 

I think with our work in open-source and all this, we understand also the challenges of building all this. And we know it's difficult. And we know that there's a lot of talented people working on those companies that will never want to live through all this but are in that situation. It's a bit tricky. Because, yeah, the moment we want to, let's say, promote it, or let's say like if you did a marketing campaign during that time, which it was kind of by coincidence we launched our funding platform at the same time. It was really good in terms of getting those donations. But you're also setting the expectations for people that this will be the replacement of Unity. And then they will want that to change. And that will compromise on the vision of what Godot is and what it wants to be. 

I think it's a bit complicated. And there isn't a real incentive for us to get all those users, right? The more, the merrier. The more people that contribute, it's going to be better for everybody. But we're not going to be making more money. We're not selling licenses. There isn't an intrinsic value in us getting people to use Godot other than having more people reporting bugs, or fixing bugs, or using it. 

Yeah, I think the culture in general inside is this. We're making our own thing and we want to make this the best it can be. And we don't need to cannibalize any other project for it. We want to make Godot what's best for Godot itself. We don't want to make a better Unity or anything like that. 

Something that came from before. I remember when I was younger, I was more into these kinds of wars, right? Which console war – 

[00:36:35] JN: [inaudible 00:36:35] some form or another, right? 

[00:36:38] EC: Yeah. Exactly. But then I think when you grow older and you understand that everybody is trying to do their best where they are working, honestly, for us it was really like sad to see the state of it. And it wasn't like something that made us happy. Yeah, we're going to get – because we also understand that we're going to get now a lot of – the stakes are higher now. And for a small team, it's sometimes difficult to be there in that situation.

[00:37:05] JN: That leads me into I guess an observation that I thought was really interesting, which was tied back to I guess the lack of big open-source usage in game development, which was I think my perception was that a lot of the Unity users who were coming to Godot and fielding requests while giving feedback didn't necessarily understand what their relationship with the organization could be. That they weren't just a consumer who was like here's my money. Give me my product. And that they were in fact like able to engage and to put things forward in a different way. That there's not one person making the decisions that trickle down. How did you – I guess to what extent do you think that is true? And then secondly, if it is true, how have you approached educating those people who have a very different relationship or about how they can greater get involved with Godot? 

[00:37:55] EC: It's honestly really, really hard. Because yeah, we get people now sending us messages as if they were not able to have a voice. And that's something that it's tricky to actually educate them and tell them you can participate of the discussions. Most of the meetings we do about these particular things are open for everybody to join. And it is difficult. There's certainly also like a lot of high-profile people that jump in and they have a very big audience. That's also a bit tricky sometimes in in terms of them having one issue with the engine and not really voicing it in a very positive or constructive way. 

A lot of people getting that idea and running with it instead of they could have come to any of our open platforms, like the chat or anywhere to just talk with any of us. And sometimes it's not that the engine cannot do something or that it does it wrong. It's that they are not used to the ways of doing it. They go out the way. And once they understand it, everything's fine. But once they already complained publicly and everybody like went through all that two weeks of tweeting, things are already kind of shaky. 

[00:39:10] JN: C# performance comes to mind here. Yeah.

[00:39:13] EC: Yeah. Yeah. And it's also I think like a change that need to happen like over time. I don't think that it's going to be like something that we can speed up too much. But I'm trying to mitigate those sorts of issues. At the moment, I'm trying to get with some other team members like a Discord forum that we can use to do more development there. Because a lot of the things we used to do and we do now are on a chat that it's kind of similar to Slack or Discord. It's a Rocket chat. And many of those conversations get kind of lost. And if you're not active there, you might have lost them. But having them on a public forum will help maybe get more people involved in the process. But it requires also time for us to adapt. Because for a long time, there wasn't too many people involved, right? 

And the things that worked before might not work now. Before, it was very easy to get the people involved to say like, "Yeah, let's improve the documentation. Let's jump in and update this, update that." But the moment, we cannot see what everyone is doing with it. We need to find better ways of capturing that interest and redirecting it to the proper place. But that's something that we need to try and see what works.

[00:40:32] JN: Yeah. I think the synchronous to asynchronous modal shift is important as you start to especially time zone expand. But yeah, absolutely. 
[00:40:40] EC: Yeah. There's a lot of things happening on GitHub, which is very open. But sometimes you will find there's a PR from someone. And then nothing. No conversation. Suddenly someone approves it and then it gets merged. And if you don't really know who these people were, you don't know that maybe there was that day a meeting for reviewing like all the PRs for GDScript and to discuss like which one. And then that gets lost. Having a better way for people to access in those sorts of conversations, I think it will improve also the culture of actually how you can get involved. 

[00:41:15] JN: Great. Yeah. I mean, top tip for anyone looking here who's adjusting to remote work as well, I think. That's excellent. We've spoken about the funding. You've launched a new funding platform. But also, again, because the Unity issue. There's been some unprecedented things. The first day, I saw one of the game studios say like, "Hey, we're putting the money we put towards Unity license towards donating to these projects." That was like – again, going into comparison to web dev, that's like not a thing that happens in web dev open-source funding. That was awesome. I'm really interested, what does the height and support and particularly the funding mean for Godot as a project? We've spoken about scaling contribution, that kind of thing. But has it changed your capabilities and what you can build out and how much you can build out, for example? 

[00:41:56] EC: Yeah. Yeah. I think it's helping – we were a little bit in the red before. We were spending more money than we were getting. But we had some sort of like reserves for getting along. But we were kind of running out of funds. And it really sucks when you have to start like thinking in which ways you can raise funds and there isn't too many options. 

But thanks to this we were able to secure that. We're not in the red anymore. And we might be able to onboard maybe two or three more people that at the moment it's not sure like who are the ones that are going to be hired. I don't want to go too much into specifics. 

Yeah, we want to also improve the infrastructure sort of work that we have. Because a lot of things, when they rely on the volunteers are running well, we had a lot of issues for instance on the websites. Not the main one, but all of them. Like the Q&A platform, the documentation. All those kind of websites that we kind of have that we need to operate our own internal platforms like the chat and all that, they were having a lot of issues and they were going down constantly. And we were under attacks and a lot of things. 

Improving those things, I think it will make it easier. And up until now, there wasn't a lot of need of doing those sort of hires. Most of the people that got hired before to work on the engine was to work on codes specifically to improve the engine. But now we need a little bit more of that infrastructure work. Not only on websites but also internally in terms of like – we hired Yuri recently to work on the production work who also sped-up the releases that we do and a lot of those things that are making like the machine run smoothly without adding more people that codes. Because I think we like we have a lot of them. But it's also hard sometimes even to go through all the pull requests and all that. 

Yeah, I think it will help in those areas. But it's a bit complicated to find people. Because up until now, we hired mostly – not mostly, but all of them from the community. The community is very technical. In open-source, there isn't a lot of designers, or UX designers, or communicators, or things like that. It's a bit harder to get those. We need to start looking out. It's a bit challenging. 

I've been looking for community manager and things like that. Because we really need one. And it's getting harder, right? You need to start reaching out and you also want to make sure that they understand the philosophy behind open source and what it means to be in a project like this. There's a lot of challenges. But thankfully, the funding was like the first thing that will help us alleviate a lot of the workload we have in all these areas so we can focus on making the rest easier.

[00:44:54] JN: Perfect. As we kind of round up close to time here, there's a more questions I want to squeeze in. First of all, what are your top tips for people looking to get started contributing to Godot itself? 

[00:45:05] EC: I think joining the platforms and just being a fly on the wall, it's very good. That's at least how I started. I really didn't like the website. I went in and I was like, "Who's doing that? Who's working that?" I noticed that there wasn't a lot of activity. And then when you start knowing the people, like if you attend to any of our events like DevRelCon, or like a local meeting, or in any gaming conference, we usually hang out there. Just come and chat. And just sharing what you do is also a good way of helping. If you are doing documentation, that also not only helps other people but gets you more familiar with those areas. And then you might also see in which ways you can help.

But yeah, I think like just joining and being around the development area and seeing in which things you think you might like to work on and try them, I think it's really good. There's a lot of issues that are marked as beginner-friendly or like first issues that you can check on GitHub if you want to contribute via code. But also, if you want to help in other areas, as I said before, there's – every time we publish an article on the blog post, we first make a PR. Everything, all this is happening on GitHub. We get people sometimes helping us with our poor English. The people who are writing the articles are not natives most of the time. We need someone that's actually like goes in and fix those. And those are things that you can make. And everything is public for you to give feedback or help. Yeah.

[00:46:37] JN: Fantastic. And at the beginning you mentioned yourself [inaudible 00:46:40] a content creator. And I think with the Unity issue, there's been a bunch of new content creators on the scene. Are there any kind of content creators who are active now or have been in the past who you are particularly fond of or you'd recommend as a great starting place for people wanting to learn about Godot? 

[00:46:56] EC: For learning about Godot, I think like the best tutorials I've seen were by GDQuest. I think like they have a lot of material. I would start by that. But it depends a lot on which kind of things you want to make. I think that if you want to make something, for instance, that's a bit more advanced, you might want to find somewhere else like for something in particular. 

But what I like of the new people that came, like the new content creators, you can see they have a lot of experience. And usually, the people we have are very technical but not so artistically gifted. We get new people, like PassiveStar. Twitter has been sharing so many cool demos and things like that. And then we have a lot of like content creators that are doing this trying to make a game in Godot. You can see their experiences and they share what they made. There were like a couple big jumps recently. And a lot of people were posting in their YouTube channels. They were maybe like Unity or Game Maker or like other content creators and they made their own games in Godot. They ported the ones that they happen. There's this big one now called Road to Vostok who's making a game – a first-person shooter that was made in Unity and now is doing very nice blogs about how the transition is going. I'm really happy that the scene is not where it used to be before. And depending on what you want, you will find something. But yeah.

[00:48:26] JN: Yeah. Those are great shouts. PassiveStar also has been doing the amazing Blender, like GIFs of their node, stuff, right? [inaudible 00:48:32]. 

[00:48:33] EC: Yeah. He's going through all the praise and doing the speed run from zero to influencer. Any person going super-fast – yeah. 

[00:48:42] JN: Yeah. That's a great shout-out. Well, Emilio, thank you so much for joining us today. I've really enjoyed this. And yeah, this has been awesome. If people want to follow your work in particular or keep tabs on what you're up to, where's the best place for them to go? 

[00:48:53] EC: Well, thank you for having me. Yeah. In Twitter is emicpl and on Mastodon as well. I'm quite active in the game dev Mastodon instance. Generally, if you follow the Godot blog, you will find where I'm working on most of the time. Yeah, the usual places.

[00:49:11] JN: Perfect. Well, thank you so much. Enjoy the rest of your day.

[00:49:14] EC: Thank you. Same.

[END]