Plugins/effects and C3

  • >

    > > digitalsoapbox I just saw Sombrero's recommended specs on steam.

    > >

    > > OS: Windows 10

    > > Processor: Intel Core i7

    > > Memory: 8 GB RAM

    > > Graphics: Nvidia GTX 980 or equivalent with 8GB VRAM

    > > DirectX: Version 11

    > > Network: Broadband Internet connection

    > > Storage: 500 MB available space

    > > Additional Notes: Best played with a 2 stick controller

    > >

    > > I think you should definitely use something other than Construct.

    > >

    >

    > Recommended specs will always be high. The minimum specs should be able to be much lower considering the 2D nature of the game, however because of serious limitations that are endemic to Construct's codebase, which are continuously denied but easy to spot just by looking at the engine code, that hasn't been possible. Even low resolution pixel art games stutter, and that's not just due to garbage collection.

    >

    > It's simply not a tool for any sizable - or sustainable - game development, period, in its current state. Or seemingly in C3, based on the expectations of either a browser-based or wrapped-browser IDE, on either desktop or mobile, and certainly not on any console, marketing claims aside.

    >

    > I'm not even sure the appropriate words exist in the English language to fully express the frustration I had getting even acceptable, let alone good, performance in Sombrero - and I've been dealing with web-based tech professionally for around 20 years. While I understand some (Ashley) will blame others for performance issues, that's simply not the case here - the engine just can't cut it for anything large, and definitely not anything that is meant to run at resolutions expected out of modern desktop games, 2D or otherwise.

    >

    > Don't even get me started on collision (or often, lack thereof) issues, unstable frame rates, buggy native behaviors that Scirra refuses to fix (jumpthrough issues, for example), or missing features that are common enough that I can comfortably say they're available with any other option natively - and by "natively" I mean the actual definition of the word, not the one that Scirra misuses all too often to obfuscate performance issues that can be linked directly to C2.

    >

    > Anyways, live and learn. There's other tools out there without these issues. I'd suggest looking into them. The event system is cool, but the albatross it's currently shackled to is held together with duct tape and bubble gum that's icky and gooey and the seams are showing.

    >

    This is the kind of dialogue that should be promoted and out in the open between high level developers and Scirra - have you provided isolated cases of your concerns?

    I have, but my experience so far has seen a refusal to admit need for improvement or understanding of what users who aren't just making simple mobile games or re-posting store templates on app stores are looking for in their development tools. It may be beneficial for Scirra to work more closely with some of their developers to understand what's needed, but maybe that's happening and we're all unaware...though it's not like there's really all that many larger games in C2 either way, which isn't a great sign.

    Here's a great example of the kind of issues I repeatedly run into when trying to push C2:

    • Create a new layout
    • Set the window size to 1280x720.
    • Add some sprites with collisions across all of it, or a tilemap with collisions enabled and some tiles placed in it that span across the layout.
    • On the start of the layout, resize the window size to 640x360.
    • Congrats! You've just broken collision cells.

    Of course, this could be easily remedied by providing an action to force a recalculation of collision cells...but we don't have that. I have at least a dozen more examples I could put down off the top of my head, but based on my experience with trying to get things improved/fixed in the past, I don't see any value in spending my time putting them together to then be ignored or called "not a bug" or "not a supported behavior." For example, issues with the jumpthrough behavior where the character just falls through platforms with no real explanation, especially on slopes - which has been reported multiple times over multiple years by multiple users. In the case of jumpthrough, it's clearly a bug being hidden behind a statement of "it doesn't support that," since it works 99% of the time but the desire to put forth the effort to fix the 1% of the time where it doesn't (edges of collision cells, certain angles at certain x/y locations, etc.) doesn't exist.

  • digitalsoapbox Don't get me wrong, I always like to see improvements. I also encounter the jump thru bug and some other weird problems. I wrote TNP's recommended specs because you said: "Recommended specs will always be high." And It sounds like every polished game should have VR Ready PC specs.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • What about having a basic plugin manager in construct3 - and a repository for the excellent work of REX and other contributors here.

    Is Ashley willing to officially support those plugins?

  • I imagine one of the many advantages of the browserification of C3 will be the asset store being baked into the editor - this combined with the new editor plugin SDK and the new features that will bring leads me to believe the editor will have plug-and-play functionality similar to editors like Sublime with package control.

  • digitalsoapbox Don't get me wrong, I always like to see improvements. I also encounter the jump thru bug and some other weird problems. I wrote TNP's recommended specs because you said: "Recommended specs will always be high." And It sounds like every polished game should have VR Ready PC specs.

    Well...maybe not VR for a 2D game .

  • Today's blog post confirms that c2 plugins/addons will not be compatible with c3.

  • Today's blog post confirms that c2 plugins/addons will not be compatible with c3.

    C3 plugs use json, and C2 uses xml.

    It should be fairly easy to convert them.

    Same for ico's, just no idea of file type.

    Im guessing vector which will require a bitmap embed for a simple conversion.

    I think Inkscape still does this.

  • It may be easy for some, but not for me (or a majority of C2 users I would imagine). I don't know how to convert xml to json etc. I would have to either wait for the developers to update the plugins or pay someone to do it. Rex has what? 100+ plugins? How long would that take him to update, even if he wanted to spend the time updating them. Using Podes plugins? Out of luck there too. What about the paid plugins that are no longer supported or have limited support? I wonder how many people use the cranberry plugings in their projects. Most of the plugins I use are from users that have already left the community or from Rex, who has so many that it will take a very long time to get them all updated. With that being said, I'm not surprised that the c2 plugins aren't compatible out of the box with c3. I never expected them to be. My concern is that users are going to be quite disappointed when they try loading up their project in c3 and it doesn't open.

  • The conversion between the two formats should be trivial, and would likely have a converter from the start.

    Think about it, why would they change it so much that it would make converting the official plugs an ordeal?

    Then the image format is trivial as well, you don't even have to have an icon.

  • It may be easy for some, but not for me (or a majority of C2 users I would imagine). I don't know how to convert xml to json etc. I would have to either wait for the developers to update the plugins or pay someone to do it. Rex has what? 100+ plugins? How long would that take him to update, even if he wanted to spend the time updating them. Using Podes plugins? Out of luck there too. What about the paid plugins that are no longer supported or have limited support? I wonder how many people use the cranberry plugings in their projects. Most of the plugins I use are from users that have already left the community or from Rex, who has so many that it will take a very long time to get them all updated. With that being said, I'm not surprised that the c2 plugins aren't compatible out of the box with c3. I never expected them to be. My concern is that users are going to be quite disappointed when they try loading up their project in c3 and it doesn't open.

    I would imagine that this is why the only parts of the "big" projects we've seen open in C3 are the title screens. The definition of "high fidelity" also seems to have changed from any I'm familiar with, if C3 is unable to use C2 projects that use any third-party plugins, which is, I would again imagine, most of them.

  • C2 plugins/behaviours are written in JavaScript. I doubt that changes in C3, but there are probably API changes needed.

    Effects are XML.

  • It's the project file format that's changing from xml (capx) to json (c3p). The plugins aren't affected by that. Any changes needed to port a plugin over are likely just busywork.

    Since c3 is primarily a editor rewrite, the runtime portion of plugins and c3's runtime such would be likely the same. Although any changes to c3's runtime would probably be a good thing.

    The edittime portion of the plugins is likely the part that would need to be re-worked, and that's actually the simpler part of the plugin. Probably most of that portion of the plugin could be converted over automatically, and only edge cases would need to be tweaked. That said people like rex probably wouldn't have any issue converting his plugins over quickly.

    At any rate, just let the beta come out and it can be figured out quickly. Scirra ported all the official plugins so I don't see an issue.

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