Ruskul's Forum Posts

  • 1StepCloser

    Glad you liked it, I was like "jeez, I need to stop writing mini novels on this forum and get back to work", lol

  • Putting the addon sdk behind the scripting interfaces doesn't do anything! How does that address the question of expanding the api? That intentially limits it, as others have said, all the while ignoring the issue at hand!

    No other engine offers infinite stability. Their api evolves, becomes depreciated, then eventually expires. And none of them face a pr fire because of it. This has allowed them to have cake and eat it too, and is a much better solution than -don't expand api, because then construct will stagnate- which is what it IS doing from a user perspective.

    > Do actually believe that behavior alone addresses all needs within the genre in a scalable, and sensible way?

    Maybe the behaviors don't do everything. They are designed to be flexible. But beyond that, you can use custom logic in event sheets, or JavaScript coding within a project, to implement things like custom movements. You don't have to jump to hacking the engine internals. There are usually several ways to get things done.

    "Usually" isn't always, and as always, you keep missing the entire point, which is that we aren't talking about the "usual" problems here.

    I've explained many times, in multiple posts over the years, including through suggestions. In the past, "intentional implementation" was a common word I heard when describing limiting bugs in official behaviors. The included behaviors are, as others have said, opinionated in their implementation, and only flexible if you share that opinion. In all other cases they are mediocre substitutes.

    I'd love to see you edit the node connections in the pathfinding behavior with events (oh snap, there aren't aces for that) or get it to work with hexagons. For that matter, you can't even make an rts with it. Either you have to recreate the whole behavior from scratch... and since many api aren't public, you have to recreate those as well, or you hack it.

    If behaviors were so flexible, they would be designed from the ground up to be component based, in and of themselves, regardless of the engines api, but they aren't. Instead they are rigid solutions for a particular set of problems.

    And yes, you can indeed make custom character handlers through events, but they can't be abstracted and easily re-used. Which pushes any complex project towards purgatory, which is what I'll call it since you clearly think you get to gate-keep dev-hell.

    It is not feasibly performant to recreate a collider engine/solver, or component architecture, or pathfinding in events. All the official behaviors CHEAT in that regard, in that there is hard codes solutions and dependencies in the engine for them to communicate by. That is bad architecture for a game engine when the devs do it but expect their users to get by without it - the api not being encapsulated is hardly the concern, but the actual architectural pattern.. You can't keep talking about how all the other engines have encapsulation, when all the other engines also don't require hacks to accomplish basic objectives like extending the engine.

    As an alternative, scripting editor side has a huge problems if you wish to use it with eventsheets or frequently interface through JS blocks - for performance reasons, it becomes better to not cross scripts and modules with events. Which leaves the addon sdk, which is performant through eventsheets.

    I'm not going to rescript/duplicate the entire sprite/collision backend (nevermind not being able to create an editor tool for it) in each behavior that I need, just so I can do something the engine is already doing!

    That would be insane.

  • Thanks, that's a good direction. Looks like I might have to add this to my, "nice to have" list and tackle it if I have time. I don't actually need palette swapping in my current project, but it always bothered my that my luts were sprites overlaying the entire viewport.

  • Yeah, scripting is nice. There are just a handful of things that I find simply more convenient/simple to do in eventsheets, but I'd like to eventually move even more into scripting, at least when we're talking complex projects. I really like the eventsheet for simple projects though.

    The speed for simple things is where construct really shines. I think I used c2 for a good year before I ever realized or ran into any sort of issue. But I also was naive about good programing patterns. Although, it seems across the gamedev world, I see countless example of poor code that works and met the deadline and who cares lol.

    It was when I got into the need to have modular, scalable functionality that construct became to difficult to use at the time (c2), which is why I switched to unity. But I always kept prototyping in construct. You can slam a concept out in an hour easy.

  • 1StepCloser

    I have a biased outlook on the matter, so I'll share that at the end if you care.

    For me, this is what I have found, given my projects. I lean very heavy into abstraction every where I can and prefer modularity, rather than hardcoded solutions.

    1. Using JS only has the limitations that you aren't utilizing one of constructs biggest strength amongst it's competitors; The eventsheet and the sol paradigm. I doubt anyone can match speed for speed if they only use JS, which then leads to the hybrid approach being favorable. Consider how many lines of JS it takes to emulate a simple "Is A overlapping B" condition.

    The api is very verbose imo, and could be streamlined with a number of apis to emulate picking conditions. Without those, you have to recode a lot of stuff. The ghost shooter template is a good example, because it requires a lot of typing to simply do what a few events did. Not only that, it is making lazy overlap tests that would kill performance in a full scale game. At the time it was made, there wasn't a way to GetCollisionCandidates and make use of the internal collision cells.

    2. Given the above, a hybrid approach is definitely a better workflow, taking advantage of ACES where can, and doing specialized stuff in JS. You can solve alot of construct's biggest weaknesses by utilizing oop through js modules and extending classes... But... But one issue here: The performance overhead of a single JS block is bad*

    Every event block in an event sheet has some overhead behind the scenes. It really isn't bad, but a single blank event still has a cost. Looping a blank event duplicates its cost. A "custom Action" has a cost around 3x that of a blank event and a "function" can be around 4-7x slower than the base. A loop in construct duplicates the overhead of events, which is why they take so much longer than no loop, even if they are acomplishing the same things. A js block in an event sheet takes around 300x longer to run than a blank event, which means if you are doing something simple like computing a dot product from a math module, it's going to be slower by a lot than simply doing it in events.

    So... if performance is an issue, now you CANNOT put js blocks into any sort of event sheet loop and you also have to make sure that what you are accomplishing with that Js block more than justifies its incredible overhead.

    Now, js blocks can eliminate the need for loops by looping themselves, which is WAY faster than an event sheet loop, but now you are losing any potential to do things through events. Basically, you can create JS systems, and so long as you minimise the number of js blocks that are needed to interact with those systems, you are golden.

    ---

    At the end, this is why I prefer authoring behaviors for some types of problems. they take longer to make, but if I need to constantly interact with them through the event sheet, they make sense from a performance perspective.

    As an example, I do alot of vector math in my game, so I created a behavior that has alot of vector utilities, along side an arbitrary number of vectors a user can add to an object. Another example would be a property whose state I need to monitor and control how it is accessed and modified. This is painful to create with events every time you need it, so I made a behavior to handle the boilerplate.

    In both cases, using a JS module and calling it from a JS block would make my game unplayable, while using behaviors I can still have 100s of entities/characters.

    ---

    For my bias: I believe if you are doing too much scripting, then you may as well pick a different engine. I make behaviors because the initial investment pays dividends in the event sheet and in scalability, but authoring them is incredibly slow compared to the equivalent in unity. If you are straight up coding the game purely through js, I would ask why bother with construct at that point at all.

    Almost every other game engine I have used has a much better workflow where coding is concerned. They have better, bigger, more elegant APIs, and offer more power and flexibility. Its also fair to note, I started with construct, so I should be biased towards it - and it was PAINFUL moving to unity, but once I learned it, it was better in a number of departments. I am choosing to make my current game in construct because I believe that given the my current projects lower complexity, construct will offer a shorter dev cycle than unity will, and I like the fast editor iteration times. I used c2 until about 2016, when I made the switch fully to unity. This is the first year back with c3, but I have always used construct as a prototyping tool.

    Fingers crossed, because I am using the internal, private api, but I think I can get a game out faster here than in unity.

  • I see someone likes scripting :D

    I routinely pack events out into behaviors wherever I can. I still like the flexibility of interacting with event sheets, and jsblocks are always sooo verbose.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Hey all,

    I think I know there is not a property for effects that can be used to load an image, but I was curious if there would be a way to load a texture in an effect from a file at runtime?

    Put simply, I'm authoring a color LUT effect.

    I also have other effects that I need to be able to reference images from, but they need not to be hardcoded, and must be user set. (think about lens dirt on a bloom effect).

    For the color LookUpTable, I used to simply set the effect to a sprite, and the sprite WAS the lookuptable. The issue with that is it will only work on a per "layer" basis, and not a per object basis for things like palette swapping.

  • Ashley

    Question 1:

    In light of what you have clarified,

    Can we find a solution? Do you want to support 3rd party development?

    Would it be possible to set up a way for folks to more easily get access to an expanded api? It's very difficult to be actively developing a game if you have to stop to go drum up popular support, pitch a suggestion that may or may not be responded to, then still have no idea if it will be made, as there is no road map!

    That is exactly a recipe for dev-hell.

    Question 2:

    If an official behavior uses an api call, why is it so hard to make those public and document them? Again, you needn't promise eternal stability, just a way to get the job done, and a promise for an alternative if the api changes. Which is why I mentioned perhaps a "experimental /dev" api in a previous post.

    Issue:

    You keep saying that you are pretty sure most things are possible without engine hacks, but you neither address the specific problems or describe the alternatives. You also have no projects or templates showcasing these scalable and well designed alternatives. As you say, using a private api is bad for a number of reasons, but If the alternative involves poor programing patterns, it isn't an alternative.

    In the specific case of creating a platformer like behavior...

    You told me you don't want anyone "duplicating" the platformer behavior (or any others for that matter). That statement alone indicates a certain level of arrogance... which leads to question 3.

    Question 3:

    Do actually believe that behavior alone addresses all needs within the genre in a scalable, and sensible way? Not only that behavior, but any of them?

    It's an objective fact that you can't possibly anticipate every need any game would ever have, which is why you need a robust way for users to extend construct's features. That is what this whole discussion is about.

    We want to be able to make OUR games, not yours!

    . C3 is supposed to be a gameenegine, not a prebuilt car package where all we do is change paint color.

    I don't want to duplicate your platform code. I want to make my own, because mine is better (for me)! The official one is fine, for those who can use it, and I use it all the time for prototypes, but never finished products. That isn't feature duplication, it is a wholly different behavior that is functionally different at all levels.

  • Also, sometimes using the internal api is as simple as:

    C3.MakeFilledArray

    Because why would I redefine that functionality when every official behavior is also using it.

    Option B in that case, is do more work and I'd prefer to do no extra work, unless I have to, ergo internal api call it is until it breaks.

  • A huge issue, is that when a feature is missing, there is no way to work with Scirra to get it added. no matter how simple or complex. There is no roadmap, no dialogue or discussion, and it has to be "popular", regardless of arguments to its necessity.

    I always figured that if you could argue that a missing feature was absolutely crucial in order to do x, y, or z, and not just a nice to have item, that Scirra would add it, but they don't necessarily do so or it takes years. Even if you have the code to do it.

    I would add, I would be totally psyched if the interal API broke because Scirra decided to modernize the architecture, add extensibility, and provided better eventsheet abstraction, and modularity. But simply breaking the internal api to obfusicate it, for the stated reason to avoid users getting hurt is so fundamentally backwards it hurts.

    The only reason users engage in internal api calls and other hacks is because of a fundamental lacking on the part of c3.

  • Ashley,

    True or false, A or B. You owe this to all paid users. Please directly answer the question in 1 word.

    Will you/Scirra intentionally obfuscate the internal api without first making available a comprehensive and reasonable alternative?

    Yes? No?

    I absolutely need to know, because it isn't possible for me to make my game without the internal api at the moment.

    I would say if you are going to ignore that warning, the only responsible way is to have a plan in place for what you are going to do if the thing it warns you about then happens, so then you can fall back on plan B. But then in that case I would say, just do plan B first, and you won't have the trouble with undocumented stuff changing or disappearing

    You do understand what option B is, right? And are you really telling your users that?

  • Basically what the title asked. I would like to create an interface that automates some behavior linking and allows me to "add" some tools to the scripting side. ;)

  • Do not do this. See the warning in the addon SDK documentation. If you refer to undocumented engine internals, your project will be unsupported and could permanently break at any time.

    "Permanently"?... or just until I can understand what changes were made and why and make a fix?

    Or is it that there is a plan to obfuscate all internals at some point?

  • brushfe I would also add that because construct effects (still) doesn't have the ability to choose/load an image through the editor, creating Table lookups has to be applied to a sprite that covers the screen whose texture is the table lookup, meaning it can't be applied as a full layer effect, and you can't get smooth lerps from one lut to the next.

    I have asked for the ability to have images as an effect property several times starting 10 years ago, and here we are.

  • github.com/Scirra/Construct-feature-requests/issues/184

    Convenience aces exist for "Move at angle", "Move Forward", etc...

    But more commonly I tend to simply whish to move an object by its x,y components. This is simple enough, but a "Translate" action would further speed up event-sheet authoring and is the obvious counterpart/twin action to Move at angle. The former operating in Cartesian space while the latter is in polar coordinates.

    But more complicates is translating an object relative to another's angle (such as a parent's)

    I propose that we include several new common aces:

    "Translate" (x,y)

    "Translate by angle" (x,y)

    "Relative Translate" (obj, x, y)

    When you need to move an object in relative space, you have to do some laborious math, but a relative Translation Ace would solve that fast and easy:

    Current way alternatives:

    //Move obj in relative space according to its parent's angle

    Set Position to (self.x + distanceX*cos(parent.angle) , self.y + distanceY*sin(parent.angle)

    //Translation

    Set Position to (self.x + distanceX , self.y + distanceY)