Nite Fite

Cart File | Forum Post |

	More cartridges by damiansommer

More Cartridges [View All]

 

Nite Fite

by damiansommer

Cart #20373 | 2016-05-09 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

6

Hey everyone! This weekend, at the Toronto Game Jam, I made a small 0-player game named Nite Fite. It was my first time working in Pico-8 and I had a blast.

Since this is a 0-player game, you don't actually have any controls. The fighters go automatically, and when they die, they pull a property from the fighter that killed them, and randomize another property. This results in a kind of weird shifting metagame that's oddly captivating to watch.

I loooooved working in Pico-8 and will definitely try to put some more stuff out in the future.

Edit: the old version had a horrible invisible bug that completely compromised the inheritance system. This version should work fine now.

Blocksy! 1.0

by Eduardolicious

Cart #20331 | 2016-05-08 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

2

(edit: naturally the first time I uploaded this I forgot to take a screenshot. lol)

My first game! It's pretty bad! But ok for the 24 hours or so I took introducing myself to Pico-8

About ~10% or so of this I'd say is probably wholesale lifted from the first tutorial for Squashy over at Picozine, since that was my starting point to all this. Added some more objects/collisions and turned it into a game sorta thing

Features:

• Z/X to adjust paddle speed
• multiple return angles
• scoring (10pts for a successful volley, 25pts for hitting the block)
• high score tracking (saved via cartdata())
• annoying sounds, by me
• working game over/restart screen
• poor logic
• poorer comments

There's the occasional (literal) corner case where the ball doesnt interact with the block correctly, but I think I've gotten it as good as I can get it with the horrible way I logic'd it all out. I've already learned/determined a better method for bounding boxes so whatever I make next WON'T be this bad (hopefully).

Enjoy! Hopefully someone gets 20 seconds of fun out of it (or learns something from it

[ Continue Reading.. ]

Foodkins, food collector

by morningtoast

Cart #20318 | 2016-05-08 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

7

Controls

• Arrows move you around
• X will start a new level

Development
This is my first game of sorts. I made it for my preschooler and as a way for me to learn some P8 basics. There's not much to it. Presents release food, then collect all the food until you get them all. There's no end, per se, the collection goal just keeps going up. If this ends up being something she enjoys, I'll add things to it but if nothing else this is a great reference for my future projects.

And thanks to everyone here on the forums...I learned a lot about some the nuances of Lua and it came in handy.

I used the animation function from here:
https://www.lexaloffle.com/bbs/?tid=3117

I copied food sprites from here:
https://www.reddit.com/r/pico8/comments/3jhmni/spritesheets_and_tools_for_the_pico8_palette/

I couldn't find the thread where I got the collision function but thank you!

Once nice experience I had with this program was the refactoring. My first dive into this game was just hacking through new commands and learning. Once I got that to a workable state, I refactored it in about 2 hours to be pretty nicely laid out, IMHO. Still learning where to gain efficiencies but hey, it's a start.

[tool] Organ 0.1.1

by miss_mouse

Cart #20313 | 2016-05-08 | Code ▽ | Embed ▽ | No License

8

Organ is a simple sfx organizer.

When I make music with the pico8 tracker, I usually end up with an unreadable mess of samples that have nothing in common.

This utility lets you switch sfx indexes and update the song data accordingly.
You can either specify a filename in the code (still waiting for a usable ls()), or paste the song data of another cart manually.

The data is saved on the editor itself (even when a filename is specified). To save it to your music cart, you'll need to edit it manually (I'll make a better UI in the future).

I may or may not extend this to make a music compression utility :T

RUNBOY

by runescape_fan_32

Cart #20308 | 2016-05-08 | Code ▽ | Embed ▽ | No License

13

uses verlet integration i ported to pico-8

So, I just recently heard about PICO-8 and fell in love with the concept, especially since a lot of my game-related projects recently end up crumbling under their own weight. Thankfully, there is no way to do that to yourself with the constraints of the Pico, so I hope to finish a few small games for it to get my groove back :).

Mine! 1.0.1

by krajzeg

Cart #20306 | 2016-05-08 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

128

This is my first Pico project. It's just a Minesweeper clone - I wanted to start with a known quantity just to get a feel for Lua and the API. I figured that in the unlikely event that the Pico becomes a hit handheld console, at least all those Minesweeper fans will have an implementation ready to go.

Then I found about the search function in splore and realized that somebody already made one :). Well, I guess there is two to choose from now :).

I accidentally uploaded an empty spritesheet instead of the cartridge for a quick test thing, as 20297. Is there a way to delete it so it doesn't gum up splore and stuff?

As I'm learning P8 and getting back into a low-level state of mind, I'm finding that (like anything) you need a plan to get a project done, but even more so in this type of environment...and that means you probably have notes, charts, doodles, spreadsheets...whatever...

I'm just wondering what physical artifacts folks create when building a game. And maybe, if you're keen to it, take a quick photo and post it.

I'm not asking anyone to give away their secret sauce or blueprints for their "next big thing" but just something to give insight into the creative and development process you go through...especially if you've made what most people would consider a "polished" game.

I just finished my first program but I did most my planning/doodling "in code" as I worked through what I wanted to do. So now I'm looking back to refactor and thinking about how to best plan things out. All in all, I'm just looking for inspiration.

Going back to basics like this is both wonderful and frustrating...but in a good way :) I haven't done it like this in decades but something about it just feels good.

CRASH!!, the sequel to CRASH!

by lorandbehold

Cart #20262 | 2016-05-07 | Code ▽ | Embed ▽ | No License

20

CRASH THE CAR!! BY ALL MEANS! CRASH IT!!! AGAIN!!

The arrow keys control the car! That is all the controls!!!

This is the sequel to CRASH!.

The music was made by the talented Pizza!!!

Have fun, show end-screens and tell me what you think!!!

If you like the game, please do consider supporting it on itch.io!! : )

Since the Ouya just runs Android, wondering if there's any way to nicely get Pico-8 running on it?

I haven't tried yet but not sure I'd even know how to go about it.

I am one of the unfortunate souls that bought an Ouya, but now thinking I could just use it as my router to the television for P8 games since it's already got the outputs, controllers, etc.

GatherKid - Learning P8 basics #1

by morningtoast

Cart #20212 | 2016-05-06 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

I just started playing around with Pico-8 and while I've been programming for a very long time, I've never done so at such a low level so I'm finding P8 a great challenge that is wonderful escape from my daily style. That being said, I'm looking for code review-style feedback on my first little learning game.

I'm making a simple game for my preschooler daughter so it's not complicate but it's requiring me to cover all the basics for making any game - collisions, maps, sprites, movement, etc. This first pass focuses on movement and object/sprite collision. I watched the "popular" light cycle tutorial as well as read through the Fanzines and took all that cobble something together. So thanks to all of those people! It's be a treat learning something new.

Right now the game is just moving the character around and collecting food items. Run into a present and food pops out. Run into the food and they disappear (collected). That's it.

Again, I'm just looking for feedback on how it's written, probably mostly around the architecture and places where I'm wasting space. The game is working as I expected, so there are no bugs, per se...just looking for efficiencies.

I am planning on adding more graphics and stats that keep track of what's been collected. There will be other screens but that's the next lesson.

I appreciate any feedback, thanks!

pickups={}
player={}
box={}

-- ///////////////////////

function _init()
	cls()
	createplayer()
	createbox()
end

function _update()
	foreach(pickups,function(o)
		if (o.wild and collide(o,player)) then o.wild=false end
	end)

	if (collide(box,player) and box.closed) then
		box.closed=false
		for x=1,4 do add(pickups, createpickup()) end
		createbox()
	end

	player.update()

	if (btnp(5)) then createbox() end
end

function _draw()
	cls()
    foreach(pickups, function(o) o.draw()  end)

    player.draw()
    box.draw()
end

-- ///////////////////////

function createbox()
    box.closed=true
    box.x=flr(rnd(110)+10)
    box.y=flr(rnd(110)+10)
    box.hitbox={x=0, y=0, w=8, h=8}

    box.draw = function()
       if(box.closed) then spr(1,box.x,box.y) end
    end
end

function createplayer()
    player.x=60
    player.y=60
    player.spr={3,2}
    player.cel=2
	player.dir=1
    player.hitbox={x=1, y=0, w=6, h=8}

    player.update=function()
        -- movement controls
		if (btn(0)) then move(player,4) end
		if (btn(1)) then move(player,2) end
		if (btn(2)) then move(player,1) end
		if (btn(3)) then move(player,3) end		
    end

    player.draw=function()

        spr(player.spr[player.cel],player.x,player.y)
    end
end

function move(obj, dir)

obj.dir = dir
	if (obj.dir == 1) then obj.y = obj.y-1 end
	if (obj.dir == 2) then 
		obj.x = obj.x+1 
		player.flip = false
	end
	if (obj.dir == 3) then obj.y = obj.y+1 end
	if (obj.dir == 4) then 
		obj.x = obj.x-1 
		player.flip = true
	end

	if (obj.x <= 1) then obj.x = 1 end
	if (obj.y <= 3) then obj.y = 3 end
	if (obj.y >= (125-8)) then obj.y = (125-8) end
	if (obj.x >= (125-6)) then obj.x = (125-6) end

	--p.spr = p.spr + 1
	--if (p.spr > 2) then p.spr = 1 end
	if player.cel==1 then player.cel=2 else player.cel=1 end

end

createpickup=function()
    local obj={}
    obj.x=flr(rnd(110)+10)
    obj.y=flr(rnd(110)+10)
    obj.spr=flr(rnd(5)) + 64
    obj.hitbox={x=0, y=0, w=8, h=8}
    obj.wild=true

    obj.draw=function()
        if (obj.wild) then spr(obj.spr, obj.x, obj.y) end  
    end

    return obj
end

function collide(obj, other)
    if
        other.x+other.hitbox.x+other.hitbox.w > obj.x+obj.hitbox.x and 
        other.y+other.hitbox.y+other.hitbox.h > obj.y+obj.hitbox.y and
        other.x+other.hitbox.x < obj.x+obj.hitbox.x+obj.hitbox.w and
        other.y+other.hitbox.y < obj.y+obj.hitbox.y+obj.hitbox.h 
    then
        return true
    end
end

I'm working up the basics for a small tile puzzle game where players navigate through a maze filling the path behind them so that they can only move on each tile once. so a trail that will then have some collision so it can't be crossed

I'm having trouble working out how to leave a trail of sprites. I have a grid set up, and a player sprite to move as follows:

function _init()
x = 0 
y = 64
end

function _update()
 if (btnp(0)) 
  then x=x-8 
 end

 if (btnp(1)) 
  then x=x+8 
 end

 if (btnp(2)) 
  then y=y-8 
 end

 if (btnp(3)) 
  then y=y+8
 end
end

function _draw()
	rectfill(0,0,127,127,7)
 spr(1,x,y)
end

I've tried having something in draw but this ended with the designated sprite following the player around and I tried adding something in the update function with the keystrokes but this b0rked it.

It seems to be something beyond what I kno so even if someone can point me in the right direction of something to read up on or code to review that would be much appreciated.

analog clock example

by audiohijack

Cart #20176 | 2016-05-04 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

1

Just an example of an analog clock you are welcome to use in any project.

Will work in a realtime fashion, like the demo. Or could be passed a static hour/minute and work as a nice background prop in a game. Obviously you could style things up a bit better.

The basic code (see cart for full detail, though):

clock_size=10 --radius of clock
clock_color=12 --blue
hr_hand_color=10 --yellow
min_hand_color=7 --white

-- draw_clock(minute, hour, origin x, origin y, radius)
-- ex: `draw_clock(45,3,50,50,10)` would draw a clock at 50,50 with a 
--    radius of 10 pixels and the hands set accordingly
function draw_clock(m,h,x,y,r)
  -- min hand 1 px smaller than the clock radius
  local mh_len=(r-1)*1.0
  -- hr hand 2 px smaller than the clock radius
  local hh_len=(r-3)*1.0

  m_x,m_y=clock_hand_position(m,x,y,mh_len)
  -- multiply the hour value by 5 for hand position
  h_x,h_y=clock_hand_position(h*5,x,y,hh_len)

  -- draw the outline of the clock
  circ(x,y,r,clock_color)

  -- draw the minute hand
  line(x,y,m_x,m_y,min_hand_color)

  -- draw the hour hand
  line(x,y,h_x,h_y,hr_hand_color)
end

-- clock_hand_position(tick, origin x, origin y, multiplier for hand length)
function clock_hand_position(t,o_x,o_y,m)
  -- rusty trig ahead. beware.
  t-=15
  t=t%60 -- handle 60 tick factors
  t=60-t
  -- determine x,y from cos/sin
  local x=cos(t/60.0)
  local y=sin(t/60.0)
  -- multiply the x & y by `m`
  x*=m
  y*=m
  -- offset from originating coords
  x+=o_x
  y+=o_y
  return x,y
end

Hi!

I'm looking very much forward to getting my PocketCHIP hardware, with PICO8 built-in .. and one of the things I'll be doing with the PocketCHIP is using it as the basis of a MIDI processor system.

So I was wondering - if we get PICO8 on PocketCHIP, would it be possible to request a feature for a new version of PICO8 in the future: MIDI I/O support?

This would be awesome! :)