Writing Clean Code for Games (Industry Veteran)

Do not pre-architect everything, because I've never seen someone who draws the architecture and then coach the architecture like that and it works. I rarely have seen code from video games that are well structured. [music] It's always a mess, but it works. This is a conversation with Rick Pillosu, co-founder and lead director at Epic Tailors. He has over 20 years experience in the industry, including lots of experience in triple A. For example, he was the development director [music] at Crytek for Ryse: Son of Rome. Now, he founded his own studio, Epic Tailors, [music] a 30-plus people remote team building a CRPG in Godot. I found people [music] that they want to show that they are very good programmers. So, they over complicate this the systems and yeah, but look at what I can do. You [music] need to acknowledge that compared to the complexity of the code that you are doing, your brain [music] is a stupid. Doesn't cannot handle it. Your brain is very limited compared to all the complexity you want to handle. So, what you are doing is that [music]

you transform the problem in something that your brain can handle. So, you keep breaking [music] it down into small pieces until one piece fit your brain.
They're the biggest Godot team out there that I know of. Then, I'm mainly here to ask questions about coding and code architecture, coding philosophy for video games. I hope you enjoy. Let's dive right in. I think I stumbled over an interesting quote of yours while doing some research and I think you said something along the lines of you're more afraid afraid of big success than of small failure or something along those lines. It's a very old thing, I know. Big success it's uh extremely dangerous for your brain. Um most of people that I see that has [music] big success, with some exceptions, that success eats them. We all know the cliché of someone who got money very fast and then somehow went crazy or or or I don't know, or famous actors that

uh famous rock stars and and people like that. And every time I meet people that have a lot of money or uh it could be money, but this kind of success depending also it could be this kind of critical success, but really really good. I don't see those people very happy, to be honest. All these people after few years they they stop producing very good stuff. Again, there are exceptions. But, that's [clears throat] why I'm scared. Statistics and my experience tell me it's actually very uh toxic for for your ego. So, this is maybe not uh the business side in you speaking, this is the artist side in you speaking. And like the artist side in you is like scared that it's difficult to stay grounded after a big hit. I felt like a very big hit or something, yeah. Oh, no, no. And this also also for for the business side. For the business side also?
Yeah, for the business side, I mean, I think if we do enough money that we do not need to worry about money, as long as we keep our

you know, feet on the ground and we are not looking for yacht or something like this. As long as we we just keep doing our normal life and keep going ahead, those things are this is fine. But, if you get a lot of money, I mean, it's extremely difficult to control yourself.
And then there are also the more money there's on the table, the more interest groups are like interacting like weirdly with you and and that sort of stuff probably also plays a role. That's very accurate. One of the the main problems with this kind of success is that people treat you differently. Yeah. Like you have the owner of some sort of secret formula for success or something. And deep down, luck is 70% of it. Okay. So, you don't think there's uh you don't think there's a formula, you think it's a lot of luck? The percentage of luck involved is always way bigger than what people think, because your brain keeps telling you that there must be something that I do that makes it happen. Yes, there are something you can do to increase your lucks, but luck is a huge

factor. The thing is that if we would accept that luck is that big factor, probably we would not start many endeavors. But, remind yourself that you need to be lucky. There are people that have fantastic games and they just ship in the wrong moment with the wrong publisher, with the wrong technology, in a moment where I don't know, and something else happens and they are not lucky. Or they are people they are just son of someone. And this is extremely the case of lucky, right? You are born in a family that has a lot of resources and money can give you a great education. That's really rolling dice. So, um that's why I think that it's something that try to remind myself that it's about that. It's about But, you need to again, you need to create generate opportunities, but remind remind yourself that it's not everything up to you.
I think most developers would probably agree that there's a lot of luck at

play, but I think where the opinions differ is maybe where where the luck happens, right? For example, I think it's very hard to argue with the fact that there's a lot of luck in where you are born, like which family you're in, if you like like good financial starting position and so on. That is extremely luck based. But, do you think that is the biggest factor or are there more luck based factors after that? Like you already said like announcement, but like where where do you see the most luck in in this process in the entire pipeline? The people you work with. Uh the situations in their life. Um you could be working with someone who I don't know, is fantastic, but depression, going through a divorce, losing someone in their life and suddenly that person is turned off by circumstances. And it's not that they choose that. And since and and the bigger the team, uh well, the bigger the team or the more involved the team, the

you are rolling more dices. I mean, the the uh I did a presentation uh a few weeks ago in a university. They asked me, "What is the most difficult factor to build a studio?" And I told them, "People." I mean, you need to yes, the right game, the right technology, but making games is not difficult. Working in team is difficult. It's in the scale of difficulties, that's it. That's that's how high it is. Making games, well, it's just all it's tedious, it's a lot of work, but it's just you solve physics, you solve collisions, you solve tools and you keep going, but all those things have solutions. I mean, it's not difficult to make video games. It is difficult to coordinate with people in the same direction. That is that is tough. I think if I'm correct, Epic Sellers is about a 30-people team, around that number at the moment, right? Yeah, Epic Tailors, not Epic Sellers. If not, that would be really bad news. Oh, Epic Sellers would be even better, though.
[laughter]
No, no, I don't think so. Yeah, yeah, yeah, yeah, right. Um yeah,

we are 30 30, I think a bit more, because we needed a bit more bandwidth and and we got two more people. So, I think it's 52 something like that. Yeah. So, that's quite a huge team. So, that comes with with quite a burn rate as well, right? That's like quite some hefty bills to pay every month, I assume.
[laughter]
Yeah. But, it's it's a calculated thing. And and for I mean, and it's not a huge team actually for I my previous work, it will be like one department. So, maybe like the coding department could be like 30 and then you get to people like 100 150 150 200 and I I haven't been there, but other I mean, I have friends working in a company of or in a project of more than 1,000 people. Maybe to quickly summarize your like development journey. You were in triple A before or could you quickly summarize that that whole journey for us? Quickly would be

I started in a small studio in in Madrid, the ones that created the Commandos series and Pyro Studios. I was the first job. Then, I went a bit more indie with a a studio called Tarariaco. Uh it seemed that it did it didn't went anywhere, so I moved to I got accepted at Crytek, where I did the bulk of my my development experience. Uh I joined Crytek when they were finishing Crysis 1. And I was part of another team that was developing new IPs and new new games in order to pitch it to publishers. I [snorts] was there, moved from senior coder, lead programmer, project manager and project director.
[snorts]
And the last project was Ryse: Son of Rome, when I was project director and that was we started like 20 30 people. It's considered micro. And then we end up like 130 or something like that by the end. Then, I went back

to to Spain, teach at the university, then game programming, engine programming, all those kind of things. And then I was hired by Smilegate to build a studio, Smilegate Barcelona, here in Barcelona. And I handled the whole tech thing and I and uh using Unreal. Um but after few years, Smilegate thought that no, they we don't want to do that anymore. And but by that time I already got the idea of with Albert, my co-founder, to to build a studio ourselves. So, that when we started Epic Tailors like two two years ago, two three years ago, I don't know. I tend to forget things very fast. So, yeah. Um so, have you always been in in more of a lead role or when did you grow into this lead position? That leadership position happened when I was in that team building new new games at Crytek and the lead programmer left. And and they asked me to fill that position. I was very hesitant, but

a very good friend from HR, Heiko, he told me, "I think you will be a good lead." And he somehow hand-holded me the whole process and it went well. I mean, the the team was happy with the with with my my kind of leadership and that. And then after that was successful, that's when they told me, "Okay, can you do the same thing you do with programming for [clears throat] the rest of the teams?" And that's why I production manager. And then after that, then production director and stuff like this. So, yeah, I would say more than half of my career. What exactly is your position now? Would you see yourself as more as like CEO or would you see yourself as tech lead or how would you describe your position now? I mean, a Pictolous is very unorthodox in how it is built and a structure. So, some stuff that I explain not does not map to other studios, but I I am kind of a project director. So,

I tend to oversee tempos, what we are aiming to do, how the player should feel, and trying to to go through all the areas and make sure that we are all aligned. Um and when there is something on the tech that the the coders, because some of them are very young, and they don't have uh enough experience even if they are super smart, way smarter than than me in many areas. I just go there and I'm build some systems uh so they can then jump in and then build build really the system after that, but having a bit of the structural um idea behind those systems, it's it's has proved many many beneficial. But normally my week is Monday to Friday is kind of direction. So, I I talk to all the the people. I talk to do one-on-ones. I I go through all the departments and we look at all the problems and I try to find a way

that there is quickly quick decision-making for everybody, so there are no any any important block in the middle and we move forward. And then during the weekends normally I get one day like Saturday or Sunday. And then it's like, "Okay, what are the things tech-wise that we could that we could solve quickly?" And then I jump and I start, you know, fixing bugs, creating base systems and things like this. And that has been pretty much since the beginning. One thing I've been wondering about is like how are AAA games developed from like a tech perspective? Let's say like the studio decides we're going to make a new game. What is what is the starting point when you're in AAA? Is it like, "Okay, here are the systems we'll need." Or do you already have like a bucket of reusable systems from the last last project or how does that look like? Or do you think it's very different from studio to studio?
It is very different from studio to studio.

Very different. So, Okay. For example, Creative believed a lot into building their own their own technology. So, it was a very technology-oriented company where they built some technology and then they created games around it. And then when the game [clears throat] was evolving, then they it was requesting technology. So, it was like this kind of very strong relationship. In the small game, it was vice versa. It was built in the correct steps. It's like, "Okay, what is the game first? What are we trying to do here? And then what is the right tool to achieve that in the most efficient way?" So, in that case, we were using Unreal because of the the game required very realistic graphics and and we wanted to have a bit of a jump start and I'm being technology feel very new. So, Unreal made sense. But for example, I have some friends in Ubisoft. I don't have that experience by myself that they have so much code, so much systems

built already for other games that uh sometimes as a coder, it's really building a puzzle like, "Okay, I need to build an inventory. Well, we have like 10 different inventories in different code bases. Uh okay.
Pick your battle here." Because there is so much history and so much technology built before. As studios evolve, they focus less on technology and more into how we make the next game interesting. So, they are more game game design dependent than technology dependent.
I see. Again, engines more or less is kind of a solved thing. We do we do feel improvements here and there, but they are not too much difference. So, with the tech stack or with the technology that you sort of get into a groove and then the main problem you try to solve at some point is just the design of the games essentially. Yeah, because it's rare that nowadays you do a game that will be interesting because of the technology.

Rare to a point that I actually cannot recall any. Innovation comes more from hardware like, I don't know, like the latest consoles are super fast hard drives. So, this way we can maybe get from hard drive to VRAM very quickly and that changes things. It means we have access to a bigger pool of textures. But that's kind of what we are trying for example, Sony is doing very interesting trying to build new things in the kind of audio, making audio way more interesting, way way more technical. Those are things that we evolve, but that is it's not that back in the days when I was playing Doom and Quake, every game was like, "Wow, it's like 10 important improvements." And and I would just want to see this game. I don't care if it's fun. I just want to have it in my computer to witness fantastic things. But nowadays it's not the case. I mean, you you are happy. I I'm happy playing a pixel art game. It's it's more about

that. Technology is out of the way now. Okay. To what degree is prototyping typically part of the process in AAA games? Because we we indie devs, we talk about prototyping a lot, right? Is that also something that studios do in AAA or is it more like, "Here's the design document. This is what we're making." What's How does that look like in your experience?
Again, every studio have different formulas. I can tell you what I talk with my peers about. For example, I have a friend in in God of War. I have a friend in in in Ubisoft other Ubisoft projects. I have friends in Guerrilla. I have friends in many different game and every time we share stories, there is not much overlap. The culture of the company finds what worked with them in the past and stick with this kind of rituals. That's why they call the culture of the company. For example, uh at Creative, we got we got one kind of ritual is that we were building something and for

example, I remember that Rise, we couldn't figure out combat. We were a bit of stuck combat. Something felt good, but it was not good enough. We don't know what to do with it. So, I can't recall the name of it. There was a name for that, but uh cabal or something like this. I can't recall. It So, everybody basically we took the a bit like a scrum, what a scrum does. We took game designers. We took programmers and we and we took an artist or something and we put them in a room and we said, "That's your only job. You're not going to do anything else." And we put the name is like, "Those guys are solving combat. You do you." Kind of you know, situation room or something. And at Creative, it worked well because when you have a big company, there is so much noise and so many opinions. So, a way of saying, "Guys, we trust you. You have game design. You have code. You have and every two weeks we will just over one is like, "Are you guys fine? But you have three months to fix it. So,

make a combat fun." And that was a a thing that that that worked well. Well, combat in Rise wasn't that good, but at least we moved it from unplayable to boring, uh which is a progress. Mhm. Yeah, so Okay, so the approach there is you create a little subteam with a clear task or responsibility and you have them let it go at it in like a smaller team basically. Yeah, I mean, depending on it highly depends on how clear the vision is and how strong vision you have coming from the creative director. Uh if you have a creative director have is the has their vision is strong and is very good at communicating that vision and has acceptable kind of flexibility around it. Things becomes very easy. Basically, he starts. He explains what he's asking for we what he what he has in his mind and we

build teams around it. And normally we do yes, we do prototypes. Normally in the pre-production phase, we do prototypes for, I don't know, movement, com well, transversals or normally we call it. Then we have combat. We have this kind of, I don't know, narrative beats. How we are going to deliver those things. We have those teams building those. He reviews those. We iterate them. And there is a a step that it could be a publisher. It could be leadership from the studio. It could be editorial in some other place in the world. It could be something that says, "Okay, I want to see this." And verify that we have something there that it's interesting. And once we have it, uh some Normally, we have it like 60 70%. But it feels good enough and then we go into production. It's like, "Okay, now we are going to those are the pieces that we are going to build the game around and now we will build all the content and we will keep saying, I don't know, we have like four things. We have

combat, dialogue, and inventory management and this. And then we keep playing with them distributing in through the game. But I have to say, it's way more messy than what I explain. So, when you start working on a new project, it almost sounds like you have like different people or different mini teams uh maybe working on on different things, right? Maybe someone is working on the inventory, someone is working on the movement, someone is working on the combat. And then at some point you have to bring that all together and they're like but in the beginning they're all like making their own prototypes and you're trying to test everything individually. Is that roughly how it works? Yes. Uh I mean, I think we are moving past that with the moment I I started in triple A it was the moment that everybody discovered Scrum. Uh and it was like the new big thing. Um So, and mind that depending on the team you will have many opinions and that's the problem. You have a creative director that talks to a lead designer

or a uh design director. The design director have lead designer or lead designers. And then those lead designers will have game designers. And all those all these people need to have I mean, even if they share the vision, they normally have a strong opinions about how to make it good and they need to have some sort of room for iterating those things. So, you normally is like, I don't know, combat, okay, you guys are the ones that have one experience with combat, you get combat programmers, you get some animators, you go into a room, you guys have, I don't know, two months, which is like three sprints and bug fixing. And then from there let's check let's check with the creative director again and then when they get all this they play, they give feedback, and they decide what's the next step until you get something that plays nice enough. Um again, this is this is the ideal, but the human factor kills it. Sometimes you get someone who

is very charismatic and even if a project is bad, they will tell you, but it will be fantastic and everybody somehow feels positive about it and convince people that that was good enough even if it is not. And sometimes you get the opposite, someone who is not very charismatic, very pragmatic, uh and it shows something and says, well, this is as much as we got and it feels like a bit of a downer even if it works well and people feel like they want to improve it. So, human factor is is is is big and it's chaotic and it is what it is. It's interesting how bigger teams sometimes manage to make very poor design decisions and nobody seems to notice, right? Have you Have you heard of the Have you heard of the term uh toxic positivity? I have. Yeah. Yes. Yeah. Do you think it's a thing in bigger teams that can happen or The thing is that you label it like it's a thing, but it's more about

as I said, the charisma of people. Let me tell you an example that happened to me. I am this kind of boring pragmatic guy. I come from tech, so it's true or false for me. Um so, I remember, for example, discussing a milestone with a big publisher and I told them, okay, so this is the milestone, we have done out of 100 things I can't even remember the details. More or less you want to we did 97, those three we are missing them, we are moving them to the next milestone. And then they're making a big thing of it. Oh, this is terrible, you haven't done those three things. Those were the most important ones. This you you record dropping the ball. And I was like, well, then don't approve the milestone. What do you want me to do? Well, but I want to And they were looking for this kind of push them back, right? This kind of convince me that I don't have to I don't want to convince you. If you don't want to approve the milestone, there's nothing I can do. I mean, I told you the

things I we did 97 items and that's a lot. If you don't value that, that's really up to you. I I respect your decision. And um and then I I that was on a call. We are not talking to them directly. And then there was a guy behind me, uh lead for another department, who is very different from me. And he's like, can I join? He's like, yeah, if you want, go ahead. And he started talking and after two minutes they were like, yes, this is exactly what we wanted to hear. You guys passing the milestone, you guys are fantastic, we trust you. Those three things were not done. He was just very magnetic. He was like, we hear you, what we are doing is that we really want to do those things right. So, we thought that we need to take the right time because we know that those are important for you. It's like, what is going on? I was like clueless. We are not doing that anyway.

Uh so, and and after that the guys were like so happy. It's like, yes, by the way, Rick, can we have that guy in the room every time we we we do a milestone report? I was
[laughter]
thinking that he will be here for all. Yes, that's fine. So, is it about the items? Maybe I'm not charismatic and I'm you know, so that's what I mean. We pass milestones because someone is sweet to someone. That's why uh big teams can can generate this kind of uh big mistakes. So, there can be false negatives and there can also be false positives depending on the charisma of a person. Basically, for for a milestone it could be could be that they don't want to improve a milestone even though you deserve it and it could also be the other way around that you don't deserve the milestone being approved, but somebody is charismatic, so it's approved anyway. Or or you So, your negotiation skills is bigger part that what my

you know, programmer mind thinks of. Um and I learned it hard way.
[laughter]
So, um I mean, we all know you do an interview and and to a company and maybe you you ace the test or something, but they don't feel it. Or quite vice versa, you are really bad with the test, but the others feel it. What is a feel it? What is the connection? It's extremely circumstantial. It's luck. It is again, human behavior. Humans talking to humans and trying to guess and use their intuition to see how things will be. But bigger teams make mistakes or even more mistakes, I would say, than a smaller teams because there is an expectation with hierarchy and experience that those people become very good at what they are doing. Um so, if you were part of a very successful game and you were the lead designer, so we trust you. If the lead designer of this

awesome game says this goes, this goes. We trust you because you were successful once.
So, this is almost what you said in the beginning is that this creates a chance for you to become a bit less grounded because maybe if you had like a big hit, maybe people trust you more than they should. And then you get caught up more in your bubble and in your mindset because of that. Can we talk about that?
people generate kind of an image of who are you based on your past success. Like but that's fine. I mean, this is the shortcuts that the brain takes. I mean, you made an image of me like you have a career and successful. I've just been coding games for that whatever people has me. I have done nothing special. Um but this kind of image that we do for other people tricks us into, well, if this guy says this and he sounds very experienced, must be true, so let's go for it. And again, makes sense, but in corporation and when there is big money, that's sometimes the only way for making

choices. This guy did a very good game last last year, so if he says this game is good, this game is good. They don't have any other thing to base their decision making into. Um but then you look into the reality and maybe that guy was part of a 200 men or team 200 devs that they were doing a game, he was lead designer, but maybe he the creative director was overruling him and making a lot of correcting his bad choices all the time. And there were many designers that did fantastic despite of him. But you have that guy bringing that title, it's like, I've done this game. I was there. And suddenly it's like, you are the guy. But in a triple A there is not the guy. I mean, there are so many people. It's very very difficult to to say you are the creator, you are Sid Meier, you are this kind of name that defines quality.

Uh business people love those, but this is basically smoke and mirrors. I see. So, it sounds a little bit like even as a lead director or something, you don't see yourself as that important or what what's like Oh, no.
[laughter]
What's like the value you provide to the team as a lead director?
It's valuable, in the end it's very difficult to explain.
I mean, experience is worth something, right? You can't be like experience isn't worth anything. Surely surely you Surely you would rather have somebody who's been in the industry for 20 years than a newcomer as like your director for your game, right? Not entirely true. There There's a pragmatic answer coming. No. No. I I I would love to give you easy answers, but there are none.
[laughter]
I'm too old for easy. No, that is not true. So, another example probably that that that I tell my students very often. I was push I was pitching a project

when I was a Crytek to a a big studio. And they were liking the project and then I give them the the the time to ship. I mean, I can't recall. Let's say 2 years. And I remember there was one guy in the publishing side that's like, "No, no, no. You could do it in half." I was like, "What What Where this comes from? No, I we cannot do it in half." Yes, you can. And he was very confrontational in that meeting. But he's and I don't want to cliche people. It Oh, but it always happened with me with Americans. Americans in a meeting room can be very strong. This is This is my business side. But then the moment and and we Europeans is like, "Man, [ __ ] you. I mean, I come on. Don't be that like that." But the moment they leave the room, it's like, "Hey, let's grab a beer. Let's grab a beer. You're super nice to work with." It's like, "You were just yelling to me, okay?" [laughter] They They are just business, okay. They are very good at compartmentalizing those kind of things. At least again,

those are the ones that I work with, which is of course statistically no value, but that has been my experience. So, I grab a beer with that guy and I told him, "Why do you think we can do it in half time? It doesn't make sense to me." And he said, "Well, because I have done it in the past and it only took me 1 year." I'm like, "What have you done?" "Well, I did it the game in in the past uh similar to yours and it took 1 year." Okay. So, I'm doing a fighting game. So, your game was a fighting game. It's like, "No, it was a racing game." Okay. And you did it with a team of 100 like the ones I'm doing. Oh, no, no, no. We were 60. Okay. Did you have the team in the start or you need to hire? No, no, no. I already got it from another project from racing racing games. This team was been doing racing games for 6 years or 7 years. Okay. So, if I understand correctly, I need to hire a bigger team. I don't know those

guys. I'm starting from a scratch and I'm going to do a fighting game and my assume is 2 years and because 10 years ago for another console, very old console, you did a racing game with a team that has been doing five racing games and you did in 1 year, you think I can do it in 1 year?" He was looking at me like, "Yeah, now that you put it like that, it doesn't make sense." It's like, "Yeah." [laughter] Yeah, but man, can you please think about it before you you start yelling at me in a meeting room? "Yeah, well, I'll talk to my boss tomorrow. I think that yeah, maybe that I it was a bit too too much." But the thing is, was his experience valuable? There is something, but as with luck, I tend to see that people overvalue experience a lot. Because and the reason is because the people that have experience, we like to show this kind of experience. This is like, "I've been 20 years doing video games." This is how you open everything in every

website in everything. Everybody talks about the years doing video games. Oh, yeah. I've seen many professionals and the way they behave or how fast they learn or how or how they are different over time varies extremely. Very, very different. It's like saying two people went to the same I don't know school and they know exactly the same. That's not true. There are people that iterate very fast, but they never go to the end of a big game. There are people that like only experience end of games because they are in a big companies like Ubisoft and they 1 year they finish one game and then they jump to another game that is finishing and they do not experience pre-production. There are other people that have been promoting very fast and they only know leadership and they have never been in the trenches. There are people that have been ignoring the company and they have been in the trenches forever and never given up value. There are people that they are

only supporting one system for 10 years. I've been doing my physics thing in 10 years. After 10 years, the only thing that you know is this. So, your 10 years are extremely different from someone has done 10 years. So, we put that number because again, simplifies the communication. Okay, 20 years. Okay, so you are silver level. Yeah, yeah, exactly. But um and also there is the factor of negative experience. Senior people come with the this worked for me in the past. Uh Um exactly as as as that guy that mentioned, "Well, it worked for me in the racing game in the super old console." And he has this stand off, "I want to value my experience. This is what I'm bringing to the table." So, that's the first choice for him. But is it? Things are extremely different from project to project, from team to team, from technology and from game. So different than when we say we

are the video game industry, yes, but you look at other industries and everything is more structured. When you go to make a movie, there is a structure in that in that in that process. There is a script, people buy a script, then you hire a director, then you put the money, then you do this, then you do that. It can go well or bad, but you do 10 movies and normally it's the process is very similar. When you do video games, everybody most of the teams they improvise and they decide how they are going to do it. There is no book of let's do a video game, page one, you have to do this. And well, there are actually many, but people ignore them. So, experience could be bad most of the time experience is way, way lower and could be negative. Could be a negative thing. Most of the people at Epic Games are very young and and I Honestly, I'm super happy with the productivity and how bright they are and

they see nothing is impossible and and they just want to, you know, eat the world. And that is a value that sometimes seniors are not getting because yeah, I tried something 10 years ago, it didn't work. That doesn't mean anything nowadays. But they are wired to not try it again if you know what I mean. I see. I see. I recently talked to a old game dev friend of mine worked with him in the past. He sort of gone a different gone a different way, made a bunch of cool games and one of the things he told me was that the more he works on games, he like he feels like he's getting better at it, but he feels like his theories for what makes a successful game become less and less well-defined the more he works on games. He He was like he could have given better advice on how to make a successful game 5 years ago than what he can do now. So, I'm wondering a bit, do you think that maybe maybe if you don't call it experience, but if you maybe call it something like wisdom, can you grow some wisdom? Maybe

the real wisdom is knowing that you don't know. Do you think that's a thing? It's a good term. I like it. I think some sort of wisdom, you carry few things with you. That's for sure. Being selective about which things you want to use or which you don't want to use is the skill. Um For example, I I when I go on the during the weekends when I go and and build a system, uh sometimes some of of of the coders in the team is like, "You did an audio system in a in a in 1 day. You are amazing. You are the final coder. You are great." It's like, "Have you looked at my audio system? It's 80 lines of code." Um he's like, "Oh, yeah, I'm looking at it. Well, it's Yeah, it's very simple." Yes, that's the magic of it. It's very simple. It doesn't do anything it doesn't have to do. I could overcomplicate it. I could I've done

very big systems and normally 60% of it they are never used. Um so, you become very practical. You become very aware of the time that you have, your energies, your moods and you try to control yourself about, "Okay, I will have my Saturday. I will have no one at home because my wife is getting the kids somewhere. I will I will be resting and then I will be focused on this." And I keep thinking, "Okay, what are my goals for this system? Those three things. I will just get those three things in the absolute easier way possible." And way that it's easy to read, easy to fix, and I don't care if I destroy it and start again. Not And that simplicity is probably one of the things that I I would carry with this wisdom. Just do the less that you can do. I mean, sometimes we test the other day I was talking with with a big a tech director at IO, a very

good friend, and told me that they do test for coders when they try to join the the company. And they give them so much code trying to prove their skill. And he keeps like, "I don't know. At my age, I just value the guys that just solve it directly with a simple as solution as possible. They don't mess around. They don't need to build all those kind of abstract classes in order to build a system that It's like, you know, those are three functions and it works. So, if it works, it works." And I love those guys and we miss those. I would say that's probably one of the the the the kind of wisdom that you carry with you, how to be practical. And this kind of wow, you program very fast. This I just decide what not to do. And that's and that's it. Right. Yeah, okay. I see. Some would call that experience. Some Some would call it wisdom. So maybe the thing is also that not all experience is created equal, right? Some of it transfers better to

new projects than than other experience. Like I think people sometimes overvalue how or overestimate how transferable skills are. I find that they're not as transferable as people think they are. Yeah, totally. They are not much transferable. What you can transfer is the way you your attitude towards it, how practical you are and and the kind of understanding you and and how practical you become in order to let's say to analyze the problem, probably preview or or think ahead about problems that you could have with this. This very morning actually, a few hours ago we were talking about with with Oscar, one of our great programmers at Epic Games. He was was saying, "Well, I think I finished the save system." So I told him, "Um we need to do versioning because at some point the save system it doesn't have a version. If it's old and we change it, we don't want to be loading trying to load old save systems." And these are the kind of things is

like, yes, it makes sense. I don't want to explain anything. He will be fantastic at doing it. But it is this kind of I've been there, done that. Let's do this now. It's very simple and it will save so much trouble. Mhm. Um other things like are very simple like for example when we upload files, we have um there is a match of where files can be and which extensions and in which folder they can be. And it feels like like very simple. You could tell, "Hey, your audio needs to be in the audio folder." Just do it. Um but my experience tells me that audios will end up everywhere because people are fast, because we are this milestone, you just put it here, no worries, nobody removes them and in the end you have a chaos of a file system. So now the pipeline does not allow any audio files outside the audio folder as an example. I see. Mhm. Mhm. Do you have any strong opinions about how you should approach

the code architecture of a new pro- project? Are you Are you The The way I would estimate your answer is probably a very pragmatic, "Ah, it depends on the project, right?" Do you have any Do you have any strong opinions on like anything like you should be super minimal, only do what's absolutely necessary or What What are those I wonder what are the strongest opinions you have about that?
So I've I've I've been the over-engineering coder because I could and I want to test myself. I like to build systems that are very well designed, very well structured and they're with minimal dependencies and things like this. At some point even after I jumped totally into the object-oriented kind of trend back in my time and [snorts] it felt like doing for example a C function in the middle of code was like a sin.

Um you need to make a class or a structure that has a class inside that defines and then you go with STL and you do this and you do that. And it and and this kind of let's say it it made this kind of you are proud of your area of the project because in bigger teams you don't have control of pretty much anything. I mean, there are people deciding the art. You actually do not talk much to with them and there are designers and everybody is like, "Yeah, Rick, but you need to make sure that this network code syncs correctly." Fine. So you hyperfocus there and then it's like, "Okay, this is my area. I'm going to make happy in this kind of playground. And now I'm going to build this playground so I am the network coder, the combat coder, the audio coder. It doesn't matter. Um but I'm going to make this program." Then you make your classes, you make your systems, you make your things, then you are happy with it because you are kind of building your house in the middle of a big city which is the game and you are you want to be

comfortable in your house. Mhm. Um but also you want to prove yourself that you are smart, that you can build very complex and very smart houses. So you start building not just a house, but you build a you know, an office building with lifts and and parking garage and tons of areas and you feel very good when people is like, "Why? I don't I look at your code. It's There's so much stuff." It's like, "I know. I know I'm very good."
[laughter]
Um yeah, well, after a few years that's not a compliment. That's actually a bad thing. People should go to your house and understand immediately what's going on. Yeah, right. So this this kind of thing of for example, no need to comment your code. Code should be readable. Uh I know I normally found an average there. Comment the intention of the code. So normally it's how you open a file, the first line

I'm build- I'm doing this file because I intend to do um I don't know, solve these, I don't know, audio listener in 3D V to do this. My intention is that with in this file I cover all the API for this. You don't need to document anything. This is what I tried to do. And let's see if the file accomplish that. And then the the the rest should be very readable. Always prefer readable code, of course. Very simple code um and remove dependencies as much as you can. Even if that means sometimes adding having to add some some code in order to make sure that things are separated. Um because then you can analyze the Well, it's very simple, but you can analyze stability of each area by itself. So would you for example include the rather include the dependency in like multiple systems rather than all have them depend on that separate system? I don't know. If I have like a bunch of utility functions, I have the

choice of having like a utility module and all of my other modules reference the utility module or I could just hardcode all of the utility functions into each individual module and then I have I mean, they have duplicates of them, but each system is more independent. What What would be your way to go there cuz you kind of have the tension between duplicating and decoupling systems? I mean, duplicating is normally the last resort, but it is acceptable sometimes. Um you don't need to be dogmatic about copy code. I mean, it's fine to copy code if code you feel is not going to change much, which normally does, but simple code that you want to just keep in an area, make sure that this code is by itself like you are building a DLL or something like this. It's really like self-contained. Then it's fine to copy code as long as it's not it's not again, it's not a big piece or you think that the change are coming to

this code. But it should be your last resort as long as you try. So for example, in our code every time I need a function is to be function. I don't know. There is a we There is a file that we call misc uh miscellaneous and that we put functions that we don't know where to put. Mhm. And then they have this other thing of um do not prevent how do not architecture the code too much because you are not that a smart and the code is very complex. So sometimes people ask me, "Hey, Rick, this function here feels odd. I I don't know. It's like just put it there." And if the problem grows over time and at some point you see that you have a group of functions that are out of the same theme and they need to be their own stuff, then later we will move them out. Mhm. Do the first work now and keep going until the system works and then we can analyze after the work is done how the game is going like how the code is going and decide where to

move stuff. But you can decide later. Do not Right. pre-architect everything because I've never seen someone who draws the architecture and then codes the architecture like that and it works. It doesn't. Uh so
You figure out the architecture as you as you go, right? Yeah. Brains are not are not wired to I mean, sometimes I see genius people, but then these genius people do not architect. They just code directly. Um but normally this architecture then code is you can draw something in order to communicate with other coders a bit of an intention, but uh after that you start coding and and then you start, you know, iterating on the smaller things and then is when you can do your stuff. And if you see again something growing, something that makes sense, no worries, change it and it's fine. You don't need to stick with your correct with your previous um thing of architecture you had in your mind. I don't know if I am answering the question, but there is it's it's very

broad. I mean, coding it's uh Mhm. It's a it's a big topic like um I don't know, coding patterns for example is something that I discover halfway through. We never got a book for coding patterns. Well, when I was coding at there was no books. Yeah, coding pattern is something I I wanted to ask you about cuz I've seen a lot of like you see people talk about a lot of different coding patterns and always they're like, "Oh, this is the one like soap is the [ __ ] now or ECS is the [ __ ] now." And then it's like you end up very confused there. Which one actually is the [ __ ] I don't know. There are too many.
[laughter]
Yeah, I mean that that's for people that love talk about that as this is their goal of their job. And not and they are detached from the goal itself. I mean Yeah, sorry. I'm not explaining myself. If you are in a big big company And again, you don't know what's going on, but you are doing this a lot 0.1% of the next Assassin's

Creed. And you need to speed up, I don't know, the way inventory shows. Then you open your Okay, what is Give me the the the solution for this. And then you look for something you could speed up maybe with doing some nasty tricks like, you know, whatever having ugly code that will speed up code. But or you could do something nice. And you are very well paid to do the a big very big task. And when your lead programmer asks you, said, I just need 2 weeks and it's going to be amazing. And then you build, as I said, your comfort zone and then you open the book. I've never done this kind of thing. That sounds a nice solution. And then you get excited and you jump and do it. I get it. I've been I've been there. I've been open a book. It's like, "Wow, this solves all my problems." And then you do it and it solves 60% of your problems, but creates other problems and maybe it's not the perfect tool. So, you end up having this nuance about selecting the right tool for the

right situation. Um when someone becomes very dogmatic, it's like, "If you don't do ECS in your in your engine, you are doing something wrong." Oh, that's I That turns me off quickly. Why? Depending on the game, depending on the situation. I mean, yes, it is a very nice solution for some stuff, but all those nice solutions after few years you start seeing them they are not that good and maybe there are other solutions. So, it's the new thing. It's very cool and you want to architect around it and you want to challenge yourself. But you will hear me very all the time saying it depends. It depends. They are very very I mean, they are very good and I probably I will recommend everybody to code them once or twice. You get this very good book of game programming patterns, which I think is fantastic. Very well explained and try them. Try them and decide which kind of

tool makes sense. And sometimes you pick one and change it. Don't worry. It's not about the pattern. It's about the outcome that you expected. So, every pattern comes with advantages and disadvantages is what you're saying and which is I think also what makes sense, right? That the pros and cons to everything. Would you say that it makes more sense to pick one programming pattern for your entire project or do you think about programming patterns on like a system to system basis?
Oh, no, no. It's always system to system. I don't think of any pattern that is kind of a general solution. So, um No, no, no. I mean, for input, for example, if I'm currently the command pattern is very interesting, especially if you need to buffer in different inputs. For the whole structure of the tree for the scene, ECS is a nice choice. I mean, you could deal with something else, but it's very well packed for memory could memory serialization continuity. I

don't recall the name. In order everything is packed in memory, so you go through this uh very fast, very optimized. For that kind of problem, you apply that solution, but the moment you need to do a an audio system or you need to integrate wise or something. I mean, it it really depends. I would say no, no. It's it's better to have knowledge of all all of them and decide which one to pick or don't pick any. I mean, you don't have to They are just solutions that have proven interesting and good in the past for certain areas. But each of them, like in the book, will tell you, "If you have problem A, B, or C, this could work. Try that." I see. So, you would pick more on a system to system basis and you don't think it's a problem if I use ECS for one scene and then soap for a different thing or whatever. Got it. For the scene manager, ECS, if you stick with it, go for it. But do not be dogmatic that everything needs to be

like that. Especially nowadays, it's very rare that you are CPU CPU bound. I mean, you need to be quite a bad coder um to or you are doing a mistake if you are CPU bound nowadays. Okay. And and depending, but with GPUs taking so much work out of your hands, be practical. I don't mean that you do not optimize things or you don't you do things, but and don't be reckless about overusing the CPU because you don't care. Just be nice to the CPU. And as long as you are nice, CPU will be easy time CPU will take over most of of of of the serialized work. So, you should be fine. Sure. Yeah, at university I remember one of the first game projects uh some of my friends, they they had a prototype um with weather effects and like all of the snow particles were like rigid bodies in Unity. And that was not very optimized.
[laughter]

They were not very optimized. That's what I said. That's a coding mistake. That's a or a That's that's a mistake, but it's not that the it's a slow because your computer or something. Yeah. It's a slow because you did a dummy mistake. But that's fine. I mean, you learn from this and and we all have done this and probably will do it in the future. That's fine. But and again, it's more of an easy clear mistake than back in my days, you really need to take care of every cycle of the CPU and be very careful. Mhm. Uh these you don't I mean, it's not that you can ignore it, but just again, be nice to it and that's it.
With Starfinder, you're fully working in Godot, right? Correct. I think that's one of the the biggest Godot teams I've heard of. Do you know any of similar size or Just think you want to do the biggest. I think that there might be others, but maybe they are hiding in the shadows doing a fantastic game that will come over in the future. But No, I mean,

I was talking to Renee about PPK fantastic game Mhm. they are doing. I think they are 8 10, something like that. Yeah.
But they have contractors and people helping them, so that will that number does not Yeah. explain the whole story. Um but no, ours is is is pretty big. I would say if not maybe one of the the the five biggest using the engine right now. Do you think that Godot maybe incentivizes certain design patterns more than others? Like, for example, I think Godot has like these this event system, right? Where you can connect things uh with signals, I think they're called. Yeah. Uh yeah, Godot is is built in a way I mean, one of the reasons I pick it because I probably will make if I would do an engine right now, I will do things very similar to them. Um I think it make a lot of sense all the decisions that they made. And it's a small it's Oh, small. I like

it that it's a small. Yeah. And [laughter] nimble. It's not bloated and it is how it thinks should be. You can do so much with one or two megabytes of this in a video game. I mean, I It kills me when I see wasted hard drive, CPU cycles. You with Unreal and Unity just loading it, you see all those things. It's like, "Come on, man." The things I can do in a millisecond and this I've been 10 minutes waiting for this. This is This is outrageous. Godot incentivizes I mean, the structure for the scene tree is very interesting. So, the concept of everything is a node works. I think it's it's just a way of doing it. I mean, I wouldn't say it's it's good or bad. It's just a way they they do that and which is fine. I think the moment you get used to it, well, you see the benefits of it. They their scene tree is very well optimized, so that you can handle hundreds of thousands of nodes, no problem. And but the

the good thing about it is makes it very transparent to see what's going on. I mean, it could be complex, but it's transparent. But I wouldn't say it's the biggest the the biggest perk and that has Godot over others other engines. Um you I mean, when you in Unity or Unreal, you pick one game object and suddenly you see all the components uh down there. And you could be scrolling and there are many things Wow, that's a lot of stuff. Um which is fine. But all those stuff, it will be nodes in the scene tree in Godot. It's really the same. You can get the same complexity, but visually it helps a bit. I wouldn't say it's a big thing. Signals are uh very smart choice for Godot. It It is a way of decoupling things that works very well. The only thing that that that worries me is that I don't like that that very long uh call stacks. And signals, by default, they immediately

call functions. And so, normally I am the guy putting always, "No, this is a deferred signal." So, you call it on idle time. I don't have long call stack. But again, I think that's me. It's not a big deal. But I prefer things to be in video games, you end up isolating things in the frame. The frame is your kind of playground there to work. And the moment something happens, if possible, it's like, "Okay, something happened. I'll take note and I'll do that later." But do try to not do something and then that thing does something and then the something and and then suddenly you see a spike in the middle of you get a frame that does a lot of stuff. You want to do stuff you see that all the player hits I don't know a detector or a trigger or something. Okay, I'll take note. I'm not react right now and I'll react maybe next frame. I'll react by the in the idle moment of the frame or when I finish this and this thing balance things out and

actually makes the code easier to understand. You know that the moment you are reacting to something you are just doing that. You are not calling from 10 things that that that could generate very long call stack and probably makes it a bit more efficient for the CPU as well because you can like batch process all of the things right? If you have like very deep stacks then the CPU has CPU has to go through a lot of different types of code where is if you just take note of collisions events or something then you can just batch process them in one go if you have multiple of them. Yeah, normally I I I prefer this because also easier to debug like for example the bark system so people things could be happening the game and then the characters in our game could be saying I don't know there is a window you are doing this there is a bad guy coming and they notice things. So the way I do it is like every time there is anybody calls like hey this guy

should be saying a bark I just take note of it and then at some point when I get to the process is like okay what is my queue of barks to say? I mean this this this this you know those are a lot I don't think I will process all of them so let me process three I'll take two or three and then the next frame I will do more it's a queue that I will be exhausting because frames in the end I mean when you have a game that goes 30 60 frames this goes extremely fast. You don't have to solve everything in the same frame. So when you have that mindset of a slicing frame slicing or I think it's called the putting things later the old systems breathe very easily because you see okay I'm going to solve three of those and then you solve one then you look at it and you know that when it's up you know the code when it's going to be the code to be executed in the process not

exactly when somebody says that this guy should be saying something else gameplay-wise is not important that it happens on the microsecond or millisecond. Game a code gets simplified that way even if you have to do a queue which is basically an array you pop and push which is nothing. How do you personally go about planning the architecture for a new game? Is it is like multiple programmers sitting on a table and like you come up with this big master plan or do you break it down into smaller systems immediately or like let's just say I want to make a new game what would be your recommendation for how to approach code architecture? First it needs to come from the game code architecture is it's like saying hey how do you approach to build an engine for a car? It's like it is a racing car or which car it is. First is which car it is and that is very important to have it as much as you can define. So for

example in Epic Towers we we know we wanted to do the CRPG. So what you do is literally make in Spanish we said the carta a los Reyes Magos which is the letter to Santa is like what are the toys that I want. So you go open Baldur's Gate 3 wow I need a dialogue system I need people moving around I need a combat in turns I need to upgrade levels and and you start going with a high priority level okay done done done and at some point you have your your the toys that you want you have like I don't know 30 40 very high level because in the end we are copying a kind of a structure of a game the genre already expects those things. Again this goes game by game if you are going to do a very innovative game this could go through a different cycle sorry a different cycle of discovering but most likely nowadays you are taking 60 70% of another three games. So you just first make the list in a paper and

once you have that then is you start breaking them down into pieces. Okay so yeah I need to do combat what is combat? Well I need for combat a storm base combat. So turn base combat it means that how do I isolate those pieces in a way that they didn't need to talk to each other as less as possible. Can you sorry to interrupt can you quickly explain why decoupling things is partner I think I I think I have some answers for this but I'd be curious in how you answer this. Why why is decoupling things important in the first place? I don't know feels too obvious to me I never
[laughter]
I never got to is it easier to debug or is it does it make systems more usable or like what? Okay so first again with as with anything you don't need to go crazy about decoupling sometimes couple systems fine but the so the coupling

systems allows you to separate things in a smaller elements and the breaking big problems in a small problems. Again the the first thing and is you need to acknowledge that compared to the complexity of the code that you are doing your brain is a stupid. Doesn't cannot handle it. Your brain is very limited compared to all the complexity you want to handle. So what you are doing is that you transform the problem in something that your brain can handle. So you keep breaking it down into small pieces until one piece fits your brain and the moment you have that then I can code for it. Okay that all makes sense. So combat as I said so the example will be for example one of the things that we did is like combat it's a lot of pieces. So in a turn base can I have a system that just handle turns? You give them

IDs of entities or something and it will and then it will tell you okay turn zero your turn and then it waits for the entity to say I'm finished it's like okay now it's your turn now it's your turn now it's your turn we found the round we finished the round we start again it's your turn again and then maybe you can tell the turn system oh by the way this entity is no longer in the combat. Fine okay it will handle it it's like now it's not your turn it's the other turn or you can say by the way this guy moved and it only handles it problem and you take away everything and say combat is too big for your brain and suddenly turn base well I think I can handle it it's just basically IDs and entity IDs that are in one sequence how hard this can be? Well normally that happens is that is actually not a simple thing and you start coding it and and you as long as you keep practical maybe you can solve that in I don't know 500 lines of

code or something. Well that's because we use GDScript and it's very easy very quick in Godot but in C++ it will be three four times that but regardless of that you solve that problem because it fits your brain. And that's it I solve it I have this turn manager and the turn manager doesn't care it just not need need to know that do I start what are my entities and it can decide by the way I don't have entities so the combat is finished. It will tell you because I don't have more entities that are active and will signal those things in and out and you have this box that solve this problem and the good thing is like out of combat you remove 20% of the problem. It's like okay this is solved and I do test and I make sure this works and the code and the code is easy because if there is a problem there it's just 500 lines of code it it's easy to find out what's the problem but it doesn't try to do everything it just solves one problem.

Move and then it's okay now skills I need to start fighting skills and killing people how what is death? Okay death that is is a is a complex concept in a game like that you can be unconscious you could be participating you can be inactive you can be so what how we are going to handle that and then you break it down in another thing and you try to it's like okay there it has to be a criteria to decide what is that and what is not and this will be handled by by this. This is skills this is test this is start this is movement and you make sure that all those pieces gradually solve the combat problem which is a big system is a like epic level kind of system.
Right so do you sort of think about it in terms of layers so you have like basically systems building on top of each other or is it more like a puzzle with a bunch of interlocked systems?
No those are layers of course layers. So

what you do is going back to the turn system. So does the turn system know what's an entity? An entity is a class somewhere else doesn't need to I mean what is interesting for the turn to know about the entity? You don't have to. So okay so they are not going to be entities they are just going to be IDs. So it's like hey there is a new thing that goes into the turn system and the turn system okay, you are going to be number three. And I don't care what you are. It's just I only handle order. So, I don't need to know that entities exist. I don't need to know if people are alive or dead. I will call it deactivated or out of combat. You decide what means death or not death. And you keep removing all those concepts until turn system is something you in theory, and I get and this is not a very good goal, but in theory, you could give it to someone else, and they will have a

turn manager that they could apply for other stuff. It's important to not go crazy with this because modularity it has its place, and some people some people go crazy about everything needs to be modular and and things like this. Don't don't go crazy with that, but it's a good goal to try to achieve. So, our turn manager as is this example doesn't know what is an entity. Doesn't know anything about anything else. It just knows it just handles order. And and that's about it. And that's already few things to solve. And in my experience, sometimes programmers young programmers and experienced programmers is like, that's too easy. I can do turn and then this and then that. It's like, okay, if it's too easy, just do it quicker. That's fine. You feel it's easy, but trust me, it's going to be more complex than this. Yeah, but come on, Rick. I just I think that I can do the whole combat together. No, no, no, no. Just solve the turn thing, and when you have it finished,

let's talk about how it is built, but just do that. And 90% of the time they come back is like, actually yeah, there was a lot of nuance into for example, there are the concept of you can delay your your action. Um it means delaying your action. It means that you can decide to not be not take your part, wait, and then you could send a signal I want to act now. Well, this is part of the turn system. Well, that's few functions to handle that and new member variables, and it keeps growing. And also the fact that it's a small thing. The moment we grow in the future, we can just go one of those small pieces of code. It's like, you grow. But it grows. They they were small in the first place. So, they never become normally they do not become overloaded. So, yeah, um that that would be called the base layer. That's the base layer of systems that do not talk to each other and don't know anything. But then you can the next layer you build on top of that they obviously need to know the layer below the side that means they

they must have dependencies. They don't they don't work without the dependencies. Yeah. So, for example, there is the game estates. The game estates is where I am in the in the game right now. So, there is a state that combat is starts. Um and the state as another example just handles movements between the states. It decides when the state is finished and what to execute before going to another state. It decides arguments when the when the state is starts, but it's actually variant. It's just normally a I don't know, like 50 lines of code 80 lines of code each state. So, for example, the combat state starts and it does okay, it seems that everything is right. Combat should start. Um I have people and they are alive and they hate each other. They are different factions. Feels like combat is right. That's my job. The only my job is to know that that state is fine. Okay, now I

uh call into memory or activate or whatever the combat manager. And I know about the combat manager and the combat manager appears there. Hello, I'm here to handle combat. Yes, it is the right context. I checked. Combat should start. And the combat manager is like, fine. What do I have to do? Uh okay, first I need the turn manager. Turn manager, I'm starting. Those are the 10 entities that are going to fight each other. Those are their their factions. Okay, you have it. Fine. Okay, now and that I have that, I am going to play cinematic scene. Combat is starts. Okay, I'm going to grab this cinematic with this system and this character will say his voice. What do I have to know? Well, it seems that combat hey, turn manager, are we okay? What is the first guy to go? Ah, it's it's ID number three. Whatever it was you said I three is entity. Oh, now it's the time for the character to play. And then he basically orchestrates three or four systems together. There is a moment you do this combat manager, but that's the as you said, that's the second layer.

So, you do have orchestrator scripts cuz I the the modularity extremists I'm I'm not sure how they would even approach it. Would they try to make a generalist orchestrator script that they plug other scripts into or that's that's not a good good approach anyway. No, no, no, no, no. So, I mean, there there was a a very smart coder Casey Muratori, which is absolute genius. And he described coding as I think was syntactical I think simplification or syntactical compression, something like that. What you are doing is layer by layer you make things simpler. So, imagine for example, that we don't have a turn manager and we have the combat manager. And the combat manager starts like, okay, I'm starting. I need to know who goes first. Okay, I'm going to start coding this. It's like, okay, this is the entity. You roll initiative. You go there. You go

that. And it it grows and it's very big. Um so, the what turn manager is doing is syntactically compressing this complexity into five function calls. All right. So, suddenly the combat manager is like, uh turn manager, just start and do your thing. Um those are the 10 guys. Which one is the first? Ah, I did everything. It's number three. This is code that is compressed. Syntactically you compressed tons of complexity and the turn manager just handles that. Um so, turn manager is syntactically compressing this. So, when you look at the combat manager, you don't need to have a long combat manager. It's just telling the the turn manager to do something. Then it goes to the entity and tells them, hey, you need to wait or the UI you need to wait for the character to decide what to do. Or it's an enemy. So, just AI system, which is already compressing all this complexity. You do you. Tell me when

you're finished. And you are selling but the code even if you are calling different systems is simple. It's syntactically compressed. It's readable. You see what's going on at every step. And with functions of 20 30 lines of code, you see one turn happening because you are calling all the systems that handle the problem for you. Right. So, if you write a system and you notice it becomes too big and too unmanageable, then perhaps that means that you need to compress some of the sub problems into their own system. So, you you keep doing that. The idea is you keep doing that until the problem almost becomes trivial, right? Or Correct. Until you see as I said, at some point the combat manager with all of this would not fit my brain. And it's like, well, I don't know what's going on. There are always bugs here. It's so long. And honestly, I just after 2 weeks I don't understand anything and that that I did

here. So, it's clear that you did a code that the moment you were coding it, you felt confident that you understand it, but when you are back, it's very difficult to handle and other people cannot understand. So, at this point, what you need is it's it is a symptom that you need to do syntactically compress something. And it happens very often and you need to be flexible on that mindset when you're coding. It's like, okay, this is growing too big. I feel this is a problem in itself that doesn't need to be connected with other stuff. Um can I compress it into a manager and put it into layer zero, which it just solves this problem. And sometimes we have managers that are literally 60 lines of code that solves a very simple thing, but it makes the code the gameplay code very easy to read. It's like, I'm calling this manager. For example, mouse. We have a mouse manager that decides which kind of

mouse icon you're showing. Uh-huh. It's really like a call function. Just put that mouse into it. But if you start thinking about it, it's really a stack. So, when you go into I don't know, you go into an area of the screen that the mouse goes in, it changes to I don't know, looking at something, but then there is an inside area where your mouse goes in, and then there is this other one. When you leave, you are is basically a stack base. You remove the top one, and then you see the previous one, and then you see the previous one. Well, okay, there is a stack to it. Fine. How do I define the icons? The icons are I don't know. Maybe it's an enum. Maybe it's a list of resources, but it needs to be very easy for me in the gameplay code say, put the icon of whatever you use when you are observing an element or you want to attack or you want to pick up. Pick up. And that already justifies a mouse manager. And the mouse manager is actually not simple. It has many things.

And this keeps happening. For example, I got surprised how difficult the target targeting manager was. When you are selecting different skills in our game, it's like, okay, you need to have a cone. Well, I thought that you pick an enemy, and that's it. It's like, how difficult that is. So, I put it into the combat manager, and then I was like, okay, just picking an enemy, that's fine." And then the designer is like, "Yeah, but what about if you need to pick two enemies?" It's like, "Yeah, I guess that I can just increase it. You pick one or two." "Yeah, but you can only pick enemies that have this condition. If they have this other condition, they don't." Like, "Okay, so I need to filter by tags." Um by the way, this other skill has a cone. You need to first send the cone, and out of the cone, you need to select three uh entities. And that has this condition. Like, "Okay, let me stop you there." Targeting system. Let's get all this into a something that

solves this. And I go to the targeting system, and targeting system actually has grown in one of the most complex systems that we have because there are many ways to it. But I didn't uh didn't expect that this to be that complex, and well, I learned the lesson. But again, you just need to be flexible about it. Would you say that like what differentiates a good programmer from a bad programmer in terms of how they architect their games is is the skill in knowing how to compartmentalize your code? Or what's what's the difference if you look at like a first game jam student project versus like a professionally done triple A or what what are like the what's the learning curve? What are the skills that you can work on to get better at that?
I will start with this saying which is saying depends. So, if you are a systems programmer, your goals are very different from a gameplay programmer, things like this. Um so, system programmer, for example,

have more of focus on understanding the underlying hardware and how to optimize correctly for it. So, in this case, for example, in our system will be the Godot programmers that are improving the the engine. Uh what we do in Epic Tellers is basically gameplay programmer. We don't do uh engine programming because Godot solves that for us. Um so, gameplay gameplay programmer have a different goal. Gameplay programmers, my experience tells me that they need to have this 30% of game designers. And that they play the game. They want the game to be fun. They the game want to be useful, and they are not solving a coding challenge. They are solving a player facing feature. And they need to be able to put themselves into the shoes of the player, understand what the designer is wants to achieve, challenge that if it's needed. They need to be a bit of game designers. And once they get it, they need to embrace it because no game

designer is going to take to do it right in the first place. And they said, "Okay, I think that for targeting, I think for the combat, for this, for that, this makes sense." And a good designer will tell you, "This is my intention." Won't tell you details because the programmer needs to fill those. Um and then you go and do it, and then you start, "Okay, I want the best experience for the player." The code is a tool. Code needs to be of course, minimally well structured, easy to read, easy for the people to jump in. And as long as it's it's like that, you are doing a good job. And that's about it. Minimal, practical, everything that I said before. I can go with examples of bad programmers that that I found. So, I found people that they want to show that they are very good programmers. So, they overcomplicate the the systems and yeah, but look at what I can do. I don't care.
[laughter]
This is not necessary. I am sure that

you are super smart and you could do amazing things, but the solution for this is way simpler. And then there are the ego ones where well, the designer told you this other thing, and this sounds not very compatible what they were intending to. Yeah, but this is better. The designer doesn't know. Uh okay, that's someone who collaborates cannot collaborate correctly with the rest of the team. There are designers that say there are programmers, for example, that they are too cautious, like, "Oh, this will take me a month." It's like, "What? No, come on. This is really like 2 days maximum, three if you want to check it." There are coders that upload all the code and forget about it, and suddenly things are crashing, and then the first reaction is to blame others. It's like, "Well, you should be doing something wrong because my code works well because I tested once." Um so, in general, the gameplay coder is really a good team player. And code

needs to be and needs to be easy to work with for the rest, but team player. QA, design, other programmers, bring them together, find the easy solution for the problem, and move forward for the next feature. Simple as that. Got it. Why why is it that some people are what would you recommend to people who code themselves into a corner, but like this happens I think this can happen if you're like not as experienced if you're making a big project for the first time, and at some point you open the project, and you can't work on it anymore because it like the complexity got too out of control. This is something like I you don't hear this super often for like people who have been making games for a while cuz they're more careful with it, but this is something you hear sometimes from from people who make the first games where they're like, "Yeah, I had to start from scratch three times because I coded myself into a corner two times."
[laughter]
I don't think there is a good solution. That's uh that's what that's the

programmer journey. I've done that so many times. Just for the fun of it. There was a good very good presentation at Godot Fest by Renat from Living Beeps where was explained the beginning exactly what all the coders we have been through. We want to do games. Maybe we don't have artists around us, but we want to do something cool. We have a general idea. And then you get into how cool is the code, which is different from how cool is to make a game. It's very easy to different to the to differentiate the focus because you get attached to the very good ideas that you are have while you're coding. It's like, "Ah, I took this shortcut." And suddenly collision is super fine and and very easy. And you are proud of yourself. But you are doing things just to challenge you and to proving yourself, which is great. It's like, "I can do it." For example, I remember I spent a week coding from scratch in C a dungeon crawler that that with collisions and everything,

very old classic, very like sharp corners and everything. And I was having my kids just drawing me bad guys, and they were putting them like a billboard. They were having much fun. Um and it was cool, and then move on. Because I mean, it's nothing. It's just an exercise. You need to feel it like programming is like a sport. Every morning, sport people just go and pick a bicycle, go running, and things like this. And it's fine. I mean, you do it, corner yourself, and learn from it. But the most important thing is learn from it. Most of my intuition and my practicality coming from cornering myself into those problems. And already saying, "Well, if I would not have done it, probably I would still be overconfident that we can complicate it, but it will find because we are very smart." Um I learned the limits of my brain by by doing things that are way more complex than I can handle.

So, I think that you should probably try to not feel very bad about it, but move on. Move on and do it again. Doing exactly same thing again, you will see that you will have many different ideas, and you will do it differently. But that's fine. I mean, just own it. Okay. So, not you don't see a problem with starting from scratch. You see it like a as a natural part of the learning journey. I mean, in a big company where you need results, and people are watching over your shoulder if you get things done in time. If you feel you are approaching this, involve your lead programmer, and involve other people, and they they will give you perspective on what you are doing on other ways of doing it. Sure. Um at some point, for example, most of the the coders in Epic Tellers, they smell that they might be something too complex, and they just call me. Like, "Okay, am I am I Is this a good direction? How do you feel about it?" And we have a conversation, and normally sometimes

they are doing fine, sometimes I give them some perspective, sometimes I do not add anything. But but at least you become good at smelling that you are probably building digging yourself in a hole. Um But in your spare time, I would say do it as many as many times as possible. As long as you learn from it, every time you will become a better programmer. Is there anything like programmers who want to learn like in my specific example, I'm trying to understand what I need to do to become like a better programmer and better at architecting my games. Is there a specific question that people who want to become better at programming don't think about that sort of that they should think about. Is there anything I didn't ask that maybe I should have asked? Okay, Jonas, what what you have done so far? I mean, how long you've been coding, and what are the things that you have done? Sure. I've made like three indie games in Unity that have been commercially quite

reasonably well received, I would say. I made Now, one of them was actually in GameMaker. So, I made Islanders in Unity in like a team of three, so fairly small indie team. Then I solo developed a game in GameMaker, which was like a platformer, and now I recently released a game called Thronefall, which we made in Unity over the course of, let's say, 2 3 years. And that was like a fairly big project, like multiple levels, top-down strategy, tower defense kind of thing. Yeah. And now we're thinking about maybe going into multiplayer and like stuff that where I think it could could really be beneficial to struct like to structure other projects properly. I've never So, I think I've developed a bit of intuition about how to structure code and I've had my learnings from it, but I feel like there is so much to learn still.
[laughter] [gasps]
Yeah. But But you are concerned about

how to become a better programmer, but it seems that you are doing fine. So, what is the problem? I mean, why why What is What is this kind of image that you have of then I will become good and I will cross that frontier and I will be joining the hall of programmers. What is that? Yeah, sure. I see this as a gradual learning journey, but I guess part of that gradual learning journey is also to ask people who've been in it long for longer to to see if there's anything to learn from them, I guess. So, I don't see it as like, "Oh, there's one secret hack." It's probably like a continual progress, right? That's probably the case.
your goal is to to become better programmer or commercial success with your game. So, I guess both or I think the the goals are interlinked. I want to become better at everything if possible. They don't have to. I mean, being commercial success and being a good programmer feels like they are aligned, but they are circumstantially aligned. They are not

There are people that are very good at picking the right game to do. That that is attractive for the audience at that moment and and things like this. And And these people will be way ahead of you, no matter how good programmer you are. Uh so, good programmer what will what will make is that the game will be will have less bugs, will be easier to maintain, you will have to do less crunch, and you will have feel happier while you are doing it. But it's a tool. The game The decision of which game to do, the decision of with whom doing it uh you are talking in plural, so I understand that you are now part of a team. Mhm. Small team, yeah. Two people? At the moment, yeah. Okay. So, be deciding who to do it with whom with whom doing this game, and the game itself it's uh 80% of the equation. Uh with you becoming a better programmer, again,

after what the background that you have, you will get 2% more or 3% more into this kind of quest into making a better game. But you also seems that you have genuine interest into the engineering of coding and enjoy having a solving problems in a smart way. That is fine in itself, but you need to make sure that that you see the difference between those two. I rarely have seen code from video games that are well structured. It's always a mess, but it works. Uh we don't care. We do video games. We don't do uh you know, uh space level NASA kind of code that needs to be stable or people will die. We do very sim are simple, you know, not not critical systems. I actually recall a guy that we hired in in in Pixel Studios that came from making an operating system for trains for train system that need to go in.

And the guy couldn't survive a week. He looked at the code is like, "How you are doing this? You nuts." It's like, "Yeah, we don't care. I mean, the game is fun, so that's the goal."
[snorts]
And And he he couldn't he couldn't I don't understand this is so complex. There are pointers that could be null and you don't check anything. You're nuts. Yeah, well, it sort of works, so we don't care. So, that's that's uh for video games you need to understand that that code's mastery is is a is is is not that attached to it. For code mastery, normally the best thing you can do is probably join a company with other coders that that will drop you. You will see other code. You It will be, for example, beneficial for code mastery to move to another engine, try to do things in Unreal, try to build even your your own engine. Um All those things brings you closer or faster to code mastery. Remember what I said that all the experience are not of the same

value. 5 years of experience doing Unity are not as good as 5 years that that I did on Unity, Unreal, my own engine, and Godot or something. Because you are changing the context so much, you force your brain to to learn very new things. But that's the road for code mastery. Making a successful game is not that road. It's a different road. Okay. Then it's like, use whatever the tools you are used to. If Unity is your thing, do Unity. If the kind of game that you want to do, go for it. And then your commercial success will be based on your smart choices around what makes it fun and the iterations that you allow yourself to do and how do you, you know, listen to your players and things like this. This is way way way more important that which kind of code architecture that you have because as long as it works, that that is not super relevant for video games. So, it's the difference in how efficiently

you get there. So, the main deciding factor is like game design, idea, market fit, a little bit of luck, and so on. And then if you have a better code architecture, the perk you get from it that is that you get there more efficiently and that maybe your project is more more scalable a little bit or something like that. Or how how do you look at it? Well, the scalable systems are also a bit of a myth. Like Like reusable code and I don't know. I'm too old. I've never reused [laughter] much code. I mean, the the best thing you can do is just start from a scratch um most of the time. Yes, you can reuse code, but also it's very boring. You want to code your own stuff. No, it's it's a bit of a myth from my point of view. So, you don't believe in building a code base and then when you make your next game, you re reuse half of your previous code base or something like that. It's not doesn't speak to you. I do believe and life have teach me otherwise. Um I still believe it. For

example, um one of the reasons we are doing CRPGs in Epic Lores um and we are announcing that the company is about that is because I strongly believe that if you keep doing CRPGs, technology can transfer decently well because you focus on content and not technology. Because CRPGs have not progress on technology that much. Pillars of Eternity, Kingmaker, Divinity, they are all having the same approximate systems. But you build very nice narrative. You become better better at writing music for it. You have levels that are more interesting. You have companions that are have better art. That is fine. That is content. But the systems can be reused. But I have already specifically targeted to build a studio around one kind of genre, which is is is a spec That's That's why I I said I believe that you can reuse some. Having said that,

um in general, uh people overused the term um this will be something that I will use in next 5 10 years because video games and life are very chaotic. They are not predictable. Your brain tricks you in telling you that in 10 years you will be doing your third game and this system you are coding right now will be fine. Reality, it's a mess. The systems and thinking changes very often. You will have a different perspective about code in uh 8 years and you will look at your code that you're doing today is like, "What the [ __ ] I was thinking?" You will have different games. And uh there is one thing that people uh normally don't don't think about is you will become bored of doing the same thing or using the same code. And this is a huge factor because the fact that you are asking me several times, "I want to become better." And that's fantastic. That's an energy you have to learn.

Now, imagine that you build your next game in multiplayer or something and you master it. And now you have to do three versions of it, three sequels that are exactly the same. You don't touch any code and you just design. You will become bored very fast because your brain wants challenge. You want to What about all those books that tell me that there are fantastic ways of solving things. I want to solve complex problems. I want to write a new system.
[laughter]
Exactly. So, um this this this is, for example, a something I I repeat a lot to my my my my my my the the team and Epic Lores is that "Oh, this is very complex now. This is very hard, but I think that when we do the next game, we'll be more experienced, so it will be easier." Um yeah, but also will be boring. Now, you have this kind of energy that every time you learn something, your brain is very happy and makes you happy.

Uh it's a survival thing. Brains want to be learning all the time. Um if you at some point stop, your brain tells you, "Come on. What is my drug? I want to learn more stuff. I am not high on learning. Uh And then you will make the game more complex just because. So let me bet right now that the fact that you want to do multiplayer in this new in this new game is also because feels good to do something you haven't done maybe before or you already maybe don't know something directly try to do a game that with technology you haven't tried because you want to do multiplayer and check how it is. It's a way to up the difficulty for sure. Yeah. Mhm. So you will be keep up in this difficulty. So this system that you think that in 5 years you will use you will want to rewrite because you will have better ideas. So no writing is a myth. I modularity in a way that you can reuse code it's a bit of a myth because of the

human factor. Mhm. With the exception of maybe specifically building a studio around a very specific genre and then strictly sticking to that genre. Which makes reusing maybe more viable. A percentage of more viable but I assume that we will be doing more stuff. So for example our game is not multiplayer and as you said in our next game CRPGs are very cool in cop. So I would love to to jump into multiplayer we needed to cut it to keep a scope doable. But what happens we have all the systems figured out and we have multiplayer figured out what we do I don't know multiplayer for multiplayer forms cool how it would be to move your game to a switch to that's a very interesting problem to have. I would like to see a devkit I would like to see how what are the metrics [snorts] I mean how do I solve that problem? That's cool. What happens when you solve you put the game in all the consoles and you put you solve multiplayer and you just do another game with a different

characters and different music and stuff. Boring. And that's a human factor that then it will be it will be a problem in the future I suspect if we manage to survive the current state of industry and but we will have to deal in the future but right now I keep telling we are in a very sweet moment you will remind remember this moment because you are super energized because everything you do every day is new and that's a fantastic thing to even if you feel that you are not experienced enough and you could be doing mistakes. That's the situation you want to be always. You want to do the fourth game and feeling that you are doing something new. If you look at the statistics all the game studios do one game and then the second game takes more time than the first one even if it's a sequel. Mhm. How come? Interesting. Always. And it's something that project managers do not understand.

How come? We built everything. So we just How come? It's because it would be a shame if the second game was smaller than the first one.
[laughter]
You you want to But even with that you you spend you have more people in the second project. Mhm. And it becomes less more difficult to ship it and it you get more delays and it's it is a tough thing. So again human factor. Code yes code could be reused but it won't. Interesting. One of the things that that probably uh that that teaching at the university I think is something we are missing in the game mastery education but specifically talking about it not about shipping cool games again I told you that those things are different. Yeah different. Yeah. I think everybody should be writing their own engine. You think this? It's like a as an exercise or to actually use it?

No exercise use it doesn't make much sense nowadays but as an exercise when I was at the university and we were building a curriculum for this video game kind of official course very well suited 40 years I managed to do a bit of a trick because they said okay Rick there's going to be a subject that is called game engines. And and they assumed that I was going to teach a real unity and I don't know cry engine or things like this. I said oh fine I can take over and I handle yes yes you Rick you do everything. So the first day the first day I said okay guys we are going to build an engine. This is the subject for game engines and we are going to learn to do all this all the parts of a game engine we are going to do everything in C++. from a scratch. We will use SDL to just open the window and the rest is ours. We have an open GL context let's go for it. We are going to build all the systems ourselves and they

were like whoa oops. It was a hard subject but it's like learning C++ and then or C and C++ and then learning our language. You learn Latin you learn the source of everything. You learn you understand what is a scenery you understand what is an audio how do you handle audio do you understand physics engine how do you understand how to load geometry how you draw it and you have visited all the systems in the most not in the most because you could do it even lower level but you have tested all the systems yourself in a pretty decent low level and then when you first open unity it's like okay how this handles audio how what is the physics system? Oh okay is this attached to the frame to the visual frame or do you guys detach frame or how do but you have a lot of concepts

clear because it has gone through your fingers when you were coding. And I see that it scares me a bit that we are evolving to a moment where the only people that knows how to do game engines are the people working at unity and unreal and there should be if if that would be the case Godot would not exist. And and probably other engines maybe there are other engines in the future that should happen but we should not be sticking with specially commercial companies that they do something and it's kind of black sorcery again how to do game engines but everybody knows how to use them but not how to do them. Which again it's fine to make that difference but if you are going through the path of code mastery building your own engine makes a lot of sense. It's a lot of time and you will corner yourself into a an impossible code complexity

and that is fine. But if with some guidance some way of of some structure we would be building a full engine not a full engine but let's say with a core part in 4 months. Well actually it was 4 months and then I asked them to expand on one system to each to each of them. Like for example you are going to do the physics you are going to do hot reloading and scripting for example in C++ or you are going to have a VM for Lua or you are going to have a UI system that is really well done in an editor but everybody did all the scenery save and loads undo load geometry draw it create the concept of a level create the concept of I don't know audio all those things you could already put geometry there have a character move around it's like okay I have everything there in an editor and you build your own editor because nowadays there are enough libraries on

C++ to simplify your things like your life like in GUI for example which is excellent a same to load geometry. Yeah. So you can patch the most low level things and then in 3 months you can build your own your own engine. And that's something I think that I'm scared that in the future it will be only few people that still keeps this kind of low level knowledge. So I would say for coding for coding I think it's a healthy thing for everyone to go through. Because you understand a bit more what's going on under the hood you understand the system smaller. Yeah I mean you know I mean it's compiling shaders what it means compiling shaders why why there is a need to compile shaders what is the concept of that? You seen through the code and you're doing yourself and you have organized that you understand what unreal you have the better intuition when unreal is saying because of course there is a lot of complexity in there. And

and you can learn any engine quicker because you have this kind of understand of the moving pieces around. Which I think it should be more the goal of the university to understand the base and then yeah you could do a course on unreal or unity but you understand the pieces of how the machine works. Why why do you think why does it feel so much like unity and unreal have so much bloat compared to Godot? Do they just have more features or is it something else? I mean this is commercial this is specifically commercial reasons and historical reasons. Historical in a way that you accumulate stuff and you keep working on the same thing. And commercially wise you are pushed to have new things all the time. So you want epic wants like the next unreal is going to be amazing because it has this and this and that. And unreal and unity

are not paid by the coders are paid by the business owners of the of all video game studios. And they will attach a price with value and they will see a video where someone in half an hour has built a racing game. And they will tell you, "Well, we have the game already half done because of Unreal. I'm going to pay this incredibly expensive uh license so you go there have an easier time." And I'm for them it makes sense, but normally they have a lot of legacy, a lot of systems and things that everybody's asking for in different ways. Sometimes also they have their own needs like Fortnite this new thing needs something. So, Unreal Engine will focus on what Fortnite needs for a while and then wrap it into we have new things that we need for Fortnite, but you know what I mean. The same for Unity. Unity has becoming bloat because they want to do everything and specially for for mobile games and indie and Mhm. and it's from my point of

view is unacceptable bloated. I mean, what means that I have to download and downloader. Yeah.
[laughter]
I mean, it's what what is that? Uh that's why Godot feels good. It just have what it needs and it doesn't and and not more. So, do you think Godot in the very long run will have the same problem where cuz people still want probably new features with every release, right? So, is is it the doom of every game engine to eventually become more and more bloated? Um so, I don't know.
the the thing is that they are a foundation. So, you are not they are not going to be better paid because they have a better version or something. So, their their motivations are different. Um so, I remember there was one one version I upgraded from Godot and it was smaller. And this is goosebumps for a coder. It tells me that "Wait, there are 3 MB of the executable that are gone?"

Oh, yes because we thought that this is not very much used, so we decided to remove it. If you want to keep using, use that that old thing. And somebody is like, "This is fantastic. This is exactly what I need." I [laughter] mean, Unreal should be smaller every time if they need to be effective, but it keeps growing and growing and exploding because it's it's kind of, you know, find fair of of all the things that you want to do. Godot doesn't try to do everything, but always tries to to keep small. And this is the more developer um mindset more than the the executive mindset. I see so the financial incentives different financial incentives create a different outcome. Yeah, absolutely. Absolutely. And they are very strong. I mean, in the end uh Epic needs to needs to keep selling games and and and Unity it's their it's what they do. That's why they try to milk as much as money from from their

teams as possible. Yeah. But do you think Godot uh Godot's user base will grow? Are you bullish on Godot in general? Bullish? What do you mean bullish?
Uh do you do you think more developers will use Godot in 5 years than now? Well, the statistics says says yes. Uh it keeps growing every year. Um I I mean, don't get me wrong. I'm I'm I'm not here to say Godot is the best thing, but the there are things that still piss me off a lot of the engine, but um [clears throat] um normally when people ask me the difference between all those engines, there is a measure that I call it is fighting the engine. So, every every day when I work with Unreal, I know that 2 hours of my life are going to be fighting Unreal. It's like, "Okay, Unreal, why how do you want me to do this? Which kind of forum from 3 years ago I need to find of somebody that hacked

this in order to make this happen? What is the button that I need to press out of 3 million buttons in order for this to happen?" And and that will be 2 hours of my life uh spending to finding how Unreal, how do you want me to do this? In Unity, when I used Unity long ago, it was it used to be an hour because Unity 4 for example was very small, was very simple, it was barebones and I guess, "Okay, Unity, how do I do that?" Oh, this way. And actually if not, I could do it myself. So, you felt this kind of freedom. Then Unreal, if you don't do things the way Unreal wants, you are in a mess because it's extremely complex. Um with Godot with Unity it used to be like that. Well, with Godot it's 20 minutes. Sometimes it's it's five. Sometimes you don't find it. So, yes, it is a problem, but the measure of the problem it's important. Um and uh this this the the thing is that it does not compile, it opens in 5 seconds, everything is very quick.

I mean, this uh makes you feel that by the end of the day you are way more productive than normally how you feel with other environments. And when you are productive, you are excited about what you're because impact is the base of happiness. Yeah, and when you are happy, you become more creative about how you solve problems. And this is a a very look good loop into between Just about that. So, I suspect that yes, it will become more and more used. It's used in a lot of places without telling them because it's open source. And I know it's built on cars and things like this. They just grab the code and do whatever they want. But I mean, it's very well done and it's evolving the right way. Normally every time there is a new version, it's like, "Yes, yes, yes and yes." And that's very good. Thanks. Oh, all those things, well, I don't care, but those old things. Normally with Unreal was upgrading is like, "You are doing what? Why? Who needs that?" [laughter] I guess that

Fortnite? What about Oh, you are making this bigger. Oh my god. I'm going to have trouble. And it's a big big deal. So, yeah, that's why it's different. I I think it it has a bright future, yeah. Yeah, I I want to present you the appeal. I I yeah. The longer you use Unity, the the more you annoyed you get by by the bloat and by all of the fighting the engine and it definitely increases my urge to either go to something more lightweight or to write my own engine though. That's probably not the smartest decision for making commercial games. No, no, for commercial commercial no, but for coding master, yes. But no, no, don't do your engine to build a uh your own game. Um maybe in the future you want. I mean, there are people that that get to that nirvana of programming that they can build very specific technology for a very specific game.

Yeah. Um that is fine, but normally you go ahead and do that when you have the luxury of um not being looking at your bank account every month and making sure that you are doing well. Yeah. If you have this time, why not? I mean, whatever makes you happy, man. Yeah. Um but if you need to do something commercial or sensible and in time, uh
[sighs]
probably the best approach is to use a a solution there. And use the solution that you are more used to. One of the reason Unity keep keeping is because people have been using Unity before and they feel comfortable in that environment. Mhm. And they don't want to be looking into other environments because time is money. My assessment right now of Godot is that for 2D games and small 3D games, there is no reason to use Unity anymore. And they are not mobile. I mean, you're you're making a decently

big 3D game in Godot, so you don't seem to be afraid of that. Cool. Thanks for having me. I watched some of all of your other videos and I I think they are very instructural is instructional and I think it's a good effort. I mean, they I I hope that more people get into the mastery of coding. Um it's very fun. It's very cool to code and get your own solution. It gets goosebumps. It's like, "Yes, I solved that very quickly." And that's, you know, that's very elegant. That's very cool. Why not? Everybody wants to get excited about their own stuff they are doing. Um I mean, you're right on the fact that it could almost be a distraction from the things that actually make games successful, but we cannot deny that it's very fun to think about these things. And to to maybe even over engineer them a bit. It's kind it's kind of a fun. Yeah, [laughter] as long as you see the difference is like, you know, I'm going to give me myself a treat and over engineer this.

Fine, let's do that. But you are conscious of what you are doing. You are [laughter] not doing it and then pretend that this is what the game needed. Yeah. Don't do that. As long as you don't do that, that's totally fine. I mean, it's your time and your computer, do whatever makes you happy. I think you had very very fair and pragmatic answers to everything. I I really enjoyed your take. So, thank thanks a lot for for your valuable input. It was was quite enjoyable. Thanks. Thanks for having me.