Recently I've worked on 2 little libraries. However, I'm not sure how I feel about the token count in these cases and I'd love to discuss that with the community.
Libraries can provide a piece of functionality that they would have otherwise programmed themselves. Someone creates a library and other people can use it in their games.
But unfortunately I feel like it's simply not worth it to ever use a library with Pico-8. Why? Because of the token count.
In pretty much every instance you're better off writing a piece of code yourself then using someone else's library. You may not need specific features from a library but using this library will still cost you those tokens.
What are your thoughts about this? Would you use a library? Or maybe you have a smart idea of dealing with this limitation.
I've been thinking about it too... There's at least one benefit of not being able to just freely use libraries (though with multi cart bundles I think you might be able to load libraries now without worrying about tokens?) You are encouraged to write the code yourself. Or at least to actually read and understand someone else's code so you can incorporate it into your own cart. The learning experience on Pico 8 puts you in a place quite different than say, using Pygame and a more unlimited wealth of libraries.
When I was working with Python, I'd need something and then try to find a library. Then I would have to tailor my code to work with said library. Then I would come to an issue I didn't understand and I just didn't have the skills to dig into the library and figure it out or modify it. While this is important for big real world projects, Pico8 gives us limitations that encourage a one size fits one solution to coding problems.
That being said... I have learned a lot from people's code snippets and a well written and commented small library for Pico 8 can be a great starting point for more complicated things.
I dunno, lack of libraries is uncomfortable sometimes, but I think it adds to the fantasy environment and learning experiences, rather than taking away from it
That's definitely true, on the other hand however you could say that libraries can allow less experienced users to create games with interesting mechanics as well.
An example would be my textbox library, it takes quite a big amount of time and knowledge to create it. However, thanks to a library like this people who like a different aspect of game development to still create a story based game for example.
In the past I've played a lot with ComputerCraft which is kinda similar to Pico-8 in some ways. In computercraft one could load seperate API's which were saved in seperate files. The API would also be loaded in it's own namespace which made it really easy to add multiple API's to your project.
I'd kinda love to see something similair in Pico-8. I understand the token limit but I kinda feel like this should still be possible since the token count is really tight.
As someone who is learning to code with Pico-8, libraries like yours, as well as carts that focus on showcasing a single idea are a god send. I have learned a lot from them, and I am actually in the midst of going through your textbox library to distill it into something much simpler that will be sufficient for my game. If my game would be more text heavy, I would be as happy using your library as is.
This takes me to another point. Libraries like that let inexperienced devs add things to their game that they would otherwise be unable to do. Sure, often it will be a case of "fire and forget" by adding the library to your game and using it as is, but often people will start messing with it. Even something as simple as changing the background of the textbox, or text color can be a learning experience.
And yeah, it would be nice to be able to add the library without spending all those tokens (we can exlain that in the fantasy universe of Pico-8 we are adding a dedicated chips onto the cart :P ), but if someone is not able to come up with the solution in the first place, this is not a difference between 500 tokens of a library or 300 by writing it yourself, it is a difference between the game having a feature or not and in some cases, the game being made or not.
What am I saying, is that no matter how you use the library, it is always helpful. I really hope that you will keep making them and that others will follow.
What I would love, is there to be a dedicated/curated place for libraries either on the BBS or elsewhere, so people like myself would be able to browse all the snippets available. Sure, there is workshop, but it seems not many people are using it to share sample code (it might be due to the BBS not having moderators to sort things into correct categories).
Nevertheless, I am all for sharing libraries. Even if not everyone will use them as a library to be implanted into their game, they are very useful things and great learning resources!
One of the main goals of my Pico-8 build tool (in progress) is dead code elimination, which would allow you to pull in code from other files and it would strip away the code that you don't use. Depending on the sophistication of the algorithm, libraries may have to be written a certain way to take advantage of this. But it would be one solution to the unused feature problem. Also you'll be able to distribute libraries as carts with demo and test code that gets stripped away automatically when included in another cart.
Library authors and users will always need to be sensitive about tokens. Even if the actively used subset of a library is ~500 tokens, that'll add up quickly if multiple libraries are used. That's no different than developing for small machines so that's working as intended, but it's a thing. I do think there's enough room in 8192 tokens for libraries to be useful in small-to-medium sized projects, especially for beginners. Carts that have been posted in the spirit of libraries so far have all been small enough that I can imagine a good-sized game using them.
Awesome to hear that you're working on a build tool!
That'll defenitely help.
The thing however is that even though the medium to small sized projcts have enough space for libraries I think that it's especially the larger games that could really benefit from those libraries. But for these projects every single token counts and thus usinf libraries is pretty much never a feasible option.
Personally what I'd like to do is to create an input and output library. For textboxes and input prompts that you often see in RPG games. However, this will defenitely take more then 1500 tokens, especially if you would like something like colored text.
I have however not tried the multicart thingy, will that allow for more tokens?
Multicart would require some careful strategy because there's no way to load new code and preserve Lua RAM. You have to completely load a new cart to get new code. You can preserve game state between carts using cartdata for 256 bytes, or you can save addressable RAM regions to one of the carts in a multi-cart setup with cstore/reload.
Given a way to save game state, you could have one cart dedicated to cutscenes and another cart dedicated to gameplay. To start a cutscene, set a byte indicating which scene to play and how to return back to gameplay, store state with cartdata, then load the cutscene cart. When the cutscene cart is done playing, it reloads the gameplay cart. The gameplay cart rebuilds its state from the cartdata or reload. That would allow you to use potentially large cutscene animation libraries with the cutscene cart without burdening the gameplay cart.
You can use a different strategy for graphics and sound data. You can even use addressable RAM for gameplay data if you build an engine for it. reload lets you load arbitrary (non-code) data into addressable memory from other carts and the Lua can keep running. You can store and load this data any way you'd like in other carts. You'd probably want a tool to build that data, either externally (via something like picotool) or with an editor of your own design in Pico-8 using cstore to save the data to the cart. My Tale of Two Cities demo was originally intended for RPG-like text strings, using a build workflow with an external tool and Lua routines to compress text strings into graphics memory.
[Please log in to post a comment]