EPISODE 1694

[INTRODUCTION]

[00:00:00] ANNOUNCER: Animal Well is a Metroidvania game developed as a solo project by Billy Basso over the course of seven years. It's the first game released by publisher Bigmode, which was founded by Jason "Dunkey" Gastrow. Billy joins the show to talk about creating Animal Well's engine from scratch, how the game handles animation, fine-tuning character movement, 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 Gary's Mod. And game development remains his favorite way to experience and explore new technologies and concepts. 

[INTERVIEW]

[00:00:54] JN: Welcome, Billy. Thank you for joining me today.

[00:00:57] BB: Hello. Happy to be here. 

[00:00:58] JN: We've mentioned in the intro there that, obviously, you're developing Animal Well. Before we get into what that game is and what it's set up to be? At the time recording, not yet released. Coming out very soon though. What was your starting to game development? What led up to the development of this game?

[00:01:11] BB: Yeah. I've been a fan of video games my whole life pretty much as far back as I could remember. It was kind of a, yeah, meandering path into game development. I think growing up, I was into drawing and I thought maybe I wanted to be an animator or a cartoonist. And then later on in high school, I got into like making videos with my friends and uploading them to very early YouTube. I actually went to school for film thinking I would want to get into that industry. 

And then that kind of just ended up and ended up not being quite as passionate about it as maybe I initially expected. During that time, I also was kind of learning to program on the side during my undergrad. And by the time I was done with my film degree, I decided that I actually enjoyed programing way more than any part of film production. 

I went back to grad school and got a degree in computer science. And then it was during that process also I realized like, "Oh, I can make video games by doing this." I started out using the programming language processing. And I was doing a lot of just like visual sort of interactive little toys and stuff. And then it was like while I was messing around with that, I made like a little Space Invaders clone and kind of sort of stumbled into all the building blocks that you need to make a game. And I was kind of learning like object-oriented programming at the time. And then when you think of that, you're like, "Oh, well." You start thinking in terms of like entities, and enemies, and sprites on screen. 

And so, yeah, I just found that to be very, very fun. Kind of got addicted to it. And then, yeah, then I kind of figured out. It's like, "Okay, I want to go into the game industry." All these things that I was kind of learning that are tangential to video games are all kind of pointing me towards this one direction. It took a while to like figure that out. And it seems kind of obvious in retrospect, because video games were probably my favorite hobby throughout my life. 

And then after that, I worked at a few different studios in Chicago. I worked at Phosphor Games for about two or three years. And then I went on to NetherRealm. That was also in Chicago. They make the Mortal Kombat games. And then I moved on to like a medical startup that was making video games for doctors. I kept kind of moving between jobs industry and kind of I was always working as a programmer. Just it was throughout that time, maybe a 10-year period, that I kind of developed my programming skills. 

And then, yeah, about seven years ago at this point, I started working on Animal Well as like a side project. Because I just never was really able to make the type of game that I wanted to make. It was either there were mobile games or had a lot of online software as a service kind of things in them, or ads, or microtransactions. I was like I still want to make the type of game that I was hoping I would be able to make. And so, it began as a side project. 

And I didn't have a lot of sort of large ambitions for it in the beginning. I thought it would be a really short game. And it would take like six months to make. But, yeah, I just kept kind of growing in scope as I just - because it was just always like a hobby that I would work on. There wasn't really like an end in sight really. But, yeah. That's how the project got started.

[00:04:28] JN: Perfect. Yeah. Having been lucky enough to spend a couple of days with gaming to lead up to this, it is not a short game. There's a lot there. I'm glad it got the time. Obviously, you mentioned wanting to build the game that you wanted to make. What is that game? Tell us about Aanimal Well and I guess the concept behind it.

[00:04:45] BB: Yeah. Animal Well is a game that offers no guidance to the player. It's this big, contiguous world that you get to explore. It's kind of a pixel art Metroidvania. It's very lush atmospheric environments you get to explore. And, yeah, the game is just packed full of secrets. And the secrets have secrets. And there's hidden passages everywhere. And it's all about learning how things work in the game without explanation. Kind of just building an intuitive understanding of everything you encounter. And then I guess that's pretty much it. 

An interesting thing about it is like I was sort of just designing it following my own kind of desires and intuition. There isn't a good pitch for the game necessarily. I didn't have a marketing plan. I didn't do like market research on what would be a viable style of game to make. I was just making kind of very purely what I wanted to make. 

And then years later, when I started working with Dan, we had to like figure out like what is this game? And how do we get people to care about this? Because I just sort of crafted this world. But on its surface, it's hard to describe what's special about it, because it's a 2D pixel art Metroidvania, which people have a very specific image in their head of what that means. 

And there's countless very derivative games that are following that genre template very closely. And so, it's hard to describe how it differs from that. And it's more almost just using genre labels is a kind of reductive way to describe it. 

[00:06:20] JN: Yeah. Yeah. I think it is having - I think it definitely deviates from I say that template really, really strongly. And one of the things that struck me is relatively no violence. The exploration is really important. But, yeah, I also - that must be - that's a really interesting challenge on how you describe it. I think you've seen somewhere that it's just like a game about mysteries or something. And I think that rings very true. Yeah. I think that's really appropriate. 

I guess onto the actual game itself. You mentioned there pixel art. I think any one who's seen the images of the game would have seen this kind of like almost surreal is a term used a lot, like dream-like thing. There's one particular visual effect that caught me from the moment I first jumped, which I think is above the pixel art. But there's almost this like segmented display overlayed on all the art. You know what I'm talking about? 

[00:07:07] BB: Yeah. The scan line effect? 

[00:07:07] JN: Yeah. Exactly. Yeah. Yeah. Well, I guess I was interested, first of all, how did you settle on that effect for the visual style? And how was that implemented?

[00:07:15] BB: Yeah. I've been a pretty big fan of retro games. I have actually a few CRT televisions in my house. And that's like how I play all those games. And when those games were developed, they were sort of - the art was authored in a way that was intended to be viewed on a CRT display instead of a sharp pixel LCD screen that we see today. 

Doing that, you can kind of create smoother gradients across surfaces. You can create transparency effects if you're expecting kind of the neighboring pixels to get blurred together a little bit. If you have like an alpha checkerboard and then you display that on a CRT at like an appropriate resolution, it'll kind of look transparent. Especially if you're doing it through like a composite video signal, then you get even more sort of weirdness with a signal kind of interfering with itself. 

I just thought that was a lot more. It was a more interesting way to display pixel data than just like the clean, crisp squares that a lot of like sort of modern indie games do that are using pixel art. Yeah, that. And then the fact that, yeah, I was playing games on a CRT, I kind of had a good reference to look at. And I was trying to go for like kind of a higher-end Sony PVM. The kind of clean horizontal scan lines. Not like without like a lot of sort of interference in the colors. 

And so, a lot of people kind of have issues with sort of retro CRT effects in games because they will like really artificially make the image kind of look crappy. They'll add distortion. Or sometimes they'll do really dumb things like add film grain or something. There's a lot of like very poor, old retro video effects that sometimes don't make sense. Or the scan lines and a lot of - worst of all, they'll make them not even line up with the pixels properly. It literally just looks like an image overlay. 

And so, I understand people being like fed up with that and demanding an option to like turn that off. I was also - and, also, I get kind of annoyed by seeing that on a lot of games. I was very motivated to like, "I'm going to do it the correct way. I'm going to actually render the game at this low resolution internally," which is seems like an obvious thing you would want to do for performance and all those reasons.

And, yeah. I don't know. I just thought it was fun to do. Pretty much, it's a shader that runs right at the end of sort of the rendering process. And it'll do bilinear filtering on the - well, it does bilinear filtering to upscale the game's internal resolution, which is just 320x180. The game runs at a very low internal resolution. And then say you're displaying that on a 4K display, which - it's like 144 times as many pixels you need to like stretch it up to, yeah, I just do a linear upscale. But then I clamp the Y-axis back to the sharp pixel center. I get a kind of a free performant blur on the X-axis, but then I keep it sharp on the Y-axis. And then there's some other effects to sort of actually, based on the pixel's luminosity, I will sort of fade off the edge of the scan line differently. 

And then because it's also blurred, you get kind of a smooth variation between the width of the scan line. It actually looks like the electron gun is sort of scanning along and like it's getting the color signal as it goes. And it's sort of modulating in intensity. It's a pretty cheap effect. But I was happy with how it turned out.

[00:10:42] JN: Yeah. It works really well. It's beautiful. Yeah, thank you for the explanation. One of the things I saw you tweet recently, which I wanted to discuss, because the game has some fairly - I think the game is very accessible in terms of I guess the mechanical skill needed, the platforming element. But there are some very skill-intensive platforming segments. And you were talking on your Twitter about reducing the input latency and how important that was for you. Can you tell us a little bit about why you wanted to bring that latency down and how you went about doing that? 

[00:11:13] BB: Yeah. I guess it was just a personal goal. I think on the outset, a game about exploration and puzzles, you probably wouldn't expect it to demand a lot of high precision latency. This isn't like a rhythm game or like a really twitchy action game. But I think just the engineer in me wanted to get like the number as low as possible. It was just like a personal challenge. 

And I have a lot of sort of performance overhead by targeting like such a low output resolution. Really, anything I could do to use that available horsepower was of interest. To get the latency down - because it's a custom engine. I can kind of configure the update and draw loop and the way it presents to the screen however I want. 

Typically, in most games, you'll get input from the controller, and then you update the game logic, and you queue up a bunch of like draw commands for the GPU. And this is all - everything I'm describing right now is done on a CPU. And you use like your entire sort of frame time to do that. Say you want to target 60 frames a second. For those 16.66 milliseconds, your processing controller input, like updating the state of the world. And then at the end, then you'd send a big command list to the GPU and say like do all this work or render everything to represent this frame. And then while the GPU is doing that, you start processing the next frame. You get a lot of parallelism between the CPU and the GPU. But it adds a frame of delay. You're letting them work together, but it's like pipelined. 

For Animal Well, I don't do that. I do all the CPU work and the GPU work within one frame window. It's one frame faster than the theoretical sort of limit that a well-implemented game using like Unity or Unreal could probably achieve. And then there's like a lot of other ways you have to look out for that like latency can get introduced. If you're processing the controller input and then you're like changing the state of the character in the game, you have to kind of make sure that like there's some visual representation on screen like right away. 

Say you want to jump, a common mistake would be like, "All right, we detected the jump button was pressed. And now we're going to like -" say you have a big switch statement of what's the state. Is a player like idle? Or are they jumping? And then in the update logic you say, "Okay, we detected that we're jumping. Now we're going to move into the jump state." But then that same frame, you're still like drawing them as idle. And it's not until - or maybe the first frame of the jump state, they're still like on the ground and they're just like applying their velocity to themselves. You have to make sure there's like a visual indicator immediately on screen that like you did that state transition and you're not - it's easy to like add extra frames there kind of and not without realizing it.

[00:14:01] JN: Fascinating. Yeah, it definitely pays off. It definitely feels very sharp. There's a particular mechanic which I don't want to spoil it, but I would definitely be asking you about after when we're off recording that like the timing is so specific on it. I've found myself wondering like is this meant to be in the final game? And I think a large part of it is down to just my brain not being used to like very tight latency games. 

Change back to I guess like the visual element a little bit. Obviously, it's called Animal Well. There's a lot of fantastic animals in it. People have seen a lot of them in the trailers. And, in general, there's a kind of running theme of a lot of the animals that you encounter, especially in a hostile setting are larger than you and imposing and very impressive. And they all have really cool animations. And you did all the art yourself as well, right? 

[00:14:45] BB: Thank you. Yes.

[00:14:47] JN: Awesome. Yeah. Can you tell us a bit about how you approached these character animations, these characters, and developing those? 

[00:14:52] BB: Yeah. I think my approach has sort of evolved over the course of development. At the start, I had no tools to make this game. It was just a blank project in Visual Studio. And I made like a really basic level editor where I can put these like 8x8 tiles around on screens and sort of build up a world composed of those screens. 

And then early on, I was drawing really tiny sprites. And for like animation, I would just draw extra frames of them and have them kind of - I had all my sprites in Photoshop on one texture. My process at the start was just like draw some art on this big Sprite Atlas. And then in code, I would just literally type in the UV coordinates of defining sort of the box around the sprite. 

And then if I wanted to do an animation, I would draw the extra frames to the right of that sprite and then sort of use some arithmetic to offset the UV coordinates. That was like version 1.0. And I think early on at that point in the game did kind of look more like an NES game. The sprites were fairly small and the animations were like, yeah, pretty basic. 

And then I think a few years in, I started using a program called Aseprite instead of Photoshop to draw the animations. And that gives you a lot of ability to tag the animations, do multiple layers. It's just like a really nice program. And it's very cheap. I think it's like $10 or something. Highly recommend Aseprite. And it was like very refreshing going from Photoshop, which is so big, and bloated, and laggy, and crappy to a program that was very lean. 

I did that. And then Aseprite has way more options to like output sprite sheets. It will pack them into like a nice tight Sprite Atlas for a given animation. I started making things in there. And then you can also tag the animations for the different sort of states. I can make one animation file for like one animal for instance. And then within that animation file I have their walk animation, their idle, their jump, their turn, whatever they do. I would be able to kind of draw all the animations in one place and lets you like reuse frames. And it's just a nice workflow. 

Actually, from there, I modified Aseprite to output a custom binary animation format. I went in GitHub and like forked it and created a new export option for myself that would sort of pack all those frame data, the timing, and the UV coordinates that corresponded to the Sprite Atlas it would output into a sort of a custom very like low overhead binary format that I defined for my engine that I could pretty much - it doesn't really need to be parsed at all. I can just kind of like load it into memory and just plop it down. And then it just starts working in the game. 

Yeah, once I had that set up - and then, also, another important sort of workflow thing is getting all the assets in the game to like hot reload. I'm sort of monitoring the directory that all the assets go in. If anything changes, the game will know to like reload the texture, sort of reload the animation file. I can work in Aseprite, edit it, edit the animations and the art and then it will like instantly update in the game. That has been super helpful. And I'm glad I did that fairly early. Because I think kind of getting those workflow improvements in into a game will really just magnify how much work you can get done for the following years.

[00:18:19] JN: Yeah. Absolutely. That was on my list of things to ask when I heard you had built your own engine you were using for such a long time was how much - you're at the mercy of yourself when it comes to developer experience and how much you think about that.

Obviously, you mentioned building a couple of your own tools there. And the hot reloading of the assets, that is a really cool example of I guess build your own developer experience. But what other tools did you build along the way? What's the tool set around the engine looking like seven years on?

[00:18:45] BB: Yeah, a lot of it is just in the engine itself the level editor sort of built into it. At any point while I'm playing the game, I can hit like tab on my keyboard and it just snaps into a level editor view of where I'm currently at in the game. And that gets like compiled out in release builds. 

There, I can sort of build up the screens and I can build up the world. I have different sort of views. And then within there, all the sprites and animations that get defined, I can also like sort of edit sort of metadata about them. Whether what layer they should be drawn on. Or if they should have like collision data. Or a lot of things like that. Or if it's like a one-way platform, can you jump through it? 

A lot of it is kind of just in one place. And that's how the game gets made. And then I honestly still just lean on hardcoding of things in the game itself. Most of the gameplay parameters are just like in the C code. And that's mostly possible, because all the game play code is in a DLL that I can kind of recompile while the game is running. 

A lot of it is just done through coding. And because like the compile times are low and I can do it while the game is running, that's like kept that viable. If I had to do one thing at a start of a project, it would be like getting code reloading working as early as possible. Because I don't think I would have ever been able to finish this game without it, because so much of my design and development process is done through kind of trial and error where I just try out different values and mess with things. And so, that has sped up development a ton. Another fun thing that people get a kick out of is I use a midi controller to control a lot of like sort of parameters - 

[00:20:22] JN: That is my engine.

[00:20:24] BB: And then I can just bind variables to like sliders and knobs on there at any point I'm working. 

[00:20:30] JN: Amazing.

[00:20:31] BB: And sort of like mess with things to get the values right.

[00:20:34] JN: Yeah. That's fantastic. Because we have a recurring segment with developers who have worked on any kind of game that has tight controls like a platformer where we talk about their like hellish list of constant variables that control everything. Love the idea of those all being attached to dials on a midi controller. That is wonderful. 

[00:20:50] BB: Yeah. Otherwise, it's like, "Oh, let me type in - should it be five? Should I turn the five to a seven?" And then you go recompile and try. And then if you're trying to edit multiple variables at once, it's just so boring and like painful. But then if you could just like put four of your fingers on some sliders and just like mess around, it feels like a toy.

[00:21:09] JN: That's very cool.

[00:21:09] BB: And the game will be a lot better for it.

[00:21:13] JN: I would definitely be coming back with more engine questions. But staying on the animation for a sec. Aside from the ones, the sprite animations, there's also a couple of creatures that feel like they're animated differently. Namely things like the ostrich, which kind of has this like bandying about effect that seemed to me almost like physically based animation. Is that the case? Or is it just very talented sprite animation? 

[00:21:31] BB: Oh, no, no, no. That one is a lot of - it's actually a combination for like its body and head. Those are still like sprites that I kind of animated. And I would like - because the ostrich can turn. I had to draw it like torso from like all sort of different angles. And then through code, it sort of picks the appropriate frame based on what direction it's like trying to go in. But the legs and the neck, those are procedurally done and they're sort of just - I generate Bézier and then sort of extrude a tube along there. And sort of just like kind of create the vertices in code. 

And so, I've sort of built up a decent library of like these little utility functions to sort of draw different geometry and curves. And so, yeah, as development went on, I sort of was making more creatures that kind of took advantage of that. And, yeah. No. That stuff's super fun. 

I think anytime there's like an opportunity where like I can leverage my experience as both like an artist and a programmer, I try to do it. Because I think if I just had like an artist working independently coming up well in the animations, they wouldn't be doing stuff like this. So I try to incorporate some of the coding stuff into the animation when I can. 

But there are like things to consider. A lot of times, it can look kind of creepy and uncanny. I kind of have to the hand drawn sprite animation. That's the more charming human thing. Depending on the animal, if it's like threatening or not, I have to use that with care. The ostrich is kind of like meant to freak you out. 

[00:23:02] JN: And it does.

[00:23:03] BB: The fact that it moves so smoothly and like - it's like, yeah, so aggressive. It fits that. But, yeah, there's capybaras in the game which are just meant to be nice. And like they don't have any like procedural animation with them.

[00:23:17] JN: Yeah. It's interesting you mentioned having to draw from different angles. Because I think that was - I can't remember which. I think it was the kangaroo where like at one point I saw it turn and I was like, "That is really a ludicrous amount of -" the amount of like frames you draw of it turning was just too many. It was too smooth a turn for pixel art. It was ridiculous. It was beautiful.

[00:23:36] BB: Thank you. 

[00:23:37] JN: And the other animal I think was very striking in the creepy dimension. I have to ask, what have sausage dogs done to you? The little brown wiener dog was like an envelope. Just like, "No. I don't like this." 

[00:23:47] JN: I had one growing up, a dachshund, named Molly. And I don't know. Just love that dog. And, yeah, I think I learned later on that they were bred to like burrow into holes and like root out badgers. It's always interesting to me when an animal like has a skill that it's bred for and it's like actually really good at one thing. And so, on the surface, they seem like, yeah, really just these chubby little short dogs that couldn't really hurt anything. But, no. If you're in a tight space, it can get you. That's where it performs best.

[00:24:23] JN: Yeah. Absolutely.

[00:24:25] BB: I just thought that was funny.

[00:24:26] JN: Yeah. It was great. And you mentioned there wanting to combine your artistry with your programming. I think another area that really came through to me was there was just a real gratuitous use of physics sims in really unassuming places. The smoke when you blow up a dynamite. The fluid sim on like the ghosty boundary stuff. Water droplet particle simulation. Is that another example of this? Just throwing in physics sims to pretty things up? Do you just really like a good physics sim? Where does that come in? 

[00:24:56] BB: Yeah. I think it's just - yeah, they're fun to make. I did try to have to be careful and still make them feel like cohesive with the pixel art. Because it's easy, especially games like made in Unreal or Unity, they'll be doing pixel art, but then it's very tempting to just like drop on like their built-in lighting system on top of that or do these other effects that just like don't match the pixel art at all and they look like they kind of clash. 

But other than that, yeah, the fluid sim kind of drives a lot of the explosions and the smoke effects. That was fun to make. I actually like had to do a lot of work making fluid sims at my day job when I was at the medical company. I was like kind of trying to like leverage that knowledge to like, "What if I could put one in Animal Well? And what could that be used for?" 

Yeah, apparently, I've never seen another like pixel art game that has like a Navier-Stokes fluid sim just sitting in there. I think it's kind of a fun thing that sort of stands out in the game. 

[00:25:59] JN: Yeah. Not just the existence of them, but how they're used as well. They're not necessarily driving mechanics. All the tools are very physically driven. But the fact that fluid sim is like not a background effect, but is primarily a visual effect, it just really shows the attention in the game. It's really awesome.

[00:26:15] BB: Thank you.

[00:26:16] JN: Staying on physics a little bit. Metroidvania, obviously, there are tools or abilities that unlock new parts of the map, new areas to explore, et cetera. I guess starting, there's a particular tool that I want to get to. But starting out on the tools in general, as I think I mentioned earlier there, I really like this game is kind of almost nonviolent. Or that you're not doing violence. Anyway, violence is done to you, but you're not doing violence. And that the tool set is almost like not exactly a section of childhood toys, but they're all very like - there's a certain innocence to them, all right. The yo-yo, the slinky, frisbee, et cetera. Where did the tools come from? What was the development story behind those? 

[00:26:50] BB: I think they're all things that either I have sort of childhood nostalgia for. Or I was trying to make the game feel - I wanted you to feel kind of disempowered and like sort of take some inspiration from like survival horror games. Didn't want to give you anything that felt explicitly like a weapon or like a big upgrade. I wanted to - the items you got to feel, yeah, kind of curious and you had to like kind of use your brain to like figure out how they're useful and make use of them. 

And I think the fact that they're toys just kind of lends itself to that. And then, also, just like I think making game items toys, there's a lot of potential there for just like fun physics interactions. Because they're all like - they usually have something physically interesting about them like a yo-yo in real-life is fun to play with or frisbee. 

And so, I think you kind of are just getting a built-in cool gameplay effect when you choose to sort of take inspiration from that. That was always just like a big focus of the game. Anytime I was making a new feature is like I want it to be like fun to program and like fun to use in the game. The way it moved about needed to be interesting and kind of surprising.

[00:28:02] JN: Yeah. You mentioned the yo-yo, which I believe you called on your Twitter at one point the best yo-yo string in games. What goes into making a good yo-yo string? 

[00:28:13] BB: It's a lot of line intersections, I guess, with the world. For that in particular, I think when I - each screen is built up of like these tiles. And so, each tile can either like collide or not. They're 8x8 pixels. And so, I can do a line intersection with the screen and then pretty much find like what tile it's colliding with. And so, when you throw the yo-yo out, I'm checking between like the player character and the yo-yo, like does this line intersect anything? And if it does, it will sort of make note of that intersection point, which it will be one of the corners of a tile. And then it sorts of maintains sort of an array of all the intersection points. 

And then once it has that, it will then start doing intersections between all the - well, you only actually need to do intersections between the line segment connected to the player and then the line segment connected to the yo-yo. Those are the things that are moving. And so, you kind of just maintain an array of these intersection points. And then you can draw the path along them. And that lets the string sort of wrap around corners and behave physically, like correct in terms of like this 2D world. And then the yo-yo's always pivoting about the last like sort of corner that it wrapped around. 

Yeah, I think that was one of the first times where I felt like I made something in the game that could act as a hook for people. I think that was like one of the first tweets I ever made that got a decent number of likes. And, yeah, I'm trying to like make the items more and more technically interesting than a lot of Metroidvania abilities. So many of them have the dash or the slide. Or there's like this sort of default tool kit. And a lot of those are pretty easy to program. It's like, "Okay, how can I push this in a more interesting direction that behaves in a way that feels fresh?" And maybe someone wouldn't exactly know how it's implemented at first glance.

[00:30:15] JN: Yeah. Absolutely. I think they also kind of lead, because you have like an intuitive way of using them, but they will have extra depth, which leads you a lot to moments as a player where you're like, "I've just solved this puzzle doing this in a way that I'm not sure is how I was meant to solve it. But it's worked." Which is always I think a key that the puzzle is perfectly designed when you're not sure you solved it how it was meant to be solved. It's always a fantastic feeling moment. 

On the tools, you mentioned earlier that the game doesn't really tell you what to do or tell you how to play it. And straight from the off, you've got multiple directions to go in. I'm always really fascinated by how Metroidvania developers balance open world with gating the world of tools, with allowing players to start on multiple directions and get different tools. What was your approach here? How did you go about balancing those desires to enable exploration but also having the gated areas? 

[00:31:06] BB: Yeah. Just a lot of play testing, honestly. The world kind of grew organically. And it just sort of almost started in the middle and then grew out to the boundaries as I worked on it. But then, eventually, the map got finished and then it's just doing a lot of play testing and trying to strike that balance of giving players the sort of the sense that they have a lot of options and they have a lot of agency in where they go. But then, also, you don't want them to just wander off into some pointless direction where they don't have what they need and it's going to take a long time to backtrack. And they're going to get lost and not really feel like they have any purpose. 

Yeah, it's like a very subtle balance you need to strike. And it's just like watching people play a lot. I think I would lean towards probably making the game more open at the start and add a lot of like shortcuts between the sort of different areas and then just watch people play. And then sometimes they take one of those shortcuts like earlier than I expected and then they would just wander around for a while and eventually reach a dead end. 

And so, it's like, "Okay, maybe I need to add another gate there where you need a certain item or make certain doors, like one-way doors." It's just like a lot of trying things out and then like watching people play. It's very time-consuming to make a - it's like an interconnected world that feels like intuitive and productive to explore. I think you just got to go through a lot of iterations of it. There's no like trick that I really know.

[00:32:39] JN: Sometimes the game just needs seven years, right? 

[00:32:42] BB: Yeah, I guess so. 

[00:32:43] JN: I guess going back to your engine. Obviously, you mentioned that you built your own engine. I know you've spoken about this a lot in the past. But, briefly, folks who haven't catch or caught your interviews before, why did you choose to go your own engine? 

[00:32:55] BB: I think a large part was I just thought it was fun to do. I took a few classes in college on like how to build game engines and I like really, really enjoyed that. And I've always been like more on the low-level side of programming. I still program in C, C++ for pretty much everything. 

And anytime I've had to use other engines and deal with bugs and stuff or like missing features and then not having the source code or having to open a support ticket or something, that's when I just really just didn't like my job. And I'd have to just be waiting for like an update, or something, or a patch. 

And then on the other hand, I really enjoy understanding how things work and sort of programming like those underlying systems. It was just a matter of sort of like if I wanted to stay motivated for the project and actually enjoy it as a hobby, that was sort of the approach I wanted to take. 

Yeah, early on, I didn't even know if I was going to release the game or not. But I did know it was fun sort of program game engines. Yeah, just started that way. And I think for the first few years, it actually felt - if I would tell people that, it seemed like kind of self-indulgent. And the game wasn't that impressive at the time. It's like why don't you just use Unity or something? It's right there. You'd be like so much farther along. 

But I think, eventually, it started to pay off. And I think once I got my animation system in and I got more tools sort of got more polished, I think I can work very quickly now. And I was comfortable like doing the ports myself. And, yeah, I just feel very like independent with everything I'm doing and I don't need to rely on really anyone else to get it done. I'm very, very happy I did it. And I think I will always work this way. But, yeah, it's fun mostly.

[00:34:47] JN: That's awesome. My next question is how does it feel having built that at the end of seven years? And whether you think you'll use it in the next title. I guess how it feels? Do you think this is engine that you'll continue to use? Or is it very closely tied to Animal Well?

[00:35:01] BB: It's very closely tied to Animal Well, for sure. But I'm probably going to make a somewhat similar game. I kind of want to do the sort of next-gen version 2.0 or like reimagining of Animal Well. My plan is to like probably borrow a lot of the code that I previously wrote. But then, also, kind of overhaul everything about it and try to make a game again. 

I will reuse the engine, but it's not going to be in any structured formal way where I like import a package or keep it in a shared library or anything. I would probably just like clone the whole repository and then just start changing it. Yeah.

[00:35:44] JN: Yeah. Really interesting that you mentioned you want to build like a next-gen like 2.0 of Animal Well. I guess there comes a certain point during your development task where you're like, "Okay, that's an idea for the future. I really just have to get things done now." Right? 

[00:35:54] BB: Yes. 

[00:35:54] JN: Yeah. Yeah. That must be a big laundry list by this point.

[00:35:58] BB: Yeah.

[00:35:59] JN: We spoke a little bit about one of the things you think was really important was like hot reloading. Were there any other features of an engine that you were particularly keen to build or that you missed when you used other engines that made it into yours? 

[00:36:13] BB: There were some tools that I think you would expect to be in a game engine that I didn't have. I don't have any way to sort of sequence events in the editor itself. There's no dialogue. There's no cut scenes. If you think of a cut scene in like an RPG or something, like a character like walks out of a house, turns to you and says something, and then walks away. And that's very common in a lot of games. But because I didn't have a way to sort of script those types of things, the game ended up having like no dialogue and no cut scenes. But I think it actually ended up being better for it. 

If I were using Unity or something I would have that and maybe just sort of lean on stuff like that. But it kind of pushed me to communicate things more visually or through the level design. And it sort of helped guide the game in a direction that was more quiet and atmospheric. And I don't know. I think you ended up being more immersed in the game. 

I often think about the way Valve used to make games with the original Half-Life 2 where there's no cut scenes in those games and everything. You still always have control of the character. But sort of stuff will be playing out around you. And if they wanted you - say there was like a gunship crashing or something and they have this like big sort of scripted spectacle and they want you to look at it, there's a very good chance that the player will be looking in the opposite direction and they'll like miss the whole thing. 

I remember one of their commentaries, they would put like one combine soldier far off in that direction kind of just shooting at you and like not really doing a lot of damage. But it's just there to get your attention. You turn and you see the big spectacle that they sort of crafted. And then it just feels like when that's done right, I think it just feels amazing and you feel like the world is alive, and you're in it, and you're participating, and you're not just like watching a cut scene or reading through the instructions.

[00:38:09] JN: Yeah. That's a really interesting I guess philosophy on it. When you were talking about your path to game development, you mentioned go through film school. The first thought was like, "Oh, that must be really useful for like lots of aspects of game development." It's particularly cut scenes. Nope. Throw them all out." 

[00:38:24] BB: No. I mean, I do occasionally have to edit a trailer for the game. And I feel like that's the one time it's like, "All right, let's get into Adobe Premiere and let's dust off the film school sort of knowledge." 

[00:38:38] JN: Yeah. We spoke about the tooling. But one thing you mentioned there was that you've done all your own ports. We talk about porting a fair amount with game developers on the show. And so, when I heard that, I was like, "That is wild." Because it seems like an awful lot of work. But I liked that your rationale in particular in the interview I saw was that you just like finding the weird stuff in these SDKs. What is your favorite odd functionality you found in a console SDK? 

[00:39:02] BB: Being able to detect the controller colors for the switch Joy-Cons is very funny to me. And I don't know if like any games utilize that. 

[00:39:12] JN: The full-on like red, blue, yellow, purple. 

[00:39:14] BB: Yeah. It's like what color is it? 

[00:39:15] JN: Fascinating.

[00:39:16] BB: Did you get the special hot pink controller where there's an API to tell you that? 

[00:39:21] JN: I don't think I've encountered a single game that's done anything with that. 

[00:39:24] BB: Yeah. I guess it may be a like - I bet they InVision, when you're doing it, playing Mario Party or something and you want to like pair your controllers and everyone can like get the game ready. They can show the correct controller color on screen. 

[00:39:38] JN: Oh, yeah. They do do that. When you lock in, it does - yeah. 

[00:39:42] BB: Yeah. But I feel like there's probably a lot of opportunity for stuff like that.

[00:39:48] JN: You don't always suspect them to do like kind of amiibo thing with it, right? Like, "Oh, you bought this particular Joy-Con. 

[00:39:53] BB: Yeah. There's one really weird thing you could do. And I think it only works in Japan. But you can use the amiibo sensor to scan your Subway card. I don't know if any games do that.

[00:40:04] JN: That's super Japan. Yeah.

[00:40:05] BB: Yeah. It will detect that and they have utility functions to probalby understand your rider ID or whatever.

[00:40:15] JN: The unassuming Subway card that powers half the economy is very usable in Nintendo consoles. Aside from weird functionality, obviously, the consoles that you're supporting are all very different machines, very different performance capability, very different architecturally. Were there any - with your own engine, as you said, doing a thing yourself also not having its port to fall back on. Were there any particularly tricky elements of the porting process that you had to tackle? 

[00:40:41] BB: They require a lot of like concentration and like just committing yourself to focus and read the documentation and being like an understanding. I would say the graphics APIs are always the hardest of all. Input, super easy. Usually, I like to do that first because it's just like getting a struct that has like all the button states or something. Or even switch is the hardest, because it has so many different types of controllers. And you have to manage like what controller configuration like each player has. But I've also made it simple for myself, because it's a one-player game. 

But then, yeah, the graphics is always - I started out, the game was using DirectX 11 on PC. And that was like sort of the first version of the game I made. DirectX 11 just like does a lot of stuff for you. So you don't even need to really understand command buffers or like how memory is allocated or anything. And you can kind of just almost use the API like it's like on the CPU and it's like everything's like synchronous. 

When I had to do the switch port and use their like native API, it's much probably has more in common with like DirectX 12 where they kind of changed everything. It was that first I think switch port that was the most challenging for me. I had to like refactor a lot of parts of the engine and then the way shaders are compiled is kind of annoying they need to be sort of transpiled from HLSL, which is what I use too. GLSL and then they can be like loaded and compiled for the switch. 

Yeah. And then just like little things you have to look out for like the UV coordinates. The Y-axis is like flipped. If you start porting, everything will be like upside down. And the you'll have like some shaders where just one effect is like upside down on screen. Or things aren't getting - you're sampling some mask and its upside down. And things look screwed. 

But, yeah. And then, usually, the documentation though is very good, I'll say, for the console platforms. Probably a lot better than stuff on PC, because I think they like kind of have to get it right. All the developers are relying on. 

[00:42:49] JN: They can't even allow community Support when it's behind a license agreement and stuff, right? 

[00:42:53] BB: Yeah. Yeah. And you can't Google anything, because it's all, NDA'd. But, yeah. It's nice when - and, also, compared to something like Windows and like OpenGL where there's been like decades of different versions of it. And if you go look stuff up online, you don't really know what you're looking at. Or there's so much redundant functionality in OpenGL that you always have to question, "Is this still the modern best practice? Is this the newest API? Or am I mixing and matching them in a way that I don't understand?" 

Yeah, the consoles are refreshing that like they have just like a much cleaner set of tools that were kind of designed to all work together. But, yeah. I think just in terms of complexity, the graphics APIs are always the biggest workload. I think that probably accounts for like 70% of the porting time is just like getting the rendering to work. And then everything else is kind of much, much simpler.

[00:43:50] JN: That makes sense. One of the things we've heard a couple of times people doing switch port is that they often have a lot of performance tweaking to do. Is that something you had to deal less with given the performance optimizations you paid so much attention to in your engine already? 

[00:44:05] BB: Yeah. It actually wasn't so bad. The switch version, it still has like the low latency stuff I was talking about. It runs at a locked 60 frames a second. There's no sort of performance compromises. There were some effects that I kind of had to cut from the switch version that I are like particularly gratuitous. Some of the backgrounds use like signed distance fields render this kind of like trippy geometry that has bounce. I'm like ray marching into and then I'm calculating a secondary bounce raise and re-marching again. 

There are some things that are like very expensive that honestly aren't like super important to the game that for the switch I had to cut. And then the fluid sim, that I was able to sort of scale down for the switch by just reducing the number of iterations that the solver has to do to like render the fluid. And it still looks pretty good. But, technically, it's like a little less accurate. 

[00:45:00] JN: Yeah. Nice. On the switch screen, it'll be fine. As we come towards the end of our time, I have again a kind of traditional question to ask. Games like the special Metroidvania pretty much always attract the attention to the speedrunning community. And I got the sense from some stuff near the end of the game that you're aware of that. Do you have any predictions for how your game's going to fair? Do you have a figure in your head for what you think the first any% run will be?

[00:45:24] BB: Yeah, I do have some predictions. I bet they'll get pretty low. Because there's a lot of opportunities for sort of sequence breaking that I'm already like aware of and sort of intentionally left in the game. Yeah, and I think once you play the game a few times, there's some knowledge you'll have from like later on the game that can dramatically like accelerate like how you get around. But, yeah. I don't know. I bet like sub-30 minutes will happen pretty quickly. 

[00:45:52] JN: And then you mentioned this a little bit, but release is coming up time recording in two weeks by the time it comes out, the game be out. It's been a long road. What's next? 

[00:46:01] BB: I think just kind of take a break. There's some sort of stuff we still have to deal with the launch and sort of follow up with post-launch plans. And just kind of be on call to just like watch how that goes. And then, eventually, yeah, I'll probably start tinkering with another project. And I don't know. That will probably take years and years to turn into anything. But, yeah, I'm just very excited to finally see this turn into something after so many years of keeping it to myself. 

[00:46:31] JN: Awesome. Well, Billy, thank you so much. This has been delight. Thank you for joining me today.

[00:46:36] BB: Yeah, of course. Thank you so much for having me. 

[END]