Describe your reason for requesting this feature. What problems are you running into?
my reasoning for adding this feature is that there is rarely a game that both employs OOP and won't have anything that needs to be destroyed. some examples are:
collectables
enemies in a game featuring combat
How would this request improve your experience developing for Playdate?
if you have classes inherit from sprite like many do, you would have to add the destroy method to each class individually, or re-structure your classes to have them inherit from a helper class which inherits from sprite, which could be a pain just for one function
Include any other details you have relating to this request.
I'm aware that you can destroy classes by removing all references to them, like removing their reference from the draw list, and setting self to nil, but that comes with the drawback that, when setting self to nil within the class, the variable the class was stored in keeps that info, rather than being set to nil. (I'm not aware of a solution to this, but if there is one please post it here)
Have you considered using object pooling instead? Garbage collection in a Lua game (due to object destruction) can lead to an inconsistent experience for players, depending on when it occurs. Object pooling also lets you have more control over the total memory footprint of your game over its running time. Pooling means you'll use more memory because you'll precreate more objects, but you may understand your memory requirements more. Pooling requires some thought while coding, but then so does trying to manage Lua garbage collection so it doesnt impact gameplay.
The sprite list seems to have been constructed to encourage pooling as well, because you can add and remove sprites from the list. The sprite list obviously represents the objects 'in game'.
Just my 2c as I'm a hobbyist, I'm writing a Bosconian inspired top down shooter in Lua (enemies and bullets in flight constantly), and was surprised how quickly I noticed garbage collection effecting gameplay, so started using pooling instead and found it a better experience.
I haven't heard of object pooling before, and while it does seem like a good idea, I still think it would be simpler for smaller projects to be able to simply instantiate and destroy classes when necessary, rather than having to load them at startup, and worry about things carrying over that aren't supposed to. (please correct me if I'm wrong, as i said I hadn't heard about object pooling until now, all my knowledge of it comes from skim reading the top google result )
No worries! It might be useful to you then. Here's an example from the forum:
Googling 'object pool in lua' gives you helpful links as well.
There's two central ideas in object pooling I think.
when you need an object like an enemy or bullet, you either create it in the pool if there's none free, or you get a free one from the pool. This means you do have to know if an object is active (in the game) or free to be reused from pool 'inactive'. Typically just a boolean flag on the object itself. The Lua objects stay in the pool, they just flip between active and free/inactive as your game plays.
when your game launches it's common to precreate objects to fill the pools. This also saves the processing time of having to create objects while your game is playing. The Play.Date is a great console but the it's built around a low power microprocessor
This pattern is also super helpful for asset loading on the Play.Date and here's a great class for that: Best practices for managing lots of assets because you just want to load assets once (music, bitmaps, fonts etc) and reuse them many times thats also an object pool.
I agree for a quick prototype I maybe wouldn't set up pools first, but I think they're very helpful for anything you get to a publishable state. Lua garbage collection is expensive time wise and harder to control when it occurs.
)