Minor changes. The game will be used for a pico-8 course.
First experience with the Pico-8!
A try to clone the original Pooyan.
Made in 2 h.
This is just the basic behavior. You can fire arrows with C. No collisions for now.
By the way, I'm a professional game maker.
Pico-8 is the best experience I ever had coding since the Amstrad CPC and the Amiga...

I was talking with zep on twitter about a possible Nspire CX (graphing calculator) port, but he said the hardware isn't powerful enough. What are the requirements? I would think that ~130 MHz would be plenty for a lua interpreter + extras. Even if an Nspire port is impossible, it'd be totally possible to get it running on an OpenPandora console. It's got a full querty keyboard, 1 GHz ARM CPU, and 512 MB of RAM. Any other platforms that it would be fun to have a port on?
If you want to be able to change text color halfway through without splitting into multiple commands, here's just that at a price of 150 tokens / 265 compressed chars.
So doing
printc("hello ^8world^7!", 4, 4)
will output
Could have been a bit smaller if there were functions to convert string to/from charcode.
Hi,
In order to challenge myself a bit, I decided to create a game in PICO based on the ideas you reply to this post.
Please answer the following questions :
What would be the theme ?
What should the primary weapon be ?
What would we have to fight ?
What do you think is a good objective ?
The answers doesn't have to be related to each other, in fact it would be interesting to create a completely absurd mix.
Thanks in advance

(updated build with music fix provided by krickit)
A hardcore platformer by Matt Thorson and Noel Berry (me), that we made in 4 days.
We used pretty much all our resources for this. 8186/8192 code, the entire spritemap, the entire map, and 63/64 sounds.
Let us know what you think! :)

Hope you enjoy.
TODO:
- Enemy AI so one person can play.
- Sounds and music!
-
Fix the patch of trail missing when turning (this is due to the the bike being shifted slightly when turning, to prevent hitting the trail if you turn 90 degrees whilst skimming the edge of a trail)
- Explosions upon death, partly implemented but currently commented out.
- Adjust the lifetime of the trails, potentially make them permanent, but I thought the map was too small for this.
- Any other suggestions!

Hey! There seem to be a few bugs when editing the bottom half of the map. I've noticed when moving tiles with the selection tool the changes are not reflected in-game or in the spritemap-data unless you hit CTRL+Z once.
Here's a gif of it in action
test = {}
add(test, {})
print(#test) -- 1
print(count(test)) -- 1
test[1] = nil
print(count(test)) -- 0
print(#test) -- 1
|
are you maintaining some other method of counting the objects in tables other than counting until you hit nil (I am guessing the answer is yes)? If so, is it faster to use COUNT than #?

I am making a song in pico-8 that has a section with 3/4 time. How do I do that with the pico-8 tracker? I think you would do it in Milkytracker by changing the length of the pattern. I could just have each pattern contain three beats of one measure and one beat from the next measure, but that's kind of messy and would cause a lot of redundant notes. Could I use Lua programming and the sfx api to hack around the tracker? Is there a chance we could have a feature to change the length of patterns (or at least to make them shorter)?

I've been working on a cartridge in Voxatron for a decent amount of time now and have become very adept and understanding of how player/monster creation, logic, and modifiers work... But! I've hit a dead end...
No matter how I try it, I can't get the logic for my player to work right. After many days of working at it, it seems that the only way to make it work is if you added a special determining factor to triggers...
That factor would simply be: Only activate (under trigger circumstances) after prior trigger is activated.
If that didn't make sense...(I had a hard time putting it in words concisely) What I want is when, say, modifier#1 is set to have modifier#2 happen next, modifier#2 will happen next, but only if modifier#2's trigger activates and will only activate if modifier#1 was triggered first.
I hope that makes sense! :( I'm trying to keep most of what I'm doing under the hood right now so if you have a contact I can message you through privately I can show you exactly what I'm doing/trying to do and more specifically what I need to make it work!
Hopeful that you'll see this and understand what I mean,
RumbleChops.
P.S. Thanks for the like on one of my Speed-Modeling videos! I hope to show you all some of the fruits of my labor soon! :)





6 comments









