EPISODE 1691

[INTRO]

[0:00:00] ANNOUNCER: Celeste is a critically acclaimed action platformer developed by Extremely OK Games. They recently released Celeste 64, which is an open-source project to commemorate the sixth anniversary of the original Celeste and development of their next major game Earthblade is underway. 

Noel Berry is a programmer at Extremely OK Games and he joins the show to talk about developing Celeste and Earthblade. Gameplay engineering, the state of C# versus C++ for game development and more.

Joe Nash is a developer, educator, and award-winning community builder who has worked at companies including GitHub, Twilio, Unity, and PayPal. Joe got a start in software development by creating mods and running servers for Garry's Mod. In-game development remains his favorite way to experience and explore new technologies and concepts.

[EPISODE]

[0:01:03] JN: Welcome, Noel. Thanks for joining me today. How are you doing?

[0:01:06] NB: Yes. Thanks for having me. I'm doing good. How are you?

[0:01:08] JN: Yes. It's been a good week. It's been fun to see if this coming GDC, which I know you have also, you are heart on the tails of it. It's always exciting week for game news, I think.

[0:01:17] NB: Yes, it was fun.

[0:01:18] JN: To kick that off, you've been working Extremely OK Games for a while, and I named a few titles there. TowerFall and Celeste, which obviously go back now, surprisingly, 10 years. How did you get your start with game development? Where does your game dev journey start?

[0:01:32] NB: Yes. I started making games as a kid. So, when I was 11, 12, I downloaded a program called GameMaker. I didn't know how to program at all at that point. So, I was just kind of fumbling around, messing and stuff. Because I was excited games. I like playing games a lot and I wanted to find - I don't know, it seems exciting to kind of mess with them.

So yes, I downloaded GameMaker and it took quite a few years of just like experimenting and messing around with it and eventually started making games that actually made sense. GameMaker had this thing like drag and drop things. You could just drag and drop these blocks in, and that describe how GameMaker do stuff. So, I didn't cut it all. Eventually, you could like drag in code block and cut a little bit. So, I started by just copying pasting people's code from the Internet into mine to make it do special things that the coding box, or the drag-and-drop box couldn't do. Over time, just going to tweak those, and start editing them myself to learn how to code.

[0:02:24] JN: Yes. Those kinds of tools, like the ones where you've got a visual editor, but then it allows you to have, essentially, like a non-visual pie inside of it. I've always been like a really - probably a really nice staircase that's really cool to hear. What version was that? GameMaker 1 or 2 at that point?

[0:02:37] NB: No. That would be GameMaker 6.1. They went through different versions. Eventually, in, I think, 2015 or '14, somewhere around there, they like rebooted the whole thing. That was like, GameMaker Studio 1 and then they had GameMaker Studio 2. But before that, in 2000, 1999, somewhere around there. They had GameMaker 1, and then they went through to like 6.1 was around, I think 2005, I want to say. Then, they went to eight, and then eventually they reset it, and so on again.

[0:03:03] JN: Okay. That makes sense. I was like, I think they've constructed or something. Where did I get one or two from? But that makes sense. So, I think what most people will know you for is Celeste, which is, I guess, the more recent of the two released games. One of the things I really want to dig into because I'm a huge PICO-8 fan is the game has origins and how you got started with PICO-8 and that whole journey. So, you made the original Celeste in PICO-8, and even since the release, you've revisited PICO-8 for Celeste a couple of times with Celeste 2. Making the sequel at PICO-8 was very - I was like, "Okay, that's awesome." What keeps bringing you back to PICO-8, even after using a full game engine to develop Celeste?

[0:03:42] NB: I think I like limitations a lot. Just creatively when you have kind of a limited, it can be anything it does have to be like - PICO-8 is like technically limited, but just kind of limitations in general. So, I like game jams for the same reason that are kind of like, "Well, you only have 48 hours." So, what you're able to do is like quite scoped down to kind of think creatively in that space. I liked [inaudible 0:04:01] too where you are kind of thinking of stuff like, "Well, I can't do a lot of stuff in this. So, what can I do and what's kind of fun to explore in that space?" Both technically and game design and art and everything. So, I think that's why I am constantly kind of coming back to PICO-8 and tools like that, just because they're fun to kind of experiment, small experiment in and play around in, mostly do the limitations. I think if PICO-8 was the same but had no limitations, and it would kind of be like, "Well, I'll just code in my own engine or coding bigger stuff, because what's the point?"

[0:04:34] JN: Yes. It makes a lot of sense. So, I guess like, in Celeste, the prototype was PICO-8 and then you've moved to build the into a full game. To what extent - obviously, I imagined that a lot of the gameplay mechanics and how Celeste evolved in terms of the basis for the gameplay and the gameplay loop was informed by the PICO-8 restrictions. How do you navigate that as you're removing those restrictions? Do you open up the concept on what you can do? Or do you try and stay true to it? 

[0:04:58] NB: Yes. I mean, when we started the larger game coming out of PICO-8, we started with basically the same game. I mean, we increase the resolution a bunch. I mean, Celeste is at least six times bigger. I don't know. PICO-8 is 128 by 128, so we expanded a lot. But initially, it kind of started off quite similar. Then, we added, like the original PICO-8 doesn't have climbing. So, we added climbing quite early on, because it kind of played well with the idea of climbing a mountain and the dash mechanics.

But yes, I think to start, it was quite similar, just kind of like bigger play space, and like scrolling camera, things that are just kind of initially like way easier to do not in PICO-8, because there's more space. We have a scrolling camera. Then, the stuff that kind of comes out of that, the level design and things that come out of that, that we added multiple levels instead of just one kind of long level. But even the first like chapter in Celeste is kind of similar to the PICO-8 chapter in a lot of sense. Because it's like, it doesn't have a lot of narratives. Kind of this one level you're going up and that was kind of the start of bigger Celeste.

In a lot of ways, it started kind of the same.

[0:06:02] JN: Right. This is a direct port..

[0:06:03] NB: Yes, almost a port. Then, once you have that kind of established and working, then you just kind of iterate on it and it keeps going.

[0:06:11] JN: Awesome. I guess speaking about moving from PICO-8 to the full game. I know the full game is built in XNA. But you tell us a bit about the technology behind the game?

[0:06:19] NB: Yes. So, XNA is deprecated Microsoft Game framework. I think was deprecated in 2013, which is like over 10 years now, which is kind of wild. But yes, at the time, both Maddy and I were making games in XNA, even though it was already deprecated when we started Celeste by like four years or something. But I was making a game called Skytorn and Maddy had obviously made TowerFall in XNA. We both just liked using C# a lot, for like the game programming at least. It was just very easy to kind of make game objects and design stuff in a language like that.

At that point, there was like open source ports of XNA. There's one called MonoGame, and one called FNA, and those kind of brought XNA to other platforms like you know, Mac and Linux, and then also consoles. So, it felt safe in regard, even though it was a deprecated dead framework. It felt like, one, we were very comfortable in it and liked working in it. Then two, it was also just like, despite being deprecated, it was quite stable, and had a good community around it, and a good support of like open source alternatives. I mean, the XNA version itself still runs on Windows 11 years later, because Windows is fairly good at keeping old stuff running.

[0:07:30] JN: There's no new stuff. So, I felt like I missed the XNA way. But I've been aware of it in the background has been a very popular framework, but not being a C# person. I feel like it's never something I've explored. But like the open-source projects are still maintaining. FNA, I saw was getting a bunch of funding off the back of the Unity debacle and stuff. They are still active in a way.

[0:07:51] NB: Yes. Both FNA and MonoGame got a bunch of funding. I think every Re-Logic, I think the Terraria people, which is really to see. Both of them are like moving forward, which is yeah, really awesome. They're both like - they've contributed a lot. The FNA maintainers contributed a lot to the development of SDL 2, which is like everything in games. Everything is like built on top of it. So, that I think it is cool to see those projects like moving forward because they just in turn, a lot of development time in them is actually spent in SDL 2 which is really cool.

[0:08:27] JN: That's awesome. So, one particular part of that build out the full game that wanted to ask about. There is a relatively well - I don't think this is a spoiler. Hopefully it's not optimal this time. There is a relatively well-known Easter Egg but the original PICO-8 version Celeste is embedded within the full Celeste. I think, I had this moment when I realized that Celeste was on Switch, where I was like, "That can't be the original PICO-8 car." Did you write a PICO-8 emulator for that? How is that working?

[0:08:53] NB: I thought about running an emulator for it. I was very close to doing it because it seemed like a fun project. But I think at the time, we were kind of rushing through a lot of stuff, and I was like, "I don't have time to make like a proper emulator."

[0:09:05] JN: It's like this huge side quests.

[0:09:08] NB: So, I just went kind of line by line in the - I wrote like an API. I made all the Lua, like all the PICO-8 calls. I kind of made like a light C# API that remapped our game engine stuff. Then, I just went line by line in the Lua version and translated it to C#, which wasn't as bad as it sounds, because PICO-8 is obviously quite simple. So, the amount of calls I had to do were not too bad. I had to write like certain custom math functions. I couldn't use the built-in C# math, like I think sine functions and stuff like that. I had to remap them to a slightly different versions and stuff like that.

[0:09:44] JN: Why is that?

[0:09:45] NB: I think it's just simple stuff like - I can't quite remember anymore -

[0:09:48] JN: - the same as the Lua version?

[0:09:50] NB: Yes. The numbers you get aren't quite rounding the same way and stuff like that. There were actually some mistakes. There wasn't exactly one-to-one for a while, but at some point people in the community kind of listed everything that was wrong with it with detailed explanations, and I fixed all of them eventually.

[0:10:08] JN: Yes. So, that brings me to actually, that was quite interesting about what you did. I guess it was on your personal GitHub. So, I assume it was you personally, where you ran a public bug tracker for Celeste, which is unusual, I think for games full stop. But even for indie games, alongside the PICO-8 code, and even if it's in actual code. What led to you doing that? Because like I said, it feels unusual to me that game devs do that.

[0:10:33] NB: Yes. I mean, I'm really into this open-source stuff in general. I'd say, I mostly got more into open-source stuff, I'd say, after Celeste. I wasn't really - I was kind of just making stuff and working away. Then afterwards, I was looking into stuff more and thinking about things more. So, I guess we just wanted to share some of the process for how we made the game and what it looked like, even though we haven't released the full source code.

But yes, it was seeing if it would be useful to people and sharing, at least, some of what went into making the game. Yes, honestly, the bug tracker for like the GitHub version, we used it a little bit. It was good to kind of see what was happening. But still, most of our bug reports come through email, and we fix them to that. But the GitHub was kind of as a cool exploration of that. I'd say like, since Celeste, I've used it a lot more. For Celeste 64, we just posted the whole thing on GitHub, and I'm still to this day, going through the issues and fixing stuff, where people are submitting bug reports. That's a lot more of a, I'd say, true open source and community-driven thing that's been really fun.

Celeste would be, it's something that I would like to explore opening more of in the future. It's just this kind of weird ground that I haven't totally figured out yet. Because it's in C#, it lives in this kind of interesting middle ground where like, we haven't technically released the source code, but it's in C#, so you can decompile it to almost exactly what we had minus comments. So, it's people who mod it and want to mess with the actual code can do so fairly easily. But we haven't officially like released it all.

[0:12:03] JN: Right. I feel like, I mean, I know at one point, the framework you used for it was four parts of the framework, a version of the framework is open source you've released. There's whole blog posts about the lighting system and the physics system. I guess, even without the comments, people could put together a lot of your intent by this point.

[0:12:20] NB: Yes. They can get quite a bit. Obviously, the modding scene, not because of us, but because of just C# and [inaudible 0:12:26], they've made really amazing stuff by pulling apart the source code, because C# just happens to be so decompilable. We didn't go through any effort to like hide the source code. So, yes, the amount of stuff out there now that people have been like doing with it is really, really cool. Something I kind of want to push for in the future games, but not something I was expecting at all. So, I wasn't prepared for it.

[0:12:49] JN: Right. So, you mentioned Celeste 64. It's just really funny to hear that you're still patching bugs on it, because I think you posted on Mastodon a while ago, it was a meme that got out of hand. So, it's really funny to hear that you not only released and you shipped that meme, but you are getting to maintain that meme. Can you tell us a little bit about Celeste 64?

[0:13:05] NB: Yes. It was basically a meme, I guess. We weren't planning to - we threw around the idea of, "Oh, it'd be fun to do something for the anniversary, because it's been six years since Celeste came out." Three years ago, we did like the Plus Celeste Classic 2, which was like a PICO-8 game, kind of in the style of Celeste. We just want to do something like that and we threw around a bunch of ideas and Celeste 64 is the one that seemed funniest, and like, kind of most exciting to work on. But we also didn't want to spend a ton of time. We were still like in the midst of making Earthblade and trying to get it done in a reasonable time. So, we didn't want to take too much time off. It's kind of like, "Well, this sounds like a really fun idea. We really want to do it. So, maybe we should try and just allocate like a week." Then, it took more than a week. But it was a lot of fun.

[0:13:51] JN: It doesn't sound like it took much more than a week. Right? It was like a week and a bit, I think.

[0:13:54] NB: Yes. I think it was 10 days. But I definitely burnt out a little bit, because I did not sleep a lot. It was really, really fun. It felt like an extended game jam. But I don't know if it was the best idea. But it was a lot of fun.

[0:14:06] JN: I do like this tradition you all have of doing your own anniversary game jams for the game. I do think that it's very cool. Especially, while you're working on other larger projects. I imagine that must be a nice break of cadence at the very least.

[0:14:17] NB: Yes. It's kind of a good leg. I know other companies they'll do games like around the holidays and stuff. But sometimes do you like, "Oh, we're taking a week off to make something else for fun." Yes, we're just taking a small break and doing this and it was really fun. Then, you come back to the main project with like, a bit more like fresh eyes and ready to kind of dive in again.

[0:14:36] JN: Yes. I mean, I had a logo of - Celeste 64 kicked my butt in an even more severe degree than like Celeste and Celeste Classic 2 did. I don't know whether it's just the 3D-ness of it, but I just - even that first jump onto the wall. I just could not do it for the longest time.

[0:14:51] NB: Yes, it's not the easiest. It's a bit janky because we made it very fast.

[0:14:56] JN: It's great that we need to get it. I guess, for listeners, it's like I mean, inspiration is in the name, right? It's like it's 3D but it's like low polygonal. Nintendo 64 graphic kind of style. How did that style come about? That's just because what was achievable in 3D at the time? Or did you explicitly set out to do that?

[0:15:10] NB: We intentionally set out to do that. I mean, there's a few aspects of it. One thing is that we worked the game entirely in my own little weird C# framework, which has not been used for 3D. It was only a 2D thing. Part of it was like, we're not going to do really intense lighting, or modern graphical effects, because this engine does not have any of that in it. So, it was mostly just - the limitation thing, I guess, that I talked about earlier with the PICO-8 which is like, we one, want to actually finish this thing and we also just want it to be like use limitations to kind of our advantage of like. If scope is down, limit ourselves in terms of how it looks, and how it feels, and the size, and scope and everything, then maybe we can make something kind of cool in that space.

That's the main reasons. Also, we kind of wanted to make sure that it was a meme in a certain sense as well, because we didn't want it to - when we're releasing it, we want to make sure that it has this appearance of not a serious project. We don't want people coming in expecting like, "Oh, this the next Celeste thing." Because there's a lot of people out there who want that and we don't want to like mislead or confusion around, why is this weird free itch.io game the next Celeste thing. It kind of had all that balance of just limitations and scope and expectations and stuff like that.

[0:16:26] JN: That makes sense. That's a really cool approach. In the move to 3D, obviously, you were still trying. It still was a Celeste game mechanically. Were there any mechanics that you found, that you had to like, a little bit difficult to get into that new environment? Or you had to change around a bit?

[0:16:40] NB: I mean, it all happened pretty fast, because we didn't have a lot of time. But yes, even just simply thinking about how the dash would work and we decided to make it - you don't you don't dash literally 360, or like 3D 360. It's not a full sphere of dash direction. It's like a plane of dash direction. Just getting stuff like that, thinking, how do we actually want to implement that? Other stuff that I think we would have spent a lot more time on if we had time. The camera is quite bad, frankly. But I think that's partially because we didn't expect - we haven't made many 3D games. So, we weren't really expecting what would happen there.

I think we're pretty happy with how the player feels and everything. But the camera could have used a lot more iteration, and that's because I think we just didn't allocate kind of time towards the camera, because we weren't thinking about it, because we're not used to thinking about it. Then, all sudden, I was like, "Wow, actually, this matters a lot." But that would have turned into weeks-long, months-long thing.

[0:17:35] JN: I think the camera control, if you're going for like invoking N64 nostalgia, it definitely does that. It's a very N64 camera, for sure.

[0:17:43] NB: That's probably true.

[0:17:44] JN: So, I guess going back to main Celeste, there's a no-clip documentary in Celeste, which is wonderful. In that documentary, you're talking about the testing process and the iteration process. Because as a platformer, as tightly tuned, as Celeste feels. I mentioned, there's a lot of that that goes on. But you said this really interesting thing, which is during testing, and whilst you're like responding to feedback, that you don't want to polish all the edges off, which was like a really interesting comment, I felt. Can you talk a little bit about, if you can recall in this interview, hopefully you can. Can you talk about methodology?

[0:18:15] NB: Yes. I don't remember specifically what I was talking about there, necessarily. But yes, I think, when we're - this is also more on Maddy's realm, for sure. But like when we're play testing stuff, you're trying to strike this balance of what is - especially in a platform like this. What is actually fun for the player? What's a fun challenge? And what is not working as intended? So, a lot of the time like levels kind of have these stories in them, and you are kind of trying to get the player to do a specific thing, which is jump over here, and then climb this thing, and jump over that, and then fall down this thing. You're trying to guide the play into that kind of story you're trying to make. Sometimes the story could change as you play test and watch. "Oh, that wasn't working at all."

So, they're doing something else that's way cooler. I think just in that area, you don't want to like - the game is about platforming, you don't want to make it so that there's never any kind of conflict in the level, I guess. But you also don't want it to do, have unintended things that don't really match what you're trying to do with it. So, I think when we were playtesting, we just eliminate a lot of like, basically almost like bugs, I call them. Things that we were not expecting, or things that just weren't feeling right for the player. But keep things that are actual challenges and fun, fun edges in terms of in the space.

[0:19:32] JN: That's awesome. That makes a lot of sense. I guess, to go back from there, back to the GitHub. On the things that the GitHub does contain, which actually was one of the things I think I knew about this file before I played Celeste, because I'd heard about it, is the player class for the game, which is, I believe, 5,000 lines long. I was familiar with this file, as like, I'd had heard the lore of like, "Hey, this is a great example of what it takes to make a really great fitting platform." I look at all the constants and the conditions, checking every permutation of ways this player could exist, and then modifying how it moves a little bit.

So, I guess one question I had about that is when you have that file, and you're tracking all these unit, you're trying to iterate on this game, and you've got all these constants that like change, or like affect the movement in different circumstances. All these conditions, in fact, move in different circumstances. How do you watch a test of the game or play a moment of the game and go, "I need to tweak this constant here." How are you tracking all those things as you're developing and iterating?

[0:20:31] NB: Yes. I mean, in terms of the player class, it is huge. That's kind of a monolithic class. It can be - yes, I think making that big can definitely make it sometimes hard to figure out where you need to be. But in general, you kind of get - we're quite a small team. So, it's me and Maddy doing most of the programming. You kind of get an intuitive sense of like, where things are, and we have these regions that we blocked off into as well, in terms of Celeste.

So, you just learn over time, like, "Oh, if I want to change how this part of the player works, you can just edit these constants." I definitely don't think it's the most like - if someone new comes into it, it's like, "Wow, this feels like spaghetti." It kind of is and I don't deny that it's a bit of a mess. But it works in terms of just like the player is - all the moves of the player is quite tightly coupled together. There's no like real salt - there are states, but they're quite intermingled and react with each other quite a lot. In that kind of environment, it feels good to just have it all there and have the constants easy to modify and tweak and just have everything in kind of one place.

I don't think, like Earthblade is more broken up. All the states are in their own classes and stuff like that. But that game is also more - the states are more defined. They're kind of more like, when you're in this state, you're doing this thing, where Celeste less is a bit more squishy and like flowy.

[0:21:46] JN: It makes a lot sense. This touches on a theme that we keep coming back to, I guess, to game devs, which is like this idea that - I don't know, because it only has to run once, it has to work. There's a lot of things you can do in game dev code that people would scream at you for in other forms of code. "You can just make the game." Magic constants are fine. They work. They're a good way of dealing with it. It just lets you crack on, right? Well, I definitely feel that looking at that code.

You mentioned Earthblade there. So, in that readme for that file, you have kind of like, I guess, a little bit of a retrospective, which I'd highly recommend listeners to read. I think at the time that was written, still written quite a few years ago, now that you've been working, going from Celeste into Earthblade, was there anything that you were looking forward to doing differently in particular?

[0:22:27] NB: Yes, definitely. I actually, I'd have to look at the remaining [inaudible 0:22:30]. Whether I was thinking, seven-ish, or six, seven years ago. But definitely, there's a lot of code changes that I have been doing in Earthblade and want to continue to do. I think, Celeste was definitely kind of a product of - it was a fairly fast game to come together, and I think the way I've coded has changed a lot in the last six years. Parts of it haven't, too. But yes, I think things are a lot more broken up in Earthblade.

Earthblade is bit more of a systems-y game. It's still platformer, but it has a lot more kind of systems and stuff, and that has just meant - there's a lot more kind of architecture around how stuff is structured and systems and states and things like that. Whereas Celeste is kind of like, "Oh, this game objects and they exist, and that's it." This in the scene and they just do their thing. Whereas Earthblade is a bit more like, there's proper systems and things that are running, and things are sending messages and checking with each other. A bit more maybe proper, in terms of a lot of people's idea.

[0:23:31] JN: Cool. Awesome. Well, I mean, speaking of Earthblade, I'd love to chat a little bit about that. I guess since it's not out yet, it might be useful to give listeners a bit of an intro. Can you tell us a little bit about what Earthblade is? Well, what it is currently, at least?

[0:23:44] NB: Yes, that's going to change it probably. Yes, Earthblade is a game that the Celeste team is working on. We started like a few years after Celeste. So, it's been working on it for maybe two and a half years, something around that. It's also a platformer, but it's taking a different space than Celeste. So, Celeste was about movement and levels. Earthblade is more, a bit more combat-focused and more exploration-focused, I think. So, the space is kind of larger, and the levels are more like - well, I can't talk too much about the levels. But it's a space that use kind of more freeform exploring.

[0:24:15] JN: Yes. I guess, you can't speak about levels. The trailer you release at the Game Awards very much does do like a camera pan across like the whole world kind of idea. It seems, so far, at least from that footage quite open.

[0:24:26] NB: Yes.

[0:24:27] JN: Obviously, we talk about Celeste being built on. I already, at the time, deprecated framework. Is Earthblade also XNA? Have you moved on from XNA now?

[0:24:37] NB: Actually, we did it first move on. So, for the first part of development of Earthblade, it was written in C++, because at the time, I love C# and working games in it. It was a lot harder to port than other stuff. This is kind of getting into the technical parts of C#. But at the time to get our game running on consoles, we used a transpiler that would take the C#. So, C# gets compiled into an IL code, and then that gets run on your computer and turned into actual bytecode at runtime with a time compiler. So, at the time, it would take the C# IL code, and then translate that into C++, and then recompile that for the target console. The version of Celeste right now that's on all the consoles is C++, but it's translated with a machine, or the program from the C# IL code.

[0:25:27] JN: The original XNA, then FNA, on one game, depending on the platform, and then transpiled to C++ from there still, okay.

[0:25:33] NB: Yes. Exactly. So, it was kind of this like big rigamarole. It's really cool. The technology, there's really great, and the person who did all that work is amazing and they did the ports of Celeste for that. It was kind of like I wanted to be in a situation where it was easier for us to just kind of like, whenever we want to just compile our game with the existing code to whatever platform we want. So, that meant C++. That said, though, as we worked on the game, there's been a bunch of changes to C# and one of them is called Native AOT, which just means like, ahead of time compile, just like what every other -

[0:26:08] JN: Just normal compilation, right? It's what people think of, compilation.

[0:26:12] NB: Yes. It's what people think of compilation. C and C++ and Rust, and all those things, that's their default, is they ahead of time compile. Whereas C# default is compiling to an intermediate language, and then compiling at runtime. Anyways, to say, in the last few years, C# has gotten a lot of progress in terms of like ahead-of-time compilation, which means that it's a lot more accessible to have C# itself just running on consoles natively, which is really great.

So, about a year ago, we actually ported Earthblade to FNA, which is the open-source port of XNA. That's what it's in right now, which is - and that was mostly just because we like working in C# a lot more than C++. There's no compile times anymore. It just runs really fast. C# compile times are like, one second. So, things like that were really nice for iteration. Then also, because of the changes to C# in the last few years, it's just a lot more straightforward for us to actually - we can just compile our code directly to the platform where you want.

[0:27:15] JN: Right. Awesome. Aside from that language switch, you mentioned the way you program a lot has - the way you program has changed a lot in the last six years. Any like other notable technology changes that you're going with this time that even weren't available? You weren't using for Celeste?

[0:27:31] NB: Yes, there's a lot of stuff that we're doing differently now. We have a lot more tools in terms of like - Celeste has kind of - there's a lot of weird janky stuff and Celeste. I think the player class even has a big start of it, where it just defines when to play sounds on certain frames and stuff. It's like a very rare thing to have in your player code. So, things like that we have tools now that ticker Aseprite files and Aseprite Pixlr program, but it has built in animation. Import Aseprite files, and then we can place where we wants to have, like the sound designers can go in and actually play sounds where they need sounds to be. Then, proper things like that, so that we don't have sound timing inside of our player code randomly for animations, or an enemy doesn't have to like say, "Oh, on frame seven, play the sound." Our audio designers can actually just go into the editor and place the sound where they want it to be and stuff like that.

There's been a lot of changes to C# as well. It has a lot more - they've been doing a lot of performance stuff around like stack allocation stuff and avoiding garbage collection calls a lot more. So, I think my time in C++ too, I spent a few years making stuff in C++ has kind of like changed my thinking around you how allocation stuff works. I learned a lot about how computers actually work and stuff. So, I think I brought a lot of that kind of mindset into C#, which I didn't really previously have just in terms of how to manage stuff to make things go fast.

[0:28:54] JN: Right. That's cool. Exploring C++ and learning that, was that why you built blah? Was blah your -

[0:29:03] NB: Yes. Blah, my weird C++ came from it. That's why I built that. I was as making both - Earthblade was built on top of that for a while and I had a side project that I was making in that. That was kind of my attempt at just like porting the parts I liked about XNA into just C++. I'm just going to use C++. I'll just make my own little like framework. It has its own Aseprite batcher and can draw stuff like OpenGL or DirectX.

That was kind of my experiment into that, which was pretty fun. I had a good time with it. But yes, C++, I'd never 100% got comfortable with C++. I'd say I was fine with it and I had a good time. But actually, working on stuff on a day-to-day basis never felt quite as nice as just like coding in C# to me.

[0:29:51] JN: Right. Because for reasons other than like, the compilation times and the iteration cycle. You caught up by foot guns a lot. I thought that's like a lot of the fun around using C++, right?

[0:29:59] NB: Yes. There's a lot of issue around C++ - yes, C++ has a lot of like design problems, and even stuff in their newer code, they'll have - they introduced like co-routines. But there's all sorts of weird memory issues with that. It's really easy to accidentally, like, I can't remember all the problems I ran into with new features that like, if you didn't use them in a very particular way, it was really easy to leak memory or have things explode in ways that were not very intuitive. I mean, I like managing memory. But in C#, I like the ability to be like, when I need to, I can really care about how things are allocated and where things are going. If I need something that happened fast, I can do that.

Then, when I don't care, because it's like a main menu or something, I just allocate stuff and throw it away. Who cares? Because it doesn't actually matter for - especially our kind of game. If you're making a really high-performance, first-person shooter or something that needs to be like, ever CPU cycle basically matters for them, then that's a different conversation. But for us, we're a small team, making a platformer. I want to be performant where it matters and be able to kind of have the ability to make stuff fast and iterate on things faster than worrying about like, how specifically just being allocated. 

[0:31:18] JN: Makes sense. So, I guess while I'm talking about making your own tools, and what tools you use in Earthblade. For Celeste, I believe you made a map editor, level designer. The distinction between the two is blurry to me. You made a map particular to [inaudible 0:31:30], which later was rebuilt in hacks and open source, which is super cool. Is [inaudible 0:31:35] returning for Earthblade? Or are you making new tooling again, or using something else off the shelf?

[0:31:40] NB: Yes. For Earthblade, we're using our own tooling, or any new tooling thing. For Earthblade, we just have a level editor. We have like an entire editor, that like I said, was editing kind of animation and sound stuff. So, we call it like a sequence editor, which is basically actions. You can put in like sprites or animations and then add sounds or we also do like hitbox frame data and stuff like that. Then, we also have other tools like the map - we have a map editor and that's really nice for C#, because C# has reflection, which is really cool. So, we can just dynamically load - we can add a new game object to Earthblade and then it just immediately shows up in our map editor. We have to do anything - now, it's in our map editor and we can like place it there and do stuff with it.

So, having the editor built around the game itself, like in the actual same - it's not the same code. It's different - through different EXEs and different libraries and stuff. But having it be able to just kind of like import the game, and then edit stuff is really nice. So, as much as I like external-level editors, yes, we did an external-level editor for Celeste, having integrated into the actual project is really nice for Earthblade.

[0:32:41] JN: Perfect. Moving on to, I guess, the gameplay itself and what the game is. So, I noticed this, first of all, on the web page, and then the team dug into it a bit in, I think, a Q&A you did on YouTube in 2023. So, it's described as an explore action platformer, which when I first read that I was like, "This sounds kind of like a Metroidvania." But then you actually, in the Q&A, you explicitly said like, "We're not using the word Metroidvania, because we want constrain ourselves." Which I think is, in this time where everything is either a soul's like, or Metroidvania, or whatever was a really interesting comment. Can you talk a little bit about like, the constraints of the Metroidvania label that you're trying to avoid, without giving too much away about what you're trying to build, I guess?
[0:33:17] NB: Yes. For sure. I mean, I think ultimately, people would call it a Metroidvania. Casually, we do, too. But I think, like words like that are definitely useful. We're just trying to, I think, manage expectations a little bit about what kind of game it is. And I'd say it's not - it's a bit more - the game itself is a bit more based on exploration. Metroidvania is very based on exploration. I want to say that in terms of like, there's not really like room so much in the game. You're kind of just exploring these spaces and it's very freeform in terms of how you're doing things and where you're going.

I don't want to get into too many details. But it's not as much of a Metroidvania in terms of like, get this powerup to open that door. It's more of just like, there's a big space, and you're kind of going through it. That's why we're kind of using more - it's more of an exploration and action game. But it's going to be called a Metroidvania for sure and that's fine too.

[0:34:06] JN: Yes. Awesome. One of the other, well, I'm talking about things you've done on social media for the game. One of the post. I think it was Christmas. You've already teased a sequence break for Earthblade X OK social media, which given how successful and popular Celeste is with the speedrunning community, made me wonder like, are you already thinking about speed running as you're developing the game? I know you've mentioned in the past that you hadn't really - I think Maddy said this on the Reddit, maybe, that you hadn't really thought about modding before you built Celeste and now you are much more aware of it. Is that a similar case with speed running?

[0:34:40] NB: Yes. We're definitely thinking about it as we make the game. It's definitely really important to us in general. Speedrunning was really important to Celeste and its longevity. I love watching speedruns and that entire scene. So, want to make the game with that in mind for sure. I think it's a different kind of speed run game. It won't be run the same way that Celeste is, because it's a good some kind of game. Celeste is about the movement tech and how you can like push that to the extreme. Whereas, Earthblade, I think will probably have less like obvious movement tech and be more about like, it's a bit more in the Metroidvania kind of sense -

[0:35:16] JN: Critical halves and what can't what you can skip and -

[0:35:18] NB: Yes. Totally. So, it's going to be a different kind of speed run, but it's definitely still in our - what we're thinking about.

[0:35:24] JN: Awesome. Speaking of the Celeste speed running, I mean, I know it's been a long time in a very big community. But was there any like particular speed? What was your speedrunning, oh, my God, they're doing this to my game moment for Celeste, if you can remember that far?

[0:35:39] NB: Yes. I think when it broke 30 minutes, the speed run. I was like, "Wow, I never thought that would happen." Celeste is about like, there's not actually - there's not really sequence breaks in Celeste, so much is just like, really amazing movement tech and there's short sequence breaks that are like you can skip this kind of object or under this thing. The physics itself doesn't really allow for clipping through multiple rooms, or skipping entire large segments. So, it's mostly just like an accumulation of like thousands and thousands of really specific little movement techs that get you to where you need to be way faster. All that stuff combined is kind of really impressive to me and how people managed to - because we knew there was a lot of moving tech, but I don't think we knew that it would go as far as it did.

[0:36:26] JN: Yes. Speaking of the physics, this reminded me of, I think, Maddy had written in the past about the physics engine used in both TowerFall and Celeste, and about the fact that you wrote your own physics based on AABB, which is axis-aligned bounding boxes, I believe. I guess I wanted to ask, I think a lot of people come into game dev now are very used to like, "Hey, I need to pick up this game engine that has everything included, and I use the APIs that are given to me." So, I wanted to ask a little bit about like, what led to the decision to roll your own physics for those games?

[0:36:56] JN: Yes. I mean, we took the approach a lot. We don't use game engines. We kind of use open source frameworks and we use - we kind of roll a lot of our own stuff, which is both good and bad. It can backfire sometimes. But mostly just control over how we want the stuff to work. I'd say like, we're both fairly competent programmers. We're not definitely the most technical or the most, doing the most high-level stuff or anything. But we're comfortable making, for example, a physics engine that is simple. It's not a true physics engine. It's not doing all the stuff like boxy or something. It's mostly about I think, control, and how - if we want something to change, we can kind of just do it. We're not fighting with the system that's kind of like a black box of like, "Oh, it's just doing this thing." We have to work around that.

So, it's much more about just like, we really care about very specific intricacies and how stuff moves and how stuff collides and how stuff reacts. To do that, it just felt, it's kind of like why - the actual physics of Celeste is very simple. It's excellent bounding boxes. They move pixel by pixel and don't overlap with each other. So, the code part of that is like, fairly simple. Why not do that and then we can have full control over what's happening, versus, yes, a black box, where we're kind of fighting with what is decided to do. I think you can get the same result if you use an actual physics engine, but it'd be a lot more like fighting, or turning off 90% of the features. It's like, "Why are we going through this instead of just kind of making our own thing?"

Yes. I don't think there's necessarily a right or wrong answer there at all. Just what we find comfortable, and what's the fastest way for us to kind of get what we want out of the code, and out of the systems. That often means, it's actually nicer and easier, just like write our own 500-line thing, then use an entire huge library that was in megabytes and stuff.

[0:38:44] JN: Yes. I know. That makes perfect sense. I'm glad to hear that explanation. Because the size of the commercial engine is getting so big, I think there's an instinct that I should make the choice that has everything I ever possibly need ever, even though I'm never going to touch it. Instinct, right? Rather than using the tool side that I need to finish the game today. So, it's good to hear.

[0:39:03] NB: Often, I think that you can even, if you decide, like, "Oh, I really need this thing. There's often really good libraries out there that do provide that." If we decided, "Oh, you know what, we really do need a physics engine. We really need stuff to bounce off in certain ways, and have friction and all this kinematic stuff that we could use box 3D, and it's an amazing library that is open source and available.

[0:39:23] JN: I imagine it has FNA. So, we've mentioned a couple times throughout the interview, the fact that the team quite often builds things in game jams that comes out of game jam. So, going back to that 2023 Q&A, one of the things that the team was talking about was the fact that Earthblade has taken a little bit longer because the first game that you've made from scratch, that hasn't like come from a game jam prototype or someone's personal project. I was interested in like, I mean, A, how that is for the team approaching and building a game the different way from a different foundation, but also, I really was interested in what the difference in your processes doing that?

[0:39:55] NB: Yes. It's true that almost all the other games we've worked on have come out of quick experiments. Then, I think I can give a lot of direction to the game because you're kind of like we're making this game and this is what it is. Then, it just goes. If the game jam version works, then you're just kind of elaborating on it, in a sense.

But yes, with that, I think there's a few things that doesn't always work. You can't make a game jam for certain kinds of games, because it's just you don't have enough time to actually implement the mechanics that are required. So, I guess there's a - for Earthblade we had more of a slightly larger scope and larger idea for what we wanted mechanically the game to do. So, I think it came from there, where just we - I don't think we wouldn't make a game jam version of Earthblade very fast. I don't think we'd be able to pull that off, because it just mechanically requires more stuff.

I'd say one is, it lets us kind of make stuff that we're not super used to, which is fun, but also make stuff that we're not super used to and that's actually quite hard. We're kind of outside our comfort zone, for sure. That means it's taking longer and a lot more experimentation. Celeste was extremely smooth, because we had this kind of like foundation of like what the game is. Now, we're just making that game and make level one, and then we make level two, and make level three, and then we're done. Earthblade is a lot more of exploring the space. So, it's taking us longer and will continue to take us a bit longer.

[0:41:21] JN: Perfect. I guess, kind of a related question. But you mentioned Skytorn earlier, which was another Metroidvania that you're working on, and when that game was canceled, one of the reasons for its cancellation was it had never worked out what it wanted to be. I was sitting here being like, "Skytorn and Earthblade, it's like the same name, but opposite." And it's also Metroidvania. It's also made by you know. Is Earthblade, to some extent, Skytorn finding itself? Or is it completely a different game?

[0:41:47] NB: I think definitely there is a lot of that. Skytorn, there's a lot of Skytorn spirit in Earthblade, definitely. The main issues of Skytorn at the time was that I was trying to make a Metroidvania. But I was trying to get proceed procedurally generated one. I was trying to explore that space and it just was kind of clashing because I had this kind of story I wanted to tell, and it's dynamic, and can't get the procedural generation to work in a way that actually made them more interesting. I could have gone way more into like, "Push it way more in a Terraria kind of direction, which is like, more sandboxing, more actual procedural space." Or I could go way more into more of a story-driven thing. Those two things were kind of fighting each other.

I could never quite mesh them together. It was kind like why am I making a procedural thing if I'm trying to tell the story? At the time, I didn't want to just make a direct Metroidvania. So, it's like, well, it's this game. If I take out a procedure on this stuff, it just kind of feels like a very standard Metroidvania, and I wasn't very excited by the idea at the time. And then with Celeste, Celeste was kind of like in the middle of development. Well, this seems this product has a lot more direction right now. It made more sense at the time.

But I'd say that yes, Earthblade definitely takes a lot of the spirit of Skytorn and what it was trying to be. But obviously, Earthblade is not procedurally generated. It's a designed world in a designed space. I didn't know where to end that, exactly.

[0:43:09] JN: Skytorn lives on in some form. As we get towards the end of the time, I guess, kind of keeping on this theme of how your work together. It's been a long time now and a lot of games and it's more or less, as far as I can tell, a lot of the same team across that time. You've been through -I know some of you are in Brazil, some of you in Vancouver. You've worked through the pandemic and lockdowns. As what seems to be quite a long record for like a small indie team. Do you have any tips for other aspiring indie developers or small teams that exists currently?

[0:43:38] NB: Yes. It's hard to give big suggestions. I think a lot of time what works would not work for other people, or is often a product of its time as well. A lot of the stuff, for our games, and where I am is just like, right place, right time, right setting, and all that stuff. But I think just finding products you're excited about making, and people you'd like working with is huge, which is obviously a given. But I think sometimes it can be easy to get kind of lost in the technical stuff, or trying to learn everything ahead of time, or figure out exactly all the stuff you need to know. Sometimes it's better to kind of just find people you like working with and to start making something, and then worrying about the ramifications and all the little details later. Because as long as you can kind of like get started on something, that's the most important thing.

[0:44:27] JN: Just make stuff with cool people is an enduring tip. Then, I guess, another thing we spoke about quite a lot, which is you've made a lot of game frameworks, you've made a lot of tools. I have noticed that this does seem to be an addiction of game developers to make lots of tools along the way. What attracts you to making game frameworks. You mentioned Foster, we spoke about blah a little bit, and I imagine there's others elsewhere. What keeps bringing you back to doing that?

[0:44:47] NB: I think it's mostly just I like learning the code stuff. I like learning about how systems work. I kind of like exploring that space a little bit. I love making games and I like making - that's definitely what I like most. But there's times and I kind of just like the systems, the engine stuff of just like what is involved in making something that is much more just like a system. I also, like, I said earlier, kind of what the black box thing of using something off the shelf versus using our own stuff. I like the learning process of using our own stuff and like seeing, "Hey, what does it actually take to this? Do we have this gigantic engine? What is actually involved in like making our own thing?" A lot of the times, it's not actually as much as I would expect to make this stuff. It's not a lot of code. It's definitely a learning process. I've been learning how the stuff works over a long time. But oftentimes, it ends up being easier than I thought it would be, and then it's fun. So, yes, learn a lot and it's fun.

[0:45:44] JN: It's awesome. I guess, kind of eccentric topic, if someone hasn't implemented the systems themselves and thinking like, "Oh, I'd be really interested in writing a physics engine, my own lighting system, or my own shader, whatever." Is it like a project from that world, you would recommend that people start in?

[0:45:59] NB: I guess, it depends on what specific like, for physics engine stuff, there's like more advanced polymer physics engines like Box2D, which is open source. You can start digging through it. But you probably need actual books on how the stuff works as well, which I unfortunately don't have recommendations for. But for simple AABB physics stuff, honestly, even the PICO-8 version of Celeste you can look at, because that's very similar to the actual code in normal Celeste, in terms how the physics work.

I can't think of other open-source projects. If you're more interested in like how frameworks work and how the game engines work, I think just looking at the source code for like FNA, which is the port of XNA, where you can kind of see like, this is a C# sharp thing that's running on top of SDL 2 to which a lot of stuff uses which is really cool. You can even just look at SDL 2 itself. The inner workings of SDL can be kind of complicated. But if you just want to try making something on top of it, it's quite friendly, honestly. You can just open a window and start doing stuff with it and it's not too bad. I think other projects that are really cool. Raylib is a really cool one. Like a C game framework, or, I mean, any kind of framework, but like a game-targeted framework. It's a little C API that has like a bunch of calls for like, "Oh, you want to create a window and then create a texture, and draw this texture in this place?", it has all that stuff ready to go, which is great if you're just wanting to write your own thing on top of it.

[0:47:30] JN: Yes. I think, this is a great recommendation. Thank you. I guess, that kind of brings us into the time now. Noel, thank you so much, and it's been wonderful.

[0:47:38] NB: Yes. Thanks for having me. This is super fun

[END]