The Pragmatic Engineer - Building a best-selling game with a tiny team – with Jonas Tyroller

Episode Date: January 29, 2025

Supported by Our Partners• Formation — Level up your career and compensation with Formation. • WorkOS — The modern identity platform for B2B SaaS• Vanta — Automate compliance and simplify security with Vanta.—In today’s episode of The Pragmatic Engineer, I’m joined by Jonas Tyroller, one of the developers behind Thronefall, a minimalist indie strategy game that blends tower defense and kingdom-building, now available on Steam.Jonas takes us through the journey of creating Thronefall from start to finish, offering insights into the world of indie game development. We explore:• Why indie developers often skip traditional testing and how they find bugs• The developer workflow using Unity, C# and Blender• The two types of prototypes game developers build • Why Jonas spent months building game prototypes in 1-2 days• How Jonas uses ChatGPT to build games• Jonas’s tips on making games that sell• And more!—Timestamps(00:00) Intro(02:07) Building in Unity(04:05) What the shader tool is used for (08:44) How a Unity build is structured(11:01) How game developers write and debug code (16:21) Jonas’s Unity workflow(18:13) Importing assets from Blender(21:06) The size of Thronefall and how it can be so small(24:04) Jonas’s thoughts on code review(26:42) Why practices like code review and source control might not be relevant for all contexts(30:40) How Jonas and Paul ensure the game is fun (32:25) How Jonas and Paul used beta testing feedback to improve their game(35:14) The mini-games in Thronefall and why they are so difficult(38:14) The struggle to find the right level of difficulty for the game(41:43) Porting to Nintendo Switch(45:11) The prototypes Jonas and Paul made to get to Thronefall(46:59) The challenge of finding something you want to build that will sell(47:20) Jonas’s ideation process and how they figure out what to build (49:35) How Thronefall evolved from a mini-game prototype(51:50) How long you spend on prototyping (52:30) A lesson in failing fast(53:50) The gameplay prototype vs. the art prototype(55:53) How Jonas and Paul distribute work (57:35) Next steps after having the play prototype and art prototype(59:36) How a launch on Steam works (1:01:18) Why pathfinding was the most challenging part of building Thronefall(1:08:40) Gen AI tools for building indie games (1:09:50) How Jonas uses ChatGPT for editing code and as a translator (1:13:25) The pros and cons of being an indie developer (1:15:32) Jonas’s advice for software engineers looking to get into indie game development(1:19:32) What to look for in a game design school(1:22:46) How luck figures into success and Jonas’s tips for building a game that sells(1:26:32) Rapid fire round—The Pragmatic Engineer deepdives relevant for this episode:• Game development basics https://newsletter.pragmaticengineer.com/p/game-development-basics • Building a simple game using Unity https://newsletter.pragmaticengineer.com/p/building-a-simple-game—See the transcript and other references from the episode at ⁠⁠https://newsletter.pragmaticengineer.com/podcast⁠⁠—Production and marketing by ⁠⁠⁠⁠⁠⁠⁠⁠https://penname.co/⁠⁠⁠⁠⁠⁠⁠⁠. For inquiries about sponsoring the podcast, email [e-mail]. Get full access to The Pragmatic Engineer at newsletter.pragmaticengineer.com/subscribe

The one challenge that you face a little bit is that you need to find a compromise between something that you want to make and something you think that will sell. First of all, finding something that will sell is already difficult, but then finding something that will sell that you also like to work on. That is fairly tricky. The way you approach it is usually you just make a lot of things that you can imagine working on that you're kind of interested in. And then you're trying to measure or guess how well it would do on the market. And then you move forward with the ideas that you think are most promising. How exactly it looks like, I come here in the morning, I sit down, I open Unity, I'm like, hmm, what do I want to make today? I just come up with a random idea that I find interest and I just make it.

The thing that I think that is important to realize is that you can make games very, very quickly. Like, if you just want to make a simple prototype without any fancy graphics or menus or whatever, you can get that up and running super, super quickly. What takes the most amount of time is just polishing it up and bringing it to production quality. But if you just want to try out a random little idea, you can mostly do that. in one or two days. Throneful is a minimal strategy game. I bought the game, enjoyed playing with it, and I was surprised to discover that it has sold a million copies

at the first year of its launch, and also that it's only been built by two developers. I figured would it not be nice to know how the game was built? For this episode, we have one of the two developers, Jonas Tyler, joining us, and we're going to cover the structure of Tronfall as a game, how scenes 3D models, C-sharp code, and other parts make up the game. Why Jonah starts his game development process by building a new mini game each day

that he then throws away and does this for a few months. Why implementing pathfinding with an A-star algorithm was an interesting challenge building the game? Tips on getting started as an indie game developer, especially if you know how to already code. And many more fascinating details about indie game development. Whether you are thinking of one day perhaps building your own indie game or you're just interested how these games are built, this episode is for you. If you enjoy the show, please subscribe to the podcast and any podcast. podcast platform and on YouTube.

So talking about the tech sac specifically, can you share like what you use, what, what language you use, what kind of dev machine? And can you maybe even share, share like how your development environment looks like? Yes. So if you want, I can open up Unity for this. All righty. We have Unity open right now. So Unity is the program we use to make our.

games. William Snail was made in GameMaker, so I'm familiar with a couple different engines. I've doubled with Godower bit as well. But Unity is our option of choice for this one. I don't know. What do you think was interesting? When you mind sharing us what programming languages use, what frameworks you're using either open source or I'm not sure if you bought some things?

And then can you just give us an overview of like, what does the project structure of this game look like. And what is that cool thing that we're seeing right in the middle? It looks like the menu a little bit, no? This is exactly. This is the level select screens on the game. Yeah, I love that screen. We can write around.

Yeah, Unity uses C-sharp. So all of this is written entirely in C-sharp. And of course, we don't have to worry about any of the rendering stuff too much. And all of that, that's all built into Unity. The shader we use here is something we bought from the Unity asset store. So Unity has its own marketplace where you can share resources relatively easily. And we definitely bought a couple of things there. As a small indie team, if you can find a way to cut corners and save time, you definitely do it.

All of the 3D models you see here, we made ourselves in Blender. But like the Stoon Shader is just something we downloaded from the Asset Store. And then the shader for those of us who are not game developers, like, what does that do? I know it's something to do with graphics and rendering, but can you explain for software engineer who's not a game developer? So the shader is essentially what renders materials onto the screen or shaders are the part of the part of your game that runs on the graphics card. Maybe it would be a different way to say it. Yeah. Because like for the game logic, where do units go and all that stuff,

that is typically done on the CPU because there's, you could do it probably on the GPU, but it's more difficult to optimize. So just for convenience that runs on the CPU. And then like the color of each individual pixel that is calculated on the GPU. And the way you calculate that is basically defined by the shaders. So you can say, okay, if the light is coming from this direction, then color this pixel bright if the light is coming from that direction, then color the pixel dark. So shaders are like highly optimized code for the graphics card that I usually use to render

graphics, but you can also use them to do different things if you want to. This episode is brought to by Formation, a personalized interview prep program for experience software engineers. Formation is built by X-Fang engineers who've conducted thousands of interviews collectively so they know what it takes. In 2024, they helped engineers increase a comp by $110,000 on average. They help you understand exactly how you stack up, and then get you ready to aise assistant design coding and behavioral interviews.

They assist in landing top-tier roles and level up your compensation through unlimited career coaching and technical mentorship. Rigourously drill problems that align with your personal skill gaps. Get unlimited mentorship to get unblocked. Do as many mocks as you need to ace the real thing. Stop wasting time trying to figure out what to prep, only to get to the interview and realize you had it wrong. Formation helps put your interview prep on autopilot,

ensuring you're always focusing on the right thing. Apply today at fm.dev.com. That is, fm.com.com. This episode is brought to you by WorkOS. If you're building a SaaS app, at some point your customers will start asking for enterprise features like Sammel authentication, skin provisioning, and fine-grained authorization.

That's where WorkOS comes in, making it fast and painless to add enterprise features to your app. Their APIs are easy to understand, and you can ship quickly and get back to building other features. WorkOS also provides a free user management solution called AuthKit for up to one million-monthly active users. It's a drop in a replacement for Alt Zero and comes standard with useful features like domain verification, rule-based access control, bot protection, and MFA. It's powered by Radix components, which means zero compromises in design. You get limited as customizations as well as modular templates designed for quick-endure.

Today, hundreds of fast-growing startups are powered by WorkOS, including ones you probably know, like Cursor, Versal, and Perplexity. Check it out at Workos.com to learn more. That is WorkOS.com. And is, am I right to suspect that this is somewhat a commodity in the sense of, like, it's not going to make a huge difference for a game? So, you know, you just bought one. I'm sure there's open source ones, but in the end, it doesn't sound like, especially for an

indie gamer, it's worth building your own and spending so much time and sweat into it, right? They are surprisingly easy to build, depending on what you want to build. Like, there are a couple of things that are pretty easy to build. There are a couple of things that are very difficult to build. In the case of like a fully fletched out tune shader with all of the features you want, because, you know, this one also has shadow casting. It has like outlines and all of that. If you want to code all of that in yourself, you're going to be busy for a while.

But if you want to make something very simple, like, I don't know, transparent particle or whatever, you can do that within half an hour, especially with the help of chat GPT or so. So there are some things you do yourself. Fastly to do yourself, there are some things where you try to use somebody else's fair because it would just not be feasible to do it yourself. But you're right. It's very much a commodity. Also, unity comes with a lot of built-in shape.

So if you look here, there's like a massive, massive list of shaders that already come with Unity. So, yeah, like in also like 90%, 80% of the cases, you'll just use the built-in Unity shaders and that would be completely fine as well. And what is the structure of this, this Unity project in terms of, you know, like, again, I'm not familiar at all with how games are. structured. If this was not a game, it will be like a series of modules and, you know, like in different things. How does it look like in your case? How do you think of it? There are different resources types. So everything is just data blocks, right? But the question is in which data blocks do you organize your game? In Unity, the main organizational structure, you put everything into his scenes.

So scenes are essentially, I would say, levels, I could say. So we have this is our level select area, but we also have scenes for other levels. This here is the second level, Durststein, which currently has odd colors. Hold on. Oh, I remember this level. Yeah, this is how it looks usually. also one of the bonus levels when they keep coming up. Yep.

Where was it exactly? And then within scenes, you have a number of objects or I'm sorry if I screw up the terminology a little bit there. Like I think maybe instances would be the correct way to write instances of specific objects. Everything is organized into these game objects. And then every game object can have scripts attached to it. So for example, if we check out our castle center here,

you can see that's a castle center game object. And then it has a couple of C-sharp scripts attached to it. And these C-sharp scripts, they're all mono behaviors. So they inherit from the mono-behavior class. And mono-behaviors are essentially just the type of object that you can attach to game objects. And then that's where you define how it behaves, like, state, those kind of things. Yeah, I opened one up for example purposes here.

We can see how one of those mono behaviors would look like. Don't judge our code too harshly. Maybe we'll talk about this a bit later on. Game developers tend to write very horrific spaghetti code at times. But yeah, this is roughly how it looks like. You know, just have... But let's talk about this. So you consider this spaghetti, first of all, why?

Like, you know, how would you critique your own code? Which actually, you know, the game works really well from the outside, right? We're looking in the inside right now. Yeah. So before we started recording, you mentioned something of, writing unit tests or whatever indie developers we don't do that at all

we we debug our code with a debug prints it's just very much a mess sometimes I would even say we're not even close to the worst offenders like I have opened game projects in the past

they were like insane spaghetti like you can't even imagine and and this surprising thing this often also happens with very popular and good games. I don't want to throw anybody under the bus here, but I know a couple of games that are very, very popular indie games where I know for a fact that they also have pretty horrific spaghetti code under the hood.

But yeah, apparently it's not really stopping the success of games. So if it works, it works. Like that's sort of the philosophy here. Well, that's the thing, right? Because the reason, like, Like, you cannot really get a way of not having unit tests at a insider, let's say, a hundred-person engineering team that is building a distributed system, let's say a large website or mobile app or something like that. It's because of maintainability. It's, well, what happened if you did that? I mean, you can do it. But then, you know, like people are going to like make code changes and there's going to be bugs and customers will be upset because suddenly what they used to use does not work.

So I'm kind of curious. If you wrote unit test, you know, it will take you a bunch of time. What would it give you? What would it give you anything? Because if it doesn't give you anything, it's the right thing that you're doing, honestly, right now. Like, you know, you shouldn't, like, apologize for it because, like,

in the end, I feel, you know, you're looking to meet your goals, which is build a game that is fun and it works and it's great, that kind of, those kind of things. Yeah, I think you're right. I think it's very much a scale thing. Like, I think stuff like unit tests and so on, they become very important at a certain scale. and I think most indie games they operate under that threshold

where you can kind of get away with a lot of these messy things. The thing is also, you know, as you keep skating these indie games bigger and bigger, a lot of these things start biting you in the back more and more, the further you go. But if you don't scale to a super large level, it's kind of okay. You find workarounds and so on, workarounds for your own screw-ups. So this leads me to a pretty good question, which is like the reason we even talk about tests in software engineering is it's not about the test, right?

It's about wanting to avoid regressions. When you're, you know, making changes to the game, how do you test it? Like, how do you, how did you make sure that when you released it, this actually worked as expected? And clearly, answer is not. You know, I'm just really curious of, you know, like, and what did you need to test, right? because I feel a lot of things, especially in your game, it's kind of hard to test, right? Like, does it, okay, there's like obvious things, which is the characters, you know, not colliding weirdly or I don't know, like, but there's also the thing of like, does it kind of work as

you think it would? It sounds like hard to, you know, like, test. Yeah, so I think one of the advantages that comes with modern game engines is that they also, like, do a lot of, a lot of the fixing on their end. So you can usually be relatively. certain that if it works on your machine, it will likely also work on other machines. So that is a luxury that we have nowadays. But then obviously there can also be issues and bugs in the stuff you write yourself.

And the way to catch that is, first of all, to test it rigorously, rigorously yourself. But you're not going to catch everything that way. So then you, before you release, you're usually tested with a group of beta testers. And they're going to catch even more, but also not everything. And then you fix the rest once it's released. Because then you essentially have thousands and thousands of real-life testers. Yeah. That's honestly, that's the only way to find all of the bugs or at the release, all of the ones that matter.

So going back to the coding environment and the development environment and unity, I've seen a lot, some of your videos where you actually should. share what your game development process looks like, which is really cool. We'll link it in the show notes below. So viewers can also, and listeners can also check it out. How does your kind of workflow look like? Because I've seen a lot of visual editing happening in Unity. Then sometimes you switch to make some code changes with, I guess, what you've shown with mono objects and so on. Like, how can you like, you know, like share what, I know, how will you jump in between these things? Are you more in the visual side of things and the UI or more of the code?

Or can you even say how this splits? Does it even make sense? It depends what you're, it depends what you're currently working on, right? If I'm building a new level, then I spend most of my time right here in the Unity editor view and I kind of move rocks around like so. I'm like, oh, here, here would be a new level. nice place for another rock. Or if I make a new level, then I take these giant shapes here and kind of bend them into

place. I'm like, okay, I want the level to maybe go this way, that way. But then obviously there are other times where, for example, you work on enemy designs. That is also something you can do in unity. Let me bring up one of the enemies for quick. And you have some of those big bosses. That's the end of some levels, not all of them. Exactly.

So there's, you can also, this is called a prefab. So prefab is essentially like a blueprint for an object you can put in your scenes. You always want all of the arches to be the same. So if I edit my archer here, then it will update on all of the scenes. which is pretty useful. Yeah, and then there are other times where you, if you work on the visuals, then you would probably do so in Blender. So Blender is very nicely integrated with Unity.

If I update anything in the blend. So this is a, is it the 3D editor if I put it in a simple way? Exactly. Blender is slowly becoming industry standard for everything. around 3D modeling and so on because blend blend is very good. It's a massive, massive program. There are tons and tons of things you can do with blender. But one of the things you can do with blender is also just making simple 3D models.

And that's what we use it for. So you can see in this blender file, we have most of our 3D models from our towers and so on so forth. So whenever I need a new model or when Paul needs a new model, then we just go in here and make it different levels of buildings. Here we can see parts of one of the bosses. Yeah, yeah. That's the part.

Is that that lake boss? Yeah, exactly. And you see it's not fully assembled because I only make every part of the boss here once, like all of the teeth in the engine. I just threw it over together. And then you put it together with code later or in the editor. You just kind of use these parts. Exactly.

I can see if I can find it maybe. Small spoilers. head for everybody who hasn't played the game, but I think it should be fine. I don't think it's that much spoilers. Just because you know how it looks, you're not going to know how it actually, that's a pretty nasty boss. I can see in the behavior. Sitting under the surface.

Oh, there it is. So throughout the whole game, it's rendered there. Just you don't see it. No, it's not rendered. Usually it's turned off. Yeah. And once it appears that it turns on. And yep, it's, uh, it's, uh, it's, uh, it's, uh, it's, uh, it's, uh,

assembled in the editor. So it's not like you manually have to enter the coordinates of like everybody part or whatever. So you assemble it in the 3D few here. But this boss in particular has procedural animations. So this one is actually animated entirely with C Sharp. There's also an animator, but this boss doesn't use it. This has what you call procedural animations.

Yeah. Nice. And then for the whole project, like, can you give a sense of the size of the project? Like often it's not a good measurement. But like when we talk about like a backend service, we would say like, okay, here's how many lines of code it is just to give a sense because, you know, a million. It's hard to maintain, you know, like a thousand line. That's kind of pretty trivial. Like, do you have a sense of like how big the game is in terms of number of assets, lines of code? How would you kind of quantify it when you talk with, you know, fellow indie games? game devs to give them a sense of like, okay, how complex this game is, really. I think there's honestly no good measure that comes to mind because there are, like, certainly like pure data size is not, not that great of a measure because there are certain types of assets that disproportionately screw up that number, like for example, textures and zones are very, very big. whereas 3D models and code is not big at all, but then also lines of code is also not a perfect measurement

because oftentimes it's not your own code, right? Oftentimes, it's third-party tools, and so on. That's very difficult. So if you want to know, I think the game itself, Throneful itself is very, very small game. I think it's maybe 100, 200 megabytes most. So that's a download size, right? That's the download size

And the reason for that is that we Don't have a lot of textures We basically have this flat shaded style We have maybe a water texture And a little bit of a grainy ground texture To add a little bit of noise there But that's pretty much it And as mentioned the 3D models

All of the 3D models are tiny Like all of the C-shark code is pretty tiny So that's why a thronefall isn't that big The biggest thing in thronefall is probably the music And the sound effects Did you also create that? created that or did you buy it or did you have someone help the music is something i made myself and the sound effects yeah yeah you have to wear a lot of hats as a game developer but that's

also what makes it fun the music is is really fun you did you like create music before or did you just do it just for this game i created music before i also made the music for uh will you as well. And I've been making music for a long time. It's like one of one of my hobbies, my little side hobbies. So I get to use that there. Okay. So when when when we let now, now I'm going to think of it a bit differently what I hear. It's it's a good you too. I like it. Yep. Yep. Yep. So just to give you an idea of how big the assets folder. So the assets folder is basically where you put all of your, all of the things you need. That's 2.23 gigabytes. But as mentioned, the final game is a lot smaller.

So I think unity just, you know, a lot of everything that's not needed for the final build is scrapped. A lot of the things are compressed and so on. And in the assets folder, everything is basically in uncompressed format. So that's why it's quite a bit bigger. I have a interesting question that I think as like non-games developers would be interested in. What do you use for source control and code review? Or do you do either? I mean, I'm sure you do some sort of source control, but I'm not sure about code review.

So, code review, I'll give you the standard answer. What is code review? What do you mean? What are you talking about? Standard game developer answer, right? Yeah, I'm sure most developers know what it is. At indie scale, it's one of the things. Honestly, I think it would be very,

beneficial to do code review. Also, I think it's getting easier because you can basically copy, paste your code into chat GPT. And then, you know, if you're at the very least at the dummy level of most game developers, myself included, then usually you'll get some very good recommendations from that. We'll probably make the project a lot easier to work with in the long run. I agree. But for some reason, you know,

it's not something most developers are excited about most developers are excited about I want this new enemy to finally work so we hack it in as quickly as possible we're not like oh let's review the code for this enemy to see if there's a more efficient way to do it that's just not the way we think at all but don't get me wrong I'm not judging you at all like seriously like you you've built with you and Paul have built this awesome game I love playing it and I'm more interested in how we're doing it and when you're saying you're not doing something that you know, larger teams would do or teams who are not building games would do. I don't really see that as a negative.

I see it as like, look, this works for you. And I think it's actually a great testament that there is no one practice that, I don't know, can help guarantee, you know, creating something great. Because like objectively, like, again, like I don't know, I'll just from my perspective, this game is great, right? And it's just cool to see how it was done. And I'm assuming if you would have, you know, taken some of these things, you might have slowed yourself down for no particular reason and, you know, maybe just got

demotivated midway and, like, get into fighting and quit and not finish the game. Yeah. I guess the reason why I'm pointing all of this out is, like, negative practices to just make, make it clear that we know it's not ideal, right? Because I know a lot of engineers will be watching or listening to this. And I know, especially, like, on the engineer side of the spectrum, I would say there are sometimes some judgmental looks about some of the things we do. Like, for example, the next thing you asked is source control.

And one of the next horrible things we do is we immediately just push everything to the main branch. Like we push everything to main. Sometimes I've seen people make a little shocked Pikachu face about that. And I'm even like, is that not normal? I thought everybody would do that. Apparently not. maybe you can tell me how that is usually done in bigger projects well don't forget that i think there's a huge difference between what you're doing which is building a game that like

you know you're you and paul are using it and at some point you push at a beta and what it means to push to main at a lot of like at a distributed system or at uber for example so like if at uber you push to main that code will automatically get deployed if it's a web service it'll get deployed to a service and it will be used by every single user of uber whoever uses that service If it's a tiny service, that's, I don't know, running in Portugal in one city because we have services like that, you know, that's not a big deal. But if it's running everywhere. So the reason it's frowned upon to just push to Main without a review is you can break everything. You're not shipping your code, right?

Like when you push to Maine, it's not updating on Steam every single time. So because I feel this is a big difference between game development and more SaaS backend development is, you ship very infrequently, which means a lot of these practices you probably don't need, by the way. Like, I think, you know, for any listeners, listening, I think it's worth challenging. You're thinking of thinking what the context is. And I'll give you one more example of, I heard a team at Apple do this thing called post-commit coach review. So they don't do code reviews, but then once someone commits, they're a larger team. They look at it and they give comments, but they can also do that because they ship once every six months.

So it's like, and also for any game developers listening, I think it's just worth thinking that, you know, these things that you hear practice is good or bad, it might not apply to your context. And this is one of the reason I was so excited to talk to you is just to see how you build this and what worked for you. And we're not saying this is going to work for everyone. But I have a feeling if someone wants to build a successful game, there and with a small team, it's worth paying attention to what you're doing. you clearly have found something that works for you. Yeah, I see the point. I see the point. I think the game not being in a functional state pretty much all the time is something

that can pretty annoying, even in relatively small teams. I think in like a team of two, it's still kind of fine. And although we pay attention to keep the game in a functional state with every commit, but this is something that I think I resonate with and that can get a problem very quickly, even in smaller teams, is that if everybody just pushes everything to main and even pushes like unfinished stuff and so on, then it becomes very annoying because whenever you try to play and test the game, it's basically not in a functional state because some system is always work and progress are broken.

That is very annoying. I will say that. That is very, very annoying. And that sort of stuff can happen sometimes when you work with, I don't know, less experience people or people that you're not as much in the groove with. Yeah. For Paul and I, I think this wasn't a big issue.

At the beginning stage, of course, sometimes the game wasn't in a functional state, but then, once it's functional, we pretty much always try to keep it functional, though then that whenever the other person wants to test it or run something, that it's always working and very runable.

Yeah. So one topic that I just wanted to touch, and while you still have your editor open is the kind of fun aspect. You know, one thing that struck me as something that I just didn't think about as a software engineer is the art, the fun. And clearly, like, when I played with this game, which, and I played with this before we met, in fact, I reached out to you after I played with the game. And I realized it's a tiny team and I thought maybe we could get some behind the scenes, which I'm very happy we're doing. Games need to be fun, right? Like, I like this game and I tell people that it's a great use of my time because it's fun.

Now, you showed me that you're kind of, you know, you're living your days, a lot of it inside unity, inside the C-sharp. But there's only two of you. How do you balance the, who is kind of the chief fun officer who makes sure that whatever you build it, it has that kind of fun, you know, jazz and feel to it? Like, how do you balance with all this coding and design work, which doesn't seem like all that fun? So there are, once again, there are different phases.

Like in the, during the prototyping phase, I would say. we were both equally responsible for that. As mentioned, Paul was, for example, the one who came up with the initial concept and prototype. But then once the concept is set into stone, the way we split it for this project is that I was the one responsible of gameplay, and Paul was like UI art and so on.

So I was the one who tried to make everything fun, and then Paul would basically quality check my decisions. I was like, yeah, this is indeed fun. Or, for example, in the beginning, I wanted to balance the economy a bit differently, make it a bit, balance it a bit slower. And Paul was like, yeah, this doesn't feel too great. I want more gold from my buildings and less gold from the enemy. So I rebalanced it a little bit according to his feedback.

But yeah. So essentially, I worry about that first and then Paul checks it to make sure that I don't do some nonsense in their regard. And how important was feedback from the players, the beta testers, the early access testers. I'm trying to get to the point of, you know, I feel there's two thoughts of creating great games. One is, or like creating great products in general. One is listen to your customers, you know, they know what they want and take a lot of their feedback, not all of it, but a lot of it. And the other one is like, no, don't do any of that.

You know, do Steve Jobs, decide what you're going to do. It's going to be great. push through and then eventually people will come around. Do you sit in any of these ones that, you know, how does they deal with the feedback? What was the feedback even? Yeah, so the way we do it is we gradually increase the number of play testers. So we started with like a closed circle of handpicked people that we trust. And we got our first round of feedback from that.

Then we expanded it to a little bit of a bigger circle with a couple more open testers. and then eventually once we were in early access, there was essentially a very big testing phase, right, with lots and basically everybody who bought the game is suddenly a tester. And the feedback was very, very important. For example, at the very beginning, when we started making the game,

there were no building upgrades, so no building choices at least. Right? So for everybody who doesn't know the game, I'll quickly show some, context here. If this starts up, come on. It's going to give it a little time.

So oftentimes when you build these buildings, you get to choose between different upgrades. And this was something that was just not the case in the first version of the game. And this was also something that we didn't plan for. Like this was not in our initial design. There was not something that we planned to do. But then because playtesters, the very early, the first round of playtesters reported back to us that is like a little bit too little choice

and it doesn't really feel like you're building your own base or you're building everything on these predefined build slots anyway. In Thronefall, you can't build buildings wherever you want. You have to build on these predefined slots. And that combined with the fact that you know, you can't even choose, you can't even customize the buildings. It felt a bit too rigid to people. And we reacted to that feedback by implementing these upgrade choices.

So now you have a lot more choice and a lot more options to customize your base. And then in the end, once your base is fully built out, even though the layout is predefined by us, it still feels like your own because you got to customize and choose a lot of different things here. Yeah, but then you do have some mini games. Interesting enough, after you complete the scenario, I played with all the, because I completed all the quests on easier. And then there's the mini games. And in some mini games, you actually have this where you cannot choose.

You can only build. You can choose, like, if you build, like, it's a binary, yeah, or nay. And then that's it. So did that come from, like, keeping some of the minigames, some of the earlier kind of versions? Honestly, the mini games is where I just go wild as a designer. And I'm like, you know, it's often, you have often have a lot of untapped potential in your game systems where it's like, I have all of these. cool systems here, there are like 10 different games we could have built with these systems. Like you have the unit movement and the combat system and all of that.

And often it's a little bit of a shame that you're not exploiting all of the possibilities you have. So the mini modes, like the little bonus modes for me, they're just a way to exploit a couple more of the possibilities we have with the systems that we've already built. So for example, there's also one mini mode where, uh, you, your character turns into a snowball. I was about to say that. That was my favorite.

I couldn't complete it. So I don't know how you do the difficulty settings, but I failed, like I did the first, like all of the waves, but the last one I just cannot do it. It's just this tiny, I'm sure if I could practice more,

which is, by the way, one more question to those, you know, of us who do not build games, but we're wondering how they do. How do you tweak the difficulty to feel right? Like, again, I'm not a huge gamer, but I do play every now.

And then it felt right to me. It was challenging. You know, I had to restart some levels, but I could finish it. And then some of the mini games, they're giving me grief. I just cannot finish them, which I guess is kind of fine because I'm not that good of a gamer. Yeah, the mini games, they are very hard. They're like... You're making it feel better.

Thank you. They are very, very hard. Like, in the beginning, we put the mini games right next to the levels where more people played them and we... yeah, people did not like them because of their difficulty. So we got demolished. So now we hit them away a little further. So not as many people play them anymore and they're like clearly identifiable as end game content. But you can obviously imagine people jumping into those mini modes before even finishing the game.

Like, that's a bad idea. Bad idea. Yeah, so arguably they're a bit too difficult. Yeah. But that's because the mini modes. for me are an outlet to make some of the crazy things that I find fun and that's one of the problems you also always have as a developer is that you're usually quite a lot better than the average player who will play your game.

So whenever I balance levels or whenever you balance levels, you have to make it so they essentially feel stupid easy. So most of the levels in Thronefall, they're so easy. Like the best players in Thronefold, they can finish most levels with only the king, without building a single building. Really? Yeah. That should tell you. Now you're making you feel bad.

It doesn't work with every level, but in a lot of levels, certainly, I think the first three or so, certainly like the ice boss and so on, you can beat with just the king. No buildings. It's... Well, you can do that as a little bit of a developer and pro gamers, but yeah. Yeah, I'm not sure I can do that. But going back to that question, as a developer, do you just get this feel of what a good difficulty is for a game that will actually be sold and people will enjoy it?

People like me, people like, you know, the casual gamers who are people who are buying it? Or do you get it from the feedback? Because it feels like this is a really big difference, right? Like you're so much better. You like, but yet you need to produce something that. will, I don't know, I guess be fun and enjoyable for the general public. Yeah, one thing that a lot of people forget about balancing is that first of all, you need to make a game that is balanceable and easiest and somewhat reasonable to balance.

The problem with strategy games like Thronefall is that they are very, very, very snowbally. And snowbally means that if you're ahead, you get further ahead. If you're behind, you get further behind. So that's why games like Thronefall and strategy games in general, they have a tendency to feel very frustrating very quickly, because if you fall behind in your economy, then it becomes exponentially more difficult. You're never going to be able to catch up again.

Whereas on the other side of the spectrum, if you get ahead, and you get exponentially more and more money every round, then suddenly it's going to feel way too easy. And this was one of the main problems I had when Balazel. thronfall is just this runaway dynamic of it all. Either it feels way too easy or it feels way too difficult. And I didn't really find a perfect way to deal with it in thronefall. One way I actually try to counteract this is by making enemies drop gold.

That was also something that wasn't always the case from the very beginning. But I very quickly realized that we need that because the economy you build yourself, like with all of these houses, it's just, there are too many runaway effects with that. Yeah. So the enemies dropping gold basically smoothest that carve out a little bit and makes it so that I can predict a bit more how much gold you're going to have at which point in time. So you're saying that the, you made it that the enemies might drop more gold when you're sensing, like you're actually doing some smart calculations or no? There's no shenanigans going on like that, but they're like, it's just math. If the enemies in Wave 10 drop 50 gold, then I just know you're going to have at least 50 gold.

And that makes it easier to balance than trying to predict how many houses you're going to have and so on. Oh, I understand. Yeah. So after you build this game, you've now ported it to a Nintendo Switch. What did that porting look like from a technical perspective? Did you do the porting? Did someone else do the porting? We outsourced the parting to Warp Digital.

So, and that's like all of my, all of the three games I made so far are available on Switch. Islanders was ported by Code Sync, Gulliusnail was parted by no gravity games and this one was now parted by Warp Digital. So this is the typical way I go about it. I just give it to somebody else and I'm like, please part this. and the typical standard deal you do for these kind of things is you get a revenue share in and other than that you basically don't have to do anything like they take care of all the publishing they take care of the parting it's like completely hands off and very free which is why if you have a successful game on steam already it's pretty much a no brainer to

just give your game to one of these companies because they're like okay we'll take care of everything and you'll just get a revenue share of what we're making. I'm assuming they're used to, you know, taking especially if it's Unity C-sharp, you're running on this code base, they'll take it, they'll know how to change it, they'll know all the performance issues,

et cetera, the testing set. That sounds a pretty sweet deal as a, well, it's kind of a positive thing. If you do make it to a successful, you know, and I guess,

am I wrong to assume that this makes it a bit more tempting as an indie developer to start on Steam because if you do well on Steam, again, it's kind of easy, easy enough to find someone who you can strike a deal with this way. Yeah, obviously, Steam is the go-to-place for indie developers anyway. There's pretty much, if you want to make indie games,

there's almost no way you're getting around Steam. Like in most cases, even if you have other platforms, Steam will still be 90% of the revenue. So anything you sell on Switch, and especially on other consoles, it's more like a little bonus on top of what you're making on Steam. Steam is, I think, by far the biggest market

for indie games. Trust isn't just earned, it's demanded. Whether you're a starter founder-founder navigating your first audit or seizing security professional skill in your governance risk and compliance program, proving your commitment to security has never been more critical or more complex. That's where Vanta comes in.

Vanta can help you start or scale your security program, by connecting with auditors and experts to conduct your audit and set up your security program quickly. Plus, with automation and AI throughout the platform, Vanta gives your time back, so you can focus on building your company. Businesses use Vanta to establish trust by automating compliance needs across over 35 frameworks, like SOC2 and ISO-27-001. With Vanta, they centralized security workflows, complete questionnaires up to five times faster, and proactively manage vendor risk. Join over 9,000 global companies to manage risk and prove security in real time. For a limited time, my listeners get $1,000 off Banta at vanta.com slash pragmatic. That is V-A-N-T-A.com slash pragmatic for $1,000 off.

You've been building games for a while. A lot of us listening have not built games, but we probably played games. I played in Thronefall. I actually love the game. It's just a great way to expend in, you know, like 10 minutes, 20, and then it turns into a few hours. How did you get started with this, starting from the idea and then like, you know, what were the actual first steps and talking about both yourself, but you also had a co-founder or a co-developer.

Yeah, Thronefall we made in a team of two. And what I just talked about is a perfect gateway to how we started making Thronefall. Because what we do in the very beginning is very much opening up our search space very wide. We try out a lot of different ideas. So this is what typically you call the prototyping phase where you make a lot of different essentially mini games or prototypes where you try out different ideas. And that way you're basically making a bunch of measurements

in the search space and just looking which direction you find most promising and then you keep searching in that direction. So that is pretty much exactly what we did for Thronefall. We made a bunch of different prototypes in use. just one or two days working on little mini-games. So we had one prototype about spreading flowers. We had a climbing prototype. We had a card game and all sorts of different things.

And then after exploring some of these ideas a little deeper, some of them we scrapped instantly. We slowly honed in on what we wanted to make. And it just turned out to be thrown for it. I don't know how exactly we were. we arrived there just in this specific case. And when you say like, you know, that you're exploring them.

So you kind of like, is it just you kind of, of building this like mini prototype game and then just playing around with it, seeing how it feels, showing it to your, your friend who's also working on and just bouncing ideas. Is that kind of how it is? Or can you help us imagine?

Like how does it, you know, how does this face look like? So the one challenge that you face a little bit is that you need to find a compromise between something that you want to make and that's something you and something you think that will sell. And that's one of the main challenges. First of all, finding something that will sell is already difficult enough by itself,

but then finding something that will sell that you also like to work on. That is fairly tricky. So the way you approach it is usually you just make a lot of things that you can imagine working on that you're kind of interested in. And then you're trying to make. measure or guess how well it would do on the market. And then you move forward with the ideas that you think are most promising. How exactly it looks like, like I come here in the morning, I sit down, I open unity,

I'm like, hmm, what do I want to make today? I just come up with a random idea that I find interesting and I just make it. Like the thing that I think that is important to realize is that you can make games very, very quickly. Like if you just want to make a simple prototype without any fancy graphics or menus or whatever, you can get that up and running super, super quickly. What takes the most amount of time is just polishing it up and bringing it to production quality. But if you just want to try out a random little idea, you can mostly do that in one or two days. So that's what you just do repeatedly for, let's say, two months or so.

both I and Paul pumped out a bunch of prototypes. We show them to each other. We play each other's prototype. We talk about them, of course, because through talking about them, we try to figure out, hey, which of these could actually do well on the market. And also in a team you have, that makes it even more important because you have another circle. Like what do I like working on? What does Paul like working on?

So we have to find the overlap between all of those things. So that's why obviously talking about these prototypes is pretty crucial. And usually what you do is you do specifically gameplay prototypes. So you start with gameplay and then only once you're sure what the gameplay is going to be, then you move on to visual prototypes where you basically repeat the entire process that you did for gameplay with for the visuals. So you try out a bunch of different visual styles and see what you like working on, what's efficient to make, what you think will do,

well in the market. That's really... So specifically with Thronefall, you said, okay, you had the problem types and then you figure it out you're going to make Thronefall. But what did that look like? Like, you kind of knew the concept that it would be this tower defense game with, you know, I mean, I'm putting it like that based on how I played with it. Or was it a lot more vague at that point still? So you go through different phases. When we started, we were very open. We're like, we have no idea what we want to make. We'll just throw anything out there.

Like, as mentioned, there were some completely wild things, like a game where you were golfing flowers like a golf ball, essentially so some wild ideas. And then at some point we narrowed down our search a bit further, and we were like, okay, we want to make a minimalist game about building a kingdom. We're like, okay, the search is getting out of hand. there are like too many options, decision paralysis, let's kind of focus down a bit more.

And then we made a bunch of prototypes that specifically had to do with managing tiny kingdoms. Like I made a turn-based game. And I made like a plants where a zombie-like game or like there are hearts coming from the side and you shoot them all down. And Paul at some point just had this little mini game where you had a castle in the center

and you had a little figure that you could control around it. And there were like enemies going towards your castle and all you were trying to do is basically defend your castle by smashing down the enemies. And it had a very nice rhythm to it because there was like the day phase

where you could build new towers and mills that would give you more coins and there was the night phase where you would defend your castle against these enemies approaching. It was a very simple top-down 2D prototype and yeah when you when you see it you see it I don't know it was like we both immediately agreed that this was gonna be the game we were gonna make because

it was just ways ahead of all of the other prototypes we've we've made so far so but based on the kind of feeling and you know your understanding of like okay what could work actually yep how long did it take to get here like you know you say like If you did like every few days you did a prototype. So like we're talking a few months into the prototyping phase ish. So I would say, you know, it depends on how big of a game you want to make. But your prototyping phase should just scale proportionally. So for example, if you want to make a game in two years, then maybe spend two months on prototyping.

If you want to make a game in a month, then obviously only maybe spent two days or something. So yeah, you have to kind of. scale that proportionally. And for us, it took a little bit longer because we went into one dead end with a card game. We thought our kingdom management game is going to be a card game. Then after about a month of development and me over engineering like a cool system, we realized that's not it. And we just scrapped it.

And then when this happens, like you know, you put in a bunch of work. already months of work. You just like throw away the code or archive it and boom, that's it. Yes. So honestly, yeah, I was grateful that we noticed at all because in the worst case, you develop the entire game, you spend two years and then you notice that it doesn't work. So whenever I notice relatively early that something doesn't work, it's not like, ah, what a shame.

It's more like, who we dodged a bullet there, you know. Yeah. It's more that feeling. So it's more a feeling of relief than anything else. And then once you, okay, figure and figure it out, this is a concept. This is a game that we're going to go like, you know, we're happy with the prototype and let's continue on. How do things look like from there?

Because I assume that that's when things change, right? Did you start to do some sort of planning? Is it just more kind of key building? You know, like I'm kind of like poking to like at some point, did you feel that you need to bring in more structure. You're still just two people. You know, you've already built like two games, so you kind of know what you're doing here. Yeah. Exactly. So as mentioned, after the gameplay prototype, we had another phase for the visual prototype because the visuals are also very important. And you repeat the entire process. You basically have the gameplay already done. And what

you do is you... Sorry, can you just help understand for the gameplay prototype? Like, what can we imagine? Is it like squares and like circles moving around or like super low fidelity for just official. Exactly. The gameplay prototype is essentially what we call programmer art, which is just a bunch of squares and boxes with colors. And for the art prototype, what we do, this is our process, is we scrap all of the gameplay once again. So it's not like we deleted, but we start on an empty project without any gameplay whatsoever. And we just build a scene without any logic. We just open a game engine and try to create a nice, that it doesn't have any motion, doesn't have any logic, we just try to make it look nice.

And if you decouple the gameplay from the visuals, you can move a lot faster in your visual prototype. Because if you try to bring it all together immediately, then you're not prototyping anymore. You're just building the game, right? So you open an empty project and you start messing around how things should look like. You click put little 3D models in there. you experiment with different camera scales, with different zoom levels. And then we had a massive mirror board with tons and tons and tons of screenshots, like hundreds of screenshots of different experiments we made.

And then you look at all of them next to each other and once again, try to assess which of them look the best or the most attractive. And yeah, once we found something we were happy there, then we move into production. And you're right, that's exactly the point where you have. have to start getting a bit more organized. In a team of two, it's sort of fine. It's not like there's insane management overhead.

You only have to manage communication between two people, which is fairly manageable, I would say. So we just have to agree who works and what. So I usually do gameplay programming and content creation. and balancing. So I write most of the gameplay logic. And then Paul is very good at basically user experience design. So he writes a lot of the UI systems, which is a surprising amount of work.

Like the UI system and all of that it's like probably 40 to 50% of the work goes into that. So by the UI, what is the difference between the UI and the gameplay? So the UI is basically all of the overlays that you can click with your mouse, like the settings menu and all of all of the different things that can pop up. And then for the UI, you have to make sure you can control it with a keyboard. You have to make sure you can control it with a mouse. You have to make sure you can control it with a game pad. It has to also look nice and so on and so forth.

So it's a fairly, fairly massive task. So, but we shared gameplay programming, I would say, 55. and then Paul did most of the UI stuff. Nice. And then what was the point where you actually had a, you know, a more traditional schedule in place of like, okay, we now know what we're built doing. We need to build, you know, the core engine, the levels, the different structures.

I'm just throwing out stuff. I don't know if this is how you actually structured it. But I'd just be interested like how it looked like when you're like, okay, we know roughly how this is going to go. And obviously at what point? And could you even announce dates? Because I just look back on the history and I saw when people are very excited at when they saw the first demos.

And of course, what they asked is like, when is it ready? When will it be out? Mm-hmm. So basically when you have the two prototypes, if you have the gameplay prototype and the visual prototype, then you know very precisely what you're going to make already. And then there are a couple of more questions that you have to answer. So when we build the first level, then we still have to answer questions of like, like how do the actual enemies,

like not the prototyping enemies, how do the actual enemies look like, how do the actual units look like, how do they actually interact with each other, which upgrades are there? So the search process definitely continues and you have to keep trying out different ideas. But basically, I would say,

the amount of communication between Paul and I that was required gradually goes down over time, right? In the beginning, you have to communicate a lot and you have to organize a lot And then as you know more and more about what you're building, you have to communicate less and less and then essentially by the end of the project. We talk maybe once a week and both of us just know what we need to work on. And so Paul and you are you both in the same city, same country? We are both in Germany and we studied game design together at universities.

So Paul is also one of the people I made Islanders with at university. just teamed up, teamed up again for Thronefall here. Nice. And then, so you've now gone through the development phase and you've been developing this thing for like, you know, closer to, I guess, two, three years. I'm curious, what, what does a launch look like for, for an indie game? You launched it on Steam, right? Was it only Steam or did it launch elsewhere on launch day? On launch day, it was only on Steam. Now it's also a on Nintendo Switch. Yeah.

How does a launch look like? It's surprisingly anticlimactic. So there's a button in the Steam backend where you just like launch the game and you click it. And then they have a couple of things that pop up where they're like, are you really sure you want to launch the game? Are you really, really sure? And then you click, yeah, yeah, yeah, yeah, sure launch the thing.

And then it's just, they'll just launch and you sit there and you're kind of like, okay. you have to pick your launch date somewhat carefully, but also because everybody tries to pick their launch date carefully. It also kind of doesn't matter. It's a little bit like, you know, trying to outsmart the market when you're buying stocks or something. Like everybody tries to be smarter than you.

So in the end, it doesn't really matter when you launch because the good spots are already very crowded. it and then like the spots that are not so good are less crowded so it kind of all makes up for for itself so it doesn't really matter too much when you launch i think in theory it does but like the market dynamics make it so that it doesn't matter too much yeah well i i guess you know beyond like some of common wisdom of like software people will not pay too much attention but yeah i i guess it's it's nice to hear the things that people think matter don't matter that much one more topic on the development itself.

What were some challenges that you would say were more challenging with this game? I'm just throwing in as some ideas. May that be performance, binary size, structure, whatnot. What might this one more challenging than the other ones that you built? So the main challenge for this one, for me personally, was everything related to pathfinding. Oh, interesting. So I'm not sure if you're aware of like algorithms like A star and so on. Very much.

So you'd be surprised on some interviews. If you interview to Google, Facebook, et cetera, you are well suited to study these things because they might ask it. So even though we don't really use it and this is a common thing with engineering, that's actually not true. And some of the things there's pathfinding and like nodes, computers, where to go. Like a typical interview question will be like, how does Google search, you know, like search between all these things? So in theory we do it, but you actually are using it. Yep. So the way this works in Thronefall is you see there's basically this blue overlay grid here on the ground.

And every triangle here is essentially a node and they're all connected. And whenever unit has to go somewhere, it just basically performs. A-star path-finding on these nodes. And this is a ready-made system. This A-star system is something we pulled from the asset store. We did not make this ourselves. But of course, you still have to customize it to a certain degree to your own needs. Hold on just so I understand.

The units definitely don't move on those paths, do they? That doesn't look like the path that the units take to me. Or they do? Maybe I'm just misunderstanding it. They do move on, like, if you want to perform A-star path finding, then first of all, you have to, you need a node graph, right? A graph, yes, yes, yes. Yeah. So this is the graph.

Yeah. So that's the graph. That's not the path the units takes. That's the graph. That's a graph that they perform to search. Exactly. And this graph is also dynamically updated. For example, when I build a castle center here.

It's a note you know it is in it. Then you see there's a hole in the graph now. And it's now connected that way. Exactly. And this is all automatically updated and done by the plug-in we purchased from the asset store. So you can see here we can define these shapes, which kind of shapes should be cut into the graph and so on and so forth. But then actually making the units behave properly and take the correct. path, it's such a nightmare because you also have walls that certain units can go through

and other units cannot. And then the default path finding doesn't support all of those features. So then you have to find workarounds. Then those workarounds cause new problems. Did you need it to worry about unit collision or I don't think so, right? In this game, they can go through each other. No, they do collide. Okay.

So you need to worry about that as well. Yes, it's partially taken care of by, once again, by the plugin we purchased. So it has what we call what's called local avoidance, right? For example, if I write through them, you can see the... Ah, that's local avoidance. And that's what plugin does that. That is all luckily handled by the plugin. And just a quick question from a, you know, like a tech perspective.

Like is that property? Would that be code that is executed on each of the units, like a mono behavior, for example? Or is it like some more global thing? So in this case, it's executed locally. And that's because our game is not very well optimized. It's kind of similar for most strategy games. Like most strategy games, if you've played any day, oftentimes they have like a unit limit of 200 or so. And the reason for that is usually not for gameplay reasons, but for a part of.

performance reasons because if more than 200 units, then at some point you're going to burn out your CPU. So yeah, this is all handled on the objects individually and it's not very well optimized, to be quite frank. I mean, it works. And we have pretty powerful CPU. Yeah, exactly. And then, of course, you also have the things that they're not exactly moving on the nodes, right?

So you basically also have to do some post-processing on those. paths so that they if they can go straight through a node then they should take the straight part and if they're cutting around corners they need to go in the corners here and you know at the beginning there were all kinds of problems like they're getting stuck on corners and so on okay and yeah but but also the the walls cause a lot of problems because you can see my units they can go through the walls but the enemy units, they cannot go through the walls. So now what should they do here? Should they try to go through this store? Should they try to go around? And it was like a bit of a nightmare and there's

some issues with that. But yeah. Well, now the enemy units are mostly just attacked the walls often. Yeah, indeed. They do. They exactly pretend like they can walk through it and they don't know that they can't. Like confused. Why can I not go through that well? See, but these, I feel these are the things that as a developer, you're probably, you know, a little bit pulling your hair about it or unhappy. But until we talked about this, I never noticed it as someone who played the game. So there's this joint of like, oh, it's, you know, you think it's a problem, but the customer or the user doesn't really. Yeah. But, you know, that's why you need different node graphs here.

For example, there's also one node graph specifically for. enemy units and you can see the enemy unit node graph has sort of a hole in the node graph here where the gate is and then the player units they don't have a hole here they have like a thing that they can go through and then there's also a separate node graph for the flying units. Oh yeah, oh yeah.

Yeah, so to answer your question, what was the biggest hassle I think for me personally, the pathfinding was the biggest hassle from a 10th. technical perspective. And then, like, from a design perspective, I would say probably the difficulty balancing was also a very big challenge due to the snowbally nature. I've already talked about that. And also one of the ways we counteracted a little bit is with the mutator system.

So all of the base levels are usually a little more on the easier side. And then if you want to make it more difficult, you can just play it with a couple of extra mutators. And I feel like, yeah. In the end, it worked out all okay. But there were challenges for sure, yeah. No, yeah. Gen AI. This is just, it's everywhere now. There's like tools, etc. And I'm just curious, like, do you use any tools that are LLMs, either for help or development? You did mention chat GPT. And also do you see any indie developers using any tools or stuff that makes your work easier? And is it making your work easier or faster at all? Yeah, that's my, it does make my work significantly easier.

And I think most people, most indie developers who say chat GPT is not helpful for them, in my opinion, they have not mastered that tool yet because it has a bit of a learning curve. You need to learn what it can do, what it cannot do. But once you know what it can and what it cannot do, it is incredibly powerful. Like, especially for beginner level questions on any subject, it's also incredibly reliable. So when we talk about Gen. AI and Gen.A. Tools are you use the chat GPT mostly for you? Yeah. I bounce back and forth a bit between chat GPT and Claude, but currently I'm back at chat GPT. I think the 01, the O series is pretty good at coding.

And then what kind of stuff did you do with it or do you do with it? So one very common thing I like to do is I like to write skeleton code. So I essentially write an entire script, just a skeleton code. So there are the functions in there. But in the functions, there's just a to-do write this function or something like this, right? And if you have a skeleton code like this, like chat chip is incredibly good at filling that in for you. So that's just like a little speed hack that I'd like to do, right? I come up with the architecture.

I define exactly what I want to happen, but I don't implement it myself. I'm just like, to do, implement this function. And from like the inputs and the context, chat GPD can figure out what I want the function to do. And this doesn't work for everything, but for like boilerplate stuff that you just can't be bothered with. It works incredibly well.

And then also sometimes there are subjects that you just don't know that much about, for example, shader coding is like an entirely different discipline and shader code looks very complicated. It's very difficult to read if you're not familiar with it. So I feel like chatchipt can also act a bit like a translator there where like you copy in a bit of shader code and ask, hey, what does this do? Where should I implement this and that? And it's just pointing you in the right direction because, you know, it's not perfect at everything, but it knows enough about everything that can help you with.

those weird disciplines that you don't maybe know enough about to deal with yourself. And, you know, instead of having to learn shader code and spending months on that, I can just basically ask chatubedia makes it so much easier. Oh, yeah. And everybody who's like, yeah, but it hallucinated one time and I had to rewrite it. Yeah, sorry, but that's your fault. You didn't use it very well. Yeah.

That's, I guess my take, yeah. And do you use GitHub copilot at all or no? You just use chatjib because what you mentioned of like, you know, doing the tutus, et cetera, copilot might be able to do that. Did you try it or not? It didn't stick. I haven't actually haven't tried it. I probably should try it sometime.

But I haven't tried it so far. And I'm also a little afraid of what it might do to my workflow. Because I kind of wanted to be intentional when I use it. I don't want it to be constantly running in the. background and doing things at the release not yet so i'm fairly happy with uh with my workflow there at the moment i mean honestly if you have a workflow that works yeah like you know like that's one complaint that i have heard and people have turned it off you know like it's not just copilot but there's a lot of things where they prompt you it it does just show you after a while it can

be annoying and it can get in the way of deep work yeah and i want i want to use it intentionally and and when I want to use it. And I also don't want to get in the habit of using it when I shouldn't. So as mentioned, I think there are very specific cases when you should use it. And there are also specific cases where you should deliberately not use it. And I want to be able to make that call. And I'm sure you can do that with co-pilot. You can probably turn it off and stuff.

But yeah, this just works for me at the moment. Talking about indie game development as a broader picture, what are some things that you kind of wish you knew before getting into indie development? Because so far we've talked about what I feel is more of the engineering part and a little bit of the art, which is the code, the design, those things. But I'm going to suspect that there's a lot of other things going outside. I know YouTube, for example, do YouTube videos. You mentioned you do music.

What were all these other things that, oh, it turns out they're kind of part of building a game with a small team? So the one thing I hate most is bureaucracy. What kind of bureaucracy? Taxes, filling out forms for Steam, accounting. That's the one thing. Nobody tells you about dealing with legal documents, you know, creating all of these deals, writing back and forth with lawyers. It's like, oh, I just can't be bothered.

Luckily, it's not a super big portion of the work I do about it. It's just the most annoying part by far that nobody really talks about. Nope. Yeah, but other than that, I think what's pleasant about being a game developer for me personally is that you get to wear a lot of different heads. So you get to make graphics, you get to make music, you get to write code, you're 3D model, you texture, you do sound design, you come up with cool systems. and write cool tech

and a little bit of everything and that I think that's exactly what makes it what makes it awesome and fun and the one thing as mentioned there is also oftentimes underestimated is the UI coding all of the overlay menus and so on that very annoying

and super happy I have Paul who's actually good at that and does it with a bit of joy as well that's a huge relief speaking with some other indie developers that you know if several listeners are software engineers who know how to code very well but they might be thinking of getting into indie development

what advice would you have for these people in starting to build their own games and publishing them first of all resist the urge to build your own engine unless that's specifically what you want to do and get joy out of like if you like I just want to I enjoy building my own stuff, sure go ahead

but if all you want to do is make a successful indie game don't write your own engine. That's step number one. Just use either Unity, Godot, Game Maker, Unreal. There are lots of good options to choose from. Pick one of those because, as mentioned, it does make a lot of it a lot faster. And one of the main things you need as an indie game developer

is speed because it really is. If you're making games alone or in a tiny team of two or three, three people, you need insane speed to even be able to finish your game. And even if you are fast, you still need to purposefully pick a very small game that's going to be manageable for you to make. The main thing that people or that new developers, I think, should know is that games don't automatically sell better if they're bigger. That's not the case.

So you need a good payoff to effort ratio. That's what you're really after, right? So you want as much bang for your buck. And if you spend twice as long, then your game needs to make twice as much money to make up for it. And that is often not that easy to achieve because the bigger your project gets, the more technical depth you build up, and the slower everything gets. So the bigger your project is the higher. harder is to make that return on investment. So actually smaller games are much, much easier to make successful.

Because if we like make a game in half a year, then it has much lower requirements to be successful. And also, people actually do like small games. Believe it or not, people really do like small focused experiences. I've seen it a lot for the games I build, for some of the games, some of my friends build. There is a market for small and focused experiences. So that's 100%.

Well, I'm going to go on a stretch on a little bit, but I'm like an example. And I think a lot of software engineers who have like day jobs, you know, working, you know, eight to 10 hours a day at a company going home, potentially having other things to do. You just don't have as much time.

And like a lot of us, like, you know, we are able to afford, you know, the indie game of, you know, 10, 20,

30, 40, 40 euros. And sometimes I personally feel it's a better use of my time to, pay for a game that is shorter, but very enjoyable. Because I do not have time to go through the, you know, $70 game. I just won't be able to finish it. And when I see that it's like 80 hours or 160 hours to finish, I'm like, no,

it's a no go for me. So there's that part, which is like, this is one of the reasons I love indie games. You can finish it and feel that it's, it's kind of complete. Okay, there's a little bit of many things, but I'm kind of happy with that personally. That's exactly it. And you're not alone with that. like a lot of people have day jobs. It's a very normal thing,

and people don't have endless time to play video games anymore. So that's why in the indie game market in particular, small games are completely fine, and quality is way more important than quantity. Yeah, so first of all, if you want to go from engineering to game design, then don't write your own engine. And also you, not only that,

you also, I think you have to resist that urge to build technical systems right away. Like even in engine, a lot of, I think a lot of people who come from an engineering direction, they kind of have the urge to build their MMO system before they even test it if it's fun or not. So take your time, take it slow, approach it from more of a design perspective where you do care about the user experience first. And only once you've figured that out, then you can start worrying about, how you want to engineer the system behind it.

But figure out the experience first and then go into the engineering part of it. I think that's very important. Thank you. In terms of learning how to, how games are built, again, coming from a background where you do no coding, so that's, you know, that's not a problem. But the frameworks are different, the tools are different. What kind of resources did you use to learn? And also you did something that a lot of listeners will have not done.

You've actually done a degree in game design. I'm curious on how much that actually helped you become a better game developer. And would you recommend, you know, like a more focused course like this, which is not just, you know, watch a YouTube tutorial kind of thing, but actually spending a bit more focused effort and how that worked for you? So I think it's completely possible to be 100% self-taught when it comes to game development. there are enough resources out there to kind of learn it yourself. I think the main thing university did for me is that it connected me to a lot of great people.

I really have to give a big shout out to my game school for that. I studied game design at HDW Berlin, the Bachelor game design degree. And it was very, very valuable. I just want to make the very clear. It was super valuable for me. They did have great coaching, they did have great courses and so on, but all of that stuff, you can teach yourself. Like, it's not, maybe it's a little more efficient if you do this in a specific area or something, but you can 100% teach that to yourself. But one thing that was just immensely, immensely, immensely valuable was just the people I met there because they basically curated a list of really awesome people.

and that was incredibly valuable as it turned out because I went on to start a company with some of them. And I guess part of the reason is that they have an application process where obviously they only select a portion of the people who apply. If you go to a different game school where the only requirement is that you pay them a lot of money, then you won't have such a nicely curated list probably. So if you want to go to a game school, honestly, that's one of the main things I would look for is how they curate the list of people there. Because honestly, the more difficult it is to get in, the more awesome, the people you will likely meet there.

I like that. Yeah. Other than that, don't be worried. You can be self-taught. It's not a problem. How do you see success as an indie developer for those who want to get serious? about it. You are reasonably successful if I'm kind of underrating it, but you've had two big hits already, and even the third game is, I think, what a lot of developers would dream of. What do you

think helped your success? And when other indie developers ask you for advice, what did you tell them? Well, the honest answers, you have to get lucky to a certain degree, but the luck isn't in what happens after you press the launch button, the luck is in where you are born and which people you meet along the way. I feel like especially extremely lucky with like the people I met. Like Paul is just such a fantastic person to work with. Really happy about that. And there was a lot of luck, you know, that we got to connect like that.

Then besides that, I think the main thing you need to do, if you really want to succeed with making indie games is you. you need to find the correct overlap of something you want to work on and something that also has a chance to do well in the market. And figuring out what can do well in the market, that is a little bit of a science by itself. And we could probably fill an entire podcast episode about my theory crafting about that. But like if I had to sum it up very quickly, you know, it needs to be appealing. It needs to be fun. It needs to be a good game.

So the super short summary would be just make a great game. but the problem with that is it also needs to be the right game. So a metaphor that somebody on X recently helped me refine a little bit. Imagine you're selling ice cream. It's not enough to sell the perfect ice cream. It also needs to be the correct kind of ice cream. Because if you're making perfect garlic ice cream, everybody's like, yeah, sure, it's perfect garlic ice cream.

But I don't want garlic ice cream. So you need to make great ice cream, but it also needs to be a flavor that people actually want. And, you know, don't open your ice cream stand next to a bunch of other people who are already selling the same kind of ice cream. Like a pretty decent analogy. Well, I guess you need to be aware of the actual, you know, like what is happening in the world. Because right now, if you start to sell Dubai chocolate ice cream, it will be popular because, you know, the past few months, it's actually been a trend. right but if you did that a year before or a year after probably not those kind of things as well short-term trend chasing doesn't work very well with game development because it's such a lengthy

process and by the time your game comes out the the trends have already moved on so you're really looking for those long-term trends and what really does well in the long run you kind of have to have a finger on and yeah what what people really crave and figuring that out I think one of the main challenges. And then also accepting that you're not making just your own dream game, but that you have to make a game for others. That is the other half of the challenge that some people struggle with where they're like, yeah, but I really want to make this and this kind of game.

And if you tell them, yeah, sure, you can make that game, but I'm not sure if it's going to sell all that well, then they're just like, la la la la la. you know if you want to make whatever you want to make more power to you that's obviously perfectly fine

but if you want to succeed then you also have to think a little bit about what what is likely to succeed and you know it's not as pure it's not as idealistic as just make great games

just follow your passion but you need to strike some compromise there for sure Yeah. Yeah, thanks. Thanks for that. So with that, we'll close it up with some rapid questions. Yeah.

If you're okay with that, I'll just ask and then you fire back. I'll see how rapid I can make it well. Yeah. What is a game that you enjoy playing and would recommend? And obviously, like, you cannot say any of the games that you made. Specifically to engineers, I would recommend Opos Magnum if you haven't played it. It's a great puzzle game. You should play it.

And just in general, I would recommend everybody should. play outer wilds. It's a bit more tricky to get into, but give it some time, play outer wilds. Thank me later. I'm going to give it a go. And I'll see if I'll thank you for it. What is your favorite programming language and why? Depends on the use case. Ooh, I haven't heard this before. Very practical. Okay, tell me. Yeah, I think both game engines as well as programming languages, they have different pros and content depending on what you're trying to do,

you can use different tools, like pick a tool that is appropriate for the job that you're trying to get done. Spoken like a true game designer. I think maybe I don't know enough programming languages to really make a great judgment call about this. You know, I'm not a sharp. That's fair.

Software engineers are often, you know, like bias towards one language or the other strengths or the weaknesses. but I like the practical aspect of this. What are two books that you'd recommend reading? If you want to get into game development, I would recommend 10 steps to making your first game successful by Latt Mahoulitz. I hope I didn't screw up that name, but I can show the book real quick.

The reason I like this book is because it's a fairly easy read, a very big font, you can go through this relatively quickly. and essentially touches on everything you need to know about making a full-on video game. It's a bit surface level, but it tells you a bit about everything. So I think it's a very, very good starting point. Awesome. Any other book? Or just one one?

One book also works. There's another one you should at least know about when you want to make games, and that is Flow by Mihai, Cheeks and Mihai. I'm not sure you necessarily have to read that book because this one is certainly not an easy read. It's a bit exhausting to read, honestly. But maybe you can read a summary about it or something. Awesome. Well, thank you very much for sharing all of these proper behind the scenes of how a game is truly made.

I've had a really good time just taking it all then. Thank you. Thank you for Jonas for taking us to behind the scenes of building of the Indie Game Thronefall. The game is available on Steam and on Nintendo Switch. Jonas also documents his indie game development journey on his YouTube channel. Check it out. It's linked in the show notes below. For a deep dive of how to build a simple game using Unity, and for the basics on game development,

see the pragmatic engineer deep dives also linked to the show notes below. If you enjoy this podcast, please do subscribe on your favorite podcast platform and on YouTube. Thanks, and see you in the next one.