With Zep's RLE compression thingy you can now store an absurd amount of graphical data. This means short FMVs are technically possible, if unwieldy.
I don't know what to use it for besides converting porn GIFs to Pico-8's palette and playing them over an energetic chiptune backbeat, though?
5 comments
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 :)
1 comment
Instead of just raising the script token limit, I propose that the token limit is fine. It's how they're counted that actually needs more polish. Here is one proposal for what to do:
Make commas, parenthesis, and periods/colons equivalent to whitespace.
They're actually abstractions denoting a specific correlation of two points of data, not a symbol in and of itself. If you're calling a function with two arguments, "funcname(arg1, arg2)" is actually 3 useful points of data, "funcname", "arg1", and "arg2", not 6 just because there are arguments at all.
Look to assembly code for inspiration. At the assembly level, which translates quite directly to bytecode, do you write "function, begin_arguments, argument1, argument_seperator, argument2, end_arguments" as that many different individual tokens? I don't think so. :P It's more like "push argument1, push argument 2, jump to function" isn't it? Three commands, three script tokens.
If you want to go farther, you could consider doing the same for math operations and the string concatenation operator. In the case of "x = y + 7", you have two things being added together and a third thing holding the resulting value, right? That can still be only 3 tokens, instead of 5. "x += 1" would be two tokens instead of three.
And if you want to make local variables usable, ever, make an exception for the word "local" so it doesn't count against you. :P
At that point, the token limit might actually be too [i]high
4 comments
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?
3 comments
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!!
1 comment
Star Wars 1.0.
I gave permission for you guys to use, but please do not post a level with attached items until this game is not WIP and fully running.
Star wars 1.0 is only f
0 comments
Got pico today.
Spent the past few hours writing a bunch of matrix math in lua. To celebrate I made a perspective-correct rotating cube :D
4 comments
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!
2 comments
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!
37 comments
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.
17 comments
Lua has a peculiar block syntax for multi-line strings. It looks like this:
game_backstory = [[ Once upon a time, the wind was blowing, kicking the sea up, nice and wavy. The tide swept in, a darkness came, and everyone drowned in sweet gravy. ]] |
Unfortunately, this makes Pico-8's code editor freak out and try to parse the entire string as individual numbers and words and stuff, grossly aggravating the token count. Plus I can't type \n in the pico-8 editor, despite the character being available in the font.
I'm already using both, since \n makes a great delimiter for writing human-readable data.
There was also a multi-line comment syntax based on it, where you could write
--[[ comments on multiple lines ]] |
4 comments
IMO instead of single license checkbox, you should be able to select by mutliple checkboxes the kind of CC license you want for your game.
So, by default it'd be CC0, but then you could check each part of CC license, so you can have any combination of by nc sa nd.
1 comment
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.
9 comments
Let's say I have a cartridge that changes game states by swapping out the _update and _draw functions. This way, when I'm at the title screen, the title screen's _draw function is called directly, as it is stored in the global variable named "_draw", and when I switch to the in-game state, the level drawing function moves to "_draw" instead. This reduces logic (and therefore saves precious characters / tokens) since you no longer need to call the function yourself based on what gamestate you're in.
Now, one of those game states is transitional. It doesn't need an _update or _draw function. It exists entirely as an _init function that draws and flips itself for a bit, then changes the gamestate to something else. But since Pico-8 knows that there was an "_update" function before, it still remembers that and tries to call it...
... Which crashes the program script with a Lua error saying that it failed to call _update on a line beyond the end of the program. Fun! :D
I can of course work around this just fine. In fact, with a full implementation I'm sure this problem wouldn't even exist, since flip() would presumably skip the _update and _draw calls until it's done. But this is still a thing worth noting... somewhere. Probably. ^^;
Test cart:
0 comments
The "Read Me" shortcut the installer puts on the Start menu points to "pico8.txt" (It should point to "pico-8.txt")
Very minor. Easy fix.
0 comments
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.
0 comments
You can use the (invisible) mouse to click the (invisible) editor mode buttons while you're still in Pico-8's command prompt, even though you can't see them, switching to an editor that way instead of hitting Esc.
The mouse is probably intended to be ignored in this state, making this a bug, right?
3 comments
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
50 comments
