Ulexes [Lexaloffle Blog Feed]

Bat Patrol

Mon, 06 Oct 2025 14:54:59 UTC

bat_patrol_v1

by Ulexes

[Click to Play]

I have worked on this on and off (mostly off) for years, but I finally have a version that's ready for release! Here's Bat Patrol, a limited-movement SHMUP that encourages good aim and punishes reckless play. I hope you enjoy it!

Special thanks to the following people for helping me bring this project to completion:

merwok
bob1996w
Icegoat9
echoinacave
RotundBun

Changelog

9 Oct. 2025: Fixed a bug that made Bombers ignore the top sector if it was the only living one. Also removed some debug code that I left in the updated version.

Bat Patrol Instruction Manual

Bat Patrol and this instruction manual are distributed under a CC4 BY-NC-SA license.

Story
Controls
Game Modes
How to Play
Tips and Tricks
Bestiary

Story

Alert! Alert! Sensors have detected a huge cloud of dangerous space bats in the vicinity – and our station is headed right for it! It's too late to correct our course and take evasive action. We have no choice but to pass through the swarm.

Based on our positioning, the bats are poised to fly through the station's vulnerable residential and life support sectors. With no weapons stationed there, we've had to scramble to deploy a pair of magnetic gun turrets discovered in the cargo bay. Unfortunately, they were meant for terrestrial use, and can inflict serious structural damage if used recklessly.

Your mission is to operate your turret, guard against the oncoming bats, and protect the space station's precious sectors. But be careful where you aim! Misplaced gunfire risks demolishing the sectors you're supposed to save. You don't want to pose a greater hazard to the space station than the bats!

Controls

Bat Patrol can be operated using a PICO-8 controller, keyboard, or joypad.

PICO-8 Controls

Action	Button
Move Turret	UP / DOWN
Aim Cannon	LEFT / RIGHT
Fire	(X)
Center Cannon	(O)
Select Game Mode	LEFT / RIGHT
Confirm Mode Selection	(X)
Restart (After Game End)	(O)

Keyboard Controls

Action	Player 1 (Red)	Player 2 (Blue)
Move Turret	UP / DOWN	E / D
Aim Cannon	LEFT / RIGHT	S / F
Fire	X, V, M	Q, A
Center Cannon	Z, C, N	W, SHIFT (L), TAB
Select Game Mode	LEFT / RIGHT	N/A
Confirm Mode Selection	X, V, M	N/A
Restart (After Game End)	Z, C, N	W, SHIFT (L), TAB

Joypad Controls

The game detects and automatically maps any connected joypads.
Controllers are assigned to players in roughly the order they are detected upon startup. There is no mechanism for assigning specific controllers to specific players.
If a controller is connected while the game is running, the game program must be restarted before the controller can be used.

Game Modes

Bat Patrol features three game modes:

Solo: Defend the space station all by yourself against the bat onslaught.
Team: Bring along a companion and fend off the bat swarm together.
Versus: Try to destroy your opponent (or their sectors) while protecting your side and yourself against the space bats.

How to Play

Bat Patrol is designed to be easy to play, but challenging to master. The game adheres to the following mechanics and rules.

Game Mechanics

Endure the bat swarm: The space bats attack in waves of varying size, composition, and difficulty. There are 45 waves in total. A wave ends when all the bats in it have passed through the station or been destroyed.
Aim your cannon for precision shots: You can change the trajectory your bullets follow by adjusting the aim of your cannon. To restore your cannon to its central position, press the "Center Cannon" button.
Protect your sectors: You must protect the seven sectors behind your turret. A single bullet will break a sector. If all seven of your turrets are destroyed, it's game over.
Preserve your turret: If your turret is struck by a bullet or bat, it will be destroyed. If you have any turrets in reserve (represented by the icons under your side of the display bar on the top of the screen), you can continue playing. If your turret is destroyed when you have no turrets in reserve, it's game over.
All bullets are destructible: Every bullet fired, whether belonging to a player or an enemy, can be destroyed by shooting it. Take advantage of this principle to eliminate bullets that threaten you or your sectors.
Friendly fire is always on: Bullets do not distinguish between friend and enemy! Player bullets can destroy turrets and sectors alike.
Fight a boss every five waves: Every fifth wave represents a boss battle. If the boss is defeated, all players gain one life (up to a maximum of five), and one of their damaged sectors is repaired at random.

Special Rules

Each of Bat Patrol's three modes features rule variations that change how gameplay is approached.

Solo Mode: The opposite wall reflects any bullets that strike it. Use caution when firing your cannon, as your missed shots might come back to you!
Team Mode: The survival of both players and their sectors is essential. If either player loses all their lives or sectors, then it's game over.
Versus Mode: The game continues until one player destroys all of their opponent's sectors or depletes all of their remaining lives. If the players manage to complete all of the game's 45 waves without defeating one another, the waves will begin again from the first.

Tips and Tricks

It not always necessary to defeat all the bats in an ordinary wave. Prioritize eliminating bullets first.
Your bullets move far more quickly than your turret. It is often more advantageous to aim and fire from afar than to steer your turret toward the enemy.
Every boss has a distinct pattern for its movements and attacks. Study their behaviors, and strategize accordingly.
Depending on the state of the game, lives and sectors do not always have equal value. Learn when each one should be prioritized.
In Solo Mode, the reflective wall can be used to your advantage. Try banking your shots off the wall to hit enemies when aiming at them directly would be too slow.
If you are trailing your opponent in Versus Mode, it is sometimes opportune to speed through boss battles in order to replenish your lives or sectors. Try to determine whether it's better to push forward or stall the game in the current wave.

Bestiary

Enemies

Space bats come in a wide variety of shapes and sizes, and each kind has their own distinct behaviors. Learn how they move and attack to counter them effectively!

Name

Image

Description

Grunt

	[8x8]

The Grunt is the most common species of space bat. They move erratically to the left and right as they make their gradual way down the screen, firing at random.

Swooper

	[8x8]

The acrobatic Swooper flies in circles as it passes. It rarely fires, but has been known to smash into turrets.

Loiterer

	[8x8]

Loiterers tend to linger in one place for a while before darting down the screen. Use their pauses to your advantage.

Diver

	[8x8]

Divers plunge through the space station at incredible speeds, and sometimes fire straight shots as they pass.

Bomber

	[8x8]

Bombers do not fire, but slam themselves into individual sectors to destroy them. If they stop in front of one of your sectors, be sure to shoot them down right away!

Assassin

	[8x8]

The Assassin tracks your movements and fires a volley of quick shots to destroy your turret. Keep your trigger finger at the ready to repel their attacks!

Crawler

	[8x8]

The slow-moving Crawler inches along the walls. They won't harm your sectors, but will rip apart your turret at a touch. Don't let them take you by surprise.

Bosses

Every five waves, one of these big baddies arrives to menace the space station. Unlike ordinary bats, they won't pass by of their own accord. You must defeat them to advance.

Name

Image

Description

Vasa

	[16x16]

Stay alert when this bat stops moving. It might be preparing to pounce!

Rhone

	[16x16]

This squat, speedy bat will pause now and then to shoot at you from multiple angles.

Iredale

	[16x16]

It soars up and down the screen, firing slow-moving shots with each pass.

Virsatis

	[16x16]

This bat spirals about the screen and launches a burst of shots when it reaches the center. Be careful to avoid colliding with it.

Oslyabya

	[16x16]

It barely moves, but snipes your turret from afar with fast-moving bullets.

Donapaz

	[16x16]

This bat doesn't shoot, but will smash your turret with its big body and bladed wings.

Endurance

	[8x8]

Don't let its small size and familiar shape fool you. It is much tougher than it looks.

Erebus & Terror

	[16x16]

	[16x16]

These twin bats twirl around one another, attacking aggressively as they fly.

Queen Anne's Revenge

???

Nobody knows how this bat behaves, for none who have faced it lived to tell the tale. Good luck!

Orb Pondering Simulator

Fri, 05 Jul 2024 19:25:35 UTC

orb_pondering_simulator_v1

by Ulexes

[Click to Play]

Orb Pondering Simulator is a silly little art experiment I made for a game jam. Read more about the motivations on the game's Itch page.

Press UP and DOWN to cycle through orb palettes. LEFT and RIGHT cycle through the available backgrounds. X pauses or resumes the background animations.

Happy pondering!

Help request: Creating an infinite height ruler

Thu, 20 Jun 2024 23:30:48 UTC

I'm working on a game that notes how high players climb. Right now I'm trying to put together a "ruler" that stays on the left side of the screen and scrolls with the player, letting them know at a glance how far they've traveled. Every 50 pixels, the ruler has a slightly longer line, and a printed numerical value indicating the corresponding height. Here's what I have so far.

fozadasohu

by Ulexes

[Click to Play]

Right now, the ruler is powered by a for loop in the function draw_elevation(), which means that it has a definite start and end. Could anyone recommend a method for making the ruler extend in both directions indefinitely (without crashing PICO-8)? My efforts to try while and repeat loops have failed. (Bonus points for making the 0 line start at the bottom or center of the screen!)

Here is the code as it stands, since the site's cart dropdowns aren't working right now:

--height measure

function _init()
 camx=0
 camy=0
 screen_height=128 
end

function _update()
 if btn(⬆️) then
  camy-=1
 end
 if btn(⬇️) then
  camy+=1
 end
end

function _draw()
 cls(12)
 camera(camx,camy)
 draw_elevation() 
 --debug: cam values
 print("camx: "..camx,85,camy+3,8)
 print("camy: "..camy,85,camy+10,8)
end

function draw_elevation()
 --to do: have 0 line at screen bottom (or at center with negative heights below)

 --to do: make the ruler extend indefinitely so that any height is recorded/printed

 --these values are kind of arbitrary at the moment
 for i=150,-screen_height,-10 do
  --draw measuring lines
  line(0,i,3,i,2)
  --longer line for every multiple of 50
  if i%50==0 then
   line(4,i,7,i,2)
   --label for longer line
   print(-i,10,i-2,2)
  end
 end
end

Making a pendulum with an increasing swing

Fri, 14 Jun 2024 03:05:17 UTC

The Question

Hello everyone,

I am ludicrously close to finishing the engine for my game, but some physics equations have me stuck. Here is what I'm trying to achieve:

The players are effectively nodes that can switch between being pendulum bobs and fulcrums. One can be anchored to serve as a fulcrum while the other swings. If both are anchored, neither moves. If both try to un-anchor themselves, they fall.
In order to let the players navigate the playfield, I want the swing of a pendulum bob to increase bit by bit. (This will let players climb the playfield by swinging upward instead of just descending.)
Once a bob makes a full loop around the fulcrum, I want it to continue in a circle at a more-or-less consistent speed.

With the help of this math writeup, I managed to assemble a simplified set of physics variables and equations that do an okay job of simulating momentum and creating a non-degrading swing (i.e., the swing distance never shrinks due to friction). But I haven't figured out how to make the desired increase in swing distance happen. I'm sure it's a single value or sign that I haven't identified.

I suspect I need to do something to increment the value of p.a in the function move_player(p), but I am not sure how to approach it -- adding a value, multiplying by a value, etc.

Could someone better at physics/math please offer suggestions?

Thank you for any and all pointers!

The annotated code is below. It's 200 lines in total, but the relevant parts are the first ~90.

zafebaraza

by Ulexes

[Click to Play]

The Code

function _init()

 screen_center=63

 player_size=5
 tether_length=25
 g=20 --gravity/momentum. more=stronger pull. negative values flip the swing's arc.
 k=-(g/tether_length)
 default_v=0 --negative=swing left, positive=swing right
 default_dt=0.01 --period/speed of swing (screwy if >=1)

 dt_cap=0.1
 dt_boost=dt_cap/(g*10)

 red={
  controller=0,
  button=5,
  control_mode="toggle", --"hold" or "toggle"
  x=screen_center-tether_length/2,
  y=screen_center,
  colors={2,8,2},
  r=player_size,
  a=0,
  v=default_v,
  dt=default_dt,
  glyph=nil,
  anchor=nil
  }

 blue={
  controller=0,
  button=4,
  control_mode="toggle",
  x=screen_center+tether_length/2,
  y=screen_center,
  colors={1,12,1},
  r=player_size,
  a=0,
  v=default_v,
  dt=default_dt,
  glyph=nil,
  anchor=nil
  }

 red.partner=blue
 blue.partner=red

 players={red,blue}

 for p in all(players) do
  set_glyph(p)
 end

end
-->8
--updates

function _update()
 for p in all(players) do
  control_player(p)
  check_angle(p)
  move_player(p)
 end
end

function move_player(p)

 if p.anchor==false and p.partner.anchor==true then

  p.v+=k*cos(p.a)*p.dt

  --to do: steadily increase swing length
  --to do: circular movement at consistent speed after looping
  --what i really want to do is boost dt and angle at the end of each swing
  p.a+=p.v*p.dt

  --dt should start small, increase, and cap around 0.1
  p.dt+=dt_boost
  if p.dt>dt_cap then
   p.dt=dt_cap
  end

  p.x=p.partner.x+tether_length*cos(p.a)
  p.y=p.partner.y+tether_length*sin(p.a)

 end

 if p.anchor==false and p.partner.anchor==false then
  --to-do: let swinging players finish their swing
  p.y+=g/5
 end

end

--everything below this line works, and is included in case anyone wants to paste the full code into a cart

function control_player(p)
 if p.control_mode=="toggle" then
  if p.anchor==nil then
   p.anchor=true
  end
  if btnp(p.button,p.controller) then
   if not out_of_bounds(p) then
    p.anchor=not p.anchor
    p.dt=default_dt
    p.v=default_v
   end
  end
  if p.anchor==true then
   p.colors[3]=7
  else
   p.colors[3]=p.colors[1]
  end
 elseif p.control_mode=="hold" then
  if p.anchor==nil then
   p.anchor=false
  end 
  if btn(p.button,p.controller) then
   if not out_of_bounds(p) then
    p.anchor=true
   end
  else
   p.anchor=false
  end
  if p.anchor==true then
   p.dt=default_dt
   p.v=default_v
   p.colors[3]=7
  elseif p.anchor==false then
   p.colors[3]=p.colors[1]
  end
 end
end

function check_angle(p)
 local angle=atan2(p.x-p.partner.x,p.y-p.partner.y)
 p.a=angle
end

function out_of_bounds(p)
 if p.x>128 or p.x<0 or p.y>128 or p.y<0 then
  return true
 end
end

function set_glyph(p)
 local glyphs={"⬅️","➡️","⬆️","⬇️","🅾️","❎"}
 p.glyph=glyphs[p.button+1]
end
-->8
--draws

function _draw()
 cls()
 draw_debug(red,1)
 draw_debug(blue,85)
 draw_tether(red,blue)
 for p in all(players) do
  draw_player(p)
 end
end

function draw_player(p)
 circfill(p.x,p.y,p.r,p.colors[1])
 circfill(p.x,p.y,p.r-1,p.colors[2])
 circfill(p.x,p.y,p.r-3,p.colors[3])
 print(p.glyph,p.x-3,p.y-2,p.colors[2])
 for i=1,2 do
  pset(p.x+1+i,p.y-5+i,7)
 end
end

function draw_tether(p1,p2)
 line(p1.x,p1.y,p2.x,p2.y,10)
end

function draw_debug(p,spot)
 local bottom=123
 local col=p.colors[2]
 if p.anchor==true then
  print("anchored",spot,bottom-21,col)
 else
  print("unanchored",spot,bottom-21,col)
 end
 print("v: "..p.v,spot,bottom-14,col)
 print("a: "..p.a,spot,bottom-7,col)
 print("dt: "..p.dt,spot,bottom,col)
end

Help: Circle math for angled projectiles

Fri, 02 Sep 2022 22:31:59 UTC

I am working on a little shooter where players can move up and down a fixed track, and can aim a cannon to shoot a projectile at an angle. Ideally, this angle can run parallel to the track, but shouldn't intersect it.

I thought I had the math down, but I am running into an issue where the players' projectiles are able to intersect the track. It appears that, even though I constrain the angles that player cannons can point and fire, players seem to be able to extend and shoot a tiny bit beyond it. Strangely, a simple debug test that prints the angles indicates that they should be parallel to the track in these situations.

Angle constraint formulas:

--player 1 is on the left side, and aims right
	if p1.a<270 and p1.a>100 then
	 p1.a=270
	end
	if p1.a>90 and p1.a<270 then
	 p1.a=90
	end
--player 2 is on the right side, and aims left
	if p2.a<90 then
	 p2.a=90
	end
	if p2.a>270 then
	 p2.a=270
	end

Cannon aiming formulas:

	if btn(⬅️, p.c) then
	 p.a+=target_speed
	 p.tx=p.x+radius*cos(p.a/360)
	 p.ty=p.y+radius*sin(p.a/360)
	 if p.a>360 then
	  p.a=0
	 end
	end
	if btn(➡️, p.c) then
	 p.a-=target_speed
	 p.tx=p.x+radius*cos(p.a/360)
	 p.ty=p.y+radius*sin(p.a/360)
	 if p.a<0 then
	  p.a=360
	 end
	end

Have I found a bug with how PICO-8 does its circle math? Or have I erred somewhere? (It's probably the latter, but I can't see what I'm doing wrong.)

ponezabaka

by Ulexes

[Click to Play]

Snail Maker

Sat, 30 Jul 2022 18:44:23 UTC

snailmaker

by Ulexes

[Click to Play]

A silly little toy I threw together. Click your mouse to generate a bunch of randomly-colored snails that flee at varying speeds to the left and right of the screen.

Robosumo!

Sun, 14 Feb 2021 01:37:38 UTC

robosumo_1

by Ulexes

[Click to Play]

I'm pleased to unveil my finished weekend project: Robosumo! Inspired by this entertaining video a friend showed me this week.

Special thanks to:

freds72, for helping me in the forums.
huulong, for an invaluable sprite rotation function.
NuSan, for a number of useful physics functions in Combo Pool.
Daisyfield's archive of public domain Japanese music.

Introduction

It's sumo, but with robots! Ram your opponent and send them flying from the dohyō. Speed and finesse are your only weapons – but take care they're not turned against you.

Features

Old-school competitive play: Local multiplayer for up to four players.
Configurable game length: Play one round, or one-hundred!
Single-player practice mode: Hone your skills in a stress-free sandbox.

Scoring

1-Player: Score is not kept in 1-Player mode.
2-Player: Gain a point whenever the other player falls out of the ring.
3- or 4-Player: Gain a point if you landed the last hit on the player who fell out of the ring. (It is possible for a round to conclude with no points scored.)

Controls

Main Menu

UP/DOWN: Move cursor
LEFT/RIGHT: Toggle selected option
Z/X: Begin game

Game Screen

Player 1

UP: Move robot forward
DOWN: Move robot backward
LEFT/RIGHT: Rotate robot
Z/X: Restart game (practice mode only)

Player 2

E: Move robot forward
D: Move robot backward
S/F: Rotate robot

Players 3 and 4

Note: Joysticks or gamepads are required for 3- or 4-player games, as Pico-8 does not have native keyboard mappings for third- and fourth-player controllers.

UP: Move robot forward
DOWN: Move robot backward
LEFT/RIGHT: Rotate robot

Other Notes

Downloadable binaries for offline play are available for free on Robosumo's itch page.

EDITS: Removed list formatting from "Special Thanks" section, because it prevented the hyperlinks from displaying. Added a "Scoring" section.

Syntax help: Comparing a table to itself

Fri, 12 Feb 2021 20:43:02 UTC

Hi everyone,

I'm working on a little robotic sumo game for a friend after seeing an IRL video about it. I decided to include a 4-player mode, because I like multiplayer games.

I want players to score only if they're the ones who knocked the player out of the arena when play is halted (basically like in Super Smash Bros), but I'm having trouble recording that information.

Here's the relevant code:

--main game loop
for p in all(players) do
 check_hit(p)
 --other stuff
end

function check_hit(p)
 for o in all(players) do
  if circlehit(p,o) and  --Basic collision function.
   p.col~=o.col then     --This line is meant to keep players from hitting themselves.
    p.lasthit=o.col      --Here, "col" is the player's color, and "lasthit" is who last hit them.
  end                    --In another function, I award points to the player whose color
 end                     --matches the "lasthit" value of the ko'd player.
end

I need to prevent players from "hitting" themselves, because otherwise they would score when they're knocked from the ring. (If I remove the "p.col~=o.col" line, that's exactly what happens.)

But right now, scores don't register properly because of a bug with check_hit(p). My testing tells me there's something wrong with this function alone -- it's not recording a "lasthit" value as currently written. I'm not sure whether the problem is the "p.col~=o.col" comparison, or running a for loop within a for loop, or what.

Does anyone have a sense of what I've done wrong, or suggestions for doing this more efficiently? Thank you in advance for any and all advice.

Syntax help: Accessing a table within a table

Thu, 10 Dec 2020 22:59:48 UTC

Hi everyone!

I am making a little game where you scare off crows to protect your vegetable garden:

I am trying to make the crows pick a vegetable to target when they spawn. I have a function that will make them chase down a point by entering its X and Y value. My problem is that I don't know how to extract the vegetables' X and Y values because of how I've set things up.

Every vegetable is decided at random at the game's outset, and stored inside another table, like so:

[note: dif is an integer, adding more vegetables at higher difficulties]

function setup()
 for i=1,dif do 
  add(vegetables, {
   x=originx+(rnd(40)+10)*cos(rnd(360)/360),
   y=originy+(rnd(40)+10)*sin(rnd(360)/360),
   w=6,
   h=6,
   [more variables and stuff you don't need to care about...]
  })
 end
end

My question is, how would I go about accessing the X and Y values for these? I have been trying something like this...

vegselect=flr(rnd(dif))+1
vegx=vegetables[vegselect][1]
vegy=vegetables[vegselect][2]

...but it has failed as a nil value every time.

Any advice is appreciated. Thanks for considering my problem!

EDIT: I classified the post incorrectly. Apologies!

Star Shield (Demo)

Mon, 30 Mar 2020 04:23:43 UTC

It's a long way from finished, but I now have something approximating a playable demo of a 1- to 4-player cart I've been working on.

Here is Star Shield for your... Uh... Enjoyment? Or whatever you want to do with it.

Premise

Defend your base against the stars' relentless assault by activating your left or right shield at the correct moment. Rack up a high score in single player, or be the last base standing in multiplayer!

Stars speed up after several deflections, and new stars appear at high point thresholds. Extra lives are awarded to particularly beleaguered players.

Controls

LEFT or (o): Activate left shield.
RIGHT or (x): Activate right shield.

For proper orientation, imagine yourself seated behind your station, looking into the circle.

Player 1: Red (South)
Player 2: Blue (North)
Player 3: Yellow (West)
Player 4: Green (East)

starshield_demo_v05

by Ulexes

[Click to Play]

To-Do List

There is a lot that I'm still working on. Namely:

Moving stars along lines at intersections, rather than teleporting.
- In an ideal world, the stars randomly decide whether to hop on a line when they pass them, and then randomly decide to travel counter/clockwise at the end of the line. I'm really struggling to come up with ways to go from circular movement to linear movement and back... The stars always fly off into space, never to be seen again!
- The travel to the center circle is necessary for 3- and 4-player games, so that stars aren't trapped between two players.
Better shield activation windows.
- BTNP allows an indefinite shield (defeating the point of the game), but BTN keeps it up way too briefly.
Displaying "empty" life markers when lives are lost.
Nicer title and menu screen.
Music and sounds.
Optimized maps and starting positions for 3-player games.
Much cleaner code!

I will update this thread as I progress.

Thanks for reading/playing!

Seeking table arrangement suggestions

Sat, 21 Mar 2020 18:53:06 UTC

Hi everybody!

So, for a jam I'm far too unskilled to have considered, I'm putting together a little game where up to four players can pilot tiny ships and defend a fort. The ships can move about, and (eventually) shoot in the direction of a target that can be rotated around the ship by holding a button. It looks like this in practice:

(Enemies and animations forthcoming.)

Right now, I am attempting to optimize the code, because the player inputs eat a LOT of tokens in their current form. I currently have four different sets of inputs, one for each player, and each also moves a target that is specified as its own object (target1 with .x and .y, target2 with .x and .y, etc.). This is obviously no good, given the immense redundancies.

I think one could probably code a generic input function by making each target a property of its ship, using something like this:

function input(p)
  if btn(0,p.c) then p.x=p.x-1 p.targetx=p.targetx-1         --repositions player and target
   if p.x<0 then p.x=0 end                                   --prevents leaving the screen
   if p.targetx<0 then p.targetx=p.x+radius*cos(p.a/360) end
  end
  if btn(1,p.c) then p.x=p.x+1 p.targetx=p.targetx+1         --repositions player and target
   if p.x>120 then p.x=120 end                               --prevents leaving the screen
   if p.targetx>120 then p.targetx=p.x+radius*cos(p.a/360) end
  end
  if btn(2,p.c) then p.y=p.y-1 p.targety=p.targety-1         --repositions player and target
   if p.y<16 then p.y=16 end                                 --prevents moving into sandbar at top of screen
  end
  if btn(3,p.c) then p.y=p.y+1 p.targety=p.targety+1         --repositions player and target
   if p.y>120 then p.y=120 end                               --prevents leaving the screen
   if p.targety>120+radius then p.targety=p.y+radius*sin(p.a/360) end
  end
  if btn(4,p.c) then end                                     --fires bullet (to be implemented)
  if btn(5,p.c) then p.a+=target_speed                       --rotates target
   p.targetx=p.x+radius*cos(p.a/360)
   p.targety=p.y+radius*sin(p.a/360)
   if p.a>360 then p.a=0                                     --resets target angle if needed
   elseif p.a<0 then p.a=360
   end
  end
end

Basically, as long as we specify the controller (c) associated with each player (p), we can use one function to dictate all player inputs. So, for each player, we have to put together a simple table of attributes.

And here is where my problem occurs: those stupid little targets.

Here's what I have tried to use for the first player's attribute table:

 p1={
   exist=false,
   dead=false,
   idle=true,
   x=50,
   y=50,
   a=180,
   idlesprite=3,
   movesprite=7,
   w=8,
   h=8,
   score=0,
   lives=3,
   c=0,
   targetx=p1.x+radius*cos(p1.a/360),  --PICO-8 doesn't like this line.
   targety=p1.y+radius*sin(p1.a/360),  --Or this one.
   targetsprite=16
   }

It seems PICO-8 doesn't accept putting p1.x, p1.y, and p1.a in those trig functions for p1.targetx and p1.targety. It raises an error, saying that they indicate an attempt to index a nil value. I guess I could just throw in a raw number for them? But I kind of need those variables, I think, since the location of the player's target must depend on the location of the player's ship.

TL;DR: A table isn't working like my noob brain would expect, and I have three questions:

Why are p1.x, p1.y, and p1.a nil values, if I already provide values for them in the table?
How else might I define targetx and targety, such that they remain properties of p1?
If the method I've proposed is stupid, what might you suggest as a workaround?

Arguments won't pass?

Thu, 19 Mar 2020 23:20:47 UTC

I'm having an issue where it seems like I absolutely cannot pass an argument to a function, no matter what I do.

For starters, I am using doc_robs' famous hitbox function:

  function player_hit(x1,y1,w1,h1,
                      x2,y2,w2,h2)
   local hit=false
   local xs=w1/2+w2/2
   local ys=h1/2+h2/2
   local xd=abs((x1+(w1/2))-(x2+(w2/2)))
   local yd=abs((y1+(h1/2))-(y2+(h2/2)))
   if xd<xs and yd<ys then
    hit=true
   end
   return hit
  end

So far, so good, right? Then I pass the following arguments along to it from another function:

  if player_hit(p1.x,p1.y,pw,ph,star1.x,star1.y,sw,sh) then
  --stuff happens in here
  end

All of the values in the preceding if statement are defined at _init(). The values pw, ph, sw, and sh are all 2, defined as global variables. The p1 and star1 values come from tables.

But every time I run my program, this error occurs:

RUNTIME ERROR
   local xs=w1/2+w2/2
Attempt to perform arithmetic on local 'w1' (a nil value)

Now, I can't find the reason why w1 registers as nil. The value pw (2) should be subbed in for it, since it's being provided in the function call.

Strangely, the same error occurs even if I manually type "2" in place of pw in the player_hit() call.

Best way to mimic NES bass?

Thu, 19 Mar 2020 18:22:40 UTC

If you grew up with the NES, you remember that their basslines had a certain "snappiness" to them (for lack of a better word). Here are two of my favorite examples:

DAT BASS!

Anyway, I've been trying to mimic that type of bass as closely as I can in my PICO-8 carts, but I haven't quite hit the mark yet.

Does anyone have instrument/effect suggestions for achieving this kind of sound?

Can we compare coordinate values? (Syntax error help)

Wed, 18 Mar 2020 01:11:33 UTC

This is probably a ludicrously simple thing that I never learned, so please forgive me in advance.

I'm trying to write a function that checks whether a thing (star1) moving in a circle intersects with any of four lines (four_p_lineX) that connect to the circle. The best way I can think to do this is to make the function check whether the X and Y coordinates of star1 match the X and Y coordinates of any of the line endpoints.

The thing is, PICO-8 doesn't like what I've written:

 function check_direction()
  local s1switch=flr(rnd(1))   --You wonderful forum people can ignore this part.
  if (star1.x,star1.y)==(four_p_line1.x1,four_p_line1.y1) or
                        (four_p_line1.x2,four_p_line1.y2) or
                        (four_p_line2.x1,four_p_line2.y1) or
                        (four_p_line2.x2,four_p_line2.y2) or
                        (four_p_line3.x1,four_p_line3.y1) or
                        (four_p_line3.x2,four_p_line3.y2) or
                        (four_p_line4.x1,four_p_line4.y1) or
                        (four_p_line4.x2,four_p_line4.y2) then
   if s1switch==1 then         --Ignore this, too.
    star1.line=not(star1.line)
   end
  end
 end

The above code produces the following syntax error:

SYNTAX ERROR LINE 187 (TAB 2)
 if (star1.x,star1.y)==(four_p_line1.x1,four_p_line1.y1) or
')' expected near ','

I can't really figure out what the error is telling me. Is it as simple as me forgetting some punctuation, or can I not make the comparison I'm trying to make?

Compensating for sprite corners in movement

Mon, 16 Mar 2020 01:54:40 UTC

Hi everyone!

I'm hard at work on a 1-4 player cart, but I've run into a snag when it comes to moving a sprite around in a circle.

I more or less have the movement down (thanks to tonechild), but it looks like the wrong part of the sprite is tracing the circle I want:

(Please excuse the incomplete graphics and such.)

It appears that the upper-left corner of the sprite is tracing the circle here, when I'd really prefer something closer to the center of the sprite. Is there a way to make this happen? Or, if not, is there a workaround any of you might recommend?

Here are the relevant points of my (messy) code. You'll notice the star is able to "trace" the track because it uses the same variables I used to draw the circle.

 --variables
 scene="logo"
 last=time()
 game_over=false   --determines that a solo player has lost
 player_win=false  --determines that a player won in multiplayer
 radius1=55  --determines outer circle size
 radius2=25  --determines inner circle size
 originx=63  --center of screen/track
 originy=63  --center of screen/track
 flashcol=11

 --star 1 data
 star1={}
  star1.exist=false
  star1.angle=13
  star1.x=originx+radius1*cos(star1.angle/360)
  star1.y=originy+radius1*sin(star1.angle/360)
  star1.speed=3
  star1.sprite=56

--moves stars along track
 function move_stars()
  --moves star 1
   star1.angle+=star1.speed
   star1.x=originx+radius1*cos(star1.angle/360)
   star1.y=originy+radius1*sin(star1.angle/360)
   if star1.angle>360 then star1.angle=0
   elseif star1.angle<0 then star1.angle=360
   end
 end

 --draws track that stars follow
 function draw_track()
  circ(originx,originy,radius1,2)
  circ(originx,originy,radius2,2)
 end

Thank you for reading, and for considering the problem! I promise I'll be a better forum participant in the near future, when I know a bit more about this whole Lua thing.

Bastard Squash

Fri, 13 Mar 2020 15:33:52 UTC

With many thanks to packbat for helping me in the forum, I can finally say my first real cart is complete!

I give you: BASTARD SQUASH.

bastard_squash_v1

by Ulexes

[Click to Play]

I don't have any training in programming or math, so this isn't as impressive as most debut carts. Still, we all have to start somewhere! I hope you find something to enjoy in it. Also, don't mind the unused sound samples, and general code inelegance...

Description

Have you ever thought your game of squash needed to hate you a little more? Then do I have a cart for you!

Your paddle shrinks with each successive hit. Past certain point thresholds, it also begins to creep toward the ceiling. Extra lives are granted every 300 points, because I love you, even if my game doesn't.

Controls

LEFT/RIGHT: Move the paddle
X (x): Hold to increase paddle speed
Z (o): Hold to decrease paddle speed

(EDIT: Added link to packbat's user profile for better crediting.)

Granting extra lives

Fri, 13 Mar 2020 04:00:37 UTC

I'm looking for some advice on how to grant the player extra lives after the score crosses a certain point interval.

I've checked a few carts that do this, but I'm not able to make sense of the functions they use, and I was wondering whether anybody had a simple method handy.

At the moment, I only have a brute-force method. My cart uses two straightforward variables: "lives" counts the player's lives, and "score" counts the score. Let's say I want to give the player an extra life for every 300 points they score. Right now, I only have this:

function gainlife()
 if score=300 then
  lives+=1
 elseif score=600 then
  lives+=1
 elseif score=900 then
  lives+=1
 end
end

It kinda works (assuming the player loses interest in the game after around 1,000 points). But I figure there HAS to be a way to capture the interval in a neater function. Unfortunately, my stupid brain can't figure it out!

Thank you for whatever wisdom you have to share.

New Learning Project: Red Planet Mission

Wed, 11 Mar 2020 22:03:08 UTC

Once again using Dylan Bennett's Game Development with PICO-8 as the backbone, I've rolled out a new project based on his "Lander" recipe. Presenting Red Planet Mission:

yasodahiba

by Ulexes

[Click to Play]

I've tweaked the sprites, added a start screen (with art!), and managed to put together menu and gameplay themes.

I couldn't figure out how to randomize the star background each time you start up the game, but I'll keep trying.

It's quite exciting to have put all the features of PICO-8 to use in a cart! The next step is to do something using my own code next time.

Unused measures in SFX/music entries

Wed, 11 Mar 2020 04:19:50 UTC

Hi everybody,

I'm having some difficulty figuring out how to solve a problem with how PICO-8 handles music, and I was wondering whether any of you out there could help me.

Let's say I have a few SFX files that I intend to collate into a music composition for my game, like in the following image:

Notice that there are a few unused measures for this clip. Let's assume that I have several other clips that are similarly structured.

When I try to string these together in the music editor, the system plays all those empty measures like they are rests. But what I would really like to happen is for the music to "jump" directly from the end of the clip to the beginning of the next one.

Is there a way to make this happen?

Thank you for any and all input!

First Game Attempt: Bat Cave

Mon, 09 Mar 2020 03:57:04 UTC

I sampled PICO-8 for the first time this weekend. Being a rank novice at programming, I have little idea of what I'm doing. Luckily, given the abundance of PICO-8 resources here and elsewhere, I'm learning quickly!

Here is my first attempt at a game: a barely modified version of Cave Diver from Dylan Bennett's Game Development with PICO-8. I give you: Bat Cave!

Bat Cave

by Ulexes

[Click to Play]

It leaves a bit to be desired as a "game," but in terms of newbie accomplishments, I'm pretty proud of figuring out how to insert a title screen. That will certainly come in handy later.

Here's to producing better games in the future!

Ulexes [Lexaloffle Blog Feed]

Bat Patrol

Changelog

Bat Patrol Instruction Manual

Contents

Story

Controls

PICO-8 Controls

Keyboard Controls

Joypad Controls

Game Modes

How to Play

Game Mechanics

Special Rules

Tips and Tricks

Bestiary

Enemies

Bosses

Orb Pondering Simulator

Help request: Creating an infinite height ruler

Making a pendulum with an increasing swing

The Question

The Code

Help: Circle math for angled projectiles

Snail Maker

Robosumo!

Introduction

Features

Scoring

Controls

Main Menu

Game Screen

Player 1

Player 2

Players 3 and 4

Other Notes

Syntax help: Comparing a table to itself

Syntax help: Accessing a table within a table

Star Shield (Demo)

Premise

Controls

To-Do List

Seeking table arrangement suggestions

Arguments won't pass?

Best way to mimic NES bass?

Can we compare coordinate values? (Syntax error help)

Compensating for sprite corners in movement

Bastard Squash

Description

Controls

Granting extra lives

New Learning Project: Red Planet Mission

Unused measures in SFX/music entries

First Game Attempt: Bat Cave