Hypothetical Event system redesign.

Chat about anything not covered in these forums, but keep it civil!

Post » Thu Apr 07, 2016 4:16 am

@animmaniac
I haven't given a whole lot of thought how the event wizard would work with the design. Right now the design is like typed code to show what you can do. Things to help you do it would come later. Ideally though if you had an action like:
Sprite.setPositionTo(sprite2)
You could click on sprite2 and it would give a list of objects.

In fact actions and conditions could be added in the same way as you can now in c2. Expressions are the main thing that is being revamped.

In that function "a" is replaced with whatever object type you call the function with. So if you called it like this:
Call indist (sprite, 100,100,50)
"a" would be Sprite. It's basically another way to make things more generic.
B
91
S
31
G
103
Posts: 5,234
Reputation: 67,754

Post » Thu Apr 07, 2016 6:35 am

How about inline vectors?
OK yeah, I know...
Image ImageImage
B
168
S
50
G
163
Posts: 8,223
Reputation: 105,065

Post » Thu Apr 07, 2016 7:54 pm

R0J0hound wrote:In that function "a" is replaced with whatever object type you call the function with. So if you called it like this:
Call indist (sprite, 100,100,50)
"a" would be Sprite. It's basically another way to make things more generic.

Yeah, that part I get it and would be very useful. My main doubt is how to make this viable.

From my perspective, in order to make it work the "a" would need to be a sol variable previously defined and limited to only one object type, in this case "Sprite".
Otherwise you could call "indist(sprite, 100,100,50)" or "indist(tiledBG, 100,100,50)", two different object types with different specific conditions. So when placing the condition you would need to select the condition inside a list of an object "a", of the type "sprite", that would temporarily appear into the object list (like local variables do). If not, how would you deal with different object types that have specific conditions not present in other object types? Like you could call both a sprite or a tiledBG, but they don't have the exact same condition set (like "animation is playing" for instance).

Unless all the object types have a common subset of conditions (like position, size, opacity...) and you can only use these when picking an object through a variable (like "a"), and select them through the system object.

*Actually I have some ideas for families with multiple object types that probably could help with this. When I get more time I'll post them.

newt wrote:How about inline vectors?
OK yeah, I know...

Well remembered. It's something that would be great if could be incorporated.
Scirra Employee
B
148
S
53
G
17
Posts: 711
Reputation: 17,700

Post » Fri Apr 08, 2016 1:29 am

SOL could be treated as a set of UID.
I had made a plugin named instance group before, it stores instances by UID in a dictionary structure for set operation, and it also has another array structure for sorting.

Maybe scirra could provide a similar plugin officially, with more powerful features.
B
108
S
26
G
259
Posts: 4,430
Reputation: 145,679

Post » Fri Apr 08, 2016 10:22 am

@rexrainbow

We all know the main annoyances. (I did not use the word problem)

1/ The Forum is filled with poeple asking for assistance with de Selected Objects List.
2/ Most beginners (including myself) have a hard time with understanding the relation between subevents and a previous made Selected Objects List.
3/ Most beginners (including myself) seem to have troubles with visualizing the Selected Objects List after a pickevent and wich objects will be passed to the actions.
4/ Most beginners (including myself) seem not to understand the difference, in relation to picking, between system based comparing and object based comparing.
5/ Most skilled forum mumbers seem as they gave up on answering the same question over an over again.

This is a very good example: forum/is-this-a-bug-in-construct-with-or-statements_t170213?start=10

Its is my sincere understanding that those annoyances can be solved by a (optional: you bring it in the layout or not) dictonary holding the SOL. Debugging would be a lot easyer for beginners. The learn curve would be a lot flatter. And it can be a big help with advanced picking.

I know that this is totaly no issue for the skilled people. But. Think back at your first days with Construct. Even when that were the Classic Version days (like in my case).

Hope i made my point, not gooing to nag more about it though.
B
33
S
18
G
27
Posts: 2,447
Reputation: 20,358

Post » Fri Apr 08, 2016 2:38 pm

@99Instances2Go

Agree. I still fall into the trap sometime until today. A possible solution is to print current SOL on console by UID list, or the count of picked instances to trace it.
B
108
S
26
G
259
Posts: 4,430
Reputation: 145,679

Post » Fri Apr 08, 2016 2:54 pm

My biggest complaints are dealing with multiple instances in collisions, and no logical way to have multiple "and", and "or" in the same event.
Image ImageImage
B
168
S
50
G
163
Posts: 8,223
Reputation: 105,065

Post » Fri Apr 08, 2016 8:15 pm

@newt
I'd imagine that'd be doable with an overhaul of expressions. My hypothetical would have it in mind. It's often hard to change an existing system to allow it, but a redesign can allow it. The freedom of my design is I'm ignoring all issues of backward compatibility, which Scirra has to deal with carefully.

@animmaniac
For that I was kind of imagining kind of a hierarchy of types or something. Limiting to common features is another thought, but I understand Ashley's point stated elsewhere where expressions can mean entirely different things for different objects, so it'd not work.
Code: Select all
object: uid
|
|--visual: x,y,width,height,angle
   |
   |--sprite: anim, frame
   |
   |--tiledbg: offset


Another sloppy idea would be to either do nothing or cause an error if an expression was used that the object doesn't have.
But basically my design is glossing over the problem by assuming pretty much only one kind of object.

@rexrainbow
The idea is similar, but I'd also like to explore the idea of not using UID's like we do now since they're a lot like pointers in c. Using an array or dictionary is more in line with normal coding. I like the picking system C2 provides and would like to design it so it acts pretty much the same.

@99Instances2Go
Those would likely be mitigated by being able to see what's picked in the debugger and being able to step through it a condition and action at a time instead of only a event at a time. Advanced users do this manually either on paper or change opacity or something to visualize it when running the game.

@newt
Having "and" and "or" in the same event makes sense for simple stuff, but in other ways it doesn't seem intuitive to me. C2's "or" event is already kind of like that to me. I'm never sure of it's behavior when two conditions of different objects are used, instead I have to verify what it does in events.
In my design i'm probably side stepping the issue by making the expression based solution, often used in C2, easier. Here are some possible solutions, but it probably needs more exploring because it should work with triggers and loops to...

sprite: x<0
or
sprite2: x<640
sprite2: x>320

sprite: sprite.x<0
or
sprite2: sprite.x<640 and sprite2.x>320

sprite, sprite2: sprite.x<0 or sprite2.x<640 and sprite2.x>320
B
91
S
31
G
103
Posts: 5,234
Reputation: 67,754

Previous

Return to Open Topic

Who is online

Users browsing this forum: beemccullah, Gear games, kklps113 and 1 guest