EPISODE 1653

[INTRODUCTION]

[0:00:00] ANNOUNCER: Godot is a free open-source game engine that's growing rapidly in popularity. Ramatak is a new public benefit company founded by Godot engine veterans, Hein-Pieter van Braam and Ariel Manzue. The goal of Ramatak is to help make Godot the number one choice for creating, deploying and monetizing games on iOS and Android. Hein-Pieter joins the show today to talk about his early career in Linux infrastructure, the shift to working on game engines and his current work on Ramatak.

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 Gary's Mod. Game development remains his favorite way to experience and explore new technologies and concepts.

[INTERVIEW]

[0:01:04] JN: Welcome to Software Engineering Daily. I'm your host for today's episode, Joe Nash. Today, I'm joined by Hein-Pieter van Braam. HP is a longtime Godot contributor and games industry veteran and Co-Founder of Ramatak, which aims to make it easier to build mobile games with Godot. Welcome HP. Thank you for joining me today.

[0:01:21] HPvB: Thank you for having me.

[0:01:22] JN: We've got a bunch of talk about in relation to Godot and mobile development on Godot and Ramatak, but I want to start with your Godot journey. Because I'm aware that you're on the board for Godot and you've been a contributor for a long time. How did that start for you?

[0:01:36] HPvB: Oh, God. We can go very far back when I was a wee little kid. My dad had a ZX spectrum, and I was very interested in the basic code, etc., made games go, make computer go brrr. I learned Basic on that thing, because I wanted to make video games. Then I basically set my entire school and everything in the idea that I want to make video games. Then obviously, I ended up doing infrastructure work.

I then spent the next, what is it, 20 years, I guess, doing Linux admining, data center, development, things like that, until I got very, very, very bored with that. Then I was like, I have all these video games I want to make, so I'm going to start making a game. Previously, all I was ever ended up doing was making video game engines, right? Because I'm a nerd. I ended up, instead of making games, I ended up making game engines.

At one point, I was like, “You know what? I'm never going to make a game engine and a game, so I'm just going to pick a game engine and I'm going to use it to make a game.” I pick Godot. The first thing that happened was that Godot didn't work on newer versions of GCC. I was like, “That can't be right.” I ended up fixing that. The story since then is basically, that I still haven't made a video game and have been a video game engine engineer for the past 10 years now, I guess.

After a while, the Linux infrastructure stuff became completely unbearable. I quit my job, started a company, specifically, to do consulting for Godot, called Prehensile Tales. I've been doing that for quite a while now. Then about a year ago, Ariel approached me with an investment opportunity for a new Godot company, modeled after other startups. I was very excited. I jumped up on that. That's what I've been doing for the last year.

When I got into Godot, the community was much smaller. If you started doing things, you rose up the ranks fairly quickly. I ended up on a leadership position fairly quickly. I want to say, six months to a year, or something like that. I ended up on what was then called the Project Leadership Commission, which was when we were still a software freedom conservancy project. I then helped set up the new Godot Foundation as a nonprofit in the Netherlands. I am treasurer of that now. That is in a very brief section. I wanted to make video games, enough game engines ended up owning two game engine creation related companies, so that's fantastic. I'm doing great.

[0:04:14] JN: Living the dream. Yeah. Obviously, that was a fairly early into Godot's journey after it, I guess, went fully open source. How did you discover at the time? Where did you find Godot back then?

[0:04:27] HPvB: That's a good question. I think, I was just looking for open-source game engines. I was always interested in the topic, because I always had this in the back of my mind. Then I saw the Godot was now open-source tweet, probably, from one at some point. Then Godot went from 1.0 to 2.0. I have to say, and since this is a bit of a nerdy audience, I think this is a thing that I can relate with, too. Originally, I was like, well, this thing is I have all of this together and I can't make any technical choices myself. Originally, I dismissed it as something that I wouldn't actually be able to use, and it would be two batteries included, basically.

I actually started another game using my own engine. Then I was like, “This is not going to work.” I ended up just trying Godot, and I was super impressed by like, okay, sure, you can't make certain technical choices, which originally, really hurt me to my nerd core. Once I got used to it, I was like, actually, well, now I don't have to think about all of these things. I can just make my goddamn game. That is how it went.

I played around with a game engine called – oh, God. I can't remember now. It was the open-source version of a game engine. It was once called – used by tribes. Oh, what was it called? Oh, this is really –

[0:05:49] JN: It's going to annoy you for the whole the whole conversation now.

[0:05:51] HPvB: This is going to annoy me for the whole conversation now. It doesn't matter. Anyway, I tried that engine for a while. I used OGRE 3D for a while. In the end of us, just like, well, with Godot, you just install it and it just works.

[0:06:02] JN: TTT engine. TT engine? Heavily modified. Oh, Torque Engine.

[0:06:07] HPvB: Torque. That's it. Thank you so much.

[0:06:07] JN: Torque. We got it.

[0:06:09] HPvB: Torque Engine. Yes. Used the Torque Engine for a little while. The thing that really impressed me at the time and it was before I saw Godot was just how quickly you could make 3D scenes, but just dropping things in and the game looked like – it looked on the editor. Godot does that as well. In my opinion, just a little bit better. That is how I got there.

[0:06:31] JN: Perfect. Yeah. Makes a lot of sense. You mentioned Prehensile Tales, which first of all, fantastic name pun. Just absolutely brilliant. Then also, Ramatak, which is what most of my questions about for you today.

[0:06:41] HPvB: Sure.

[0:06:42] JN: First of all, I guess, I want to start sentencing, so what is Ramatak in like a pitch?

[0:06:47] HPvB: Ramatak is basically a distribution of the Godot engine, where we've integrated all of the nonsense that you need to make an actual game on a mobile platform. We install the Android SDKs for you and configure them correctly. We make sure that your Xcode is set up correctly, if you're on a Mac. We've done some performance improvements for the 2D and 3D renderer for mobile specifically. We added some features for the depth pass, etc., to make that just faster. We've improved the way that you can integrate with third-party profiling tools, so you can actually see what's happening on your device. A lot of this stuff has went upstream as well, so this is not entirely exclusive to Ramatak, but we have to put it all together in a very easy to use package, basically.

[0:07:38] JN: Sure.

[0:07:39] HPvB: The reasoning behind that was that what we found is that if you look at the Godot Q&As and the forums and what people ask about in Discord, it's like, everyone wants to make games on mobile, but they basically fall at the first hurdle of making, doing all of this yak shaving to get their system ready to even begin to develop a mobile game. We were like, well, the Godot project, the open-source project can't really solve this, because we can't ship out that proprietary software, and we don't want to, because as an open-source project, that's just not our mission goal. That is how it started.

The next thing, it was, okay, how do we make sure that when people have actually have made a mobile game, that they can actually make some money off of it? What we've done there is we've partnered with a ad mediation company. We have a version of the engine that basically, comes with batteries included for everything you really need for mobile.

You sign up for the mediation company, dump your API key into the Godot editor. Then you just drag your ads onto your game. Then you're done. Then you can start shipping a monetized game. That is what we want to do. The idea being that the time frame we set is basically, from not knowing anything about mobile, to being able to have a monetized game on the app store in about two hours. I think, we're getting very close to that. That's a general idea. Just make it as easy as possible for developers to either take their existing Godot game and monetize it on a mobile platform, or just use the whole tool chain for a mobile game.

[0:09:14] JN: Perfect. Okay. Yeah, speaking of that ads a piece, so in a recent GodotCon talk, you laid out, I guess, the challenges of doing an ad supported game in a way that you highlighted some issues I'd never heard before. I think, one of the things you mentioned a couple of times was that there are various reasons throughout a game's life that a mobile game developer may have to re-export, re-compile their game again, because of changes to that ads infrastructure. Can you run us through that problem and what mobile developers are dealing with there?

[0:09:41] HPvB: There's two main problems that mobile developers run into. One of them is simply the fact that Apple and Google are incredibly fickle, and they might change the rules on what you can and can't do on the store any time. They might change the type of SDKs that you need to use at any time. Every time that happens, you have to do work to keep your game on the store, keep your income from the game going. That is painful. With Godot and by extension, with Ramatak, what we can do is because it's open source, we can basically take an old version of the engine and make it so that if you re-export today, that your game works exactly as it did, like when you made it, maybe two years ago, but now with all of the new requirements from Apple and Google, etc., apply to the game that you already have.

We call that backlog management. That's, I think, something that is difficult for an open-source project to do, because finding volunteers to take a Godot version from three years ago and fixing it up, so that that particular version now works in today's app stores is difficult, because it is frankly, a little bit boring, and there is just a lot of – it's like paperwork, right? It's paper pushing work almost. That is something that we do.

The other thing is switching ad providers. Ad providers change the payout scheme that change how much revenue you can actually get from a particular game. But not only that, not every ad provider performs well in every market. For instance, there are ad providers that work much better in Asia than, say, in Europe. If you want to really publish your game far and wide, you end up having to not implement one SDK, you end up having to implement four, or five SDKs for different regions, sometimes different times of day.

What we've done is we've created an abstraction layer in the engine itself that provides ads. We have basically have a note, if you ever use Godot. You can just create ad notes in your game with a standard API. Then at export time, you decide what ad networks actually end up implemented behind those nodes. What that means is, for instance, you can very easily say, make a version of your game for a European market with a different ad network than, say, for an American market. Those are the two main challenges that we're trying to address and also, the two main challenges that we've seen from various mobile developers.

[0:12:12] JN: Awesome. Yeah. Again, go back to that GodotCon talk. Obviously, a lot of the things you mentioned when you introduced Ramatak were really interesting developer experience improvements. You're making it seamless to get started building games. I don’t have to worry about all this other stuff. When you were running through why Godot is already very good for developers, you mentioned GD script, the in-built included scripting language as one of the things that makes it great for mobile devs. Can you talk a little bit about why that is?

[0:12:38] HPvB: This is something that exists for all types of games, don't get me wrong. The way that mobile games are monetized is very around playtime and to a certain extent, the negative version of saying, that is getting people hooked on it, but I think the more positive spin you can give to that is make something that people want to play, right? I think that that is a most of the time, a more honest description of what is actually happening.

You need to make a game that people want to play. In order to do that, you need to be able to tweak your game after play tests really rapidly and change these little things like, does this ball need to bounce half a second longer? Is the visual squishiness of this thing like, just at peak cute, or it's a little bit more squishiness, slightly cuter, etc. There's a lot of these minutia that on mobile are amplified compared to other games.

That's how people will try your game and particularly, if they've already spent a dollar or two or three on Steam on your game, they are more willing to explore what is there. If something is not ideal immediately, they are usually happier to push through that and then find the hidden gems within. With mobile games, they tend to be free, so people will just install five, six, seven of them in a day and try which one they want. If they're not immediately hooked on it, or immediately interested in it, they will just go away and there goes all your ad revenue, right?

This is really about your descript. I will get there now. Because you need to have this very fluid way of iterating on your game, having a scripting language that is built into the engine and that doesn't need compiling and that you can just live at it basically with your device running is a huge time saver. It lets you do these iterations maybe two, three, four times faster, depending on the quality of your machine. If you have some 20-core monstrosity, then probably, a C# will be fine. But if you have a regular game dev laptop, or something like that and you don't want to invest in this nuclear power plants worth of computing power, then having something like GDScript is just this force multiplier.

Not only that, it makes it much easier to create little scripts that say, maybe your game designers can actually directly edit, rather than having to go through the developers for. That is really my main thing, where I'm like, GDScript is just this rapid development tool almost for your game feel. I feel that particularly, your mobile, this is a quality that cannot be underestimated.

[0:15:33] JN: Yeah. I guess, the extra juice in the mobile section is really interesting. I haven't had to express that way before. Yeah. I mean, I'm sold. I think that works. I'm a big GDScript fan already, so I didn't have much selling to do. Much, yeah, selling to do, but that makes a lot of sense.

[0:15:51] HPvB: I was preaching to the choir, as they say.

[0:15:53] JN: Well, yeah. That leads me on to something that we spoke about briefly before we jumped on the recording, which is you're working on a project, which I think is super, super cool, which is to bring GDScript to LLVM, or I guess bring LLVM to GDScript, whichever round you think about that. If this is where LLVM is the low-level virtual machine. It's a compiler backend that’s used in all kinds of high-performance programming languages. Can you tell us a little bit about what that project is and the inspiration behind it?

[0:16:20] HPvB: Right. The main inspiration behind that is that what I frequently see in forums where people come and ask, “Okay. I want to start making a game in Godot. What do I do?” A large percentage of more veteran game developers will almost immediately stare people towards compiled languages, with the idea being that it's faster. While technically true, C# is faster than GDScript, then C++ is even faster. For literally 95% of their games, and of those 5%, 80% of that code is not actually performance critical.

For the most part, you can make Candy Crush in GDScript. You can make infinite runners in GDScript. You can make hidden puzzle games in GDScript. There's no need to use C# for any of that. But because of this, I want to say, almost cultural or political thing around that you need your games to be as fast as possible, I see a lot of novice developers getting steered on a path which requires them to set up tooling, requires them to learn an extra language, or requires them to learn a new IDE, because generally speaking, using C# comes with using visual studio code and now you have to install a DotNet runtime and etc., etc., etc. There's a lot of ands there.

Whereas, the experience that I want people to have when they start making games is you download this one executable, you double click it and you start making a game. Because that is satisfying, you get quick results, and it is very low – there's a lot barrier of entry to that. In part, the reason for the LLVM compiler is simply that, that is to make sure that novice developers when they talk to experienced developers, that the experienced developers can say something like, “Yeah, C# might be a little faster, but GDScript is 90% of the way there.” That gives people less of a incentive to have to switch.

The other thing is there is this 5%, 10% of code that can be slow in GDScript. The experience there for experienced developers is actually really, really good. Because due to the way Godot is set up with the node system taking a bit of code in GDScript, making that into a C++ module and just building that into your game is actually really easy for seasoned developers, particularly if they're not only game developers.

But for more novice developers, this is a big hurdle. Because now, again, we have to set up an external tool chain. You have to build this module for all of your target platforms. How do you even do that? How do you get a iOS compiled binary created for your game? It is hard. This is the second tag of this. I want to make sure that for most of the things you could want to do in your game, like procedural generation comes to mind as one of the main things where GDScript is oftentimes a little bit on the slower side for some people. Making sure that you can write all of that in GDScript and still get 80%, 85% of the performance which is probably more than good enough.

If you have a gigantic development team and you're thinking between, “Oh, should I use Godot, or Unreal, or something like that?” At that point, you have the developers to do this. This is not for them. This is for the smaller teams that need just a little bit of extra. That’s a very long-winded answer, I guess, to say, it would be good if it was faster.

[0:20:06] JN: I know this is early on in the project, so you might – the technical details might not be fully sketched out yet, but how does that integration work? You mentioned that GDScript compiling to GD extensions via C++, is that how you envisioned this being used? Where does LLVM sit in Godot in this case? What is the GDScript turning into through LLVM, I guess, is my question?

[0:20:25] HPvB: Right. Right, right, right. Yeah. The way I want to do this is we include a linker, because the project itself is much larger than at then just the low level VM, right? There's a lot of tooling around it. The nice thing about LLVM is that all of these tools are available as libraries. We can have an actual elf linker, or an PE linker, etc., inside the editor itself. What we can do is ship the export templates as object files and then the LLVM ahead of time compiled code can just be put in this pile of object files that gets linked as we export. That is the general idea of what I want to do.

The other difficult part for this that we are still thinking about is whether if you install this, whether we want to still use the old style GDScript VM, or if what we're going to do is take the LLVM VM, the actual VM part of it, block that into the editor for your very quick runtime and then at export time, do this ahead of time compilation. There is a bit of things that are still a little bit unclear, and there's also some interactions that we have with the proprietary platforms, particularly on console, where Microsoft and Sony don't really want you to use compilers that they don't give you. But also, they can't really check.

[0:21:57] JN: Sony execs don't listen to this bit. Yeah.

[0:21:59] HPvB: Yeah, exactly. We're not sure how to do that yet. LLVM has an option to actually spit out C, instead of LLVM IR. What we might end up doing is for those targets that instead of spitting out object files, we actually spit out C files. If you want to publish PlayStation, or Xbox, that what you end up getting is just a pile of C files and maybe, some kind of project solution, so that if you build the engine, you then build the C files with the compilers for that target platform. Because by the time you're deploying on those kinds of targets, you already have to set up this gigantic tool chain anyway.

Trying to balance this needs of novice developers, or intermediate developers, versus to the large teams that know how to set up all of this tool change, that's the friction point there. How do we make it fast and accessible for everyone?

[0:22:56] JN: Mm-hmm. Interesting. I guess, that leads me to, I guess, a general theme which is Ramatak as a business, and from what you're making is going upstream. You mentioned earlier, that a lot of what you're adding is going upstream where it makes sense. Can you draw like, what stuff do we see moving upstream to Godot?

[0:23:14] JN: Anything we do that improves the direct developer experience of using the engine, we end up wanting to put upstream. We're talking about the improvement in profiling the performance improvements. That thing goes upstream, the things that we can't put upstream are the things that are directly related to things like, the ad networks and things like that. We are thinking about maybe upstreaming the ad abstraction layer, but then we'll require some politicking and just making sure that the project actually wants that in the form that we've made it. That is generally where I draw the line.

Sort of like, I want the Ramatak products value add to be the turnkey way of starting mobile development. But not it being a superior renderer to the open-source version and stuff. It is very important to me personally that the Ramatak version is both backwards and forwards compatible with upstream Godot, because one of the things that is difficult about the game engine landscape right now is just that this complete lack of trust in this entire industry.  Unity’s, let's say escapades have not really helped with that.

I want to make sure that the Ramatak product is safe for developers. That is, okay, you use our version of the engine and we think you will like it better than the upstream version, but we don't want to make it a binary choice in the sense, okay, I switched to the Ramatak engine and now my game is stuck in this version of Godot. We don't want to do that. We want to make sure that this is a free choice for our customers, or for our users and that we actually have a value add that isn't like, “Oh, I picked this one time and now I don't have a choice anymore.” That is where this line is, and I realize that it's a little bit fuzzy, because it is a little bit fuzzy, because when I when we add something, will that impact people's ability to take their games out of Ramatak mobile studio and into Godot upstream, or not? But that is the question we ask whenever we add anything to the engine.

[0:25:33] JN: Then, yeah. Also, as you said, upstreaming things isn't just a case of you saying, “Oh, we built this and we like it. Off to Godot it goes.” They have to also want to have it as well, right?

[0:25:43] HPvB: Right, exactly. Because while I am part of the board of directors of the foundation, that does not give me any special ability to get features merged. There is a process for that. I can't skip that process either. Making things that are used, generally useful and making things that people want remains the most important thing. One of the things I talked about, just about the engine in general for a long time, just as part of the board, when some of this stuff came out, like we talked about adding the video physics to the engine for a while for instance, because there was a BSD version for desktops. But you had to pay for it for mobile platforms. This was well before Ramatak, etc.

Our general stance on that is that we don't want Godot, the open-source project to basically be a storefront for third parties to sell special access. That is also something that we have to keep in mind with the features we had here now.

[0:26:44] JN: Yeah. That makes a lot of sense. Along the way there, you mentioned just very briefly, that there are some rendering improvements mobiles being made in Ramatak. Can you talk about those? There's one in particular that's very interesting, but I think it's good to intro the general things you’re aiming for.

[0:26:57] HPvB: Sure. Yeah. First of all, I am not a rendering engineer. Ramatak hired rendering engineers, but I can give you a high-level overview of what we did. One of the things is there is an extension, OpenGL extension that can do some of the depth buffer in hardware, and we've implemented that. The original idea thinking was, that it would not be faster than the CPU method, I guess, for that particular feature. But we found after a little bit of benchmarking that actually, using those extensions on the engine actually helped a lot, and we were able to take the third-person shooter demo app and run it on Android with 40%, 50% higher frame rates just with some of these little tweaks.

It's those kinds of things, that things that the volunteers tend to not have necessarily have time for. Finding a pile of phones and seeing if this particular OpenGL extension is actually faster than what the common wisdom is, things like that. Because we have a rendering engineer. We have a pile of phones, so we can just try these things. That's the biggest one. We've also done some things where we are not allocating frame prefers for unused parts of the shader, so that brings down the memory used, particularly on mobile, this is very important down. We've done some lighting improvements for which I do not know the technical details.

[0:28:22] JN: Sure, sure, sure. No, that's very interesting. I guess, one of the, again, from your GodotCon talk, again, one of the things I hadn't quite appreciated about building mobile games and I guess, that's because it's very easy as an iPhone person to get locked into the monolith. It's just the amount of platforms you need to support. Can you talk a little bit about that? Particularly, I think there was something interesting, also, we're supporting itch exports? Does that ring a bell?

[0:28:50] HPvB: Yeah. That was mostly for the web exports.

[0:28:52] JN: Sure, sure.

[0:28:53] HPvB: This comes to Godot 4. Godot 4 is our next generation of the engine. We've thrown caution in the wind and made a more visually rich renderer, which is great and it works really well, but the problem is that mobile phones move slower than desktop to a certain extent. But part of the reason for that is that for a lot of people, their mobile phone is basically, their only computer. They buy one and then they use it for basically, all of their computing needs. They sometimes have to stretch this for quite a long time.

The fact that you can do Vulcan on mobile is great, but there is a lot of phones in which it doesn't work right, or is slow, etc. Making sure that you can actually take your 2D game and ship it to devices that are 10-years-old, 12-years-old, etc. That is actually challenging in the way Godot is set up right now. One of the things we're doing is we're developing an OpenGL ES2 renderer, which is the most baseline of baseline 3D APIs that is still supported. The reason for that is primarily, to make sure that you can basically take these simpler games that don't need Vulcan 1.3 with full extensions, and just take your Candy Crush, your 2D puzzle games, your other things, and actually deploy them to as wide an audience as possible.

That is the primary, I think, difference between desktop and mobile development in that the range of devices and also, the range of capabilities of those devices is so vastly different. On desktop, you have one of three GPU vendors. You have an Intel GPU, you have an AMD GPU, or you have an NVIDIA GPU. On mobile, that is not the case. Because you could have a very capable GPU on your device, but the drivers for it remained eight years ago and nobody has updated them and they're terrible.

The matrix of things is much wider and much less forgiving as well, because mobile games also have the big, let's say, downside that there is, reviews on those websites. If you create a relatively simple game that people look at into store and there's simple 2D graphics and they install it on their 6-year-old phone and it doesn't run, they're going to give you a one-star review. That's going to tank your overall standing in the stores, etc.

We want to work around that a little bit by first, just testing on more devices and try to fix the higher-level renderers on those. But there is no fixing some of these. There's just devices that just cannot be fixed. There's no workaround that makes your Vulcan renderer work on some of these devices. For that, we have the ES2 renderer. The idea there is just that this will work on everything that can still be charitably called usable today. Doing that, I think, will just open up Godot to way more things.

As we talked about the itch.io exports, people want to be able to export their games as a web export. Godot 4 does support that, but that needs WebGL 2 support, because the fallback renderer is an OpenGL ES3 renderer. That doesn't work on all platforms either. Particularly, Apple seems to be very concerned about allowing people to run WebGL 2 content in their browser, so they really only work well with WebGL 1, and that sadly requires an ES2 renderer as well. The idea being that if we upstream this, we get these benefits for these older phones and we get the benefits for game jam games that just want to ship their games on itch.io with a click to play on the browser.

[0:32:36] JN: Fantastic. Along the way there, you start to work with Godot 4, which I'm very interesting, because at time of recording, Ramatak supports 3.5.1, right?

[0:32:46] HPvB: Yeah.

[0:32:47] JN: Between all these rendering things, and then also, having to support versions in perpetuity for the ad updating vision, I imagine your business of supporting, keeping pace with the Godot open-source releases is a key challenge for you. How do you address that?

[0:33:05] HPvB: Well, first of all, we are all – all of the people that work for Ramatak have some ties to the Godot community already. That's how we found them. They are used to the base of development on the one end. On the other hand, it is a matter for us of creating a product that we can support on the platforms that we say we will support. That is why the Godot 4 version of the studio is still a little ways out, because we want to have the ES2 renderer in there. We want to have some of these life improvements in there.

The reason for starting with Godot 3 really was pragmatic in the sense that there are a lot of Godot 3 mobile games out already, so we want to make it easy for people who already have their games to say, “Okay. I'm going to take the game I already have, add the Ramatak ads to it and actually, try to make some money off of the games that I've already made.” Godot 4 is enough still that the number of games for which that is true is relatively low, because we plan to be entirely compatible with the upstream version by the time we have a version of the Ramatak mobile studio based on Godot 4, the games will also be ready around that time.

Like I said, we want to be cross-compatible, it is not really a downside for us to not have it yet, because the open-source version exists and people can make their games already. That is one of the critical things for us is that we don't need to be first to market for platforms, because Godot already exists.

[0:34:45] JN: Yeah. Makes a lot of sense. Well, I think that it's bringing us more or less to time. I wanted to wrap up by asking, whether there are any creators in the Godot space, whether mobile specific or not in particular that you would recommend to folks who are curious about Godot, or looking to improve their skills as they go?

[0:35:02] HPvB: Sure. First of all, GDQuest makes fantastic learning content, and I cannot recommend his stuff enough. His tutorials are fantastic, super high-quality, well-polished. Definitely worth your time. I have no black financial ties to him, but I can only recommend that try some of his free content, and if you're interested, his paid for content is fantastic. Second of all, there is a developer that is making a game called Road to Vostok, which I believe is a survival looter shooter, I think. I'm not sure if the looter part is correct, but that's the vibe I get.

[0:35:38] JN: I think you are correct. Yeah.

[0:35:40] HPvB: Yeah. His Patreon, his free pages on Patreon have a fantastic porting log of when he decided to move away from Unity to Godot. He has a very honest description of things that he really liked things, that we didn't like so much. The other nice thing is that he has screenshots of his game actually in progress. For people who are skeptical that like a, let's say, AA looking game can be made in Godot today, his blogs and his screenshots and videos really, I think prove that you can.

Another interesting project is a disclaimer that there that they are a customer of mine, which Prehensile Tales. Take this with a little bit of a grain of salt. But a project called The Mirror is making a very interesting piece of software, where they're basically doing a sort of Robloxy-like thing using Godot, that looks really good, and the people who are making it are really nice. I think that is going to be a very interesting platform for people to get into game dev at all, compared to say, actually starting to write code right away. Those will be my three main recommendations, I think.

[0:36:51] JN: Perfect. Yeah. Those all sound great. I mean, the Vostok one especially, is it's a very rare occasion to see someone porting their game across platform live, let alone, sharing all of it and sharing their opinions and fully committing to go in through with it. I think that's a really useful recommendation for a bunch of reasons.

[0:37:10] JN: That developer is a machine, man. He managed to port some of this stuff in times where I was like, “How is this even possible?” To get to get back a little bit to something we talked about earlier, he's doing it all in GDScript.

[0:37:25] JN: Yeah. Valid language. Valid language.

[0:37:27] HPvB: Exactly.

[0:37:27] JN: Well, thank you so much. It's been super interesting. I definitely have learned an awful lot about developing games mobile from your content and from our chat today. Yeah. Thank you so much for joining us.

[0:37:37] HPvB: You're welcome. Thank you so much for having me.

[END]