One block or multiple blocks?


#1

GDevelop allows multiple actions per action block, but you can also create multiple action blocks with just one action. When an export is done, does it make any difference? As a programmer, this type of information is useful from a best practices perspective.

Thanks
Art.


#2

Code generated is longer with sub-events or multiples blocs of events.
Here pretty code ^^


#3

Thank you @Bouh - that is good information to have when developing a game.


#4

Now that I have discovered Event Groups, I just have to ask - are groupings stripped out when the code is generated? If they are, then the following block would generate the same code with and without the blue grouping lines.
24%20PM

Thanks,
Art.


#5

This is local web export, it’s can be different on others export i don’t know.
With one group generated code is longer because profiler function for debugging in GD5 appear.

I guess this profiler is not present in exported game so if condition for profiler is avoided.
But a new function is created for this conditions then code is a bit longer with one function and two condition

It’s same if the Groups have no descriptions functions and profiler are present.
Maybe this profiler functions can be avoid when a user export game manually ? @4ian


#6

A few comments:

  • Profiler calls should be stripped in export but if it’s not the case I have to look at it.
    • This means that performance wise, a group is equivalent to an event with sub events, when exported
  • Sub events generate internally, as you’ve seen, different functions that call each other. The code is slightly longer, but before it was generated without extra functions and this was making performance worse (with long events sheet). Splitting the generated code into separate functions made the job easier somehow for JavaScript engines and their garbage collector.
  • All of this is probably, performance speaking, not significant at all. Most of the time spent in your game will be dominated by collision handling/conditions related to objects if you have too much objects and/or rendering if you’re displaying too much things on screen. (For example, displaying tons of tiled sprite of the size of the screen with lots of transparency/empty area will put a lot of burden on the GPU, because the whole screen must be drawn multiple times, in which case a lot of smaller objects can be better: less pixels to draw)