skymen's Forum Posts

    I guess you haven't had to deal with desperate customers begging you to fix their ruined project and been unable to help?

    I've been doing consulting work on Construct project for many many years. Dealing with panicked developers begging me to help them fix an issue that might kill their games is a thing I do fairly often.

    Also, as a 3rd party addon developer, this is also a thing I do, and I've had to deal with it most of the time for free and on my free time.

    Please, please, please please please please don't do that.

    Please understand I am not saying that to make you panick, I am just trying to explain that things often take the path of least resistance, and with the way v2 is currently designed, I believe that this is a possible outcome that might happen.

    Again, I will always do my best to cooperate, but I cannot tell you with a straight face that no other dev will ever attempt this.

    The downside of accessing engine internals is ruining customer's projects.

    Also, please take into consideration that often not doing these changes might also mean the end of the project as well. If the "good" alternative means rewriting large chunks of a game's system which might take months, then it's just not going to happen. These developers are always on tight deadlines, and often with publishers looming, or with player sentiment dwindling, which means that it's often perceived as just as bad.

    Also, most of the issues regarding possible long term failure in the long run can be addressed simply by asking the developer to stick to a single Construct 3 version. This is also why I've requested multiple times in the past to let addons access the current version number to be able to properly gate against long term failure.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

    Even then, the more I think about it the more I realise that the way addon SDK v2 is designed right now can only lead to more issues, or less addons.

    In the future, when addon devs will inevitably reach the same problems we've faced with v1 (aka feature exists in C3 but is undocumented because arbitrary reasons, and Scirra doesn't want to add it because of other constraints) we will be left with only radical options.

    For example, I recently made a SetFOV addon that contains essentially 4 lines of code. These same 4 lines of code are now in C3, but at the time the only way to do that would have been to access runtime internals.

    For such an addon, the new way to do it according to the ideal design is to write my own camera system. However, the camera system in C3 is deeply tied to the layout system and the canvas renderer. So I need to rewrite those as well.

    So now, to be able to change the FOV of my game I am left with 3 options:

    - Beg scirra to add it

    - Do even more aggressive engine hacks

    - Write my own renderer

    None of these options are good. None of these options are workable.

    Let's take another example:

    In my addon Reset Variable, I access the class that manages the variables inside of C3's event sheet system. All variables (global, local, static) have an internal "reset value" function, but C3 only exposes an action to reset ALL global variables.

    There is no way to reset ONE variable, and there is no way to reset local variables (static or not). Which means the engine has a feature that exists, works and is just there, but does not use it at all, and does not want me to use it.

    With V2, I am left with the following choices:

    - replace the event variable class with my own class that gives me access, which is a BIG engine hack

    - write my own system that, every tick, tracks the value of event variables, stores initial states, and lets me set their values to the stored initial state. This would create a lot of issues related to state sync, because there is no way to be 100% sure the value I am currently holding is correct.

    - write my own variable system that is completely decorrelated from every other feature in C3.

    Again, none of these options are good, which means the only solution is to not make that addon.

    Now you might think "oh well its fairly easy to do this with events, just use another variable" however if you're doing this on a project with several hundreds of variables, there is no way in hell this will actually be feasible. And it's especially a bad idea knowing the feature is already there and works perfectly fine.

    One last example:

    In my addon LocalStorage Snapshot I am trying to solve an issue where a game has every system deeply integrated with LocalStorage and now needs to save and load everything to and from a file instead.

    What this addon does is use the undocumented features C3 has to get all the data currently saved to C3's localStorage system, package it all in a JSON string, and allows me to load that JSON string back into the system.

    The only way to do this with V2 would be to copy paste C3's localstorage system on both worker and domside and mess with the final indexedDB it saves to and pulls from, which might create conflicts. Also, if at any point in the future, C3's localstorage system changes, my addon explodes and creates issues whereas the first implementation has good chances to keep working, and even if it fails, it's very likely it's just a matter of changing what functions to call which is far easier to maintain that to rewrite the entire thing.

    These addons have all been made and published to solve very real problems people I've helped have encountered. The solutions are far from ideal, sure, but with addon SDK v2, the alternatives become far worse, and IMO, would lead to way bigger issues down the line.

    It reminds me of how back in the Construct 2 days people would copy paste addons, change 5 lines of code and republish them as "Text+" and that lead to issues whenever the main Text object would get a new feature because we'd now have 2 separate codebases to maintain.

    In Construct 3, this issue was largely avoided because the engine internals made it easy to do these simple changes while keeping the main code base the same, and while keeping the risks of failure relatively low. Losing access to this means the only alternative will be to go back to how things were done in C2 aka copy chunks of the engine into your addon just to be able to access one feature, or change one value.

    I'm sure additional tools will be developed, just as they were for Construct 2, to assist with the conversion of plugins from the old to the new system.

    It sure would be nice! I wonder what ethereal entity makes these tools.

    In general, I agree with the concept that the SDK v2 will be better in the long run, but it is very dismissive to look at what I and many other devs have spent years working on being basically rendered useless and say "eh I'm sure it's gonna be fine :)"

    I do promise I will do my best to port my own addons, cooperate as much as I can with Scirra, and help write any tools that could help with porting, but also there are 282 addons that need to be ported right now, just counting the ones listed on Scirra's addon exchange page (so excluding the ones on github, on itch and the ones made in private) and last time it took us multiple years to port like 100 of them from C2 to C3.

    I used to maintain a database of what was and wasn't ported back in the day, and looking at the list there are a good amount of C2 addons that were never ported fully to C3 (with C3runtime)

    wasthataddonported.surge.sh

  • Hi,

    does anyone have a good way to detect when the SOL is empty? Like I want to check when a given object type has 0 objects that fit into a filter. Right now I'm doing this, but I don't know if it's a good way to do it

    (The thought process being that if the SOL is empty, the condition will not run, and thus the else block will be true)

  • Hi,

    I feel this is a much better reply, and this is something I can perfectly align with.

    Again, I trust you with your expertise as you've repeatedly proven to make hard calls in good faith and I trust that you will abide by that once again.

    My main point during all of this was never to argue against what you feel is a move in the right direction, it's always been to convince you to be mindful of what you will hurt in the process. I am sure everyone here would love to help as time goes on to move towards a better designed SDK, so I just hope to see this move towards something that can still let us use the engine appropriately for our games.

    I just want to be able to keep using Construct for my games, that is all.

  • Again, I understand. But what am I supposed to do? Beg for features only for them to be added in 9 months on average?

    That's my entire point. There is no alternative.

    If C3 had a proper 3rd party addon versioning system like it does for vanilla addons, again that would not be as much of an issue. I could just make my addon for all the versions prior to the one that adds the feature in the future and all is well.

    But with both a restrictive SDK and a lack of versioning system, there is just nothing left.

  • The issue is not "not being able to customize the engine as much".

    The issue is the lack in alternatives.

    Currently:

    1) the documented API is not broad enough to cover every use case, especially for niche but very important features

    2) The ideas board is moving way too slowly to keep up with the needs of everyone, and there is no roadmap to even be able to tell in what vague direction Scirra is moving

    3) There is no proper channel of communication between Scirra and power users, so there is no way for us to help even if we wanted to.

    For years, this has left us with our only option being ignoring warnings and just using undocumented features.

    Let's take a simple example that has been hammered a few times in this conversation: my SetFOV addon. The addon is something like 6 lines long. C3 perfectly supports a variable FOV by virtue of it being editable in the editor. Changing it at runtime is as simple as updating the FOV value and updating the camera. This feature has been asked repeatedly pretty much ever since the 3D camera was released, yet it has still not been added by Scirra.

    In the future will we just be expected to sit down and possibly wait years for a feature so absolutely basic to be added, with no good way to even tell if it might be coming until it just appears one day?

    90% of my undocumented feature usage is for features you have partially exposed and so that I know you will absolutely maintain, but where the specific thing I need just isn't exposed for some reason. This is done with the knowledge that in the worst case scenario you might just rework the whole thing but you're not gonna remove it because the feature exists in the software (i.e. I know changing the FOV will not suddenly stop being possible because you completely overhauled the camera system, it will just need to be done differently)

  • Again, I understand your point and reasoning, but I frankly don't know how you can look at your userbase dead in the eye and say "this change you all unanimously find stupid is great for you actually".

    Maybe it will be in 2030 when the SDK v2 reaches a point of maturity where it's usable enough to make stuff with, but again the whole issue is we're all making games today not in 6 years. The scripting runtime came out years ago and it's arguably only reached "fairly usable" status this year. I have no reason to believe a complete rearchitecture of the SDK won't feel like 1000 steps backwards for the next 5 years.

    I still think a version range would be a good thing to do to neatly notify users that an addon might not be the right version installed btw, beyond all of this.

    + You say that people will be in development hell if they can't update due to a 3rd party addon but drastically changing the entire SDK structure sounds like the best way to make that happen on a large scale. Do you just expect people to port all of the addons to that new even more limited SDK for free?

    Hell, even if they wanted to, a lot of the most popular addons that have been commonly used for almost a decade at this point might straight up not be compatible.

    To me, this all sounds like the best way to create a mass exodus of users. Still, you seem dead set in doing things your way and there seems to be no words I can say that will convince you to listen, so all I can do is hope you keep your promise of actually doing your best to make that change be as non disruptive as possible for everyone. I will keep giving you the benefit of the doubt and trust your decisions, but you don't make it easy.

  • Hi, I feel the main point Ashley is raising is about addons breaking down the line for no good reason and users being mad about it and complaining to Scirra.

    IMO this would be fixed by just letting addon devs specify a version range for which addons are made for, and have the editor warn you that the addon may be unstable if the current version falls outside the range (with a button to continue at your own risk)

    That way, addons that can neatly fit within the SDK can just be infinitely usable, and addons that can't will let the users know.

    Add to that a field with a proper way to contact the developer that would be shown on that popup AND if the addon fails to load in the editor and it should be fine. It would also make it easier to use C3 with unstable addons as right now if an addon fails to load the editor crashes.

    + That would let you count these out of support range addons as a form of deprecated addons and you could hide them in the object selectors with a context menu option to show them regardless.

    I feel this would alleviate some of the concern and I personally would be perfectly fine building my addons for every stable version that comes out

    Also, about the text thing, unless I am mistaken this is still only me you're talking about and my stance has been clear on this. Break my addons if you want, I'll deal with it when I can. It's not like it's the first time you've repeatedly made deep changes within the text rendering + Animate Text uses litterally 0 undocumented features that you did not promise to provide. It's only just a call to WrapLines to get the line count back, and set typewriter progress to use C3's typewriter code instead of my own if possible but it fallsback to my own typewriter if needed. I have good reasons to assume that even if you throw out all of the text rendering code and redo it from scratch you will still have a way to get line count.

    99% of the code is my own and completely relies on BBCode and used the exposed SetText action to achieve everything.

    The only way for you to break AnimateText is if you decide to stop supporting BBCode, or stop supporting text.

  • I think you need to understand our stance on this Ashley while you are working on software architecture and striving to have something that will still work in 10 years, we are not.

    We are making games, and ask any game developer out there, from AAA to indie and they will all tell you that designing games like a software is itself a recipe for disaster.

    You are making a game engine, so I get that you need to have it work as long as you can, but at the end of the day you are making it for a crowd that actively depends on being able to break and hack stuff. You might think this decision is sensible for you, but it will be very hurtful for the bottomline of your userbase.

    If we reuse your car manufacturer analogy, that's like specialising in making cars used in rallies and complaining that people wanna mess with all the car parts. You can lock that down, but then the rally drivers will just look for another manufacturer. Sure you will be able to keep your parts secure but people actually competing will stop buying them.

  • I understand the reasoning, but also you need to understand why stuff like that happens in the first place.

    I have been making addons for 7 years now, and the overwhelming majority of the issues I encountered making addons for C3 has been the fact that the C3 addon SDK is very limited. I don't think anyone would be too worked up if the exposed SDK was more extensive.

    In fact most of the new addons made by Scirra use non exposed features. You also run into the same issues we run into and I don't think it's fair to say that for us it's not allowed because programmer god said so.

  • Jumping on this topic as well. Obfuscating the runtime will ABSOLUTELY break most of the bigger 3rd party addons, it will break a LOT of scripts and in general it is extremely hostile to any advanced user of the engine.

    To me this sounds like shooting your own foot with a shotgun because a fly landed on it.

  • If there is no editor for c3ide2, what exactly does it do for you?

    It still does the same thing, the only difference is that you fill out a much simpler JSON format and the framework compiles everything to a proper c3addon.

    In general, it offers more or less the same capabilities as C3IDE, but loses some of the editor capabilities (like dropdowns instead of a list of accepted values written in a comment). In exchange, it offers way more freedom to change about anything you need inside the generated addons and the structure of things.

    For example, I have used it to make it so scripting runtime can be auto filled by the framework for you, instead of having to define all ACEs a second time for the JS scripting side.

    In the same vein, I have used it to simplify the process of working with DOM side scripts, external scripts, C++ wrapper extensions etc, all of which C3IDE doesn't and can't support because of the way the editor has been designed.

  • C3IDE is pretty old nowadays and I don't think will be maintained in the future. I would recommend switching to C3IDE2 that has been completely remade to be faster to dev with and easier to maintain. C3IDE2 doesn't have an editor yet, but there are plans to make one in the future, however I can attest that it is overall smoother to use than C3IDE was.

    github.com/ConstructFund/c3ide2-framework

    github.com/ConstructFund/c3ide2-cli

    Also, I recommend doing addon work in two main passes. First you do the editor side where you define all the ACEs and properties of the addon, and then you do the runtime side where you actually implement the addon itself. Nowadays C3 can (or at least is supposed to) reload addon files from the dev server when you hit preview. I don't think this updates the editor side, but it does update the runtime side.

    An optimal workflow would be to open an empty project and save with your addon added, and keep reloading C3 and that project until the addon is set up. Once that's done, implement the actions you wanna test, and press preview every time you wanna test your implementation.

    C3IDE was also not really designed with that workflow in mind, as it assumes you will be implementing the runtime part of each action immediately after defining them. The new framework cleanly separates the two.

    Also, the new framework was designed to be used with all the advantages VS Code comes with, including generative AI to autofill repetitive tasks for you, so if you have Copilot, writing addons can be done much quicker as well. I would say to be weary of doing that because often Copilot can fill in the wrong things, and you can easily end up spending more time fixing its problems than actually just writing the code yourself. Keep that in mind if you plan to use it.

    Since the framework doesn't have an editor, creating new addons and starting the web server have been moved to the CLI instead. You can still do the process manually if you prefer though. Also each addon comes with an individual dev server script in case you prefer to work that way.

  • No, because in the case of "node templates" I might prefer to have the info of how many inputs are required directly on the node.

    Also, I want to get the parent by ID, if I have to check every parent, find the correct output that leads to current node, and then check the value, it makes something that's SUPER simple become so tedious it makes no sense.