Overboy's Forum Posts

  • Single features changing or even disappearing is something entirely different to obfuscate all internals at some point.

    And that was the question, "is it your plan to obfuscate all internals at some point?"

    That's a big difference in quality and quantity.

    ^ This basically

  • So you can guarantee the Runtime API won't become like the Editor API in the future where only the documented exposed stuff is accessible while the rest is obfuscated and impossible to use ?

    To me what you are saying here isn't clear.

    I think we all know about that warning and that we should use undocumented features with caution.

    The difference here is that you mentioned several times those past months that you would like those undocumented feature to be totally unavailable for us. Which is completely different

  • The only thing we want is to keep being able to access undocumented methods (that all official features relies on including all official Behaviors/Plugins that never changed in 6+ years) at our own risks when we need it. It's nothing like forking/hacking the engine.

    Anyway could you just please answer this simple question so we can plan our projects accordingly : do you plan to obfuscate the whole undocumented runtime and only let us use the documented features ?

    I think it would be fair to give us a clear answer

  • Hey Ashley, I totally understand why you're saying us to not use undocumented internals. It allow C3 to evolve pretty fast without Scirra needing to worry about rewriting some chunk of the runtime. You don't have to support indefinitely every method etc.

    However please, never obfuscate it / make the undocumented runtime unavailable.

    Being able to acces the runtime internals (at our own risk) is essential to allow us to workaround engine limitations or create very specific features we need for our own games and that Scirra couldn't want to implement (for legitimate reason - too specific, would bloat ACE lists, taking too much time to implement, too hard to grasp for beginners).

    For any complex game production no matter the game engine, the gamedev sometimes need to tweak, hack or extend the engine to make something work. I avoid it as much as I can, and I don't plan to release publicly addons making heavy use of it but for my own purpose, i need it very often and making it unaccessible at some point would just make any dev at the mercy of what Scirra has the time/wants to implement. (And most likely very specific issues hapenning on specific game productions aren't Scirra priority)

    I think the current balance is good: Scirra warn us to not use it, but advanced dev knowing what they're doing still can use it for their own purpose instead of spending months/years to beg for missing features that might never happen, or moving to an other engine.

    As Scirra has limited resources/small team and far too many suggestions this is the best balance for 2 reasons : Scirra can rewrite any part of the internal at any time AND If a user REALLY need a specific feature, at least he's able to do it using undocumented features.

    If this become obfuscated, we wouldn't have any ways to implement features ourself, the documented Addon SDK is just far far too limited. (and will always be, because no one knows what will be the very specific/advanced needs of any complex game production)

    I would definitely like to use that throughout our codebase

    Are you really considering to do it ? Your message could let us think that this is actually planned which would be really worrying. Could you give us any guarantee that this will or will not happen ? This kind of thing would have a major impact on my business and mid/long term plans. Imagine if you knew the Construct 3 engine you're developing for 15 years as a whole had a 50% chance to just permantently break with no workaround at any time because major Browsers decided to do so ? This is basically the situation you're putting some of us in with this kind of statement. (in fact it's even worse as we're paying a subscription to fund the development here)

    Some of us are C3 subscribers or customers for 10+ years and i think we desserve to know if such an important change is about to happen. If a game engine moves from "a workaround is likely possible if you really need something" to "no workaround no matter how experienced you are and how hard you try", it's not the same kind of game engine anymore.

  • Regarding the SDK integration itself yeah I agree it shouldn't be too hard to do for me or an other 3rd party dev.

    I was mostly thinking about guidelines on how to make a Construct 3 HTML export to work properly as an Embedded Game in Discord as it looked intimidating at first to be honest.

  • Discord launched a new Embedded Game SDK that will allow to ship webgames for Mobile/Desktop/Web via their platform.

    discord.com/build/embedded-app-sdk

    discord.com/developers/docs/developer-tools/embedded-app-sdk

    It looks like a big deal for webgames as new way to monetize and distribute them.

    Several other JS frameworks or engines already shipped or are working on Templates/Integrations for it. (Raylib/Phaser)

    Would Scirra be up to take a look into it and potentially provide us ways to ship to this platform ? :)

  • I'm actually personally running relatively low on new suggestions, and I'd rather see added robustness to the existing stuff. Aka more exposed ACEs, added functionality etc.

    But adding ACEs and tiny/subtle functionalities to existing stuff are in fact considered as feature suggestions. Most of the ideas on the new GitHub platform are about that

    (I could implement almost any ACE that were requested right now as add-ons if i wanted to btw - in fact 4 suggestions on the 2024 platform are already done in addons I released)

    So that would mean asking for an obviously missing ACE would be considered as the single suggestion you're able to ask. I find it pretty counter-productive and inefficient

  • There are 64 suggestions on the platform rn, not that close to 100 and it's normal it went fast during the first days because people posted their most wished/relevant suggestion from the old platform as there was a reset. We all make different games (Art-Heavy/Data-Heavy/UI-Heavy/simple hypercasual/Multiplayer/Performance-sensitive), for different platforms (Web/Mobile/Desktop/Consoles), have different skills (VisualScripting/JS/AddonDev/HTML/CSS/Shaders ?) so it's normal most suggestions don't please us.

    Again community voting is the best way to help prioritazing stuff we could imagine, no need to think too far and no one is expecting every single issue to be implemented in the last beta.

    Github provide a bunch of way to filter and sort issues.

    Just sort them from the "most recent" to see the new ones, "recently updated" to see recent discussions, or use searching syntax to filter only last month.

    For me the only annoying thing with Github is that the Likes are displayed only if you sort them by Likes. But you could still filter issues from last month only (or any filtering you want) + sort them by likes.

    Being able to add tags like "Behavior", "Editor" could help indeed but i suspect tags are reserved for Scirra to set status for the requests "In Developement", "Planned", "Will Not implement" etc. I wonder if using tags for both would be possible, it implies only a few tags are available to use for the users (categories but not development status), if it's possible it would be cool.

    FWIW Godot, the most "democratic" game engine out there also use Github issues, doesn't limit the amount of suggestion per user and don't care about having 3955 opened issues (with about 7 new ones per day), given their incredible growth and speed of developement i would say it works quite well.

  • Sorry, you're right. I always forget that our job is to overwhelm the engine developers with a ton of work.

    This u ?

    770 bug reports.

    I mean i'm thankful for all the work you put into this and it's useful for all of us in many situations.

    But please don't speak about overwhelming the devs, especially since all bug reports are always treated as urgent while it's not clear if anyone on earth will even face them once. There is not any kind of community voting/prioritization for bugs as opposed to feature suggestions. Also we all know feature requests are not meant to all be developed and pushed, only the most popular/easy-to-add/relevant, so it's less an issue.

  • Bugs are about technical issues, Feature request are about useability/UX/limitation issues.

    I would argue a painful workflow that the whole community is required to do every X minutes in the engine or a big limitation impossible to overcome no matter how skilled you are at JS/Addondev/EventsheetTrick is far more important to report and urgent than a very obscure bug that happens in 10% of the time when you smash your keyboard randomly in a full moon evening (especially since sometimes fixing that weird bug takes 50x more time than exposing an existing method to the Addon SDK for exemple and that would solve several of the most annoying C3 limitations in 1 shot)

    IMO, reducing the number of your bug reports to keep only the ones that actually matter wouldn't slow down the speed of developement of the engine, quite the opposite. But no one is trying to enforce Scirra to stop you from doing this, so I would appreciate if you let other users provide feedback to Scirra Team as well

    The community filters the idea themself thanks to the voting system.

    Reducing the number of idea reduce the quality of feedback Scirra receives, and will slow down the speed of useability/power improvement of the engine by not giving a chance of the tiny clever ideas to pop out.

    Also it would incitate users to request a bunch of things in a single request while it's more efficient if each thing is requested as seperate suggestions, or it would incitate to only submit the very big brand new feature stuff while sometime a "quick tiny" ACE/SDK addition can be a real game-changer.

  • The voting system is here to show what the community wants, knowing what a single user wants the most is irrelevant.

    Allowing 1 feature request per user would be as pointless and ineffictive as allowing 1 bug report per user. (which i think you agree would be annoying given the fact you submit more than 50% of all bug reports)

  • That being said Nested Families don't need a "parallel feature" or to break backward compatibility. It involves a lot of rework under the hood but it's not incompatible with the existing Family features and it wouldn't break any project if it was done someday.

    It wouldn't be confusing either if the family inheritance support was added some day. People who don't need it wouldn't see the difference and most people are actually confused it's not supported yet.

  • Ok I think I understand now. You want to create systems where some Nodes require to have multiple In Nodes like usual Shader Node Systems or Unreal Blueprints are working.

    I dismissed that kind of nodal usecase because I thought anything that looks like nodal visual scripting would be best achieved via regular top-down eventsheets.

    Do you have some ideas of cool systems it would allow us to build more easily than what we already had with existing features ? (given the limitations and the fact everything related to Nodes, and their in/out values would require long expressions and id or string checks ?)

    Im mostly thinking about the Flowchart feature has a way to create branching logic for things such as Quests/Dialogs/TalentTrees/StateMachines/BehaviorTrees/Cinematics, where each node could implement custom logic, which have always very tedious to deal with in C3 in my experience, because it doesn't scale well (and the issue persist with current Flowchart features).

    And in that kind of systems it makes no sense to limit the number of possible in or output nodes.

    This is why I want so much Nodes supporting Node Conditions and NodeEnter/Tick/Exit to be able to implement specific logic for each node via "Flowchart Sheet" (by overriding/extending their Node Template Logic and with better Node instance variable support) without the pain of error-prone manual work with many steps for every nodes we create + no quick Visualisation/Navigation help. (The Flowsheet as pop-up suggestion would allow to see both side-to-side, especially if we are currently creating a bunch of Nodes while building a Dialog)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • To be clear Overboy, I don't mean having them linked to the same values Outputs use. I mean having a second list for inputs like this

    This is a super quick mockup, as long as we can "name" inputs I think it's good enough

    Isn't it already how it works ?

    (it looks like a bit redundant with how it works right now + it would be a bit confusing and it involves the fact we need to manually add Input Value in addition to Output value which could lead to "misclicks")

  • I think linking inputs to "IDs" would let you get a parent by ID, instead of by whatever is already there.

    I can see a few reasons why this would be cool, but it's mainly for UX and just letting things be more open IMO.

    Just in general, having more control over how the input field works is good.

    Could also make it so we can write graph structures where instead of seeing this as a node structure, we treat everything as siblings and so any node can be linked to from either side.

    Let's say I use this as an FSM, having every single link go out from the node from the left side can be pretty painful.

    I still don't understand how it would help 🤔

    Being able to do FSM by linking later nodes to first nodes would be indeed very useful, as the posts of the first page of this thread explain.

    But what would be the benefit to connect a value to an other value rather than a node ? I can't find any example of usecase. You can already get any value from an output node anyway

    Also even if they are usecases, wouldn't it be unreadable and confusing ? let's say you have some stuff that have the whole Node as output and some other stuff that have values of this Node as output.