Making a game in PICO-8

7 Comments

1. 2017-01-03 10:34 pm

   Feneric

   My daughters and nephew are all fans of the PocketC.H.I.P., the little handheld console that brings the PICO-8 fantasy console into reality. There’s a lot more info to be found on both it and PICO-8. Here are a few places to start looking:

   * http://pico-8.wikia.com/wiki/PocketChip

   * https://getchip.com

   * http://www.lexaloffle.com/pico-8.php

   * https://github.com/IkerGarcia/PocketInstaller

   * https://sectordub.itch.io/pico-8-fanzine-1
2. 2017-01-04 11:46 am

   henderson101

   I did a few simple games with the Pico-8. It’s okay, but the limits of code size and complexity are a big barrier to casual programmers. For example, getting the collision detection to work well, applying gravity in a 2D platformer – these are all non-trivial and not well explained in the docs that come with the product. You need to grok a lot of the examples, and there’s a lot of subtle ways to achieve the same thing. Where-as, if you pick up something like Unity and use the 2D engine, the learning curve is as steep in other ways, but a lot of this physics stuff is done for you. I’d love to see the authors add in more helpers to make the code more compact.
• 2017-01-04 1:49 pm

  signals

  I’d love to see the authors add in more helpers to make the code more compact. [/q]

  I think that would violate the spirit of the project.

  [q]The harsh limitations of PICO-8 are carefully chosen to be fun to work with, encourage small but expressive designs and hopefully to give PICO-8 cartridges their own particular look and feel.

  I’m pretty sure the target audience are those folks who did this on 8-bit and 16-bit machines 30 years ago. In fact the only thing that’s kept me from looking in to it (aside from available time) is that it’s Lua and not some sort of fantasy “assembly programmer’s dream CPU.”
• 2017-01-04 3:40 pm

  henderson101

  I think that would violate the spirit of the project. [/q]

  Why? The spirit of the console is to encourage people to hack on games. But giving a large learning curve to get started is exactly the opposite. Like I said, I had a few moments scratching my head, and I’m fairly experienced in writing games in Lua (Love2d, Codea), Flash (FlashPunk) and Unity. I also wrote a lot of stuff in BASIC as a kid. But the disparity here is, it’s a tile based Map system with no tile based collision detection past a very basic “is this point within a tile of this type?”… I though it was a bit ill thought out personally. There are a number of ways to code around it, but you’ll use us a bunch of your storage more than you should need to if that function was inbuilt. I would like to see, “does this sprite collide with this sprite/tile, at this (X,Y) position.) If we at least had that it would make the barrier of entry massively easier for the novice.

  [q]I’m pretty sure the target audience are those folks who did this on 8-bit and 16-bit machines 30 years ago. In fact the only thing that’s kept me from looking in to it (aside from available time) is that it’s Lua and not some sort of fantasy “assembly programmer’s dream CPU.”

  Lua is simple enough to learn in an afternoon. Really, that shouldn’t stop you.

  The target audience is both that, and the new generation of kids that desperately want to write games, but who need to start somewhere simple. That’s where Pico-8 falls down at the moment.
• 2017-01-05 2:25 pm

  signals

  Why? The spirit of the console is to encourage people to hack on games. But giving a large learning curve to get started is exactly the opposite.

  I guess I had always assumed that the PICO-8 wasn’t about playing games as much as it was about making games. There are those out there who perceive the limitations of old machines as a challenge or a puzzle to be solved, and enjoy working through those limitations. There are harsh limitations on the PICO-8 in order to recreate that feeling.

  Or at least that’s what I make of it.
• 2017-01-06 3:14 pm

  henderson101

  There are those out there who perceive the limitations of old machines as a challenge or a puzzle to be solved, and enjoy working through those limitations. There are harsh limitations on the PICO-8 in order to recreate that feeling. [/q]

  PICO-8 is confused. That’s the problem. On the one hand it wants to be restricted and quirky, but on the other hand it hands you sprites and tile maps for free, and the sound engine is bloody good fun to play with too. But here’s the thing, making it look really easy but adding so little to help with the actual code, that is where it falls down. Take the way you look at map tiles:

  local val = mget(p.x,p.y) –get the tile Id at that point

  local f = fget(val,flag) — check the flag (as you don’t always want to just hit a wall, the flag helps you work out what is actually solid)

  …except, that only gives you info for one SINGLE point!! The problem with the map and flags are that they are not intuitive at all.

  Your sprite is anything from a few pixels, to 8 x 8 (or bigger if you are rendering the player with multiple sprites..) So you then need to do something like a check for each edge of your hit box…. So imagine that was wrapped in to a function called “solid”:

  function collides(x,y,w,h,o)

  local mx0 = flr((x)/w)

  local mx1 = flr((x+(w – 1))/w)

  local my0 = flr((y)/h)

  local my1 = flr((y+(h – 1))/h)

  return solid(mx0,my0,o) or

  solid(mx0,my1,o) or

  solid(mx1,my1,o) or

  solid(mx1,my0,o)

  end

  And for everything else we have something like this:

  [q]

  function checkcollision(p, e)

  return p.x < e.x+8 and

  e.x < p.x+8 and

  p.y < e.y+8 and

  e.y < p.y+8

  end

  And that’s literally just some code I had lying around… like possibly the simplest way to do this kind of thing. What would be a lot nicer is if you could have a unique ID for each Sprite or Tile, then when there’s a collision you could get either an event “Collides(id1, id2)” which tells you what collided, or you could set flags on a sprite as well as a tile and then actually just have a function like “spritecollides(id, x, y, flag)”, which looks at the sprite and works out i the visible portion collided with a tile or sprite with that specific flag.

  That way, you can go on making you games with complicated logic, but kids have a chance of understanding the mechanics.
• 2017-01-06 6:55 pm

  Bill Shooter of Bul Platinum Prime

  But the disparity here is, it’s a tile based Map system with no tile based collision detection past a very basic “is this point within a tile of this type?”… I though it was a bit ill thought out personally. There are a number of ways to code around it, but you’ll use us a bunch of your storage more than you should need to if that function was inbuilt. I would like to see, “does this sprite collide with this sprite/tile, at this (X,Y) position.)

  I don’t know. Its cool for what it is. I’ve written that collision detection routine several times for tile based systems. Part of what makes it what it is, is that it has to be done. It requires more work, but allows for more opportunities to think about how to build basic low level things like that.

  However, despite that, I’m not a fan of the pico games I’ve played. Any suggestions from anyone on what a good one is?