The fastest guns in the west have got the shakes!
High Noon (H I G H N O O N) is sort of a mutant of the classic "who can hit a button the fastest" cowboy duel game.
Instead of just pressing the button you must release the button when the white line is in the green line in a powerbar thingy.
- press and hold either X or O,
- release when the white line is in the green bar
- the green bar gets bigger each time you hit the top of the power bar
- games go until someone gets 6 points.
- if you draw before the signal you lose one point
- if you miss the green bar, you miss your shot and you become a sitting duck
- the computer player needs serious work but 2 player should work fine (let me know if it doesnt)
- computer player gets more accurate the higher your score
- cheesy looking tumble weeds included
originally this game was just a basic "who can hit the button fastest" type game but in changing it i have broken that functionality but plan on re-adding it, so the menu will have the option to select "simple mode"~
theres normal hit the button mode again. Some minor improvement to the CPU but this is still mostly designed to be played on a couch with another human while intoxicated
oh and you can customize your cowpokes outfit now and it will be saved to cart data

(v01 11-07-22)
TO LOAD THIS PICO-8 CART, in immediate mode, type:
load #mazechallenge
VVhat's new? (11-07-22)
- Fixed blocks so no part of map is missed now. (Please confirm this !)
- Pressing ❎ now has 3-modes. 1, 2, and 3.
- Made maze darker so it is easier to see the player.
- 3rd mode after fill now shows path as darker color of the blocks.
- Greatly sped up fill routine.
- Added notice on end on how to restart.
- Shrank code size slightly.
Hello there.
This is really more of an experiment that I think got way out of hand.
The premise is simple. With all of the tile-generating code out there, I wanted to see if it was possible to make a "maze-like" environment with no 100% straight corridors and using only 4- 8x8 tiles and placed randomly on the board. AND make it so that every point can be reached no matter the arrangement and that it is not a "cake walk" to do so - and there are no hard diagonal lines.

I'm working on a game using procedural generation and although the game is nowhere near done I thought the generation technique itself was interesting enough on its own to post about.
Rather than try to explain it myself I'll just send you to someone who already has, better than I likely could. BorisTheBrave: Graph Rewriting for Procedural Level Generation
Instead, I'll just share some of my initial results. The general idea is to generate the "big picture" details first and then successively refine them to build a fleshed out so the levels generated here are shown at 1/8 scale. Eventually every pixel in these maps will expand to be one tile at full scale with additional generation filling in the fine details along the way.
Hey so I was just doing some map work and I was using the cmd+x to move tiles around and I think when I was cutting and pasting somewhere else in the mapview tiles in the shared space it would move the sprites but not the map tiles which was . . . not good and took a while to make sure everything was ok.
It feels like this isn't intentional but I'm not 100%? I'm on 0.2.5c, thanks in advance!
(Like I said maybe this is on purpose since I'm moving the data it's self around in the shared space but in my game I was making I'm using the shared space for sprites and map and it makes it more difficult.)


Controls
- ⬆️ Walk
- ⬅️➡️ Turn left/right
- ⬇️ Toggle basic HUD
- ❎ [X] Hold for full HUD and ⬅️⬆️➡️⬇️ to inspect the surroundings
- ⓩ [Z] Open Inventory/Actions menu
How to play
You initially can't do much -except gathering fruits- more items and actions will be unlocked as you progress in the game.
So just explore the islands and:
- talk to the stone statue/head
- walk under palm-trees to gather a couple fruits if any
Here be Dragons
The writing "Here be Dragons" at the edge of the map means you can't walk farther at that moment:
the game map is initially just a small portion of the full map, next areas will be unlocked by defeating the enemy creatures, just report your success to the statue (Kahuna).

A few days back @dw817 posted a thread about the number of possible combinations in 256 bytes in which they asked:
> Is there a way to calculate 256^256 ?
And knowing there are all sorts of tools and languages which can handle such huge numbers I cheekily posted the answer and caused a bit of a derail.
Anyway, I had some time on my hands so I figured I'd implement large number support for Pico-8.
Edit: Fixed a bug in divide()
Is this likely to be of use to anybody? Probably not. Is it major overkill? You betcha! Though in fairness, at 706 tokens it came out smaller than I was expecting.
Features/Functions
-
bignum(n): Create a 'bignum' with valuenwhich is just a regular Pico-8 number. Most operations require both numbers to be bignums. Sobignum(16000)*bignum(1254)but notbignum(16000)*1254.bignum()is equivalent tobignum(0) -
divide(bn): You can use the division and mod operators (/, %) on bignums if you only need one or the other. Thedividefunction returns both the quotient and remainder at once.q, r = divide(bignum(3)^16, bignum(2)^15) show(bn): Converts a bignum into its decimal representation as a string.factorial(n): Calculates the factorial ofnand returns the result as a bignum. Factorials get very big, very fast so the input tofactorialis just a regular number.+ - / % ^: Arithmetic operators behave how you would expect. All require both arguments to be bignums with the exception of^where only the first argument is a bignum and the second is a regular number. Division is integer division only sobignum(3)/bignum(4)==bignum(0).> >= <= < ==: Comparisons similarly require both arguments to be bignums.
Issues
- The arithmetic operators are all fairly efficent but probably not optimally so.
- I wasn't taking negative numbers into account at all so I make no promises about what will happen if you try to use them. Maybe it will work! (It probably won't work.)
showis extremely inefficient. I'm sure there are better ways to convert very long binary strings to decimal but I'm not familiar with them so this is what I've got. Large numbers (like 52!) may take a bit of time and very large numbers will crash the program as it runs out of memory. (bignum(256)^256 does this, sadly. It calculates the number fine but crashes when you try to convert it.)

A quick and dirty Sudoku solver, may or may not work.
Not sure if there any use-case for such a tool on PICO-8, but here it is.
⚠️ Looking a the source code may or may not induce permanent blindness ⚠️
Controls :
⬆️⬇️⬅️➡️ : move the cursor.
❎ : select a cell/value.
[1️-9️] : fill cell with the corresponding digit if possible.
Pause : access menu.
changelog
2022-11-06:
- added a solve cell option.

Hello.
I use RND() quite a bit, don't you ?
I have noticed in other game programming languages that you can have a 2nd argument for the rnd() command. Currently Pico-8 does not do this. It's quite useful though. Here's an example:
a=rnd(1,10) |
Will for instance choose an integer random number between and including 1 through 10. This:
a=rnd(10,1) |
Will give the same results. This however:
a=rnd(-4,4) |
Will give you a random integer number between and including -4 to 4.
The function of which:
function rndrange(a,b) if (a>b) a,b=b,a return a+rnd(b-a+1)\1 end |
How about it guys and @zep, do you think this is a good addition for Pico-8, to add a 2nd argument to already existing rnd() function ? Or a new function altogether, rrnd() for Range Random.

A game created during a 6-days sprint by 3 software developers in training !
Check out our feminist and inclusive coding school in Paris : Ada Tech School https://adatechschool.fr/
Your goal : find the key to escape this haunted house.
Beware of the zombies... and hurry : you only have 40 seconds to get out !






6 comments









.png)








