Magic Link Tutorial

So I’ve almost got the Magic Link tutorial working. Although it’s playable I’m left with 2 bugs:

  • had to disable the alpha channel animation of start menu falling blocks because it was affecting the empty parts of the sprite and not the whole sprite, so it looked like an artifact.
  • the magic_fx do not spawn properly, sometimes not at all. If I finish or restart a level, a magic_fx will spawn on the last place touched.

Spoiler alert:

A lot of the adventure in this tutorial involves moving functions so they get declared before use, which means practise looking at the error console. Renaming most id’s to ‘script’ or ‘gui’. Hunting for ‘scale’ to correct the given values - maybe I am not the only one looking for a global scale after this, or at least a plan for some global variable. Since it is an old and somewhat vague tutorial, putting the gui together may entail looking at colorslide or some other gui tutorial as well, which means one will still have questions regarding guis when done. Dealing with a board.collection that has a renamed id of board and holds a board.go (not to mention a board.gui) lends itself to a type of ‘object oriented dislexia’ when looking at board.script. And there are parts of the code that have no explanation of how they work. As of this writing, I could not get the completed version for comparison.

So in short, I’d like to see more explanations of the code especially the magic_fx.script, block.script and board.script dealing with the fx - since it is not working and I do not understand how it is supposed to work.

Thank you for the feedback on the tutorial. I’m sure @sicher appreciates it as well!

Yes, thanks for the feedback. It is an old and pretty hefty tutorial, and it certainly needs some work. Maybe it should be split up or something?

1 Like

It is an intermediate tutorial so one can expect to be willing to dig in and figure most of this out, or troubleshoot and trace…

Sure it’s old and hefty, but as I said I’ve only got a couple bugs and it is playable.
I would not recommend splitting it up - though I just ignored the bugs in the creation of the magic_fx and moved on, the tutorial is also good for practising pushing commits. Maybe a couple more

titles

type of breaks that to me are good places to commit/push once they are working as expected.

The GUI bits are ok - if one first goes and tries the colorslide tutorial and is willing to read up on guis in the manual. There’s the animation of “color.w” in main_menu.gui_script that ends up looking like an artifact (not at all like the completed version at the start of the tutorial) so I disabled it -> the only thing gui related I can whine about and eventually I will go look deeper to see what is what, but I am not bothered by it.

But, I can not find where I went ‘wrong’ with the magic_fx parts - so somewhere when the tutorial got revised a step or something got left out, much as when one gets to the

Magic block logic

the following is missing from the start of otherwise complete block.script :

-- block.script
go.property("color", hash("none"))  -- 
-- this IS needed

In the same script are scale 1 values that need to be scale .18

So I also figure I need to study lua tables quite a bit more, but that said…

There’s the board.script which is large (533 lines). And the bits that need pasting in - I tried what I thought was logical - paste after the previous pasting, and of course this ends up with errors getting thrown that are easy enough to fix but I wonder if my magic_fx bugs are related to where something is pasted. So it would be helpful to be able to look at the completed script.

edit; one more thing…
–board.script …
– Distribute magic blocks.
This could use a bit more explanation.
Here we have rand_x and rand_y which serve as indices.
Is it a holdover from C programming to index from 0-8 instead of 1-9; are there performance benefits and/or does it facilitate this block of code?

4 Likes

Thanks for this feedback!

So in the on_message() of board.script

edit: pseudo code

“next_level”

    clear_board()   -- ***
    self.drops += 1
    "start_level"

*** One would think that the deletion of the fx game objects in final() of block.script would happen as the clear_board() loops are deleting each block. According to my print statements however, this does not happen until the new level is created, i.e. after all the statements in the “next_level” clause of on_message(). Is this some sort of priority thing?

That is not valid Lua code. Lua has no += operator. The only way to increment is to do:

self.drops = self.drops + 1

No. It’s async. go.delete() returns immediately after marking the game object for deletion, which happens later, but before next frame. See https://www.defold.com/manuals/application-lifecycle/

sorry I mean it as pseudo code while I was tracing… I will edit

So it means that every thing in the “next_level” clause (and probably more) will happen before the “Post update” bit where the final() functions actually get called and then the objects actually get deleted.

This would explain why the section :

-- "Win" from start. Make new board.

is going to throw a lot errors with this setting in game.project :

factory  
GameObject factory related settings  
Max Count   128  

I also wonder where the timing of print() falls.

This is also the most likely culprit for the bugs I have (tutorial was for editor 1?). Perhaps some well placed wait timers (delta time and or messages?) would fix them.