Will the top level design be removed in C3?

Discussion and feedback on Construct 2

Post » Wed Sep 30, 2015 6:44 pm

i was using containers as an explanation for how simultaneous objects should be created in general, not for your example. trust me, containers are GREAT, and they lower the amount of coding. also, when it comes to your example, i don't see the problem. random 1-3, have a var which defines what is 1,2,3, spawn depending on the number. also i was talking about design in general.

that's not true. during my time of development with c# / c++ i've noticed a lot of things that don't work as expected and need workaround because computers calculate them differently. the same is with this wait thing. you either accept it, or leave it. you will see much more trouble with unity / ue4 / any engine. but it all depends how masochistic you are
to work your ass off on something. and in the end it all comes down to learning how computers work, how interpreters work, how compilers work, to just fix that ONE bug.


of course it's not impossible that something relies on something else. but you used "on created" that was connected to another "on created" that was calling a function that does something. you can't do that in 1 tick since you've got a chaining of events. that's why wait (0) stops the chain before calling function for 1 sec so that the objects are completed and then continues from there to get the right values and print them out.

i'm pretty sure you don't know what happens, and how c2 engine works.
Sea Monsters template - Isometric
Also includes 40 pages PDF of optimizations and "how-to" for your games, and how the "sea monsters" template was built. Follow link for details :)

sea-monsters-templates-and-assets_t162705
B
43
S
14
G
12
Posts: 626
Reputation: 9,450

Post » Wed Sep 30, 2015 7:11 pm

saiyadjin wrote:i was using containers as an explanation for how simultaneous objects should be created in general, not for your example. trust me, containers are GREAT, and they lower the amount of coding. also, when it comes to your example, i don't see the problem. random 1-3, have a var which defines what is 1,2,3, spawn depending on the number. also i was talking about design in general.

that's not true. during my time of development with c# / c++ i've noticed a lot of things that don't work as expected and need workaround because computers calculate them differently. the same is with this wait thing. you either accept it, or leave it. you will see much more trouble with unity / ue4 / any engine. but it all depends how masochistic you are
to work your ass off on something. and in the end it all comes down to learning how computers work, how interpreters work, how compilers work, to just fix that ONE bug.


of course it's not impossible that something relies on something else. but you used "on created" that was connected to another "on created" that was calling a function that does something. you can't do that in 1 tick since you've got a chaining of events. that's why wait (0) stops the chain before calling function for 1 sec so that the objects are completed and then continues from there to get the right values and print them out.

i'm pretty sure you don't know what happens, and how c2 engine works.

Sorry Saiyadjin, but you speak to me like you assume that I have no clue how C2 works, which of course is fair enough if that's how you see it. But I did make you aware of this issue in the first place, which is known by Scirra, that it is designed that way. Why I asked about it in the first place. I fully respect if you do not see a problem with this, but that doesn't make it go away. And I made a simple example of how and when it happens, not because I was trying to show good design, but to explain the problem to those people, including yourself that related this issue to being maybe about the UI. If you have never used a wait() in your code to solve varies issues even though you knew it was bad, then I fully understand why you haven't noticed this.
Besides that im not comparing to other software solutions and whether they have problems or not, because its of no concern to me. But if you have experience with C++/C# you know just as well as me, that you would never solve problems with creating objects by throwing in waits(). So why you would even compare those with C2, im not sure of.

Besides that you have moved from my initial question, which I have no clue why you would even argue against in the first place, that if objects could be created so they exist instantly, that it wouldn't be better than having to wait? to how I made the example, which shows the problem and then explain to me, what happens in it? Since I made the example, im well aware of what it does, again it weren't made to show good design, but to show where the problem occurs and in what situations. And if you can solve it some other way under the same conditions that I put up, then I would be glad to see it and learn from it. But still why defend how it works now, if it can be changed in C3 so this wouldn't even be an issue, since this is a part of the core of how C2 works, it would make sense to change it for C3 if possible, which is why I asked the question and not to be shown 10 examples of how to use waits for varies things, that have nothing to do with what this is about.
Last edited by nimos100 on Wed Sep 30, 2015 9:07 pm, edited 1 time in total.
B
44
S
11
G
2
Posts: 1,182
Reputation: 6,848

Post » Wed Sep 30, 2015 8:11 pm

I'm guessing you're referring to when you can pick new objects.
New object's do exist instantly, but here's info on what's happens with regard to picking new objects:
is-this-a-bug-can-t-pick-objects-created-in-the-same-ti_p890954?#p890954

It's basically do to how the object filtering works in the event system. The question is how to implement it better.
Maybe having the ability to make lists of objects. It would be a bit tricky when dealing with destroyed objects though.

I'd like to think the whole event system could be overhauled to be simpler and more powerful. I've been trying to come up with a design that addresses things like picking two separate instances and this toplevel thing in a simple way. Imo a good design is key before I make argument how I think things could be better. Maybe eventually I'll find that holy grail of perfect simple design.
B
94
S
33
G
114
Posts: 5,360
Reputation: 73,781

Post » Wed Sep 30, 2015 8:58 pm

R0J0hound wrote:I'm guessing you're referring to when you can pick new objects.
New object's do exist instantly, but here's info on what's happens with regard to picking new objects:
is-this-a-bug-can-t-pick-objects-created-in-the-same-ti_p890954?#p890954

It's basically do to how the object filtering works in the event system. The question is how to implement it better.
Maybe having the ability to make lists of objects. It would be a bit tricky when dealing with destroyed objects though.

I'd like to think the whole event system could be overhauled to be simpler and more powerful. I've been trying to come up with a design that addresses things like picking two separate instances and this toplevel thing in a simple way. Imo a good design is key before I make argument how I think things could be better. Maybe eventually I'll find that holy grail of perfect simple design.


In the picking selection window, just add txt input where you place a name of "set pick group" , or even just a dropdown under same name with groups "A" "B" "C" and "D". Sorted :)
My professional Royalty Free Music at Scirra Assets Store
--------------------------------
Specs: i5 2500, 16gb of ram, gtx 770, win 7, Focusrite Scarlett 8i6, Mackie mr8mk2, Alesis 320, browsing the net on chrome.
B
92
S
30
G
22
Posts: 1,987
Reputation: 20,178

Post » Wed Sep 30, 2015 9:01 pm

R0J0hound wrote:I'm guessing you're referring to when you can pick new objects.
New object's do exist instantly, but here's info on what's happens with regard to picking new objects:
is-this-a-bug-can-t-pick-objects-created-in-the-same-ti_p890954?#p890954

It's basically do to how the object filtering works in the event system. The question is how to implement it better.
Maybe having the ability to make lists of objects. It would be a bit tricky when dealing with destroyed objects though.

I'd like to think the whole event system could be overhauled to be simpler and more powerful. I've been trying to come up with a design that addresses things like picking two separate instances and this toplevel thing in a simple way. Imo a good design is key before I make argument how I think things could be better. Maybe eventually I'll find that holy grail of perfect simple design.

Yeah think you make a good point and recall that thread you are linking too as well. How to solve it is of course the whole issue, also why I was curious to whether it was on the table when designing C3.

One way I thought it might be possible or at least worth a consideration, could be something in the lines of creating "temporary" objects/data. Meaning that when a create takes place, all the information is stored temporary until the actually creation takes place, said in another way. Because you of course is correct that the object is created. But in lack of better terms I just refer to it as "not being created". But what I mean is that during the period until a top level is reached, maybe the information could be stored and all interactions etc. would then be done on this temporary data/object and copied to the actually object when its ready. If that makes sense? But whether something like that is possible, a good solution or even worth it, I don't know.

But that way you would be able to just destroy the temporary data, instead of the actual object, or said in another way never create it. Anyway just some thoughts about it. Hopefully Ashley have already figured something out, if its of course being considered :)
B
44
S
11
G
2
Posts: 1,182
Reputation: 6,848

Post » Wed Sep 30, 2015 9:38 pm

The reason objects aren't pickable until the next top level event is an architectural detail. It actually used to make them pickable immediately, but it led to crash bugs, so the existing system is a workaround to those bugs. The problem is that to make an object pickable it needs to be added to the set of instances in the object type, but conditions iterate this set when evaluating conditions. For example think about this event:

+ For each Sprite
-> Create "Sprite"

"For each Sprite" will iterate every Sprite instance, but the event itself modifies the set of Sprite instances. It's difficult to handle this case correctly without introducing a global performance impact to the event system, because every condition has to constantly check if the set of instances it is iterating has changed. (It's also interesting to think about how this event would turn in to an infinite loop if it also iterated the instances it just created!)

The actual bugs IIRC were even more complicated, involving sub-events and function calls, which ultimately led to an instance being created half-way through the evaluation of a condition that was testing the set of instances in that object. In order to handle this case, created objects are picked (so you can access them in the event immediately), but they are not added to the set of instances until the end of the top-level event, which guarantees no conditions are iterating them. I thought about only doing this when this mid-iteration case was specifically identified as happening, but I thought it would be better to be always consistent rather than doing something subtly different depending on the parent events/function call context which would make for some pretty maddening debugging. So created instances don't "really" exist until the next top-level event, although they are picked.

It's hard to see how this could really be different. We could make it only do the workaround when it needs to, but being slightly inconsistent depending on the context is generally a terrible idea, because in practice it means unpredictable consequences. We could add them to the instance lists immediately, and then a bunch of games start crashing. Or we could add a check to every condition to verify if the instances change while it is iterating them, which adds a performance overhead to every event. Given these options, leaving it until the next top level event is the best option IMO.

BTW the stated goal of C3 is to rebuild the editor and keep the same runtime, so this is not really the kind of thing we intend to change anyway in the scope of that project.
Scirra Founder
B
400
S
237
G
89
Posts: 24,550
Reputation: 195,527

Post » Wed Sep 30, 2015 9:43 pm

@Ashley What do you think about my idea of creating temp groups while picking, by assigning them to selected group?

"In the picking selection window, just add txt input where you place a name of "set pick group" , or even just a dropdown under same name with groups "A" "B" "C" and "D"."

This is not related to picking at creation, but it would be useful to pick few objects of the same type, and it would be better then using families.
My professional Royalty Free Music at Scirra Assets Store
--------------------------------
Specs: i5 2500, 16gb of ram, gtx 770, win 7, Focusrite Scarlett 8i6, Mackie mr8mk2, Alesis 320, browsing the net on chrome.
B
92
S
30
G
22
Posts: 1,987
Reputation: 20,178

Post » Thu Oct 01, 2015 6:10 am

Ashley wrote:+ For each Sprite
-> Create "Sprite"

"For each Sprite" will iterate every Sprite instance, but the event itself modifies the set of Sprite instances. It's difficult to handle this case correctly without introducing a global performance impact to the event system, because every condition has to constantly check if the set of instances it is iterating has changed. (It's also interesting to think about how this event would turn in to an infinite loop if it also iterated the instances it just created!)

BTW the stated goal of C3 is to rebuild the editor and keep the same runtime, so this is not really the kind of thing we intend to change anyway in the scope of that project.


It had of course crossed my mind since you have already stated in the C3 presentation that C2 projects are compatible with C3 that this of course could cause some problems if something like this were redesigned.

But as I suggested with the temporary objects/data, couldn't that be a viable solution, for in the example that you made with the For each Sprite, Assume you have 5 Sprites (Existing instances), So for each of these, a temporary object is created. So even though there now are 10 objects in total, only 5 of them are on the "Existing instances" list and 5 is on a "temporary instance list". So at the point the for each runs it will only include the 5 "existing instances" as the temporary ones are not currently sharing this scope. So imagine you apply yet another For each Sprite after the last one, it actually knows at this point that 10 exists as it include or checks any former created temporary lists, so it will create a new temporary instance list which will hold the new temporary instances, in this case 10. So to put it visually, it would look something like this:

5 (Existing sprites list)
5 (Temporary sprites list 1)
10 (Temporary sprites list 2)

So still you could update these objects as if they were all part of the same instance list, but would make some of the changes to the "Existing sprite list, some to temporary list 1 and 2. When the process at some point hit the top level all instances are then moved to the normal "Existing list". But whether that would ruin the C2 projects or even work im not sure of, at least not if some sort of fail save weren't added. Maybe it could know that if its an original C2 project it could simply not make use of temporary lists, or it could ask the user if they wanted to update there project to a C3 one, and what problems might occur. So users are left with both options.

Would something like that be possible, assuming that this was on the agenda for C3, which you of course have already mentioned that its not? :)

Because if you look at the example I made earlier in this thread, and assumes that for some reason this was an important game mechanic. How would you go about solving it, with the way that it currently works, because I don't find it an unrealistic scenario?

Anyway cheers for sharing your thoughts on this matter.
B
44
S
11
G
2
Posts: 1,182
Reputation: 6,848

Post » Thu Oct 01, 2015 9:48 am

The "temporary sprite list" is pretty much exactly how it works already, and it moves those instances to the main list at the end of the top-level event. However if every condition also checked the temporary list as well as the existing list, that would add a performance impact to every event again, since now every condition has to check two lists instead of one.
Scirra Founder
B
400
S
237
G
89
Posts: 24,550
Reputation: 195,527

Post » Thu Oct 01, 2015 10:17 am

Ashley wrote:The "temporary sprite list" is pretty much exactly how it works already, and it moves those instances to the main list at the end of the top-level event. However if every condition also checked the temporary list as well as the existing list, that would add a performance impact to every event again, since now every condition has to check two lists instead of one.

I see.
However im a bit confused why it would hurt performance. Because wont it be the same in the end anyway? For example we create 100 objects which are transferred to the main list at the end of the top level, and this is what confuse me. Because during the next tick, all 100 objects will be on the main list so whatever condition that would check these objects would apply to all 100 objects. So the performance impact happens from the period of creation to the end of top level, when working with the temporary list?

Since im not 100% sure to be honest what these lists are, but assumes you mean they are stored in memory? it might be what confuses me a little. Because if we assume that in our game we have at max 1000 objects at a given time and for the sake of argument the temporary list is checked as well. So we have two scenarios, this is just so I understand what you mean:

A: There are 800 objects on the main list and 200 on the temporary list
B: There are 150 objects on the main list and 600 on the temporary list

So if I understand you correct, the performance impact would be higher in scenario B than A, if the temporary list was checked as well?

And to further extend this and we remove the check of the temporary list, using the same scenarios.

Then during the "tick" of creation until the end of top level, you would have better performance in both scenarios due to not checking the temporary list, but the next tick. You have 1000 objects in scenario A and 750 in B. Hope you see what I mean when I ask if its not the same in the end? or did I misunderstand you?
B
44
S
11
G
2
Posts: 1,182
Reputation: 6,848

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 3 guests