Hypothetical Event system redesign.

0 favourites
From the Asset Store
Create complex dialogues with ease with this tool/template!
  • 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.

  • My biggest complaints are dealing with multiple instances in collisions, and no logical way to have multiple "and", and "or" in the same event.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • 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[/p] 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.[/p] [/p] 99Instances2Go[/p] 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.[/p] [/p] newt[/p] 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.[/p] 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...[/p] [/p] sprite: x<0[/p] or[/p] sprite2: x<640[/p] sprite2: x>320[/p] [/p] sprite: sprite.x<0[/p] or[/p] sprite2: sprite.x<640 and sprite2.x>320[/p] [/p] sprite, sprite2: sprite.x<0 or sprite2.x<640 and sprite2.x>320

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)