How do I get started in PICO-8?

If you're dipping your toes in PICO-8, you might find yourself staring at an inky, blank canvas, wondering:

"Shoot! What do I make next?"

You could always clone classic games. As John Carmack writes,

My stock suggestions for aspiring game programmers is to try to both clone classic games to learn from the ground up, and to work on mods to large scale games to learn from a high level.

– Formatted from @ID_AA_Carmack's tweet

Which is great advice. But how exactly do you clone games?

Heck, what if you don't wanna clone games?

Maybe you have ideas of your own, but you aren't sure how to make them a reality.

Whether you choose to clone games or not, you'll need to just DIU it (do it).

It's a lame pun 😅 that stands for Draw-Init-Update, and it represents the essential process of getting something on the screen.

If you don't know what to do next, "just DIU'ing it" will kickstart your creative juices, and get you making games.

Here's how.

1. Start with the feedback

PICO-8 offers 3 callbacks that imply an order of doing things:

1. _init: First, you define your game's state.
2. _update: Then, you update your game's state over time.
3. _draw: Finally, you draw your game's state.

But that order is misleading! Instead, it should be:

1. _draw: First, you draw something.
2. _init: Then, you pull values out of your drawing, into variables.
3. _update: Finally (if needed), you update those variables over time.

Get something on screen first, then make it move. So you're always excited about what you're making.

Heck, you don't even need to be a great pixel artist. Try improvising with rect() and rectfill():

Remember: all your brilliant game mechanics don't matter if your game looks like this:

(But you know what'd be cool? A game that's all audio. If you make one, please tell me!)

2. Evolve your feedback into a game

When you start with feedback, next steps become obvious.

First, you let your imagination flow onto the canvas. You fill out your _draw() function:

function _draw()
 cls()
 rectfill(64, 64-1, 64+3, 64-1, 8)
 rectfill(64, 64, 64+2, 64+4, 15)
 rectfill(64, 64+2, 64+2, 64+3, 8)
end

It's clearly Mario, what do you mean?

Then you add parameters, so you can explore variations of your drawing.

function draw_player(x, y, w, h, c)
 rectfill(x, y-1, x+w+1, y-1, c)
 rectfill(x, y, x+w, y+h/2, 15)
 rectfill(x, y+2, x+w, y+h, c)
end

function _draw()
 cls()
 draw_player(32, 72, 4, 4, 8)
 draw_player(52, 70, 3, 6, 3)
 draw_player(72, 70, 3, 6, 2)
 draw_player(92, 72, 6, 4, 9)
end

Interesting...

Maybe you like a particular set of values.

So you save those values in _init() to keep them around.

function _init()
  wario_lol = { x = 64, y = 64, w = 2, h = 3, c = 15 }
end

I like it!

Last but not least, you can make your drawing move:

function _update60()
  if (btn(0)) wario_lol.x -= 1
  if (btn(1)) wario_lol.x += 1
end

it's wario lol

At this point, pat yourself on the back. You can't play a static drawing, but you can play your PICO-8 program. Your drawing is now an interaction!

It's not quite a game though, which leads to the next section...

3. DIU is the fundamental unit of work

If you're like me, you're brimming with ideas for games.

Maybe there's a strong feeling that you wanna explore. Maybe you want to make a game that your mom would play. Maybe you wanna try designing a couch co-op game.

It's lovely to have ideas. But without a solid grasp of how you'll execute your ideas, they will never make it to reality.

The antidote? Break your game idea into small "DIU it" tasks.

Take a platformer. Minimally, you need:

1. A player that can move using arrow keys
2. Gravity, and a ground that prevents the player from falling
3. The ability to jump when on the ground

That's 3 "DIU it" tasks for you to implement. For #2 above (gravity), that might mean:

1. Draw: Draw the ground
2. Init: Save the y-coordinate of the ground to a variable
3. Update: When the player exceeds the ground's y-coordinate, prevent movement

List out your "DIU it" tasks, and flesh out the DIU steps:

By doing this, you can rest easy. Your idea is only so many coding tasks away from reality.

Ctrl-R is your friend

I like to see stuff as much as possible. So, my iteration time is just usually a couple lines of code before I look at it again. I run my code over and over, like thousands and thousands of times. I write a couple lines, I wanna see how it works, so I know that what I wrote is not going to turn into this big huge problem later, and so I’m always working on getting cool stuff up on the screen and so I’m always excited the whole time I’m making something.

– Transcribed from a talk by John Romero 

In closing, break your ideas down into "DIU it" tasks.

Draw some graphics. Then get those graphics moving.

Rinse and repeat, and ride the thrill of seeing your graphics come to life. 🙂