PICO-8 + Nature of Code + ECS = piconoc.
Emergent ecosystem behaviors for agents in Pico-8. Based on Daniel Schiffman's "Nature of Code". Uses Entity Component Systems.
***UPDATE: 100% more player control of frog with arrow keys. Frog also eats nearby flies.
Hi! I want to simulate flies and frogs and lizards and spaceships and such in PICO-8. And I want to do so in ways that give surprising results. PLUS I want to refine my understanding of Entity Component Systems (ECS). This cart holds my efforts to do all those things.
Critters should be recognizable by their behaviors, not the graphics and/or sounds.
This is a very early learning project in process.
More details and source code;
https://github.com/camerongoble/piconoc
Critters in progress:
- flies (implemented!)
- frogs (implemented!)
- rabbits
- snakes
- cows?
- aliens?
- Cthulhu?
When a fly hits the borders, it makes a "blatt" sound. Because flies make annoying sounds in real life. So authentic!
The framework will ideally make it possible to simply add data without lots of customized functions for each critter's particular behavior. I'm not there yet. But I'm getting there.
5 comments
Help your pet time traveler pilot his way to the next planet in an endless journey of excitement and discovery! But watch out! The ship is a bit tricky to handle.
UDLR arrows maneuver your traveler around the central console. Look for X and O hints to operate the ship. Be quick! When flying a time machine, Time is against you.
This is one of several mini games that will be a part of the whole cartridge. Working from a minimalist Tomagotchi style of game play with an LCD aesthetic.
I hope for feedback on general snappiness and sense of hurried panic. Any critique and/or enthusiasm also welcome :)
PLEASE NOTE: The minigame starts immediately. The only way for the minigame to end is with a "ding" when you reach the destination planet. This marks a successful journey. There is no failure state implemented yet, but there will be a suitable "you lose" screen when the console is completely destroyed.
Okay, so, interesting bug/feature: print("^a") with just the beep and not the text introduces a new line at the last cursor point.
If this is the first print() in the game, and if x/y coordinates are not specified, the new line will insert at the bottom of the screen and force the screen to scroll, potentially disrupting previously drawn graphics.
In the game of the attached screenshot, the blue case and UPLR button are drawn first, then a beep via print("^a"), then the "Vortex" in the next print(). Note the scrolling of the lower buttons by one character height.
Specifying x/y coords prevents this corruption from happening, e.g.: print("\^a", 0, -20).
The expected behavior was that since the print() was called with only a beep code and no text, it would not force a new line.
A solution might be to check if pixel width of a print equals zero, and if so, to prevent the new line at the end of the print.
Using .12c.
If "#include file.p8" is preceded by whitespace, it will result in a syntax error: unexpected symbol near #.
#include my_stuff.p8 <- works #include my_stuff.p8 <- doesn't work |
This makes it difficult to embed #includes into "function() end" blocks without disrupting indention for readability.
Perhaps the "#" character is being called upon to do just a little too much work? Maybe "@" for compiler directives would be a better choice.
