 My name is Ayla. This is the joys of Pico 8 token crunching. We're going to be talking about the Pico 8 game development and very, very weird things that happen when you are forced to reconcile multiple competing limitations. So a bit about me, my name is Ayla. I'm an independent game designer and developer, which means I make games. So about a year and a half ago I came across this cute little thing called the Pico 8. I fell in love with it and since then I've just been making games pretty much non-stop for it. I'm on the subways anywhere I can get a chance. Many of you probably haven't heard of the Pico 8 before, so that might be a good place for us to get started. So the Pico 8 is a fantasy console which you can think of as a gaming platform that kind of splits the difference between modern-day convenience and old-school limitations. So any Pico 8 game has this very retro look to it, but it comes with a lot of features that make it fun and easy to play and develop for. For example, it comes with a built-in code editor so you can code your own game. It comes with a built-in sprite editor so you can draw sprites for your own game. And it comes with a chiptune editor so you can et cetera, et cetera. Music, sound effects, which is really cool. It makes it really easy if you're looking to get started in game development. I would highly recommend it. It's a very cool platform. It does come with one or two limitations. It comes with a lot of limitations. And this is really interesting too because these limitations are completely artificial. We have the technology and hardware to do better than this, but they were chosen specifically to make it fun to make games for the Pico 8. All these restrictions are specifically chosen by the creators so that making a game is fun and achievable. And I want to focus on this one right now, this little innocuous 8192 tokens. So in addition to all these restrictions, Pico 8 limits you on the amount of code you're allowed to pack into a game and the way it measures that is tokens. You're only allowed to pack 8192 tokens into a game. That number is embedded in my nightmares. If you want to know what a token is, it's these little orange bubbles, basically any aspect of the code that is independent like an if or an else or a number or variable that all counts as a token. This little function to normalize a vector is 43 tokens long. A great thing about measuring code in this way is there's no incentive to minify or uglify your code because even if you change variable names, it would still be the same number of tokens, which is really cool. Moving along, our game isn't just code, it's also beautiful cutting edge graphics. So Pico 8 does graphics in the same way a lot of other 2D engines do graphics. You have a sprite sheet, which is basically an image with all of your assets scattered about it. And then when you wanted to draw something to the screen, you have all this well-named sysper function. And you pass in a rectangle from the sprite sheet, a position on the screen, and it'll copy all those pixels in that rectangle to that position on the screen. And there you go. And you just repeat that and you can render your game. Games aren't just code and graphics, so they're also sound. So we have a built-in chiptune editor. We have 64 slots for sounds, 32 notes each. If we wanted to play a sound effect, we can use the better-named suffix, a function, and then we just call that function, pass in the index of the sound we want to play, and we can play the sound. Alternatively, we can pass in a start and an end note, and it'll play a subset of that sound, which is great. Great. But here's the thing. We have 8,192 tokens. We have 128 by 128 sprite sheet, and we have 64 sounds. And each one of these alone is already really restrictive, and it's hard to build a game with one of these. Doing it with three is really hard, and really, really weird things happen when you try to do all of that at once. So to walk you through that and convince you that's a case, let's try adding a birthday snake to our game. So problem number one, our sprite sheet is already full of happy birthday animals, so there's no place to put our snake, which is really sad, but I noticed something. This grumpy cat is actually perfectly symmetrical, so why are we storing both halves in the sprite sheet? Why not instead, let's just store half the cat in the sprite sheet, and then we'll call the sysper function twice, once to draw the left half, once to draw the right flipped half, and then we can reproduce our cat perfectly, except our grumpy cat's cute little polka dot hat doesn't really work anymore, but luckily we have some great programming tools to account for that. Let's just change it so it's a striped hat. And now we can draw our cat to the screen successfully. But oh no, there's another problem. Oh wait, no there's no problem. And now we can put our snake in the sprite sheet now that we've made some space. But there is a problem, sorry for that. When we're drawing the mirrored cat we're actually using more tokens of code to do that because we need to draw the sysper function twice, and that means that we've gone all over our token limit, so now we have too much code, so we need to find somewhere in our code to remove tokens. So going through our game we have this meow function that calls a sound effect, and actually it's calling a very specific couple of notes on that sound effect, which corresponds to a meow sound, and the first four notes above that correspond to a purr sound, but we're not playing those, we're playing just the last four notes. But we need to save two tokens, so what if we just got rid of those, and now whenever we meow, we momentarily purr before that. And like maybe that's not good, but we need to cut two tokens somewhere, so what if we just did that? So now whenever you meow, you purr for a little bit beforehand, but at least now we're under our token limit so we can play our game again. And then my product manager comes up to me and asks, so were you able to add the snake to the game? And I say yes, here's the thing. To add the snake, the cat needs to have a striped hat, and it needs to purr before it meows. And this is where my product manager frowns at me, maybe schedules a one-on-one. But this is a really interesting thing, because who could have predicted that these things were related, these seemed completely independent. And the first time I was making a Pico 8 game, that was pushing the limits of the engine, I ran into this a lot and I didn't have a mental model for thinking about it. But I turned to, for all things, my experience as a university student, who knew, and thought of it this way, my game is a miniature economy, and tokens are the currency. So this is kind of like a new mental model that helped me think about and build Pico 8 games that pushed the limit of the console. I have 8,192 bucks or tokens and I can spend them to buy behavior, which is code or sprites or sounds, or even readability, readability cost tokens. And if I spend all my tokens, I can sell things to get some tokens back, sell some sounds to buy some more sprites. And this is kind of a really interesting way of thinking about building a game and programming something. And this turned out to be a really cool way of thinking about it, and there are other benefits of thinking it this way. So we have a limited sprite sheet, which you might think means we have a limited number of sprites that we can pack in there, but we saw before we were at a max size for a sprite sheet and we were still able to add more sprites. It's just that the cost of doing so rise. So there's this cool thing where there's diminishing returns to adding sprites to your game. The more sprites you add, the higher the token cost for adding the next sprite, which was a very economics thing. And we can also think about if we were to have a game that had a certain amount of functionality or code or behavior and a certain number of sprites, there is a cusp along which is like the maximum amount we can have. So if we were to be at the edge of that cusp, we couldn't add any more sprites or any more code or any more behavior or maxed out, but we can move along that cusp. And that's like a really important aspect of economics too is this thing of a once you reach the maximum point, it's just a matter of trade-offs from there, which maps really well to what I was experiencing with Pico 8. And I don't think this is the universally best way of thinking about something. It's a little hard to describe. It doesn't always work. Pico 8 definitely has stronger relations than other development, but I think there's still ways, I think this can be a lens through which at least I've started to view other projects where I'm working on my website, maybe I'm not restricted to the number of characters the way I am on Pico 8, but I am restricted to the amount of dev time I'm able to put in. And maybe thinking about it as like a currency that I spend on things allows me to see like at some point I'm gonna need to like sell things to buy other things. And I think this could be a cool way of communicating those to people. So that's what I've learned from doing a little bit of Pico 8 game development. Thanks so much.