Small shooter game written for Ludum Dare 39 in 48 hours.
About the game
You need to control your space ship and keep eye on the energy! Every shot cost's you some, as you move forward, your battery discharges.
Avoid enemies, kill the boss and survive as long, as you can!
Controls
Arrows - move
X - shoot
You can also play ADC on its itch.io page!
- - - ABOUT - - -
So right after I finished my first released game, Messages, I decided that I wanted to try and make an RPG in Pico-8. Well, about a month and a half later, this is what that project became.
This thing barely fits on a cart, using almost 8192 tokens, each of the 64 available sounds, and basically all of the sprite and texture data.
Oh, and I did what I could with the soundtrack, but I'm not a musician so I can't promise anything about it's quality.
And if you're interesting in finding out about future projects of mine, you can check out my Twitter: @Jusiv_









.png)
A barebones implementation of the FABRIK algorithm ("Forward And Backward Reaching IK"). Move the mouse around to control the IK target point.
I think there's something kind of cute and coincidental about the way that it actually sorta looks like fabric.
FABRIK is a clever trick that's surprisingly straightforward to implement, and it gives some really natural and performant results. The general principle is that instead of doing gradient descent or other fancy math for IK, you just imagine that your IK chain is a string (for 2D strings, imagine that they're resting on a table, and you're viewing from above).
At each tick, you perform two loops through the chain: First, you "pull the string" by the end point to the target position (and some amount of the rest of the string will get pulled along with it). After you've done this, you do the same thing, but this time, you pull the root of the string to the anchor point. (If the IK chain is a person's arm, then the anchor point is the shoulder.)
The source code also includes a 2D-distance check that tries to avoid number-overflow (by sacrificing some precision) when you give it a large enough vector. Might not be tuned perfectly (I really just guessed about the "safe range"), but maybe some motivated party can math out a more rigorous version of the function!


Kudos for my teacher for the custom level art.
My teacher gave me the task of creating a enemy where it cannot be hurt from the front, but can be hurt from the back from any projectile. First I thought: I'll make a Visibility modifier and make the enemy immortal when the player is in view. My teacher then placed a projectile shooter in front of the thing, and the player behind it. The projectile happened to kill it from the front.
Then I had to rethink things. The only way (that I thought) to stop something from hurting you is to place something in front of you. I then made the monster produce another monster repeatedly to take the bullet for it. It worked, and the monster cannot be hurt from the front (with acceptation of collision damage).
Also, they're based off of the knights from the binding of Issac (if it was too hard to tell), so don't be surprised if they start moving faster when you stand in front of them.
Here's my next project, Bubbill!
It's about a duck that shoots bubbles. That's about it.
My last project, Grapple Land, was horribly written, so I decided to start something new.
Controls:
Arrows to move,
Z to jump
X (while on ground) to shoot
Bubbles and enemies can be jumped off of, but you'll need to be holding Z for full height.


I am so terribly sorry. I actually intended to demake Insaniquarium using this game kit as some form of sample game, but it ended up sitting on my computer for months.
Anyway, over said months, I probably forgot the actual state of this gamekit, but from what I remember:
- Allows players to take a break for at least 3 years before breaking.
- Provides a screen for entering date + time. With this info the game calculates the last time the player played the game. (You basically rely on the player not lying to you, because Pico8 doesn't expose the OS clock.)
- Unique feature where time is progressing slower while the game is running. /s
- No seriously, the clock isn't accurate while the game is running, but it should be somewhat accurately calculating the time since the last playtime.
- Lots of finicky floating errors and overflows to keep in mind with while setting up the numbers.
- Define your own "resources" (hunger, gold, joy, etc...) with their own min, max and starting values. As well as the tickrate and tickamount (negative or positive!)
- Uses cartdata
Obviously I welcome any and all optimizations. Actually... considering the token count I [i]should beg


Phew! It took a lot longer to get to work on it again than I'd liked, but here it is, the updated version of the prototype!
I added more tile colors, tried to get the blank tiles a bit pleasing to the eye, added more stars (like that's important), worked slightly on the sounds, and made drawing attach to the existing line when started on it.
The controls are, in case you missed the first version:
- Z (button 1) to switch between drawing and navigating
- X (button 2) to cancel current drawing
- Arrows to move the cursor
Tell me what you think!
Version history


Game for the Ludum Dare 39 -- Theme: Running out of Energy
The shy gladiator has to defeat three mythical creatures, but he is too embarrassed to attack,
so instead he must dodge their attacks until the monsters lose all their powers.
You can move left or right, and dodge with "Z". Dodge will give you a few invincibility frames, but also
take some hit points from you.
Can you defeat all three monsters?
Game by @caranha and @conanfelipe
TODO:
- Better title screen that actually explains the game;
- Better logic for the Cyclops, and calling out attacks;
- Balance the damage amounts better;


Please join me at https://www.twitch.tv/hearthmasta to watch me live stream PlayPico.com development tonight at 10:00 PM EST (2:00 AM UTC, or 20 minutes from the time of this posting)! Great music, great wine, learn web development and give me your feature requests and help me design and develop PlayPico for you!
Looking forward to seeing you there!
The two things I really wanted to get out of the way before learning anything more were object-like tables and collision detection.
Done and done with very little presentation.
64x64 graphics mode used. In part as practice as I'd like to help my brother with the Low Res Jam. In part, because it made a "larger" maze with less actual coding.
Now with basic sound and music, because why not.
Collision detection modified slightly from Pico-8 Fanzine issue 3, page 16.
This is a slightly changed of the original made by me Sam (I made an account for my self).
The Original was made in a camp called Digital Monkey with help by Greg and Matt.
If you would like to use this weapon in your game, I highly recommend making your own music for the gun due to how much space the song in the gun takes, and there is a limit for uploading to voxatron.
Feel free to remix but please credit me.
Original Post Here

At long last, the game is finally done!
Before you play: Dank Tomb is a pay-what-you-want title, which means that if you prefer to play it for free, it's perfectly okay to do so. But I'd really appreciate it a lot if you choose to pay for it through itch.io, or support my future work on Patreon! Supporters get bonus stuff as a thank-you from me: an expedition journal with additional story for Dank Tomb and access to unminified PICO-8 source code for the game ($5+).
Enjoy the game, and let me know what you think! A lot of blood, sweat, tears and elbow grease went into making this game, so I hope you'll have as much fun playing it as I had making it!










PICO-8 uses the discrete GPU on mac laptops; this uses a lot of power on battery.
@zep, could PICO-8 use the integrated graphics instead of the discrete GPU?
I really hope this change is compatible with PICO-8, I would really like to use it on battery and still have decent battery life. PICO-8 seems lightweight otherwise.
THANK YOU!
Resources I found on this topic:
This is a link to how GLFW sets up an OpenGL context on the integrated GPU on macOS
https://github.com/glfw/glfw/blob/master/src/nsgl_context.m#L173
In SDL2, I added those two attributes used in the GLFW source to the NSOpenGLPixelFormat init call found in
"src/video/cocoa/SDL_cocoaopengl.m"
This caused all of the example apps in the Xcode "SDLTest" project in the SDL2 source code to use the integrated graphics, the attributes being: "NSOpenGLPFAAllowOfflineRenderers" and "kCGLPFASupportsAutomaticGraphicsSwitching"
Here is the partial change from the SDL source tree (missing adding attribute "kCGLPFASupportsAutomaticGraphicsSwitching"):
https://hg.libsdl.org/SDL/rev/fb4e35d0d523
(edited to a single post for easy reading, thanks @PixelBytes)




