Advice on approach for script placement

I just realized I tried Defold a couple of years ago. :roll_eyes: Anyway, brain is better now so am positive I will stay with it this time.

After playing around with the engine, watching some tutorials I need a bit of advice for my project and what would be the best approach.

I have a main collection with a manage game script which will hold lots of functions needed through out the game. This main collection (coll) will send you to the first coll you will actually see in the game.

The first coll you arrive at /after the main) is a place where you see every thing from above, you can click/tap areas (20 of them) which will take you to corresponding coll.
Question is what would be best practise:
Do I handle all the moving back and forth between colls in a script in this first coll or in the main “manage game” script?

Any advice much appreciated.

2 Likes

I have something called “collection_manager” which lives in my bootstrap collection. This handles all the loading/unloading of various collections. Various scripts interact with the collection manager via message passing, e.g. clicking “play” on main menu will request the game collection, or on death player.script will request the game over collection, etc.

I rolled my own collection manager, but many people use Monarch, which is likely a good idea to save time and effort.

2 Likes

Thank you!

1 Like

Yeah, for example I use Monarch for this especially :wink:

I have a main.collection with main.script and screens:

image

Main script handles message “change_screen”:

if message_id == hash("change_screen")
	local next_screen = message.next_screen
	log:info("Change screen to: [ " .. next_screen .. " ]")
	monarch.show(next_screen, {
		clear = true
	})
end

Then monarch handles the rest to open any collection, including smooth transitions I define according to its documentation.


Off topic (but also useful tips):

I use also my Pigeon module for easier message handling, but it’s not needed - in this case though the address of main script is really easy and not changing, but I’m still lazy and I use Pigeon for subscribing to messages :smiley: But Pigeon can also check message data correctness in runtime, especially useful in early development :wink:

I also actually use “Hashed” module instead of built-in “hash”, which is caching hashed messages inside, because it’s a generally good practice to pre-hash everything (you can as well just make a local hashed_message = hash"my_message")

And I use my logger module - Squid too :smiley: Above you can see a line log:info which is because I use instanced logger here:

local squid = require "squid.squid"
local log = squid.new("main")
-- and then:
log:info("my message")

The double dots “:” (colon) is used in Lua to pass “itself” as first argument, so it’s same as:

log.info(log, "my message")

And one other tip to get rid of confussion here:

require "something" / print "something" / hash "something"
-- is same as:
require("something") / print("something") / hash("something")

When there is one parameter that is string in Lua :smiley:

3 Likes

Great. Thank you.

2 Likes