How the Defold’s sound instance works? If I play just a clip (not a loop) I still need to call sound.stop()? Because I have this on my game: (edit: fixed the video)
(yea after the explosion there’s a static. It’s an anomaly-ish thing I made xD)
Do I need to turn off each sound before instantiate another one?
How can I achieve something like inheritance with lua + defold? My game have a few types of anomalies and I made a script for each (gravity, explosion, movement, gravity impulse and so on). First ( and I didnt test that yet) I can set a few scripts on same game object, maybe. But they will have always those extra wasted scripts (also I’ll need to make something to manage them like “isActive” idk). What is the best way to do that? Thanks
No, if you haven’t set the sound as looping there is no need to call sound.stop()
This could be solved using Lua modules. You could have a single script with a bunch of boolean script properties to define which properties an object should have:
And you would put the behaviour of each effect in a Lua module. Your script will require all of them and use/activate the ones which has a corresponding script property set to true.
Yeah, as @britzl said, with Lua modules and go properties you can apply something like OOP. Firstly read this: https://defold.com/manuals/modules/ - it really explains a lot
I’m using them in several ways, maybe this would be some advise for future for you :
as just a wrappers for some generic functions, for example: move(object, where, anim) which animates the movement of the certain ‘object’ to the destination ‘where’ and plays provided ‘anim’ on its sprite (assuming default #sprite), that I could use in many places, so it’s like utilities library
as stateful modules using state tables - even if you create another instance it will share its state with other instances - you can think of it as a “global” access to those variables (from the scripts that includes this module)
modules with metatables so you can instantiate it in your scripts, even many times and each time you create a separate state table, and moreover you can add functions that operate on those states, so you can for example create a simple module for maintaining animation and you can instantiate it for each object with a sprite and use for each:
local animator = require "your_module.animator"
go.property("init_anim", hash("idle"))
--in init:
self.anim = animator.new(go.get_id())
self.anim:set_anim(self.init_anim) -- save anim from go property
self.anim:play()
With above you can set for each object different animation and when you set and play it in init of their scripts you’ll reuse same game objects but with different animation each (note the : sign after self.anim and again, read the manual from the link above)
An alternative to metatables is to use closures - in each Lua module add a function new() or create() in which you create a new table with own state and functions. This solution is faster than metatables, but consumes more memory. Although I think it’s easier to understand than metatables at the beginning - you are literally creating a table with variables and functions (maybe something like std::function or pointers to functions if you’re familiar with C++) and you are returning this table, so scripts uses this instance of the table, this part of reserved memory
: