Anybody know any Lua? You might remember Red Alert, the little shmup I’m developing for the PICO-8 fantasy console? Well, I’m getting close to actually having it in a playable state but I’m currently stuck with this one bug I can’t quite fix. You see, I built in this boss enemy that uses a laser beam and something is off with the collision detection for it. I am checking whether this beam intersects with a hitbox on the ship and it works most of the time, but there are edge cases with false positives. Here’s an example where the algorithm thinks the beam intersects with my ship:

The numbers in the screenshot are the top left and bottom right X/Y coordinates of the ship and the origin and end points (X/Y) of the laser beam. I am trying to check if the line of the beam touches the lines of the 2x2 pixel hitbox on the ship sprite. Here’s the relevant collision detection check:

local hitbox={}
hitbox.x=ship_x+2
hitbox.y=ship_y+2
hitbox.colw=2
hitbox.colh=2
if phcol(myen.phorx,myen.phory,myen.phposx,myen.phposy,hitbox) and myen.pht>0 then

function phcol(phx1,phy1,phx2,phy2,obj)
 if linecol(phx1,phy1,phx2,phy2,obj.x,obj.y,obj.x,obj.x+obj.colw) then return true end
 if linecol(phx1,phy1,phx2,phy2,obj.x+obj.colw,obj.y,obj.x+obj.colw,obj.y+obj.colh) then return true end
 if linecol(phx1,phy1,phx2,phy2,obj.x,obj.y,obj.x+obj.colw,obj.y) then return true end
 if linecol(phx1,phy1,phx2,phy2,obj.x,obj.y+obj.colh,obj.x+obj.colw,obj.y+obj.colh) then return true end
 return false
end

function linecol(x1,y1,x2,y2,x3,y3,x4,y4)
 ua=((x4-x3)*(y1-y3)-(y4-y3)*(x1-x3))/((y4-y3)*(x2-x1)-(x4-x3)*(y2-y1))
 ub=((x2-x1)*(y1-y3)- (y2-y1)*(x1-x3))/((y4-y3)*(x2-x1)-(x4-x3)*(y2-y1))
 if ua>=0 and ua<=1 and ub>=0 and ub<=1 then return true end
 return false
end

It works in most cases, but just not in some edge cases like that screenshot. If you have any pointers for me about what is going wrong or how I can fix it, please don’t hesitate to contact me! If you want to see the full code of the game, you can find it here. The relevant code starts in line 281 of the game cartridge file.

Work on the shmup continues. Enemies shoot to kill now.

My little shmup is coming along! I did a lot of improvements to it over the last few days: Dynamic enemy waves, enemy attack patterns, several quality-of-life tweaks. It’s almost a game now. My next task is to implement enemy shooting…

I updated the code of my PICO-8 clock to make it so that the clock and stopwatch displays refresh at the same time. This was a request from Jonathan M.H. and it brings the version number up to 0.02.

In other news, I am now also hosting a web version of the clock here on the website. You can also use it on mobile phones!

I’ve gradually continued work on my tiny soulsborne roguelike hack & slash game Dark Embers. I’ve previously described the idea here. I now have a a basic game engine going with player animations, a particle system and a way to spawn and despawn game objects like campfires. I’ve also started to implement enemy spawning. Next up is basic pathfinding for the enemies and then collision detection, before I turn to animating the enemies and writing a basic combat AI for them.

Today I learned that the creator of PICO-8 is working on another fantasy video game console called Picotron that is releasing in March. Unlike PICO-8, which is an 8-bit fantasy console modelled after third generation video game consoles (like the NES), Picotron is a 16-bit console modelled after the fourth generation (like the SNES). It can run PICO-8 games and its Lua syntax is largely backwards compatible, but it has a lot more features like 64 colours, an 480 x 270 pixel (widescreen) display and – and this is pretty important – no size limit for cartridges. It also includes an operating system written in Lua that can be modified. And you can code your own apps for it. And all of this runs on the web!

→ Picotron FAQ

Although Picotron is conceptually similar to PICO-8 — an imaginary machine that you can make things for with built-in tools — it aims to be a more practical and flexible development environment. The two main differences are in specifications (larger display and cartridge capacity), and the way that built-in tools are implemented.

Unlike PICO-8 and Voxatron, all of the design tools in Picotron are written in Lua and are editable from inside the machine itself. Even things like the file browser, code editor and the terminal are implemented in userland. Custom tools can be created from scratch that run in fullscreen workspaces alongside the bundled editors. These additions and the subsequent shift in focus of the machine give Picotron the title of ‘Workstation’ rather than ‘Console’. Instead of ‘Plug in a keyboard to get a devkit!’ It feels more like: ‘Unplug the keyboard to get a console!'

Holy shit this is exciting!

Work’s been pretty stressful lately and one of the way’s I’ve been coping with that is to take some time out of my day to do some PICO-8 game development. I’ve had a number of game ideas lately, one of which I have written about on this blog. But I’ve now actually had a new game idea that came to me over the holidays while staying offline in a cabin in Sweden. It’s a mashup of the Half Sword demo and Dark Souls, mixed with a healthy dose of roguelike ideas, rendered within PICO-8’s tiny 8-bit dimensions.

The idea is to make an endless roguelike game where you fight enemies with a sword and collect their embers (a kind of soul-like essence). When you die, you lose all embers you’ve collected since your last rest at a campfire. So it doesn’t have permadeath, since you always load in at the last campfire, but the enemies get spawned in prodecurally, based on your ember score. It doesn’t have a world per se. It’s just a dark, mysterious place — much like the Half Sword demo — which enables me to concentrate most of the limited PICO-8 resources on having interesting enemies. One big goal of the game is to make the combat very smooth and pixel-perfect, taking inspirations from early shmups. As fas as I know, nobody has done something like this, which is kind of exciting to me.

It’s also pretty interesting that I’ve been able to re-use a lot of code from Tinyhold and an earlier unfinished prototype. I guess that’s a factor of PICO-8 forcing its restrictions on the developer, so you tend to have to solve similar problems again and again, even in games that look very different from each other. As it turns out, I have quite a nice library of (probably shoddily written) tools now.