Linked by Thom Holwerda on Tue 3rd Jan 2017 21:17 UTC
General Development

I'm going to use PICO-8, which its creator, Joseph "Zep" White, calls a 'fantasy console', but really it's like an indie-fied emulator of the computers I grew up with, like the BBC B. When you start it, you're presented with a 128 by 128 pixel display glitching into life, this little do-do-do-do! jingle, and a command prompt.

Everything you need to make games is right there: a mini Lua code editor, sprite and map editors, and sound and music editors. It's reactive, instant to test to see if things work, and generally delightful. And the stuff people have made in it is extraordinary. Little short-form games: colourful, fun, immediate, varied. Type SPLORE into the command prompt and this little browser for games posted to the PICO-8 forum comes up. Since no game, including its graphics, is bigger than a 65K text file, you're playing them pretty much instantly. It's lovely.

This is just the first article in a series.

Order by: Score:
PocketC.H.I.P.
by Feneric on Tue 3rd Jan 2017 22:34 UTC
Feneric
Member since:
2006-01-16

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

Reply Score: 3

Pico-8
by henderson101 on Wed 4th Jan 2017 11:46 UTC
henderson101
Member since:
2006-05-30

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.

Reply Score: 2

RE: Pico-8
by signals on Wed 4th Jan 2017 13:49 UTC in reply to "Pico-8"
signals Member since:
2005-07-08

I'd love to see the authors add in more helpers to make the code more compact.


I think that would violate the spirit of the project.

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."

Reply Score: 2

RE[2]: Pico-8
by henderson101 on Wed 4th Jan 2017 15:40 UTC in reply to "RE: Pico-8"
henderson101 Member since:
2006-05-30

I think that would violate the spirit of the project.


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.

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.

Reply Score: 2

RE[3]: Pico-8
by signals on Thu 5th Jan 2017 14:25 UTC in reply to "RE[2]: Pico-8"
signals Member since:
2005-07-08


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.

Reply Score: 2

RE[4]: Pico-8
by henderson101 on Fri 6th Jan 2017 15:14 UTC in reply to "RE[3]: Pico-8"
henderson101 Member since:
2006-05-30

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.


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:


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.

Reply Score: 2

RE[3]: Pico-8
by Bill Shooter of Bul on Fri 6th Jan 2017 18:55 UTC in reply to "RE[2]: Pico-8"
Bill Shooter of Bul Member since:
2006-07-14

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?

Reply Score: 2