We need a "Function call behavior"

Discussion and feedback on Construct 2

Post » Sat Jan 03, 2015 9:58 pm

@Tylermon
There isn't really an issue, not exactly, just some coding and C2 objects functionality Q&A :)

I was hoping for a way to have instance methods in C2. There isn't such a thing right now. I was hoping for an existing behavior that might provide this functionality. It doesn't exist. @PixelRebirth made the point that calling onFunction events, passing in the instance.UID as first param pretty much duplicates the behavior I described in OP.

The issue, if we in fact have one, is does the Object.PickByUID action iterate every instance to locate/return the one instance I want by it's UID. Or does it somehow directly select/Pick an instance in memory with the UID. If the latter, than onFunction(inst.UID, param1, parm2..) will be fine for now or maybe forever. If the former, I need to start thinking about building a custom behavior.

Which of the following illustrates how Object.PickByUID works...

Code: Select all
// 1
Monster.PickByUID(paramUID) {
    foreach(allMonsterInsts as m) {
        if (m.UID = paramUID) return m
    }   
}

// 2
Monster.PickByUID(paramUID) {
    return allMosterInsts[paramUID]
}


If PickByUID action works like 2, then I'm fine with just using onFunction and passing in the UID. If it's 1, then we need something better like instance methods as I described in the OP. Or perhaps a way to pass an actual object instance reference into onFunction like @PixelRebirth said.
B
13
S
4
Posts: 280
Reputation: 1,578

Post » Sat Jan 03, 2015 11:13 pm

@locohost

For the most part, I feel pickByUID can be completely avoided by other events instead of using a function. I struggle to think of a case where pickByUID is necessary. Most animations can be determined by collisions, keypresses, or data values(health,stamina, etc). And a similar reasoning goes with many other concepts. Most, if not all pickByUID cases can be avoided altogether.


My thoughts on object id's
I would imagine they are sorted at O(n log n) merge sorted, heap sorted, or something similar. in which case finding and picking the correct uID would be rather quick. Although a bubble sort or insert honestly wouldn't be bad either O(n^2).
If objects are not sorted though and construct is using something linear, I can see how we might come across an issue. An easy way to test this would be creating a project with a very large amount of objects then time how long it takes to get the first object and last object.
Do this about 3 times with different object counts, and we should be able to tell if it is linear or not.
Unless @ashley wants to tell us if object id's are sorted/picked faster than that
B
28
S
8
G
1
Posts: 226
Reputation: 2,865

Post » Sat Jan 03, 2015 11:55 pm

locohost wrote:Can we ask Ashley some how?

If Object.PickByUID gets a reference to the instance without iterating them all, then @PixelRebirth is right, just keep using onFunctions with the PickByUID action on param0. Otherwise, someone (me I guess) needs to look into building the behavior described in OP. Which will be time consuming.


Clearly he will say you are wasting time on micro optimization.

The events are intentionally a subset of a traditional programming language. That is why they advertise "no coding required". For those that want to "do coding" that is what the JavaScript SDK is for.
B
21
S
5
Posts: 196
Reputation: 1,974

Post » Sun Jan 04, 2015 12:03 am

B
48
S
16
G
9
Posts: 1,098
Reputation: 11,197

Post » Sun Jan 04, 2015 12:27 am

@locohost
I requested object oriented methods 2 years ago. Ashley isn't convinced yet that doing so is worth while. Me I believe that object methods would improve coding efficiency and reduce poor event coding. Which is my main request why. However that's not enough.

And I also suggest the blog post should be taken with a grain of salt. I know of a game where the basic optimizations Ashley listed just didn't cut it. However when we went into micro optimization for mobile. The 5fps mobile game jumped up to 60 after a month of micro optimization. Then there was a discussion of why Spaceblaster runs descently on mobile where as newb game X does not. Ashley went on to list numerous micro optimizations based on knowing how canvas and webgl render. And yet there are claims to not to bother to micro optimize.
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,028

Post » Sun Jan 04, 2015 12:45 am

@jayderyu Wow. I'm not sure what to think about that :shock:
B
13
S
4
Posts: 280
Reputation: 1,578

Post » Sun Jan 04, 2015 12:49 am

ggibson1 wrote:The events are intentionally a subset of a traditional programming language. That is why they advertise "no coding required". For those that want to "do coding" that is what the JavaScript SDK is for.

This is true. I'll look into coding a behavior sometime very soon.
B
13
S
4
Posts: 280
Reputation: 1,578

Post » Sun Jan 04, 2015 1:56 am

I've also had some similar thoughts about doing Object methods. However my thought is to create a behaviour that allows custom javascript, and then passing the core object into the script. I was originally thinking of using Eval, then found out Eval is super slow due to not ever recieving JIT run time compilation. So I'm thinking of looking into a way to get the code into the JIT sooner than later.

It's not the same your request. but good luck. I would like to see self inference object functions. What would be awesomer would also be Object Triggers linked to to Events... drool

And to be fair in optimization. He has made a new blog going into understanding some of the micro optimizations. Such as batching sprite images to single sprites based on layers and a few others. however they aren't in the blog post posted for "Don't waste your time".
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,028

Post » Sun Jan 04, 2015 3:46 am

well, to be fair, micro-optimisation is always context dependant, if there is really a check of every instances with pick by uid, that would be bothering if your game needs it, but nothing if it was not that used in your game, same goes with collisions optimisations (even though those can be easily the bottleneck), etc... But in that case, if the pick by uid would be wasteful, that would be dissapointing.

always have a critic eye over ashley's blogposts, as he tries both to talk to people that can go really far in wasteful design and also he tries to be general and so, something true can become false depending on how you did your game (the recent render cells are a micro optimisation for a lot of games, it can even be worse, but in some defined cases, it is nice and can save out a lot of time), learning to identify what is really causing trouble is something that will help you in the long run.

also have a critic eye over other people talking about their experiences too, for the same reasons.
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
53
S
22
G
18
Posts: 2,122
Reputation: 17,123

Post » Sun Jan 04, 2015 5:19 am

@locohost
According to the change log "pick by uid" works with a single look up since r127
The condition 'Pick by UID' has been reimplemented to work with a single lookup, rather than iterating every instance. This should make it faster, but it also is now the one condition that is the exception to the rule about picking newly created objects in subevents, i.e. you can call a function on a newly created object, passing its UID, and successfully pick the instance, which did not previously work.

https://www.scirra.com/construct2/releases/r127
B
92
S
32
G
109
Posts: 5,290
Reputation: 70,991

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: AnimH01, MrQuickGame and 17 guests