Blender and Godot in Game Development with Simon Thommes

0:00Blender Studio is the creative arm of the Blender Foundation, and it's dedicated to producing films, games, and other projects that showcase the full potential of Blender. The studio functions as both an art and technology lab, and pushes the boundaries of 3D animation through open productions. All of their assets, production files, and workflows are shared publicly, which gives artists and developers valuable resources to learn from and build upon. Most recently, Blender Studio released its second game, Dog Walk, where the playable character is a dog exploring snowy winter woods with a child.

0:37The project was built entirely with open-source tools, including Blender, the Godot engine, Krita for concept art, Kitsu for project management, and Linux. Simone Thomas is a lead technical artist at Blender Studio and a developer on Dogwalk. He joins the podcast with Joe Nash to talk about Blender Studio, the process behind building Dogwalk, and developing a pipeline between Blender and Godot. Joe Nash is a developer, educator, and award-winning community builder who has worked at companies including GitHub, Twilio, Unity, and PayPal. Joe got his 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.

1:38Simon, welcome to the show. Thank you, thank you. I want to ask you what your role is and what you do, but I guess to set the context for that, for folks who aren't aware, can you run us through what Blender Studio is and how it sits and is different from Blender itself? Yeah, it's probably a good idea. A lot of people that we talk to are not actually aware that Blender is also doing its own content creation. And yeah, that's done in the form of the Blender Studio. The Blender Studio has been existing for almost 20 years, I think now, for creating actual open projects with Blender, making short films mainly.

2:13And recently we've also done a game that's been a game before. But the whole concept of the Blender Studio is to support the development of the Blender software by actually testing out the features that are being developed as they're being developed. So we're always on the latest main branch of the software, not waiting for releases. So we're immediately testing the features as they make it into Blender. And at the same time, also pushing the development into different directions. The idea is also to focus on various different art styles and just general themes with the project that we're doing to make sure that Blender is usable in all sorts of different branches.

2:52And at the same time, we're also using a full open source pipeline for our project. So anything, of course, Blender being open source is our main tool. But for anything else that we do, it's like concept art, we use Krita. For our production management, we use Kitsu, which is also open source. We're all on Linux. The idea is really to push open source content creation beyond what just only Blender does and make sure that that's possible and then fill the gaps where we need to with our own tools. While we're doing that, we're also sharing everything that we do openly. so in the same spirit of open source software development for blender we're sharing the content that we create like the short films under cc by license so people can also use it for like just the video for testing like there's people doing like rescores uploading them on youtube things like that and also the tools that we create around blender for the production management and everything we share openly so that's like a little bit of a rundown of what we do at the under studio.

3:54Yeah, that raises a lot of questions. I guess first one, before we get too in the weeds on this, I want to give you a chance to talk about what you particularly do. But one question on that, so you said you're always working on that latest main. And I imagine with that goal of trying to make sure you're always testing the latest stuff, that puts... How many projects are you doing a year, basically? I guess they have to be quite short to keep that goal relevant, right? Yeah, so it really varies. We've been doing some longer projects. I think on average, it's been about a year for one project because we're a relatively small team and we have long cycles of preparing the production, doing the production.

4:26And then we also do other stuff in between. Like we also create educational content and blog posts and stuff like that to actually share that knowledge. Because it's not just the content creation that takes up a lot of time, but sharing that is also something that you need to actually actively put time into. So it's been more of like one project a year and then some stuff in between. But more recently, we've been trying to speed that up and have like a shorter iteration cycle to be able to also, like you said, try out different things, be very much on top of what Blender is doing. Because if it's a longer cycle, like one year, that is difficult to make sure that it's aligned with the Blender development in a way that it actually makes sense.

5:03Some smaller experimental stuff is a lot easier to handle in that sense. So I'm trying to, this year, do four projects that cut down into like three and a half, maybe. But we've already shipped one of them, which is Dog Walk. One of them is almost done, which is a character asset that people can use a full production ready rig that animators can use for their reels and stuff like that studios can learn from and currently we're working on another short film called singularity and upcoming is another short film that we already produced a little reel for that is still in development nice but i've been trying to speed it up quite a bit yeah moving from one to four is a there's a lot of projects yeah but it's interesting i was familiar with Blanche do those short films, but it's really cool.

5:49You know, Dog Walk was really cool to see, but also hearing about the character rig, that's really interesting. Well, I guess that's a good segue into your role. What is a technical artist? What is it you do? Well, I think technical artist is a role that's not super defined. It like really depends on the branch that you're working in. It's just that little spot in between being a programmer, working on the software and an artist using it it's like a little bit of both and mainly i just try to find technical solutions to the creative problems that we're facing so what i do a lot is just shading like writing shaders for the assets that we're creating and tools for the other artists in our team also to work like a lot of it is geometry notes work nowadays yeah with the blender studio being very tightly connected with blender for the software development i'm also or not just me but our whole team is also pretty involved with that and in that sense i'm quite involved with the geometry nodes development team as a stakeholder artist basically helping them design the features and test everything before it makes it into main awesome that makes sense a lot of you found a geometry node problem whilst using it for a project and now you have to help fix it kind of situation yeah that i mean it comes with like downsides and upsides, right?

7:02But a lot of the time, it's very nice being able to face a problem in production and then talk to the people that work on the features directly and help come up with a solution that integrates well into Blender for everybody to use, but fixes our problem. Yeah, there's kind of been a large part of the philosophy of the Blender Studio being so connected to Blender development. If we fix a problem for ourselves, it's probably also going to help other people out. So it's easier to make a software for us because we know what we want. And it's probably still going to be useful for others rather than only focusing, okay, let's make the best possible software for everyone.

7:39Of course, we're trying to keep that in mind, but it makes it a lot easier to have a concrete example of the Blender Studio as a use case. Right. So with that in mind, what was the problem you were trying to fix with Dogwalk? Yeah, so with Dogwalk, for us, it's been like really a big change of pace being a game since we're very much used to movie productions. and it was mainly just that we are very much aware that the game development community is using blender quite a lot more so maybe even in the movie industry because it's kind of already disconnected between the dcc and the engine where most people wouldn't use their actual game engine to create the assets so there's a difference anyways so might as well use blender in your pipeline it's a lot easier to interconnect than maybe in the movie industry where people might already been using Maya for animation, so it integrates well with Autodesk software, and then it's harder to shoehorn Blender in there.

8:36So we're very much aware of that being the case and don't have that much experience ourselves with it. So like we do for movie creation, we wanted to also have some more real-life experience of how the process works for game development with Blender or generally with open source. so it was definitely something that was interesting to us to just get the experience and just connect basically with the interoperability aspect of how can we make blender more easy to hook up to for exchange of creating assets and then using them in a game cool so i guess before i follow up on that and ask some ways you do that i guess it'd be useful to talk about what dog walk is as a game what the game play is that kind of thing yeah so dog walk is a little micro game we call it because it's very small you can play through it in like 20 minutes but it's a little interactive experience where you walk around in a winter landscape building a snowman as a dog you're actually playing the dog being led by or maybe leading a little kid through that landscape and then you need to decorate the snowman find some items around the world and need to get along so there's like really a relationship aspect to this game as well Yeah, absolutely.

9:54The leading bit. But the first time I realized I could hurt the kid by pulling too hard, I was like, oh no. Yeah, no, that was definitely intentional to create these moments where people maybe accidentally at first or just find out how you really affect the emotion of the kid running around with your behavior. That's one of the main core aspects, because in terms of game mechanics, there's not a lot. It's really just movement mechanics. You're just walking around and that's it. and then there's obstacles and different environments and you need to kind of lead the child around the landscape without making it cry so much that it doesn't want to move anymore yeah it's very charming and you said the 20 minute length super playable highly recommend just go grab it from steam and give it a go if you're listening to this is is really fun also i like the way you worked in blender's dutch roots by calling the dog chocomel very good i appreciated that i appreciate you noticing so that's the game and it is i think a really you call it a micro game but it has a lot of like obviously which makes sense given the original team a lot of like love and attention to the art and the art style with that art style i got the vibe that you were going for like a crafted like i almost i'm straight away compared to like yoshi's island like looking like craft paper kind of thing what led to the decision to that art style you said that you tend to experiment with an art style to drive blender development was that something there yeah so definitely in general for this it was actually a little bit different because the final implementation of the game obviously would not be in Blender, but it was in Godot.

11:22So it's not really about pushing the art style capabilities of Blender as much. It was more about the interoperability, really. And on a technical level, the question of the art style was more, how can we get something that we can work mainly in Blender and don't really need to focus too much on getting that same look in Godot because we wanted to really focus on other aspects. We just wanted to focus on the pipeline for getting assets into Godot. But shaders, like replicating a complicated shader setup, for example, that was a few steps too far for that goal because it was really just a small project, so we couldn't really focus on everything.

12:02And then the logical conclusion was to try and go for an art style that allows us to basically use the built-in interoperability features that we already have. And we went with GLTF as the exchange format. And there's many standards just for PBR workflows, right? It's just physically based rendering. You just have some color map, roughness map, and normal maps and such. And then it just works for anything that is supposed to kind of look photorealistic. And for anything else that's really stylized, you might need to do something very custom. And we didn't really want to do that. So the idea was to focus on a PBR workflow, but still stylize it on top of that.

12:44And papercraft is kind of a natural answer to that because it is like physically based. It's supposed to look realistic in the sense of the surface quality and everything, the lighting. But at its core, it's still very stylized. It's purely art, basically. It's all crafted in a way. So that was kind of the logical conclusion on a technical level for us. Also, our art director on the game, Vivian Lulkovsky, She's very excited always when it comes to doing things at a practical table and not just in the digital space. So it was also very fun to see these things come to life in real life and then recreating them in 3D.

13:23And that workflow worked out perfectly because that meant also for us, we could focus with the creation of these assets, mainly on the interoperability part. And it was relatively straightforward to just build the assets themselves. So it was really for us trying to put the focus where we wanted to and then see what results from that. Very interesting. A good incentive to finish the game as well. If you want to see any of those physical models, they are in the credits. Yes. So do roll through. So in terms of the pipeline itself, so the team has said some really interesting things, some of your devlogs about what you're trying to achieve with the pipeline, like some things that stood out where you wanted it to be Blender driven as much as possible and to do as little as possible in Godot, which is really interesting.

14:02and the other one was about GLTF and why you chose GLTF. But let's start with the first one. So actually, I guess at a high level, what did you want this pipeline to look like? As an artist, what did you want the flow to be? Yeah, so basically the idea was that, like you mentioned, we could do as much as possible in Blender because like I mentioned before, we're very much coming from just using Blender for all of our content creation and having people learn a new software would be, I mean, it would be possible, of course, but also it's not really in the interest of the people that are supporting us to some degree of course like we want to also support the godot development that's not the point but we wanted to with the funding that we get from people that want to support blender keep as much also from that in blender while we are still providing a use case for godot and giving them feedback for their development so yeah it's a little bit about the skill set of the people that come from the background of movie production, but also about just keeping our focus strictly on Blender.

15:05So the idea pipeline for us was to just basically use exactly what we've been doing so far for asset creation, which is really relying on the data structures that we have in Blender. So having everything set up with collections as like a unit of an asset and then objects inside there that contain all the data, the geometry, all the different data layers, and then being able to nest them inside each other. So a tree would have multiple branches, but then another tree could use those same branches to basically make it easier for ourselves to create those assets and not duplicate the data all over the place.

15:40So we'd be able to nest them inside each other. So each branch would be an asset and those are used in all the trees, which are all individual assets. Then those are finally used in the set and the set itself is also an asset. So nesting was like very much at the core of what we're trying to go for, because that's something that we're used to from working in Blender. Then the idea was that we really just have all the assets, sets, the characters, everything set up in Blender like we normally do. And then instead of linking everything into animation files, which is what we usually do as like a direct reference, export it to a GLTF, and then push it to Godot.

16:17But on the Blender side, everything was very much the same as we usually have it just with nested assets that are just instancing data around and then the pipeline would take care of the rest by recreating all of that hierarchy on the Godot side so the artists that were working for the actual content creation of the assets on the blender end only really needed to touch Godot for validating that what they did actually looks the same so if the pipeline worked perfectly they wouldn't really need to touch Godot at all which obviously it's very important for us to still take a look and validate everything and the people that were actually working with the game code would mainly work on Godot but the people creating the content would really be able to stick to just working in blender very cool and so part of that workflow that I found interesting as a amateur Godot dabbler who has been frustrated by collision meshes is that you're also trying to deal with the collision meshes in the blender side right did that work out?

17:16Yeah, I think that worked quite well. So with the pipeline that we went for, we immediately saw that if we want to actually have this work, we need to extend the built-in functionality quite a bit with some custom things that we want to add. And once we have some setup in place to just have an extension, which is very easy to do with Blender for the GLTF export, is just create an extension by the template that already exists. And then you can add a lot of functionality as hooks to just run code whenever something in the exporter is happening. So it was very easy for us to just write metadata to the individual export nodes about the collision, for example.

17:54So it's very custom, of course, so it's not really super easy to replicate that unless you really just use the exact same methods. But for me, within that framework, it was very easy to create a geometry nodes, node group, for example, that would create some of the primitives that we want to use for collisions, so the capsule sphere, whatever there exists in Godot, and then have a user interface on the blender side for people to define the properties of that, like the size, the radius, and everything of the primitives for the collision. And then just in the name of the object, just mark it as this is supposed to be for collision.

18:30And then the script could very easily just read out all those properties, write them as metadata, attach them to the node on export, and all that would happen automatically. And then on import, we would just use all of that metadata to just recreate the exact settings. So we really have this like mirroring setup on Blender on Godot's side to give us the same kind of functionality to communicate to the artist working on it. Basically, this is what you're going to get and then make sure with the pipeline that that's actually happening by recreating the whole setup using the metadata. So it was really quite easy for us to set up a nice user interface also on the Blender side and write that data in a way that it can be used on export.

19:11That's awesome. That's very cool. Which I guess brings me to, you know, the goal of this project was to experiment this pipeline and see, you know, how the pipeline between these two pieces of software was and, you know, drive the development of that. How much of what you ended up with was additional tooling on top of Blender and Godot and how much is things that we might see appear in a later version of Blender, if that makes sense? Yeah. Capital One's tech team isn't just talking about multi-agentic AI. They already deployed one. It's called Chat Concierge and is simplifying car shopping. Using self-reflection and layered reasoning with live API checks.

19:45It doesn't just help buyers find a car they love. It helps schedule a test drive, get pre-approved for financing, and estimate trade-in value. Advanced, intuitive, and deployed. That's how they stack. That's technology at Capital One. I think most of the features that came out of this are already in the release of 4.5. That's out. So that was mainly like bug fixes, some smaller features for the GLTF exporter, some bigger ones also like on the geometry node side, like some reworks on the API to make it easier to export geometry data. That's hopefully still coming. That's still in the works. but there was a big chunk that was also just custom code on top which hopefully we can still use to communicate also with the godot developers to just see okay what of that can we how can we tackle those shortcomings basically to some degree it's also that kronos group for developing the gltf exchange format they have some extensions to gltf that we haven't really used because to be honest at the time when we were developing the pipeline i wasn't fully aware of those or some of them i saw but they seemed very much work in progress so i wasn't sure if you could rely on them and at that point it was easier for us to just do a custom thing our own that we know works that we have full control over but there's some extensions that they're working on like for example for uh complex scenes the whole nesting concept that i talked about earlier that we kind of did in a custom way there's a concept for that with gltf as well with that extension so i think now it's a little bit of a matter of trying to assemble the pieces to really bring those features to the regular user that doesn't necessarily want to write their own custom pipeline because that's something that we still need to do but that's definitely planned for now it was like with the project itself because it was a relatively small scope we did the whole thing in four months so doing that with some development on the side and then also like polishing everything is not really feasible so for now we just focus on getting all the pieces and then assembling them later yeah so we're also planning to do a workshop with some good old developers and some interested people to actually make that happen but yeah that's going to drag a little bit more unfortunately as things go because we also have some other projects that we're working on but yeah we definitely still want to make that happen that's awesome yeah and although i know in the post you've kind of just done it there as well disclaim that it's not production ready and you know it's very beta but in the post as well you did release the source of the pipeline that you have currently again with a lot of disclaimers but if folks are interested you can go poke that around look up the dog walk wrap-up post yeah we definitely have the entire repository of the project actually uploaded so the game itself the code including also the pipeline is all online for people to dabble around perfect so one thing i think is really interesting so you just said there that you know you were thinking about the dx of this from the perspective of like a an individual user either program but like one of the special things about blender studio is you're doing this at a production scale so it's a large-ish team working together and that i saw had some really interesting implications for your selection of gltf as the interchange format over you know the blend files can you talk to us a bit about that oh over blend files well as far as i know on the godot side from what i understood so the blend file itself directly as an exchange format is under the hood still using gltf for the exchange so in terms of like the feature set it would have been more or less the same what's supported out of the box but for additional customizability it was a lot easier for us to make that step explicit because if we just have the blend file itself as the thing that's important for the game files it would still generate that ephemeral data of a gltf under the but we would have no control over it basically.

23:32So the way that we did it now is like more or less the same because it's still using GATF, but we actually have control over the data that we output. So hooking up to that export step, yeah, by having an explicit export step in the first place was really valuable for us in that sense. Something that we also generally have been walking towards in terms of our workflow is to have an explicit publishing step. So rather than having all of the working data that you might be working progress working on, having an explicit publishing step that the artist can control to say, okay, this is done, this can go into production.

24:10And then pressing the button, that's not something that we see as negative at all. It's something that's actually very positive by creating that in your workflow. So having the blend files as direct input to Godot wasn't actually very useful for us because we would make a custom pipeline anyways. I think for people, individuals, for example, that are working on their own, it might still be very useful to have that just because it cuts out one element of their pipeline that might not be necessary. But for us as a studio working on this, it meant giving us more control, which was actually very valuable.

24:44Yeah, that's really interesting. And I guess while we're talking about, you know, as a studio working on things, you know, you're used to working on shorts and motion picture stuff. How was it working on a game? Did that require any differences in how you worked as a team or your workflows? it was quite different i mean it was i think it very much depends on who you ask for the whole team it was quite different but some of the people working on it in terms of pipeline we tried to keep it as much the same as it was right like i mentioned before like the people that were creating the assets were still working in blender for 99 of the time in that sense we tried to keep it basically the same as it was of course like animating for a game is going to be very different than animating for a film because you cannot rely on the camera being in a specific spot or the angle that the character is facing.

25:31So we also have a blog post over the difference there, but it's very different animating for a game also with a variable refresh rate compared to a film where you always know, okay, it's 24 FPS, the camera is exactly this, the character is facing this way, and then you can cheat anything that you want in between. With a game, you can't. the player will see immediately when there's something cheated. So in that sense, it was very different for the animators. For the asset creation, I think it was quite similar, actually, because usually assets we want to be able to see from all angles anyways. For me personally, it was very different because I was in a completely different role than I was usually.

26:08So I was mainly doing or almost exclusively doing programming on this project, which I usually only do a little bit on the side. So for this, I was actually implementing the pipeline, implementing shaders and stuff like that. And then at some point, halfway or so throughout the production, I could actually move over to help out programming on the game code itself, which was quite late. I would have hoped to move over to that a lot earlier, but the pipeline was proving to be more complicated to implement. Had you used Godot before this project? No. I think I'd opened it up before, but that was about it.

26:42I went to last year's Godot conference. At that point, I hadn't used it at all. But it was really interesting also to hear about the way that they do open source development and how that is different to what we do at Blender. It was just a super fun event, really good talks, very cool that you can try out games that people made in Godot just on the trade show. But yeah, that's basically been my experience with Godot before this, just hearing about it. What were some of those ways that the two projects managed differently? The way they do open source development is maybe a bit more democratic, I would probably say, and more loose in terms of adding features, adding like smaller features.

27:23The way I understand it is that they try to solve problems, if necessary, several different ways with like a slightly different flavor. While we at Bender try to like keep things a bit more streamlined in that sense, but that makes them a lot more agile because you can just on the fly fix a problem. and then it's fixed. And there might be a different way to solve it slightly differently, but that's fine. So I think you can argue about what's the better approach here and what's more scalable in the long run. But it was definitely very interesting to me to see how that works. And I think most of their code or most of their code is actually written by contributors and then just reviewed by the people that are actually hired by the foundation.

28:04And I think at Blender, it's the opposite way around where most of the code is actually written by people that are on payroll by Blender, hired by the Blender Institute. Yeah, of course, there's still contributions from, like very important contributions from community members, but in terms of just the quantity, I think it's the other way around for us. Right, right, right. So yeah, I guess coming back to your first use of Godot, I guess you kind of answered this in the intro, but was there anything that drove the choice of Godot here aside from it being like the open source engine of the moment?

28:32Yeah, it was kind of an obvious choice for us. So one, well, the director of the game, the main person driving this idea here, Julian Kaspar. He has been just very interested in games in general. Most of us have been, but he's been trying to just play around a little with game development on the side. He doesn't really come from a strong programming background before that, but he really tried to lean in deeply to figure out how to make these things happen because he was really excited about the project. And he had been trying out Godot on the side and he had been really excited about it. So that's mainly where the choice came from, I think.

29:09But like you mentioned, it is kind of the open source game engine of the time, I suppose. And personally, I've been also very excited about it. Like jumping on it, like when I actually started using it, it felt very familiar. It felt very easy to get around. I was kind of surprised how quickly that would work out, especially Python being something that's very familiar to me also from vendor, like add-on development as a basis for the GDScript. So that was very nice to jump onto. Of course, there used to be a Blender game engine, which, yeah, I think in the aftermath of releasing this game, there's been lots of talks from people that Blender should bring it back.

29:48There is a fork of that that exists and is ongoing, right? Exactly. That was what I was going to bring up. There is a fork, but yeah, we didn't, to be honest, we didn't really consider it that much as a viable option. We'd have to actually look into it a bit more again to see what they're doing with the development of that. But yeah, in terms of what people are using, it's a lot more representative to use Godot. Because yeah, like I mentioned before, we're really trying to figure out the current landscape of open source game development to see what people are currently doing and where the shortcomings of that might be.

30:22You're a developer who wants to innovate. Instead, you're stuck fixing bottlenecks and fighting legacy code. MongoDB can help. It's a flexible, unified platform that's built for developers by developers. MongoDB is ACID compliant, enterprise ready, with the capabilities you need to ship AI apps fast. That's why so many of the Fortune 500 trust MongoDB with their most critical workloads. Ready to think outside rows and columns? Start building at mongodb.com slash build. So yeah, looking at the, I think UpBGE is the name of the fork for the Blender game engine, would have not really been super representative of that.

30:59yeah and i also imagine that would probably cause the discourse about blender should do its game engine again even more if you did definitely yeah so we've spoken quite a bit about things that have been going on on the blender side but i guess on the gameplay side as you were getting into godot for the first time was there anything that you were surprised by godot or like features that were missing for what you were trying to do so personally also not coming from a game development background just to put that as a disclaimer so i don't have a lot of experience and like or presumptions i guess coming into this like i was kind of like a blank slate in that sense yeah so i've been really surprised how extensible godot is also for tooling like that's actually something that i also heard about a lot before in for example the godot conference when i was there how writing tools for godot for the actual development is kind of the same thing is writing the game code itself, which is absolutely true.

31:59And it's a brilliant concept, in my opinion. I've been trying to think also how we can kind of replicate that kind of thing in Blender, which to me, Geometry Notes is a little bit similar, where you can use it directly for content creation itself and for tooling to create content with. So it's kind of a similar idea, which I really like, that there's a point of connection. In Godot, that's been really useful for me, that you can really just write features or tools and it doesn't really matter and you can use the same code in either one yeah we've been exclusively using gdscript just because that's something that we were a lot more familiar with in terms of like being so close to related to python i think that is definitely the happy path as well as far as i understand it yeah yeah we didn't even think about using anything else to be honest but yeah from what i hear also that it's it's very extensible with c++ for example it was really interesting to me how extensible it really is especially also with the signal functional functionality that you have, where you can really hook up functions that you want to write yourself to the engine itself, like even to the point of the file system, for example, that was very useful actually for us.