Overboy's Forum Posts

  • Thanks for your comments everyone, i'm glad you find those addons useful !!

    I understand the apprehension, here are some thoughts regarding some points mentionned above :

    • C3 is probably the most stable engine you can think of. You can basically open any 7-10 years old .capx from the Construct 2 era and it just still works in last beta. You couldn't say the same about Unity, Godot, Game Maker or Unreal, yet 98% of the successful games made with those engine are using 3rd party tools in production, even if it's in fact "riskier" to use addons in those engines, or to use those engines in general if backward compatibility break is such a big issue. The truth is that Construct actually lacks 3rd party tools enpowering C3 devs.
    • Ashley is incredibly careful about making sure nothing breaks backward compatibility and he does it very well (it only happenned in very very rare occasion on tiny details and the documentation was available to handle those particular cases long before it happens).
    • ProUI was by far the most complex addons ever made it was doing a huge amount of stuff related to many risky C3 features at the same time. This was a suite of interdependant addons that basically created a full Hierarchy system (among many other things) before it was a thing in the C3 engine and was using a big amount undocumented features of the addon SDK.
    • I have a more "stand-alone" and "simple yet powerful" approach in all the plugins I made so far.
    • My addons also aren't based on API of other services (ads network for example) that evolves over time and need active maintaining.
    • Most of the addons ever made in Construct aren't risky. At the beginning of Construct 3, 5 years ago, there were a few changes in how addons must be written to support the new c3runtime and the worker mode. But since then, nothing changed.
    • Keep in mind every single Action, Condition, Expression, Plugin or Behavior that are included in Construct are in fact addons. Fundamentally nothing really differs between an official addon and a third party addon. They're working on the same base.
    • IMO the most risky thing right now regarding 3rd party tools are effects as WebGPU is being deployed and there is this whole compatibility topic with WebGL1, WebGL2 and WebGPU. But this has to do only with effects and I don't plan to publish Effects, I'm only making Plugins and Behaviors.
    • I've been making games with Construct for 10 years and i'm still here. I'm working on the most ambitious project i've ever made (SECRET ROGUELIKE™) and I developped it so it could be a framework that will allow me to develop even more games on the same base. Construct 3 freelancing/consulting is the biggest part of my freelancing/consulting revenues (more than Game Design and Pixel Art). All in all, chances are high that i'll be still be working with C3 in a few years.
    • All the addons I published so far (and the many more i created for my Roguelike and that i didn't release yet) are low risk. Most of the time i'm working with last beta on my big game and never had to edit anything for them to work while upgrading. When publishing an addon, I'm even more cautious regarding every single details to make sure I won't have trouble with people using them. Most of my addons could have be written exactly the same 3 years ago and still work the same. (Minus the fact i make my best to support the last features of C3, such as TemplateNames, ImagePointZ or BBoxMidX/Y in my UIDToAnything plugin for example : I want them to be on page with last stable C3 enhancements).
    • From my experience, replacing a lot of events is sure annoying to do but isn't that impossible to achieve when needed. I have 6075 event blocks on my project and reworked everything multiple time to implement my addons when I first created them (to replace annoying tricks - non performant/ineffective ways i had to handle things before or just because Vanilla C3 didn't let me achieve what i wanted to do). Even in such big projects, it takes a few hours at most. Also when Scirra release a useful update, that's already what we're doing anyway, replacing old events with better and newest features.
    • The recent dynamic layers were one of the most requested feature for many years and even Skymen (who is a friend of mine and who helped me a lot over the past few years btw) was begging for that feature to be released. His addon was mostly a proof of concept to use with caution because it was using undocumented features and hijacking the engine to work.
    • IMO it wouldn't be in Scirra interest to copy my plugins and make them obsolete anytime soon, there are hundreds and hundreds of features and suggestions that are requested for a long time and that are very important and impossible to achieve no matter how skilled you are at Addon-Making, Eventsheets and Javascript. They probably better put focus on those impossible-to-do stuff or missing spot rather than convincing me right away that developping and publishing high-quality addons for C3 devs isn't worth my time. (even if I already made the plugin for myself, the fact to double-check, polish, publish, market and explain them takes a lot of time). It would be a strong signal to any experienced dev that they should not bother creating premium addons.
    • The top most missing thing for Scirra to be at the same level of the biggest engine out there is more people like you and me, or guys like Skymen/Federico. Community members that dedicate a lot of time and effort to create awesome tools, ressources, spend time helping fellow devs. A game engine = its community. The small (extremely talented) scirra team can't be everywhere. The best way to attract talented and dedicated devs is to make sure it's worth it and safe for them to work within the Construct ecosystem. (Selling tools, making great games, creating Youtube Content). I think the Affiliate Program they just released today (and the Asset Store they released a few month ago) are proofs they understand the power of the community and are moving toward this direction.
    • If someday i leave the community (don't see why it would happen anytime soon), i'll probably open source my tools so other devs can maintain/update them. (if they ever need to be updated which i'm not even sure)
    • I'm using all my addons extensively in my own production, that's why I made them in the first place. I want them to be perfect.

    I took the time to answer those points in details, but I would appreciate if this topic doesn't become a discussion about the history of construct or if it's safe or not to use 3rd party tools in general.

    I went an extra mile and explained a few extra things I discovered/learned/understood over the past few years, I hope it helps :)

    It's up to everyone to decide what's risky or not, what's useful for their game and I prefer that the people that buy my addons are relaxed about that. I'm mostly targeting ambitious Construct 3 dev, who are serious about gamedev/their project and who don't worry too much about spending a few dollars in tools that provide great value and that took a lot of effort and R&D to be made, especially if they know how useful it would be for their productions.

    Thank you for raising those points and for your interest in my tools, I'm very happy to see how well the whole Construct 3 community welcomed them so far.

    If those 2 tools keep doing that well, I'll probably release more of the best tools I made in a few weeks/months ! I still have a lot of exciting stuff 👀

  • OVERBOY'S TOOLS FOR CONSTRUCT 3

    Helloooo !

    • I've been making games for 10 years using various engines including Construct.
    • They were played by millions of people and showcased by the biggest gaming youtubers of the world. (Markiplier 35M subs, Jacksepticeye 30M subs, DanTDM 27M subs, just to name a few).
    • I'm also a big game jam lover and won the Ludum Dare 3 times.
    • I'm doing consulting/freelancing on Construct 3 projects.

    My Games, Tools and Asset Packs : overboy.itch.io

    I'm currently working on SECRET ROGUELIKE™, for which I created a bunch of tools to extend the features of Construct 3.

    Recently I decided to release some of them and was overwhelmed by the positive response it got, so I'm also sharing this here :D

    • Each tool is detailed on their own page listed below.
    • I'll update this list when i'll release new plugins (You can follow this topic if you want to get notified about major updates and new addon releases)
    • I hope it will help other ambitious C3 devs to achieve their games.

    Enjoy !

    DATA+ 2.0 (Previously JSON+)

    overboy.itch.io/construct-3-json-plus

    The Best Data Management solution for Construct 3 (1 Plugin & 3 Behaviors) :

    • JSON+ allows you to create all kind of variables, arrays and data structures (even at runtime !) for your game objects and comes with a lot of additional ACEs, Utilities and QOL enhancements, to make the whole process as fast and enjoyable as possible
    • It comes both with a JSON+ Plugin and a JSON+ Behavior
    • Example/documentation Construct Project (.c3p), which also includes a few tips and tricks I found
    • (2.0 Bonus) Array as a Behavior !
    • (2.0 Bonus) Dictionary as a Behavior !
    • Everything is detailed on the page.

    ADVANCED SIGNALS & CUSTOM EXPRESSIONS

    overboy.itch.io/construct-3-object-signals-custom-expressions

    Create your own Behaviors using Events : Custom Expressions, Signals and Triggers (3 Behaviors) :

    • ADVANCED SIGNALS Behavior (Per-Instance Functions on steroid, supporting parameters, multiple trigger eventblocks and polymorphism)
    • CUSTOM EXPRESSIONS Behavior, create your own expressions and getter functions for your Objects and Families. You can even execute logic each time you use those expression and thanks to the polymorphism feature, the same expression could work differently for each Object member of the same Family.
    • SIMPLE TRIGGER Behavior
    • It basically allows you to create your own behaviors only using eventsheet. (In fact it's even more powerful than Behaviors on some aspect thanks to the polymorphism feature)
    • All those behaviors also support polymorphism, making the Family feature way more powerful.
    • Everything is detailed on the page.

    UID TO ANYTHING

    overboy.itch.io/construct-3-uid-to-anything

    • Act on your instance and get/set their properties, expressions and variables without needing to pick them first, only thanks to their UID ! (Unique Identifiers)
    • Share logic between objects even if they're not from the same Family and even if they are from different Object Category for example (that's right you can share the same code for Text, Sprite, 9Patch and TiledBackground for example !!)
    • Act differently on 2 or more instances from the same Family or ObjectType within the same event block without doing weird tricks
    • Also allows you to work around a lot of Family and Eventsheet limitations, as detailed further on the page

    UTILS (Free Plugin)

    overboy.itch.io/construct-3-utils

    Good Luck on your projects 💪

  • Oh yeah , i just meant that if a Spritesheet folder results in just a little 256x256 px spritesheet (because there is just a few images inside), then it shouldn't try to merge it with an other small spritesheet from outside this Spritesheet Folder.

    But yeah there could be several textures for 1 big Spritesheet Folder.

  • This would be amazing but i think it would be better if we could turn a Regular Folder into a Spritesheet Folder (so a setting per folder) instead of a global project setting turning all Regular Folders into Spritesheet Folders.

    This way we would still be able to use folder for organisation purpose as it works right now and create just a few special "Spritesheet folder" dedicated to memory optimisation whithin the same project.

    It could be an option on the right click context menu of Object Folders :

    Right Click > Turn into Spritesheet Folder (that folder would have a slightly different icon so we immediatly know this folder will force spritesheet packing for all its children)

    Right Click > Turn into Regular Folder (turn back the spritesheet folder into a regular folder)

    Regarding nested Spritesheet Folders, it should probably pack the Spritesheet subfolder into a single spritesheet and the content under the Spritesheet parent folder that isn't itself under a Spritesheet subfolder into an other spritesheet.

    Which means each Spritesheet Folder would be guaranteed to generate a different spritesheet no matter the size of its texture and their parent/child relationship.

  • EDIT : I released an addon pack including a Custom Expressions behavior and everything else i've been advocating for in this thread !

    overboy.itch.io/construct-3-object-signals-custom-expressions

    I posted a suggestion for Custom Expressions

    Vote here: construct23.ideas.aha.io/ideas/C23-I-336

    How it works :

    • It would work the same as returned Function.
    • You can use them using an ObjectType.MyExpression(MyParams) expression.
    • The special event block would be named "MyObject expression MyExpression1 -> Number" like in the mockup.

    Benefits :

    • It would support polymorphism
    • we would be able to create getter function very easily.
    • Would help to keep complex projects clean and readable.
    • No need to use Functions and passing UID parameter anymore
    • Just "MyObject.myexpression1" instead of "Functions.MyObject_myexpression1(MyObject.UID)"
    • Just "MyObject.myexpression2(Params)" instead of "Functions.MyObject_myexpression2(MyObject.UID, Params)" (look how long and unreadable it can get currently)
  • Yes I understand but at the same time, stuff like conditions and actions are SOL-based in Eventsheet while their equivalent in JS interfaces are instance-based.

    It would be better if Custom Actions scripting interface followed the same logic. SOL-based in eventsheet but instance-based in JS.

  • You do not have permission to view this post

  • You do not have permission to view this post

  • I created a suggestion for Custom Actions scripting support a month ago :

    Vote here> construct23.ideas.aha.io/ideas/C23-I-272

    The best way to handle it in scripting would be per instance :

    instance.callAction("MyAction", parameter0)

    As it works for all the other stuff in scripting interfaces.

  • Functions map are tedious to use.

    We need 2 things to solve all issues :

    1. Ability to turn any Function/Custom Action into a Better signal (= Multiple "Listener Block" support) : construct23.ideas.aha.io/ideas/C23-I-165

    It would be the same as calling Multiple Function at once with the same parameters but with an amazing UX, an optional execution order feature and a single thing to "Find All References" for (single name).

    2. Ability to call a Function/Custom Action by its name

    (3. For 2 to be easier to use in some situations, it could be cool to have Function/Custom Actions Names autocomplete and autoupdate everywhere thanks to new System Expressions such as EnumFunctions.MyFunctionName and EnumCustomActions.MyObjectType.MyCustomeAction as in this suggestion : construct23.ideas.aha.io/ideas/C23-I-69 )

    I detailed those 3 points extensively in this thread : construct.net/en/forum/construct-3/general-discussion-7/custom-actionsfunctions-175063

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • You do not have permission to view this post

  • IMO Buttons/Sliders/Radio Groups and that kind of UI component are already achievable relatively easily with existing Eventsheet features (Families/Hierarchy/Custom Actions)

    While it would be great to have those "Components" built-in in C3, IMO this isn't the real pain we're facing with UI right now. It could bloat the engine with a bunch of additional Plugins/Behaviors and each person might want their Sliders/Buttons to act very differently. So Component would probably need too many features and parameters to cover everyone's need and might even be disappointing in the end, and dismissed in favor of "custom Components" created with existing features.

    If those potential "Built-in Components" were Plugin, it would be the same pain as today as there is not Multi-Plugin support for Families in C3 for example

    The biggest pain is manipulating the position (transform) of all UI Objects with auto-layouting which is almost impossible to achieve even with Families as Text and Sprite for example are different Plugin and can't share common logic. (it would be the same issue with Button/Sliders)

    This is why Hierarchy based autolayouting would solve this as it works with any world object (+ easy picking benefit and intuitive display in a potential Hierarchy view)

    Hierarchy based autolayouting + a "Selectable" behavior would help us to make those Slider/Button/Grid/Scrolllist "Components" ourselves

  • As i said several times in the past, we don't need to replicate everything HTML and CSS can achieve to be able to create UI in C3.

    We just need :

    1. Hierarchy-based autolayouting features (similar to Godot Containers docs.godotengine.org/en/stable/tutorials/ui/gui_containers.html as they're the best autolayouting ever created for a game engine)

    2. maybe a new "Selectable" behavior

    (The suggestion explain those 2 points further,https://construct23.ideas.aha.io/ideas/C23-I-78)

    The existing C3 features and all existing synergies that exist between them will do the rest and allow us to do anything we could imagine for our UIs using eventsheet features.

    On the other hand, turning HTML/CSS into a decent UI solution is a rabbit hole and might even be impossible for a bunch a reasons I pointed out in the Twitter thread. (live preview of UI at editime, reliable and consistent display across platform and browser, event sheet ways to manipulate the UI, Layer support just to name a few)

    Anyway sorry this wasn't the subject of this topic, just wanted to pointed out that 3rd party console porting would be 100% impossible to achieve for games relying on HTML/CSS UI as opposed to any game currently developed in C3

  • browser things the HTML Element object with custom HTML and CSS may never be portable.

    I think this is quite an (additional) important point against requiring us to use HTML/CSS for UI systems. Most popular C3 commercial games are ported to console thanks to those 3rd party companies but soon it might be impossible to ever port a C3 game to console if the whole UI of the game was done using HTML/CSS.

    And this is only one of the less annoying drawbacks with going with a HTML/CSS-based UI solution for C3 as we talked about recently

    twitter.com/OverboyYT/status/1638952637315047424

    (which is also why i think we need built-in UI features and they could be Hierarchy-based construct23.ideas.aha.io/ideas/C23-I-78 )

  • You do not have permission to view this post