I ran into an odd bug with printing glyphs. I think what's happening is that if it detects a button glyph being used on a line with a btn() or btnp() function, it replaces all instances of the button glyphs on that line with the appropriate button number. This is a problem if you do something like the following two lines of code (obviously using actual glyphs instead of these unicode chars):
if (btn(⬅️)) print("⬅️")
print("❎",20,20,btn(⬅️) and 7 or 5)
|
The following gif shows the code for the cart above:
2 comments
Controls
Z to start. Arrows move the helicopter. Z (held) deploys ropes to save survivors (if any are near enough).
Commentary
Yet another one of those games where I finally have a good idea in the last few hours of the month, but this one came together so well I can't be mad.
I am on a pretty good streak of games that don't involve killing/shooting (a gentle challenge I set myself). This one puts you in the active role of a rescuer - albeit, one who never has to recover dead people, as the real volunteers/coast guard often find themselves doing. In this world everyone is save-able, if you're quick.
Watch your fuel and do passes around the darkened sea in order to find the eye-catching life rings. Then use your trusty ropes (hold Z) to pull people up.
itch.io page: here.
0 comments
This is Pico-8 on the GamePad Digital GPD-WIN palmtop gaming computer. I won't give this a detailed review because there are better sources of info on this machine, and it's no surprise that it can run Pico-8. But since I posted pics of RaspiBoy I thought it'd be fun to show it off in comparison.
GPD-WIN is a bit famous for being surprisingly good at what it does, but if you haven't seen it before: 5.5 inch touch screen, Intel Atom processor, teeny keyboard, built-in game controls (including shoulder buttons), and it runs Windows 10. Install the Windows version of Pico-8 and not only can you play games, but you can make games as well. The keyboard is implausibly small, but it compares favorably to a PocketChip. The whole thing folds up to the size of a 3DS.
I made a half-hearted attempt at setting up the game controls with Pico-8. You can choose between three controller modes using a hardware switch, including a mouse-and-keyboard emulation mode for regular Windowing. I ended up using this mode and Pico-8's keyconfig to get a reasonable result with the D-pad and buttons. I bet another mode and proper SDL controller set-up would also work. Mouse-and-key mode is also plausible for the editors: left stick to move the mouse, left shoulder button to left-click, etc. Touchscreen mousing is surprisingly good in general, but I personally would prefer the stick for drawing. There is one (and only one) USB-A port for external peripherals. It also supports Bluetooth.
The GPD-WIN sells for ~$400 USD, so a bit pricier than a RaspPi set-up (or any handheld game machine subsidized through licensing). It's also a plausible option (only option?) for playing Steam games in a handheld-like, which appears to be its chief purpose. I don't think I'd use it for apps unless I were desperate, or could use its mini-HDMI out and peripherals.
GPD-WIN has a subreddit of devoted fans, and the subreddit has a FAQ.
11 comments
This is the RaspiBoy handheld console kit running Pico-8. Inside, it's a Raspberry Pi Zero connected to a TFT display, a LiPo rechargeable battery, a small speaker, a custom controller board, and a built-in full-size SNES-style controller including shoulder buttons on the back. The custom board provides two USB-A ports for data, a microUSB port strictly for charging, mini-HDMI video out, a headphone jack, a volume wheel for the speaker, and buttons for adjusting the display. RaspiBoy ships as a solderless kit that does not include the RaspPi Zero.
The two big ideas here are the full-size SNES-like controller grip and the injection molded case. Injection molding and silicone membrane pushbuttons do more to recreate the mass-market handhelds than any 3D-printed equivalent can. The controller size is comfortable and familiar. Overall, there are a lot of good ideas in the RaspiBoy that we haven't seen yet in this increasingly populated category of small-run manufacturing of Raspberry Pi-based handheld game consoles. The general design ticks a lot of boxes in my ideal version of this concept.
Unfortunately, there are some significant failures in the details. The large grip comes at the expense of a wide frame around the TFT screen. As shown in the picture, Pico-8 by default doesn't fill the frame, and the low resolution makes even Pico-8's chunky typeface difficult to read. (I have not yet experimented with options and config to fix this. The -width and -height command-line arguments may come in handy.) A flaw common to RaspPi-based handhelds is the need to formally shut down the operating system before turning it off, or risk corrupting the filesystem. (This could be fixed with custom software and a "soft" power button, but it'd be a project that I haven't seen anyone attempt yet.)
While the silicone membrane buttons have a familiar feel, they're a pain to assemble as part of the kit. Plastic buttons sit atop the membrane, and the membrane makes contact with simple copper pads on the circuit board. Getting these to line up while you push the two sides of the case together is difficult, and it took me multiple tries to get it to fit together correctly. Even when fully assembled, the buttons are too unreliable for gaming performance. I had far better luck sticking a prefab USB controller into one of the ports than I did with the built-in controller.
RaspiBoy doesn't use any custom software: it's just RetroPie in a common RaspPi configuration, and you install it yourself. So I'm not sure how to explain that Pico-8 misbehaves and crashes after a few minutes of play. I'm tentatively inclined to blame the RaspiBoy, the RaspPi Zero, or possibly the way the controller board connects to the Zero using pogo pins pressed up against the test pads. Needless to say, it's a deal breaker if I can't actually use it to play games reliably. I doubt I'll have the time or patience to troubleshoot this properly.
The basic RaspiBoy kit sells for 75 euros (~$90 USD) from http://www.8bcraft.com/.
4 comments
Experience the thrill of being a Dad behind the wheel in the 70s!
Swerve wildly! Drink beers! Yell at your kids! Don't learn from your mistakes!
Controls
Z: Accelerate
X: Brake
Arrows steer and do ~other things~
There is an ending, it's not just a high score thing.
This is my entry into the 2017 GitHub Game Off.
GitHub repo https://github.com/Alligator/game-off-throwback
11 comments
A mixture of two genres – a Roguelike and a Tetris-style game – based on a prototype I made with a friend (@ollie_read) in 8 hours during a "Crafts and Gin" Game Jam back in 2012.
• 10 levels
• Procedural generation
• Musicality!
• Old-school gameplay
• But actually winnable though
Arrow keys to move/rotate/drop blocks, X + arrows to move rogue and fight monsters.
Full instructions can be found in game. I hope you enjoy it.
Thoughts
This version of the game took a long time to make – more than 40 coding sessions during evenings/weekends of July-November 2017. I had the core game fully working within a few sessions, and the rest has literally been set dressing and "polish" (it still looks like programmer art!). Presentation is quite pompous in places, e.g. a full menu system; this is simply because I wanted to make the game as "finished" as possible (I teach game dev so I want to set a good example).
In order to fit the standard 10x20 grid (plus 4 invisible rows for spawning blocks) on the screen, I had to use 6x6 pixel sprites for each cell rather than the easier option of a map of 8x8 pixel cells. Making clear pixel art in 6x6 tiles is hard, but I’m quite happy with the monster designs and animations – I think they have personality.
This was my first Pico-8 / Lua game so wasn’t sure how restrictive the CPU or token/char count would be in practice. I was worried it would struggle with drawing so many sprites but seems okay? (stat() was showing about 10% CPU at worst). Token budget was more than enough too, but I only realised this once I had carefully implemented most of the critical content – so in general the code is unnecessarily dense. I was disappointed at first that it would easily fit into the restrictions, but then I noticed that I’d gone well over the limit for the compressed .p8.png format, which added a nice little challenge towards the end. Had two runs at crunching - the first involved me hard-coding a load of values and adding short function references, but this meant that I would have to retest the entire game thoroughly to check I hadn't broken anything, so instead I rolled back and just minimised the comments :)
A warning for beginners: Tetris clones might seem like an ideal "basic" project to work on, but I found there are lots of unforeseeable logic problems/exceptions, and quite a few subtle UX tricks that you have to do to make the game "feel" right (some I've done, some I haven't). So beware, I guess.
I’ve got it so the music is in sync with the GFX, but I have had to implement procedural music in order to do this. Originally I had a song that I played at a set tempo and synced up with the monsters "dancing", but if the Pico-8 loses focus (e.g. to desktop) the audio continues to play while the GFX freezes, so the music goes out of sync. Also noticed that pausing and unpausing the game seemed to cause the Pico-8 to throw the sync out by 2 ticks. In the end I created separate instruments as SFX and made my own "song" by triggering them on certain ticks. It’s no accident that the game follows a 12-bar blues pattern; finally my GCSE music lessons paid off.
With so much RNG it was hard to balance, especially while preserving the luck-factor of a roguelike. This meant that I had to complete several runs each time I changed something, to allow for fluctuations in RNG. The longer I've worked on it, the more I've lost all objective sense of how difficult it is, but it is definitely winnable. I hope you guys enjoy it anyway; do let me know how you get on.
Neil
25 comments
A cute game about 3 girls playing with a spiritboard and getting more than they bargained for! Started out as a cute spiritboard thing like an 8 ball but became a visual novel without me realizing it.
If you want the executables there is a itch.io page it also contains the full code with comments which I sadly had to strip for the bbs release.
The question menu is controlled with x to go to the top of the menu and c to select. Enter opens the start menu.
To use the paste option on the question menu you must first paste into the game before it can access your clipboard.
5 comments
This is my second experiment with PICO-8, this time making a flexible and customizable particle emitter system. In this demo I've pre-made several different emitters that you can view by pressing (left) or (right).
Particles are only rendered as lines, but there are a lot of options to control how they look and behave. It took a while to figure out how to handle colliding with the edges of the screen such that it was accurate no matter how fast the particles were traveling or how long their trails were. Here's just the particle update function to see what's going on:
function particle:update()
if self.age < self.lifespan then
if self.jitter > 0 then
local curr_jitter = rnd(self.jitter)-self.jitter/2
local curr_angle = atan2(self.dx,self.dy)
local curr_mag = sqrt(self.dx^2+self.dy^2)
self.dx = cos(curr_angle+curr_jitter)*curr_mag
self.dy = sin(curr_angle+curr_jitter)*curr_mag
end
self.dx = (self.dx+self.xgrav)*self.drag
self.dy = (self.dy+self.ygrav)*self.drag
local next_x = self.x+self.dx
local next_y = self.y+self.dy
local line_pts = {{self.x, self.y}}
line_pts.segments = 0
while self.collide do
-- left collision
if next_x < 0 and btwn(self.y+((next_y-self.y)*self.x/(self.x-next_x)),0,screen) then
self.y += (next_y-self.y)*self.x/(self.x-next_x)
self.x = 0
self.dx *= -self.bounce
next_x *= -self.bounce
-- right collision
elseif next_x > screen and btwn(self.y+((next_y-self.y)*(screen-self.x)/(next_x-self.x)),0,screen) then
self.y += (next_y-self.y)*(screen-self.x)/(next_x-self.x)
self.x = screen
self.dx *= -self.bounce
next_x = screen-(next_x-screen)*self.bounce
-- top collision
elseif next_y < 0 and btwn(self.x+((next_x-self.x)*self.y/(self.y-next_y)),0,screen) then
self.x += (next_x-self.x)*self.y/(self.y-next_y)
self.y = 0
self.dy *= -self.bounce
next_y *= -self.bounce
-- bottom collision
elseif next_y > screen and btwn(self.x+((next_x-self.x)*(screen-self.y)/(next_y-self.y)),0,screen) then
self.x += (next_x-self.x)*(screen-self.y)/(next_y-self.y)
self.y = screen
self.dy *= -self.bounce
next_y = screen-(next_y-screen)*self.bounce
else -- no collision
break
end
add(line_pts, {self.x, self.y})
line_pts.segments += 1
end
self.x = next_x
self.y = next_y
add(line_pts, {self.x, self.y})
line_pts.segments += 1
add(self.lines, line_pts)
elseif self.maxlength >= 1 then
self.maxlength -= 1
end
-- trim the lines
while #self.lines > self.maxlength do
del(self.lines, self.lines[1])
end
-- get older
self.age += 1
end
|
1 comment
-- 12/1/17 --
Version 1.666 !
A new item and a new #3CJam cart have been added!
Sorry it's not much of a puzzle to unlock this one :/ If I'd had space, I would have done something neater, BUT.. there are also now TWO Spiritboard-inspired masks to find :)
(also button prompts have been fixed)
-- 11/29/17 --
EDIT: Bugfix release has replaced the original version:
-Corrects some issues with cart loading
-Music is less random (now only cycles when using a door)
-tweaked a few puzzles
-note: Do NOT mess with haunted hardware -- who KNOWS what could happen?
-note: Also do NOT mess with controller 2. I mean, who KNOWS what could happen??
-note: Do NOT experiment with items -- who KNOWS what could happen?
-note: Do NOT, I repeat do NOT look for odd-numbered houses. They probably don't even exist anywhere. It isn't healthy to imagine such things. Try to stay grounded instead.
The #3CJam 2017 hub cart is finally complete!
This isn't the witch game that castpixel and I started on as a 3cjam entry. It's.. something else.
"What is it, then?" you ask??
Well.. You'll have to explore and find out for yourself. :)
If you get stuck, feel free to post here in the thread or twitter.
Manual:
11 comments
Try the following code, in which a negative number is repeatedly multiplied by a fractional value:
k=-1 for i=1,33 do k*=0.5 end print(k.." or "..tostr(k,true)) |
As of 0.1.11d, you'll end up with "-0 or 0xFFFF.FFFF" as your output, or negative zero.
There are arguments for the concept of negative zero, particularly when you're working with floating-point numbers—but I'm not sure it makes sense within the context of Pico-8's fixed-point values. Unlike unsigned zero, negative zero is unstable in a fixed-point representation. If you multiply 1000 by 0, you get zero. But if you multiply 1000 by negative zero (0xFFFF.FFFF), you get -0.0153.
In other words, unless you handle negative zero as a special case (e.g. compare to an epsilon value), it's possible you'll introduce numeric drift.
It also leads to other weird behavior. Try this:
k=-1 for i=1,33 do k=shr(k,1) end print(k.." or "..tostr(k,true)) |
The output will also be negative zero, which makes very little sense to me. Bit-shifting past the range of the number should yield 0; if I were using k as a bit field, e.g., I wouldn't necessarily want a shift-right to mean "multiply by 1/2."
SHORTER: it seems like negative zero in Pico-8 is either a bug or just a bad idea. But maybe someone can explain why it should be there?
8 comments
made a 40 mins game cause why not
- you move with arrows
- and move in small steps by holding X + arrows
- get diamonds, highscore, post here!1
LOL
0 comments
Hello,
Sorry, it's probably been covered before, but I'm trying to get my latest PICO-8 thing (done in 0.1.11D) to work on a Pocket CHIP I borrowed. As you might imagine, it doesn't work/won't load.
What's the easiest way to get the Pocket CHIP up to date? (this is someone who has never really fiddled with one and have just borrowed one from a colleague)
Cheers,
Roy
1 comment
Landing Simulator 2017
Fly for the high score based on how fast you complete the levels using the arrow keys to maneuver through space and time.
My first PICO-8 project, based on the second tutorial from the "Game Development for PICO-8"-zine by MBoffin. A small and rough expansion to get my hands dirty. Sorry about the lack of music, I limited this project to focus on programming patterns and a few visual effects.
My high score: https://twitter.com/r_pdx/status/935305070157094912
3 comments
Me learning how to program :)
CHANGELOG
Version 0.9.1 :
- Fixed crash upon restart
Version 0.9 :
- Snake grows
- Aligned every object to a virtual grid. Now "collision" code is much more simple.
PAST VERSIONS
0.9 :
Alpha :
0 comments
The game launched properly under Windows 7 on the same PC, but fails to launch or create a config file in windows 10.
codo_init
platform: Windows
codo_system_init
codo_reset_timer
codo_gui_init
codo_keys_init
codo_text_init
codo_video_init
codo_mouse_init
codo_joystick_init
codo_joystick_init
found 0 joystick(s)
ok
ok
codo_set_screen 0 0 32 b
retrieving desktop resolution: 1280 800
EDIT: Dell Latitude E6400
0 comments
