EPISODE 1776

[INTRO]

[0:00:00] ANNOUNCER: PICO-8 is a software-based gaming console for making, sharing, and playing small games with a retro aesthetic. It emulates the look and feel of 8-bit consoles, providing limited color palettes, screen resolutions, and memory constraints. The PICO-8 dev environment uses Lua and is focused on being accessible to developers while offering depth for complex projects.

Johan Peitz is a games industry veteran and developer extraordinaire, having created dozens of games across many platforms. He's an expert in PICO-8 development and joins the podcast to talk about creating games for the console.

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.

[EPISODE]

[0:01:05] JN: Welcome to the show, Johan. How are you doing?

[0:01:07] JP: Thanks, Joe. I'm really good. So happy to be here.

[0:01:10] JN: I've followed your work for a long time as a big PICO-8 fan, and as we'll cover, you are one of more prolific PICO-8 devs. I think I counted yesterday and I think it was 7 or 8 of the 30 PICO-8 games on Steam are yours. So, I'm very excited to have you on the show.

But before we start talking about PICO-8 and PICO-8 development, I wanted to - one thing I didn't know is what was your journey into game development and how did you come to become like a PICO-8 dev in particular?

[0:01:37] JP: Well, I think that's two very different things. I started out with board games, when I was a kid, a huge fan of everything that had dice in it, basically. Then one summer, I guess I was 10 or something, a friend of mine had a Commodore 128 at home and we shut off all the light, closed the windows, closed the doors, and we spent an entire summer just learning everything about it, how it worked. I guess we weren't too good at it. He had a cousin who knew way more than we did, but definitely my first intro into computers. From then, I just realized all the things that I wanted to do with board games, I could now do, or I couldn't do it, but I could at least attempt to do it inside a computer instead. Basically, I've been stuck since, so that was, I don't know, 35 years ago or something. It's been a while.

[0:02:25] JN: That's awesome.

[0:02:25] JP: But I think what I actually liked with PICO-8 was that it harkens back to that day, right? You just launch it. There's a prompt. You can just start typing. Everything is testable from the get go. You don't need any specific setups or plugins or everything. It's just there. For me, it's also similar. I think if I think back, I also used AMOS quite a lot, which was a game programming package for the Amiga. I think it was for the ST as well, maybe also is integrated package where you could just do everything without touching anything else.

I think Flash was really close to that as well with ActionScript, and I think all those environments are things I really, really, really enjoyed when I was using it, and PICO-8 was just the best of both worlds, right? It's the old stuff, then also this really nice environment where you have all the tools that you're disposed of without having to do. Build steps or convert things back and forth. You can just jump in and build stuff.

[0:03:18] JN: Yes, that makes a lot of sense. And especially, I guess, one of the elements of nostalgia that you hear people talk about with the retro consoles and with like the Commodore and the Amigas is the experience of booting up into it, being able to like get going with making stuff straight away and there being nothing in between. So, that drawing about the PICO-8 makes no sense.

You mentioned the intro to the Commodore being 45 years ago. I know you've been in the game industry a long time. When did you come to find PICO-8 and start using PICO-8? I imagine you were still working in the industry before that?

[0:03:45] JP: I think that must have been, oh, I don't know, six, seven years ago or something. I think I wasn't one of the early adopters by any means. I like to jump in when things are a bit more stable and I don't need to be the first test person for that stuff. But I was still working in the industry, huge issues, not issues, but there were always, these non-compete clauses when I was, if I had a proper job, so to speak. Could I actually do this? Could I do a game jam? Who owned the code I wrote, et cetera, and all that stuff. But I was so fun to work with. So, I ignored that stuff most of the time and nobody came knocking on my door. So, I guess it was fine.

[0:04:24] JN: Nice. Awesome. So, we've spoken about PICO-8 a bit and alluded to what it is. But just for the listeners who aren't aware, can you explain briefly what PICO-8 is?

[0:04:32] JP: I think it's best described as, I mean, it's not a game engine either, right? It's a console. It's the Commodore 64, basically, that you can boot up straight at the prompt. It has all the tools you need to make a nice-looking game. What makes it different from similar packages, I think, is the restrictions, right? It's very harsh on what you can display, how much CPU time you have, how much code you can put it in, how much graphics you have. There's only 128 times 128 in terms of sprite space et cetera. So, very often you run into these restrictions and I guess to a newcomer that can seem as a turn-off to some extent. Okay, but I want to do these big things and now I can't do my portraits or write my long procedural code or whatever it is.

But I've always thought of PICO-8 as almost like a game-like experience when you develop for it because as you learn more about the program, you also know about how to kind of bend the rules slightly. It turns out those seemingly super harsh restrictions, they aren't really that harsh because you can kind of, "Okay, I can use the sprite memory for my music instead, or if I write this piece of code, I can start compressing my tile map or something." Slowly it becomes a much, much bigger environment than your first thought, but it's only available once you kind of had that epiphany that how it actually works on the inside and constantly making these trade-offs between should I use this space for graphics? Should I use this space for code or whatever? That almost becomes like a puzzle game in itself and just making these trade-offs back and forth and it's super rewarding when you actually get to fit your ideas into this extremely confined space.

I don't know if that actually explained what it is, but I think it's at least bits of the philosophy. I mean, it's a nice ecosystem, super friendly community. Most of the games are, you can just download them through a BBS tool and check out how they are made, which is also a great learning tool, right?

[0:06:31] JN: Yes, the choice of BBS is like the distribution mechanism, the native distribution mechanism is also, I guess part of the retro nostalgia part of it. So, you mentioned a lot of interesting things that I want to follow up on. I guess, like, first of all, talking about the constraints, I guess it's, I've always taken it as like a prime example of constraints breed creativity or whatever. But I think I'm wondering this particular case of you, because as I said, my perception is that you ship a lot of games very fast. Is that especially when you're starting out, the limitations really help you avoid scope creep, right? Like you're forced to not scope creep and to finish the game as you originally like a slice of game as you intended. Do you find that to be accurate?

[0:07:06] JP: To some extent. I think I am a lot less structured as a developer than what people might think. I usually have a seed of an idea and I see it more like, I don't know the English word is, but a stone masons or something, where they have this big block of marble or something, and they start chopping away and maybe it's supposed to be a dog or whatever. Then it turns up, "Whoops, I broke the tail. I can't really put that stone back on." And you have to kind of say, "Oops, it didn't really fit inside the PICO-8. How I'm going to change the design on my model or sculpture to actually work with what works in it." Then it's kind of, "Okay, didn't really turn out the way I wanted, but what changes do I make to the design so it actually fits and still makes a lot of fun to play?"

[0:07:53] JN: You have to let the stone tell you what it wants to be.

[0:07:55] JP: To some extent, I'm more of a following a very vague vision when I develop games more than that. I have a very specific idea from the beginning.

[0:08:05] JN: Cool. So, when you're following that process, I guess at the point where you're at that idea stage, how much are you already thinking about the constraints of PICO-8 or is it, you come up with grand visions and then they get paired down to size? Or I guess by this point, you've been doing it for so long, you're already like, you're thinking in terms of what you can do more often than not.

[0:08:29] JP: Yes, definitely. Usually, I try to make things kind of like half of the space or scope that PICO-8 can offer, and then it kind of grows a bit from there. Then I can use the last 25% to push it a bit extra, right? Because I find it extremely rewarding when you can fit that type of gameplay or technical solution into the game that people didn't really think was possible. Then once that works, then you can remove all the other fluff, because nobody cares about that. The technical achievement is big enough to be the main driver of the game. It's still seen as a complete package, but other things can be down prioritized very much once you have that core that really works.

[0:09:12] JN: Interesting. Yes. The technical achievement within the limited environment being a selling point, I guess, is another advantage of these ecosystems where everyone is dealing with the same constraints. I definitely think that's true of picoCAD. Like I often cite picoCAD, which you will talk about more in detail in a moment, but just for a brief summary for listeners, it's a CAD tool built in PICO-8 and it's 3D.

I always mention picoCAD as like an example of like, here is something that you would first of I think shouldn't be possible in this, but obviously it is. Yes, well, definitely I've got a bunch of questions for that in a minute. But I guess to get onto more concrete terms, so you mentioned some of the tools available. I think it'd be cool to go over what is actually available, what is actually like to be a PICO-8 dev. So, I guess first of all, you mentioned briefly, like the idea of messing with the memory and fitting music in so-and-so place and your like maps in another place. Can you run through like the tool suite, I guess, on PICO-8 that you use?

[0:09:59] JP: Yes. So, some developers, I know they sit in other environments, for instance, maybe they use visual code. I'm Swedish, so I'm not going to promote a specific tool now. So, there are other tools available, you always have to say. But I've more and more found that staying inside the little box that is PICO-8, I mean, 128 times 128, that really helps me not running away with my ideas. You keep variable names short. You keep the scope short. You keep the functions short and it has to be very readable and understandable in order to be able to work in that environment. That really helps me moving forward.

I mean, the code writing books, whatever it is.

[0:10:41] JN: Editor, I guess?

[0:10:43] JP: The editor, exactly. That's one thing, right? And then there's the sprite editor, again, 128 times 128, 16 colors, not sure I mentioned that, that are predefined as well. So, it's very set, which gives all PICO-8 games a very specific look. You can almost instantly see that it's a PICO-8 game. Now, we're making another game in another engine, but I'm so colored by my PICO-8 work. It looks like a PICO-8 game. "Oh, that's PICO-8," people told me, but no, it's not. It's actually something else, but it still has so many things in common.

The sprite editor, and then there's the tile map. So, I don't know how big it is, probably 128 by 128 as well. But that actually shares memory with the sprites. If you want to use half of the sprite bank, you lose half of your tile map, right? Or vice versa. There's obviously ways around that once you get to know the system. But that in turn, then forces you to do some other things. For instance, if you want to use the whole tile map, they have to move it to somewhere else in the memory and then you can't use the actual tool that is built in to place your tiles which forces you then to write your own tile editor and things kind of escalate from there, right? So, lots of tooling and the custom-built stuff to get it working if once you start pushing the limits.

There's sound editor for sound effects, not my forte, same with music editor, a classic tracker that was really popular in the Amiga days. That's it, I think. So, all the basic things to get stuff up and moving. I should also say it's all in Lua, which is if people aren't familiar with that, it's a super friendly, very easy to use language that leaves you open to all the mistakes you can ever make with no type checking or anything else. You have to keep everything in your head.

[0:12:27] JN: Yes. Not an uncommon choice in game dev land, but I know no countless people who immediately despite all of its advantages and pleasantries who bounce off of it because of indexing starting at one and not zero.

[0:12:39] JP: Endless to date.

[0:12:41] JN: Yes, cool. Thank you for some of this. You mentioned various like hacky ways to get around the memory constraints and stuff. One of the ones that I think is really interesting that I've not really doubled with, but I know that you've used it a couple of times, that you used on, I think, I believe you used it for the arcade distributor you gave, that it is multi-carting. Can you tell us a bit about multi-carting and how it works, I guess? I guess actually, first of all, we'll start with what is a cart in the context of PICO-8. I guess, how it gets distributed?

[0:13:12] JP: So, once you're happy with your game, the main idea is that it's kind of, I guess, Joseph White who's built the whole system. He likes things to have physical representation, or at least as close as you can come. You can save all the code, all the graphics, everything. It can be saved both into a text file, but you can also export it into a little PNG file that actually looks like a memory card or something with a little image on and everything. It's very cute and he uses lots of little compression techniques in special layers of the PNG files, so it doesn't actually get garbled, but the image actually stores all the code, all the memory stuff you made, and the whole thing, which is a technical achievement in itself, I guess.

[0:13:53] JN: Yes, just to make that explicit for anyone who didn't catch that, that is PNG, the image format is being used to store all of the games. It's incredible. It's so cool.

[0:14:01] JP: Which makes it super easy to store, right? You just send it on Discord or upload it somewhere or wherever. People can just load that and play it, look at the code or the graphics or whatever, or upload it to this BBS function where there's tons and tons of great games. But for that to work, you're kind of limited to the space that PICO-8 gives you. And I think it's about not totally sure about these limits. But it has to be able to compress under 16k. I think there's a top limit of 32k characters or something like that. Then there's a token limit in terms of how you structure the code, et cetera. All that has to kind of be possible to cram together to fit into this cart. That's the cart, right? It looks like a cartridge.

But if you think, "Oh, I wrote this code and it doesn't really fit, for instance, in my game, Golf Monday." We have two golf games, Golf Sunday and Golf Monday, where Golf Monday is the sequel. There I wanted to have a much better course generation, right? So, I wrote an editor to make the golf course and then that is loaded into a special format, which has to reside in its own cart because it doesn't fit in the actual game cart. So, there's a title cart, which loads the main menu and you can customize for the player, et cetera. And then when you actually press start, then it also has a bit of code to generate the course, which then stays in RAM. Then the other cart is loaded. Everything about the last cart is forgotten, but since I could load the map into RAM, I can start playing with that as if it was in my original cart but it wasn't quite then.

People are of course changing this into craziness, some people. I mean I know the guys who made Doom and other world ports and things like that they have like 64 carts and it's just massive. So, there's huge build steps to make everything work. I only made double carts, so to speak. I think that's enough for me, but it's very convenient if you have, for instance, a dungeon crawler and you need a separate cart to do all your generation and you just load that cart to the calculations. Put that in RAM and then swap back to the original cart.

[0:16:06] JN: It's very cool.

[0:16:07] JP: But then you kind of lose some of the distribution methods that are available and you need to kind of package it up a bit differently.

[0:16:14] JN: Yes. Which I guess brings me on to my next question, and we'll talk about this more in a bit. But you make PICO-8 games commercially, you're not just distributing them within the BBS. You sell them on all kinds of platforms and you provide them cross-platform as well. What is the build process for that? So, I know there's export tools, but does PICO-8 natively support building
executables for the platforms?

[0:16:35] JP: Yes, it's the short answer, and it's just super easy, just write, export, and then it gives you the Windows build, the Mac build, the Linux build, and the Raspberry Pi build straight off, and that's it. So, it's horribly easy. It's so easy. I think I released six or seven games on Steam. I developed them on the Mac. I've never tested the Windows builds. I just uploaded them, and they're like 90% of my players use Windows, obviously, but it just works so well, so I don't even need to test it.

[0:17:04] JN: Nice. The advantage of your whole game engine being its own little virtual machine, I guess.

[0:17:09] JP: Yes, definitely.

[0:17:09] JN: It's very cool. So, you mentioned along the way, building your own map editors, building various tools, and some of these tools are commercial releases, picoCAD and picoSynth. Again, this is one of the things my perception of you as a PICO-8 developer is quite unique, because I think you build an unusual amount of tools in PICO-8. What led to you have - was that just a natural emergence of your own game development practice? What made you start wanting to build tools in the editor?

[0:17:32] JP: I think it's a necessity sometimes to make the games I want to make. And also, lots of time, like you mentioned, picoSynth and picoCAD. They're all the starter or something else, right? And then it turned into something, picoSynth, which is, how should I summarize that? It's a modular synth experience, I guess, where you can kind of, you create different boxes of equipment and then you connect them with the springy cables and sound is made.

Usually, same with picoCAD, I don't know anything about 3D. With Pico things, I know nothing about Synth or how they work. That actually started with me playing around with
Verlet physics.

[0:18:11] JN: Great.

[0:18:12] JP: What should I do with all these springy cables? There should be something fun I could make with them. And then it started us, maybe I can just send electricity through them and have some sort of light puzzle where you're supposed to get certain inputs or outputs. Then I just stumble onto the audio stuff. Suddenly I built out the full range of various things that you could connect with cables. I mean, for me, it's very much I prototype stuff. If I find something that's fun like this cable, it wasn't just a nice feeling to move them around and kind of click them into little holes. Then the actual application doesn't matter so much to me.

[0:18:47] JN: Cool. Yes, that makes sense. But I guess with picoCAD, that has really grown into something special. There's like a huge community around it. People use it to make games and other engines. People are exporting the tools. So, I guess for an intro, can you tell us about picoCAD and the kind of capabilities it has?

[0:19:04] JP: Yes. So, picoCAD is a time trip back to the nineties where CAD programs consisted of four viewpoints and it was very much looked like an old technical drawing or something where you need to see it from three different angles and then you have a 3D view of it. That's how I learned doing CAD back in the nineties in school. I've never been a fan of these more natural mesh like things, very dynamically move things. I'm so old for that, I guess.

But back to picoCAD. So, it has these three views. It's super limited, but you can add like primitives, like cubes, prisms, and various volumes. Then you can extrude certain faces, which is super basic, right? But that's basically the tools you have. You can build stuff, you can extrude stuff, and you can then move vertices around, of course. And then you can also texture it. You can load it in a simple texture. That's basically it and it's super simple. There's a few things more to it. Of course, you can have lights, some sort of lighting a shading model on it. You can have flat shading if you just want to use colors and textures, things like that.

But it's super simple, but the same way PICO-8 kind of breeds this creativity through, you can't even go farther, right? There's been people who's just been building amazing things in it and really learning the ins and outs of it, much more than I could ever have imagined. I mean, there's hashtags all over the place and it's to some extent to the restrictions and how it actually looks. I mean, there's lots of - for this to work, there's no C buffer in it. So, the faces can get all jumbled if you don't do it properly and things like that. They have a very distinct look the same way you can say this say this is a PICO-8 game. I think you can safely say this is a picoCAD model, because how the kind of software encourages you to work.

[0:21:00] JN: When you say it's that aesthetic of writers, because how the software encourages you to work, was there intentional design in that where you were like, I want these things to look a certain way, and this is kind of how the tool set is developing? Or was that purely organic? It just came out of the constraints situation.

[0:21:15] JP: When I started making picoCAD again, there was some talk about, "Oh, you can do 3D in PICO-8." So, nice. People were doing some various experiments and did I, and I started with cubes, et cetera. I thought, "It would be nice to have a car, and I could still write the specification. I could just write that in text." It made sense, and I could edit the UV coordinates and things like that. Then, "It would be nice to do a muscle car with sort of exhaust on the hood or air intake and things like
That." It quickly became very difficult to do this on graph paper, right? So, then I just started trying out what if it looks like this, blah, blah, and I quickly find a way that worked really, really well. Then, as things happen, that project became much more interesting than actually using the models for anything. 

But in that step, since you worked on graph paper, it kind of became very natural with snapping, for instance. The game or the software doesn't allow you to put vertices wherever you want it snaps to 0.25 or a quarter of a unit. That also makes it really, it promotes a certain chunkiness or roughness of the models. You can hold a key and do freehand movement. But that's for the pros, right? Also, it makes it much easier to connect certain volumes, because you can't merge meshes, as we have to kind of put them really close to each other. Thanks to the snapping, then it becomes really -

[0:22:39] JN: Cut the lines up. Yes.

[0:22:40] JP: Exactly. And that's then stops stuff from bleeding through things like that. So, lots of technical decisions also led to how it looks right. Then the big weight palette is very specific. We had to put the light model on that. If I want to fade, for instance, red, there's no dark red, right? So, it has to fade into brown, or pink has to fade into red and orange, et cetera. It gives also a very certain look to the shading, depending on what colors you use in your model. Instead of just fading into dark, the shade it actually fades into different colors, which gives a nice vibe to it.

[0:23:16] JN: Awesome. Okay. So, I do want to come back to the shading and the lighting engine, but I guess first a fundamental question, and this might be an uninteresting question, depending on how much you know about 3D rendering, or how much to do this in 3D rendering. What does it take to do 3D in picoCAD? Because to me, that's still mind blowing. But this might be my ignorance I find that is part of the reason I find it so interesting.

[0:23:36] JP: Yes. So, PICO-8 actually comes with an example called Dots 3D, which looks like an old eighties demo with spheres circling around. It's like booting up some sort of crack intro to whatever game you want to play. I think most of picoCAD still uses that for its base code, right? And then it's just packed with layers on top of that. But that's the core is still rotation around Oracle or the central of the scene. I mean, if you have one dots with X, Y, Z coordinates and another, then you can draw a line between those two, right? Then you arrange your dots into a cube and there's your wireframe. Then PICO-8 has this specific thing which makes the texturing work, which is called tline.

So, it draws a line, but instead of you just specifying a color, you specify two coordinates basically in the tile map, and then it colors the line according to those colors in the tile map. You first draw your texture in the sprite map, and then you use those sprites to place them as tiles on the tile map, and then you can start using that as a texture for your draws.

[0:24:44] JN: Right. Cool. That's really cool, because that was part of where I think my mental model was struggling. So, when you first come to PICO-8 2D, you're like, "Okay, I'm drawing a sprite and that sprite is living on the tile." That's going on a map, and it's very - the model of what you're interacting with is very straightforward, and I'm hearing how those parts interact with the 3D is really useful. Okay, cool.

[0:25:05] JP: Then you also get perspective correctness, right? Usually, when you draw a texture in 3D, have to kind of think, "Okay, it's supposed to actually get smaller." The shape gets smaller because I can easily calculate, but the texture should also be drawn differently depending on where it is in the depth. But there's nothing of that, right? So, you also get this PlayStation one aesthetic where it's kind of a bit jittery and things are kind of moving a bit janky, which I think a lot of people like is well, because the same way pixel art is my childhood. The PlayStation one art is a lot about the people's childhood.

[0:25:39] JN: Yes. People invested a lot of time in recreating that aesthetic. So, if the engine doesn't look - that's great. Yes. Onto the I guess like the lighting and the shading, so as we said for various like geometry reasons, the picoCAD models look very distinctive, but you have a really nice differed shading approach as well. Can you talk briefly about that?

[0:25:59] JP: So, PICO-8 comes with a dithering functionality, when you draw basic drawing primitives, basically, so if you want to draw a square, you can apply a four-by-four pattern to it, I think it is, which can then be a check board or a heart or a square or whatever. It's quite useful when I do particle effects in games for instance, if I want things to fade out, so they can at least - you can't do transparency but they can at least be more sparse in terms of their pixel density to some extent.

But then you can also set, I think this is how you do it. You can set color - whenever you draw something in PICO-8, you set, okay, when I draw it with color seven for instance, but there's actually more and you have 16 colors but that's just the first 4 bits, I guess, of the color space. But you can send the whole byte so that means you have four bits at the bottom for the actual color and the higher part of the bytes you can use for another color. So, then you can tell PICO-8, "Okay, use this dither pattern that I specified and all the lit bits are with one color and all the unlit bits or with the other color." Then it's just a matter of calculating which angle the face is facing and then deciding, okay, if it's this color, then it should do this darker shade instead on every other pixel.

[0:27:18] JN: Very cool.

[0:27:18] JP: If that makes sense. Then while I was developing that, I usually am very open with my progress on social media. It gives me a lot of good feedback. Of course, Zep, Joseph, who's making PICO-8 was following that as well to some extent. So, he actually started implementing stuff that I needed for picoCAD. So, previously it wasn't possible to apply these dithering effects to textured sprites or tline this texturing thing you can use so that you kind of slipped into a new PICO-8 version, so I could get even the texture so I could lit, so I can use the dithered lighting module even on textured faces.

[0:27:58] JN: That's really cool. That's awesome. I guess that kind of leads into something that I didn't ask for was meant asked earlier, which is in terms of the - so, we mentioned the codes are obviously written in Lua, but in terms of the API, how much is the PICO-8 API doing, providing for you in terms of utilities when you're developing a game? What is the kind of tool set it gives you?

[0:28:17] JP: I mean, you get an API to kind of access all these things like sound, style, map, sprites. There's a lot of syntactic sugar in PICO-8 Lua version that it doesn't exist in the real one. So, it means that I miss a lot, for instance, with the tables. I mean, there's lots of shorter words. It's just so much easier to express yourself in code than having to write, I don't know, table dot, remove something, something and things like that. It's just a horror for me. Once you get used to just dell and add. That works in PICO-8, because the API is so compact, so it doesn't collide with anything else, right? Also, when I started writing PICO-8, there was no split functionality. So, you can take a string and then split it up on some delimiter. That didn't exist.

So, it then uses my own version of how to write my own version of that. But also, due to the format, I mean, the safe format in PICO-8 is basically a JSON file, not exactly. It's more like a Lua representation of a table, so that it also had to be kind of a special split that could handle the nested tables in that. So, there's quite a lot of special stuff. I mean, there's no UI functionality in PICO-8 as well. All that is also built custom.

[0:29:39] JN: Yes. Again, this is somewhat of a silly question. So, when you're talking about writing your own split implementation, or even your own tools, how are those used? Because there's no package management situation, right? You're not like importing modules. Is it just case of copying and pasting your implementation into your new cart?

[0:29:58] JP: You can actually import like that. There's a little include statement. You can say so okay in case I had let's say a Verlet engine and then I could just do import verlet.lua or something. That's totally doable. The challenge with that is that if you have your special Verlet engine, then it's likely to be very generic, and if you actually want to use it for a proper game product, it needs to be more specific, and to get there, you have to rewrite it and work inside the code, and then it won't be reusable for anything else anyway. So, it very quickly doesn't really work. You can use it to kind of structure your project. But it doesn't, at least for me, it doesn't help to reuse things.

But for picoCAD, for instance, one of the key things to do was usually in PICO-8, you get three functions that are drove that are called automatically. So, there's the in it, which kind of sets everything up. There's the update, which is called 30 or 60 times per second, and then there's the draw, which just draws everything right. 

Usually, in all the programming books and what you learn in school is supposed to have the model work in the update, and then you just draw whatever the model is, right? But for PICO-8 to work, everything happens in the update, including the drawing, and I draw an update very intertwined and mixed. So, there's probably something happening in the draw function, but most of it happens in the update function. Because one thing that is, or at least turned out to be very difficult for me, if I want to use the mouse to click on a vertex, for instance, how do I know where that is? I mean, there's lots of ways to do that. You can do race and things in 3D that I don't know so much about.

But the way I solved it was that If I draw it first, the 3d model, and then as every time I draw a vertex, I can save that vertex a screen position inside the vertex, and then I kind of blend into the next step which is the update then I can just run through all the vertices, look at their screen positions. Is anyone of them close to the mouse?

[0:31:58] JN: That's cool.

[0:31:59] JP: And get all that weird stuff, where am I in 3D? In my 2D interface? That's just solved through that step.

[0:32:06] JN: Yes, that's really neat.

[0:32:07] JP: The same way when I draw a polygon or a face, and I can really quickly check is the mouse inside this face? So, it is very mixed up, and it's probably not how I would do it if I had another type of engine to write it is, but this is what I had, right? And what I chose to do, and it works surprisingly well, right?

[0:32:25] JN: Yes. Absolutely. It's again, a good example of the constraints. Like you said, without those constraints, someone might go to implementing ray tracing, but you found a really elegant way of doing it. Cause that's what you had, which is really cool. So, aside from the commercial tools, respect my picoCAD. I know, and we've spoken, you've mentioned your map editors and stuff, but like you've done some tools for your personal use that like - so you were the first person I ever saw do like PICO-8 for slide shows when you gave that workshop at EMF camp this year. I know this is a tendency of everyone. You get familiar with a tool and you're like, "I'm going to build all my tools and this and start doing really silly things." Do you have a favorite unintended use of PICO-8 that you've done personally or that you've seen?

[0:33:03] JP: It wasn't by any means, just want to say that I wasn't the first to make a PICO-8 presentation.

[0:33:08] JN: The first I saw.

[0:33:10] JP: I know Joseph White who did the PICO-8. There's a YouTube video where he does something similar. Just retrace that. I don't have any good examples for this. I once thought that I was going to make my website in PICO-8, use PICO-8 to generate the HTML code, right? Because, as you say, once you have a good hammer, everything looks like a nail or whatever the saying is, I don't know. But part of PICO-8 being so sandboxed, you can of course use it to kind of send stuff into and back and forth. But it makes it a bit hard to move out of that.

[0:33:45] JN: Yes, absolutely.

[0:33:46] JP: Making your website in PICO-8 would be truly like connecting it to the flash legacy. That would be - that would be great. That'd be awesome. It would be great though, right? So, not only build the website but have the website full-screen PICO-8 app. That would be nice.

[0:33:59] JN: Yeah, it'd be lovely. So, in the intro we mentioned, you're in the studio of Apskeppet, whose pronunciation I pretty much just butchered. You spoke about the BBS and the model, the normal model of distributing games in the PICO-8 ecosystem, which obviously has a commercial studio, trying to survive on this, you have to be slightly different about. Can you talk about how you approach being a commercial studio whilst interacting with the PICO-8 ecosystem, like how that works?

[0:34:26] JP: On a philosophical level, it's kind of difficult, because as soon as - I mean, I learned lots of free PICO-8 games as well. But as soon as I stepped out from that, it felt like I stopped paying back to the community, so to speak. That was a bit difficult on a mental level, just okay, now I'm using this, but have I done enough for the community, et cetera, right? That was a bit of a, I wouldn't say it was a struggle, but it was a very significant change in how I had to think and approach it.

But when I launched picoCAD the first time, and it was free and basically people could donate on each, and people were very generous so I kind of knew that it was possible that people were, I wouldn't say they were interested in paying for it but they were at least able to pay for things even if it came from such a limited tool. Not limited, but at least restricted tool. So, I had some ideas that it will probably work to sustain a single person if I get a nice cadence of games out, as you said.

Last year, I think I released five or six games this year, doing half of that, maybe I'm trying to do a little bit bigger things and also need to kind of slow down if it wasn't really sustainable. But it was fun, and it worked. So, I made a modest, very modest profit last year on the first year, just doing PICO-8 games, at least it's doable. Kind of stay in the game jam mode for an extended amount of time. That was hard. 

[0:35:55] JN: Yes. Because you were doing lots of experiments. I should say you share a lot of social media. Doing lots of really interesting experiments that looked like they were taking a lot of your time. Whilst also, I think the main one, I was very excited about your submarine building experiments because I love that genre of game. You were doing that and that looked like what you were focusing on, and then you shipped Hellgineers. I was just like, "Where did that come from? I didn't see that being made at all."

So, I guess even when you're in that permanent game jam mode and you're getting a game ready to ship, how much doing a process of making one game are you also already thinking about and working on the next one in the series, or were in that frantic year? I imagine it's changing.

[0:36:33] JP: It's very different. I mean, I did Shadow King, a Metroidvania platform game that took calendar time, I don't know, three to four months to make. Within that time, when I was kind of bored of it or a bit burned out on level design, I guess, then I made Cosmic Collapse, which is this merging game where you merge planets into bigger planets.

[0:36:56] JN: Which was a beautiful strategic move. Your timing with that was amazing.

[0:37:00] JP: That's been my best game, actually. I made that in two weeks by just being frustrated on my main project. I try to catch when I get silly ideas that I feel that when I can kind of, for me, can I see the path from where I am now to it being done and to see how everything kind of falls into place. Then it's very easy for me to just put on the [Sweedish inaudible 0:37:24] in Swedish, the blinders.

[0:37:26] JN: The blinkers, I think we call it.

[0:37:27] JP: The blinkers, exactly. Then I just go there in a day or so, right? That makes it possible to very quickly - I mean, the submarine game, for instance, where you build your own submarine out of modules. Code is crap, but it works. It works to tell somebody an idea of what the experience could be like and it always looks like there's lots of things going on in the background. That's usually it's just smoke and mirrors to get there working. But you can at least get the feeling of what it could be.

[0:37:53] JN: So, actually, you made a [inaudible 0:37:55] here, which is great to hear. You use lots of platforms. You sell across Itch and Steam. You also have a Patreon. How are you fine - is there a particular one that's like, more successful for PICO-8? I kind of imagined just from like vibes that like PICO-8 games would sell better on Itch than Steam. I don't know if that works in reality. How do you find them?

[0:38:15] JP: I found it absolutely so. But it also comes down to that I've had six years to build an audience on Itch. While on Steam, it's been kind of a struggle to build that up. But I think on each I've managed to sustain the titles a lot better. I had a longer tail on those titles. Where on the Steam it more becomes like a blip and then it kind of goes into nothingness. Patreon is nice to have. Super grateful for those people who want to give me some money without knowing what the game is like. It always makes it possible to at least, I know I will have something back for the game that could pay for a musician or especially art or whatever it could be.

[0:38:54] JN: One of the interesting things about your Patreon is your upper tier. I think. you release the source code as well which I think is going back to what you said your philosophical struggles with giving back to the PICO-8 community, I think, is a really great way of reconciling that that, that people still get the source code. What's your tier distribution like? Do you find lots of people are excited about getting hold of that source code or is that for like a niche, your niche like PICO-8 community member followers?

[0:39:17] JP: I have four tiers and one is like two dollars, get the games, that's it. Then it's five, I think, which is some sort of early access. You get to play the game way before. Then it's the source code thing. Then it's number one fan, which is just throw your money at me and be eternally grateful. But I think the lowest performing tier or performing, but the tier that most people are not interested in is the early access thing.

[0:39:44] JN: Interesting.

[0:39:44] JP: Then there's a handful of these top contributors, but I think 50/50 or 45/45 are just given a game or source code. I guess that tells me that it's a very developer-centric following, in my case, on Patreon, I think that's been the major struggle with making PICO-8 games commercially. How do I kind of break out of the dev community?

[0:40:09] JN: Yes, that totally makes sense. As we were talking earlier with the fact that the technical achievements are a large part of the marketing, I think there's a lot of - I mean, it's nice that the PICO-8 developers support each other and make that viable, right? But yes, actually the breakout is important. 

[0:40:22] JP: Because now that I'm - PICO-8 has been on Itch for a couple of years and I'm launching it on Steam, hoping to reach a bigger audience, right? It's part of my worry there that the people won't have this acceptance of what PICO-8 is. I mean, it comes with the key binds are totally different. It kind of starts to lag when you build two big things, even if you run it on your 16-core megaflop computer, right? So, I'm trying to do a lot of expectation management so people actually know what they'll get. 

[0:40:52] JN: Yes, that's fascinating. I hadn't thought about the - well, I mean the constraints being part of the selling point and part of the interest of any game made in picoCAD, PICO-8, if you know PICO-8, but then just being read as bad software if you're not - so, are you doing that expectation management? Is it like part of your pitch for these games as you reach for wider audience having to also sell PICO-8 in some way?

[0:41:12] JP: I don't think PICO-8 is going to be sellable through that. I mean, I can't explain it. I just have to tell people this is made on a computer from the eighties -

[0:41:22] JN: Right. And go for -

[0:41:23] JP: - and you have to live with that. If it starts to slow down, you're doing it wrong.

[0:41:28] JN: Right. That makes sense. So, you've got picoCAD coming on Steam, which I think it was November 28th, which is very exciting. You've also been talking a lot, and it's also on Steam about your upcoming game, which is Coco's Delivery Service. Is that the game that's on a different engine?

[0:41:41] JP: That's on a different engine.

[0:41:43] JN: Cool. What is the engine?

[0:41:45] JP: So, it's built - it's not built on an engine. It's built on a framework called Love2D.

[0:41:50] JN: I'm friendly with it. Yes, cool.

[0:41:51] JP: Which also has, as we spoke about the action script and it has - the way it's built up is very similar. And the way I stumbled into that was Cosmic Collapse, the game where you kind of merge planets, which was somewhat of a hit. I decided to put that on iOS and to do that, I didn't want to rewrite the code because that's boring. So instead, I wrote a layer so I could just load my PICO-8 file into Love2D and then I had kind of all the function calls that PICO-8 want to make things that went to my abstraction layer, and then that sorted out all the stuff with Love2D, right?

[0:42:26] JN: That's really cool.

[0:42:28] JP: That worked really well. And then doing all the Apple things to get it out, of course. But I guess I ported it in a day or two. So, it was very small effort. But it got my eyes open to Love2D, of course, and also the possibility of actually having a custom-made for me, PICO-8 like API without the restrictions, which is a blessing and a curse. Definitely a lot of a curse sometimes because it's so easy to just start making stuff instead of reining in.

But Coco's Delivery Service is then made in. I made the prototype in PICO-8 and it felt fun. So then, I moved that over to my API in Love2D.

[0:43:07] JN: Was Coco's delivery service needing more than you could build in PICO-8, born of the fact that you'd had this experience with Love2D and you wanted to use that? Or was it you found a game that you could then use that facility for?

[0:43:19] JP: It arose from different of perspective. So, one thing I felt that, okay, I can have this game, I can make it in PICO-8, but then it will be a very quick arcade thing, and I'm kind of want to have a break from quick things, try to slightly bigger things. Then, I also have - so the submarine game, for instance, that's definitely not going to work on PICO-8. So, there's a version of that as well in the pipe. 

[0:43:40] JN: I'm very excited to hear that.

[0:43:43] JP: Years away, maybe, but it's at least on the table. But then there's another game I want to make that I hope to reveal in a few months or so that's definitely not going to work on PICO-8. I hope that's going to be a big thing. So, I want to do some tech proofs before I get there. I don't want to know, can I actually release a game written in Love2D on Steam without it exploding on a million computers as it doesn't use a virtual machine? So, it also solves that step, can I actually do this? And then for this specific game, it can be a bit bigger, have a little bit more graphics and have a bit more power.

[0:44:18] JN: You've mentioned the upcoming gaming this next one in the future. So, I guess one of my questions about your studio as an entity is like, is this a vehicle for you as an indie developer occasionally hiring out music or do you hope to grow this as a studio and bring on more people?

[0:44:34] JP: Well, that's the question. I mean, I've run studios before and some of them grew, some didn't. It is a vehicle for me to do whatever I want. If I feel the urge of growing and taking on some other people, then maybe. If it doesn't, I mean, the main thing is I wanted to get out of the, I wouldn't call it the rat race, but I grew tired of VC. I grew tired of founders. I you're tired of politics in big companies and all that and just go back to hammering on that Commodore 64 in my friend's basement and try to get it to work. Just following my passions, basically. I've been super fortunate that it's actually is sustainable at the moment.

So, we'll see what happens, right? I can definitely feel at times that would be nice to have some people who were as invested into whatever I'm making as I was. I mean, you contract people to do art and music and things and they are nice and they like what they're doing, but they're still just getting paid, so to speak.

[0:45:35] JN: Yes, absolutely.

[0:45:37] JP: And that I can miss to just have that daily back and forth with people who want the same thing. But we'll see in the future.

[0:45:43] JN: Final question, which may just, the answer may be no. There's a lot of excitement about Picotron. Zep's next project kind of PICO-8 taken to a mock OS level and being such a prolific builder of tools and as we found out, influencer of the API. I'm very intrigued to know if you played with it at all? Have you've got any designs or things you're thinking about for Picotron?

[0:46:02] JP: I did meddle a bit with it. But for me, when I go up to that level, then I might as well do everything myself. I think that's where I ended up and still early in development, right? I don't like to make things that might break because of someone else. And I'm also thinking that the same with PICO-8, I came in fairly late. People have solved most of the problems that could just use them, right? And I think Picotron will probably have a similar journey and where I am now with moving my own PICO-8 like API into Love2D, that solves a lot of the problems that I hoped Picotron would solve as well. I mean, Picotron looks amazing and people are doing super cool things in it, of course, because people are always super crazy.

But I'm not sure yet whether I should, or how I should approach it. I mean, now a deal breaker for me is that it can't export to native binaries at the moment, right? And I need to be able to do that to make a living. So, maybe when that is, we can go back and see if it solves something.

[0:47:04] JN: Cool. Awesome. Well, Johan, thank you so much for joining me today. This has been wonderful. I'm so glad we finally got to cover PICO-8 and your work. Thank you.

[0:47:12] JP: Yes, thank you. Happy to be here.

[END]