Jump to content
IGNORED

PICO-8 development


TehStu
 Share

Recommended Posts

On 11/01/2022 at 15:25, bradigor said:

Hope you can get it properly working (with a dark mode ;) ) as will be all over that on my RG351

Oh I'll absolutely put a dark mode in there if you need it, it'll be handy to learn how to do options and persistent storage on the cart. I could use some help on the color palette too, eventually. Something high contrast in both light/dark modes.

 

I've been under the weather all week so no coding, but I'm at the point where I need to flowchart out how to work out the silly yellow tiles. I fixed my bug in the gif, but that was a minor issue compared to how you handle yellow tiles. If nothing else, it's helped me learn how to branch in git!

Link to comment
Share on other sites

  • 2 weeks later...

I spent two weeks noodling how to do the damn yellow tiles in wordle. After pages of notes and flowing out test cases in Excel, it finally came to me. By which time, I found working in the painfully limited code editor of PICO-8, well, painful. Had to fire up VScode, find a PICO extension for syntax highlighting, and refactored all my code to be up to 80 chars wide.

 

Now I can actually follow what I wrote :lol:. Anyway, have written it, introduced some new bugs, but I'm so close I can taste it. Then we'll spit and polish this thing into a game.

 

Public service announcement: when PICO throws an unclosed function error at line X, the error is AFTER line X, not before. You've got a missing END in the function. Sigh.

Link to comment
Share on other sites

ling8_0.png.50ad67c2e1bef3c44030dcfc1aca3700.png

 

anakin.gif

 

One more obvious bug left - the order in which the colors are applied to the keys means that if you guessed (say, using TIGER as the word) E twice and one was correct, it would render E in grey because the order of operations means "letter not present" is the "else". I think I have to render them as "not present", "present but incorrect position", and then "correct" to make sure green goes last, as it's the most important.

 

Assuming that was the last functional bug, I need to then:

- add a proper gaming loop

- add persistent cart data

- add a proper dictionary other than TIGER, which is the only word

- enforce that guesses need to be in the dictionary (left last so I can do nonsense words for debugging)

Link to comment
Share on other sites

21 minutes ago, Skykid said:

 

Do you know about the token limit for carts?

Yeah, I figured I'd get it all working and squeeze in as many words as I can. Just an array of strings, unless there's a more efficient way to do it? I think I'm at about 1400/8192 ish, with the current code.

Link to comment
Share on other sites

I've only played around with small PICO-8 projects so I've not smashed up against the token limit. Seems to be one per string, but I can't find a limit on string length.

 

Looks like Wordle has 2,500 'guessable' words out of 12,000,so you should be able to get a very decent chunk of those into the 65536 character limit. And if not, you can add decompression to that task list :D

 

Link to comment
Share on other sites

I had an idea this morning - keep all the word data in external carts and randomize the #include to pull in different sets during cart initialization. Alas, you need to #include before you start executing code, unless I'm doing something wrong. Therefore I don't know how I'd randomize which data cart to #include, unless some external mechanism is renaming the cart. That's not going to help pico8 carts distributed on devices or built for html/js publishing, though.

 

However, just did some experimentation. Right now I'm using 1105/8192 tokens, pasting my code from the lua file into the PICO8 code editor. Every word I add uses 4 tokens, using the add(T,"TIGER") method of plonking it my dictionary. Guessing another 500 tokens of cleaning up the game into a repeatably playable state, I've got a super approximate dictionary size of 1,500 ish words. That feels OK. This is without shrinking the code, getting rid of comments, etc.

 

I could publish different versions which link to different word carts if people are really keen. Or I should say if Brad is keen :)

 

 

Link to comment
Share on other sites

22 hours ago, TehStu said:

ling8_0.png.50ad67c2e1bef3c44030dcfc1aca3700.png

 

anakin.gif

 

One more obvious bug left - the order in which the colors are applied to the keys means that if you guessed (say, using TIGER as the word) E twice and one was correct, it would render E in grey because the order of operations means "letter not present" is the "else". I think I have to render them as "not present", "present but incorrect position", and then "correct" to make sure green goes last, as it's the most important.

 

Assuming that was the last functional bug, I need to then:

- add a proper gaming loop

- add persistent cart data

- add a proper dictionary other than TIGER, which is the only word

- enforce that guesses need to be in the dictionary (left last so I can do nonsense words for debugging)

That is awesome. :D

 

Link to comment
Share on other sites

On 24/01/2022 at 15:18, TehStu said:

One more obvious bug left - the order in which the colors are applied to the keys means that if you guessed (say, using TIGER as the word) E twice and one was correct, it would render E in grey because the order of operations means "letter not present" is the "else". I think I have to render them as "not present", "present but incorrect position", and then "correct" to make sure green goes last, as it's the most important.

 

Got this fixed. Previously I wasn't tracking the status of keys, I was just updating their color values. Now I track the status, which mirrors how I've had to do it for the guess and grid. So when drawing the keyboard, it now does a "state" lookup to the color palette, like the grid does. Anyway:

 

ling8_1.png.595dc38b6bb4922fa7c67ca5dd6d694f.png

 

  1. On turn 1 I had a single T and the keyboard correctly rendered that yellow
  2. On turn 2, I had two Ts but the last T didn't overwrite the keyboard with grey (for second T = not present), which it was doing previously
  3. On turn 3, T is correct and again the second T present doesn't overwrite this (this is what the keyboard shows now)

 

Before, it would whip through all 5 letters of the guess and keep updating the key color, causing incorrect colors. Now there's a state check to make sure "no" doesn't overwrite a "yes", if you see what I mean.

 

Anyway, in doing this I spotted a bunch of other inconsistencies, which I think I'm going to refactor before going further. It's amazing how such a short program can be all over the place when you don't plan it out. The next time I do this, I'm going to do a very high level flow chart of what the program needs to be, instead of focusing on what's interesting (I literally started this project the keyboard rendering, :lol:).

 

Also in my list of TODOs is add multiple palettes, so I can get a high contrast and night modes going. I was looking over it earlier and realized I didn't think ahead to that, although I thought I did. I just have a single table with the palette, whereas I needed an array of tables.

Link to comment
Share on other sites

  • 1 month later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Use of this website is subject to our Privacy Policy, Terms of Use, and Guidelines.