Defold Design Patterns (SOLVED)

Questions
#1

Is there a stash of Defold designed patterns somewhere?

While there are bunch of examples (thanks to the many authors) extracting the pattern from the implementation/problem can be a bit time consuming. Add to this whether or not that design is considered ‘good’, leaves thing a little murky.

Standard patterns can of course be co-opted but wont take into account how Defold itself, specifically, functions.

As an example; I have a collection of objects that is character: body, sword, shoes, etc. However, this collection doesn’t exist at run-time so if I want to delete the character I can’t just call ‘delete collection’.

This is fairly easy problem to solve: Have all of the game objects register themselves with the ‘main’ game object and then have that component delete all them, before deleting itself.

My problem is that I don’t know if this approach is going to cause issues down the line (memory leaks, asynchronous delete commands leaving a characters limbs behind).

You could instead have a ‘deleteStuff’ game object that you pass tables of urls to be delete and thus avoid the limb problem above. But is this actually a better approach, or is it just solving a problem that was never going to occur anyway. :slight_smile:

Knowing the recommended approach before I write the implementation would save me some time reworking things.

To be clear, this isn’t a request for a solution to the above issue, merely a request for the location of design patterns if I wandered past them without noticing.

Thanks.

#2

go.delete() allows recursive deletion of children, do go.delete(“main_object”, true) and then have a root GO in that collection and all will be deleted based on the deletion of the root.

There are no real rules but it would be useful to be aware of everything in the API and to study a few larger projects, such as ones open sourced from comps. Of course experience from other tools can carry over too. Most important thing is to not be afraid of asking questions when you’re unsure of a decent way to do something.

Here’s a list of dependencies we use in one of the commercial Defold games I worked on Faerie Solitaire Harvest. If you go through that list you can find some things you may have not noticed before which can help you with dev.

https://github.com/subsoap/defos/
https://github.com/subsoap/defsave/
https://github.com/subsoap/defstring/
https://github.com/subsoap/defmath/
https://github.com/britzl/monarch/
https://github.com/rgrams/rendercam/
https://github.com/britzl/gooey/
https://github.com/britzl/defold-lfs/
https://github.com/dapetcu21/defold-fmod/
https://github.com/GameAnalytics/GA-SDK-DEFOLD/
https://github.com/britzl/steamworks-defold/
https://github.com/subsoap/discordrich/
https://github.com/Lerg/extension-directories/
5 Likes
#3

Thanks for the links, will be handy.

While source code is an invaluable tool and I certainly do read a great deal of it, abstracted patterns tend to faster. If for no other reason that you don’t have to detangle the specific implementation from the underlying pattern.

If the answer to my question is; “there isn’t one” that fine, I just wanted to make sure that I didn’t miss it.

#4

What I personally like to do is to utilize factories to the max. So instead of laying out elements in main.collection by hand, I prefer to spawn them at runtime with factory.create(). For objects that consist of several game objects, you would use collectionfactory.create().

This way all spawned ids can be stored in your script instance and you would be able to delete any of them.

3 Likes
#5

Which is also a good approach but my question was more about the if there was a pattern stash somewhere. I only added the example to try and illustrate my point.

In saying that; I did consider your approach but it means that you can not see how elements are laid out in the editor, which while not an insurmountable issue, does render having a lovely GUI editor somewhat less useful.

1 Like
#6

No we have no manual or other document describing design patterns specific to Defold. Maybe it’s something that would be valuable to our users?

3 Likes
#7

For me, certainly.

I do find that patterns tend to be more resilient than code in regards to time. IE if a function name changes the code example will top working. The pattern, in theory, should be fine as its layer of abstraction means that developer should be able to find a suitable replacement.

It does have the down side that people that don’t already have a programming background will ask for, quite rightly, a example in code. However you may be able to point them to an existing broader project now that they can use the pattern description as a ‘map’ by which to find the relevant code?

Lastly, I find the anti-patterns or the reasons why an approach was taken in a pattern also be extremely valuable. Someone using an example that is designed for a specific purpose (say a facebook instant game) and implementing it for a different purpose (say a thick client PC game) may result in them doing things that aren’t relevant and/or cause them issue down the road. This is what I meant by having to separate the implementation from the design.

Now in saying all of this, it’s not critical . I was merely checking to make sure I had not missed something (and I do enjoy discussing solution architecture. There seems to be a paucity of it around game design for some reason).

2 Likes
#8

Thank you for clarifying your thoughts on this. I’ll keep this under consideration, but right now there’s no plan to add anything like this.

1 Like