It’s been about a week since I got back from GodotCon, and I thought for this week’s blog, I’d post a bit about what I presented on and impressions of the first North American Godot-based conference.
The biggest takeaway was that the conference was excellent for bringing together hobbyists, software contributors, and creators working with open source tools. Riding the train home, I strongly felt that the appetite for gatherings like this was met. However, folks (including myself) wanted more. This isn’t to say there weren’t plenty of great talks, presentations, and opportunities to network. But when talking with people on Monday and Tuesday, there was a palpable eagerness for engagement with/learning from workshops, finding potential collaborators, and bonding over a love for game design.
But before getting too far ahead of myself, I should share that I went to the conference to host a workshop entitled “Narrative Design for the Solo Developer.” This two and a half hour event introduced folks to Narrative Design concepts like Hannah Nicklin’s multiple middles, designing layer-cake quests, and other patterns in choice-based games as outlined by Sam Kabo Ashwell. The plan was to adapt some of this thinking to a very short piece made in Ink(y) with responsive text and variables integrated into Godot using the inkgd plugin.
I had prepared four 30-minute segments to go through:
- Why/what is narrative design
- Making an Ink Story and understanding its syntax
- Beginning Narrative Design Concepts
- Integrating an Ink Story into Godot and formatting a starter scene
I found that the audience was very eager to talk a specific examples of narrative design techniques they’d observed in games, and how those games were structurally or technically designed. For instance, a couple of questions about games like Kentucky Route Zero came up when I introduced notions of authorial voice using multiple middles. I said that I wasn’t completely sure how Cardboard Computer had technically designed the wonderful prose of that game, but that I knew that some of the design was influenced by early text-adventures (a question that I should truly pose to Jake from CC at some point).
Additionally, I immediately recognized that participants were not only very well-versed in a slew of contemporary narrative games, but that their understanding of the design of those games exceeded my expectations (not that it was low, mind you, but rather folks were VERY up on things). When it came to designing systems around storytelling, there was a noticeable drop-off in understanding structure, even for experienced programmers and developers. Folks posed a lot of hypotheticals about designing systems around player interaction and NPC dialog, but it took a second for participants to wrap their heads around the methodologies of having a story trigger events or speak to a Singleton that could store variable data (in Engine).
Gratned, the workshop was designed for beginnings and I wish I had spent a bit more time on getting into the weeds in Godot to show how one could observe story variables and then send data from those variables to a game state manager (a system I used frequently for Bundle of Joy and plan to use in even more details for other future projects). We were a bit strapped for time, but I felt a bit disappointed that I didn’t have more concrete examples of how to scale narrative design systems in a meaningful way, since I felt like a lot of participants had questions about how to use Ink to manage entire story arcs. I tried to give some helpful advice and best practices, but having an explicit example to show would’ve been very helpful for connecting the dots between getting started and the development process.
But… maybe that’s just my worries talking, since everyone who came up to me after the talk over the next couple of days said how much they enjoyed the presentation and learned a lot about technique and implementation in the short time we had together. Funnily enough, many folks said something to the effect of “y’know, you should think about teaching,” to which I replied that one reason I had to leave GodotCon early was to come back to Brooklyn for students wrapping up their finals.
Anyways, if you’re interested in the presentation, the workshop was recorded and should be posted online soon (and I’ll put room __here__ to remind myself to post the recorded video at a later date). In the meantime, the GitHub repo of the project can be found here. Also, the slides for my presentation are available here (I decided to repost these as a standard “deck” although my presentation at GodotCon was itself run in Godot).
My workshop was on Monday, and I spent the rest of the day and all of Tuesday hopping between talks, chatting with attendees, and visiting the small games showcase. Some of the highlights of those talks included an excellent, in-depth presentation by Adam Scott, the Godot Engine web lead. He not only premiered some exciting upcoming features (published here) but also walked through some really technically sticky aspects of creating quicker loading times for Godot projects running in the browser. This was of particular interest to me since I want to encourage my students and other folks I mentor to consider Godot as a viable engine for direct-to-web prototyping and publishing.
Another exciting talk was a short presentation on designing messaging systems or event buses by Eric Peterson (aka BajaTheFrog). He gave an excellent short presentation about redesigning a more agnostic approach to sending and receiving signals between objects using an Autoloader intermediary that uses a pub/sub methodology for registering objects that would both send and receive data without having to parse that data discretely at all times. I felt like it confirmed some of my design thinking, and even though I didn’t implement this methodology explicitly in BoJ, I did something similar where I would use Singletons to store data sent using signals and then retrieve that data from the singleton using more hard-coded calls/methods. So… I got part of the way there, lol.
In both of these talks, I was surprised that I understood the higher-level engineering concerns while also grasping the lower-level implementation examples. It’s almost like I’ve been using this software long enough to get it! Joking aside, it inspired me to try to contribute more to actual PRs and to do more active bug reporting on the engine. I use Godot almost every day and run into very niche instances where using the software for unconventional (in my mind) design goals leads to questions about usability improvements.
I’m curious if other attendees who don’t actively contribute to the software felt the same way. I’ve been a supporter of Godot for a while, and I try to donate to the foundation when I can (which you can also do!), and I’m actively trying to fold it more into the Pratt Game Arts curriculum (with the help of Jason and Everest, ofc). But the thought of being a contributor has always been a bit daunting. So… if anything, having some time back in Brooklyn from the event is instilling in me a desire to change that this year. I’m particularly motivated to do this as I start to ramp up a bit of pre-production/r&d on the next project.
Before heading out to catch the train, I caught the start of Rawb Herb‘s talk about UI design and best practices. I wish I could’ve stayed to watch his live demo, but the initial information was excellent. Seeing real examples based on his work at White Thorn Games (and his upcoming Tennis Academy project) really drove home some excellent design points about usability, organization, legibility, and knowing when to be stylized and when to be functional. I’m definitely going to keep an eye on what Rawb is working on, and a special shout-out to him for “TA’ing” my workshop.
That’s it! Overall, I had a truly excellent–if short–time and am looking forward to seeing what GodotCon will shape up to be in 2026!
Leave a Reply