Game Object Or Collections - Best Practices

Questions
#1

I’ve been wondering recently (as I’m working on my first sizeable project in Defold) whether people are using Game Objects or collections as the top level containers for game entities (or a mix of both).

As far as I can see, there are some advantages to using collections over game objects:

Pros

  • Ability to resize/reposition sprites
  • Multiple scripts controlling different parts of an entity (a gun that has a kickback animation when it fires)

Cons

  • Added complexity in message passing
  • In a large project, it can be confusing if certain entities are defined as collections, and others as game objects.

A more general question I will add to the end of this is:

Are there some best practices/patterns that experienced Defold users have adopted? (if this is already covered in another forum post - then please redirect me to it and I’ll edit this part out :slight_smile: )

Position a sprite relatively to an object + object inside an object
#2

I think that the answer highly depends on what you are building.

2 Likes
#3

It’s a boring answer but also very true.

The first thing to mention is that game objects are cheap. You can have quite a few without any significant impact to performance. If it makes sense to separate an entity in your game into multiple game objects then sure, put them in a collection.

Yes, this is nice. For complex things such as bosses or characters with weapons that should be animated but anchored to a main game object it is really convenient to put all of the game objects in a collection.

This could potentially have a bit of negative impact on performance, especially if you have a lot of messages going back and forth between the different scripts on a game object. Also if you have multiple scripts you’ll end up with multiple transitions from engine native code across the boundary to the Lua lifecycle functions. The more you can collect your logic in a single script the better.

Yes, this is a risk with the approach. Especially if you have child game objects with collision objects that need to communicate collisions to a script on the parent game object.

I don’t consider this a big problem. The most annoying thing is usually when you start with a game object and a factory but later on need to change it to a collection and a collection factory.

4 Likes
#4

It is boring, yes. :slight_smile: Elaborating a bit: I think that instead of focussing on best practices it is better to build stuff and think about how to get the results that you want with simple solutions. When your new ideas don’t fit with the code you have, refactor and rewrite, but don’t overdo it. It is tempting to build systems instead of a game. There are many cases where you end up needing small systems, but don’t create them until you get there. At that point you will know enough of Defold to figure out a solution that fits your use case.

This is usually not a huge issue if you build data oriented as opposed to object oriented where logic tends to be spread out all over the place and refactoring becomes hard (requires an IDE).

10 Likes
#5

I think my questions fits this topic, so I would like to ask about a good designing rules that some of more experienced of you are applying to your large projects to keep it clean and readable.

Usually the most complex entities are main characters, that need to handle controls, movement, interactions, animations, sounds, storing, managing and using data. I tried many attempts and still think the code is really hard to freely move around. I tried to delegate functions to modules or tried to cut functionalities into separate scripts. I tried something really stripped like in DefKit or Platformer Creation Kit.

What approach are you choosing usually? Do you have some tips that could make the project more readable? What is your favorite project structure - I mean game objects for different functionalities or one game object with different scripts?