Warning
This game contains flickering sprites, so be careful if you are prone to epileptic seizures.
There is an option in the menu to toggle flickering on or off if you need to.
This game also features a scrolling background which may cause motion sickness in some individuals.
This can also be disabled in the menu.
A basic WIP shmup inspired by Danmaku.
Apologies for the messy code; I'm not super familiar with LUA or Pico-8 yet.
Comments and criticism are welcome!
Mechanics
Focus
This game features a fairly standard FOCUS MODE, as seen in many shmups.
Basically you press the button and you shift most of your ship's power into its weapons, allowing you to fire a focused, more powerful beam at the cost of movement speed. FOCUS MODE also makes your hitbox more visible.
I just entered the basic uppercase Apple ][+ font in sprites and added a SFX that is the tone of the boot beep of the Apple ][. If this is exciting to you, use it in whatever project you want with a lil' credit in the comments.
I also added a few character I wish I'd had back then in spritesheet 1.
Initial running of the cart cuts off the beep. Reset the cart to hear it properly (hit Return and choose).
Enjoy!
Another Tetris clone, I know :P
I managed to squeeze in an extra mode, take a look if you want!
Why are you reading this, it's Tetris, you probably already know how it works
Anyways, this clone is guideline-compliant in large parts (except where the guideline is boring or confusing to me), including Standard Rotation System and kicks. It has a steep difficulty curve, and a lot of options to adjust gameplay, animations, or Tetromino sprites (I have 16 now!).
I implemented 9 different modes, and up to 3 highscores are automatically saved per mode (options are also automatically saved btw)
If that description was too [b]dry and boring
Made for CCAW jam. (https://itch.io/jam/ccaw-jam)
Get dog into the doghouse by moving planets and blasting jetpacks.
Definitely my biggest pico-8 game yet. Time to learn how to use metatables...
Controls
Menu: Z to start game.
Game: UP/DOWN to adjust nectar quota (how much nectar a bee will collect before returning to the hive)
Z (when the 'add bee' icon is visible) to add a bee at a cost of 10 nectar
Game over: Z to restart.
Mechanics
Bees visit flowers for nectar (but they can only find flowers within a certain radius, so they explore if they don't find one right away). Bees collect nectar until they have enough for the quota, then they bring it back to the hive. As the hive accumulates nectar it can produce more bees. Bees have limited lives, but every time a bee dies, a new flower is born somewhere in the garden. Every visit of a bee to a flower adds pollen to the flower, which helps the flower produce more nectar. You can adjust how much the nectar quota is, balancing between bees being away longer (more likely to die without returning their nectar) and bees spending too much time on journeys to the hive (not using time efficiently). You can also add new bees once there is ten or more nectar in the hive.
The game is over when the last bee has died and there is not enough nectar left to add a new one.
(I am not trying for realism in any way with this game!!!)
Commentary
I started with just bees, and they would look around for flowers. Writing rules for entities and seeing how they work is great fun. This game was a slow burn but a great experience. I was flexing my systems design brain gently throughout the month, trying to ride the line between 'there's nothing to do here' and 'this game is asking too much of me'. I think it came out pretty well in that sense. The only interaction from the player (if they even want to interact) is to adjust the nectar quota and get the bees coming back more/less often, or add new bees.
itch.io page: here.
For my game, Witch n Wiz (https://www.lexaloffle.com/bbs/?pid=38117#p), I implemented as simple technique for loading a secondary spritesheet at runtime. This allowed me to have a fullscreen title graphic, but not use up any of the sprite sheet memory (needed for game sprites and map data).
The cart at the top of this post is an ultra simple example of it in use. As you can see, you are able to switch between 2 sprite sheets that would each normally take up the entire sprite memory.
Credit for the num2hex function goes to felice (https://www.lexaloffle.com/bbs/?tid=30910)
Limitations:
You can still only have 128x128 worth of sprites in memory at a time. So this is really best for things like the title screen, or major switches in gameplay (say switching worlds where you don't need any of the original sprites anymore).
BUG COLLECT
Move around to collect bug specimens that add up to the correct number in the upper right corner of the screen.
How many collections can you make in 1 minute?
Arrow keys - move
X - reset bugs
Z - start the game
Oh, and don't step on the eggs!
My entry to the 17-in-1 jam.
Follow me on twitter @brintown
z - generate new frames
x - start/stop animation
left/right - change between different lsystems
up/down - regenerate all frames/ regenerate system (for stochastic systems)
System handles a variety of lsystems and also generates new frames to interpolate between on
the fly using coroutines.
Big_B_Radical
This is my first pico cart. I hope you like it. It only has a few levels, and the collision mechanics might be a bit wonky at times.
PicoPort is a Portal demake. Where you solve platforming puzzles by using portals, which teleport you from one point to another.
I might add more levels and more gameplay elements to the game.
Controls:
-Arrows to move around
-Hold x or z to start aiming
-Arrows to aim
-Release x or z to shoot
-X for the pink portal
-Z for the blue portal
Hey y'all :) I'm currently working on a game where you look through various objects cluttering up your space & scrub them out of existence if you don't want them. Objects are placed onto the screen, one at a time, for you to observe & erase. The screenshots here show a rough draft of the mechanic--the brush goes to the right side of the screen, having come over from the left & "cleaned" a line through the box.
I've gotten a functional brush up & running (thanks to carts like shodo for reference!), but I want the game to be able to check if the object has been "erased" or not, aka if the object has been completely covered up by the brush drawing over it.
Because the background will be black, and the object is being drawn over in black, I'm thinking something that checks to see if the screen data equals 0 might work. I'm not really sure if that's how I should be approaching it, or even how to format it properly. There's also the fact that the brush will still be on the screen after erasing the object, so I don't know if there's a way to check for screen data while it's there, or if I also need to make sure that disappears too.