Log In  
[ :: Read More :: ]

Important note: Due to the multi-cart nature of this game, do not use the "reset cart" menu option. All that will do is corrupt the data loaded from another cartridge and make the whole system crash.

Cart #58338 | 2018-10-24 | Code ▽ | Embed ▽ | No License

A massively multi-cart Mario Party type of game. Currently an early proof-of-concept tech-demo type of thing and not actually "playable".

The character select can be huge because every character exists in its own "sprite blueprint" cart and gets chainloaded compressed into RAM when the game starts, followed by the game board or game mode (eg. a minigame select free-play menu) cart which drives the rest of play. The board/mode itself (and any minigames it loads into) decompress only the specific sprites they need into the active sprite sheet for use in play. Some minigames might only use the sideways character sprites because they're 2D. Some might use tiny Jelpi-style sprites for players. Some might opt to use player portraits instead of world sprites. And so on.

The sprite blueprint system supports multi-part sprites (in this case Nora's head is separated from her body in all but the portrait sprites) made of parts which are independently offset, vertically and horizontally flipped, and palette-remapped (including primary and secondary "special colors" which might be remapped for duplicate players or special events), and all that data is transferred between carts so the sprites, colors, and character names are consistently recreated.

P#58227 2018-10-22 06:09 ( Edited 2018-11-01 19:32)

[ :: Read More :: ]

I'm about to make a dozen blind assumptions based on this old Tamagotchi device, the original Digimon Digital Monsters Fighting Virtual Pet. I know very little about electronics and don't currently own one of these devices to do any tests on, so please excuse my ignorance if I'm completely wrong.

Those two metal bits on top? They're GPIO pins, essentially. If you're lucky, it's likely even 3.3 volt and won't need to be converted up or down to utilize it.

Because they're oriented vertically, the top pin will always connect to the matching top pin of the partnered device. Therefore, instead of using one pin as an input and the other as an output and just hoping the clock speeds of both devices match (which would require a horizontal pin layout so that the input pin of one device connects with the output pin of the other and vice versa), they probably use an i2c method of communication. https://learn.sparkfun.com/tutorials/i2c

Therefore, if you carefully inspect the transmissions between two of these devices (which should be simple, considering the pins are spring-loaded and would easily compensate for a wire being shoved between them), figure out which pin is the clock and which pin is the data, and what kind of data is being transmitted...

Theoretically, you should be able to develop a virtual pet on Pico-8 which can utilize the GPIO pins of a Pocket CHIP or Raspberry Pi device to fight a Digimon. And win. How cool is that? :3

P#58122 2018-10-18 19:59 ( Edited 2018-10-19 21:46)

[ :: Read More :: ]
-- generate tile
for y=0,7 do
 for x=8,15 do
  local c=flr(x/2)+y
  if(x%2==0) c+=rnd(2)-1

-- set map tiles
for y=0,15 do
 for x=0,15 do

-- display map
local t=0
function _update()
function _draw()
 for i=0,3 do
  pal(i,flr(t/4)%4==i and 12 or 1)
 map(0,0, 0,0, 16,16)

Cart #41801 | 2017-06-20 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

P#41802 2017-06-20 08:23 ( Edited 2017-06-20 19:35)

[ :: Read More :: ]

For literally-years now I've had this comment at the top of my Kid Radd cart, right under the label comments:


Although more recently, Pico-8 has become able to properly handle standard Lua multi-line comments, so that could be changed to a cleaner block with a defined ending, like this:


These comments are entirely unused, waiting for some kind of extension format to come along and read metadata to make modifications to the machine before the cart runs as normal. With the theory being that the block of comments could be "cut out" of the script and run as their own, separate, "configuration script" with reasonable ease, using an extension API of some sort. In this case, the configuration script expects to be given an array named "pal" (no relation to the Pico-8 command of the same name) which is pre-populated with Pico-8's default palette, and then internally gets read back to set the screen palette before the game script even begins.

However, if such extensions were made widely available, perhaps in some third party pico-8 emulator (as there are a few floating around), it's more likely they'd take an active role in the game script (and therefore token count) such as this:

if __ext__ and __ext__.palette then
 local remap=__ext__.palette
 remap(1, 0x24, 0x35, 0x66)
 remap(6, 0xc0, 0xc2, 0xe3)
 remap(12, 0x57, 0x6d, 0xff)
 remap(14, 0xff, 0x5e, 0x98)

This would allow certain extension-enhanced Pico-8 games to potentially remap the colors of the Pico-8 palette in realtime between frames to subtly tune the color outputs for each scene, and would still be playable on a vanilla pico-8 without color modifications because "__ext__" would be nil and therefore evaluate as false, skipping the entire code block.

As far as I'm aware, various Pico-8 web player wrappers exist which manipulate input types and gpio pins, but none have gone so far as being capable of remapping the palette colors or added other noncanonical extensions to the api itself, to be run by each individual cart to apply their own mods and settings.

tl;dr? start here

So, if there were a third-party extension api which some games could use to improve their quality in some way, and those carts may or may not retain backwards compatibility with unmodded pico-8, how would you design the extension api and what kinds of neat features would it have?

Would you add new common optimization functions to try and reduce cpu usage of otherwise sluggish games? (Assuming your pico-8 emulator even respects cpu restrictions, of course!) Would you add completely new rendering modes? Would you make a new bank of memory available like an N64 expansion pack? Would you add a new widescreen aspect ratio mode, or even break the 127x127 screen resolution somehow?

Tell me what you'd do and how you'd do it! What kind of code would you put in the cartridge's script to "activate" and use your extension features?

P#41494 2017-06-09 15:49 ( Edited 2017-06-09 19:49)

[ :: Read More :: ]

Instead of just giving carts the ability to replace colors in the palette with other colors outright, I propose a totally dumb alternative:

A new screen rendering mode which does linear blending on the image by shrinking the 128x128 screen area to 64x64, turning this:

into that:

Games would have to be designed as 64x64 to make proper use of this of course (unlike my test case there...)

The basic idea is: To make a new color, all you need to do is color each pixel in a 2x2 area with different colors you want to blend together to make the new one. Then when the screen gets scaled down, all those pixels will get combined, making a huge number of new shades and hues available without just letting you change Pico-8's base palette colors outright.

Now excuse me while I study how composite video cables work so I can figure out CGA Composite Mode rendering to make 16 colors out of 4...

P#25328 2016-07-15 05:05 ( Edited 2016-07-15 10:00)

[ :: Read More :: ]

When I made Nora's Mouse Chase! for p8jam2 last month, it left me unsatisfied. So I started work on my own 2D game engine again. At first I was making it from scratch, but then I realized all the C libraries I had gathered made up basically the same thing as LÖVE anyway, so I switched to using that as the base. There were some other snags and I've had to basically start over a few times, but I'm working out the details as I go.

I don't have anything to show for my work yet, so I don't know why I'm posting... And I certainly don't know why I'm posting it here, of all places. Maybe I just really adore this quiet little corner of the Internet.

Anyway, I've given this project the working name of Nora-Net. The goal? A decentralized online multiplayer game engine and service, capable of supporting at least 100 players per server (although ideally somewhere around 1024 players would be amazing), where the game itself can be edited cooperatively online by admins who can upload new scripts and sprites on the fly and build the world together.

In one sense, the continuing efforts where pico-hotel left off. In another, a decent replacement for BYOND and Second Life, with realtime action gaming in mind. I want Nora-Net to be able to support puzzle games, platformers, and RPGs all just as effortlessly, with a Bitcoin Wallet type of client-side account registration and identification to access server-side save data which servers can share with eachother if set up to allow it.

I want this to be something I can go to as my game engine of choice for all my future projects, an engine capable of virtually any 2D game imaginable, supporting singleplayer, multiplayer, and massively multiplayer, with optimized renderig and networking behind the scenes. I want to run a Mii-like character creation service on it which exports finished character head sprites in a variety of sizes, styles, and poses for other games on the engine to use with their own body sprites to make a unified-yet-customizable avatar for you to take with you everywhere, whether that head is getting tacked on to a space marine or used as a portrait when you win or lose a round of Puzzle & Flower Land 3.

This is too big of a project for me to tackle alone, and I know it. I also have no income and approximately two years left before my life will almost certainly take a turn for worse. But what the hell, let's see where this road takes me anyway. It'll be fun.

P#22887 2016-06-14 17:51 ( Edited 2016-07-30 01:50)

[ :: Read More :: ]

Cart #21677 | 2016-05-30 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Overworld Controls:
◁ ▷ △ ▽ - Move
Ⓧ - Interact, continue dialog
Ⓞ - Speed up dialog

Combat controls:
◁ ▷ △ ▽ - Change selection
Ⓧ - Activate
Ⓞ - Cancel / Back

Standard Pico-8 keyboard assignments:
Arrow keys = ◁ ▷ △ ▽
Z,C,N = Ⓞ
X,V,M = Ⓧ
P,Enter = Pause menu (useful for resetting the game to play it again)

For the best experience, take the time to try interacting with all the objects, too!
Have fun catting around!

Thank you everyone for your support.
Here's my post-jam development diary / full disclosure wrap-up thing:

So, at first I wasn't sure how I could motivate myself to participate again, because I can only really get into it and make something amazing when my heart is in it. Nearing the date of the jam, I got the bright idea that what I most wanted to do right now was make a game about Nora, so no matter what the theme was I would find a way to shoehorn Nora into it.

Nora is my mascot character. She was thoughtfully designed ahead of time to be the epitome of adorable innocence. The large art at the top of the post is actually a piece of rough concept art for her that I worked together with an artist to produce, and it actually took a bit of work to get her to where she is today.

I had been meaning to flesh out her world and create additional characters to play off of her personality for a while now, and I figured the jam would be a perfect way to motivate myself to get something out there.

I was actually hoping all along that I'd get to make an RPG, because RPGs are rare on the Pico-8. When jam theme voting came up, I cast a dual vote for Blob and Useless Power-up. That way, if Blob was selected, I would benefit by having standard RPG slimes to fight against (and cute moe blobs for characters!) while everyone else foolishly used the built-in circle tool to try and do wacky blob physics games. And if Nora gets a Useless Powerup instead I could easily make that an RPG McGuffin of some kind... So either way I'm good, right? With that settled, I began work on pixel art.

And then the jam turned out to be about Chain Reaction. Crap.

How am I supposed to make these 16x16 pixel overworld walking catgirl sprites into the embodiment of a "chain reaction"? At first I doubled-back, thought I could change my design into another charming but simple puzzle game where you place a dog to move forward and scare a cat, which moves away from the dog to scare a mouse, which moves away from the cat to collect the cheese... That's a puzzle game, right? I have vague memories of a puzzle game like that actually existing at some point, but I couldn't remember the details to really make it work... It would be boring to make a puzzle game if I can't figure out any intricacies to make it require some thought! At any rate, the first early alpha version went by this design (see "Earlier versions:" below), hence the little info box which is now missing from the current version of the header image.

Uh oh. It looks like someone else had the same idea as me, and they seem to remember the rules better than I do as well. It was a game about using a mouse to scare an elephant into a cage or something, right?

Well, since I don't want to risk my jam entry being redundant and I don't remember how to make that fun anyway, I'm back to figuring out how to make an RPG with a "chain reaction" twist. The results became the finished product: A battle system where instead of selecting the attack you want to use (so that you can just spam the enemy's weakness over and over), you have to figure out how to connect multiple attacks together into a big chain to deal significant damage.

My fatal mistake was trying to keep the overworld aspect of the game, rather than just focusing on the combat system. Because this project was still about fleshing out Nora's world, which was important to me. I already had sprites for all four directions set up, so it would be a waste to throw them away changing my plans again, right?

I ended up working obsessively, pouring hours into this project all week long, slowly adding more dialogue, more rooms, more scenery objects... Then I realized my second mistake: The combat system is like nothing anyone has ever seen before, so it needs a full proper tutorial before people will grasp how to use it. And if you don't know how to play, you can't win the game.

After packing a full tutorial, a bunch of overworld NPCs and dialogue, a wacky scripting system for dialog-triggered events and the like, and then finally getting around to implimenting skills to use up your MP and drastically reduce the luck factor for players who know what they're doing, all in a newfangled object-oriented system that uses up more code space for the sake of making everything much easier to handle and find your way around...

I ran out of tokens. Oops.

So, the finished product ended up having only two battles (I had planned a third, final boss, with gimmicks and a true ending) and thus was very light on gameplay despite being packed to the brim with solid content. If I had instead only made the combat screen and cycled through enemies randomly (including recolors), I could've had potentially endless hours of gameplay. Instead it's something short and cute that you play once and never touch again, much like my previous Pico-8 Jam entry, Frog Home.

I guess I just love to tell a story.

Known issues:
* Battle animations may be too violent. (unintentional game design flaw...)

  • Web player desynchronizes audio when lagging (nothing I can do about that, try restarting your web browser or closing your excess tabs)
  • Pico-8 font is hard to read (might consider wasting space fitting in another font or something)
  • Only one silly little music track. :(
  • No good display for elemental weaknesses, you'll have to pay attention to the numbers.
  • There was supposed to be an optional final boss with some gimmicks that I couldn't fit under the code limit, let alone write another ending for. If the ending feels wrong, that's partly why.
  • I see you messing with the palette again zep, cut it out... D:

Earlier versions:
Cart #21673 | 2016-05-30 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Cart #21598 | 2016-05-29 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Cart #21536 | 2016-05-28 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Cart #21533 | 2016-05-28 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Cart #21518 | 2016-05-28 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Cart #21445 | 2016-05-27 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Cart #21442 | 2016-05-27 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Cart #21296 | 2016-05-25 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Cart #21148 | 2016-05-23 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Cart #21145 | 2016-05-23 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Cart #21067 | 2016-05-22 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

P#21050 2016-05-21 22:07 ( Edited 2017-06-20 18:53)

[ :: Read More :: ]

Here's a recent interesting project which is completely unrelated to Pico-8.

It's an HTML5 game engine. More importantly, it's a free and open-source web-based development IDE. That is to say, instead of using Superpowers IDE to make Unity-like Superpowers games, you can add a plug-in to your Superpowers server to add additional project types, including (officially supported, in fact) LÖVE games and static webpages.

Superpowers is a real-time multi-user collaborative development environment unlike anything I've ever seen before, albeit still very much in its infancy. We should seriously consider adding Pico-8 cartridge support to it, as an alternative to using Pico-8's built-in IDE.

It would take a bit of effort, but with the result, you'd basically have the ability for any number of developers to simultaneously log onto a hosted Superpowers server, upload scripts and sprites, and download and run the resulting combined cartridge from the server in real time.

Superpowers is pretty much designed for small teams working together on game jam entries with strict time limits, getting all the work together immediately in real-time as individual files are changed and saved, without having to worry about committing and merging changesets like you would with Git or other collaboration methods.

... I don't know, just a passing thought. Probably wouldn't be worth it, considering how difficult it would be to manage Pico-8's arbitrary limits in a development environment meant to handle limitless modern PC games.

P#19132 2016-03-08 09:36 ( Edited 2016-03-08 14:36)

[ :: Read More :: ]

Happy birthday to me, I guess.

P#19103 2016-03-07 14:56 ( Edited 2016-03-07 20:33)

[ :: Read More :: ]

Zep made me an adorable little plastic coaster commemorating Frog Home.

So I turned the design back into a little Pico-8 cart.

Sorry it's so barebones, I just wanted to share with everyone. An amusing way to upscale a little sprite, I guess?

P#18197 2016-01-08 09:44 ( Edited 2016-01-21 01:38)

[ :: Read More :: ]

Cart #17988 | 2015-12-22 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Cart #17974 | 2015-12-21 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Just a "music" cart.
It shouldn't desynch even if the web client lags because the floating text spawns the music.

P#17975 2015-12-21 17:41 ( Edited 2015-12-24 05:59)

[ :: Read More :: ]

Cart #16965 | 2015-11-24 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Here's my generic "Look everyone! I made raindrops!" cart, since the theme is rain.

If it sounds absolutely horrible, don't use the web player. The web player skips frames, which does not bode well when the raindrops themselves are playing the music.

If it still sounds absolutely horrible, I'm sorry for being terrible at music. I will try harder next time.

P#16964 2015-11-24 09:37 ( Edited 2015-12-11 11:53)

[ :: Read More :: ]

Cart #froghome-0 | 2023-01-24 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Press Z to frog. Go do frog stuff.

This is now a complete game and solvable. It'll tell you when it's over.

Puzzle games are meant to have solid mechanics, so unless a frog starts floating, you're probably not actually stuck and it's probably not a bug.

Pico-8 Jam 1 version
Cart #16983 | 2015-11-24 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Unrefined, but still "finished" version
(May contain bugs)

Cart #16979 | 2015-11-24 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

P#16826 2015-11-21 04:10 ( Edited 2023-01-24 02:13)

[ :: Read More :: ]

I've been using the Pico-8 for a while now, since it's pretty much everything I've ever wanted in a "fantasy console", and I would have made one almost exactly like it (albeit with a larger palette and looser limits, perhaps...) if and when designing and programming one myself. So to skip that entire process and jump straight into making nifty little widgets and toys for this device... Well it's been quite a dream come true!

That said, Pico-8 is far from being without issues, and more keep cropping up the more I play with it. So, outside of bug reports, here's a small laundry list of things I "want", or would be nice to have at some point...

Note: This is a blog post, an off-the-cuff rattling of random things I personally would desire. I'm not expecting it to be directly acted on or hotly debated or anything like that, this just keeps track of what I want so I don't forget, you know?

  • The ability to call non-system functions without arguments in the same way as system functions, eg. as "run" instead of "run()". Maybe before trying to process the input as a Lua script, it should try to see if there's a global variable by that name first, and if that variable is a function, call it?! There's no reason to make such a distinction in most cases.

  • How about a find(needle,haystack) function? It would search strings for substrings or arrays for values and return a number from 1 to #haystack where it's found or nil, false, 0, -1, or whatever when it's not.

  • I often find myself needing a pause button, even if it's not a game button. The only way to pause a game right now, if it's not in the web player (which can be paused by clicking on it, as counter-intuitive as that sounds!), is to press Esc to kill the entire program, which often has unfortunate side effects like stopping the music or reverting the map, sprite, and sound data.

  • If it doesn't already, when Lua "runs out of memory", it should first try to garbage collect and see if that frees enough space to keep going.

  • I need the type() function back so I can have mixed type arrays again. Without it, and without tostring(), there's no way to avoid accidentally crashing the script trying to concatenate arbitrary values to print debug text and whatnot... I'm forced to carefully distinguish variables and keep it all totally separate. Bogus, man!

  • I want the _G table back so I can iterate through variables in the global namespace or "construct" variable names by string concatenation. It would have to be lower-cased to _g in Pico-8 due to the whole mono-case thing it has going on.

  • load()'s silent failure is a troublemaker, and there isn't an exists()... So either make load() return a meaningful value (a boolean perhaps) or add an exists() that checks for a file or make ls() return a list of files or something... Come on...

  • Change the hardcoded _mainloop function so that it works more like this:
function _mainloop()
    local must_draw = true
    while _update or _draw do
        if _update then _update() end
        if _draw and (must_draw or stat(1) < 1.0) then
            must_draw = false
        else must_draw = true end

(This was the closest approximation I was able to make without knowing the actual script source.) That way, programs can have only an _update loop or only a _draw loop, swap them out, or even terminate the main loop by removing them both. There is currently no way to exit the main loop otherwise, as far as I'm aware.

  • I miss metatables, but considering Pico-8's constraints they're not high on my priority list for the return of...
P#16599 2015-11-13 06:10 ( Edited 2022-04-13 21:22)

[ :: Read More :: ]

So, today I made a Pico-8 paint program... in Pico-8.

You might be wondering why I would do such a thing, since the Pico-8 development platform comes with a built-in paint program that's almost exactly the same, except it can use the mouse instead of clunky keyboard controls. The simple answer is... This is the beginning of what might be the biggest thing I'm likely to do on the Pico-8. Ever.

Imagine a Pico-8 game shared by a Dropbox folder or similar system, where every user gets their own character and their own room, and every object in the game world was uniquely painted up by users, held, given, and placed in those rooms to furnish them with things, and all of it was maintained by a slow, asynchronous system of a multitude of carts, set up in such a way that multiple copies of the game being run by tens of players should never cause data collisions.

Welcome to Pico Hotel, an oldschool collaborative world-building and interaction experience.

P#16595 2015-11-13 00:49 ( Edited 2016-05-17 14:28)

[ :: Read More :: ]

Cart #16507 | 2015-11-10 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Sorry for your eyes. I am so bad at math.

P#16508 2015-11-10 18:05 ( Edited 2015-11-12 00:42)

[ :: Read More :: ]

You know how in "Kong" they called Mario "JumpMan" because he jumped over things? Well I call this little guy "RunMan" because... Well, you'll see!

Cart #16486 | 2015-11-10 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

P#16480 2015-11-10 02:25 ( Edited 2015-11-23 07:30)

[ :: Read More :: ]

Cart #16461 | 2015-11-09 | Code ▽ | Embed ▽ | No License

(Warning: It takes more effort to lose than it does to "win" endlessly.)

This is a little something I threw together specifically to make into a microgame for the PicoWare collab project

I may have gotten a little carried away with the music, it's way more awesome than the gameplay at this point...

P#16448 2015-11-09 00:20 ( Edited 2015-11-20 18:18)

[ :: Read More :: ]

Here's a funny little collaboration project that I'm afraid only works offline by nature. I've set up a system to pass data back and forth between carts for a "WarioWare Inc."-style micro-game system.

If you have Pico-8 installed, you can download the current API / project and microgames from here: picoware-inc_2015-11-19_2.zip
You're all set to play and/or make your own microgames, microgame loaders, etc. Have fun!

Starter pack microgame list:

  • Jelpi by Zep
  • ennuigi by joshmillard
  • Simon Says by Connorses
  • pick the nose booger by Connorses
  • Tech Exercise by Connorses based on Graphics Exercise by Mason
  • Puzzlecave - Raiders Of The Lost Potato by hackefuffel
  • Endless Train by le_gars

Currently missing features:

  • "Skill" ramping. The microgames never get harder, only faster.
  • The interface is entirely barebones right now. It could use some art assets, fuller music, etc.

If you need help, you can contact me as JTE on IRC or catgirl on Slack, I'd be happy to work with you if you have any problems or improvements or just want to slip a new microgame cart or two into the next release package.

P#16418 2015-11-08 06:09 ( Edited 2016-07-02 23:36)

[ :: Read More :: ]

Cart #16385 | 2015-11-08 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

3D week? I think we're skipping a big technological step going straight to filled and dithered polygons...
I made a triangle out of lasers, I guess.

P#16386 2015-11-07 20:01 ( Edited 2015-11-08 01:16)

View Older Posts