I'm trying to write a tool that has text editing, and I find that the devkit keyboard doesn't return a lot of the special keys that it easily could.
You're returning a string, so there's no reason why it has to be just one character. So pressing the Home key could simply return the string "home". No need for special characters, escape sequences, etc., since these verbose names would all be distinct from any single regular typed character.
I'm mainly thinking of the standard navigation cluster: up, down, left, right, ins, del, home, end, pgup, pgdn.
It'd also be nice if there were a second stat() value that had a bitmask of the modifier keys that are currently pressed, if the host has them. Like, left/right shift, left/right alt/cmd, maybe left/right win/opt, altgr, maybe capslock. Not crucial, but definitely helpful. It'd be nice to be able to support things like ^Z for undo in my tool.
I say all this because one of the things I love about PICO-8 is working entirely within PICO-8, so it's nice to write tools that work inside of the platform, but the devkit functionality is a little limited in this department.
1 comment
You're just chillin' in your lawn chair, sipping a cold lemonade outside your sweet new trailer home when suddenly, HOLY CRAP! A wall of fire blasts out of nowhere! Can you escape this fiery blitz with your life? Run, flap, and flip your way to safety in this short and sweet platformer. You'll dodge spikes and walls and maybe even discover a couple secrets along your way. Good luck and don't end up as a BBQ!
This is my first time utilizing a collision system with floating point values. Let me know if you enjoyed this adventure! I sure loved making it!
6 comments
I'm learning to make hitbox collisions (instead of flags collisions).
Vertical collisions seem to work just fine but horizontals don't.
How can this be done?
Maybe hitbox collisions are just to complicated and shouldn't be used?
.
.
.
.
.
.
function _init()
pad_x=45
pad_y=45
pad_width=30
pad_height=30
pad_color=7
pad_speed=3
ball_x=80
ball_y=10
ball_radius=4
ball_color=8
ball_speed_x=2
ball_speed_y=2
end
function _update60()
btnprss=false
cls(1)
--ball movement
ball_x+=ball_speed_x
ball_y+=ball_speed_y
--ball-screen collision
if ball_x<0 or ball_x>128 then
ball_speed_x=-ball_speed_x
end
if ball_y<0 or ball_y>128 then
ball_speed_y=-ball_speed_y
end
--pad movement
if btn(0) then
btnprss=true
pad_speed=-5
end
if btn(1) then
btnprss=true
pad_speed=5
end
pad_x+=pad_speed
if btnprss==false then
pad_speed=pad_speed/2
end
if pad_x<1 or pad_x>126-pad_width then
pad_x=mid(1,pad_x,126-pad_width)
end
pad_color=7
if ball_box(pad_x,pad_y,pad_width,pad_height) then
pad_color=8
ball_speed_y=-ball_speed_y
end
end
function _draw()
rectfill(pad_x,pad_y,pad_x+pad_width,pad_y+pad_height,pad_color)
circfill(ball_x,ball_y,ball_radius,ball_color)
end
function ball_box(box_x,box_y,box_w,box_h)
--conditions where there are no collisions
if ball_y-ball_radius>box_y+box_h then
return false
end
if ball_y+ball_radius<box_y then
return false
end
if ball_x-ball_radius>box_x+box_w then
return false
end
if ball_x+ball_radius<box_x then
return false
end
return true
end
|
0 comments
This is a work in progress for a midterm. The basics are all there, but the goal, in the end, is to have a single player "snake" like mode, add in some power-ups, work on better hit detection collision when sprites are added, and general cleanup to look more like a SNES game than a basic Atari game.
0 comments
One of my favorite hobbies of late is trying to transcribe/approximate existing music into PICO-8's tiny tracker, so here is my attempt at "Castles of Cake" from my favorite kirby game, Kirby's Dream Course :D
Technically Interesting Note: I am doing some slightly sneaky swapping of SFX after the intro so I can use a couple of different SFX instruments that are only in the intro and not used in the rest of the song
6 comments
New version fixes random spawns; mooks will only spawn outside the screen bounds now.
New version (2/6/19) adds levels and backgrounds (shoddy, not-final-product backgrounds)
New version (2/25/19) adds directional sprites to the player and mooks, as well as heart pickups. Additionally, minions will now fire ammo from a distance instead of their previous behavior of standing there... menacingly.
New version (2/25/19) adds a score tracker to end screen and makes minion fire actually, well, visible.
New version (3/2/19) implements a boss at 9000 score, but be careful - he's not exactly balanced.
- Also changes text color in areas for readability.
1 comment
Just wanted to cross-post this here -- Voxajam is happening all through February, and to announce it @Eiyeron and I put together over a dozen little demos to help pico-8 devs wade into the waters of Voxatron.
These all ignore Voxatron's built-in actor/physics systems, and work by overriding _init, _update, and _draw to create games in a fashion that isn't all that different from making a pico-8 title.
If you already have Voxatron (or are a pico-8 owner looking to take advantage of the $5 'upgrade' to it -- https://www.lexaloffle.com/purchase.php?product=add_voxatron ), I think this could definitely help bridge the gap and let you hit the ground running.
Announcement cart is here:
https://www.lexaloffle.com/bbs/?tid=32932
1 comment
Despite experience programming for over a decade, this is my first real completed game, ever. I did it basically just as a learning project before tackling something bigger in PICO-8. It's a very simple top-down shooter involving what looks to be robots. Enemies spawn faster and faster, and have random health. The gimmick (and thing that made implementation easier) is that you can only shoot while moving unless you're pushing against a rock. See how high of a score you can get! I got to 47. If an enemy touches you its game over.
3 comments
