skymen's Forum Posts

    Wait? Shouldn't that be the minimum? How are you suppose to extend C3 in any meaningful way with an API that isn't even flexible enough to create its own existing features?

    I thought these discussions are about things like Skymen hacking in the ability to have different sampling modes on different layers. Things that currently aren't possible.

    No, currently with SDK V1 here are the built-in addons that use undocumented features (and by that I don't mean easily replaceable ones, I mean the plugin is impossible without them or requires rewriting chunks of the engine):

    Plugins: 3D Camera, FlowchartController, ShadowLight, Sprite, Spritefont, Text, Tilemap, Timeline Controller, Drawing Canvas

    Behaviors: Bullet, Car, Custom, LOS, Persist, Solid

    Addons that use undocumented features for what I think are important features, but that can be worked around or removed for worse UX:

    Plugins: 3D Shape, 9 Patch, Particles, SVG, TiledBG, HTMLElement, Advanced Random

    Behaviors: 8 Direction, Move to, Physics, Platform, Tile Movement, Tween

    And here are ones that use undocumented features to provide slightly better UX (again, and said UX cannot be replicated) but otherwise fit perfectly inside V1:

    Plugins: LocalStorage, Audio

    Behaviors: Sine, Rotate, Orbit

    This list has been made by being reasonable on what counts as an undocumented feature, and what is just built in addons being better designed inside the engine.

    I am not making this list to ask Scirra to make addons using the SDK features because this is far from a viable option. I am just using these as an example of how low the bar is. When we say 3rd party addon devs have been asking for features we consider as basic, we do not mean "hacking in the ability to have different sampling modes on different layers". Not anywhere close.

    In fact, I asked that same exact question to Ashley 7 months ago.

    At the time, the answer boiled down to "don't make an addon then".

    For some addons, this can mean "use events", but for other addons, this means "don't make that at all"

    I'm gonna give one last thought on this subject. I personally think there is a huge difference between this, and what happened when C3 released, or with C3runtime or the modules change. For one the modules change often implied very minor tweaks so it does not count IMO.

    For the two other cases, the changes were indeed drastic, but they also came with MASSIVE benefits. Everyone happily obliged despite the required effort specifically because there was no debate on whether the new thing was better than the old thing outside of minor technicalities.

    Did we lose a few features in the move each time that made some addons impossible to port? Yeah, sure. But in return we gained a lot more, and C3 has evolved way beyond what we were hoping at the time.

    My main worry with SDK v2 is not that it is a breaking change, far from it. It's that it's a breaking change, and so far I am unconvinced that it actually solves the issues it's trying to solve.

    I can definitely see a scenario where everything turns out fine, and it actually leads to better cooperation between Scirra and addon devs, and we end up with a much cleaner addon ecosystem overall, but this relies on significant effort and goodwill from both parties. I wanna thank Mikal and EMI INDO for leading that march, by suggesting improvements to SDK v2 and upgrading the tools we use to be compatible with V2 already.

    I personally don't have much time to contribute anything meaningful just yet as I'm busy with a billion other things, but I genuinely hope to see things move in a positive direction by the time I can.

    At least, this is a good time to demonstrate the significant value provided for free by the goodwill of the people in this community. Many people (and not only addon devs) are working hard in silence to make Construct a better engine and to make its community more welcoming, and often don't get a lot of recognition for it.

    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.

    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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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.