Rationale behind factory components?

Questions
#1

Hello,

I’m new to Defold and have been reading documentation and getting myself familiar with best practices and nomenclature of this framework.

My question is: I’m not sure I see the benefit of having factory components and I’m wondering why does Defold require you to create them ahead of time “at design time” rather than just creating objects at runtime?

In other words, I feel like i’m missing some key understanding of factories. I know what purpose they serve, but is there a way that I can create components at runtime without having to link a factory to a game object ahead of time?

The reason why I ask is that I want to build an engine on top of Defold where people can write code and instantiate game objects into their game without having to do do this step in the editor.

Perhaps Defold isn’t a good fit for my needs unless there is a way to do this without having to create factories in the editor while still being able to create game objects at runtime.

I feel like this is the only thing preventing me from really pulling off what I want to do.

Any guidance is appreciated!

-deckarep

#2

One of the goals of Defold is to provide a small and performant runtime where games include only the exact set of assets that are known to be used at runtime.

This is achieved by building a full dependency tree of content used in the game, starting from the bootstrap collection, down through all game objects, sub collections, factories and so on. If an atlas, sound, particle effect or script is referenced in this tree of dependencies it will be optimized (compressed etc) and included in the final game archive. If a file happens to be in your project, but is not referenced it will not be included.

If you want to create anything at any time and use any sound, image or other asset we need to include everything at all times in the final application bundle, thus growing the final application bundle.

Despite the limitations I mentioned above I think you still can achieve most of this anyway.

  • Additional Lua code can be loaded and run at any time using loadstring and similar Lua functions.
  • You can load images from disk and create or modify an existing atlas to include the loaded images

Now, the main challenge is probably how to let the user create game objects of any kind at any time. Will there really be no limitations to what the user can do?

I guess you could have something like a sprite factory (basically a game object+sprite) that you create at runtime using a factory and attach to a game object. So some kind of game object composition to create arbitrary combinations of components.

4 Likes
#3

@britzl - hey thank you for the prompt replay and details here.

What you are proposing towards the end of your post is what I was thinking as well. I possibly need to come up with a way to represent classes of game objects as prefabs that I can’t then change at runtime as needed.

The kicker for me is that the engine (on top of Defold) that Im trying to build allows you to express complex hierarchies of objects using Lua. Here is an example of what you can do:

   -- Excerpt from a Lua-like language
   function makeButton(pos, text, code) {
       local image = createImage(UI_SHEET, "panel_button")
       imageAt(image, pos)
       imageParentChild(options_image, image)
       imageScale(image, 3.0)

      local text_image = createTextImage(FONT_OPTIONS, text, ALIGN_CENTER)
      imageAt(text_image, point(1,-3.5))
      imageScale(text_image, 1.0)
      imageParentChild(image, text_image)

      createButton({"image": image}, image, options_image, @(data, event, pos, flags) {
	    if (event == BUTTON_EVENT_ENTER) {
	        imageWiggle(data.image, 0.25,1,2)
	    }
	    if (event == BUTTON_EVENT_UP) {
	 	code()
	    }
    })
return image
}

As you can imagine, the scripting engine allows one to build at runtime any arbitrary visual components with one or more sub componets setting properties as needed and even attaching button click callback events.

Now that I think about it I’m not sure Defold is a good fit for doing this type of thing.

#4

I think this can be done in Defold. A while back I came across Kaboom.js, a simple Javascript framework, with a simple API, and got inspired thinking if/how something like Kaboom could be created in Defold. As a small pet project for evening coding I created Boom, a framework on top of Defold with an API similar to that of Kaboom:

You can use the same declarative API as in Kaboom to compose game objects with visual components and code components into elements in a game. Here’s an example of a Flappy Birds game in Defold using the Boom API:

I use the basic setup with factories to create different visual components, as I suggested above, and it works quite well.

6 Likes
#5

@britzl - oh this is awesome and definitely along the lines of what I’m looking to do. Looks like you are a step ahead here with this Boom framework and it looks pretty awesome to use.

Thanks for the guidance and pointing me in a direction that can hopefully help me move forward!

Cheers,

-deckarep

1 Like
#6

@britzl - I spent most of the day sidetracked going down the rabbit-hole of learning Kaboom and it’s API. Then I came back and cloned your repo Boom and I’m so impressed with how well yours works on top of Defold and mimics the Kaboom api.

This is so impressively well done and I encourage anyone who sees this thread to checkout Boom by @britzl.

2 Likes
#7

Thanks :slight_smile: There are plenty of API functions from Kaboom that I haven’t added in Boom yet, but what is there works surprisingly well.

Creating a game using Boom will not be as performant as writing one without the extra overhead which Boom adds. But in the average case it will be good enough.

PS I am not a big fan of writing an engine on top of an engine, but Boom is in a greyarea, as it tries to leverage the strengths of Defold as much as possible.

1 Like
#8

PS I am not a big fan of writing an engine on top of an engine…

I completely understand! I know to get the most out of Defold it will largely make sense to use Defold’s first class constructs rather than going the route of Boom so for anyone seeing this you’ll definitely want to stick with Defold for ordinary game development.

1 Like