Should I switch back to the old function system?

Post reply
0 favourites
From the Asset Store
Switches Toggles Buckles Alerts !
$4 USD
Toggles Dials Switches and Alerts ! A foundational sound grouping of Analog type switches and Steampunk effects
Dynomite Sound's avatar
Dynomite Sound

  • It's better to move to the new built-in Functions feature. It helps you make your project events modular and the functions can be easily looked up.

    Although, I do not recommend Function Maps, use the Scripting Feature for string based Function calls. 

    	runtime.callFunction("functionName", param1, param2, param3, ...);

    I hope that helps.

  • WackyToaster Games written in classic programming languages probably DO use same named functions that way.

    That is only possible, however, if you can make them local.

    You could, for example, easily have scene-handler functions called scene_1(), scene_2(), scene_3() ... scene_456() and if each of these had a local sub-function called identically item_arrive() that would be pretty normal.

    You would probably also twist your brain trying to make this more efficient by using things like inheritance, classes, scene instancing etc. but thankfully the reason C3 exists is to free you of all these :)

  • The fact you can have multiple functions with the same name is basically a design mistake. AFAIK, no other programming languages support this, and it's simply an error to declare the same function twice. So if you were writing code, you could not do this and would be forced to find another way to do it. You should do the same in Construct too, so you don't have to rely on an deprecated, slow and badly designed feature!

    I would suggest using function maps instead. You could have a function that does some basic work and then calls a mapped function at the end using a string variable to continue doing any extra layout-dependent work. Then you change the string variable as you change layout, and the work that the function does will also change accordingly.

  • no other programming languages support this

    Ashley I think what we mean is something like this 

    function layout1() 
{
	 /* local */ function dostuff() {
		 console.log("This is scene1!");
	}
	dostuff();
}

function layout2()
{
	 /* local */ function dostuff() {
 		console.log("This is scene2!");
 		console.log("Dostuff does something different here!");
 	}
	dostuff();
}

    This is a valid way to declare the same function twice (dostuff). The misunderstanding, I think, is in the fact that Layouts are not scopes in the traditional sense.

  • I would suggest using function maps instead.

    Ashley I know about function maps, but they are not very well suited for large projects like this. At the moment I have about 7 "shared" functions in 10 different layouts. This number will likely grow to 10-15 functions and there may be 50-100-150 layouts in the game. With new functions, imagine the list I will have to scroll through in the Call Function dialog, or in the dropdown box for Map Function dialog! And I will need 1000+ actions just to create this huge map.

    Old Functions are closer to triggered events, and there is nothing wrong in having the same event like "On Item clicked" in multiple event sheets. So it seems fine to me to have the same function "Item_Click" in multiple sheets. If this was a design mistake, it was a fortunate one.

  • pirx - in that example you have declared two entirely different functions, but used scopes to make sure their names don't overlap. The equivalent in Construct is two separate functions with different names.

    Another approach would be to have unique functions on every layout, which themselves call a "common" core function for the parts that are the same. That's probably a simpler way to do it, actually.

    I would strongly advise to find a way to do this with the new functions feature. There should be a reasonable way to do it without having to rely on weird behaviors of old features.

  • Another approach would be to have unique functions on every layout

    This is not possible in my project. Like I said, all core mechanics is in the MAIN event sheet - it performs a bunch of different checks, gestures recognition, modifies instance variables, enables/disables behaviors etc. And only then it calls a custom function from layout event sheet for some finishing touches.

    The only way for me to use new functions here is to call them by string name from a script, as chadorireborn suggested. And I will still end up with a thousand function names in the list..

  • I'm suggesting to do it the other way round: instead of having a main function that then calls in to a layout-specific function at the end, have layout-specific functions that start by calling the common function. Then you shouldn't need any call-by-string feature at all.

  • Ashley, and what will trigger those layout-specific functions?

    There is about a dozen different ways players can interact with items in the game. Besides, every scene is heavily scripted. All of this is currently handled by the MAIN event sheet (200+ events). I can't move this code to layout event sheets, this will not make any sense.

    .

    Anyway, I didn't mean to hijack this thread, sorry :)

    I am not trying to say that the old functions are better, only that in some cases they are more convenient.

  • Oh, I see. I guess that's trickier. Still, I think your attitude to deprecated features should be to not even consider them. If they do end up getting removed in future, then you're creating a new problem for yourself by using them. "Deprecated" does mean "on a path to removal".

  • If anything I think I use functions more now which is interesting because I usually hate methods that aren't very linear.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • dop2000

    Not sure if it would work in your project but another way to avoid the problem would be to ditch functions completely in this case. You could store layout specific actions in an event and trigger this event when needed ("on TriggerPixel created" or something). Passing parameters could also be accomplished via a couple temp variables. This way you could have this same exact setup in as many layouts/sheets as needed.

    Of course if there's a need to call stuff inline; recursion or other function-specific mechanics this wouldn't work but for simple scripting or just firing off actions/conditions it should be enough.

  • pirx Using "On Created" is a clever idea, as it's triggered immediately. Anyway, at the moment I am quite happy with the current system. If in the future (very distant I hope), old functions stop working, I'm sure I'll find some replacement.

  • Actually you can use the old function on C3 runtime, but since its unprecated you can't add it as a new object, although you can use it if its already added in your project.

    But I still doesn't understand your reasons to not use the new functions, since it can do all things the old function do and more.

    I used to call functions directly by string variables and make a whole tree of them. I can still do that now but it's a bit more tricky.

  • The restrictions of the new functions are intended to both enforce better organisation on your project, and improve performance. For example if you are allowed a function with the same name in two places, you can no longer look at a function and know what it does - you have to be aware of the entire rest of the project and see if there are any other functions with the same name. Besides, there's no reason to do it: you could just use one function with a series of sub-events to do everything in one function. And if for some reason that is difficult or awkward, you probably actually just want two separate functions. Now with the new functions you can look at one function and be confident that is the full logic of the function right there since other functions with the same name are not allowed. This improves your ability to reason about your events. It's also faster since the engine doesn't have to handle iterating over multiple functions with the same name, it just goes to the one function directly and runs that.

    There are also major usability improvements, like being able to properly name and describe parameters, and renaming functions and parameters automatically updates the entire project for you.

    I would strongly discourage you from using the old functions since they have poorer usability and much slower performance. Also in general deprecated features should not be used in new projects, since one day eventually they will probably be removed.

    There's more info in the blog post Construct 3's new redesigned functions and More about Construct's new functions.

    This got more attention than I imagined it would. Is there any chance you could make it so we can set default maps and strings for a function directly when we create it, in some update in the future? I have already switched to new functions and am getting used to them.

Post reply
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)