skymen's Forum Posts

  • 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

  • It wouldn't make sense to link an input to a value, so the way it works right now is good, a whole Node can have different input Nodes !

    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.

  • Nodes can't have multiple inputs AFAIK

    They can, it's just that you can't link an input with a value the same way you can with outputs

  • In the example the output values are used as raw text, but they don't need to be used like that all the time. They could be ids to a dictionary. With a few events it would be relatively easy to pick up the real values from the dictionary using the ids from the node outputs.

    I disagree on that point, because being able to save and load flocharts at runtime would be amazing for moddable content. Also in some languages it might be required to split a given dialogue message into 2, or remove one option entirely (for any reason that might occur during localisation) and having the option to have separate flowchart files one can load can come in very handy.

    Although, for most projects linking to a dictionnary will still be the best use case, having the alternative would be great!

  • Oh wow, this is some amazing news. There has been back to back absolute treats lately, thanks Ashley 🙏🙏🙏🙏🙏🙏

    It would be cool to see the quadtree method adapted to work as a 3rd party addon. I could help with that as I think there is still some value in having it as an alternative collision algorithm.

  • Well Ashley I am glad to know my way of doing things is at least working. If in the future a disaster happens because of my own addons, please let me know and I will do my best to help in any way I can, as quickly as I can.

    About Animate Text, while I know it was hypothetical, I think it's still a great example: My addon does exactly what you suggest it does, and still I have to use undocumented features of the engine to make it work.

    Animate Text does not have any "hacks" in it as I offloaded all of them into my Experimental Text Fix addon. I made sure not to change any parts of the engine for my addon.

    Now you might think that everything you mentionned should and would absolutely fit inside the documented features but in fact they dont. I will refrain from going too much into the specifics to avoid derailing the subject, but in short I do my best to work around the limitations.

    I rewrote code that I know is in the engine but don't have access to because it's "reasonable" for me to do so. (Like easings, tag parsing and typewriter) I even rewrote a bbcode parser to handle special cases like icon tags and tags with no params for animation before giving them back to C3's BBCode class.

    Now, doing this means there will be very specific details that I cannot do without using undocumented features (or rewriting huge chunks of the engine). Very tiny details that make all the difference and that most people will be bothered by. These things I cannot work around, and most likely my addon is the only existing use case for having them available, so they will probably not be exposed.

    In this case what am I supposed to do? Drop the whole addon because of one implementation detail? Ship without a core feature of the addon? Beg for months for a super niche feature that we all know full well will not be exposed to the SDK because nobody will ever use it ever again after me? Or just use undocumented features and maintain it when it breaks?

    In fact this is what I think Ruskul meant by

    Basically, its seems like Scirra recognizes the need for engine tweaking to support behavior interaction, but is adamant that isn't how you should develop (do as we say, not as we do). So instead you end up with behaviors that, in order to function correctly, need some back and forth boiler plate added either to the event side, or through scripting.

    If the addon was made by Scirra this would not have been a problem at all, because you can just accomodate just fine for these kinds of minor changes. These kind of mini tweaks are done all the time in vanilla addons, and most of the time they are not exposed to the SDK because they are so niche it's reasonable to think no one will ever need them again.

    Now, Animate Text is an outlier in the fact that it's the only addon I don't advertise as "Experimental" or "Unstable" while also relying on using undocumented features for a core feature. That's mostly because said undocumented feature is accessing your line and fragment count after your tag parser runs, and it's VERY reasonable to assume you will not remove line and fragments from your text renderer. Even if you break my code and change your entire architecture, these info would still be there somewhere. I can always fix my addon ad vitam eternam.

    Anyway, this is mostly why I keep doing stuff that way. I make cool addons, make them available for free and make them open source. I keep maintaining my addons, and provide support for free as long as I can, and do my best to stay out of your way. In turn staying out of your way means not clogging the ideas board with sdk requests I think are useless to the community at large and doing whatever I need to do that's reasonable.

    Staying out of your way also means that sometimes to prove an idea is doable, there is no better way than to just make it happen and show the result. Stuff like dynamic layers I've been asking for 5 years, and they were finally added as soon as I was able to prove the concept worked by making an addon that does it. I see no way of doing that without dabbling in a bit of engine hackery.

    Anyway, I think we both made our points clear and I don't wanna engage in this SDK topic any more. Most other addon devs will agree that we do not want to bother the Construct team by making addons, far from it. I know Mikal for example has specifically avoided using engine hacks or undocumented features in his released addons for the reasons you outlined, and he has half a dozen proof of concept addons he is sitting on for the day they are possible without engine hacks.

    Now they're in development hell: they can't stay on the current version of Construct because it's got a showstopper bug. But they can't update to the newest version of Construct with the fix, because the hack they used in their project won't work. They have no good options and can't rely on official support.

    About this: I've been doing consulting work on many games for a while and from experience, this does happen. It's just that it's never EVER that simple. And it's not only on Construct, this kind of stuff happens all the time, because it's expected when making larger scale games. You WILL write bad code that WILL cause problems. You WILL stop updating your engine (not only due to hacks, but also to avoid regressions, and to make the engine codebase more stable for late development) and you WILL cry because an engine bug was fixed 10 versions later. You WILL learn to deal with it, and you WILL find a way to still release.

    You are not lucky, you are just hoping not to be asked to deal with a problem most game dev teams are already dealing with themselves.

    Astral Ascent is one of the biggest Construct games, and having read the code, it's a Construct game that scaled FAAAAR beyond what anyone in this thread seems to be able to imagine using Construct's core features. They have ran into MANY issues, as you do when making games and they have just dealt with it. They have locked their engine version to r225 that released 3 years ago.

    In general, in game development if you start a large project, it's common practice to not update the engine that's under the game too much in the process because you risk creating regressions and unforseen issues. Stuff you cannot just see coming when writing backwards compatible code, or even just by using documented features. Updating the engine should only be done very carefully when you make 200% sure you absolutely need whatever fix or feature was added. It sometimes takes weeks to properly update, and in some other engines, the team are sometimes dedicated to remaking the entire game from scratch on the new engine version.

    In Construct games, it's often not that dramatic because of the backwards compatibility work being done, but also because there are very few large Construct projects that have full teams collaborating on them. So we just forget how things are supposed to be done and complain when we hit the same walls we've been warned about.

  • I am sure people would still ignore the warnings, cause compatibility disasters for themselves including corrupting their projects, and then contact support and ask us to help rescue their project. Or we update Construct, it breaks the custom code change, and then the situation I described previously plays out again.

    Well, let's speak concretely as I am genuinely curious:

    I often make hacks of the engine, publish addons that break the rules, and lately I've even delved much deeper into engine hacks.

    I've always tried to do my best by being vocal in the community so users who use my addons know who to come to when an issue happens. If an addon of mine gets broken by an update (most likely Animate Text), I do my best to fix it while the engine is still in a beta cycle. I beg users to report stuff to me, and only me, and I always try and fix it as soon as I reasonably can.

    For more hacky addons, I provide warnings, call the stuff "Experimental", make it painfully clear that using the addon is at your own risk, and when the addon actually does break, I warn everyone I know has been using it on a larger project, and give them ways to either remove my addon, or update it so it works again.

    For some other addons, I've even marked them as deprecated so they don't appear in the addon search, and people who aren't aware of my work can't break their project.

    I do all of this because the LAST thing I want is for some entitled customer to come to Scirra and bother the team for an issue I have caused and I am perfectly willing to fix.

    Now, what I want to know is:

    - Has this happened?

    - What can I do to minimise the chances of this happening? (I mean besides respect the rules since you've already made your point very clear, and we both agree that if I didn't use undocumented features, it wouldn't happen anyway)

    Now, I hope you can understand that in many cases, Construct users find themselves needing a very specific feature for a very specific project, and it is simply not an option to:

    - Ask for it and wait

    - Ask for the SDK changes and wait

    Often in those cases, the only choices are:

    - Mod the engine to add that feature

    - Drop that feature

    Which is not an easy choice to make, and me as an addon dev, I often make the choice to write an addon that does add the feature, and keep it up to date as long as I can, while providing free support on work I'm not even paid to do. I've been happily doing that for the past 6 years, and it's always been done thinking about the possible effect this can all have on Scirra and trying to find ways not to be too much of a problem.

    If I am a problem however, I would like to know, and I will do my best to minimise that.

  • How can you deal with global space bloat in a large project without simply having to "get over it". For someone with pretty bad adhd, I have a aneurysm when autocomplete lists literally every function or object in the the game. The real big appeal to construct is how sleek it can be, at a smaller scale. It isn't that you can't scale in construct, its just that it you do have to just "deal with things" that you don't in other environments.

    I understand the point and I have a few tips for that.

    For object types, the search bar is focused by default, so typing the name of the object will filter it immediately.

    For global variables, instead of using them as is, I use a global object type and instance vars. This plugin was designed around that idea: construct.net/en/make-games/addons/539/globals-c3runtime

    But you could do the same with an Array, Dictionnary or JSON object. (globals is just the same but with none of the data management features). This makes global variables hidden behind an object type that you can name whatever you like. In practice it works like variable folders.

    For groups, I name them as "Parent Child SubChild" where each sub group takes its parents name and adds something at the end. This makes it infinitely easier to sort through them when enabling/disabling groups. It also makes sure there will never be name overlaps.

    For functions, one thing that can be done is using custom actions instead on a globals/array like object. Custom Actions are similar in functionnality to the new functions, and adding them on unique global objects makes the object picking do nothing, so you end up with functions, but stored in objects. It can't do custom expressions though.

    Overall, there are a few organisation tricks, and learning keyboard shortcuts, I end up mostly never using my mouse when writing events, and I never get lost searching for stuff.

    Basically, its seems like Scirra recognizes the need for engine tweaking to support behavior interaction, but is adamant that isn't how you should develop (do as we say, not as we do). So instead you end up with behaviors that, in order to function correctly, need some back and forth boiler plate added either to the event side, or through scripting.

    TLDR, its hard to take such advice seriously when the Scrirra team authors behaviors that need engine tweaks in order to function (shadow caster, platformer, solid, dropthrough, etc... all have some internal engine stuff if I recall). Its frustrating in many cases and makes the itch to switch pretty strong.

    I deeply agree with that, and it's more or less why I have respectfully ignored such advice in the past. On the other hand, I can understand not wanting to do the extra work to "release" the hidden parts of the SDK, and also not wanting to deal with angry customers coming to them because a 3rd party addon broke.

    So there is a gentleman's agreement where I will keep fixing my stuff, but they will accept that I will frequently just completely bypass the limitations of the SDK, to the point where I have now released multiple addons where the core functionnality entirely relies on deep engine hacks.

    I don't agree that the SDK should only be used to add 3rd party services. In fact, I think JS is a FAR better solution for integrating 3rd party services because of how detached from the engine they are, and how much iteration is needed on them. Something like an ad provider for example might need frequent tweaks, updates and you might not implement all of it in one go. Having it as a JS script in your project that you can change is a much better workflow in my opinion. The addon SDK is definitely not designed for quick iteration and an ongoing list of small tweaks.

    Instead I think the addon SDK is amazing at adding functionnality. Extending the engine with new features, and adding "premade" stuff everywhere. It is what 90% of the vanilla addons are doing, I don't see in what world it wouldn't also be 90% of 3rd party addons. If you ask ANY construct user what the addon SDK does, they will answer "do stuff like add platformer, physics or keyboard" and never ever "support newgrounds"

    Also, there is a big topic about the a good chunk userbase of Construct not being able to code. Making addons that add features to the engine is the best way to share reusable code, and is IMO the best design paradigm not only in Construct but in all game engines. Having the entire engine's features be "a la carte" is phenomenal.

  • This doesn't have to be something completely open in the public if there is a fear of discussing features that might never actually arrive, but maybe specific people like R0J0hound, Overboy, skymen, Mikal, etc. could be involved in giving their thoughts and early feedback before production even starts (If they would be willing to spend some of their time on this).

    I would be very down for this to be honest. I know other engines have a similar thing with an insiders program, where handpicked ppl have a communication channel under NDA.

  • I understand where you're coming from Ruskul but I don't necessarily agree. I don't think it's fair to try to strictly apply code architecture principles to Construct's Event sheet system as they have been written with typical coding languages in mind, and not event sheets.

    Instead I think it's far more sensible to apply a set of new coding principles that are designed around the event sheet and Construct's addon architecture instead.

    The idea that because you might outgrow an addon then you should absolutely avoid it doesn't make sense to me. If you truly have a good reason not to use built in features, I think writing a new behavior is a far better idea than trying to handle everything using events.

    I have seen projects scale just fine within Construct's features, but it implies that you need to design your architecture around what's there, not around arbitrary coding style made for other software development environments.

    However, if you would rather stick to paradigms you are already familiar with, then I would agree that maybe construct events aren't the best choice.

    About scripting, while I agree that it's lacking in some aspects, there are many ways to extend it and break free from many of its limitations. In this aspect, since it's all JS, the sky is the limit with what you can do. Especially if you would rather ditch behaviors and write your own systems, I think writing your own behaviors in the form of scripts can fix whatever issue you have with the program.

    Also, with the recent addition of TS, and with the VS Code extension, I think Unity C# with Visual Studio isn't that much of a better coding environment compared to C3. The only thing maybe is that it doesn't integrate into the editor, and C3 scripts aren't treated the same way as Unity scripts.

  • I recommend any JS dev to give my framework a try, as I feel it can make the process a lot more fun and less cumbersome. I also hate writing a lot of boilerplate.

    My take on what should be addons and what should not is that if other people are able to use a system without context in unrelated projects with no deep understanding of what it does under the hood, then it should be an addon. Otherwise, it should be a JS module.

    A while ago I wrote a lot about how to design code in Construct to be modular on many levels, but a lot of what I wrote is outdated, and I think there is a lot to be taught on that regard considering what Construct 3 has become in recent years.

    Overall I think most of the issues people have been complaining can be solved by Brackeys type community members teaching people about the software and writing tools to cover more and more blind spots.

    So I don't even think the burden lies on Scirra, instead IMO they should focus on doing whatever the fuck they've been doing for the past 15 years.

  • You want the 99 that didn't to love your product. So forget the Unity types and go after the 12 year olds who's parents buy RPG maker for them.

    I don't necessarily agree. The 99 don't look at products to know which engine to choose, they look at games they love and try to replicate them. With close to no successful indie titles made with Construct, the 99 will flock to Game Maker, RPG Maker and Unity instead.

    In fact, only reason I ever used Multimedia Fusion 2 was because of I Wanna Be The Guy and only reason I switched to Construct 2 was because of I Wanna Be The Boshi.

    What I mean is that while Construct's accessibility is a big plus, alone it doesn't sell the engine. Convincing power users will make the engine look more capable, and will in turn motivate beginners to give it a try.

    Another recent example has been Five Nights At Freddy's making a horde of new users flock to MMF2 in the past 5 years. Undertale made ppl flock to GMS and Friday Night Funkin made some beginners want to learn Haxe!

  • Jumping in;

    IMO the game engine market is rapidly evolving and I am very worried that Construct will not be able to keep up with engines like GDevelop or Godot being supported by grants and donations, eating away at significant chunks of market share.

    The free version of C3 as it stands is very limited and I understand that it is not something that can change without reducing license sales. However, have you considered doing a timed "free trial" of a paid version? Something like 14 days of having the full engine unlocked, once per account before having to pay for the full thing. It would make it far easier for a lot of us to recommend the engine to developer friends looking to try it for real.

    On another note:

    I'm also working on something else to highlight games made in Construct, but it's going to take some time to put together.

    Laura_D if you need me to hand over the work done on madewithconstruct.com , its database, or its domain name, let me know and I will gladly do so.

    Also, on the topic of recommending the engine, I was at the poki office 3 days ago (Poki is a web games portal I've been working with for a while: poki.com ) and I made a presentation about the work my company has been doing to push web games forward and a lot of that talk has been Construct related. It has also sparked a lot of discussion with Poki staff about the state of game engines for web games.

    I am planning on sharing that presentation in the following weeks, as it's not exactly geared at web games but rather games made with web technologies.

    In general, I think changing the appearance of Construct can be a community effort, because at the end of the day, an engine is only as good as its community. I'm not as active on the forums as I used to be but that's something that's important for me and it's why I've been working on so much free open source things around Construct. We cannot recommend an engine to power users without power user tools and tutorials, which Construct severely lacks.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Chiming in on the topic of 3rd part developers taking some of that weight:

    I've been contemplating making a brand new Steam NW.js plugin around the new steamworks.js which seems to be much more actively maintained.

    My main issue right now is that I have never used the lib before and I don't have much time to learn it, and don't think I will have much time for it for at least a few months.

    That being said, if someone else has time for it, we've recently set up an Open Collective to crowdfund Free Open Source 3rd party stuff for Construct with some folks in the Construct community.

    I invite any dev that would be up for the challenge to reach out and we can set up a project for them (we've already funded one project and others are on the way)

    opencollective.com/construct-community

    That way everyone could chip in to fund the development of this new plugin and it could resolve that issue, while also avoiding long term issues that come with important addons like these being closed source and abandonned after a few years.

    On an unrelated note, I would also like to add that indeed the lack of File System access for the WebView2 export is sad. I already advocated for Tauri as an alternative to a custom export maintained by Scirra as it would make developing addons for it much easier. Tauri has the same benefits as the Cpp WebView2 export, but also has full File System access (as well as a bunch of NW.js equivalents) it also has cross platform support, and lets you write Rust which means extending the app with native stuff (like steam support and such) much easier for 3rd party devs.

    I understand that using Tauri might also come with a bunch of challenges of its own. Also Tauri suffers from the same issue Ashley's WebView2 wrapper has with Steam overlay.

  • Ah well, I don't know how easy it is to detect Proton :/

    + even if you were to detect proton that wouldn't even give you any info on wether you're running on a regular Linux machine or on Steamdeck.

    I guess we're back to trying to implement steamworks.js

    The alternative would be to do some machine profiling using CPU, GPU and screen size info to try and make an educated guess but that's not really a great idea.