Defold Timer - The native timer extension


Creating a timer in Defold using a Lua module is a fairly straight forward process, covered in separate topics here on the forum (here and here), but I’ve never really liked that you have to call timer.update() yourself. Now, with the alpha release of native extensions, there is the possibility to create a timer module using a native extension and thus get automatic calls to a provided update function from the engine itself. I decided to try this and you can check out the result in the defold-timer project on GitHub. The API looks like this:

local id = timer.seconds(1.5, function(self, id)
  print("I will be called once, unless I'm cancelled")

local id = timer.repeating(2.5, function(self, id)
  print("I will be called repeatedly, until I'm cancelled")


Note that native extensions aren’t supported on all platforms yet!

Execute a function on a repeating timer (SOLVED)
Questions on delays and positions

Why not provide such functionality in core engine? Is that so hard?


No, not hard at all, but it hasn’t been given enough priority. There’s even a ticket in Jira for it (DEF-1183).


What prevents Defold engeneers give DEF-1183 (and others core engine bug fixes and features) max priority? And, in the same time, give slightly lower priority for “support” and “nice-to-have” features, like native extensions and live updates?


Extensions and live update are far from “support” or “nice to have” since they provide essential functionality that you cannot work around. Especially extensions empower our users to create functionality that is missing for them, like support for specific ad providers, external libraries and such.


It’s most expected features for now!!!

I know 2 workarounds for DEF-1183, and thanks @britzl for third workaround.
Why it should be “max priority” if it has so many workarounds?

UPD: In my humble opinion Defold Timer lib can be reason of closing DEF-1183.
Why not? It is absolutely native resolve of task.


This is only matters if core engine is feature rich and (almost) free of bugs. Defold is far from that. There is so many bugs (not fixing by years), glitches and missing functionality. Just look at your infamous backlog. Substitute basic features by extensions is not an option.
I think, Defold team lost his “priorities” altogether.


Native extensions is good only to show ads and such. We can’t implement custom raycasts, for example, etc. Good game can live without live updates, indie games is not so big.


For now, yes. But maybe you hear about Defold SDK? As I understand, native extension is first step of future module-architecture. And make modules with special function is good way, I think. Better than huge engine with million api methods, and games which use only 1% of it.

It’s your case, but you can read forum and find many other cases. And eg we planing new social/mobile game (and yes, we are small indie team) where live update must have feture.

Alarms/Wait function? (SOLVED)
Hiding the mouse cursor (DEF-1619)

I’m sorry you feel that way. It’s my opinion that we are focused on delivering the best possible engine for both indie developers and developers at King. But with that said, I can totally understand the frustration when it feels like we’re not doing what’s important. Personally, I felt that it totally sucked that we had a broken multi touch for such a long time, but eventually we fixed that as well.

Would you mind posting your top three list of bugs that you would like to se fixed in Defold?


Defold is definitely not feature rich (compared to Unity, etc.), but in my experience it’s more stable and bug-free than any other game engine I’ve tried (Unreal, Unity, Godot). I’ve been searching for years for the perfect game engine and it doesn’t exist. I’ve never found one that I fully understood their priorities or what the heck they spent all their time working on. You will always have to work around some things. You just get to choose the engine with workarounds you dislike the least, or build it all yourself.


This is annoying me right now in no particular order:

  1. I want immediate ray casts.
    I realize what that is impossible. So, please double (or triple) raycast buffer length. This is really a show-stopper for me. I am already reach this limit.
  2. Some sound crackling when plays short wav sounds (like hero jumps). It sometimes happens, sometimes not. Not sure about origin of this. Because this is one-liner in code, i don’t know how to fix this.
  3. Multi-touch issue. This is source of some hard-to-find glitches. DEF-2024.


I use Defold because it is definitely lesser evil :slight_smile: But sometimes i fight with engine too much.
My main complains is about absent common basic features, which present in all other engines (sprite component anchor point, for example), and some strange design decision (deferred ray cast) which prevents using normal coding practice and lead to weird and hackish code.


Awesome! Thanks a ton


No 3. Fixed in 1.2.100 that was just released.


Thank you for providing a list of your top priority issues!

I’m not sure why it is designed the way it currently is. Let me talk to some people and get back to you on this.

Does this happen on mobile (and in that case on all devices) or other platforms as well? There’s an issue on HTML5 about crackling sounds (DEF-2515)

Solved in 1.2.100!


It’s strange: i can’t fetch this library. The link ( is working through a browser, I can fetch some another libraries, but not this one.


Ah, not strange at all actually. I had forgotten to specify the timer directory as an include_dir for the library in game.project. Fixed now. Please try again.


I’ve made some investigation and what happens when you request a ray case is that we let the physics system step through it’s simulation once and at the same time check the ray cast and communicating this back as a message. This is the main reason for it being asynchronous in the way it is currently. I’ve created a ticket (DEF-2581) to request that physics.ray_cast() would also support a callback to complement the message. Something like this:

local from = go.get_position()
local to = go.get_position(some_id)
local groups = { hash("enemy"), hash("wall") }
physics.ray_cast(from, to, groups, 1234, function(self, ray_cast_response)
  -- handle response here

Now, the main idea would be the same in that we step the physics one and do the ray cast, meaning that the thing would still be asynchronous, but instead of forcing the developer to do additional bookkeeping because of the message passing it would be possible to remain in the same scope and have access to all up-values and state.

When you say immediate, would that be sufficient or do you mean immediate as in always happening the same frame and not the next one?


DEF-2581 will not help at all. This is no different from what we have now. Just another way doing the same thing.

“Always happening the same frame and not the next one” – exactly what i mean.

In update function:

  1. Do raycast.
  2. Analize what it returns (it also should return “nothing hit” response) and do something.
  3. Do another raycast, based on that new state.
  4. Repeat from step 2.
    All steps should happens in the same frame.

For now, increasing raycast buffer length from 64 to some higher number will help a little.