Log In  


This subject may have been touched on lightly already, I don't know.

As some game writers in PICO are selling their products, I would like to recommend that PICO have one of a few things.

First off, I've already written a program that can bundle PICO and a source code and have them run each other from a single EXE file that doesn't leave or use any stray files. The problem is the ESCAPE key. Once you hit it, the game stops, and the player can hit ESCAPE again and the source code is revealed.

I would like to add to COMMAND LINE options for PICO -NOESC where the ESCAPE key cannot be used.

Better than this would be to have an option to compile to a single (and possibly encrypted) EXE.

So someone could load up their game. In command mode type, "SAVE GAME.EXE" and a single executable file is created. If ESC is hit during runtime, you only get similar options like you do in SPLORE, but no option to edit or view the source.

CONTINUE
RESET CART
EXIT

Saved game files would be saved either in Users/Name/AppData ... or directly in the same path as the EXE.

Any ideas on this ?

2


So like, a Pico-8 standalone executable for playing games without having to own the fantasy console?

Especially since I've heard that the web player has some input latency, being able to distribute native executables of your game without expecting your players to own Pico 8 would be awesome.

Back to an earlier discussion we had about "installer cartridges", you could just bundle a bunch of data files with your executable so that your game can load new music, tiles, and map data at the start of each level. That doesn't work in the web player, and it certainly wouldn't work to distribute your game if your players didn't own Pico 8, but with standalone executables then you can zip up whatever extra files you want along with your .exe.

People may see that as "cheating" with Pico 8, but hey, the Commodore 64 had a floppy disk drive add-on, so why can't we load multiple files too, right?

EDIT: Almost every cartridge based computer or gaming system had support for bank switching and various cartridge sizes, so I don't see why Pico8 can't support that, too :( I love the 16 color limitation, I love the RAM limitation, and I love the CPU limitations, and they're all more-or-less true to the bygone era, but oh god why can't we have banked cartridges which have been around the better part of 34 years?


Sounds reasonable, Jamish. I definitely don't see it as cheating to have data files.

Look at any Windows game today. If you know where they store the "save game" stuff, anyone is welcome to take a crack at those.

Me ? When I did stuff like that, I would encrypt the save files and use a checksum at both the beginning and end - oh, those were the days. :)

Certainly that could be done today to "protect" the data cart files you are referring to. There would be no 'cheating.'

And yes, as I would do it, I would have to bundle the actual PICO system and lock out the ESCAPE key while it runs - and I'd rather not.

There's too many ways to get around that.

No, I'd like ZEP to make a marvelous little compiler that takes an existing .p8 or .p8.png and converts it to a single Windows (or MAC) EXE.

Failing that, a program you can use with arguments, like "-run" to run it.

I know you can do this in current PICO, but the user need only press ESC to see the game stop, and ESC again to see the source.

So - it would be a cut down PICO engine that handles run-time only with no way to view or extract source. Or perhaps just remove the key input routine entirely outside of the game - which can be seen when you hit END or STOP in an Online PICO game.

The prompt appears, the cursor flashes, but no key works.

This multiple file idea of yours is interesting. It would allow people to make custom maps for existing PICO titles and never have to get their hands sullied with the actual source or coding. :)


Yeah, I'd be tempted to resort to bundling the actual PICO executable, but I highly doubt the legality of redistributing that (or am I wrong and we are free to?). That's all the incentive Zep needs to make the standalone native exporter right there... don't make me a pirate :P

(to clarify, that's not a threat to Zep... I'm not going to redistribute anything if I am not legally entitled to do so!)

The other point that you have about not being able to view or extract source would be tricky. I'm sure when you compile this hypothetical marvelous native EXE, the Lua code could get obfuscated, but since it's an interpreted language, is encryption even possible? I've read that Lua can be compiled as C++ so maybe that's doable.


Grin Exactly. I really REALLY do want ZEP to handle it.

As for encryption, well, I'm not going to brag. :) No I'm not. However I have some methods involving poly morphable data where the key is based entirely on the encrypted contents and no other key would fit, easily 64- or 128-bit, not an easy thing to crack.

If ZEP likes, I would be more than happy to have a chat (real chat software) to discuss the elements, implication, and administration of such code.

And no. No-one is accusing you of being a pirate, Jamish. PICO is just too nice to do that to and the community is too wide and friendly, aren't they ? :) Sure they are.

Likely this conversation and very question will crop up again sometimes, and by someone much more influential than myself - and - if it happens, great. I'm all for it.

If not, I doubt I will be the final word on the matter.

And I definitely do appreciate your input on the matter ! Thanks for that ! :D


Why would you want to bundle the Pico-8 dev kit binary, and not just wrap the web player in a standalone app? The only reason I can think of is if your game spans multiple carts, which the web player currently doesn't support. See previous discussion, including links to tools that do this: https://www.lexaloffle.com/bbs/?tid=27701


@dddaaannn: there seems to be performance issues, difficulties with code compression, lack of gamepad support... can you even start fullscreen?

there's a binary exporter far away on the roadmap. we can try to pressure zep to make it priority, but illegally distributing the devkit exe is a really stupid idea.


Thanks for the knowledge bomb, @dddaaannn and @ultrabrite. I didn't realize that was on the roadmap, which is exciting. Again, I'd never actually illegally distribute the devkit exe, it just sucks that the devkit is the only to get the full player features right now.


Good points, thanks ultrabrite!


Right, please do /not/ distribute the binaries! I hope that's obvious.

I've bumped the exporters up to 0.2.0 (beta) which I'm aiming to release this year. They'll be able to package up to 16 carts into a single file, so will serve as a way to do things that feel non-standard (multi-carts, lots of save data, or larger games, etc) in a slightly separated space. I think this will be the way to have our cake (the pure format encouraging small designs on the BBS) and eat it too (making larger, and/or commercial games that feel a bit different, distributed through other channels).


Zep. Good to hear from you. I'd like to apologize about being a pest earlier (multi-posts). Certainly I (and I suspect everyone else) will wait patiently as you make upgrades and updates to PICO.

We won't make a move without you. :)


Since you are at it, make an apk, deb, rpm exporter too. This way PICO-8 will get even more famous!


I was wondering how to export PICO-8 games to consoles without distributing the binary, and discovered that Celeste embedded its own PICO-8 version as a mini-game. Since the current binary export only applies to PC, I wonder how they did.

A Linux emulator on PS4 and Switch, and a Windows emulator on Xbox? No way...
A PicoLove port as done here? Why the PICO-8 splash screen then?

My best bet would be that they use the browser version, since the PICO-8 standalone .js is made to be put on web pages so it shouldn't hurt to distribute it. However you'd still need to embed an HTML game in your engine, in this case XNA... Not sure if that has really been done.


I'm sure there must be apps out there that can take an emscripten app like the PICO-8 webplayer and compile them into an executable or a lib. I wouldn't be surprised if that's how Celeste did it.

It's also the case that the PICO-8 platform is pretty simple conceptually and it really wouldn't take a lot of effort to convert the lua+platform-specific-features of a game to another platform.


Apache Cordova would definitely be a solution to embed the html version as a ‘native’ application.


Since this thread was resurrected earlier this year, I just want to point out that they actually ported PICO-8 Celeste to C# line by line!

https://twitter.com/NoelFB/status/885176599028523009


I suppose one nice feature of lua is that its simple syntax tends to map easily onto more complex languages. Not to mention the very limited API on PICO-8...


Ah, thanks for the precision @tobiasvl.

That reminds me that Matt Hughson (https://twitter.com/matthughson) is porting the PICO-8 API to monogame for his MGS-like (he may even be parsing Lua scripts directly... last time I asked, he told me he was using Moonscript).

Anyway, about the browser version, any wrapper could turn an HTML page into a web app (e.g. nwjs on desktop). So we could have a cross-platform runtime-only cartridge player at the cost of performance.

BTW, the thread started in 2016 and zep released binary export in the meantime. https://www.lexaloffle.com/bbs/?tid=30127 explains that a binary export is actually a runtime executable + a cartridge (data.pod). Which means we already have a runtime player, and we are already distributing it. We just have to say somewhere to players that they can reuse the runtime player they got with one game directly with other data.pod files (at least for compatible versions).

On one side, you gain 1MB per cartridge by doing this because you don't have to copy the whole player for each game. On the other side, data.pod is still much heavier than a p8 or png cartridge (with a fixed size of 800kB). So if the objective is to spare memory for your minimalistic hardware, I'm not sure how efficient this is, compared to spending $15 to buy the editor. Now, if data.pod had not a fixed size, this would become very interesting.



[Please log in to post a comment]