Your Pico-8 just got a big graphics upgrade
With game graphics drawn "from the limitless imagery of your imagination" (according to an old Infocom advertisement), a world of classic text adventures is now playable on the Pico-8.
Status Line implements the z-machine v3/v4 specifications, allowing you to play .z3 and .z4 text adventures like Zork, Hitchhiker's Guide to the Galaxy, Trinity, A Mind Forever Voyaging and more. There are those who continue to keep the Infocom flame alive, and their games will work as well.
Features
- Can play every game in the "z3" and "z4" format
- Custom font with multi-font display, includes mixed plain/bold/italic
- Supports game sizes up to 256K
- Supports simple sound effects (used by many z4 games)
- Save/restore games in progress
- Multiple color themes to recreate a "classic feel"
- Player-selectable text scroll speed
- Player-selectable cursor style, because why not
- Choose 24 or 12-hour clock for time-based games
Status Line Available Now at itch.io
Details, where to find games to play, future work, etc. can be found on the project page at https://christopherdrum.itch.io/statusline.
Source code now on github: https://github.com/ChristopherDrum/status-line
Special Feature: Status Line Classics
I've modified a handful of original Infocom games, from original source code, to look and play great on the Pico-8. Lots of UX changes, text layout/formatting changes, etc. to accomodate the Pico-8's tiny, cozy screen. Source and playable .z4 files are available at github: https://github.com/ChristopherDrum/status-line-classics
Update - v2.0 Released (Mar. 22, 2022)
This update adds .z4 game support, multi-font display, better core engine, slightly faster core performance, more compact input cursor, some deep bug fixes, and more. Status Line Classics v1.0 is released in conjunction with this update to give the Pico-8 community best-in-class adaptations of Infocom classics for our beloved machine. Extended notes and full changelog are here:
https://christopherdrum.itch.io/statusline/devlog/349264/status-line-v20-released-z4-support-multi-font-display-custom-infocom-classics-and-the-resurrection-of-bureaucracy
Update - v1.2 Released (Feb. 13, 2022)
This update focuses on lowering memory usage, general performance improvements, and improved text layout handling. This puts the project in good shape for z4 game support in the near future. Write-up of the changes and the full changelog are here:
https://christopherdrum.itch.io/statusline/devlog/343409/status-line-v12-released
Update - v1.1 Released
v1.1 was uploaded today to the product page on itch.io. Most changes handle various typographic inconsistencies and strive to give a more clean, consistent presentation. Additional color schemes, player-selectable cursor style, and more are also added. Write-up of the changes and the full changelog are here:
https://christopherdrum.itch.io/statusline/devlog/330128/status-line-11-released
If you're going to run it online for cellphones, @ChristopherD, typing is going to be a problem as the standard keyboard for Android does not appear.
Yet I definitely look forward to seeing how you are going to handle this.
There have been a few ambitious coders who have written text adventures for the Gameboy and even the Atari 2600.
You might be interested in a program I wrote years ago to circumvent the input problem to your Z3 interpreter:
@dw817 This isn't a text adventure. It is an engine for running existing adventures in the .z3 format. It doesn't run on cellphones and I don't even make it available for that. You don't have to "look forward to seeing how" because it is alive and on itch.io right this second.
Huge congrats! I got Zork I working just fine, running in PICO-8 directly using the source distro. A full interpreter in just 6230 tokens!
Are you interested in bug reports for other carts? HHGTTG asserts out: "asked to retrieve local var 16" (I imagine you have plenty to test with.)
Stellar use of stat(120), too!
@dddaaannn Thanks!
Ah crud... well, I appreciate the bug report! I played a bunch of games start to finish before posting, but somehow didn't think to try HHGTTG :/
I'll definitely take a look and see what I can see.
I could see it's an engine and requires a real keyboard.
(Adjusted) At the bottom of this page, not at the top, you can find multiple versions of the game that started it all, "Zork I." Pick the latest version.
https://github.com/the-infocom-files/zork1
Or download it direct here:
https://eblong.com/infocom/gamefiles/zork1-r119-s880429.z3
My initial tests for "status_line.exe" including commands of SAVE and RESTORE show it to work fine.
I'm more interested in carts that run directly through Splore and Lexaloffle though. Best wishes !
The HHG I have on my hard drive is release 31 serial number 871119, which is one of the newer "gold" releases with hints and footnotes. It probably pushes the z3 standard a bit. I don't have older versions lying around to compare, but I'm sure they're findable.
@dddaaannn "gold" release MIGHT have been bumped up to z4 or z5, IIRC... lemmee look into it. All Infocom games are up on GitHub now (source and compiled z3,4,5,6,etc... files) Link is on the itch.io page, but you can just go to https://github.com/the-infocom-files
@dddaaannn
According to the definitive release list, there was a z5 version published, but I'm unclear if that is the "gold" version or not
https://eblong.com/infocom/#hitchhiker
Update: I grabbed the .z5 version and encountered exactly the bug you reported. I suspect there is no problem with the games I currently support (i.e. z3 only) The z5 file is "hitchhiker-invclues-r31-s871119.z5" which matches your reported release # and date. Bullet dodged!
Cool beans! My file is probably just incorrectly named .z3. The assert that was tripping does indicate a limit that was raised for later versions.
wow ...thank you so much that is beautiful and .... i love zork and everything witch is related to it...... i played it on my raspberry it works fine.... great:-)....
then i got an idea i made a little cyberdeck years ago with a spi screen and run the bare version of pico on it .... but in this mode i don't have mouse ore any window manager....
so my question is is it possible to load a cart as default like make a game.z3 in the same folder and it starts automatically???? that would be awesome.
i'm no god programmer i hunt the load operation down to the memory.lua file and the "load_story_file()" function but i see it reads the file to an address and that is all i get...(and maybe even this is wrong)...
can you ore somebody help me with this it would be awesome to play zork on the train....
if not no problem im very happy with this. thank you again for your work
(and sorry for my bad english)
This is super neat, I gotta give this a shot. One of those ideas that seems so obvious once you see it ... and once it's been demonstrated to be possible. Hard to believe this fits in the token limit!
@rmueglitz Unfortunately the Pico-8 APIs do not allow us to load in any arbitrary file. What we can do is load in data from other cartridges. However, each cartridge can only store 16KB of data. For reference, Zork is 85KB.
So, what could be done is to split a .z3 file into 16KB chunks and store those chunks onto a stack of .p8 cartridges. Those could be auto-loaded via the reload() command at startup... theoretically. It is actually something I'm considering in the future for people who want to self-publish standalone versions of their new .z3 games with Status Line as the engine behind the scenes.
But I have a lot more to do before getting to that. So, for now, if you can figure out how to do it, you're more than welcome to hack at it! Official support for something like that is quite a bit later in my personal development schedule.
@luchak I actually have about 2000 tokens free, which is good for me since I still have a lot to do to support z4 and z5 gamaes.
cool i have it laying around so it remembers me. il try to figure something out
thanks for the hint...good luck with your progress i'm looking forward to it...thanks
@rmueglitz Oh, I forgot to mention also that save/reload will need to be modified to use cstore() and reload() as well. Again, the save data has to be broken up into 16KB chunks, each one saved to a .p8 file. That group of .p8 files then holds one save game. Then the prompt to load a game would have to be reworked to ask for a save game name and load in all 16KB chunks sequentially from the previous save files. Working around Pico-8's file system limitations isn't "hard" but definitely a pain for projects like this.
Hey, just curious: Why not release this here as a pngcart if you make the source code available anyway? I always thought people released on itch.io to keep the code private, but obviously there are other considerations.
@TBMcQueen, this cannot run in Lexaloffle because it requires special external LUA programs, functions, and procedures.
You can, however, download the sourcecode graciously provided by @ChristopherD found HERE:
More to the point, #included files remain external when a game is exported, which I did not realize.
@TBMcQueen There are a couple of reasons I didn't release as a pngcart here. First, as you noted, the #included files didn't export with the .png. I could stitch that all together manually for an export, but it was kind of a drag. I recall that export worked in a previous version (I used it for PicoCalc, IIRC), but it ain't working for me these days, so :shrug_emoji:
However, more to the point, posting a png cart would run it in the embedded web browser. I think it also adds it to Splore, but I'm unclear about that. This would cause quite a lot of confusion, because it relies on Pico-8's serial() and extcmd("folder") to enable drag-and-drop. That is an absolute requirement to use this program. Drag-and-drop isn't available to the web experience (although maybe there's a hacky way to make it work?)
So, to eliminate all of the "Why doesn't this program work?" (trying to run on the web, or a handheld that doesn't allow drag-and-drop/keyboard input) I chose to limit the usage to "only people running Pico-8 on the deskop". Not posting it as a .png seems to me the most straightforward way to do that, and I also like having download stats consolidated.
@dw817 That is not true. This program uses nothing but built-in Pico-8 functions. There are no "special external Lua programs" in use; it is pure Pico-8 Lua, nothing more. The #included .lua files are only to help me mentally separate code into manageable portions based on the z-machine specification.
Well now @ChristopherD, I tried running your program, just the P8 by itself, and it does not accept files. Nor does it run as a P8.PNG if you do not include the LUA files.
Updated 01-08-22
Find the project working HERE:
https://christopherdrum.itch.io/statusline
So, no the extra LUA files you've included are required - if you run it in immediate mode.
--#include memory.lua --#include ops.lua --#include io.lua |
I'm not knocking your work, it's quite good, it just won't run in Lexaloffle without including your extra LUA files - and at the moment there is no way to do this for Lexaloffle.
That is a limitation of Lexaloffle, not you.
I touched on this briefly years ago myself.
@dw817 I never said the #includes aren't integral the program, I took issue with your phrasing that they are "special external Lua programs" because that makes it sound like I did something different than just "normal Pico-8 development." They're not "special," they're just normal #includes like any other long program. I was trying to distinguish your phrasing from the reality of what those files do; they exist solely to help me organize the code. Removing 3/4 of the code and saying "it doesn't work" just confuses the issue, I feel. I didn't think this needed to be said explicitly.
The code from the #includes can be copy/pasted as-is into the .p8 file and will work fine locally, but NOT ON Lexaloffle because of the limitations on serial() in the HTML runner. That has nothing at all to do with breaking a long program up into smaller .lua files. Posting any .p8.png file of this program here is pointless because it will never work without changes to serial() in the HTML environment, and so I didn't.
The smallest of clarifications: "save foo.p8.png" interpolates #include statements, and Status Line saved in this way works great. "export foo.p8.png" does not interpolate #include statements. Kinda weird to have that option at all—IMO only .p8 files should support #include—but even weirder that only the export version is available headless on the command line (via -export). So getting the fully interpolated .p8.png still requires a manual step, but is possible without copy-pasting. Regardless, I agree that without HTML support for file drag-and-drop, posting it to the BBS might be confusing.
That's all very off topic for a thread that should be about praise for this amazing cart. :)
@dddaaannn save not export Aha, got it. I don't think I was clear about the differences or which to use. Good to know. I'm working on v1.2 and I'll re-try a proper .p8.png export when that's done (rather than the "zip up the source files" option I've been doing so far)
@dw817 Can you please take that fikukupide cart down? It is showing up in the carts list. I don't think it is good to have a known broken cart there, and it makes my project look broken.
Sure thing, @ChristopherD. And no your project is not broken, in many ways it's ahead of its time, Lexaloffle is just not ready for it. And no your .LUA files are not normal, at least not to Pico-8, they are special.
For instance you are making use of a command that would not run in Pico-8 by itself called, "set_var."
This command is native to LUA, but not to Pico-8. So you could not have written this engine without using commands native to LUA that are not native to Pico-8. Likely there are other commands you wrote in your LUA that do not run on their own in Pico-8.
Now once #INCLUDE LUAs can be flattened properly inside a Lexaloffle PNG or @CLIP, hopefully in the next Pico-8 release or so by @zep, then other coders might start to explore the advanced command set of LUA, as you have, with the knowledge they will run correctly in Lexaloffle.
Reading the source though, set_var is implemented by OP in memory.lua, it's not using a Lua native function of that name and the code in the function is all PICO-8 valid so far as I can see.
@dddaaannn That's fascinating that save/export work differently like that. Cool, though: Now I have a smart-looking png for my collection.
@dw817 I believe we've established at this point that this CAN all be flattened, and it runs fine. (on desktop, I should say; obviously it would still be useless embedded in the site).
As for the command, @2bitchuck. Well, I thought I found a native LUA command. :) Clearly the LUA codes are there for a reason. Obviously if you remove the #INCLUDE from the main P8 it does not allow you to load a Z3 file.
So the LUA =IS= required for this project. That's the only point I was trying to make - nothing further than that.
That and, @TBMcQueen, I think in time engines such as this WILL run effectively and fluidly in the Lexaloffle site. I await that day - and it will be interesting to see what other programmers will do with the expansion of LUA as well.
@dw817 I'm sorry, but your understanding of how the project works is completely incorrect.
- The only variation of Lua I know is the Pico-8 version.
- If some function names happen to, by shear coincidence, match some extended Lua function name, that's just how it goes. In fact, this means that if I wanted to move the project outside Pico-8, I'd probably need to rename those functions so I don't conflict with Lua built-in functions. However, these are safe in the Pico-8 environment, it seems. I'm following the naming guidelines of a virtual machine spec which pre-dates Lua by almost 20 years.
- The #include files are themselves just plain Pico-8 code. As mentioned multiple times now, the program can be built in such a way that combines those files into a single .p8 or .p8.png and it will work fine. I don't like having all code in a single, extra long file. I like it in smaller chunks. My usage of #include is only doing what zep says in the P8 docs: "#INCLUDE can be used for things like: Using an external code editor without needing to edit the .p8 file directly."
- You wrote, "Likely there are other commands you wrote in your LUA that do not run on their own in Pico-8." That is 100% false.
- You wrote, "Now once #INCLUDE LUAs can be flattened properly inside a Lexaloffle PNG..." and we have well-established they can be, I just didn't do it right. but that has NOTHING to do with "explore the advanced command set of LUA". I didn't do that, and I don't even think it is possible. Even if it were possible, I wouldn't do that because a goal of the project is to make Pico-8 itself do interesting things.
@2bitchuck You are, of course, correct. set_var just happens to be the name of the function, it is not an indicator of using something beyond normal Pico-8 Lua, which is easily understood by looking at the implementation.
Hi @ChristopherD.
"The #include files are themselves just plain Pico-8 code."
Well you CONFUSE me by using the 3-character "lua" extension for your filenames if they are in fact 100% normal run-out-of-the-box P8 ".p8" files ! Why are you doing this ?? o.O
Yeeph ... Anyways, that's fine, I'm exploring something entirely different now.
I have you to thank to get my brain in gear to working on it though. A P8 compiler to single EXE amongst other things and a whole host of new P8 library functions. I'll let you know more when I know more myself.
@dw817 I already explained above why I'm doing this. It is straight out of zep's documentation for Pico-8. It is a normal, built-in option we have for code organization. The .p8 file contains all of the extra junk Pico-8 needs to launch a program (sprite sheet, sound effects, etc...) but a .lua file only contains Pico-8 code, none of the extra junk.
Here's what it looks like if everything is a .p8 file, and how it looks with the main project as the sole .p8 file with supporting .lua files. I find this much easier to see "which file is the main file for the project" especially in early development before I've decided a name for the project.
Again, this is just how Pico-8 works, nothing special; look through zep's docs for .lua
Well then just use a directory for those extra files maybe ? I dunno, @ChristopherD ...
Volume in drive C is Windows Volume Serial Number is 5813-F93A Directory of C:\Chris\Pico-8\pico-8 0.2.4 windows 12/03/2021 02:31 PM [DIR] status_line_files 12/03/2021 02:32 PM status_line.p8 |
I'm at wit's end here. Your program does not run in Lexaloffle. My future programs may not run directly in Lexaloffle. We can leave it there.
@dw817 I don't know what you're struggling with; I've explained my decisions multiple times now. People are using the project, doing .p8.png files, playing games, and none of that would be possible if there were some "problem" with the project that your comments seem to suggest exists. You're at "wit's end"?
I don't want to put everything into a subfolder because then I'd have to #include subfolder/file.whatever_extension and if I change folder structures, I'd have to fix every #include. I do not want to do that; I like my organization structure as-is. It has zero bearing on anything related to the distribution and execution of the program.
It seems hyper-important to you, but "does not run in Lexaloffle" thing is not a problem for me, because Lexaloffle is not a distribution target I'm interested in at this time. Me ignoring this option has no relationship to your future projects running in Lexaloffle. I'm sure it will work just fine.
So, good luck on your compiler and libraries. I'm sure they'll turn out great.
Well thanks @ChristopherD ... :)
I'm sure this will turn out well too. And yeah it =IS= sorta a big deal for me to have carts run in Lexaloffle. That's a crucible to me.
And yet here I am working on something that very clearly will not run in Lexaloffle, not unless the clipboard CTRL+C and CTRL+V keystroke requirements are revoked, and that doesn't seem like it's gonna happen anytime soon.
So it is new territory for me to explore, but interesting nonetheless. Fortune favors the bold. See you around.
[Please log in to post a comment]
