EPISODE 1672

[INTRODUCTION]

[0:00:00] ANNOUNCER: Panic has created games such as Firewatch and Untitled Goose Game. They recently ventured into gaming hardware with Playdate. The console is unique for its inputs, which include a hand crank, and because Panic provides a free SDK, so anyone can develop games for it. James Moore is a DevOps engineer and Dave Hayden is an engineer at Panic. They join the show to talk about developing the Playdate handheld.

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

[INTERVIEW]

[0:00:57] JN: Welcome to the show. Thank you so much for joining me today.

[0:00:59] DH: Thanks for having us.

[0:01:00] JM: Thank you for having us.

[0:01:02] JN: Before we get into you two and your specific backgrounds, it's probably good to set the context of folks who don't have on these delightful little yellow machines. Dave, do you want to kick us off and explain what is the Playdate?

[0:01:12] DH: It's a little yellow thing that has a crank. The crank does not charge it. I'm just going to go straight out and go straight there, because we get asked that question so many times. People are like, "Oh, yeah, yeah. It definitely charged it." That would be physically impossible. Anyway, that out of the way, it is a small handheld pocket-sized portable gaming device. People call it retro, because the screen only has two colors. It is retro in the sense that it's a throwback to how computers worked when we were kids, people of my generation, older than probably most of your audience, I don't know.

You'd get a computer and you could just sit down and start writing games for it, writing code for it. You'd hit control, reset, or whatever it was, and enter into the command line, and you could start writing basic code just like that. We wanted Playdate to be different from modern game development, where you have to download a million frameworks and have this giant dev rig and all this nonsense.

Anybody can write games for it and load them on there and play the games that you wrote, carry them around in your pocket. We wanted it to be very accessible in a way that modern game development seems like it isn't anymore.

[0:02:23] JN: Absolutely. Yeah. Well, definitely, I have a lot of questions about this and how you achieved this in particular. Before we get into that, I guess it'd probably be useful to talk about what you each have done on the history. Playdate today, I know you've each had various different hats to wear along the way, but also what you do now. James, you want to kick us off?

[0:02:38] JM: Yeah, sure. Let's see. I dug through the SDK Git repo this morning, because I wanted to find out when we landed the first commit. It was just over 10 years ago. It was on February 14th, 2014. I opened the repo. Dave landed the first batch of files consisting of some firmware and a little bit of API to maybe support Hammer Down, which was the first proof of concept game that Dave wrote for the earliest prototype of the device.

I also, because it's been 10 years, relearned that Inventory Hero started off as a - it was going to be a pack-in sample game for this gift idea that we had. The very earliest Inventory Hero code was in that repo. It was a love2D project started by Stephen Frank. Then I took it over in May of 2014. Then, yeah. Sorry, that was a bit of a digression. What I mainly do on Playdate is I wrote all the software that runs on the manufacturing stations and our factory in Malaysia. I can go into as much detail as you like about that.

[0:03:51] JN: Well, I'll be after you for that. That's a wild sounding process. Also, we'll come back to Inventory Hero as well. Yeah. Dave, do you want to share briefly what you worked on?

[0:03:59] DH: I was given this project in, it was the end of 2012 where we started talking about it, or I started talking about it internally. Apparently, I didn't realize at the time that it was something that Neven and Cabel had talked about for a while. It started from this meeting that we had in with a friend of mine and the company he works for, he's an industrial designer in Portland. We knew we would need some of that and that they do things - that they do hardware projects. Not knowing anything at all about how to get into that area, we went for a chat with them and they looked at us like we were crazy.

There was the founder of the company and my friend and then a consultant that they worked with. The consultant looked at this and he's like, "It's going to cost you a million dollars just to get the buttons right." After the meeting, Cabel and Neven were like, "It's going to take up -" They were mocking that. They were laughing at about that. Not mocking, but they were - it's like, a million dollars out of it. I bet we've spent that on the buttons. I don't know.

[0:05:04] JN: They're good buttons.

[0:05:06] DH: I mean, they were absolutely right. We were insane to do it and here we are. Anyway, so that kicked us in the ass to actually make it happen, to prove them wrong, or right as it were. At the beginning of the year, in 2013, I started just messing around with hardware and learning a lot. Basically, I was given two years - no, it wasn't how it started. It wasn't like, "Okay, Dave. We're going to give you two years. You got to come up with something." It was like, just start doing it, see what you come up with.

I was making progress enough that, or coming up with interesting stuff to show for long enough that there's like, I'm going to keep doing it, whatever. Basically, I went with two years of just teaching myself how to do hardware and all this stuff, which was really fun.

[0:05:49] JM: Dave, did this coincide with us winding down unison? Was that about the same time?

[0:05:53] DH: Yeah. I started the first half of 2013, I made that first prototype, and then I just switched over and do that weird thing where we - Yeah. I spent the rest of the year building it. We had this software product that I made forever ago, and we were going to sell it to another company. We did all this work to sell it to them. Then the whole thing went bust, I don't know.

[0:06:15] JM: It was a Usenet client, so you can figure how big the market for that was.

[0:06:20] JN: Yeah, I was very confused, because Unison is a distributed programming language. I was like, presumably not that one. Okay, awesome. I'm a bunch of stuff to dig into there. I guess, James, you mentioned the SDK, the first SDK commit was 10 years ago, which is one of the things I was really interested to talk about is the timeline from SDK development and hardware development and when you start thinking of this thing as a platform and building out the SDK, people to build with it, and how that interacts with the hardware development. 10 years ago is far earlier than I expected in the lifeline of things. What was the state of the hardware at that point? What were you writing an SDK for?

[0:07:00] JM: Let's see. Dave, that photo that you dug up earlier of the very first 3D printed prototype bolted onto the STM 32 discovery board, you said that was from 2013?

[0:07:10] DH: Yeah. Yeah.

[0:07:13] JM: At that point, Dave had Hammer Down running, which is very much an LCD, an old-style game and watch LCD game. I think, the story goes that once we figured like, well, we don't have to confine ourselves to an LCD style game, we have this beautiful, sharp LCD, we could be drawing all the pixels all the time. That's when some of the other game ideas started to come in, when Steven started working on Inventory Hero and writing it in love, like I said. When I took that over, my recollection is that I was building Inventory Hero in love and telling Dave like, "Okay, these are the functions I'm using. These are the drawing functions I'm using."

I think at the very early stages, we were pretty heavily influenced by love and their conventions, because that was 10 years ago. Back then, that was a great little game development platform. I was doing this love development in parallel with Dave fleshing out SDK functions. Then eventually, I ported Inventory Hero over to our SDK.

[0:08:16] JN: That's incredible. Had either of you done any SDK, or API design prior to this project?

[0:08:24] DH: The internal stuff. Made tools for other parts of other Panic apps, things like that. A long time ago, I did Flash work. I did some stuff, if you remember Flash back in the day.

[0:08:36] JN: Very fondly. It's how I went to programming.

[0:08:39] DH: I wrote a library to deal with to manipulate Flash files. One day I got an email from, I thought it was a joke, it's from somebody at Adobe and he's like, "Can we license this from you?" I wrote back. I said, "Don't you have your own code to do that?" He's like, "Yeah, we like yours better." Okay, I guess I'm good at that kind of thing. I enjoy doing it a lot. I really like making tools for other people and trying to make them easy to use and also expressive. With Panic, we're on the application side, we're very focused on user interface, user experience, which I guess, are two separate things now. I don't know. I'm not up to date on that.

Yeah, we've always wanted to make the kinds of applications that we want to use. Pretty much everything we do at Panic is something that just we do it for ourselves. Then it turns out that other people really like it, too. Yeah, so I'm terrible at that graphical stuff. But on the code side, we have the same philosophy that you look at it from the point of view of the consumer and try to make it as useful as possible in that sense. Don't just expose every single thing that it could possibly do and expect somebody else to do all the filtering that you need to have some kind of curation, but whatever. Top-down point of view.

[0:09:53] JM: The long development process of the Playdate also let us spend a really long time with our season one game developers, who we brought onboard years ago, right? We were paying them to make games, to make the very first games that the customers, the first customers would see. We literally spent years with those folks, while they were developing their games and giving us feedback on what would be nice to have in the SDK, or how can we improve the ergonomics of the SDK.

Everything we do at Panic, we take our time, and sometimes to our detriment. I think when we did finally ship the SDK to the public, it wasn't that rough around the edges. It felt like a true 1.0 release. I think that really helped us get people developing right out of the gate. The SDK was very usable from day one.

[0:10:51] DH: I'll go back a little and describe how that happened. We didn't have the hardware then. The whole thing was done in parallel where we were - I was dorking around with hardware for a few years doing prototypes. Eventually, I was at the point where we had something that you could play games on. I think, I might have sent - I sent one of those to Sean, maybe some of the other game developers. It was really, really hokey hardware, but it could play a game. Didn't have a crank. That was the one thing that I couldn't figure out how to do. Anyway, but at that time, we handed off to teenage engineering to start doing the prototypes.

We had the simulator that we gave to all of the game developers in the first season, well before we had the hardware available for them, so they could go ahead and start making games that ran on the simulator. It's a simulator, not an emulator. It did not represent the performance properly.

[0:11:48] JN: As in, it was better or worse? I imagine better.

[0:11:51] DH: Oh, yeah. It could run a dozen times or more faster than the device. There were a few game developers were like, "Great. We're going to do, build these enormous frameworks in Lua and really push this thing." When that finally got on the hardware, it ran it like one frame a second. It was totally not feasible. In some cases, we were able to help them with the code and get it working well. In some cases, there were a few, at least one group that just like, "Oh, sorry. We're out." Shaun Inman, who did Ratcheteer and Crankin, or help do the code on those, wound up completely rewriting his stuff in C. Not exactly rewriting it, but building his own custom portability layer, a custom toolkit cross compiler in C to be able to convert his code into this other language that could then be compiled into C, so that he wouldn't be running into memory management issues and the stuff that he was hitting that was keeping him from being able to do exactly what he wanted.

I don't think anybody else went that crazy, but there were a lot of different strategies that people employed to get their game working on the hardware. But then a lot of the cases, it worked fine, because so many games were just simple enough that the Lua ran okay.

[0:13:05] JM: Yeah, Inventory Hero, for instance, never had any performance problems, because it's just a slot machine game, and we just redraw the screen completely. There's no sprites, there's no anything. Another game I worked on that was going to be a bike messenger game that had a full city simulator running on it. Back then, it was an early version of the sprite system, and I could never get more than 15 frames a second out of it on the hardware.

[0:13:31] JN: I was going to ask how the Lua API came to be make sense with, talking about Lua 11, the genesis of it. When did the C SDK start becoming a first supported thing? When people started running into these issues, or?

[0:13:44] DH: Originally, the C API was here's the frame buffer, here's an audio interface you can spit beta directly into and here's your button interaction, and that was going to be it. Where I assumed that anybody that used C would be bringing their own game engine, and that turned out not to be the case. When Shaun moved over to C, he then wanted all those Lua functions he was using. He then went and filled the whole thing out. Then we've slowly been getting close to parity. In some cases, it doesn't make sense to have the exact Lua functions in C, because Lua is higher level. In some cases, you can do things in C that you wouldn't want to do in Lua, because there's so much data, and there's a penalty in moving data between C and Lua; a lot of overhead for arrays and things like that. But you can write a native - anyway, no, I'm not going to go there.

Yeah. Over the time, the C side has expanded. Then on the other side, Shaun one day said, "Oh, here's this thing I've been working on called Pulp," which is going the other direction. It's like, you can make a game in your web browser, and it's all just tile-based, and it's got this entirely different scripting language, but it's very simple. The things people have done with that are mind-blowing.

[0:14:57] JM: Yeah, truly.

[0:14:59] DH: I think, like with the rest of Playdate, they see these limitations as ways to focus their creative stuff, and just mind-boggling what they've done with it.

[0:15:10] JN: Yeah, Pulp always reminds me a lot of Bitsy, if you're familiar with that? It has a similar thing where, yeah, even -

[0:15:16] JM: Bitsy was a big inspiration for Pulp.

[0:15:18] JN: I can imagine.

[0:15:19] DH: Back to the inspirations, I completely forgot about that the game had already been written in love, and that's why that informed a lot of the API design. That must be why we went with Lua. I can't remember now why we did Lua.

[0:15:33] JM: We talked for a hot minute about, if we could do a micro-Python runtime on there. I think back then, it wasn't mature enough to do it. It was too slow, or something. Lua just was already set up for embedded development.

[0:15:49] DH: Yeah. It worked, and I looked at everything else that would possibly work as an alternative, because there's a lot of stuff that at the time that I really didn't like about Lua. I reuse the same joke that it's the best - it's the worst system, except for all the others, like we say about democracy. I've slowly, over the years, come to appreciate it, that it's very easy to embed. The source is, well, you get used to it eventually.

[0:16:19] JN: The pretty popular with game developers of various kinds, I guess, is an advantage?

[0:16:23] DH: Yeah. A lot of game developers were already familiar with it. What really sold me on it though, was looking at the games, we helped a lot with the code on the season one games. Some of the games, the code was a nightmare, but it ran just fine.

[0:16:40] JN: Sure.

[0:16:41] DH: You can write horrible looking code in Lua, and it works. You can write the cleanest code imaginable. With Lua, they fight you a bit if you try and get too fancy, which might be a positive thing. I think it is in our case, where we have limited runtime.

[0:17:00] JN: Yeah. I think, I've always found interesting about game code in general, is it feels like an especially deep well of sins could be hidden in game code and just absolutely never matter, right?

[0:17:13] JM: The first game I ever made was a iOS game called Black Bar that I made with Neven. I've been writing software for a very long time, and developed certain principles.  Software engineering can be a little dogmatic. Everybody has their right way of doing things. When I got into game development, what I realized was like, when I ship this game, I don't have to really maintain it anymore.

[0:17:38] JN: Right.

[0:17:39] JM: I'll fix the occasional bug, but there's not going to be a 2.0. I don't have to think about the future. Man, you can just let it be as scary as you want inside. It just has to run. That's the advice I've given to other people who are like, "Oh, man. I really want to learn to write a game for the Playdate, but I don't really have that much programming experience." I'm like, "Don't worry about it. Just put pixels on the screen." It's so unlikely you will have to get into actual proper software engineering practices in writing a game, unless you need performance.

[0:18:12] JN: Yeah, I find it very freeing. I was having this experience just last week, where I found - I was messing up with a game for Game Jam, and I found myself thinking about architecture, and I was like, "I don't need to do this. It's fine." I guess, just go back to basics, but I've been nodding along like an idiot who's talking about seasons and the crank. For folks who are less familiar, I guess, to start with the original game distribution model of the seasons. Could you talk about having these season developers in season one? What does that mean?

[0:18:39] JM: Well, the idea was that, okay, so if you go back in time to back when we were thinking about these ideas, what was happening around the same time was Netflix was starting to release TV shows, and they would release all the episodes at once, which was a new thing. We were experiencing this along with everybody else, and thought like, there's something lost when you can come into work the next week, and someone's binge the whole season, and you've only seen the first episode. You can't have the same conversations about that.

We were thinking like, well when we ship this Playdate, are we going to ship all the games at once? Then on social media, everybody's going to be talking about different games, and people won't be having these shared experiences. The old, timey TV show model of the new episode comes out on Thursday night at 8 p.m. and on Friday, everybody talks about that episode was the influence there. Because when you put your marketing hat on, you want to maximize the amount of buzz for your product. The way we were going to do that is to trickle these games out in twos. I think, by and large, even now when people buy Playdates, they get the season one games, two a week, and they seem to enjoy it.

[0:20:03] DH: Yeah, a lot of people said that they played games that they never would have - they would have just skipped entirely, because that was what was available.

[0:20:12] JM: They're allowed to skip it out if they want.

[0:20:15] JN: Mine was Playdate - I think mine was batch two or three. I'd seen the concept of the season, because I was in the first batch. I thought the season was - it gets released every week. Then it was done, and future Playdates would just have them. When I had the season, I was very pleasantly surprised. The effect it had on me was astounding. The minute the day was come around for new games, I was my Playdate ready to go. It was very exciting, and it really did work. It was really delightful.

What was the, I guess, if you can speak about it at all, the development process? You said you had all the season one devs well in advance. The timing of their games throughout the season, how did you decide which games came out and when? Was that a discussion that happened?

[0:20:58] JM: That would have been a discussion between Neven, Cabel, and Greg. Greg, Maletic's the PM of the Playdate project. Neven's our lead designer, creative lead, and Cabel's obviously the co-founder. They were handling more of those ideas. Maybe Arisa was part of that discussion as well. Arisa Sudangnoi, she's our Playdate community dev relations person. Yeah, Dave and I are like, back-of-house guys.

[0:21:27] JN: Of course. Giving them the tools. Yeah, I guess with that in mind, Dave, you mentioned earlier what the crank doesn't do. It's not a charging device. What does it do? Well, how is it used in these games? What's the API for it?

[0:21:40] DH: You just get a number, an angle out of it. I think, then you can also get a differential callback, or something like that. I think, you could probably ask the system how much has changed since the last cycle, but it's really simple. It also tells you if it's docked or not. There's a little sensor in there as well. Overall, it's really a simple device. It's just a dye, whatever, bipolar magnet with little sensor.

[0:22:06] JM: T, when they did the electrical stuff work on it, all the layout and everything. I had no idea that there are chips that - tiny, tiny little chips that are full 3D magnet sensors, like flux sensors. That's incredible. All you need is a magnet and you can put it on top of a potentiometer, or whatever, kind of thing to make a dial. There's all sorts of really cool things you can do with them. I had no idea that existed. That was really one of the funnest parts of the project was learning about - was getting to interact with real ease and find out how these things are made. Just fascinating.

[0:22:43] JN: Yeah. I mean, I guess that brings up two questions. The first one, I've heard that you developed the original prototype. When did the crank come into the picture? Was that from the moment you're like, "We're going to make a console, it's going to have a crank"? When did this come about?

[0:22:56] JM: Yeah. That was all Jesper's - one of Jesper's crazy ideas. He's the principal designer at Teenage Engineering. When we got them onboard, he sent us piles and piles of his crazy ideas, just throwing anything at the wall to see what sticks. We've got just amazing renders of the fantasy Playdates that never came to light. One of the dial on the back. They honed in on an extra control pretty quickly, that it would have some kind of extra something. Then eventually, on the renders, the crank showed up on the side, and it was in various places and different sizes and whatever. Yeah, that is our two gimmicks right this season and the crank. It works really well. People have done really cool things with it.

I'm trying to think of what obviously, directional controls. There's the crank in the game, which I can't get very far in before I'm like, my hand just gives up. It's definitely the most extreme one. Can you think of any other games that really use the crank?

[0:23:55] DH: Joke Worth $0.99.

[0:23:57] JM: Oh, yeah. Absolutely difficult game.

[0:23:59] DH: Yeah, Whitewater Wipeout, which is a pack in game.

[0:24:02] JN: Right. It is the first week of the season as well. It really demonstrates the crank pretty quick.

[0:24:09] DH: Yeah. Casual Birder and Whitewater Wipeout are put on the device at the factory.

[0:24:14] JN: Right. I guess, the second question I had on that was through those early developers getting in the hang of it, did they immediately caught on to the crank? Was that part of - were they realizing how to use it effectively from the get go? Did that need some massaging?

[0:24:31] DH: When you introduce the idea to someone and they haven't seen it before, you have to first purge all of the fishing ideas from your mind. Then the real creativity starts to flow.

[0:24:39] JN: Right. Yeah, that makes sense. Absolutely makes sense. You mentioned some extreme use cases. Is there a particularly surprising, or delightful use of it you've seen that really surprised you? Casual Birder is a good, good one, actually. The idea of focusing a camera lens with it was one moment where I was like, oh, yeah, that's - I wouldn't have ever imagined that. That was pretty cool.

[0:25:01] JM: Yeah. Like, in Sasquatchers, when you go into photo mode, you use the crank to very fluidly pan the camera back and forth. I feel like, when you want a really fine grain control, even if it's not a rotational change in the game, it just makes for a very satisfying control that way.

[0:25:22] JN: I guess, back to the SDK. We've spoken around the SDK a lot, and where it came from and different developers getting hands on it. Can you run through, I guess, at a high level, what are some of the capabilities that the SDK gives to developers? I mean, at one point, I guess, you mentioned that you didn't expect C developers to need - do you expect them to be bringing their own game engine? I take from that that you would consider the Lua SDK to some extent to be a game engine in its functionality.

[0:25:48] DH: Right. Yeah. The graphic stuff, lots of drawing functions to - I mean, these all evolved out of what people needed for their games for the most part. There were some things where I was like, "Oh, that's a cool effect, or that's a cool thing. I wonder if we could do that." None of the games have really used it, or because it doesn't work very well. That's why, actually. The mode seven style drawing, where you have an image, and then you project it down into a plane and you have a perspective on it. That's a good example of API design done poorly, where you have - you've got a function that has 15 arguments, and so you just give them all to the customer, or the client and expect them to figure it out.

[0:26:32] JN: Is this core lib 3D? Or is that a different -

[0:26:34] DH: That's different from the 3D. Yeah, the 3D engine was another little thing that was like, let's see how it performs. It's just simple graphics code. That was one of the really fun things about developing the SDK was doing all these examples, example code, that people could then, hopefully, pick up and play around with and build on. Some people have expanded that code considerably, and there are some pretty sophisticated 3D engines out there now. I'm trying to think of any games in particular that have used them. There's a racing game that looks really cool.

[0:27:12] JN: I think Skew is what I was looking at. Skew the -

[0:27:14] DH: Oh, yeah, yeah. Right. There was, I guess, a port, or a port from another platform, or related to, somehow.

[0:27:23] JN: People already pushing the boundaries for 3D. You mentioned some things you mostly including it due to need and then sliding some things in there. I have two specific pieces I want to ask about. One, so the A* pathfinding algorithm was one that seemed surprising for a couple of reasons. I mean, A, it seemed very specific for an SDK at this level. Then B, to me, it's, I guess, it's just tick the genre of games that have obviously use all kinds of things, but I think, I hear A* and I think RTS is I think very much not Playdate games, right? Where did the A* come from?

[0:28:00] DH: I think, again, Sasquatchers, I think uses some pathfinding. I think Zipper uses some pathfinding, but I don't know if Bennett took advantage of that. It's entirely possible someone - one of the season one devs was just like, "hey, I've used A* before. Can we have this? I could implement it, but can you guys add it and make it fast?"

[0:28:18] JM: I think that's probably what happened. Yeah.

[0:28:20] JN: There are advantages, performance-wise, to you adding it to the SDK and shipping it?

[0:28:26] DH: Well, that's been a really cool thing about using Lua, where we can implement something really quickly and easily using Lua. Then if it doesn't perform well, then we can move parts of it into the firmware proper. Developing with initially with Lua has really made things go really fast. Fast, I say 10 years after we started the project, or 11 years now. But yeah, it's been easy to iterate on ideas. You don't have that compile cycle. You don't even have to - It's really easy to bang out Lua code and prove a concept. Then if you need to go back and implement at lower level, it's been a really, really handy way to do things.

[0:29:08] JN: Right. Yeah, it makes a lot of sense. Yeah, the other one that struck me as surprising was the QR code drawing, which again is very cool. All kinds of places you drop in the platform. I think, the OS itself display some QR codes at some point, which I guess, is where it comes from.

[0:29:23] JM: I added that. I had a lot of jobs at Panic. The initial web backend for Playdate, which internally we call Whopper, which is a reference back to the old war games movie, was developed by a guy named Patrick Gibson, who left Panic to go back to school. I took over the Whopper development for a while. While I was working on it, one of the things I added was the pin. We were working on the pin code registration. We were sitting there like, how do you make this device registration easy? I think around the same time, we were starting to see TV applications doing their authorization cycle using a five-letter pin code. You go to this URL, type in this pin code, and then the TV is registered to your account. We were emulating that model. I was like, "Oh, but, well, we're just going to print a URL in the screen? It's lame." Yeah, so that's why the QR code thing is in there.

[0:30:25] JN: That makes sense. Calling right back to the beginning we're talking about the origin of the Playdate and the easier, more accessible heyday of being able to boot up a computer straight into an interpreter, you can start making games straight away. It's obvious that developer experience is a driver, and in that scenario you've both worked on. What are some of the ways you thought about making developing for the Playdate as easy as possible? You mentioned things like Pulp, etc., but where do we really see that, I guess? I think Dave, you mentioned it as an Apple II inspiration at some point in a stream. How does that come through?

[0:31:01] DH: Not quite that easy anymore. But you can download the SDK. Used to be called Coda and now it's called Nova. Our editing app used to be mostly for HTML, but now you can do all sorts of things in it. If you have the SDK, then it automatically, I think sets up the hooks in Nova, so that you can just start writing code, click the button, and it will go launch immediately in the simulator. I don't know. If you're trying to build for the device, actually don't know how the SDK sets that up right now. We have an installer, right? That then puts the -

[0:31:42] JM: That puts the farm tool chain on your computer. Yeah.

[0:31:46] DH: Okay. I'm so far removed from the actual, the mechanics of all that.

[0:31:53] JM: That was also one of my early contributions to the project was, I think when we decided to - we're like, "Okay. I think we're going to do a SDK for the public. I think we're going to let people write games for this thing." It was like, oh, boy. How do we make this thing usable for the public? It's not an app. That's what we're used to shipping, building and shipping. This is a different beast. Yeah, going back to your question, I think there's been an ethos about Playdate from the very, very early days where enough of us are old enough at Panic to have my first computer was at TI-99. It's an all-in-one. You turn the thing on without a cartridge and you get a basic prompt. You just start typing lines of code. Then I had an Apple IIe later on.

I think the idea of your computer as its own development device was the driving ethos for this thing, because obviously, we've made iOS software. We've made Mac software. We've seen how the computing landscape has changed to be more locked down, be more restricted. Playdate was our like, let's turn back time, so that when you get a Playdate, it is also your dev unit.

[0:33:09] DH: Anybody can do it. No, you don't need to buy a license from us.

[0:33:12] JM: Exactly. Side loading was part of that ethos. Also, we never even considered locking the device, so that you couldn't put your own stuff on it.

[0:33:25] JN: Right. Yeah, I think such an FAQ item in the dev docs that stood out was like, you having to address that there is no such thing as a dev kit. That the device is the dev kit, right? Yeah. Side loading is an interesting one, because I think I saw Playdate games - I played Playdate applications landing on itch really early. I remember being applications, because I think the one that stood out was there was a calendar app and a contacts app, which I was like, the use case for that is wild.

Now, that the season one finished a while ago, and now you've moved to a catalog model, but there's still a healthy ecosystem of games being sold on third-party marketplaces, right? That's where a lot of them are sold. Interesting.

[0:34:07] DH: Are there seriously a thousand games out?

[0:34:08] JN: Yeah, I checked yesterday. It's nearly a thousand. There's approaching 800 on itch, and then across various other sources. Yeah. It's, yeah, all kinds of things. Yeah.

[0:34:18] DH: I never would have guessed.

[0:34:22] JM: The Playdate has, to say that it has vastly exceeded our expectations in terms of what people would do with it, like I cannot overstate how vastly exceeded our expectations have been. I mean, our mind weekly, we have a Slack channel where people are just dropping links to dev blogs and little videos of people posting their game ideas. I mean, weekly, our minds are still being blown by what people are creating.

[0:34:50] JN: I mean, there's lots of elements about it as a developer community that I think are really delightful as an outsider, like the birthday cake tradition, where the game developers are giving gamers who complete their games cakes is wild. The other one I really like, this is probably not an act. This is probably an ungenerous term, but it seems there are a lot of developers who called it quits, or were slowing down, or taking a break, who are making Playdate games as their return. Lucas Pope comes to mind, right? Well, he was done and now he's like, "No, actually, that thing's awesome. I'm going to make a Playdate game." Part of it's like, the constraints the ease of use.

That, I think, is really special that you've made a development environment and a device that's so delightful to build for that is inspiring people who thought they'd completed game dev again, right? That's very cool to see.

[0:35:40] JM: On the other end of that, we also see across the Discords, people saying like, "Ever since I was a kid, I wanted to make video games. I never learned how to program. I never thought it was possible. But I started messing around with Pulp and me and my kid made a game together." It's like, man, there's no price you can put on that kind of experience, right?

[0:36:00] JN: Yeah. I think the sideloading is really key to that. I had a discussion with a friend who was trying to teach his daughter game development, because she was interested. Part of the desire was being able to put the games that she made on her Switch. The fact they couldn't do that was a huge barrier to her interest in doing it. The fact that they can have their games on handheld and take around, I think is it's very cool.

You mentioned there that the path, what's happened is far exceeded your expectations. One of the things that I learned in the run up to this interview is that the original idea for the Playdate came out being a 20th anniversary keepsake for Panic. Obviously, the remake grew very quickly, but a one-off gift commemorative item is now this huge platform with all these people developing on that. How are you thinking and feeling about that internally? I guess, that's been in the making for a while, but that seems like a big vision shift in some ways.

[0:36:54] JM: Yeah, that's definitely some scope creep there.

[0:37:00] JN: You've made an ecosystem.

[0:37:03] DH: I do want to say that if it hadn't been for our foray into publishing, Firewatch gave us some - patted the bank account a little, so that we could invest more into Playdate. Then Goose Game really did. The playdate was definitely funded by Goose Game, or development.

[0:37:24] JN: That makes me very happy.

[0:37:25] DH: We probably would have had to scale things down, or possibly cancel the project, I guess, if we hadn't had success on that side. I have no idea if we've turned a profit. We probably haven't. At this point, I think we've still sunk way more in development, because I mean, we're paying people over the last 10 years. Then hardware, yeah, is you have to - it takes a lot of investment.

[0:37:49] JN: And a much challenging time for making hardware as well.

[0:37:52] JM: Oh boy. Got some stories.

[0:37:55] JN: Yeah. Actually, maybe this is a good time to go back to something which still, like James, you working on the code for the machines and the factory challenged my belief about how manufacturing works in 2024. I was very much of the - my mental model was like, probably worked with a factory that makes small devices of this nature. You get design, you ship them off, you maybe see some dies for the cases and you work on the specs. I did not imagine there was ever a situation where someone from "the client," maybe it is the wrong word, is shipping code for machines on the factory. That blew my mind. Can you talk about a little bit about that?

[0:38:33] JM: Yeah. Well, it's safe to say I knew next to nothing about manufacturing going into this. But I did have some experience working with external hardware over serial ports, which is largely what you need if you're going to be assembling something the way we do, which is, it's all assembled by humans. The humans, the factory operators are moving little trays of parts, or assembled units from station to station and putting them into test fixtures, where they're being, depending - one of the first stations is just the main PCB. That's basically a hands-off station, where we flash the chips, test the I2C bus components, test the Wi-Fi antenna, and then that PCB is moved to the next station, where it's combined with the chassis and the screen and the battery and then put in a fixture where it's doing physical button testing and the crank testing and the LED calibration and things like that.

I didn't know about any of this stuff when I started. But I was like, there's nobody else to do this. I think, Dave, you had a Python script that would run through a couple of little things, and I took that and expanded it into a very large piece of software. I can definitely answer more questions about it, but it's a large topic on its own, all the things we didn't know when we started this. I mean, the first time Dave and I went to Malaysia, when was that, Dave? Was that 2018, or something?

[0:40:18] DH: No, before that. 17 or maybe 16.

[0:40:21] JM: We were like, at the time, our expectation was we're six months away from mass production.

[0:40:26] DH: Right, right.

[0:40:28] JM: I've gone to Malaysia five times. Every time was like, okay, we're two months away from getting ready for mass production. Then the last time I went was December, 2019. Come back to the US, coronavirus hits. Suddenly, we have 100-week leads times on our main CPU. It was just like, we've had a lot of barricades in this project. Some of them were barricades that we created for ourselves. Others were simply the realities of manufacturing and during the pandemic.

[0:41:04] DH: I would say, like you, I thought before this, I thought a factory was just a black box that you put parts in and out comes your product. What we learned is that the factory is a process. They work with you to get the thing done.

[0:41:19] JM: Yeah. For anybody who wants a little bit of insight into this, for people who want to make hardware on the scale that we did, so sub 100,000 units, or sub 50,000 units, I highly recommend reading The Hardware Hacker by Bunnie Hwang, Andrew Wang. That book is great, because it's him going to Shenzhen and figuring out, learning on the fly, how you convince a Chinese manufacturer to make something to your specs and how you build the test rigs and all this other stuff. Now, we didn't face some of his challenges, because we were in Malaysia, but it's a pretty accurate view of the challenges you face. Yeah, highly recommend that book.

[0:42:02] DH: We also got really lucky that T referred us to a production consultant who is great at this thing. If we hadn't known that, and if we hadn't been working with him, and we'd dug up some factory in China that would be willing to do something at this scale, they would have - it would have been a disaster. They probably would have taken us for the fools we were, I guess. He's done a tremendous job. Yeah, the factory was a perfect match for us. They're great. Yeah, I don't have any more to say there.

[0:42:39] JN: Yeah, awesome. See, we're all getting close towards time. I guess, a couple of the last questions to wrap up. One of the things, again, that I learned around this interview is that it seems like, loads of people at Panic have incredible 10 years. A lots of people have been there from very early days, or at least a duration that I perceive as being multiples of the average tech industry tenure rate. What do you think creates that? What is going on culturally there that's making this happen?

[0:43:11] DH: Well, we all really like each other. I think, Panic tends to hire people who are very inert, maybe. Not really go-getters. I don't know.

[0:43:20] JN: Not really go-guys, he says after making a hand-hold console from a software company.

[0:43:25] DH: They treat us really well. It's a great place to work. The founders aren't driving Ferraris and everything. Everybody's really wants everybody else to have a good time and a good job. It's been a really great place to work. We've had a few people that show up and it's just not for them and filters that pretty quickly. Everybody else, having a good time.

[0:43:53] JM: I think what Dave said, and that the thing that people don't understand about Panic is the tech industry is seen as very homogenous, but Panic's older than Google. It was never founded on a startup mindset. It's always been about creating a company that makes products and sells those products, just like a grocery store, or some other stable business. That's what Cabel and Steven have created over the last 26 or so years.

Also, just being, I don't want to go so far as to say anti-capitalist, because that's not right, but we don't do a lot of things that a lot of other companies do. We don't worry about what people are doing with their time. If you need to go off and go to your kids' school thing in the middle of the day, you just do it. I liken panic to, at this point in our size, an orchestra. Everybody's playing along in the orchestra, and you can tell when someone's struggling or not having - not playing to where they should be playing. Really, we're all just trying to move in the same direction. I don't know. It's like a little family.

[0:45:16] DH: Any job stress that exists is always internally created. We don't really have deadlines. You may have noticed that. We take as long as we need to get something done.

[0:45:27] JN: There's no arbitrary urgency. Things take what they take.

[0:45:30] DH: Exactly. Yeah.

[0:45:31] JM: Well, we've never taken any outside funding, so there's never been anybody else saying, "These are the performance metrics we want you to hit." We make ourselves happy first.

[0:45:45] JN: Yeah. Awesome. Yeah, just take us back to Playdate briefly. Are there any particular creators, or games that you'd recommend folks check out if they're listening and have a Playdate sitting at home?

[0:45:56] JM: I will be honest that I have not kept up on everything that's coming out. I mean, I can't keep up with the network out there. I mean, I think for me, what's more exciting than a particular game is that tiny yellow machine community and all the cool things that they do with their community awards. That to me is more incredible than any particular game. The fact that there are people that care enough about this thing that we made to spend their own time to raise other people up and do awards shows and be goofy about it. That to me is it's incredible.

[0:46:32] JN: A whole fan community with streams and all cool. Yeah, it's very cool.

[0:46:37] DH: I have a problem that I can't actually play a game on the Playdate without paying attention to everything that might possibly be going wrong. I'll see a little glitch, or something and I'm like, "Okay. I got to go." I load the game into the debugger and okay, I've got to figure that out. I don't think I've really actually sat down and played a game in a while now. I really wish I had more time.

[0:46:59] JN: That makes total sense. A comment I hear a lot from game developers, but also, people who make tools for games, which is like, yeah, making tools for gaming ruins games for you. Too much seeing how the sausage is made for sure.

All right, well, thank you both so much. This has been super delightful. Really appreciate your time and yeah, thanks for joining us today.

[0:47:19] JM: All right. Thank you.

[0:47:19] DH: Thank you.

[END]