Two developers built a game that sold 1M copies. How?

pragmaticengineer Oiz6Q7txUqk Watch on YouTube Published January 28, 2025
Scored
Duration
1:29:32
Views
81,005
Likes
1,231

Scores

Composite
0.46
Freshness
0.00
Quality
0.70
Relevance
1.00
16,853 words Language: en Auto-generated

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 hm what do I want to make today I just come up with a random idea that I find interesting 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 follows minimalist strategy game I bought the game enjoyed playing with it and then was surprised to discover that it has sold a million copies at the first year ver 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 are joining us and we're going to cover the structure of trone fall as a game how scenes 3D models C Cod other parts make up the game while 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 while implementing pth fighting with an AAR 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're 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 on any podcast platform and on YouTube so talking about the tech 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 I if you want I can open up Unity for this this will just all righty we have uh Unity open uh right now so Unity is the program we use to make our games uh will snail was made in game maker so I'm with a couple different engines I've debled with go a bit as well but Unity is our option of choice for this one uh I don't know what what what do you think uh so would you mind sharing us you know what programming languages use what Frameworks you 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 a 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 screen so in the game this I love that screen where you can write around yeah Unity uses C so all of this is uh written entirely in C 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 can like share resources relatively easily and we definitely bought a couple of things there like um as a small IND team if you if you can find a way to cut Corners in safe time you definitely do it uh all of the 3D models you see here we made ourselves in blender but like the the tun Shader is just something we we downloaded from the asset store and then the Shader for those of us who are not game developers like what what does that do I know it's something to do with you know graphics and and rendering but can you explain for for a software engineer who's not a game developer mhm so um 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 would it be a different way to say it yeah because um like for the game logic where where do your units go and all that other stuff that is typ typically done on the CPU cuz uh the 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 B basically defined by the shaders so you can can say okay if 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 um yeah so shaders are like highly optimized uh code for the graphics card that I usually used to render Graphics but you can also use them to do different things if you want to this episode is brought to you by formation a personalized interview prep program for experienced software Engineers formation is built by xfang 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 as a system design coding and behavioral interviews they assist in landing top tier roles and level up your compensation through unlimited career coaching and Technical mentorship rigorously 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. df/ pragmatic that is FM dodev pragmatic this episode is brought to you by work OS if you're building a SAS app at some point your customers will start asking for Enterprise features like salification skim provisioning and fine grain authorization that's where work comes in making it fast and painless ad Enterprise features to your app their apis are easy to understand and you can ship quickly and get back to building other features work also provides a free user management solution called authkit for up to 1 Mill monthly active users it's a drop in replacement for OD zero and comes standard with useful features like domain verification role base Access Control bot protection and MFA it's powered by radic components which means zero compromises in design you get Limitless customizations as well as modular templates designed for quick Integrations today hundreds of fast growing stups are powered by work OS including ones you probably know like cursor versel and perplexity check it out at work.com to learn more that is workos and does 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 what what you know you just bought one I'm sure there's open source ones but but it in the end it doesn't sound like for especially for an indie gamer it's worth building your own and spending so much you know time time and sweat into it right they are surprisingly easy to build depending on what you want to build like there a couple of things that are pretty pretty easy to build there a couple of things that are very difficult to build um in the case of like a fully fletched out tune Shader with all of the features you want because you know you 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 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 or whatever you can you can do that within half an hour especially with the help of jet GPT or so so there some things you you do yourself faster to do yourself there are some things where you try to use somebody else as F because would just not be feasible to do it yourself but you're right it's it's very much a commodity also Unity comes with a lot of built-in shaders so if you look here there's like a massive massive list of shaders that already come with unity so yeah like in also in like 90% 80% of the cases you'll just use the build in unity shaders and that would be completely fine as well and what is the structure of this this Unity project uh in terms of you know like again I'm I'm not familiar at all with the how how games are structured if this was not a game it would be like a series of modules uh and you know like in different things how does it look like in your case how do you think of it um there are different resource type so everything's 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 is scenes so scenes are essentially I would say levels say so we have this is our level select area but we also have scenes for other levels this here is the second level D Stein um which currently has OD colors hold on color oh I remember this level yeah this is how it looks usually it's also one of the bonus levels when they they come they keep coming up y um where was it exactly and then within scenes you have a number of objects or I'm I'm sorry if I screw up the terminology a little bit there like I think think maybe instances would be the correct way to would 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 a couple of C scripts attached to it and these C scripts they're all mono behaviors so they inherit from the monob behavior class mhm and mono behaviors are essentially just the the type of object that you can attach to uh game objects and and then that's where you you define like how it behaves like State those kind of things yeah I I opened one up for example purposes here we can see how one of those Mo 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 um but yeah this is roughly how it looks like um you just have but let's let's talk about this so you consider this spaghetti first of all why like you know what 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 um so so before we started recording you mentioned something of uh uh writing unit tests or whatever IND the developers we don't do that at all we we know we we debug our code with uh uh debug prints like uh it's just very much a mess sometimes I I would even say like we're not even close to the verst offenders like the I've opened game projects in the past that were like insane spaghetti like you you can't even imagine and and the surprising thing this often also happens with very popular and and good games MH there 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 Cod under the hood but yeah apparently it's not really stopping stopping uh the success of games so if it works it works like that's sort of the the philosophy here well that's the thing right because the the reason like you cannot really get away of not having unit test at a inside of let's say 100 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 uh it's what would happen if you did that I mean you can do it but then you know like people are going to like make 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 if you're 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 I feel you know you're 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 M yeah I think you're right I I think it's very much a a scale thing like I think stuff like unit test and so on they 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 with a lot of these me messy things the thing is also you know as you keep scating these Indie Games bigger and bigger a lot of these things start biting you in the back more and more the more you the further you go but if you don't scale like to a super large level it's it's kind of okay you find workarounds and so on workarounds for for your own screw-ups so this this leads me to a pretty good question BEC which is like the reason we even talk about Tes and 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 uh 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 the answer is not unit test so I'm I'm just really curious of uh you know like and and what did you need to test right cuz I feel a lot of things in 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 but there's also the thing of like does it kind of work as you think it would which sounds like hard to you know like like test yeah so I think um 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 so that is a luxury uh 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 R rully rigorously yourself uh but you're not going to catch everything that way so then you before you releasee you usually test it with a with a 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 cuz then you essentially have thousands and thousands of real life testers and yeah that's honestly that's the only way to find find all of the all of the bugs or at the least all of all of the ones that matter so going back to the coding environment and and the development environment in unity I I've seen a lot some of your videos where you actually share uh what your game development process looks like which is really cool U 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 uh make some code changes uh with uh uh I guess with what what you what you've shown with mon mono objects and so on like how can you like you know like share what I know how you jump in in between these things are you more in the visual side of things in 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 VI and I kind of move Rock around like so I'm like oh here here would be a nice place for another rock or if if I make a new level then uh I take these giant shapes here and kind of bent 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 real quick and you also those big bosses at end of some levels not all of them mhm exactly so there's you can also this is called a prefab so prefab is essentially like a blueprint for for for an object you can put in your scenes right you always want all of the archers to be the same so if I addit my Archer here then it will update on all of the scenes which just pretty useful um yeah and then there are other times where you if you work on the visuals then you would probably uh do so in blender mhm so blender is is very nicely integrated with unity if I update anything in the so this is BND is a is a the 3D editor if if I put it in a simple way exactly blender is uh slowly becoming industry standard for everything around 3D modeling and so on because BL blender 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 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 uh parts of one of the bosses the is that that Lake boss yeah exactly and you see it's not fully assembled because you I I only make every part of the boss here once like all of the teeth in the engine I just it over to and then you put it together with code later or or in the in the editor you just kind of use these parts exactly I can see if I can find it maybe small spoilers ahead for everybody who hasn't played the game but I think it should be fine I I I don't think it's that much spoilers because just because you know how it looks you're not going to know how it actually that's a pretty nasty boss in the behavior sitting under the surface oh there it is so throughout the whole game it's it's rendered there just you don't see no it's not it's it's not rended usually it's turned off and then once it appears it yeah it turns on and yep it's uh assembled in the editor so it's not like you manually have to enter the coordinates of like every body part or whatever so you assemble it in the 3D view here but this boss in particular has procedural animations so it is this one is actually animated entirely with C oh there's also an animator but uh this boss doesn't use it this has what you call procedural animations uh yeah nice and then for for for the whole project like can you give a sense of the size of the project like often it's 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 it a sense because you know a million it's 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 H how would you kind of quantify when you talk with you know fellow indie game devs to to give them a sense of like okay how complex this game is really I think there's honestly no no good measure that comes to mind because there are like certainly SI like pure data size is is not not that great of a measure because there are certain types of methods that disproportionally screw up that number like for example textures and sounds are very very big whereas 3D models and code is not big at all but then also lines of code is also not not a perfect measurement because often times you often times it's not your own code right often times it's third party tools and so on so it's very difficult uh so if you want to know I think the game itself Throne fall itself is very very small game I think it's maybe 100 200 megabytes most so that's the download size right that's the download size and the reason for that is that we don't have a lot of textures right 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 the like all of the C code is pretty tiny so that's why I th thrf fall isn't isn't that big the biggest thing in thrf fall is probably the music and the sound effects M did you also create that who created that or did you buy it or did you have someone help uh the music is something I made myself and the sound effects yeah yeah you have you have to wear a lot of hats as a game developer but that's also what makes it fun the 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 snil as well and I've been making music for a long time it's it's like one of one of my hobbies my little side Hobbies so I I get get to use that there yeah okay so when when when now now I'm going to think of it a bit differently when I hear it's it's to I like it yep yep yep so just to give you an idea of how big the the assets folder so the assets folders basically where you put all of your all of the things you need that's 2.23 gabt um but as 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 finer 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 it's quite a bit bigger I I have a interesting question that I think as as like nonam devolopers would be interested in what do use for Source control and code review or do you do either I mean you I'm sure you do some sort of source control but I'm not sure about code review mhm so code review I I'll give you the the the standard answer what is code review what do you mean what are you talking about huh standard game developer answer right yeah I'm sure most developers know what it is but at Indie scale that's one of the things is like honestly I think it would be very beneficial to to do code review uh Al I think it's getting easier because you can basically copy paste your code in into chat GPT and then you know if you're at at the very least at the dummy level of most game developers myself included then usually you'll you'll get some very good recommendations from that um would probably make the project a lot easier to work with in the long run I agree but for some reason uh you know it's not something it's not something most developers are excited about most developers are excited about I 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 if there's a more efficient way to do it that's that's just not the way we think at all but uh don't get me wrong I I'm not judging you at all like seriously like 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 you're doing it and when you're saying you're not doing something that you know larger teams would do or or teams who are not building games would do I don't really see that as a negative I I see it as like look this works for you and I think it's it's actually a great Testament that there is no one practice that I don't know can help guarantee a you know creating something great because like objectively like again like I I don't know I just from from my perspective this game is great right like and it's just cool to see how how it's 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 fight and then quit and not finish the game yeah I guess the reason why I'm pointing all of this out is like negative practices to to just make make it clear that we that we know it's 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 uh I I would say there there are sometimes some some judgmental looks about some of the things we do like for example the next thing you asked is uh Source control and one of one of the next horrible things we do is uh we immediately just push everything to to the main branch like we push everything to main sometimes I've I've I've seen people make a little shocked Pikachu face about that and I'm I'm even like H 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 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 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 will 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 you 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 to to main without a review is you can break everything but you're not shipping your code right like when when you push to main it's it's it's not updating on Steam every single time so yeah because I feel this is a big difference between game development and um more SAS uh backend development is you ship very infrequently which which means a lot of these practices you you probably don't need by the way like uh I think you know for any listeners listening I think it's it's it's worth challenging you're thinking of thinking what the context is and I'll give you one more example of uh I heard a team at Apple do this thing called uh post commit code 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 so it's it's like uh and also for any game developers listening I think it's just worth thinking that you know these things that you hear practices good or bad if might not apply to your context and and and this is this is what one of the reason I was so excited to talk to you is just to see how you built this and what worked for you and we're not saying this is going to work for everyone but uh I have a feeling if someone wants to build a successful game there there and with a small team it's worth paying attention to what you're doing because you you clearly have found some that works for you yeah I I 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 in like a team of two it's it's still kind of fine and also we pay attention to keep the game in a functional state with every commit but this is something that I think uh I resonate with and that uh that can get a problem very quickly even in smaller teams is that if everybody just pushes everything to Main and you know even pushes like uh 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 in Pro progress are broken that is very annoying I will say that that is very very annoying and it uh that sort of stuff uh can happen sometimes when you work with uh I don't know less experienced people or people that you're not as much in the group grof with yeah like for for Paul and I I think this wasn't a big issue at at the beginning stage of course sometimes the game wasn't in a functional state but then like once it's functional we pretty much always try to keep it functional so then that whenever the other person wants to test it or run something that it's it's always working and very runnable yeah so one topic that I just wanted to touch on while you still have your editor 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 and clearly like when I played with this game which and I played with this before we met in fact I I I reached out to you after I played with the game and I realiz a tiny team and I thought maybe we could get some behind the scenes which I'm very happy what we're doing games need to be fun right like I I like this game uh and I I tell people that it's 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 SE 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 and feel to it like how how did you balance with all this coding and and design work which doesn't seem like all that fun so there there 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 Pro prototype but then once the concept is set into stone the way we split it for this project is that I was I was the one responsible of uh 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 and was like uh yeah this is indeed fun or for example in the beginning I wanted to balance the com economy a bit differently make it a bit uh balance it a bit slower and Paul was like yeah this doesn't feel too great I 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 that regard and and how important was feedback from the players the the beta testers The Early Access uh testers that I'm trying to get to the point of you know there I feel there's two thoughts of creating great games one is listen or or like creating great products in general one is listen to your your customers you know they 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 nope don't do any with that you know do Steve Jobs uh decide what you're going to do it's going to be great uh push through and then eventually people will come around like do you sit in any of these ones that you know how they deal with the feedback what was the feedback even yeah so the way way um we do this we gradually increase the number of play testers so we started with a bun with like a close circle of handpicked people that we trust and we got our first round of feedback from that then we expanded it to 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 like essentially a very big testing phase right with lots and basically everybody who bought the game is suddenly a test 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 um I'll I'll for everybody who doesn't know the game I'll quickly show some context here if if this starts up come on give it a little time so often times when you build these buildings you get to choose between different upgrades and this was something was just not the case in in the first version of the game and this was also something that we we didn't plan for like this was this was not in our initial design that was not not something that we pled to do but then because play testers the very early the first round of play testers reported back to us that it's like a little bit too too little choice and this doesn't really feel like you're building your own base right you're building everything on these predefined build slots anyway you can't in Throne fall you can't build buildings wherever you want you have to build on yeah on these predin slots and that combined with the fact that you know you can't even choose you can't even customize the buildings it it felt a bit too rigid to people and we reacted to that feedback by implementing implementing these upgrade choices so now you have a lot more choice and and a lot more options to customize your base and then in the end once you base is fully built out even though the layout is predefined by us it still feels like your own cuz you got to customize and choose a lot of um lot of different things here yeah but 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 on on easier uh and then uh there's the mini games and in some mini games you actually have this where you cannot choose uh you can only build uh you can choose like if you build like it's a binary yay or nay and then that's it so I I did that come from like keeping some of mini games some of the earlier kind of versions honestly the mini games is where I just go wild as as a designer and I'm like you know it's it's it's often you have often have a lot of untapped potential in your game systems where it's like I have 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 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 your character turns into a snowball and I was about to say that that was my favorite I I I couldn't complete it so I I don't know how you do the difficulty settings but I failed like I did the first like all the waves but the last one I just cannot do it just this tiny ah I'm sure if I could practice more which is by the way one one one more question to those you know of us who do who do not build games but were wondering how you do how do you tweak the difficulty to feel right like CU for again I'm not a huge gamer but but I do play right now and then it felt right to me it was challenging you know I had to restart some levels but I I could finish it and then some of the mini games are giving me grief I just cannot finish them which I guess is kind of fine because I'm I'm not that good of a gamer yeah the mini games they they are very hard they they're like you're making feel 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 HD them away a little further so not not as many people play them anymore and they're like clearly identifiable as endgame content yeah but you can obvious obviously imagine people jumping into those mini modes before even finishing the game like that's bad idea bad idea bad idea um yeah so arguably they're 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 you're usually quite quite a lot better than the average player who will play your game yeah 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 Throne fall they're so easy they have like the best players in Throne fall they can finish most levels with only the king with without building a single building and that yeah that should tell you now you're making feel bad uh it doesn't work with every level but in in a lot of levels certainly I think the first three or so certainly like the ice boss and so on you you can beat with just the king no buildings it's um well you can do that as as a developer and and pro Gamers but yeah yeah I'm not sure I can do that but I've I've seen going back to that question uh as as a as a developer like do you just get this feel of what a good difficulty is for a game that will actually be sold and and you know people will enjoy it people like me people like you know the casual gamers who are people who are buying it or or do you get it from the the feedback or because this it feels like this is a really big difference right like you're so much better you like and but yet you need to produce something that will I don't know like I I guess be be fun and enjoyable for the you know general public yeah one thing thing that a lot of people forget about balancing is that first of all you need to make a game that is balanceable and easy and somewhat reasonable to balance the problem with the problem with strategy games like Throne fall is is that they are very very very snowb 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 Throne fall and strategy games in general they have a tendency to feel very frustrating very quickly cuz 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 balancing throne and fall is just this runaway Dynamic of it all that I 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 Throne fall there like one way I actually try to counteract this is by making enemies drop gold that was also something that uh wasn't the always the case from the very beginning but and I very quickly realized that we need that because like the 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 Smooths that curve 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 in time so 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 ah there's there's no Shenanigans going on like that but there like it's it's just math if if um 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 got it got it that makes it easier to balance than trying to predict how many you're going to have and so on so that oh I understand yeah so after you buil this game you've now ported it to Nintendo switch what what did that porting look like from a technical perspective did you do the porting did someone else do the porting uh we outsourced the porting 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 uh was parted by coding will snail 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 uh kind of things is you get a revenue share in and other than that you basically have don't have to do anything like they take care of all of the publishing they take care of The Parting it's like completely hands of and very free which is which is why if if you have a successful game on Steam already it's PR pretty much a no-brainer to just give your game to one of these companies because they're like okay we'll take we'll take care of everything and you'll just get a revenue share of what we make yeah I'm assuming they're they're used to you know taking especially if it's Unity C you running on this code base they'll they'll take it they'll know how to change it they'll know all the performance issues ETC the testing that sounds a pretty sweet deal as a it's kind of a positive thing if if 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 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 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 is more like a a little bonus on top of what you're making on Steam like steam is I think by far the biggest market for for Indie Games trust isn't just earned it's demanded whether you're startup founder navigating your first audit or season secur to professional skill your governance risk and compliance program proving your commitment to security has never been more critical or more complex that's where vant comes in vant 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 vant gives your time back so you can focus on building your company businesses use vant to establish trust by automating compliance needs across over 35 Frameworks like sock 2 and ISO 271 with vanta they centralize security workflows complete questioners up to five times faster and proactively manage vendor risk join over 9,000 global companies to manage risk and proove Security in real time for a limited time my listeners get $1,000 off vanta atv.com pragmatic that is v.com 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 I I played in throw and fall I I I actually love the game it's it's just great way to spend in you know like 10 minutes 20 and then it turns into a few hours uh 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 or a co-developer yeah thrf fall we made in a team of Two And what I just talked about is a is a perfect gateway to how we started making Throne fall cuz what we do in the very beginning is very much uh 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 which direction you find most promising and then you keep searching in that direction so that is pretty much exactly what we did for throne fall we we made a bunch of different prototypes uh in unity just one or two days working on little mini games so we had one prototype uh about spreading flowers we had had a climbing prototype we had a card game uh and all 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 on what we wanted to make and it just turned out to be thrown fold I I don't know how exactly we arrived there just in in this specific case um and and and when you say like you know that you're exploring them so you kind of like is it just you kind of you know building this like mini Prototype game and then just playing around with it seeing how it feels showing it to your uh your your friend who's also working on it just bouncing ideas is that kind of how it is or or can you help us imagine like how does it you know how does this phase look like so the one challenge that you um face a little bit is that you need to find a compromise between something that you want to make and that something you and something you think that will sell and that's one of the main challenges uh 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 that is fairly tricky um so the 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 or guess how well it would do on the market and then you move forward with with the ideas that you think are most promising how exactly it looks like um like I I come here in the morning I sit down I open Unity I I'm like H what do I want to make today I just come up with a random idea that I find interesting and I and I just make it like 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 you can get that up and running super super quickly like what takes the most amount of time is just polishing it up and bringing it to production quality but if you 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 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 we talk about them of course um 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 to find the overlap between all of those things so that's why obviously talking about these prototypes is is pretty crucial and usually what you do is you do specifically game playay prototypes so you start with gameplay and then only once you're sure what the game play is going to be then you move on to visual prototypes where you basically repeat the entire process that you did for gameplay with uh 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 uh what you think will do well in the market it's really so so specifically with Throne fall you said okay you had the prototypes and then you figure it out you're going to make Throne fall but what 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 I'm putting it like that based on how I I played with it or 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 there as mentioned there were some completely Wild things like like a game where you were golfing flowers like a golf ball essentially so some just wild ideas and then at some point we uh narrowed down our search a bit further and we were like okay we want to make a minimalist uh game about building a kingdom we were like okay this search is getting out of hand there are like too many options decision paralysis let's just kind of focus down a bit more and then we made a bunch of prototypes uh that specifically had to do with managing tiny kingdoms like I made a turn based game and I made like a plant where a zombie like game where like there 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 had it had a very nice Rhythm to it cuz there 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 when you see it you see it I don't know it was like we we both immediately agreed that this was going to be the game we were going to make because it was just a ways ahead of all of the other prototypes we've we've made so far mhm So based on the kind of feeling and you know your understanding of like okay what could work actually yep Y 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 is 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 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 in a month then obviously only only maybe spend 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 the with a card game we thought uh our kingdom management game is going to be a card game then after about a month of development and me over engineering like a a cool system we realized uh it's not that's not it and we 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 and boom that that that's it yes so honestly ly yeah I was grateful that we noticed at all CU in the worst case you develop the entire game you spend two years and then you notice that doesn't work so whenever I I notice relatively early that something doesn't work I I it's not like ah what a shame it's more like we dodged the bullet there you know yeah it's more that feeling so uh it's more a feeling of of relief than than anything else and then once you okay figure figured out this is this is a concept this is a game that we're we're going to go like you know we we're happy with the Prototype and let's continue on how do things look like from there cuz I assume that that's when things change right did you start to do some sort of planning is it just more kind of keep 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 had another pH for the visual prototype cuz the visuals are also very important and you repeat the entire process you basically have the game play already done and what you do is you s can you just help understand for for the gameplay prototype like what can we imagine is it like squares and like circles moving around or like super low Fidelity versus the visual exactly the the gameplay prototype is essentially Pro what we call programmer art which is just a bunch of squares and boxes with colors and and for the art prototype what you what we do this is our process is we scrap all of the gameplay once again so we it's not like we delete it but we're we start in an empty Project without any gameplay whatsoever and we just build a scene without without any any logic we just open my game engine and try to create a nice looking scene that it does it doesn't have any motion doesn't have any logic we just try to make it look nice and if you if you decouple the game play from the visual 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 H messing around how how things should look like you you like put little 3D models in there you experiment with different camera scales with different Zoom levels and then we had 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 look the best or the most attractive and yeah on once 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 to start uh getting a bit more organized like in in a team of two it's it's sort of fine you know it's not like there's insane management overhead you only have to manage uh communication between two people which which is fairly manageable I would say um so we just have to agree who works on 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 um 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 the work goes into that so but but the UI what what is the difference with the UI and the game play so the UI is uh 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 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 uh it has to also look nice and so on and so forth so it's a fairly fairly massive task so but we we we shared gameplay programming I would say 50/50 and then pauled most of the UI stuff nice and and then what was the point where you actually had a you know a more traditional schedule in in place of like okay we now know what we're bu doing we need to build you know the core engine the levels the the different structures I'm just throwing out stuff I I don't know if this is how how you actually structured it but I just be interested like how did how did it look like when you're like okay we know roughly how this is going to go and obviously at what point could you even uh announce dates because I just look back on you know the history and I saw when people very excited when they saw the first demos and of course what they asked is like when when is it ready when when when will it be out mhm so basically when you have the two prototypes if you have the gameplay prototype and the visual prototype then you have a very 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 we still have to answer questions of like how do the act 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 upgrad are there so the search process definitely continues and we 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 and so Paul and you are you both in were you in the same city same country we are both uh in in Germany and we studied uh game design together at University so Paul is also one of the people I made Islanders with at University and we just teamed up teamed up again for throne fall here nice and then so you 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 what does a launch look like for a for an indie game uh you launched it on Steam right was it only steam or did it launch Elsewhere on launch day uh on launch day it was only on Steam now it's also available on Nintendo switch yeah how does a launch look like it's it's surprisingly anticlimactic so there's a there's a button in the steam back end where you just like launch the game and you click it and then there you know 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 uh then 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 um you know trying to outsmart the market when you're buying stocks or something like everybody tries to be smarter than you so in in the end it doesn't really matter when you launch because um the the good spots are already very crowded 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 d dyamics make it so that it doesn't matter too much yeah well I 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 it's nice to hear that the things that people think matter don't matter that much one one more topic on the development itself what were some challenges that that that you would say were more challenging with this game I'm just throwing in at some ideas made that be performance binary size as structure whatnot what what what made this one more challenging than the other ones that you built so the main challenge for this one for me personally was uh everything related to pathf finding oh interesting the I'm not sure if you're aware of like algorithms like AAR and so on very much so you'd be surprised uh on some interviews if you interview to Google Facebook ET 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 uh in some of the things there's pathf finding and uh like nodes computers uh where where to go like a typical interview question will be like how does Google search you know like search between all all these things so in theory we do it but you actually are using it mhm yep so the way this works in in Throne fall is you see there there's basically this blue overlay grid here on the ground and every 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 pathfinding on on these nodes and this is a this is a rade system like this a star system is something we pulled from the asset store we did not make this ourselves but of of course you still have to customize it to a certain degree to your own needs so but hold on just so I understand like the units definitely don't move on those paths do they they like that doesn't look like the path that the units take to me or they do maybe I'm just misunderstanding it they they do they do move on like if you want to perform AAR pathfinding then first of all you have to you need a a note graph right a graph yes yes yes yeah so this the this is the graph yeah so that's the graph yeah that's not the path the units takes that that's the that's a graph that they perform to search exactly and this graph is also uh dynamically updated for example when I build a castle Center here uh you know it isn't it then you see there's a hole in the graph now where the and it's now connected that way exactly and this is all automatically updated and done by the by the plugin we purchased from the asset store so you can see here we can Define these shapes which kind of shapes should be cut 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 it's such a nightmare because uh 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 worker rounds then those work arounds cause new problems do you needed to worry about unit Collision or I I don't think so right in this game they don't uh they can go through each other no they they do Collide so okay so you need to worry about that as well yes it's partially taken care of by uh 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 they Ah that's local avoidance plugin does that that is all luckily handled by the plugin now from just a quick question from a you know like a t perspective like is that property would that be code that is executed on each of the the units like a mono behavior for example or 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 you know it's kind of similar for most strategy games like most Strate strategy games if you've played any they often times they have like a a unit limit of 200 or so and and the reason for that is usually not for gameplay reasons but for performance reasons because like you're more than 200 units then at some point you're going to burn burn out your CPU um so yeah this is all handled on the objects individually and it's it's not very well optimized to be quite Frank I mean it works and and we have pretty powerful CPU so yeah exactly and then of course you also have the the things that they're not exactly uh moving on the nodes right so that you basically also have to do some postprocessing on those paths um 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 on the corners here and you know at the beginning there were all kinds of problems like they getting stuck corners and so on okay and yeah but but also the the walls cause a lot of problems cuz you can see my units they can go through the walls but the enemy units they cannot go through the walls so 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 bit of a nightmare and there are still some issues with that but yeah well now now the enemy units are mostly just attack the walls often so yeah indeed they they do they except they basically pretend like they can walk through it and they don't know that they can't like they like confused why why can I not go through that well see but 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 this 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 but you know that's that's also 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 um yeah so to answer question what what was the biggest hassle I think for me personally uh the pathf finding was was the biggest hassle from a 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 snowb nature we'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 more 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 CP of extra mutators and I feel like yeah in the end it worked all out all okay but there there were challenges for sure yeah no yeah gen AI this is just it's everywhere now there 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 Chad GPT and also do you see any Indie developers using any tools or or stuff that makes your work easier and is it making making your work easier or faster F at all it does my it does make my work uh significantly easier and I think the mo most people most Indie developers who say chat GPT is not helpful for them they in my opinion they have not master that tool yet cuz it has a bit of a learning curve you you need to learn what it can do what what cannot do but once you know what it can and what what it cannot do it is incredibly powerful like especially for beginner L questions on any subject it's it's also incredibly re reliable so so when when we talk about gen and gen tools you use is it Chad GPT mostly for you yeah uh I bounced back and forth a bit between Chad GPT and Claud but currently I'm back at chat GPT I think the the 01 the O Series is pretty good at coding mhm U and then what what what kind of stuff do you 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 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 Chet GPT is incredibly good at filling that in for you so that's just like a little speed Tech that I like to do right I come up with the I 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 from like the inputs and the context uh chpt 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 CPT 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 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 know instead of having to learn Shader code and spending months on that I can just basically ask chgb and 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 you didn't use it very well yeah that's that's uh I guess my take yeah and uh do you use GitHub copilot at all or no you just use Chad D because because what you mentioned of like you know doing the toos Etc co-pilot might be able to do that did you try it or no didn't stick uh I haven't actually haven't tried it I probably should try it sometime but haven't haven't tried it so far and I'm also a little afraid of it what of what it might do to my workflow cuz I I kind of wanted to uh be intentional when I use it I don't want it to be constantly running in the background and doing things at the ear least 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 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 co-pilot 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 yeah I I want I want to use it intentionally and and when I want to want 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 there 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 and I want to uh be able to make that call and I 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 as as a as a broader picture what are some things that you kind of wish you knew before getting into IND development because so far we've talked talked about what I feel is more of the engineering part and a little bit of the art which is you know the code the design those things but I'm going to suspect that there's a lot of other things going outside I know you do for example do YouTube YouTube videos you mentioned you do music what were all these other things that oh turns out they're kind of part of you know building a game with a small team so the one thing I hate most is uh bureaucracy really what what kind of bureaucracy taxes filling out for steam accounting that's that's the one thing I nobody tells you about dealing with legal documents you know creating all of these deals writing back and forth with lawyers it's like ah I just can't be bothered luckily it's not a super big portion of the work I do but it's just the most annoying part by far that nobody really talks about nope um yeah but I other than that I I think what's Pleasant about being a game developer for me personally is that you get to wear a lot of different hats so you get to make graphics you get to make music you get to write code you 3D model you texture you do sound design you come up with cool systems and uh write cool teag and this is 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 that is also oftentimes underestimated is the UI coding all of the overlay menus and so on that very annoying I'm 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 uh that that that you know if you know some SE several listeners are are software Engineers who know how to code very well but they might be thinking of getting into any development what advice would you have for for these uh people in starting to build uh 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 if you you're like H 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 godau game maker unre there are lots of good options to choose from pick one of those CU 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 it really is if you're making games alone or in a tiny team of two or three people you need insane speed to even be able to finish your game and you all and 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 um the main thing that people or that new developers I think should know is that games don't automatically sell better if they're if they're bigger that's not the case so you need a good uh payoff to effort Rao that's what you really after right so you 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 to make up for it and that is um 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 uh the harder it is to make that return on investment so actually smaller games are are much much easier to make successful because if you 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' I've seen it a lot for the games I build for some of the games my some of my friends build there there is a market for small and focused experiences so that's 100% well and I'm I'm going to go on and stretch in a little bit but I I like I'm an example and I think a lot of software Engineers who have like day jobs you know working you 8 to 10 hours a day at a company going home potentially having other uh things to do you just don't have as much time and uh like a lot of us like you know we are able to afford you know the indie game of you know 10 20 3040 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 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 see that it's like 80 hours or 160 hours to finish I'm like no it's it's a no noo for me so there's that part which is like this is one of the reasons I 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 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 uh 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 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 uh build Technical Systems right away like even in engine a lot of I think a lot of people who come from a engineering Direction they they kind of have the urge to to build their MMO system before they even test it if it's fun or not so take your time take it slow and approach it from 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 uh how you how you want to engineer the system behind it but figure out the experience first and then then go into the engineering part of it I think that's very important thank you in terms of learning how to how games engine how how games are built uh again coming from a background where you do know coding so that 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 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 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 um I think the main thing un university did for me is that it connected me to a lot of great people so I really have to give a big shout out to to my game school for that it like I studied game design at htw 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 um 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 way or something but you can 100% s teach that to yourself but one thing that was just immensely immensely immensely valuable was just the the people I met there cuz uh they basically uh curated a list of really awesome people and that was incredibly valuable as a turn out cuz I I went on to uh start a company with with some of some of them yeah and yeah I guess part of the reason is that they have an application process where obviously they only select a uh 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 uh you won't have such a nice nicely curated list probably um so if 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 uh people there because honestly the more difficult it is to get in uh the more awesome the people you will likely meet there I like that yeah other than that don't don't be worried you can you can be selftaught it's not a problem how do you see success as an indie developer for those who want to get serious about it uh you you are reasonably successful if if I'm kind of underrating it but you you've had uh two big hits already and even the third game is is I think what a lot of developers would would dream of what do you think helped your success uh and when other Indie developers ask you for advice what what did you tell them well the the honest answer 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 got I feel like especially extremely lucky with like the the people I met like Paul is just such a fantastic person to work with really happy about that and that there was a lot of luck you know that we uh got to connect like that uh 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 uh 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 so the 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 uh somebody on X recently helped me refine a little bit is imagine you're selling ice cream it's it's not enough to sell the perfect ice cream Al needs to be the correct kind of ice cream because if you're making perfect garlic ice cream and everybody's like yeah sure it's perect perfect garlic ice cream but I don't want garlic ice cream so you need to make great ice cream but also needs to be a flavor that people actually want and you know don't open your 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 yeah 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 or or a year after probably not those kind of things as well shortterm 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 uh long-term trends and what really does well in the long run you kind of have to have a finger on on yeah what what people really Cate and figuring that out is I think one of the main challenges and then also accepting that you're not making just your own dream game but that you're that you have to make a game for others that is 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 you know um if you want to make whatever you want to make more power to you that's that's obviously perfectly fine but if you want to succeed then you also have to think a little bit about uh what what is likely to succeed and you know it's it's 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 uh we'll close it up with some rapid questions if you're okay with that I'll just ask and then you you fire back L see how rapid I can make it but I'll try my best what is a game that you enjoy playing and would recommend and obviously like you cannot say any of the games that you made uh specifically to Engineers I would recommend Opus Magnum if you haven't played it it's a great puzzle game you should play it and Justin General I would recommend uh everybody should play aut of Wilds it's a bit more tricky to get into like but give it some time play out Wilds thank me later I'm I'm going to give it a go and I'll I'll see if I I thank you for it what is your favorite programming language and why depends on the use case oo haven't heard this before very practical okay tell me yeah I think uh G both game engines as well as uh programming languages they they have different pros and cons and 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 yeah spoken like a true game designer I think I maybe I don't know enough programming languages to really make a a great judgment call about this you know I I know sh Fair uh software Engineers are often you know like like biased towards one language or the other the strengths or or the weaknesses but I I 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 lot mulets I hope I didn't screw up that name but I can show the book real quick t uh the reason I like this book is because it's a fairly easy read you know a very very big font you can go through this relatively quickly and essentially touches on everything you need to know about uh making a fullon video game it's a 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 and any other book or or this one book also works there's another one you should at least uh know about when you want to make games and that is Flow by Mii Chi s Mii um 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 for read honestly but uh maybe you can read a summary about it or something awesome well well well thank you very much for sharing all of these is like proper behind the scenes of how a game is is truly made I i' I've had a really good time just taking it all in thank you thank you for Jonas for taking us to behind the scenes of building of the indie game Throne fall 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 about how to build a simple game using unity and for the basics on game development see the pragmatic engineer deep Dives also linked in the show not below if you've enjoyed this podcast please do subscribe on your favorite podcast platform and on YouTube thanks and see you in the next one

Summary

Two indie developers share their process for creating the successful game Thronefall, emphasizing rapid prototyping, focusing on fun and market appeal, and using Unity with C# to build a minimalist strategy game that sold over a million copies.

Key Points

  • The developers built Thronefall through a rapid prototyping process, creating many mini-games to find a concept that was both fun and marketable.
  • They used Unity with C# for development, leveraging the engine's built-in tools and purchasing assets like shaders and pathfinding algorithms to save time.
  • The game's minimalist art style and small file size (100-200MB) were intentional choices to keep development focused and efficient.
  • They split roles, with one developer handling gameplay and content, and the other focusing on UI and art, which helped manage the workload.
  • The team did not use unit tests or code reviews, prioritizing speed and functionality over strict engineering practices, which worked for their small-scale project.
  • They used AI tools like ChatGPT to generate boilerplate code and understand complex areas like shaders, significantly speeding up development.
  • The game's success was due to finding a balance between a game they enjoyed making and one that had market potential, not just a personal passion project.
  • They released the game on Steam first, with a simple launch process, and later ported it to Nintendo Switch via a revenue-share deal with a third-party company.
  • Player feedback during Early Access was crucial, leading to the addition of building upgrades to make the game feel more customizable.
  • The developers recommend that indie developers use established engines like Unity, avoid building their own engine, and focus on creating small, high-quality games.

Key Takeaways

  • Prioritize rapid prototyping to test multiple ideas quickly and find a concept that is both enjoyable and marketable.
  • Use established game engines like Unity and leverage pre-built assets to accelerate development and reduce technical debt.
  • Focus on a small, well-defined game scope to manage time and resources effectively, as larger projects have a harder time achieving a good return on investment.
  • Consider the market and player feedback early and often; a great game must also be a game people want to play.
  • Leverage AI tools like ChatGPT to generate code and understand complex topics, which can significantly speed up the development process.

Primary Category

Indie Games

Secondary Categories

Game Design Analysis Game Mechanics & Systems

Topics

indie game development Thronefall Unity C# Blender game prototyping pathfinding difficulty balancing AI in game development ChatGPT source control code review game launch Nintendo Switch porting

Entities

people
Jonas Tyroller Gergely Orosz
organizations
The Pragmatic Engineer Formation WorkOS Vanta Unity Blender Warp Digital No Gravity Games
products
technologies
domain_specific
video_games game_genres gaming_platforms game_developers game_publishers

Sentiment

0.85 (Positive)

Content Type

interview

Difficulty

intermediate

Tone

educational entertaining inspirational technical professional