chrismaltby / gb-studio

A quick and easy to use drag and drop retro game creator for your favourite handheld video game system
https://www.gbstudio.dev
MIT License
8.49k stars 469 forks source link

Destroy and create actors dynamically #714

Open AnthonyMeehan opened 3 years ago

AnthonyMeehan commented 3 years ago

Is your feature request related to a problem? Please describe. While I understand that there are only a limited number of actors that you can place in a scene, having the option to add/remove actors on the fly could lead to a treasure trove of new gameplay options.

Describe the solution you'd like If possible, add a "Destroy Actor" and "Create/Spawn Actor" event to the engine.

Describe alternatives you've considered If this creates too many edge cases, another option might be to provide an accessible path for creating/spawning actors by handling the engine code directly, and then creating some guide/documentation on how you might do this. In a similar vein, perhaps there could be an option to create custom events that run small snippets of code and then limit actor creation / destruction to that.

Additional context As for gameplay examples, when entering a town you could populate it with 10 unique actors assigned randomly from a pool of say 50 possible actors in ROM. Through this you could create environments that feel less static, changing parts of a scene between playthroughs or after completing a quest, without butting into the limits of workarounds like hiding actors or manually duplicating scenes.

Another scenario this could enable would be "recursive" actors i.e. after firing a projectile actor, upon hitting a wall that actor then destroys itself, and spawns another 2 projectile actors that travel in different directions (obviously you would need to be careful with multiple moving actors but you get the idea).

beatbesmer commented 3 years ago

AFAIK you can't bypass the actor limitation, because all possible variations are preloaded for the current scene where they'd be used... the Pros in here will be able to explain the technical reasons ;-)

RichardULZ commented 3 years ago

Projectiles can be created dynamically for how simple they are, and that the event tells the scene to keep the projectile sprite loaded. Projectiles at all, was not a simple task in itself, #73

Dynamically loadable actors are, in part, already a thing now, as there is a pool of 30 actors over a larger scene.

All the scripts for them however, are hard coded pointers, any local variables used in the script, added to the total variable list like a new global variable, references to other actors for movement too, duplicating an actor in editor usually creates new variables and actor references before the compile, which might not work if they were left as is.

Any arrays for amount of actors, or the dynamic pool of projectiles, must also fit within a pre allocated section of ram, and are referenced in collision checks. From all of that, sprite to scene allocation issues, actor and variable reference setups, and other edge cases, it might be hard to get around.

Ejecting the engine and modifying projectile code might be a good place to start, Randomly generating actors in a scene might be easier/simpler/more polished as a few duplicated preset scenes, with random actor starting positions on init making everything else. Your "recursive" actor is hit, and spawns 2 more projectiles, is already possible, update scripts are terminated if the actor is hidden, not sure about hit scripts, you might need to fire the projectiles before hiding. You could experiment with unhiding them after a certain time, or a transparent sprite/ disabling collision, or moving them to the corner of screen instead of hiding the actor.

However, the coming engine rewrite to /gbvm aims to make scripts human readable when output, and rework a lot of things, so it might be a possibility in future, but not exactly soon. Work around/with the limitations for now, and be glad there are projectiles at all