Hey, long time no see!
I've had this sitting on my hard drive for quite some time, but I don't have the time to work on it right now due to university work... Wasn't doing any good just sitting there (and other people are posting 3d stuff not), so here it is in its current state.
Z to drive, arrows to turn. Unfortunately that's it! No AI, ghosts or even checkpoints/laps at this stage. I got stuck on some integer overflow bugs, which you can still experience a little too easily... It might be finished one day, who knows! Just not soon. :(

Space limit is a little 3D demo (so no gameplay yet) inspired by Kerbal Space Program.
If it's too slow in your browser, try directly in Pico8



There is nothing in the sprite/tile data, the code is (realy) messy and triangles can only be monochrome.
For this project, I made a blender exporter (based on the .ply one) that can be found here
I also made a mesh converter to vertex/index string (one byte per location, scale limited to 2.5 around origin) to import in Pico 8. I made it in Javascript (If some people want it, I could port it in the blender exporter instead).

Hello everyone :)
I just made it public on pico-8 Slack's group. A couple weeks ago I created an api to use on my experiments with PICO-8. I used Kimono to scrape the BBS every 24 hours.
I had not made it public yet because I don't know if Zep'd be ok with that... and sometimes I'm too lazy to ask hahah. So hey @zep, are you ok with that? It makes just a few requests per day to the BBS... It's updated every 24 hours and makes one request per carts page. So I don't think it's gonna hurt the BBS's performance.
So here's the json api and here's a page with (hopefully) all carts.
And finally here's the api docs.

Hello, world !
I have been thinking about setting up a Slack team for PICO-8.
I noticed after searching with Google there's a team created already, but it seems to be dead, and no one in the IRC knew about it.
:: EDIT
New invite system implemented. Get your invite here: JOIN !
There's also the good old invite system JTE is running on her server: (alt) JOIN !
Eternal love (<3) to JTE for running the invite automation system, and asterick for helping to set it up.

UPDATE: Hey look! I updated it (above), and fixed the bug where when the laser made contact with the enemy, it spazzed out for a second. Enjoy!(?)
Here's my first publicly-available game made with the Pico-8! It's a space shooter where you play as a Nroctrion star-cruiser, and have to fend off the evil cihptnueians and save your home-world.
CONTROLS:
Left and Right Arrow Keys to move
Z to fire
NOTE: This is an alpha build of the game. (Very few) new features will be coming.
Also, feedback is highly appreciated! Thanks :)

I'll admit that I'm a bit new to PICO-8 and don't have a good handle on how it's built. Maybe other language support isn't trivial.
That said, I'd love to be able to use a subset of something like Ruby, Javascript, or Python in addition to the current Lua based subset.
Is there a chance we'll see other languages in the future?

Hi everyone!
I'm an absolut fan of Pico-8 and I spend a lot of hours reading this forum, many of them in my smartphone or my tablet.
I love running cartridges when I have a free time (without the possibility of use my computer). And, I can't do anything because in mobiles phones or tablets we can't take a virtual keyboard when we are running a game so...
Can you add an option to pico webplayer in order to give a solution to this?
Or... have anyone any idea how to play cartridges with smartphones?
Thanks a lot!!

Hi,
i've been thinking about something for pico-8 that could be nice: Having a kind of online high score rankings by game on the website.
Let's say the easiest way to do it first would be just in the web player on that site with logged in users.
API can be as minimal as score(value). The advantage of the opaque function is that it can redirect score anywhere (online db for webplayer, local file when ran from pico-8 sdk, silently ignored...)
This kind of feature is cool as it gives game dev more feedbacks on their games as well as increasing their replay value. Plus the community will benefit from that as it gives another axis to consolidate it.
I'm aware it is not that trivial to implement and it requires some work but I love the idea!

Hello everyone.
I bought pico8 like a week ago after my friend kept linking me awesome stuff on the forum here. The "exercise" and "now is fornever" ones were particularly inspiring to me.
On the weekend I sat down to make this scrolling background thing and then I just kept running with it. It's mostly a ton of lines, circles, and the mod operator. There isn't much point to it. You can press left and right to change speed, press up to randomise the palette, and down to reset those changes.
EDIT: 42 stars!


Here's a fun little project. By "fun" I mean "nightmarish" and by "little" I mean "countless hours of headaches".
Let's network a Pico-8 cart.
This operation involves careful controlled management of the game state and manipulating the player controls with a wrapper. If we're using an HTML5 build, we can already manipulate the player inputs with JavaScript trivially enough -- there's an API explicitly for that one purpose. It also doesn't sound too hard to pause the game whenever controls haven't been received, although keeping a frame-perfect lockstep sync might be a hassle in itself.
But the BEST networking would involve allowing the local game to run a few frames ahead of the networked player and carefully revert and re-run those frames whenever changes in input are received, so that the game still runs full speed and remains synchronized with just a little bit of reality-bending when there's latency. This requires a deep, deep control over the entire game state, and the ability to run the game (without rendering) much faster than it's intended to go.
Fun.
Maybe I'll try it sometime. The license explicitly states I'm allowed to alter and use HTML5 cartridges for any purpose. If I can't hack around that, maybe I can make my own Pico-8 emulator that runs off of the .p8 text format files... although that seemingly falls into the legal grey area of the license a bit, since it would technically require fabricating a 16 color palette and sound waveforms similar enough that they could be considered a derivative work or some such, ... unless I read the same data out of a JavaScript file generated by the HTML5 exporter...? Gah.
That's enough rambling for now. This post is just a reminder for fun things to try whenever I'm bored next.

Sometimes, especially when working with animations, I prefer using GraphicsGale than Pico's internal editor. So I'd be glad if I could copy/paste sprites to/from standard image editing programs. As of how palette thing would work when pasting, if pixel is "unknown" (not in pico's palette), color with closest r/g/b values from palette would be used.
So e.g. if I have some pixels that are totally blue (#00FF00), when pasting those pixels will be changed to closest color in pico's palette which is 1 (I think) in this case.
Alternatively import/export of spritesheet from/to png file would be welcome, with same color conversion process when importing as when proposed pasting.

Like explode() in PHP, nothing fancy, just taking a string and convert it into an array based on delimiter, so e.g. I can have following string: "303;12;18;6;23;45;10;66" and after doing:
array = explode("303;12;18;6;23;45;10;66",";")
|
Array will be {303,12,18,6,23,45,10,66}.
Reason is of course token space and I want to encode maps this way for my contra cart.
I heard of Pico-8 on the Indie retro news blog, and loved the idea. I quickly purchased the "soft hardware" implementation, and I love it. What a great community, and what a great idea.
I love the restrictions ... except for one!
I feel that the cartridge limit is restrictive. I mean, I know it's "meant" to be restrictive, and I appreciate that it forces a certain kind of game - or at least a certain way of thinking about games - HOWEVER I also feel that the resolution and interface restrictions control the type of software developed beautifully.
With more "RAM" (or is it ROM if we're talking about a cartridge? Soft ROM :)?) we could see some amazing games with great depth catering to the display hardware restrictions.
If simply allowing any size cartridge is out of the question, what about considering several "categories", so we could have 64, 128, and 256k cartridge categories, for instance?
ps
None of this is any kind of negative or "I know better than thou". I love what you have created!
Cheers,
Rob






30 comments




