This is my first game, Wordstorm! It's based on the old Text Twist flash game-- the goal is to use a scrambled set of letters to find valid words. Each round, you need to make three 3-letter words, two 4-letter words, and one 5-letter word to increase your score and get a new set of letters. Use the arrow button to submit a word once you've spelled it out. Timed mode adds a one minute timer per round and lets you accumulate a persistent high score. Untimed mode lets you spend as much time as you'd like per round, but you can't get a high score.
Huge thankyou to zep's is_word_40k dictionary that allowed me to greatly increase the number of words used. The font is copied from Early Gameboy by Jimmy Campbell on Dafont.
Rain Maker
Oh, River... you really want to do this, huh? Well.. who am I to stop you... but, keep in mind, Becoming the new rain maker will not be easy.
Your name is River, you are a 19 year old trans girl looking to become the new rain maker and save your town's crops from drought and death, and the gem is right there, were the stories all false?
Exposition
This is my first go at a game like this!!! I've never worked on a game that required design and wasn't completely endless! I'm really looking for constructive criticism and code suggestions! I really wish to improve my code and my game design abilities!! The dungeon is completely the same every time as I didn't know the Pico8 could do procedural generation. :(
Feature Suggestion: Cart Forking and Collaboration
I wish there was a way to track when a cart from the BBS is improved or modded or altered, linking it back to the original in some way. This could function like a "fork," showing all variants and allowing users to see the evolution of a cart over time.
With this feature, we could collaboratively work on adding features and fixing bugs, even through small individual contributions. Over time, these efforts would add up, leading to polished and feature-rich games and software.
Isn’t that the beauty of open-sourcing carts? A system like this would make it easier for the community to come together and create something truly amazing!
Feature added:
- Added more shading on sprites
- Added "wasd" + "e" + "space" as optional keyboard control
Typically, when using an external editor, I do cp -f cart.p64 src
and then work on src
externally. Every time I make a change, I need to load src
before running. Then, I can put it back in the cart by doing cp -f src cart.p64
.
The suggested way of using external editors in the docs is to have the code externally, and simply include it from inside the cart. This will automatically use the latest external change, but it makes it harder to switch back to editing inside Picotron, as you need to change parts of your code to put everything back in the cart.
I made a quick utility to make loading an external folders easier.
extload
is a modified version of /system/util/load.lua
that loads a folder for external editing. It saves the path of the folder in /ram/extcart.pod
and loads extrunner
instead of the actual folder. (It also loads the workspaces from the folder, though this is a little janky.)
extrunner
is a dummy cart that cds into the external folder (from /ram/extcart.pod
), loads the graphics and sfx (by including /system/lib/resources.lua
), and runs it (by including main.lua
).
This is for anyone that didn't manage to find a solution or was too lazy to look at the Picotron Documentation (like me).
You can get the window size after the user resized the window with
get_display():width()
and
get_display():height()
, respectively.
To detect when the window is resized, you can use the following code by arnaught:
on_event("resize", function (msg) width = msg.width height = msg.height end) |
Another solution would be to constantly compare a variable to the current screen width and height. From my experience, this is a better solution performance-wise, but you can try both options and see which fits best for your purposes.
function _update() if height != get_display():height() or width != get_display():width() then height = get_display():height() width = get_display():width() [ [size=16][color=#ffaabb] [ Continue Reading.. ] [/color][/size] ](/bbs/?pid=160517#p) |
Hello all! I am new to Pico-8 and emulation as a whole. I recently got a RG35XXSP and bought Pico-8. I moved over the files people told me to, changed the core to Pico-8, and even got a game to run, but Splore isn't popping up in the Pico-8 directory. All the videos I saw, the second they got out of a game, Splore would populate the directory and they could use it but it's not working for me. Am I missing something?
Also sorry if this isn't the right category for this. I'm in a hurry to post something so I can sleep for work.
i wanna get back into gamedev sometime this year, or at least try to, and this little thing seems the perfect way to start that journey.
unfortunately i dont know how to change my username, so this accounts name will forever reflect a 12 year old pipo, one with foolish ambitions and thought they wouldnt be a girl in the future lol
this is just me yammering. i wont post much and its unlikely anyone will see this but, sometimes its nice to talk out in the void
PICROID is a procedurally generated metroidvania-inspired platformer.
Each playthrough offers a unique map, where your goal is to explore and survive as long as possible without shrinking to death.
There are no enemies or boss fights—just pure exploration and challenge.
This is a beta version, and the game is still a work in progress. Feedback and suggestions are greatly appreciated!
Controls
If you're curious about how the map generation works or want to edit rooms in the sprite editor, let me know.
Changelog:
- Beta 0.6: New game mechanic: coins & shop | Improved gates | Level design is slightly easier | misc bug fixes
- Alpha 0.5: Fixed health restoring minor bug
- Alpha 0.4: New levels change color, fixed a wall jump glitch
- Alpha 0.3: Fixed top collision minor bug
I made a simple ini parsing/dumping function. load_ini()
converts an ini string to a table, and dump_ini()
converts a lua table to an ini string.
This could be useful for projects that have a configuration file. Using an ini might be better for user configs since ini supports comments.
The ini format is simple. Section headings are marked with [section]
and items are stored as key=value
. Subsections are separated with a dot. Inline comments are not supported, but comments at the start of the line are.
Strings don't have to be quoted, but you should quote them.
Example:
[heading] a=1 b=2 [heading.sub] c="hello" d="world" [heading.array] 1=4 2=5 3=6 |
This will convert to:
{ heading = { a = 1, b = 2, sub = { c = "hello", d = "world" }, array = { 4, 5, 6 } } } |
With the way I wrote it, it can handle anything that can be parsed with unpod()
. This may be useful for writing some things (such as arrays) more compactly. The following is equivalent to the above example:
[heading] [ [size=16][color=#ffaabb] [ Continue Reading.. ] [/color][/size] ](/bbs/?pid=160480#p) |
Nin Demo V1
A demo for an action-platformer I have been working on. It has about 14 levels done so far with a planned 32. Any feedback is much appreciated as I still have a lot of work to do on the game. There are level numbers in the top left corner if you have any feedback for a specific screen.
Enjoy!
This is a trash manager for Picotron that loosely follows the XDG Trash Specification. You can use it to delete and and later restore files from trash.
Full usage instructions are in the README (also available from "Help" inside the cart), but basically you can drag/drop files to move them to trash. Left click a file in trash to restore it, right click a file in trash to permanently delete it.
You can also use Trash Manager as a CLI utility.
trash [files]
to move files to trash
trash --list [search]
or trash --search [search]
to list/search trash
trash --restore [files]
trash --restore-all
to restore all files
Elevator in my raycaster FPS Dark Streets. Pushing the button simply teleports the player to an identical-looking elevator on another "floor" (somewhere else on the map), but since the player has to face the button, they cannot see the sudden change. Adding a little shake and a ding contributes to the illusion.
This Lua script is designed to copy files from a directory in /appdata/system/lib to the corresponding destination in /system/lib. The key functionality of this script allows the user to modify the system libraries (e.g., gui_ed.lua in this case) in /appdata/system/lib and have those modified versions persist even after a reboot.
Key Features:
Directory Syncing:
The script checks for files in the /appdata/system/lib directory.
It copies each file to the matching location in /system/lib based on the filenames. For example, if gui_ed.lua is modified in /appdata/system/lib, it will be copied to /system/lib/gui_ed.lua replacing the original.
Persistence of Edits:
Any changes made to files in /appdata/system/lib will persist after reboot, ensuring that the customized libraries remain intact and are used when the system restarts.
Works with Any /system Directory:
The script can be adapted to copy files from any directory within /appdata/system to the equivalent directory in /system, not just /lib. It can be used to update any files in the /system/ directories by making minor changes.