Quick question... can too many conditions lag your game?

0 favourites
  • 6 posts
From the Asset Store
A challenging game that needs quick responses!
  • Not including conditions that involve loops, since those VERY OBVIOUSLY lag games made in this engine...

    I'm wanting to ask if you can have so many conditions on a single event that it can cause it to start lagging a bit.

    If no, then good to hear. If yes... was wondering if someone can point me in the right direction on how to make more optimized events.

  • Its like a loop, it depends on what the events are doing.

    Obviously you should do you best to keep events from happening every tick, and you should design mechanics to be somewhat asynchronous.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Not including conditions that involve loops, since those VERY OBVIOUSLY lag games made in this engine...

    I'm wanting to ask if you can have so many conditions on a single event that it can cause it to start lagging a bit.

    If no, then good to hear. If yes... was wondering if someone can point me in the right direction on how to make more optimized events.

    As far as I know the overhead is the same as with regular Javascript. The exporter does a fabulous job at that.

    A small caveat: using the layout debugger causes more overhead.

    Concerning loops:

    Loops actually run pretty frigging amazing with cs3.

    It's all in the application.

    If you have tons of objects and loop through it to change one or two instances, you should have gone with picking.

    Or with loops, not needing to run every tick, gain huge performance increase when running it only like once every second, or every 10th of a second.

    There are manny ways to optimize or use a different approach that perhaps only uses a fraction of performance from how you tried to achieve it previously.

  • Ah. So... more or less it's a non-issue UNLESS if using the layout debugger

    so long you aren't using hundreds of events that go on an "every tick" basis

  • I usually tend to avoid using loops and the "Every Tick" events as much as I can unless if I DESPERATELY need to... like having tons of sprite objects be tied to eachother based on a variable choosing which ones to add.

    I suppose this answers what I asked.

    Thanks for the advice

  • Ah. So... more or less it's a non-issue UNLESS if using the layout debugger

    so long you aren't using hundreds of events that go on an "every tick" basis

    Well, the layout debugger can give a misleading representation of overhead. I seen various discussions here involving it over the years.

    Thought I'd point that out.

    Most its all a matter of application, in any language, applied wrong, results suck.

    And construct can definetly handle 100s or 1000s of events .... but it can take just 1 that drags the whole things down ^_^

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