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.
object: uid
|
|--visual: x,y,width,height,angle
|
|--sprite: anim, frame
|
|--tiledbg: offset[/code:3p95f9kh]
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