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

Transcript

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

0:00
The one challenge that you face a little bit is that you need to find a
0:03
compromise between something that you want to make and something you think
0:06
that will sell.
0:07
First of all,
0:07
finding something that will sell is already difficult,
0:09
but then finding something that will sell that you also like to work on,
0:12
that is fairly tricky.
0:13
The way you approach it is usually you just make a lot of things that you can
0:17
imagine working on that you're interested in,
0:19
and then you are trying to measure or guess how well it would do on the market,
0:23
and then you move forward with the ideas that you think are most promising.
0:28
How exactly it looks like,
0:29
I come here in the morning,
0:30
I sit down,
0:31
I open Unity.
0:32
SPEAKER_0: I'm like, "What do I want to make today?"
0:35
I just come up with a random idea that I find interesting and I just make it.
0:39
The thing that I think that is important to realize is that you can make games very,
0:43
very quickly.
0:44
If you just want to make a simple prototype without any fancy graphics or
0:47
menus or whatever,
0:48
you can get that up and running super,
0:49
super quickly.
0:50
What takes the most amount of time is just polishing it up and bringing it to
0:53
production quality.
0:54
But if you just want to try out a random little idea,
0:57
you can mostly do that in one or two days.
1:00
SPEAKER_1: Thronefall is a minimal strategy game.
1:01
I bought the game,
1:02
enjoyed playing with it,
1:03
and I was surprised to discover that it has sold a million copies of the first
1:06
year of its launch,
1:07
and also that it's only been built by two developers.
1:10
SPEAKER_1: I figured would it not be nice to know how the game was built?
1:14
For this episode,
1:15
we have one of the two developers,
1:16
Jonas Tyroller joining us and we're going to cover the structure of
1:20
Thronefall as a game,
1:21
how scenes,
1:22
3D models,
1:23
C# code,
1:23
and other parts make up the game.
1:26
Why Jonas starts his game development process by building a new mini game
1:29
each day that he then throws away and does this for a few months.
1:33
Why implementing Pathfinding with an A* algorithm was an interesting
1:36
challenge building the game,
1:38
tips on getting started as an indie game developer,
1:40
especially if you know how to already code and many more fascinating details
1:44
about indie game development.
1:46
Whether you're thinking of one day perhaps building your own indie game or
1:49
you're just interested how these games are built,
1:51
this episode is for you.
1:52
If you enjoy the show,
1:53
please subscribe to the podcast in any podcast platform and on YouTube.
1:58
So talking about the tech stack specifically,
2:01
can you share what you use,
2:03
what language you use,
2:05
what kind of dev machine,
2:06
and can you maybe even share how your development environment looks like?
2:11
SPEAKER_0: Yes.
2:12
SPEAKER_0: So if you want, I can open up Unity for this.
2:15
SPEAKER_0: These are just... Alrighty.
2:16
SPEAKER_0: We have Unity opened right now.
2:19
SPEAKER_0: So Unity is the program we used to make our games.
2:27
SPEAKER_0: Will You Snail?
2:27
SPEAKER_0: was made in GameMaker, so I'm familiar with a couple different engines.
2:31
I've dabbled with Godot a bit as well,
2:33
but Unity is our option of choice for this one.
2:40
SPEAKER_0: I don't know.
2:41
SPEAKER_0: What do you think what's interesting?
2:43
So would you mind sharing us what programming language did you use,
2:47
what frameworks you're using,
2:49
either open source or I'm not sure if you bought some things and then can you
2:53
just give us an overview of what does the project structure of this game look
2:57
like and what is that cool thing that we're seeing right in the middle?
3:00
SPEAKER_1: It looks like the menu a little bit.
3:01
SPEAKER_1: No?
3:03
SPEAKER_0: Exactly.
3:03
SPEAKER_0: This is the level select screens on the game.
3:05
SPEAKER_0: This will solve the [inaudible 00:03:07]
3:06
SPEAKER_1: Yeah, I love that screen.
3:09
SPEAKER_0: We can write around.
3:10
Yeah,
3:10
Unity uses C#,
3:12
so all of this is written entirely in C# and of course we don't have to worry
3:17
about any of the rendering stuff too much and all of that.
3:21
SPEAKER_0: That's all built into Unity.
3:24
SPEAKER_0: The shader we use here is something we bought from the Unity Asset Store.
3:27
So Unity has its own marketplace where you can share resources relatively
3:32
easily and we definitely bought a couple of things there.
3:37
As a small indie team,
3:38
if you can find a way to cut corners and save time,
3:40
you definitely do it.
3:43
All of the 3D models you see here,
3:45
we made ourselves in Blender,
3:46
but like this Toon Shader is just something we downloaded from the asset
3:51
store
3:52
And then the shader,
3:53
for those of us who are not game developers,
3:56
what does that do?
3:58
I know it's something to do with graphics and rendering,
4:01
but can you explain for a software engineer who's not a game developer?
4:07
So the shader is essentially what renders materials onto the screen or
4:14
shaders are the part of your game that runs on the graphics card,
4:18
maybe would it be a different way to say it.
4:20
SPEAKER_0: Because for the game logic, where do your units go and all that stuff?
4:25
That is typically done on the CPU because you could do it probably on the GPU,
4:32
but it's more difficult to optimize.
4:34
SPEAKER_0: So just for convenience, that runs on the CPU.
4:37
And then the color of each individual pixel,
4:41
that is calculated on the GPU and the way you calculate that is basically
4:45
defined by the shader.
4:46
So you can say,
4:48
okay,
4:48
if the light is coming from this direction,
4:51
then color this pixel bright.
4:53
SPEAKER_0: If the light is coming from that direction, then color the pixel dark.
4:58
Yeah,
4:58
so shaders are highly optimized code for the graphics card that I usually use
5:04
to render graphics,
5:05
but you can also use them to do different things if you want to.
5:08
This episode is brought to by Formation,
5:10
a personalized interview prep program for experienced software engineers.
5:13
Formation is built by ex-FAANG engineers who've conducted thousands of
5:17
interviews collectively so they know what it takes.
5:20
SPEAKER_1: In 2024, they helped engineers increase the comp by $110,000 on average.
5:25
They help you understand exactly how you stack up and then get you ready to ace
5:28
assistant design,
5:29
coding and behavioral interviews,
5:32
they assist in landing top tier roles and level up your composition through
5:35
unlimited career coaching and technical mentorship,
5:38
rigorously drill problems that align with your personal skill gaps.
5:41
Get unlimited mentorship to get unblocked,
5:44
do as many mocks as you need to ace the real thing.
5:47
Stop wasting time trying to figure out what to prep,
5:49
only to get to the interview and realize you had it wrong.
5:52
Formation helps put your interview prep on autopilot,
5:54
ensuring you're always focusing on the right thing.
5:57
SPEAKER_1: Apply today at fm.dev/pragmatic, that is fm.dev/pragmatic.
6:05
SPEAKER_1: This episode is brought to you by WorkOS.
6:07
If you're building a SaaS app,
6:08
at some point,
6:08
your customers will start asking for enterprise features like sample authentication,
6:12
skin provisioning,
6:13
and fine-grained authorization.
6:15
That's where WorkOS comes in,
6:17
making it fast and painless to add enterprise features to your app.
6:20
Their APIs are easy to understand and you can ship quickly and get back to
6:23
building on your features.
6:25
WorkOS also provides a free user management solution called AuthKit for up
6:29
to 1 million monthly active users.
6:31
SPEAKER_1: It's a drop-in replacement for Auth0.
6:33
Income standard would useful features like domain verification,
6:36
rule-based access control,
6:37
bot protection and MFA.
6:39
SPEAKER_1: It's powered by Radix components, which means zero compromises in design.
6:43
You get limited customizations as well as modular templates designed for
6:46
quick integrations.
6:48
Today,
6:48
hundreds of fast-growing startups are powered by WorkOS,
6:51
including ones you probably know like Cursor,
6:53
Vercel,
6:53
and Perplexity.
6:55
SPEAKER_1: Check it out at workos.com to learn more.
6:58
SPEAKER_1: That is workos.com.
7:01
And am I right to suspect that this is somewhat a commodity in the sense of it's
7:06
not going to make a huge difference for a game?
7:08
SPEAKER_1: So you just bought one.
7:10
I'm sure there's open source ones,
7:12
but in the end it doesn't sound like especially for an indie gamer,
7:16
it's worth building your own and spending so much time and sweat into it,
7:21
right?
7:23
SPEAKER_0: They are surprisingly easy to build depending on what you want to build.
7:27
SPEAKER_0: There are a couple of things that are pretty easy to build.
7:30
SPEAKER_0: There are a couple of things that are very difficult to build.
7:34
In the case of a fully fledged-out Toon Shader with all of the features you
7:38
want because this one also has shadow casting,
7:42
it has outlines and all of that.
7:44
If you want to code all of that in yourself,
7:46
you're going to be busy for a while,
7:48
but if you want to make something very simple,
7:49
like I don't know,
7:51
transparent particle or whatever,
7:54
you can do that within half an hour,
7:56
especially with the help of ChatGPT or so and so.
7:59
SPEAKER_0: There are some things you do yourself, faster to do yourself.
8:04
There are some things where you try to use somebody else's work because it
8:08
would just not be feasible to do it yourself.
8:10
SPEAKER_0: But you're right, it's very much a commodity.
8:12
SPEAKER_0: Although Unity comes with a lot of built-in shaders.
8:16
So if you look here,
8:17
there's a massive,
8:18
massive list of shaders that already come with Unity.
8:23
So yeah,
8:25
also in 90%,
8:23
80% of the cases,
8:28
you'll just use the built-in Unity shaders and that will be completely fine
8:32
as well.
8:34
And what is the structure of this Unity project in terms of,
8:40
again,
8:41
I'm not familiar at all with how games are structured.
8:45
If this was not a game,
8:47
it will be like a series of modules and different things.
8:52
SPEAKER_1: How does it look like in your case?
8:54
SPEAKER_1: How do you think of it?
8:56
There are different resource types,
9:00
so everything's just data blocks,
9:03
right?
9:03
SPEAKER_0: But the question is in which data blocks do you organize your game?
9:06
Unity,
9:07
the main organizational structure you put everything into is scenes.
9:13
So scenes are essentially,
9:16
I would say levels,
9:18
so this is our level select area,
9:21
but we also have scenes for other levels.
9:26
SPEAKER_0: This here is the second level rush time, which currently has art colors.
9:33
SPEAKER_0: Hold on.
9:33
SPEAKER_0: Color miniature.
9:36
SPEAKER_1: Oh, I remember this level.
9:38
SPEAKER_0: Yeah, this is how it looks usually.
9:39
SPEAKER_1: It's also one of the bonus levels when they keep coming up.
9:44
SPEAKER_0: Yep.
9:48
SPEAKER_0: Where was it exactly?
9:49
And then within scenes,
9:51
you have a number of objects or I'm sorry,
9:55
if I screw up the terminology a little bit there.
9:59
SPEAKER_0: I think maybe instances would be the correct way word, right?
10:04
SPEAKER_0: Instances of specific objects.
10:06
Everything is organized into these game objects and then every game object
10:11
can have scripts attached to it.
10:15
So for example,
10:16
if we check out our castle center here,
10:19
you can see that's a castle center game object and then it has a couple of C#
10:25
scripts attached to it.
10:26
And these C# scripts,
10:28
they're all mono behaviors,
10:31
so they inherit from the mono behavior class.
10:35
And mono behaviors are essentially just the type of object that you can
10:39
attach to game objects.
10:43
And then that's where you define how it behaves,
10:48
states,
10:49
those kind of things.
10:50
SPEAKER_0: Yeah, I opened one up for example purposes here.
10:54
SPEAKER_0: We can see how one of those mono behaviors would look like.
10:59
SPEAKER_0: Don't judge our code too harshly.
11:01
SPEAKER_0: Maybe we'll talk about this a bit later on.
11:04
SPEAKER_0: Game developers tend to write very horrific spaghetti code at times.
11:11
SPEAKER_0: But yeah, this is roughly how it looks like.
11:16
SPEAKER_0: Just have logic in there.
11:18
SPEAKER_1: But let's talk about this.
11:19
SPEAKER_1: So you consider this spaghetti, first of all, why?
11:24
SPEAKER_1: How would you critique your own code?
11:26
SPEAKER_1: Which actually the game works really well from the outside, right?
11:29
SPEAKER_1: We're looking in the inside right now.
11:35
So before we started recording,
11:37
I mentioned something of writing unit tests or whatever.
11:42
SPEAKER_0: Indie developers, we don't do that at all.
11:46
SPEAKER_0: We debug our code with debug prints.
11:53
SPEAKER_0: It's just very much a mess sometimes.
11:55
SPEAKER_0: I would even say we are not even close to the worst offenders.
11:59
SPEAKER_0: I have opened game projects in the past.
12:02
SPEAKER_0: They were insane spaghetti.
12:05
SPEAKER_0: You can't even imagine.
12:07
And the surprising thing,
12:09
this often also happens with very popular and good games.
12:14
I don't want to throw anybody under the bus here,
12:15
but I know a couple of games that are very,
12:18
very popular indie games where I know for a fact that they also have pretty
12:23
horrific spaghetti code under the hood.
12:26
SPEAKER_0: But yeah, apparently it's not really stopping the success of games.
12:31
SPEAKER_0: So if it works, it works.
12:33
SPEAKER_0: That's sort of the philosophy here.
12:36
Well that's the thing because the reason you cannot really get away of not
12:40
having unit tests at inside or let's say a hundred person engineering team
12:45
that is building a distributed system,
12:47
let's say a large real website or mobile app or something like that.
12:51
SPEAKER_1: It's because of maintainability.
12:54
SPEAKER_1: What would happen if you did that?
12:56
I mean you can do it,
12:57
but then people are going to make code changes and there's going to be bugs and
13:00
customers will be upset because suddenly what they used to use does not work.
13:05
So I'm kind of curious,
13:07
if you're on unit test,
13:08
will take you a bunch of time,
13:10
what would it give you?
13:11
SPEAKER_1: What would it give you?
13:12
SPEAKER_1: Anything?
13:12
Because if it doesn't give you anything,
13:13
it's the right thing that you're doing,
13:15
honestly,
13:15
right now.
13:16
You shouldn't apologize for it because in the end,
13:20
I feel you're looking to meet your goals,
13:23
which is build a game that is fun and it works and it's great,
13:26
those kind of things.
13:28
SPEAKER_0: Yeah, I think you're right.
13:29
SPEAKER_0: I think it's very much a scale thing.
13:31
I think stuff like unit test and so on,
13:33
they become very important at a certain scale and I think most indie games,
13:38
they operate under that threshold where you can get away with a lot of these
13:43
messy things.
13:45
The thing is also,
13:46
as you keep scaling these indie games bigger and bigger,
13:49
a lot of these things start biting you in the back more and more the further you go.
13:55
But if you don't scale to a super large level,
14:00
it's kind of okay,
14:01
you find workarounds and so on,
14:03
workarounds for your own screw-ups.
14:07
So this leads me to a pretty good question,
14:11
which is the reason we even talk about tests and software engineering is,
14:16
it's not about the test,
14:16
right?
14:17
SPEAKER_1: It's about wanting to avoid regressions.
14:19
SPEAKER_1: When you're making changes to the game, how do you test it?
14:24
How did you make sure that when you released it,
14:27
this actually worked as expected?
14:29
SPEAKER_1: And clearly the answer is not unit test.
14:31
SPEAKER_1: So I'm just really curious of and what did you need to test?
14:35
SPEAKER_1: Right?
14:35
I feel a lot of things,
14:36
especially in your game,
14:37
it's kind of hard to test,
14:38
right?
14:39
SPEAKER_1: Okay.
14:39
There's obvious things which is the characters not colliding weirdly or I
14:44
don't know.
14:45
SPEAKER_1: But there's also the thing of does it kind of work as you think it would?
14:49
SPEAKER_1: Which sounds hard to test.
14:53
Yeah,
14:53
so I think one of the advantages that comes with modern game engines is that
15:00
they also do a lot of the fixing on their end.
15:03
So you can usually be relatively certain that if it works on your machine,
15:07
it will likely also work on other machines.
15:10
SPEAKER_0: So that is a luxury that we have nowadays.
15:14
But then obviously there can also be issues and bugs in the stuff you write yourself.
15:19
And the way to catch that is first of all to test it rigorously yourself,
15:27
but you're not going to catch everything that way.
15:29
So then before you release,
15:31
you usually test it with a group of beta testers and they're going to catch
15:38
even more,
15:38
but also not everything.
15:39
And then you fix the rest once it's released,
15:42
because then you essentially have thousands and thousands of real life testers.
15:48
And honestly,
15:50
that's the only way to find all of the bugs or at least all of the ones that matter.
15:58
So going back to the coding environment and the development environment in Unity,
16:03
I've seen a some of your videos where you actually share what your game
16:07
development process looks like,
16:08
which is really cool.
16:09
We'll link it in the show notes below so viewers can also,
16:12
and listeners can also check it out.
16:15
SPEAKER_1: How does your workflow look like?
16:18
Because I've seen a lot of visual editing happening in Unity,
16:21
then sometimes you switch to make some code changes with I guess what you've
16:28
shown with mono objects and so on.
16:32
SPEAKER_1: Can you share how you jump in between these things?
16:37
Are you more in the visual side of things in the UI or more of the code or can you
16:42
even say how this splits?
16:45
SPEAKER_1: Does it even make sense?
16:48
SPEAKER_0: It depends what you're currently working on, right?
16:50
If I'm building a new level,
16:52
then I spend most of my time right here in the Unity editor view and I kind of
16:58
move rocks around like so,
17:00
I'm like,
17:00
"Oh,
17:01
herewillbeaniceplaceforanotherrock."
17:04
Or if I make a new level,
17:07
then I take these giant shapes here and kind of bend them into place.
17:17
SPEAKER_0: I'm like, okay, I want the level to maybe go this way, that way.
17:22
But then obviously,
17:23
there are other times where for example,
17:25
you work on enemy designs.
17:27
SPEAKER_0: That is also something you can do in Unity.
17:30
SPEAKER_0: Let me bring up one of the enemies real quick.
17:37
And you also have those big bosses that's in of some levels,
17:40
not all of them.
17:43
SPEAKER_0: Exactly.
17:44
SPEAKER_0: This is called a prefab.
17:48
So prefab is essentially like a blueprint for a foreign object you can put in
17:53
your scenes.
17:54
SPEAKER_0: You always want all of the archers to be the same.
17:58
So if I edit my archer here,
17:59
then it will update on all of the scenes,
18:01
just pretty useful.
18:05
And then there are other times where if you work on the visuals,
18:08
then you would probably do so in Blender.
18:14
SPEAKER_0: So Blender is very nicely integrated with Unity.
18:18
SPEAKER_0: If I update anything in the Blender...
18:20
SPEAKER_1: So this is a Blender, it's the 3D editor, if I put it in a simple way.
18:27
SPEAKER_0: Exactly.
18:27
Blender is slowly becoming industry standard for everything around 3D
18:35
modeling and so on,
18:36
because Blender is very good.
18:38
SPEAKER_0: It's a massive, massive program.
18:40
There are tons and tons of things you can do with Blender,
18:42
but one of the things you can do with Blender is also just making simple 3D
18:45
models and that's what we use it for.
18:48
So you can see in this Blender file we have most of our 3D models from our towers
18:54
and so on,
18:54
so forth.
18:55
So whenever I need a new model or when Paul needs a new model,
18:58
then we just go in here and make it different levels of buildings.
19:03
SPEAKER_0: Here we can see parts of one of the bosses and then the parts of...
19:10
SPEAKER_1: Is that lake boss?
19:11
SPEAKER_0: Yeah, exactly.
19:12
And you see it's not fully assembled because I only make every part of the boss
19:18
here once,
19:19
all of the teeth in the engine just route over together.
19:22
And then you put it together with code later or in the editor you just use these parts.
19:29
SPEAKER_0: Exactly.
19:29
SPEAKER_0: I can see if I can find it maybe.
19:36
Small spoilers ahead for everybody who hasn't played the game,
19:38
but I think it should be fine.
19:41
SPEAKER_1: I don't think it's that much spoilers.
19:43
Just because you know how it looks,
19:44
you're not going to know how it actually...
19:47
That's a pretty nasty boss.
19:50
SPEAKER_0: I can see it's...
19:50
SPEAKER_1: And the behavior.
19:52
SPEAKER_0: Sitting under the surface.
19:55
SPEAKER_1: Oh, there it is.
19:55
So throughout the whole game,
19:55
it's rendered there just you don't see it because...
19:58
SPEAKER_0: No, it's not rendered.
20:01
Usually it's turned off and then once it appears,
20:04
it turns on and yep,
20:06
it's assembled in the editor.
20:09
So it's not like you manually have to enter the coordinates of everybody,
20:12
part or whatever.
20:13
So you assemble it in the 3D view here,
20:18
but this spot in particular has procedural animations.
20:22
SPEAKER_0: So this one is actually animated entirely with C#.
20:26
SPEAKER_0: There's also an animator, but this boss doesn't use it.
20:32
SPEAKER_0: This has what you call procedural animations.
20:39
SPEAKER_1: Nice.
20:40
And then for the whole project,
20:42
can you give a sense of the size of the project?
20:45
Often it's not a good measurement,
20:47
but when we talk about a back-end service,
20:51
we would say,
20:52
"Okay,
20:52
here'showmanylinesofcodeitis."
20:53
Just to give a sense because a million,
20:55
it's hard to maintain a thousand line.
20:57
SPEAKER_1: That's pretty trivial.
20:59
Do you have a sense of how big the game is in terms of number of assets,
21:03
lines of code?
21:05
How would you kind of quantify it when you talk with fellow indie game devs to
21:09
give them a sense of,
21:10
okay,
21:11
how complex this game is really?
21:15
I think there's honestly no good measure that comes to mind because there are
21:21
certainly pure data sizes is not that great of a measure because there are
21:26
certain types of assets that disproportionately screw up that number.
21:31
For example,
21:32
textures and zones are very,
21:34
very big,
21:36
whereas 3D models and code is not big at all.
21:41
But then also lines of code is also not a perfect measurement because
21:45
oftentimes it's not your own code.
21:49
SPEAKER_1: True.
21:49
SPEAKER_0: Oftentimes it's third-party tools and so on.
21:52
SPEAKER_0: That's very difficult.
21:55
So if you want to know,
21:56
I think the game itself,
21:57
Thronefall itself is very,
21:59
very small game.
22:00
SPEAKER_0: I think it's maybe a hundred, 200 megabytes at most.
22:03
SPEAKER_1: So that's the download size, right?
22:05
SPEAKER_0: That's the download size.
22:06
SPEAKER_0: And the reason for that is that we don't have a lot of textures.
22:11
SPEAKER_0: We basically have this flat shaded style.
22:14
We have maybe a water texture and a little bit of a grainy ground texture to add
22:18
a little bit of noise there.
22:19
SPEAKER_0: But that's pretty much it.
22:21
And as mentioned,
22:22
the 3D models,
22:23
all of the 3D models are tiny,
22:25
all of the C# code is pretty tiny,
22:27
so that's why Thronefall isn't that big.
22:29
The biggest thing in Thronefall is probably the music and the sound effects.
22:34
SPEAKER_1: Did you also create that?
22:35
SPEAKER_1: Who created that?
22:35
SPEAKER_1: Or did you buy it or did you have someone help?
22:39
SPEAKER_0: The music is something I made myself and the sound effects.
22:43
SPEAKER_1: Really?
22:45
Yeah,
22:45
you have to wear a lot of hats as a game developer,
22:48
but that's also what makes it fun.
22:51
SPEAKER_1: The music is really fun.
22:53
SPEAKER_1: Did you create music before or did you just do it just for this game?
22:57
SPEAKER_0: I created music before.
22:58
SPEAKER_0: I also made the music for Will You Snail?
23:02
SPEAKER_0: as well.
23:03
SPEAKER_0: And I've been making music for a long time.
23:05
SPEAKER_0: It's one of my hobbies, my little side hobby, so I get to use that there.
23:11
SPEAKER_1: Okay, so now I'm going to think of it a bit differently when I hear it.
23:15
SPEAKER_1: It's a boujee too.
23:17
SPEAKER_1: I like it.
23:20
SPEAKER_0: So just to give you an idea of how big the assets folder.
23:24
So the assets folder is basically where you put all of the things you need.
23:28
SPEAKER_0: That's 2.23 gigabytes.
23:34
SPEAKER_0: But as I mentioned, the final game is a lot smaller.
23:37
So I think Unity,
23:39
just everything that's not needed for the final build is scrapped.
23:42
SPEAKER_0: A lot of the things are compressed and so on.
23:44
And in the assets folder,
23:45
everything is basically in uncompressed format,
23:48
so that's why it's quite a bit bigger.
23:51
I have an interesting question that I think as non-games developers would be
23:56
interested in.
23:57
SPEAKER_1: What do you use for source control and code review?
23:59
SPEAKER_1: Or do you do either?
24:01
I'm sure you do some sort of source control,
24:02
but I'm not sure about code review.
24:05
SPEAKER_0: So code review, I'll give you the standard answer.
24:12
SPEAKER_0: What is code review?
24:13
SPEAKER_0: What do you mean?
24:14
SPEAKER_0: What are you talking about?
24:17
SPEAKER_1: Standard game developer answer, right?
24:24
Yeah,
24:24
I'm sure most developers know what it is,
24:26
but at indie scale,
24:27
it's one of the things.
24:30
Honestly,
24:31
I think it would be very beneficial to do code review,
24:38
although I think it's getting easier because you can basically copy paste
24:41
your code into ChatGPT and then if you're at the very least at the dummy level
24:47
of most game developers,
24:49
myself included,
24:50
then usually you'll get some very good recommendations from that.
24:55
We will probably make the project a lot easier to work with in the long run.
24:59
SPEAKER_0: I agree.
25:00
But for some reason,
25:03
it's not something most developers are excited about.
25:05
Most developers are excited about,
25:07
"Iwantthisnewenemytofinallywork."
25:09
So we hack it in as quickly as possible where we're not like,
25:12
"Oh,
25:13
let's review the code for this enemy to see if there are some more efficient
25:16
waytodoit."
25:17
SPEAKER_0: That's just not the way we think at all.
25:19
SPEAKER_1: But don't get me wrong, I'm not judging you at all.
25:22
SPEAKER_1: Seriously.
25:23
SPEAKER_1: You and Paul have built this awesome game.
25:26
SPEAKER_1: I love playing it and I'm more interested in how you're doing it.
25:29
And when you're saying you're not doing something that larger teams would do
25:34
or teams who are not building games would do,
25:36
I don't really see that as a negative.
25:37
I see it as like,
25:38
look,
25:38
this works for you and I think it's actually a great testament that there is no
25:43
one practice that,
25:45
I don't know,
25:45
can help guarantee creating something great because objectively,
25:50
again,
25:51
I don't know,
25:52
I'll just from my perspective,
25:53
this game is great and it is just cool to see how it was done.
25:56
And I'm assuming if you would've taken some of these things,
26:00
you might've slowed yourself down for no particular reason and maybe just
26:04
got demotivated midway and get into fight and quit and not finish the game.
26:09
Yeah,
26:09
I guess the reason why I'm pointing all of this negative practices to just
26:14
make it clear that we know it's not ideal.
26:17
Because I know a lot of engineers who will be watching or listening to this and
26:21
I know especially on the engineer side of the spectrum,
26:27
I would say there are sometimes some judgmental looks about some of the
26:33
things we do.
26:33
SPEAKER_0: Like for example, the next thing you asked is source control.
26:38
And one of the next horrible things we do is we immediately just push
26:43
everything to the main branch.
26:46
SPEAKER_0: We push everything to main.
26:48
Sometimes I've seen people make a little shocked Pikachu face about that and
26:53
I'm even like,
26:53
"Oh,
26:54
is that not normal?
26:55
SPEAKER_0: I thought everybody would do that."
26:56
SPEAKER_0: Apparently not.
26:59
SPEAKER_0: Maybe you can tell me how that is usually done on bigger projects.
27:02
SPEAKER_1: Well, don't forget that.
27:03
I think there's a huge difference between what you're doing,
27:06
which is building a game that you and Paul are using it and at some point you
27:11
push out a beta and what it means to push to main at a lot of,
27:14
at a distributed system or at Uber for example.
27:17
So if at Uber you push to main,
27:19
that code will automatically get deployed.
27:21
If it's a web service,
27:22
it'll get deployed to a service and it will be used by every single user of Uber,
27:26
whoever uses that service.
27:27
If it's a tiny service that's,
27:28
I don't know,
27:29
running in Portugal in one city because we have services like that,
27:32
that's not a big deal but if it's running everywhere.
27:35
So the reason it's frowned upon to just push to main without a review is you can
27:40
break everything but you're not shipping your code.
27:43
SPEAKER_1: When you push to main, it's not updating on Steam every single time.
27:49
Because I feel this is a big difference between game development and more
27:54
SaaS backend development,
27:57
is you ship very infrequently,
27:59
which means a lot of these practices you probably don't need,
28:02
by the way.
28:02
SPEAKER_1: I think for any listeners listening, I think it's worth challenging.
28:07
SPEAKER_1: You're thinking what the context is.
28:10
And I'll give you one more example of,
28:12
I heard a team at Apple do this thing called post commit code reviews.
28:18
So they don't do code reviews,
28:19
but then once someone commits,
28:20
they're a larger team,
28:21
they look at it and they give comments,
28:23
but they can also do that because they ship once every six months.
28:29
And also for any game developers listening,
28:31
I think it's just worth thinking that these things that you hear,
28:34
practices good or bad,
28:36
it might not apply to your context.
28:38
And this is one of the reasons I was so excited to talk to you is just to see how
28:43
you built this and what worked for you.
28:45
And we're not saying this is going to work for everyone,
28:47
but I have a feeling if someone wants to build a successful game and with a
28:52
small team,
28:53
it's worth paying attention to what you're doing because you clearly have
28:57
found something that works for you.
29:00
SPEAKER_0: Yeah, I see the point.
29:02
SPEAKER_0: I see the point.
29:03
I think the game not being in a functional state pretty much all the time is
29:09
something that can pretty annoying even in relatively small teams.
29:12
I think in a team of two,
29:14
it's still kind of fine,
29:15
although we pay attention to keep the game in a functional state with every commit,
29:20
but this is something that I think I resonate with and that can get a problem
29:26
very quickly even in smaller teams is that if everybody just pushes
29:29
everything to main and even pushes unfinished stuff and so on,
29:34
then it becomes very annoying because whenever you try to play and test the game,
29:38
it's basically not in a functional state because some system is always work
29:42
in progress are broken.
29:44
SPEAKER_0: That is very annoying.
29:46
SPEAKER_0: I will say that.
29:47
That is very,
29:47
very annoying and that sort of stuff can happen sometimes when you work with,
29:55
I don't know,
29:55
less experienced people or people that you're not as much in the groove with.
30:00
SPEAKER_0: For Paul and I, I think this wasn't a big issue at the beginning stage.
30:03
Of course sometimes the game wasn't in a functional state,
30:05
but then once it's functional we pretty much always try to keep it functional
30:10
so then that whenever the other person wants to test it or run something that
30:14
it's always working and very runnable.
30:19
So one topic that I just wanted to touch on while you still have your editor
30:23
open is the kind of fun aspect.
30:25
One thing that struck me as something that I just didn't think about as a
30:29
software engineer is the art,
30:31
the fun.
30:32
And clearly when I played with this game,
30:34
and I played with this before we met,
30:36
in fact I reached out to you after I played with the game and I realized it's a
30:39
tiny team and I thought maybe we could get some behind the scenes,
30:42
which I'm very happy we're doing.
30:45
SPEAKER_1: Games need to be fun.
30:46
I like this game and I tell people that it's a great use of my time because it's fun.
30:52
Now you showed me that you're living your days,
30:55
a lot of it inside Unity,
30:57
inside the C#,
30:58
but there's only two of you.
30:59
How do you balance the...
31:01
Who is kind of the chief fun officer who makes sure that whatever you build,
31:05
it has that kind of fun jazz and feel to it?
31:09
How do you balance with all this coding and design work,
31:12
which doesn't seem like all that fun?
31:17
SPEAKER_0: So once again, there are different phases.
31:19
During the prototyping phase,
31:21
I would say we were both equally responsible for that.
31:23
As mentioned,
31:24
Paul was for example,
31:25
the one who came up with the initial concept and prototype.
31:29
But then once the concept is set into stone,
31:31
the way we split it for this project is that I was the one responsible of
31:38
gameplay and Paul was like UI art and so on.
31:42
So I was the one who tried to make everything fun and then Paul did basically
31:48
quality check my decisions and was like,
31:51
"Yeah,
31:52
thisisindeedfun."
31:52
Or for example,
31:54
in the beginning,
31:55
I wanted to balance the economy a bit differently,
31:59
make it a bit balanced,
32:00
and a bit slower.
32:00
SPEAKER_0: And Paul was like, "Yeah, this doesn't feel too great.
32:04
SPEAKER_0: I want more gold from my buildings and less gold from the enemy."
32:07
SPEAKER_0: So I rebalanced it a little bit according to his feedback.
32:11
So essentially I worry about that first and then Paul checks it to make sure
32:15
that I don't do some nonsense in that regard.
32:20
And how important was feedback from the players,
32:23
the beta testers,
32:24
the early access testers?
32:27
I'm trying to get to the point of I feel there's two thoughts of creating great
32:31
games or creating great products in general.
32:34
SPEAKER_1: One is listen to your customers.
32:37
SPEAKER_1: They know what they want and take a lot of their feedback.
32:39
SPEAKER_1: Not all of it, but a lot of it.
32:40
SPEAKER_1: And the other one is like, nope, don't do any of that.
32:42
SPEAKER_1: Do Steve Jobs.
32:44
SPEAKER_1: Decide what you're going to do.
32:45
It's going to be great,
32:47
push through and then eventually people will come around.
32:50
SPEAKER_1: Do you sit in any of these ones?
32:52
SPEAKER_1: How do they deal with the feedback?
32:54
SPEAKER_1: What was the feedback even?
32:57
Yeah,
32:57
so the way we do it is we gradually increase the number of playtesters.
33:03
So we started with a closed circle of handpicked people that we trust and we
33:09
got our first round of feedback from that.
33:11
Then we expanded it to a little bit of a bigger circle with a couple more open testers.
33:16
And then eventually once we were in early access,
33:20
there was essentially a very big testing phase with lots,
33:24
and basically everybody who bought the game is suddenly a tester.
33:28
SPEAKER_0: And the feedback was very, very important.
33:31
For example,
33:32
at the very beginning when we started making the game,
33:35
there were no building upgrades or no building choices at least.
33:41
So for everybody who doesn't know the game,
33:44
I'll quickly show some context here,
33:47
if this starts up,
33:50
come on.
33:51
SPEAKER_1: Let's give it a little time.
33:57
So oftentimes,
33:57
when you build these buildings,
34:00
you get to choose between different upgrades and this was something that was
34:04
just not the case in the first version of the game.
34:07
SPEAKER_0: And this was also something that we didn't plan for.
34:09
SPEAKER_0: This was not in our initial design.
34:12
SPEAKER_0: This was not something that we planned to do.
34:14
But then because playtesters,
34:17
the very early,
34:18
the first round of playtesters reported back to us that it's a little bit too
34:24
little choice and it doesn't really feel like you're building your own base
34:27
or you're building everything on these predefined build slots anyway.
34:31
SPEAKER_0: In Thronefall, you can't build buildings for everyone.
34:33
SPEAKER_0: You have to build on these predefined slots.
34:37
And that combined with the fact that you can't even choose,
34:40
you can't even customize the buildings,
34:42
it felt a bit too rigid to people.
34:44
SPEAKER_0: And we reacted to that feedback by implementing these upgrade choices.
34:50
So now you have a lot more choice and a lot more options to customize your base.
34:56
And then in the end,
34:57
once your base is fully built out,
34:59
even though the layout is predefined by us,
35:01
it still feels like your own because you got to customize and choose a lot of
35:07
different things here.
35:08
SPEAKER_1: But then you do have some mini games.
35:10
SPEAKER_1: Interesting enough.
35:10
After you complete the scenario,
35:12
I played with all the...
35:13
Because I completed all the quests on easier,
35:17
and then there's the mini games.
35:19
And in some mini games,
35:19
you actually have this where you cannot choose,
35:22
you can only build,
35:23
you can choose if you build,
35:25
it's a minor yay or nay,
35:26
and then that's it.
35:27
So did that come from keeping some of the mini games,
35:30
some of the earlier versions?
35:33
Honestly,
35:33
the mini games is where I just go wild as a designer and I'm like,
35:42
you often have a lot of untapped potential in your game systems where it's like,
35:48
I have all of these cool systems here.
35:49
SPEAKER_0: There are 10 different games we could have built with these systems.
35:53
SPEAKER_0: You have the unit movement and the combat system and all of that.
35:57
And often it's a little bit of a shame that you're not exploiting all of the
36:03
possibilities you have.
36:04
So the mini modes,
36:06
like the little bonus modes for me,
36:08
they're just a way to exploit a couple more of the possibilities we have with
36:14
the systems that we've already built.
36:15
So for example,
36:16
there's also one mini mode where your character turns into a snowball.
36:21
SPEAKER_1: I was about to say that.
36:23
SPEAKER_1: That was my favorite.
36:25
SPEAKER_1: I couldn't complete it.
36:26
SPEAKER_1: So I don't know how you do the difficulty settings, but I failed.
36:31
SPEAKER_1: I did the first, all the ways, but the last one I just cannot do it.
36:34
SPEAKER_1: It's just this tiny ugh.
36:36
I'm sure if I could practice more,
36:37
which is by the way,
36:38
one more question to those of us who do not build games,
36:42
but were wondering how you do,
36:43
how do you tweak the difficulty to feel right?
36:47
SPEAKER_1: Again, I'm not a huge gamer, but I do play every now and then.
36:51
SPEAKER_1: It felt right to me.
36:51
SPEAKER_1: It was challenging.
36:53
SPEAKER_1: I had to restart some levels, but I could finish it.
36:55
And then some of the mini games,
36:56
they're giving me grief,
36:57
I just cannot finish them,
36:58
which I guess is kind of fine,
37:00
because I'm not that good of a gamer.
37:04
SPEAKER_0: Yeah, the mini games, they are very hard.
37:08
SPEAKER_0: They're like, we...
37:09
SPEAKER_1: You're making me feel better.
37:10
SPEAKER_1: Thank you.
37:11
SPEAKER_0: They're very, very hard.
37:13
In the beginning,
37:14
we put the mini games right next to the levels where more people played them
37:17
and yeah,
37:20
people did not like them because of their difficulty.
37:22
SPEAKER_0: So we got demolished.
37:24
SPEAKER_0: So now we hit them away a little further.
37:27
So not as many people play them anymore,
37:29
and they're clearly identifiable as end game content,
37:33
but you can obviously imagine people jumping into those mini modes before
37:36
even finishing the game.
37:37
SPEAKER_1: That's a bad idea.
37:39
SPEAKER_0: Bad idea, bad idea.
37:44
SPEAKER_0: So arguably, they're a bit too difficult.
37:47
But that's because the mini modes for me are an outlet to make some of the crazy
37:51
things that I find fun.
37:53
And that's one of the problems you also always have as a developer,
37:57
is that you're usually quite a lot better than the average player who will
38:03
play your game.
38:04
So whenever I balance levels or whenever you balance levels,
38:10
you have to make it so they essentially feel stupid easy.
38:14
SPEAKER_0: So most of the levels in Thronefall, they're so easy.
38:18
The best players in Thronefall,
38:21
they can finish most levels with only the king without building a single building.
38:26
SPEAKER_1: Really?
38:27
SPEAKER_0: Yeah.
38:28
SPEAKER_0: That should tell you...
38:30
SPEAKER_1: Okay.
38:30
SPEAKER_1: Now you're making me feel bad.
38:32
It doesn't work with every level,
38:33
but in a lot of levels,
38:35
certainly I think the first three or so,
38:37
certainly the Ice Boss and zone you can beat with just the king.
38:41
SPEAKER_0: No buildings.
38:44
SPEAKER_1: Well, you can do that as a developer and pro gamers, yeah.
38:49
SPEAKER_0: Yeah, I'm not sure I can do that.
38:51
SPEAKER_0: I've seen people do that.
38:52
Going back to that question,
38:53
as a developer,
38:54
do you just get this feel of what a good difficulty is for a game that will
38:59
actually be sold and people will enjoy it,
39:02
people like me,
39:03
people like the casual gamers who are people who are buying it,
39:07
or do you get it from the feedback?
39:10
SPEAKER_1: Because it feels like this is a really big difference, right?
39:13
You're so much better,
39:16
but yet you need to produce something that will,
39:18
I don't know,
39:19
I guess be fun and enjoyable for the general public.
39:26
SPEAKER_0: Yeah.
39:27
One thing that a lot of people forget about balancing is that first of all,
39:31
you need to make a game that is balanceable and easy and somewhat reasonable
39:36
to balance.
39:37
The problem with strategy games like Thronefall is that they are very,
39:42
very,
39:43
very snowbally.
39:44
SPEAKER_0: And snowbally means that if you're ahead, you get further ahead.
39:48
SPEAKER_0: If you're behind, you get further behind.
39:50
So that's why games like Thronefall and strategy games in general,
39:53
they have a tendency to feel very frustrating very quickly because if you
39:57
fall behind a new economy,
39:59
then it becomes exponentially more difficult.
40:02
SPEAKER_0: You're never going to be able to catch up again.
40:03
Whereas on the other side of the spectrum,
40:05
if you get ahead and you get exponentially more and more money every round,
40:09
then suddenly it's going to feel way too easy.
40:12
And this was one of the main problems I had when balancing Thronefall is just
40:15
this runaway dynamic of it all that either it feels way too easy or it feels way
40:21
too difficult.
40:23
And I didn't really find a perfect way to deal with it in Thronefall that one
40:29
way I actually try to counteract this is by making enemies drop gold.
40:33
That was also something that wasn't always the case from the very beginning,
40:37
but I very quickly realized that we need that because the economy you build
40:43
yourself with all of these houses,
40:45
there are too many runaway effects with it.
40:49
So the enemies dropping gold basically smoothes that curve out a little bit
40:53
and makes it so that I can predict a bit more how much gold you're going to have
40:56
at which point in time.
40:59
So you're saying that you made it that the enemies might drop more gold when
41:03
you're sensing you're actually doing some smart calculations or no?
41:08
SPEAKER_0: There's no shenanigans going on like that, but it's just math.
41:13
If the enemies in wave 10 drop 50 gold,
41:19
then I just know you're going to have at least 50 gold and that makes it...
41:22
SPEAKER_1: Got it, got it, got it, got it.
41:23
Makes it easier to balance than trying to predict how many houses you're
41:27
going to have and so on,
41:28
so that.
41:29
SPEAKER_1: Oh, I understand.
41:30
SPEAKER_0: Yeah.
41:33
SPEAKER_1: So after you build this game, you've now ported it to Nintendo Switch.
41:36
SPEAKER_1: What did that porting look like from a technical perspective?
41:38
SPEAKER_1: Did you do the porting?
41:40
SPEAKER_1: Did someone else do the porting?
41:44
We outsourced the porting to Warp Digital,
41:51
and that's all of the three games I made so far are available on Switch.
41:56
SPEAKER_0: Islanders was ported by CodeSync.
41:59
SPEAKER_0: Will You Snail?
42:00
was ported by No Gravity Games and this one was now ported by Warp Digital.
42:03
SPEAKER_0: So this is the typical way I go about it.
42:06
SPEAKER_0: I just give it to somebody else and I'm like, "Please port this."
42:11
And the typical standard deal you do for these kind of things is you get a
42:16
revenue share.
42:19
SPEAKER_0: And other than that, you basically don't have to do anything.
42:22
SPEAKER_0: They take care of all of the publishing, they take care of the porting.
42:25
It's like completely hands-off and very free,
42:28
which is why if you have a successful game on Steam already,
42:31
it's pretty much a no-brainer to just give your game to one of these companies
42:35
because they're like,
42:37
"Okay,
42:38
we'll take care of everything and we'll just get a revenue share of what we
42:42
make."
42:43
I'm assuming they're used to taking,
42:44
especially if it's Unity C#,
42:46
running on this code base,
42:48
they'll take it,
42:48
they'll know how to change it,
42:50
they'll know all the performance issues,
42:52
etc.
42:52
SPEAKER_1: The testing, you said.
42:53
SPEAKER_0: Yeah.
42:54
That sounds a pretty sweet deal as a...
42:57
Well,
42:57
it's kind of a positive thing if you do make it to a successful...
43:00
And I guess,
43:02
am I wrong to assume that this makes it a bit more tempting as an indie
43:07
developer to start on Steam?
43:09
Because if you do well on Steam again,
43:11
it's kind of easy enough to find someone who you can strike a deal with this way.
43:17
SPEAKER_0: Yeah.
43:18
SPEAKER_0: Obviously Steam is the go-to place for indie developers anyway.
43:22
There's pretty much,
43:23
if you want to make indie games,
43:24
there's almost no way you're getting around Steam.
43:29
In most cases,
43:31
even if you have other platforms,
43:33
Steam will still be 90% of the revenue.
43:35
So anything you sell on Switch and especially on other consoles is more like a
43:40
little bonus on top what you're making on Steam.
43:44
SPEAKER_0: Steam is, I think by far the biggest market for indie games.
43:49
SPEAKER_1: Trust isn't just earned.
43:50
It's demanded,
43:51
whether you're a starter founder navigating your first audit or seasoned
43:54
security professional skill in your governance risk and compliance program,
43:58
proving your commitment to security has never been more critical or more complex.
44:03
SPEAKER_1: That's where Vanta comes in.
44:05
Vanta can help you start or scale your security program by connecting with
44:08
auditors and experts to conduct your audit and set up your security program quickly.
44:13
Plus,
44:13
with automation and AI throughout the platform,
44:15
Vanta gives your time back so you can focus on building your company.
44:19
Businesses use Vanta to establish trust by automating compliance needs
44:22
across over 35 frameworks like SOC 2 and ISO 27001.
44:27
With Vanta,
44:28
they centralized security workflows complete questionnaires up five
44:31
times faster and proactively manage vendor risk.
44:34
Join over 9,000 global companies to manage risk and improve security in real time.
44:39
For a limited time,
44:40
my listeners get $1,000 off Vanta at vanta.com/pragmatic.
44:43
SPEAKER_1: That is vanta.com/pragmatic for $1,000 off.
44:50
SPEAKER_1: You've been building games for a while.
44:52
SPEAKER_1: A lot of us listening have not built games, but we probably played games.
44:55
SPEAKER_1: I played Thronefall.
44:56
SPEAKER_1: I actually love the game.
44:58
It's just a great way to expend in 10 minutes,
44:58
20,
45:02
and then it turned into a few hours.
45:05
How did you get started with this,
45:07
starting from the idea and then what were the actual first steps and talking
45:13
about both yourself,
45:14
but you also had a co-founder or a co-developer?
45:18
Yeah,
45:18
Thronefall,
45:19
we made in a team of two,
45:21
and what I just talked about is a perfect gateway to how we started making
45:25
Thronefall because what we do in the very beginning is very much opening up
45:30
our search space very wide.
45:32
SPEAKER_0: We try out a lot of different ideas.
45:36
So this is what typically you call the prototyping phase where you make a lot
45:40
of different,
45:41
essentially mini games or prototypes where you try out different ideas and
45:47
that way,
45:47
you're basically making a bunch of measurements in the search space and just
45:51
looking which direction you find most promising and then you keep searching
45:55
in that direction.
45:56
SPEAKER_0: So that is pretty much exactly what we did for Thronefall.
45:59
We made a bunch of different prototypes in Unity,
46:02
just one or two days working on little mini games.
46:06
So we had one prototype about spreading flowers,
46:10
we had a climbing prototype,
46:14
we had a card game and all sorts of different things.
46:19
And then after exploring some of these ideas a little deeper,
46:23
some of them we scrapped instantly.
46:25
We slowly honed in on what we wanted to make and it just turned out to be Thronefall.
46:31
SPEAKER_0: I don't know how exactly we arrived there just in this specific case.
46:36
And when you say you're exploring them,
46:39
is it just you kind of building this mini prototype game and then just playing
46:43
around with it,
46:44
seeing how it feels,
46:45
showing it to your friend who's also working on it and just bouncing ideas?
46:51
SPEAKER_1: Is that kind of how it is?
46:52
SPEAKER_1: Or can you help us imagine, how does this phase look like?
46:56
So the one challenge that you face a little bit is that you need to find a
47:01
compromise between something that you want to make and something you think
47:06
that will sell,
47:07
and that's one of the main challenges.
47:10
First of all,
47:11
finding something that will sell is already difficult enough by itself,
47:14
but then finding something that will sell that you also like to work on,
47:18
that is fairly tricky.
47:22
So the way you approach it is usually you just make a lot of things that you can
47:27
imagine working on that you're kind of interested in,
47:30
and then you are trying to measure or guess how well it would do on the market.
47:36
And then you move forward with the ideas that you think are most promising.
47:42
SPEAKER_0: How exactly it looks like.
47:45
I come here in the morning,
47:46
I sit down,
47:47
I open Unity,
47:48
I'm like,
47:50
"WhatdoIwanttomaketoday?"
47:52
I just come up with a random idea that I find interesting and I just make it.
47:57
The thing that I think that is important to realize is that you can make games very,
48:02
very quickly.
48:03
If you just want to make a simple prototype without any fancy graphics or
48:06
menus or whatever,
48:07
you can get that up and running super,
48:09
super quickly.
48:12
What takes the most amount of time is just polishing it up and bringing it to
48:15
production quality.
48:16
But if you just want to try out a random little idea,
48:19
you can mostly do that in one or two days.
48:21
SPEAKER_0: So that's what you just do repeatedly for let's say two months or so.
48:26
SPEAKER_0: Both I and Paul pumped out a bunch of prototypes.
48:30
SPEAKER_0: We show them to each other.
48:31
SPEAKER_0: We played each other's prototype.
48:32
We talked about them of course,
48:35
because through talking about them,
48:37
we try to figure out,
48:39
"Hey,
48:39
whichofthesecouldactuallydowellonthemarket?"
48:42
And also,
48:43
in a team you have...
48:44
That makes it even more important because you have another circle,
48:46
like what do I like working on?
48:48
SPEAKER_0: What does Paul like working on?
48:49
SPEAKER_0: So we have to find the overlap between all of those things.
48:52
SPEAKER_0: So that's why obviously talking about these prototypes is pretty crucial.
48:58
SPEAKER_0: And usually what you do is you do specifically gameplay prototypes.
49:02
So you start with gameplay and then only once you're sure what the gameplay is
49:06
going to be,
49:07
then you move on to visual prototypes where you basically repeat the entire
49:11
process that you did for gameplay for the visuals.
49:15
So you try out a bunch of different visual styles and see what you like working on,
49:19
what's efficient to make,
49:21
what do you think will do well in the market.
49:24
SPEAKER_0: That's really...
49:25
So specifically with Thronefall,
49:27
you said,
49:28
okay,
49:28
you had the prototypes and then you figured it out,
49:29
you're going to make Thronefall,
49:30
but what did that look like?
49:31
You kind of knew the concept that it will be this tower defense game with...
49:38
I'm putting it like that based on how I played with it,
49:42
or was it a lot more vague at that point still?
49:45
SPEAKER_0: So you go through different phases.
49:48
SPEAKER_0: When we started, we were very open.
49:50
SPEAKER_0: We have no idea what we want to make.
49:52
SPEAKER_0: We'll just throw anything out there.
49:55
As mentioned,
49:55
there were some completely wild things like a game where we're golfing flowers,
50:00
like a golf ball essentially.
50:02
SPEAKER_0: So some wild ideas.
50:06
And then at some point we narrowed down our search a bit further and we were like,
50:11
okay,
50:11
we want to make a minimalist game about building a kingdom.
50:16
SPEAKER_0: We're like, "Okay, the search is getting out of hand.
50:18
SPEAKER_0: There are too many options, decision paralysis.
50:22
SPEAKER_0: Let's focus down a bit more."
50:25
And then we made a bunch of prototypes that specifically had to do with
50:31
managing tiny kingdoms.
50:32
I made a turn-based game and I made a Plants vs.
50:37
Zombies-like game where there are hordes coming from the side and you shoot
50:40
them all down.
50:42
And Paul at some point,
50:45
just had this little mini game where you had a castle in the center and you had a
50:49
little figure that you could control around it,
50:54
and there were enemies going towards your castle,
50:57
and all you were trying to do is basically defend your castle by smashing on
51:01
the enemies.
51:02
SPEAKER_0: And it had a very nice rhythm to it.
51:05
There was the day phase where you could build new towers and mills that would
51:10
give you more coins,
51:11
and there was the night phase where you would defend your castle against
51:14
these enemies approaching.
51:16
SPEAKER_0: It was a very simple top-down 2D prototype.
51:21
SPEAKER_0: And yeah, when you see it, you see it.
51:26
SPEAKER_0: I don't know.
51:26
It was like we both immediately agreed that this was going to be the game we
51:31
were going to make because it was just ways ahead of all of the other
51:35
prototypes we've made so far.
51:38
So based on the kind of feeling and your understanding of like,
51:40
okay,
51:41
what could work actually.
51:44
SPEAKER_0: Yep.
51:45
SPEAKER_1: How long did it take to get here?
51:47
SPEAKER_1: You say you did every few days you did a prototype.
51:50
SPEAKER_1: So we're talking a few months into the prototyping phase-ish.
51:55
So I would say it depends on how big of a game you want to make,
52:01
but your prototyping phase should just scale proportionally.
52:04
So for example,
52:07
if you want to make a game in two years,
52:08
then maybe spend two months on prototyping.
52:11
If you want to make a game in a month,
52:13
then obviously only maybe spend two days or something.
52:16
SPEAKER_0: So yeah, you have to scale that proportionally.
52:20
And for us,
52:21
it took a little bit longer because we went into one debt and with a card game.
52:27
SPEAKER_0: We thought our kingdom management game is going to be a card game.
52:32
Then after about a month of development and me over-engineering a cool system,
52:39
we realized that's not it,
52:42
and we just scrapped it.
52:45
And then when this happens,
52:46
you've put in a bunch of work already,
52:48
months of work,
52:50
you just throw away the code or archive it and boom,
52:53
that's it?
52:54
SPEAKER_0: Yeah.
52:55
So honestly,
52:58
I was grateful that we noticed it all because in the worst case,
53:02
you develop the entire game.
53:03
SPEAKER_0: You spend two years and then you notice that doesn't work.
53:06
So whenever I notice relatively early that something doesn't work,
53:11
it's not like,
53:12
"Ah,
53:12
whatashame."
53:12
SPEAKER_0: It's more like, "Phew.
53:13
SPEAKER_0: We dodged a bullet there."
53:16
SPEAKER_0: It's more that feeling.
53:17
SPEAKER_0: So it's more a feeling of relief than anything else.
53:23
And then once you,
53:24
okay,
53:25
figure it out,
53:25
this is a concept,
53:26
this is a game that we're going to go.
53:29
SPEAKER_1: We're happy with the prototype and let's continue on.
53:32
SPEAKER_1: How do things look like from there?
53:34
SPEAKER_1: Because I assume that that's when things change, right?
53:36
SPEAKER_1: Did you start to do some sort of planning?
53:39
SPEAKER_1: Is it just more kind of keep building?
53:42
I'm kind of poking to,
53:44
at some point,
53:45
did you feel that you need to bring in more structure?
53:47
SPEAKER_1: You're still just two people.
53:48
You've already built two games,
53:49
so you kind of know what you're doing here.
53:51
SPEAKER_0: Yeah, exactly.
53:53
So as mentioned after the gameplay prototype,
53:56
we had another phase for the visual prototype because the visuals are also
54:00
very important,
54:02
and you repeat the entire process.
54:04
SPEAKER_0: You basically have the gameplay already done, and what you do is you...
54:07
SPEAKER_1: Sorry.
54:07
Can you just help me understand for the gameplay prototype,
54:11
what can we imagine?
54:12
Is it squares and circles moving around or super low fidelity versus the visual?
54:18
SPEAKER_0: Exactly.
54:18
The gameplay prototype is essentially what we call programmer art,
54:22
which is just a bunch of squares,
54:24
sand boxes with colors.
54:26
And for the art prototype,
54:29
what we do,
54:30
this is our process,
54:31
is we scrap all of the gameplay once again.
54:33
So it's not like we delete it,
54:36
but we start on an empty project without any gameplay whatsoever,
54:39
and we just build a scene without any logic.
54:43
SPEAKER_0: We just open my game engine and try to create a nice looking scene.
54:47
SPEAKER_0: It doesn't have any motion, doesn't have any logic.
54:49
SPEAKER_0: We just try to make it look nice.
54:52
And if you decouple the gameplay from the visuals,
54:56
you can move a lot faster in your visual prototype.
54:59
If you try to bring it all together immediately,
55:01
then you're not prototyping anymore,
55:03
you're just building the game.
55:05
So you open an empty project and you start messing around how things should
55:12
look like.
55:13
SPEAKER_0: You put little 3D models in there.
55:16
SPEAKER_0: You experiment with different camera scales, with different zoom levels.
55:20
And then we had a massive mirror board with tons and tons and tons of screenshots,
55:25
like hundreds of screenshots of different experiments we made.
55:29
And then you look at all of them next to each other and once again,
55:32
try to assess which of them look the best or the most attractive.
55:38
SPEAKER_0: And yeah, once we found something, we're happy there.
55:42
SPEAKER_0: Then we move into production.
55:44
And you're right,
55:44
that's exactly the point where you have to start getting a bit more organized.
55:51
SPEAKER_0: In a team of two, it's sort of fine.
55:54
SPEAKER_0: It's not like there's insane management overhead.
55:59
You only have to manage communication between two people,
56:02
which is fairly manageable,
56:03
I would say.
56:06
SPEAKER_0: So we just have to agree who works on what.
56:11
SPEAKER_0: So I usually do gameplay programming and content creation and balancing.
56:18
SPEAKER_0: So I write most of the gameplay logic.
56:22
SPEAKER_0: And then Paul is very good at basically user experience design.
56:27
So he writes a lot of the UI systems,
56:30
which is a surprising amount of work.
56:32
The UI system and all of that,
56:34
it's probably 40 to 50% of the work goes into that.
56:40
SPEAKER_1: But the UI, what is the difference between the UI and the gameplay?
56:44
So the UI is basically all of the overlays that you can click with your mouse,
56:49
like the settings menu and all of the different things that can pop up.
56:54
And then for the UI,
56:56
you have to make sure you can control it with the keyboard,
56:58
you have to make sure you can control it with the mouse,
57:00
you have to make sure you can control it with a gamepad,
57:03
it has to also look nice and so on and so forth.
57:06
SPEAKER_0: So it's a fairly, fairly massive task.
57:11
SPEAKER_0: But we shared gameplay programming, I would say 50-50.
57:14
SPEAKER_0: And then Paul did most of the UI stuff.
57:18
SPEAKER_1: Nice.
57:19
And then what was the point where you actually had a more traditional
57:23
schedule in place of like,
57:25
okay,
57:26
we now know what we're doing.
57:27
SPEAKER_1: We need to build the core engine, the levels, the different structures.
57:33
SPEAKER_1: I'm just throwing out stuff.
57:34
I don't know if this is how you actually structured it,
57:36
but I'd just be interested.
57:37
How did it look like when you're like,
57:38
okay,
57:38
we know roughly how this is going to go,
57:41
and obviously at what point could you even announce dates?
57:46
Because I just look back on the history and I saw when people were very excited
57:50
when they saw the first demos,
57:52
and of course what they asked is,
57:53
"When is it ready?
57:54
SPEAKER_1: When will it be out?"
58:00
So basically when you have the two prototypes,
58:02
if you have the gameplay prototype and the visual prototype,
58:04
then you know very precisely what you're going to make already.
58:09
SPEAKER_0: And then there are a couple of more questions that you have to answer.
58:12
So when we build the first level,
58:14
then we still have to answer questions of how do the actual enemies,
58:18
not the prototyping enemies,
58:19
how do the actual enemies look like?
58:21
SPEAKER_0: How do the actual units look like?
58:23
SPEAKER_0: How do they actually interact with each other?
58:25
SPEAKER_0: Which upgrades are there?
58:26
SPEAKER_0: So the search process definitely continues.
58:30
SPEAKER_0: You have to keep trying out different ideas.
58:33
But basically I would say the amount of communication between Paul and I that
58:37
was required gradually goes down over time.
58:40
In the beginning,
58:41
you have to communicate a lot and you have to organize a lot.
58:45
And then as you know more and more about what you're building,
58:48
you have to communicate less and less.
58:50
And then essentially by the end of the project,
58:53
we talk maybe once a week and both of us just know what we need to work on.
58:57
SPEAKER_1: And so Paul and you, are you both were in the same city, same country?
59:03
SPEAKER_0: We are both in Germany and we studied game design together at university.
59:09
So Paul is also one of the people I made Islanders with at university,
59:15
and we just teamed up again for Thronefall here.
59:20
SPEAKER_1: Nice.
59:20
And then,
59:21
so you've now gone through the development phase and you've been developing
59:27
this thing for closer to I guess two,
59:30
three years.
59:31
SPEAKER_1: I'm curious, what does a launch look like for an indie game?
59:36
SPEAKER_1: You launched it on Steam, right?
59:38
SPEAKER_1: Was it only Steam or did it launch elsewhere on launch day?
59:42
SPEAKER_0: On launch day, it was only on Steam.
59:43
SPEAKER_0: Now it's also available on Nintendo Switch.
59:48
SPEAKER_0: How does a launch look like?
59:49
SPEAKER_0: It's surprisingly anticlimactic.
59:52
So there's a button in the Steam backend where you're just like launch the
59:57
game and you click it.
59:59
And then they have a couple of things that pop up where they're like,
1:00:03
"Are you really sure you want to launch the game?
1:00:05
SPEAKER_0: Are you really, really sure?"
1:00:06
SPEAKER_0: And then you click, "Yeah, yeah, yeah, yeah, sure.
1:00:07
SPEAKER_0: Launch the thing."
1:00:09
And then it's just launch and you sit there and you're kind of like,
1:00:14
"Okay."
1:00:18
You have to pick your launch date somewhat carefully,
1:00:22
but also because everybody tries to pick their launch date carefully.
1:00:26
SPEAKER_0: It also kind of doesn't matter.
1:00:28
It's a little bit like trying to outsmart the market when you're buying
1:00:33
stocks or something.
1:00:34
SPEAKER_0: Everybody tries to be smarter than you.
1:00:36
So in the end,
1:00:37
it doesn't really matter when you launch because the good spots are already
1:00:43
very crowded and then the spots that are not so good are less crowded.
1:00:48
SPEAKER_0: So it kind of all makes up for itself.
1:00:50
SPEAKER_0: It doesn't really matter too much when you launch, I think.
1:00:53
In theory,
1:00:53
it does,
1:00:54
but the market dynamics make it so that it doesn't matter too much.
1:00:59
SPEAKER_1: Yeah.
1:00:59
Well,
1:01:00
I guess beyond some of the common wisdom of software people will not pay too
1:01:04
much attention.
1:01:06
But yeah,
1:01:06
I guess it's nice to hear that the things that people think matter don't
1:01:11
matter that much.
1:01:13
SPEAKER_1: One more topic on the development itself.
1:01:15
What were some challenges that you would say were more challenging with this game?
1:01:21
I'm just throwing in some ideas,
1:01:22
may that be performance,
1:01:23
binary size,
1:01:26
structure,
1:01:27
whatnot.
1:01:28
SPEAKER_1: What made this one more challenging than the other ones that you built?
1:01:32
So the main challenge for this one,
1:01:36
for me personally,
1:01:37
was everything related to pathfinding.
1:01:41
SPEAKER_1: Oh, interesting.
1:01:42
SPEAKER_1: Tell me more.
1:01:44
SPEAKER_0: I'm not sure if you're aware of algorithms like A* and so on.
1:01:51
SPEAKER_1: Very much.
1:01:51
SPEAKER_1: You'd be surprised.
1:01:53
On some interviews,
1:01:54
if you interviewed to Google,
1:01:55
Facebook,
1:01:56
et cetera,
1:01:56
you are well suited to study these things because they might ask it.
1:02:00
So even though we don't really use it,
1:02:01
and this is a common thing with engineering,
1:02:04
that's actually not true.
1:02:05
In some of the things,
1:02:06
there's pathfinding and like nodes,
1:02:09
computers,
1:02:10
where to go.
1:02:13
A typical interview question will be how does Google Search search between
1:02:17
all these things?
1:02:17
SPEAKER_1: So in theory we do it, but you actually are using it.
1:02:25
SPEAKER_0: Yep.
1:02:25
So the way this works in Thronefall is you see there's basically this blue
1:02:32
overlay grid here on the ground,
1:02:34
and every triangle here is essentially a node and they're all connected.
1:02:39
And whenever a unit has to go somewhere,
1:02:41
it just basically performs A* pathfinding on these nodes.
1:02:47
SPEAKER_0: And this is a ready-made system.
1:02:50
SPEAKER_0: This A* system is something we pulled from the asset store.
1:02:53
SPEAKER_0: We did not make this ourselves.
1:02:55
But of course you still have to customize it to a certain degree to your own needs.
1:03:02
But hold on,
1:03:03
just so I understand,
1:03:04
the units definitely don't move on those paths,
1:03:06
do they?
1:03:07
SPEAKER_1: That doesn't look like the path that the units take to me, or they do.
1:03:12
SPEAKER_1: Maybe I'm just misunderstanding it.
1:03:14
SPEAKER_0: They do.
1:03:15
They do move on...
1:03:17
If you want to perform A* pathfinding,
1:03:19
then first of all,
1:03:20
you need a node graph.
1:03:21
SPEAKER_0: Right?
1:03:24
SPEAKER_1: A node graph, yes, yes, yes.
1:03:25
SPEAKER_0: So this is the graph.
1:03:27
SPEAKER_1: Yeah.
1:03:27
SPEAKER_1: Also, that's a graph.
1:03:28
SPEAKER_1: Yeah.
1:03:30
SPEAKER_0: That's not the path the units takes.
1:03:31
SPEAKER_1: That's a graph that they perform to search.
1:03:34
SPEAKER_0: Exactly.
1:03:36
SPEAKER_0: And this graph is also dynamically updated.
1:03:38
SPEAKER_0: For example, when I build a castle center here.
1:03:42
SPEAKER_1: It's a node.
1:03:42
SPEAKER_1: You know it doesn't actually...
1:03:45
SPEAKER_0: Then you see there's a hole in the graph now where the castle center was.
1:03:49
SPEAKER_1: And it's now connected that way.
1:03:51
SPEAKER_0: Exactly.
1:03:52
And this is all automatically updated and done by the plugin we purchased
1:03:59
from the asset store.
1:03:59
So you can see here,
1:04:02
we can define these shapes,
1:04:03
which kind of shapes should be cut into the graph and so on and so forth.
1:04:08
But then actually making the units behave properly and take the correct path,
1:04:12
it's such a nightmare because you also have walls that certain units can go
1:04:18
through and other units cannot,
1:04:19
and then the default path finding doesn't support all of those features.
1:04:23
SPEAKER_0: So then you have to find workarounds.
1:04:25
SPEAKER_0: Then those workarounds cause new problems.
1:04:28
SPEAKER_1: Did you need to worry about unit collision or... I don't think so.
1:04:31
SPEAKER_1: Right?
1:04:31
SPEAKER_1: In this game, they can go through each other.
1:04:35
SPEAKER_0: No, they do collide.
1:04:36
SPEAKER_0: So there's...
1:04:37
SPEAKER_1: Okay, so you need to worry about that as well.
1:04:41
SPEAKER_0: Yes.
1:04:42
SPEAKER_0: It's partially taken care of by, once again, by the plugin we purchased.
1:04:47
SPEAKER_0: So it has what's called local avoidance.
1:04:52
SPEAKER_0: For example, if I write through them, you can see the...
1:04:56
SPEAKER_1: That's local avoidance.
1:04:58
SPEAKER_1: And so plugin does that.
1:05:00
SPEAKER_0: That is all luckily handled by the plugin.
1:05:04
SPEAKER_1: Just a quick question.
1:05:05
From a tech perspective,
1:05:07
is that property,
1:05:08
would that be code that is executed on each of the units,
1:05:12
like a mono behavior for example?
1:05:14
SPEAKER_1: Or is it some more global thing?
1:05:17
So in this case,
1:05:18
it's executed locally,
1:05:20
and that's because our game is not very well optimized.
1:05:25
SPEAKER_0: It's kind of similar for most strategy games.
1:05:27
Like most strategy games,
1:05:29
if you've played any,
1:05:30
oftentimes they have a unit limit of 200 or so.
1:05:33
And the reason for that is usually not for gameplay reasons,
1:05:36
but for performance reasons.
1:05:37
Because you're more than 200 units,
1:05:39
then at some point you're going to burn out your CPU.
1:05:45
So yeah,
1:05:45
this is all handled on the objects individually,
1:05:48
and it's not very well optimized to be quite frank.
1:05:51
SPEAKER_1: I mean it works and we have pretty powerful CPUs.
1:05:54
SPEAKER_0: Yeah, exactly.
1:05:56
And then of course,
1:05:57
you also have the things that they're not exactly moving on the nodes.
1:06:02
So you basically also have to do some post-processing on those paths so that
1:06:11
if they can go straight through a node,
1:06:14
then they should take the straight part.
1:06:17
And if they're cutting around corners,
1:06:19
they need to go in the corners here.
1:06:21
And at the beginning,
1:06:23
there were all kinds of problems,
1:06:24
like they're getting stuck on corners and so on.
1:06:27
SPEAKER_1: Okay.
1:06:28
SPEAKER_0: Yeah.
1:06:29
But also the walls cause a lot of problems because you can see my units,
1:06:33
they can go through the walls,
1:06:36
but the enemy units,
1:06:37
they cannot go through the walls.
1:06:39
SPEAKER_0: So now what should they do here?
1:06:40
SPEAKER_0: Should they try to go through this store?
1:06:42
SPEAKER_0: Should they try to go around?
1:06:44
SPEAKER_0: And it was a bit of a nightmare.
1:06:46
SPEAKER_0: And there are still some issues with it, but yeah.
1:06:49
SPEAKER_1: Well, now the enemy meetings are mostly just attack the walls often.
1:06:52
SPEAKER_0: Yeah, indeed they do.
1:06:54
They basically pretend like they can walk through it and they don't know that
1:06:59
they can't.
1:06:59
SPEAKER_0: They're confused.
1:07:02
SPEAKER_0: Why can I not go through that wall?
1:07:04
See,
1:07:04
but I feel these are the things that as a developer,
1:07:07
you're probably a little bit pulling your hair about it or unhappy,
1:07:12
but until we talked about this,
1:07:13
I never noticed it as someone who played the game.
1:07:16
So there's this joint of like,
1:07:18
oh,
1:07:19
you think it's a problem,
1:07:20
but the customer or the user doesn't really.
1:07:24
Yeah,
1:07:25
but that's also why you need different node graphs here,
1:07:29
for example,
1:07:29
there's also one node graph specifically for enemy units.
1:07:34
And you can see the enemy unit node graph has sort of a hole in the node graph
1:07:40
here where the gate is.
1:07:41
And then the player units,
1:07:43
they don't have a hole here,
1:07:44
they have a thing that they can go through.
1:07:46
SPEAKER_0: And then there's also a separate node graph for the flying units.
1:07:51
SPEAKER_1: Oh, yeah.
1:07:51
SPEAKER_1: Oh, yeah.
1:07:53
SPEAKER_0: So to answer your question, what was the biggest hassle?
1:07:57
I think for me personally,
1:07:59
the pathfinding was the biggest hassle from a technical perspective.
1:08:04
And then from a design perspective,
1:08:06
I would say probably the difficulty balancing was also a very big challenge
1:08:11
due to the snowbally nature.
1:08:13
SPEAKER_0: We've already talked about that.
1:08:14
And also one of the ways we counteract that a little bit is with the mutator system.
1:08:18
So all of the base levels are usually a little more on the easier side,
1:08:22
and then if you want to make it more difficult,
1:08:24
you can just play it with a couple of extra mutators.
1:08:27
SPEAKER_0: And I feel like, in the end it worked out all okay.
1:08:31
SPEAKER_0: But there were challenges for sure.
1:08:32
SPEAKER_0: Yeah.
1:08:34
SPEAKER_1: Yeah.
1:08:34
SPEAKER_1: Gen AI, it's everywhere now.
1:08:37
SPEAKER_1: There's like tools, etc.
1:08:38
And I'm just curious,
1:08:40
do you use any tools that are LLMs either for help or development?
1:08:45
You did mention ChatGPT and also do you see any indie developers using any
1:08:51
tools or stuff that makes your work easier?
1:08:53
SPEAKER_1: And is it making your work easier or faster at all?
1:08:57
It does make my work significantly easier,
1:09:03
and I think for most people,
1:09:05
most indie developers who say ChatGPT is not helpful for them,
1:09:09
in my opinion,
1:09:10
they have not mastered that tool yet.
1:09:12
Because it has a bit of a learning curve and you need to learn what it can do,
1:09:15
what it cannot do.
1:09:17
But once you know what it can and what it cannot do,
1:09:19
it is incredibly powerful,
1:09:23
especially for beginner level questions on any subject,
1:09:27
it's also incredibly reliable.
1:09:31
So when we talk about Gen AI and Gen AI tools you use,
1:09:33
is it ChatGPT mostly for you?
1:09:36
Yeah,
1:09:37
I bounce back and forth a bit between ChatGPT and Claude,
1:09:41
but currently I'm back at ChatGPT.
1:09:43
SPEAKER_0: I think the o1, the o series is pretty good at coding.
1:09:49
SPEAKER_1: And what kind of stuff did you do with it or do you do with it?
1:09:54
SPEAKER_0: So one very common thing I like to do is I like to write skeleton code.
1:10:02
SPEAKER_0: So I essentially write an entire script, just a skeleton code.
1:10:05
So there are the functions in there,
1:10:08
but in the functions,
1:10:09
there's just a to do write this function or something like this.
1:10:14
And if you have a skeleton code like this,
1:10:17
ChatGPT is incredibly good at filling that in for you.
1:10:19
SPEAKER_0: So that's just a little speed hack that I drew.
1:10:24
I come up with the architecture,
1:10:25
I define exactly what I want to happen,
1:10:28
but I don't implement it myself.
1:10:31
I'm just like to do implement this function and from the inputs and the context,
1:10:37
ChatGPT can figure out what I want the function to do.
1:10:39
And this doesn't work for everything,
1:10:41
but for boilerplate stuff that you just can't be bothered with,
1:10:44
it works incredibly well.
1:10:46
And then also sometimes there are subjects that you just don't know that much about.
1:10:50
SPEAKER_0: For example, shader coding is entirely different.
1:10:54
SPEAKER_0: Discipline and shader code looks very complicated.
1:10:57
SPEAKER_0: It's very difficult to read if you're not familiar with it.
1:11:00
So I feel like ChatGPT can also act a bit like a translator there where you copy
1:11:05
in a bit of shader code and ask,
1:11:07
"Hey,
1:11:07
what does this do?
1:11:09
SPEAKER_0: Where should I implement this and that?"
1:11:11
And it's just pointing you in the right direction because it's not perfect at everything,
1:11:17
but it knows enough about everything that can help you with those weird
1:11:21
disciplines that you don't maybe know enough about to deal with yourself.
1:11:26
And instead of having to learn shader code and spending months on that,
1:11:31
I can just basically ask ChatGPT and it makes it so much easier and everybody
1:11:37
who's like,
1:11:38
"Yeah,
1:11:38
butithallucinatedonetimeandIhadtorewriteit."
1:11:42
SPEAKER_0: Yeah, sorry, but that's your fault.
1:11:44
SPEAKER_0: You didn't use it very well.
1:11:47
SPEAKER_0: That's I guess my take, yeah.
1:11:51
And do you use GitHub Copilot at all,
1:11:53
or no,
1:11:53
you just use ChatGPT because what you mentioned of doing the to dos cetera,
1:11:57
Copilot might be able to do that.
1:12:00
SPEAKER_1: Did you try it or not?
1:12:01
SPEAKER_1: It didn't stick.
1:12:02
SPEAKER_0: I actually haven't tried it.
1:12:04
SPEAKER_0: I probably should try it sometime, but I haven't tried it so far.
1:12:08
And I'm also a little afraid of what it might do to my workflow because I wanted
1:12:14
to be intentional when I use it.
1:12:17
I don't want it to be constantly running in the background and doing things,
1:12:22
at the very least not yet.
1:12:23
SPEAKER_0: So I'm fairly happy with my workflow there at the moment.
1:12:28
Honestly,
1:12:28
if you have a workflow that works,
1:12:31
that's one complaint that I have heard and people have turned it off.
1:12:34
SPEAKER_1: It's not just Copilot, but there's a lot of things where they prompt you.
1:12:38
It does just show you,
1:12:40
and after a while it can be annoying and it can get in the way of deep work.
1:12:46
SPEAKER_0: I want to use it intentionally and when I want to use it.
1:12:50
SPEAKER_0: And I also don't want to get in the habit of using it when I shouldn't.
1:12:57
So as mentioned,
1:12:58
I think there are very specific cases when you should use it,
1:13:00
and there are also specific cases where I should deliberately not use it,
1:13:04
and I want to be able to make that call.
1:13:07
SPEAKER_0: And I am sure you can do that with Copilot.
1:13:09
SPEAKER_0: You can probably turn it off and stuff.
1:13:10
SPEAKER_0: But yeah.
1:13:11
SPEAKER_0: This just works for me at the moment.
1:13:14
Talking about indie game development as a broader picture,
1:13:18
what are some things that you wish you knew before getting into indie development?
1:13:24
Because so far we've talked about what I feel is more of the engineering part
1:13:27
and a little bit of the art,
1:13:28
which is the code,
1:13:30
the design,
1:13:30
those things.
1:13:31
But I'm going to suspect that there's a lot of other things going outside.
1:13:35
SPEAKER_1: I know you do, for example, the YouTube videos.
1:13:37
SPEAKER_1: You mentioned you do music.
1:13:39
What were all these other things that oh,
1:13:41
turns out they're kind of part of building a game with a small team?
1:13:46
SPEAKER_0: The one thing I hate most is bureaucracy.
1:13:49
SPEAKER_1: Really.
1:13:49
SPEAKER_1: What kind of bureaucracy?
1:13:53
SPEAKER_0: Taxes, filling out forms for Steam.
1:13:56
SPEAKER_1: Oh, accounting.
1:13:58
SPEAKER_0: Accounting.
1:13:58
SPEAKER_0: That's the one thing nobody tells you about.
1:14:01
Dealing with legal documents,
1:14:04
creating all of these deals,
1:14:06
writing back and forth with lawyers.
1:14:08
SPEAKER_0: It's like I just can't be bothered.
1:14:11
Luckily,
1:14:12
it's not a super big portion of the work I do,
1:14:14
but it's just the most annoying part by far that nobody really talks about.
1:14:19
SPEAKER_1: Nope.
1:14:23
SPEAKER_0: Yeah.
1:14:23
But other than that,
1:14:24
I think what's pleasant about being a game developer for me personally is
1:14:28
that you get to wear a lot of different hats.
1:14:31
So you get to make graphics,
1:14:33
you get to make music,
1:14:34
you get to write code,
1:14:36
you 3D model,
1:14:37
you texture,
1:14:39
you do sound design,
1:14:41
you come up with cool systems and write cool tech,
1:14:48
and this is a little bit of everything.
1:14:50
SPEAKER_0: And I think that's exactly what makes it awesome and fun.
1:14:54
And the one thing,
1:14:57
as mentioned,
1:14:57
this is also oftentimes underestimated is the UI coding,
1:15:01
all of the overlay menus and so on,
1:15:04
very annoying and super happy,
1:15:06
I have Paul who's actually good at that and does it with a bit of joy as well.
1:15:12
SPEAKER_0: That's a huge relief.
1:15:14
Speaking with some other indie developers that you know,
1:15:18
if several listeners are software engineers who know how to code very well,
1:15:22
but they might be thinking of getting into indie development,
1:15:25
what advice would you have for these people in starting to build their own
1:15:30
games and publishing them?
1:15:33
First of all,
1:15:34
resist the urge to build your own engine,
1:15:37
unless that's specifically what you want to do and get joy out of.
1:15:40
SPEAKER_0: If I just want to enjoy building my own stuff, sure, go ahead.
1:15:45
But if all you want to do is make a successful indie game,
1:15:48
don't write your own engine.
1:15:49
SPEAKER_0: That's step number one.
1:15:51
SPEAKER_0: Just use either Unity, Godot, GameMaker, Unreal.
1:15:55
SPEAKER_0: There are lots of good options to choose from.
1:15:57
Pick one of those because as mentioned,
1:15:59
it does make a lot of it a lot faster.
1:16:02
And one of the main things you need as an indie game developer is speed,
1:16:07
because it really is.
1:16:10
If you're making games alone or in a tiny team of two or three people,
1:16:13
you need insane speed to even be able to finish your game.
1:16:19
And even if you are fast,
1:16:21
you still need to purposefully pick a very small game that's going to be
1:16:26
manageable for you to make.
1:16:29
The main thing that people,
1:16:31
or that new developers I think should know is that games don't automatically
1:16:37
sell better if they're bigger.
1:16:39
SPEAKER_0: That's not the case.
1:16:42
SPEAKER_0: So you need a good payoff to effort ratio.
1:16:48
SPEAKER_0: That's what you're really after.
1:16:49
So you want as much bang for your buck,
1:16:52
and if you spend twice as long,
1:16:55
then your game needs to make twice as much money to make up for it.
1:16:59
And that is often not that easy to achieve because the bigger your project gets,
1:17:04
the more technical depth you build up and the slower everything gets.
1:17:08
So the bigger your project is,
1:17:10
the harder it is to make that return on investment.
1:17:13
So actually smaller games are much,
1:17:16
much easier to make successful because if you make a game in half a year,
1:17:21
then it has much lower requirements to be successful.
1:17:24
SPEAKER_0: And also people actually do like small games, believe it or not.
1:17:28
SPEAKER_0: People really do small focused experiences.
1:17:30
SPEAKER_0: I've seen it a lot for the games I build, for some of my friends build.
1:17:36
SPEAKER_0: There is a market for small and focused experiences, so that's 100%.
1:17:42
Well,
1:17:42
I'm going to go on a stretch in a little bit,
1:17:44
but I'm an example,
1:17:46
and I think a lot of software engineers who have day jobs working eight to 10
1:17:52
hours a day at a company,
1:17:53
going home,
1:17:54
potentially having other things to do,
1:17:57
you just don't have as much time.
1:17:59
And a lot of us,
1:18:01
we were able to afford the indie game of 10,
1:17:59
20,
1:17:59
30,
1:17:59
40 euros,
1:18:06
and sometimes I personally feel it's a better use of my time to pay for a game
1:18:10
that is shorter,
1:18:12
but very enjoyable because I do not have time to go through the $70 game.
1:18:18
SPEAKER_1: I just won't be able to finish it.
1:18:20
And when I see that it's like 80 hours or 160 hours to finish,
1:18:23
I'm like,
1:18:24
no,
1:18:24
it's a no go for me.
1:18:26
So there's that part which is,
1:18:28
this is one of the reasons I love indie games.
1:18:30
SPEAKER_1: You can finish it and feel that it's kind of complete.
1:18:33
Okay,
1:18:33
there's a little bit of many things,
1:18:34
but I'm kind of happy with that personally.
1:18:37
SPEAKER_0: That's exactly it.
1:18:38
SPEAKER_0: And you're not alone with that.
1:18:39
SPEAKER_0: A lot of people have day jobs.
1:18:41
That's a very normal thing and people don't have endless time to play video
1:18:45
games anymore.
1:18:45
So that's why in the indie game market in particular,
1:18:50
small games are completely fine and quality is way more important than quantity.
1:18:56
So first of all,
1:18:58
if you want to go from engineering to game design,
1:19:02
then don't write your own engine.
1:19:04
And also not only that,
1:19:07
you also,
1:19:08
I think you have to resist that urge to build technical systems right away.
1:19:13
Even an engine,
1:19:16
I think a lot of people who come from an engineering direction,
1:19:19
they have the urge to build their MMO system before they even test it if it's
1:19:24
fun or not.
1:19:25
So take your time,
1:19:27
take it slow,
1:19:28
approach it from more of a design perspective where you do care about the user
1:19:33
experience first and only once you figured that out,
1:19:36
then you can start worrying about how you want to engineer the system behind it,
1:19:41
but figure out the experience first and then go into the engineering part of it.
1:19:46
SPEAKER_0: I think that's very important.
1:19:48
SPEAKER_1: Thank you.
1:19:49
In terms of learning how games are built,
1:19:55
again,
1:19:56
coming from a background where you do know coding,
1:19:58
so that's not a problem,
1:19:59
but the frameworks are different,
1:20:01
the tools are different.
1:20:03
SPEAKER_1: What kind of resources did you use to learn?
1:20:06
SPEAKER_1: And also you did something that a lot of listeners will have not done.
1:20:09
SPEAKER_1: You've actually done a degree in game design.
1:20:11
I'm curious on how much that actually helped you become a better game developer,
1:20:16
and would you recommend a more focused course like this,
1:20:20
which is not just a watch a YouTube tutorial kind of thing,
1:20:23
but actually spending a bit more focused effort and how that worked for you?
1:20:30
I think it's completely possible to be 100% self-taught when it comes to game development.
1:20:34
SPEAKER_0: There are enough resources out there to learn it yourself.
1:20:41
I think the main thing university did for me is that it connected me to a lot of
1:20:48
great people.
1:20:49
SPEAKER_0: I really have to give a big shout-out to my game school for that.
1:20:53
I studied game design at HTW Berlin,
1:20:56
the bachelor game design degree,
1:20:58
and it was very,
1:21:00
very valuable.
1:21:01
SPEAKER_0: I just want to make the very clear, it was super valuable for me.
1:21:05
They did have great coaching,
1:21:07
they did have great courses and so on,
1:21:08
but all of that stuff you can teach yourself.
1:21:12
Maybe it's a little more efficient if you do this in a specific way or something,
1:21:16
but you can 100% teach that to yourself.
1:21:19
But one thing that was just immensely,
1:21:21
immensely,
1:21:21
immensely valuable was just the people I met there because they basically
1:21:29
curated a list of really awesome people,
1:21:31
and that was incredibly valuable as it turned out,
1:21:37
because I went on to start a company with some of them.
1:21:42
And I guess part of the reason is that they have an application process where
1:21:46
obviously they only select a portion of the people who apply.
1:21:51
If you go to a different game school where the only requirement is that you pay
1:21:54
them a lot of money,
1:21:56
then you won't have such a nicely curated list probably.
1:22:03
So if you want to go to a game school,
1:22:05
honestly,
1:22:05
that's one of the main things I would look for is how they curate the list of
1:22:13
people there.
1:22:14
Because honestly,
1:22:15
the more difficult it is to get in,
1:22:18
the more awesome the people you will likely meet there.
1:22:22
SPEAKER_1: I like that.
1:22:22
SPEAKER_1: Yeah.
1:22:23
SPEAKER_0: Other than that, don't be worried.
1:22:26
SPEAKER_0: You can be self-taught.
1:22:26
SPEAKER_0: It's not a problem.
1:22:28
How do you see success as an indie developer for those who want to get serious
1:22:32
about it?
1:22:33
You are reasonably successful,
1:22:35
if I'm kind of under rating it,
1:22:37
but you've had two big hits already,
1:22:40
and even the third game is I think what a lot of developers would dream of.
1:22:44
What do you think helped your success and when other indie developers ask you
1:22:49
for advice,
1:22:50
what did you tell them?
1:22:53
Well,
1:22:53
the honest answers,
1:22:55
you have to get lucky to a certain degree,
1:22:58
but the luck isn't in what happens after you press the launch button.
1:23:01
The luck is in where you are born and which people you meet along the way.
1:23:06
SPEAKER_0: I feel like especially extremely lucky with the people I met.
1:23:10
Paul is just such a fantastic person to work with,
1:23:14
really happy about that,
1:23:15
and there was a lot of luck that we got to connect like that.
1:23:21
Then besides that,
1:23:23
I think the main thing you need to do if you really want to succeed with making
1:23:26
indie games is you need to find the correct overlap of something you want to
1:23:32
work on and something that also has a chance to do well in the market and
1:23:35
figuring out what can do well in the market.
1:23:38
That is a little bit of a science by itself,
1:23:40
and we could probably fill an entire podcast episode about my theory
1:23:45
crafting about that.
1:23:46
But if I had to sum it up very quickly,
1:23:50
it needs to be appealing,
1:23:51
it needs to be fun,
1:23:52
it needs to be a good game.
1:23:54
SPEAKER_0: So the super short summary would be just make a great game.
1:23:59
SPEAKER_0: But the problem with that is it also needs to be the right game.
1:24:03
So a metaphor that somebody on X recently helped me refine a little bit is
1:24:09
imagine you're selling ice cream.
1:24:13
SPEAKER_0: It's not enough to sell the perfect ice cream.
1:24:16
All there needs to be the correct kind of ice cream because if you're making
1:24:19
perfect garlic ice cream,
1:24:22
everybody's like,
1:24:23
"Yeah,
1:24:23
sure,
1:24:24
it's perfect garlic ice cream,
1:24:25
butIdon'twantgarlicicecream."
1:24:27
So you need to make great ice cream and also needs to be a flavor that people
1:24:31
actually want,
1:24:33
and don't open your ice cream stand next to a bunch of other people who are
1:24:37
already selling the same kind of ice cream.
1:24:39
SPEAKER_0: Like a pretty decent analogy.
1:24:42
SPEAKER_0: So you need to...
1:24:43
SPEAKER_1: Well, yeah.
1:24:43
I guess you need to be aware of the actual what is happening in the world,
1:24:47
because right now,
1:24:48
if you start to sell Dubai chocolate ice cream,
1:24:51
it will be popular because the past few months,
1:24:54
it's actually been a trend.
1:24:55
SPEAKER_1: But if you did that a year before or a year after, probably not.
1:25:00
SPEAKER_1: Those kind of things as well.
1:25:02
Short-term trend chasing doesn't work very well with game development
1:25:05
because it's such a lengthy process,
1:25:07
and by the time your game comes out,
1:25:08
the trends have already moved on.
1:25:10
So you're really looking for those long-term trends and what really does
1:25:17
well in the long run.
1:25:18
You have to have a finger on what people really crave and figuring that out is I
1:25:25
think one of the main challenges.
1:25:27
And then also accepting that you're not making just your own dream game,
1:25:31
but that you have to make a game for others.
1:25:35
That is the other half of the challenge that some people struggle with,
1:25:39
where they're like,
1:25:40
"Yeah,
1:25:40
butIreallywanttomakethisandthiskindofgame."
1:25:42
And if you tell them,
1:25:44
"Yeah,
1:25:44
sure,
1:25:45
you can make that game,
1:25:45
but I'm not sure if it's going to sell all that well," then they're just like,
1:25:50
"La,
1:25:50
la,
1:25:50
la."
1:25:54
If you want to make whatever you want to make,
1:25:56
more power to you,
1:25:57
that's obviously perfectly fine.
1:26:00
But if you want to succeed,
1:26:02
then you also have to think a little bit about what is likely to succeed.
1:26:08
And it's not as pure,
1:26:12
it's not as idealistic as just make great games,
1:26:16
just follow your passion,
1:26:17
but you need to strike some compromise.
1:26:22
SPEAKER_1: Yeah.
1:26:23
SPEAKER_1: For sure.
1:26:23
SPEAKER_1: Yeah.
1:26:24
SPEAKER_1: Thanks for that.
1:26:24
SPEAKER_1: So with that, we'll close it up with some rapid questions.
1:26:28
SPEAKER_1: If you're okay with that, I'll just ask and then you fire back.
1:26:31
SPEAKER_0: I'll see how rapid I can make it.
1:26:32
SPEAKER_0: Well, I'll try my best.
1:26:34
SPEAKER_1: Yeah.
1:26:34
SPEAKER_1: What is the game that you enjoy playing and would recommend?
1:26:36
SPEAKER_1: And obviously you cannot say any of the games that you made.
1:26:41
SPEAKER_0: Specifically to engineers, I would recommend Opus Magnum.
1:26:44
SPEAKER_0: If you haven't played, it's a great puzzle game.
1:26:46
SPEAKER_0: You should play it.
1:26:47
SPEAKER_0: And just in general, I would recommend everybody should play Outer Wilds.
1:26:52
SPEAKER_0: It's a bit more tricky to get into, but give it some time.
1:26:56
SPEAKER_0: Play Outer Wilds.
1:26:57
SPEAKER_0: Thank me later.
1:26:59
SPEAKER_1: I'm going to give it a go and I'll see if I'll thank you for it.
1:27:03
SPEAKER_1: What is your favorite programming language and why?
1:27:07
SPEAKER_0: Depends on the use case.
1:27:09
SPEAKER_1: Oh, haven't heard this before.
1:27:12
SPEAKER_1: Very practical.
1:27:12
SPEAKER_1: Okay, tell me.
1:27:14
Yeah,
1:27:14
I think both game engines as well as programming languages,
1:27:20
they have different pros and cons,
1:27:21
and depending on what you're trying to do,
1:27:23
you can use different tools like pick a tool that is appropriate for the job
1:27:28
that you're trying to get done.
1:27:30
SPEAKER_0: Yeah.
1:27:31
SPEAKER_1: Spoken like a true game designer.
1:27:33
I think maybe,
1:27:33
I don't know enough programming languages to really make a great judgment
1:27:37
call about this.
1:27:38
SPEAKER_0: I know C#.
1:27:39
SPEAKER_1: That's fair.
1:27:40
Software engineers are often biased towards one language or the other,
1:27:45
the strengths or the weaknesses,
1:27:46
but I like the practical aspect of this.
1:27:50
SPEAKER_1: What are two books that you'd recommend reading?
1:27:54
If you want to get into game development,
1:27:56
I would recommend 10 Steps to Making Your First Game Successful by Wlad Marhulets.
1:28:03
SPEAKER_0: I hope I didn't screw up that name, but I can show the book real quick.
1:28:06
SPEAKER_0: Tada.
1:28:08
The reason I like this book is because it's a fairly easy read,
1:28:13
very,
1:28:13
very big font.
1:28:14
You can go through this relatively quickly and it essentially touches on
1:28:18
everything you need to know about making a full on video game.
1:28:23
SPEAKER_0: It's a bit surface level, but it tells you a bit about everything.
1:28:25
SPEAKER_0: So I think it's a very, very good starting point.
1:28:28
SPEAKER_1: Awesome.
1:28:28
SPEAKER_1: Any other book or one book also works.
1:28:31
There's another one you should at least know about when you want to make games,
1:28:34
and that is Flow by Mihaly Csikszentmihalyi.
1:28:38
I'm not sure you necessarily have to read that book,
1:28:41
because this one is certainly not an easy read.
1:28:44
It's a bit exhausting to read,
1:28:46
honestly,
1:28:47
but maybe you can read a summary about it or something.
1:28:50
SPEAKER_1: Awesome.
1:28:50
Well,
1:28:51
thank you very much for sharing all of these proper behind the scenes of how a
1:28:56
game is truly made.
1:28:58
SPEAKER_1: I've had a really good time just taking it all in.
1:29:01
SPEAKER_1: Thank you.
1:29:02
Thank you for Jonas for taking us to behind the scenes of building of the indie game,
1:29:06
Thronefall.
1:29:07
SPEAKER_1: The game is available on Steam and on Nintendo Switch.
1:29:10
Jonas also documents his indie game development journey on his YouTube channel.
1:29:14
SPEAKER_1: Check it out.
1:29:15
SPEAKER_1: It's linked in the show notes below.
1:29:16
For a deep dive of how to build a simple game using Unity and for the basics on
1:29:20
game development,
1:29:21
see The Pragmatic Engineer Deep Dives,
1:29:23
also linked in the show notes below.
1:29:24
If you've enjoyed this podcast,
1:29:26
please do subscribe on your favorite podcast platform and on YouTube.
1:29:29
SPEAKER_1: Thanks and see you in the next one.