My entry for LD34.
I didn't really participated in this Ludum Dare (again)... I just started to do something on whim 3 hours before the deadline. So "Bean up" is what I managed to finish in that time. :)
Ohh, a link to the games LD page, in case somebody arrives from anywhere else than the LD site, and wants to vote (hehe) http://ludumdare.com/compo/ludum-dare-34/?action=preview&uid=36967
POST-COMPO VERSION:
If you came here to vote on Ludumdare, please play the original version!
If you are just here to play, then definitely play this post compo version. :) I worked on it a couple of more hours. Not that it means that I worked on it more time than any LD participiant :) I'm still nowhere near 48 hours - maybe around 5-6 I guess.
0 comments
Well, after spending the entire weekend doing other things, about 7 hours ago I decided that maybe I should try to create something for this Ludum Dare after all. :)
And I almost done it... The cartridge is playable, not even too ugly, but lacks levels - I managed to create only four introductory levels.
And of course there are some bugs too (don't step on a human!), but it can be finished without much problem.
Tomorrow I will travel the whole day, I doubt I will have the energy in the evening to complete the game, so I just submit it in this state.
Enjoy! :)
Hi,
This is Helitaxi 2000
By the year 2000 (the far future) the surface Earth is doomed, ruined by atomic wars fought between evil corporations. The survivors live in huge caves underground and for transport, they use armored helicopters, because that makes complete sense in a cave.
You are one of the pilots, trying to make a living by taxiing people in the hostile environment.
This game is a mix between Space taxi and Airwolf. At least thats the aim, but right now it is mostly like Space taxi - there are no enemies on the level, just environmental hazards. I run into code size limitations, and didn't wanted to go over the whole thing and shorten the function/variable names... (Actually there is a lot of unused code in it, but I wanted to use those later by yet-unwritten code parts...)
I originally wanted to wait for pico-8 v0.1.1 to raise the code size limitations somewhat to finish the cart, but I'm not sure when I will have time to actually work on it again, so I just post it here as it is.
There are a couple of bugs (like stucking in the walls, or not ending the game when the fuel runs out), but it is quite playable anyway.
There is only one level, and no real end goal yet, but you can play it just for the highscore.
Who could make the most money? :)
I'm not a lua expert, so I can be totally mistaken on this - please correct me if so.
I can't see any reason why a variable should be global in pico-8... Defining as a local outside any functions, makes it accessible from that file (or module? or what is the correct lua terminology for this?) and since pico-8 only has one code file, that is essentially makes it global.
And as far as I know locals are way faster in lua than globals.
So I suggest just removing the keyword, and making everything local by default.
If there is a reason for globals, I would still ask for local-by-default, and suggest introducing a "global" keyword - just to save on the code size.
Again, I don't know much about the inner workings of lua/pico-8, so just ignore this if it doesn't make any sense. :)
Limitations always make me think about breaking them, and when last time I realized that you can “load()” cartridges while your program is running, that seemed something exploitable :)
So here is one way to circumvent the limitations somewhat: You can only fit one “fullscreen” picture in the gfx space in pico-8 - BUT the cartridge change and load is fast (at least compared to changing a physical cartridge :) ) so what if I put more pictures my program need in other cartridges, and load when I need?
Turns out it can be done. :)
Here is a demonstration: a “fullscreen” anim player. It reads the frames from the cartridges in the “frames” directory, and copies the contents to the screen.
It is not that fast as I hoped to be, but it is still useable. It plays an animation with no problem, and with some planning it should be useable for other purposes too (while something else is still happening on the screen, like a game for example :) )
As the screenshot shows: it consumes 96% of cpu time, but only in the frame when the load and refresh happens. (I refresh every third frame, that’s how the average is around 32% - two frames with zero cpu load, one with 96%).
In theory you could spread the cartridge load and the refresh to different frames, but unfortunately the load is not “silent” (it prints a message to the screen), and that scrolls/writes in the picture. I couldn’t come up with a way to hide that yet, but the separete load/update lowers the max cpu usage to 49.6% (the average is stays the same, because now we have one frame with zero, and two frames with roughly 49%).
But of course an animation player is really the stress test of this technique. Apart from… you now, actually playing animations (like intros or something) you don’t really need to refresh that fast probably, and loading data from other cartridges can be used a number of different ways: backgrounds for an adventure game or transition screens, or replacing the tileset for an another world in the game, etc.
I have the sample for you to download (I don't think it will work in the web player), but it seems that I can't post any links in this forum, so please go to my blog post on tumblr and download from there if you want to check it out: http://blog.ccatgames.com/post/118623662172/still-playing-with-pico-8-limitations-always-make
Neil (nknauth here in this forum) had this awesome idea to use my image importer to create custom covers for cartridges.
I myself wondered if one could use a cartridge cover other than a screenshot, but my best idea was “Probably at some point I should ask zep if he can enable using some other images. Maybe. Someday.” :)
But neil's idea is actually working. Needs a small amount of hacking though: simply loading an image, taking a screenshot, loading an another cartridge, and saving that cartridge by hand just produces a gray square on the cart instead of the image.
BUT using this code in the image loader works:
function _update()
if (btnp(4)) then
load(“road”)
end
if (btnp(5)) then
save(“road.png”)
end
end
function _draw()
cls()
sspr(0,0,127,127,0,0)
end
So the steps are:
- Create an “image cartridge” with the code above, but replacing “road” for the target cartridge name.
- Import the cover picture into this “image cartridge” by using the image importer from my previous post, or simply just drawing directly in Pico-8
- Run the “image cartridge”
- Press “z” to load the target cartridge.
- Press F7 to take a screenshot
- Press “X” to save the target cartridge.
Done! You have your own shiny custom cover Pico-8 cartridge! :)
After writing a small image converter for pomppo's 1-bit sprites I hacked together a color image "importer".
It reads a 128x128, 16 color image, and spits out something you can paste in a p8 file, in the gfx section.
The cartridge here just displays it.
I don't know if there is any point in doing this... a "fullscreen" 128x128 image takes up Pico-8's all gfx memory, so after that there are no more room for any sprites...
One use case would be importing a sprite sheet, so an artist can work in his/her favorite editor program, or something.
Anyway here is it.
It is a (really-really-really hacky) Processing program.
Just change the image name, run the sketch, and the data is copied to the clipboard (or if not, you can copy it from the console window).
Paste it over the gfx data in the p8 cartrigde file, and the sprites will be replaced by your picture.
import java.awt.;
import java.awt.event.;
import java.awt.datatransfer.;
import javax.swing.;
import java.io.*;
PImage img, dimg;
HashMap<Integer, String> converter;
void setup() {
img = loadImage("sonofman.png");
size(img.width, img.height);
dimg = createImage(img.width, img.height, RGB);
dimg.copy(img, 0, 0, img.width, img.height, 0, 0, img.width, img.height);
converter = new HashMap<Integer, String>();
converter.put(0xFE000000, "0");
converter.put(0xFE1C2A52, "1");
converter.put(0xFE7D2452, "2");
converter.put(0xFE008650, "3");
converter.put(0xFEAA5135, "4");
converter.put(0xFE5E564E, "5");
converter.put(0xFEC1C2C6, "6");
converter.put(0xFEFEF0E7, "7");
converter.put(0xFEFE004C, "8");
converter.put(0xFEFEA200, "9");
converter.put(0xFEFEFE26, "a");
converter.put(0xFE00E655, "b");
converter.put(0xFE28ACFE, "c");
converter.put(0xFE82759B, "d");
converter.put(0xFEFE76A7, "e");
converter.put(0xFEFECBA9, "f");
mousePressed();
}
void draw() {
image(dimg, 0, 0);
}
void mousePressed() {
String simg = "";
int counter = 0;
dimg.loadPixels();
for (int i = 0; i<dimg.pixels.length; i++) {
Integer s = dimg.pixels[i];
simg += converter.get(s);
//println("Got: "+hex(s)+" -> "+converter.get(s));
counter++;
if (counter==img.width) {
for (int o = counter; o<128; o++) {
simg += "0";
}
simg += "\n";
counter = 0;
}}
StringSelection data = new StringSelection(simg);
Clipboard clipboard = Toolkit.getDefaultToolkit().getSystemClipboard();
clipboard.setContents(data, data);
println(simg);
}
As I mentioned this is really hacky - the stupidest thing is that looks for exactly same colors, so it is a good idea to use the following palette.
This is a photoshop .act file, load as the color table of your indexed image.
0000 00ff ff27 fff1 e8ff ccaa ffa3 00ff
77a8 ff00 4dc2 c3c7 ab52 3683 769c 7e25
535f 574f 29ad ff1d 2b53 00e7 5600 8751
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0010 ffff
Two player Missile Commander clone. You can also play it in single player (just ignore the second cursor), but it will be harder.
Not quite finished, but playable.
Player 1 keys: Cursors + Z,X or N,M to launch missile from left/right silos
Player 2 keys: SDFE + tab,Q or shift, A to launch missile from left/right silos
In every level, you must survive 20 enemy missiles. At every new level, they got faster and faster...
For every 300 points you got two new missiles (one for the left, and one for the right silo).
How many levels can you survive?
(There is a bug, and sometimes the level won't completes... I'll fix it later.)
New version!
I added music and sound effects, starry background, more animations to the main menu, and a new enemy missile type: the cluster bomb.
There are still bugs left - it is more fun to work on new things, then fixing bugs. :)
I start to get running into size limitations - both code size, and memory during play...
Sooo... I was doodling around in pico-8, creating a game for #1GAM, and I needed to create some particle systems, so I started to code one, but carried away a bit, and made a general purpose particle system library... and then carried away a bit more, and made a couple of samples for it, and took the liberty to call it "advanced" :) and here is the end result. :)
Feel free to use it in your projects if you want!
A couple of remarks though:
- I don't know a lot about lua optimalizations, but I guess it is not really optimized for speed. :)
- It is quite big in its current form. I guess. This sample cartridge is hovering on the limits of code size, but the library part is way smaller, and more importantly, quite modular. I plan to look into minifying the code, if there are any interest.
- I don't even know if a "library" is viable concept in pico-8... The size limitations are quite severe, so you only want to include what you absolutely must in your code, which usually means hand-coding everything.
- Ohh, and it is quite possible contains bugs. Use at your own risk. :)
- There are documentation or explanation of the workings of any kind for now, but I will write some later. Just look at the code till then. :)
Is there a square root function somewhere in pico-8?
The lua sqrt doesn't seem to work, and there is no mention of such function in the docs either.
Or is there an easy way to calculate a unit vector?
