[Answered]What are the limitations?

0 favourites
  • 7 posts
  • .

    Basic-ish questions, What are the limitations? (Of the engine, no license type.)

    I understand the fps limitations very a lot based on what your tying to run X on. (PC, Tablet, Phone)

    But what are the engine limitations, the mechanics point where it quits, invents errors, wont compile. (Does it compile? lets say run.)

    In Source, a door hinged to a door, hinged to a door, hinged to a door, hinged to a door, with a rocket tied to it, would be a physics bomb on the fps without VERY specific settings. What about Construct 2?

    Is a rocket tied down to a weight with three chain links each with two rotating points asking for trouble?

    In source, there are lots of limitations on the compiler, like T junctions for textures where planes intersect. Or vertexes which are the vertex points (corners) of brushes (shapes).

    Or entdata, which is entities talking to each other. (I/O Logic. Code.)

    How about Construct 2?

    Will it quit on me if I have 10,000+ sprites in the same game? (Optimized so they aren't all active (seen) at the same time... Actually, is there that kind of optimization in Construct 2?)

    Will it be mad at me if I have 1,000 lines of logic? (code in the Event sheet)

    Can it run Monopoly with eight players taking their turn at the same time?

    Can it run the same thing except 15 times more complex?

    Thanks,

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • If you expect to do everything with just physics, this may not be the perfect engine for you.

    The physics engine C2 uses is quite capable, but it is bound to the hardware capabilities, so your answer to all that is maybe.

    Then again I'm not sure you know this is a 2d engine.

  • .

    Yep I know it's 2d.

    I'm not so much worried about physics capabilities as I am logic capabilities.

    I'm curious what it will handle before it hits it's max. Is it limitless? Bound only to the speed, memory, space, etc of the computer running it? That would be cool.

    Source has an interestingly tiny limit of dynamic lights you can have on a single texture face. (4) if you had more then 4 lights that could turn on and off in the same room, your compile log would get smashed with lighting errors and in-game things would just look a little off depending on what lights you were using.

  • It's apples and oranges. C2 has no lighting system, and all logic is made by the user, run on the cpu, in events.

    It does have a limited shadow caster, but all official plugs are made to run on both webgl, and canvas, thus the limitation.

    Im sure an fx implementation of lighting is doable, and so is 3d, via third party support.

    Logic wise there are no limitations, however the proper use of events may take some getting used to.

    You might make up some mechanic, and have it working, but at a high cpu cost.

    Optimization does tend to be an issue for some users, however the forum is quite good at finding solutions.

  • Have you read https://www.scirra.com/manual/134/performance-tips?

    The most common limitations have to do with graphics memory, object count, and rendering/fill rate. These can be pretty much eliminated with good design. Otherwise, fine control over memory management is something that you might miss.

    I've seen projects with well over 1000 events... That is generally not a big deal. As I mentioned before, it is all about your design. For example, I can use a single event with loops and a ton of collision checks to slow rendering to a crawl.

    If you dig into the blogs, I recall seeing some example benchmarks for browser performance at some point, those may be of interest to you.

    I think you don't have to worry about compiling, ever. The program generally does a great job keeping you from making stupid syntax mistakes, as far as I've experienced.

    Honestly though, just try it! The free version has more than enough capability for you to try to push the limits of whatever you are trying to do.

  • .

    Awesome guys!

    Thanks.

    This helps me out a lot in more ways then one.

    Ossyrag thanks for the link. Hopefully this time next year I'll basically have its principles/tips memorized lol.

    My favorite thing in the digital creation world is a community willing to help both each other and the noobs like me. (Source had a lot of communities that were an ass to noobs.)

  • One limitation I do know is that, in a big project, with a lot of images, it is prone to crash due to a windows limit on how many images files can be used by a program, or something like that.

    there is I think an option to turn off icons to prevent this, but then again this is for very large projects with tons of objects that contains images.

    Also keep in mind this engine is thought for browser games first, and every export method (appart from cocoon.io as far as I know, and for iOS also) is basically a packaged version of chromium, I prefer to let you know that rather than being dissapointed, that does not mean it is incapable of handling large projects, it simply means it can be harder than expected.

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