The Power of SVG / Vector (Updated)

0 favourites
From the Asset Store
75 power-up sound effects; bonus and notification sounds, fanfares, harp glissandi, stabs, clock ticks, etc.
  • FYI collisions are a separate part of the engine, so including that broadens an already technically challenging suggestion to cover even more. Doing all of this would be a massive undertaking and have a major opportunity cost.

    I'm not saying it's a bad idea - it's just you are asking for a massive project here, and that makes it much more difficult to justify and schedule. The less you ask for, the easier it is to countenance it. For example a static single-image SVG object is pretty feasible.

  • The one thing I´d personally find very nice from all the suggestions is animating objects along paths

    Beeing able to drop a Bézier (and maybe a few base-shapes) down and have something animate along it would be extremely useful for all kinds of things.

  • Yeah i understand that. But i think that is a good long term goal then. The necessity of Dummy sprites is just a good example of something that could be made much better. And animation lines is pretty much a must for a timeline feature.

    Some of my projects contain more dummy sprites than actual sprites, mainly because there's no such thing as a Null object, an object can't have more than one collision box. In those cases I'm not using, sprite data, I'm not using animations, No collissions, Basically just an XY position with some instance variables. Sometimes using dummy sprites only for collision box, and that's it.

    Divorcing collisions from sprites, is probably a good thing in the long run. Often an invisible dummy sprite is used anyway, with all the behaviours, and a character sprite is pinned on to that one.

    Yeah simple static SVG objects, if they can be rendered reasonably lightweight I think can be a good addition as well. I can only speak for myself, but main usage would be as mentioned before. (UI, buttons, icons, etc)

    So to summarize my wishlist for the future.

    * Null object (XY point that can hold (some)behaviours, and variables, that's it.

    * Paths/shapes, that can be used as collision objects.

    * Paths/shapes, that can be used as dummy objects to define areas.

    * Paths/shapes that can be used as curves to animate things from A to B.

    * Paths/shapes that can be used as Alpha masks for Sprite objects, with feather (smooth edges)

    * Simple Paths/shapes that can be drawn with a fill/outline such as gradient.

    * Support for SVG import.

    Other ideas

    Layer Masking is another good use of vector. Drawing a circle on layer 1, and setting the property of that circle to be a layer mask. Anything within that circle will be rendered. Anything outside, will be transparent. Or reverse, if you want to make a hole in the layer. Currently you have to use a round sprite to do that job. and it has to be pretty large if you want crisp edges.

    Deformation objects/nodes

    The easiest way to explain this is to show you... some things like sprited does, could then be done directly inside of construct.

    Or for example bend operations similar to what After effects does in this video.

    youtube.com/watch

    Most of these ideas come from the fact that i often use other tools like After Effects, Sketch, Prototyping tools, where vectors/curves and curves are often used. They are all great with cool features, but they don't do games :p

  • I think we're stuck with polygons for collisions for the foreseeable future, but that does bring up an alternative option, a polygon object.

    Something similar to the one Yann made:

    construct.net/en/forum/extending-construct-2/addons-29/plugin-polygon-update-2013-04-55480

  • I think we're stuck with polygons for collisions for the foreseeable future, but that does bring up an alternative option, a polygon object.

    Something similar to the one Yann made:

    https://www.construct.net/en/forum/extending-construct-2/addons-29/plugin-polygon-update-2013-04-55480

    Yeah.. maybe... even that would be useful. If you could create an empty collision polygon directly on your layout, much like how you do it in the sprite editor. That would be a nice addition.

    You could use that to cover larger areas even though it will not support "rounded" curves, and only linear between points.

    Imagine you creating your whole level... then when you're done, you just draw (polygon shapes like sprite editor) shapes for layer boundries etc.

    Most my "graphic" sprites I always disable collisions anyway and I'm pretty allergic to dummy sprites, so any improvement in that area is good.

    * Point object. (just a xy position you can move around, that has some editor visible representation of angle, and variables)

    * Collision Object (pretty much a sprite without the image, used for covering larger areas, or smaller attached to sprites)

    Construct is kind of Rigid when it comes to those things. But it would all come together nicely when you have a proper heirarchy of objects.

    Workflow I'm imagining...

    1. Create as sprite object for body

    2. Create sprite object for head

    3. Select the objects and Click group, to create a parent node for the whole character.

    4. Attach a collision polygon for the group node.

    Parent/group Node. (translating this node would move all childs as well.

    - Body

    - Head

    Collision boxes can be attached to nodes, or objects individually kind of like how container works. Just pick the collision polygon you want attached to your object.

    I see so much potential for C3, but there's probably so much old legacy stuff, that needs to be thrown out of the window and redesigned from scratch so I doubt it will ever happen. Maybe in C4? ... lol

  • Being able to draw paths for objects to follow would be cool. It’s the ultimate in “no programming required” to get things to move about. I’ve lost interest in making feature requests though. I’m more a try to make it myself now sort of guy, since I’m not very patient.

    The existing solutions of using sprites to mark the path can look messy pretty quick. That’s kind of a creative use. My thought is there’s always the in game editor solution. Then you could do whatever you want once you get past the boilerplate stuff.

    All the paths and vector shapes are just data and you can already do rendering of them utilizing sprites or the canvas plugin. It’s lower level than just throwing a svg at it but filled polygons will get you mostly there.

    The hard part is getting it to work with constructs collision system. Probably by utilizing a bunch of hidden sprites. Or you could make your own independent collision system. Decisions decisions.

  • macube ported Rex's spline behavior:

    construct.net/en/make-games/addons/198/spline-movement-c3-runtime

    It's quite nice, but missing a few features.

    While it would be nice to have an editor for such things, I feel I don't really need it as most paths are made during runtime.

    Now an editor for a polygon object, I can get behind that.

  • R0J0hound> Being able to draw paths for objects to follow would be cool. It’s the ultimate in “no programming required” to get things to move about. I’ve lost interest in making feature requests though. I’m more a try to make it myself now sort of guy, since I’m not very patient.

    The existing solutions of using sprites to mark the path can look messy pretty quick.

    As far as my ability goes i try to come up with my own solutions as well using the tools available. Either with events or other means.

    As you point out... It's easy that things become messy when you create your own workarounds, of unsupported features.

    With some math and expressions and dummy objects you could probably get things moving about the way you wanted. But in many cases you also want good visual representation of what's going on. UI handles for tweaking start and end points, shape of curves.

    I've seen event based examples of things doing exactly that. but once again, messy, and leaves a lot of clutter in the layout.

    One of the most interesting features Ashley has been talking about in one of earlier blog posts is the ability to pretty much "bake" events into some kind of component that can be reused, and shared.

    Mentioned in this blog post. construct.net/en/blogs/construct-official-blog-1/the-future-of-the-construct-3-runtime-884

    Modular event features, aimed at capabilities like building plugins out of events

    As a big portion of the community probably don't do much coding, hence the choice of construct. This would open up the possibilites of sharing your event based solutions.

    Which reminds me of another thing that would also be useful: Events for interacting with the editor itself. A good example is the "Particle Object" ... if you take a look at that built in plugin, there's a visual representation of the spray cone visualized by 2 red lines.

    I would imagine that some kind of "Editor Plugin" you would be able to create visual representations and UI for your own solutions, that does not show in runtime. A way to create your own, handles for controlling variables.

    As an example. Let's say you want to want to create your own, Spline movement plugin using events. With an "editor plugin" you could define a start and endpoint, and add a visual layout representation of those points, using the editor plugin, draw a curve between those points, or add all kinds of switches to visually control what's going on, instead of changing variables in your event sheet. They would show up in the layout editor, but they would not show in runtime.

    While we're on the topic R0J0hound Ashley When you're creating your own plugin for C3. How do you go about creating something like the red lines showing in the particles plugin?

    Events for n editor plugin would work something like this in my imagination.

    Example1 :

    Condition: Editor Object selected (UID)

    Action: Display Checkbox at Sprite.X - 20, Sprite.Y-20.

    Action: Set Checkbox description to: ("Toggle.")

    This would create a checkbox near the location of a certain sprite, to toggle for example boolean variable for that object.

    Example 2:

    The editor plugin can be dragged like an object to the layout. In object properties your can choose what this instance is from a dropdown menu. Some useful things you could choose from that list is:

    Crosshair , Checkbox, Line , rectangle, square, circle, slider bar, arrow, pie, angle (like the particles plugin), spline, indicator, handle, etc etc.

    You can chose to render them for debugging purposes, you can choose not to render them to only use them in the editor to control things.

    -

    Example 3:

    Place a slider bar from the Editor plugin, in your layout, that is pinned to an object.

    The slider can be used to control a variable or maybe opacity for that object, and will display any time that object is selected, or choose to always have it visible.

    Dummy sprites NEEDS to go away, and we need a proper way to interact with what we create in the editor itself, not only in runtime.

  • Im only focusing on doing an editor via as modular as possible events. Basically a small amount of objects to do the interface, a chunk of events using those objects (this is the guts that doesn’t need to be understood), and lastly simple events to tie in with project specific stuff.

    I’m unable to comment on the viability of other ideas such as doing it from a plugin or actually changing the construct editor.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Perhaps the next push should be for how in-editor editors are to work, and how it works with the plug api.

  • Since this would probably take time to implement, can we get instead WebP support? instead of current PNG stripe sheet export images? Same quality and features + support on over 70%(natively supported by chrome,mozilla,even and many big name browsers) world wide browsers and devices (cause around 30% are '99 outdated devices / platforms -who cares...)

    To make this clear, instead of exporting the images as PNG strips, instead convert them to Webp, if selected as that. Like not making it default but optional conversion.

    that saves around 50% + image size on game assets.

    Maybe i should add this in the Ideas forum.

    Edited: and here it is WebP Suggestion Submitted

    Having a lower compression image structure, would allow us to fake the SVG functionalities(which we can now by using normal images and lots of event_coding) at lower the GPU/CPU usage and faster data serving.

  • A polygon object would be great for this. I suggested it here: construct3.ideas.aha.io/ideas/C3-I-640

  • > I don't understand the motivation behind this request. I can't think of a single game engine that renders svg in their runtime (the only exception is real-time text rendering, but that's not technically svg, just a similar process).

    You're forgetting a pretty huge one, although pretty dead now. Flash... There was a LOOOOT of games made with flash back in the day. Pretty much every game online was made with flash.

    Vectors was one of the few things I actually liked about it. Action script was pretty flexible as well, but now we're talking about vector itself.

    Vector paths support in general in any engine is still very useful. For many reasons.... apart from graphics.

    Here are some reasons

    * A simple path can be used for an enemy or Npc to travel along. Or just in general for animating movement, from A to B. (I don't know how they going to solve making a competent animation timeline feature, without any kind of paths to control movement.)

    * Paths and shapes can be used to define areas, a much better solution than placing a lot of useless dummy sprites with individual collision boxes all over your map just to block movement of where you can and can't go. Just draw or define an area with vector shapes directly on the layout, and use add it to the list of collisions boxes to interact with. Kill the old collission boxes and assign a simple shape instead.... and you can have perfectly round collision on balls for example.

    * Simple Shapes and paths can be used for deformation purposes as well, much how like Spriter and Spine works, but that's another topic.

    * Apart from these, there's the obvious advantage of using svg's for general graphics. Especially, UI, Icons, buttons, etc etc.

    Pretty much every game engine I know has some implementation of paths, and shapes in some form, for things mentioned above.

    My suggestion is to start from the ground up, starting to support basic shapes and paths for purposes other than graphics, later they can support loading more complex vectors.

    Many developers forget to fix this.

  • Regarding to UI I tend to use 9 patch object and tweens. I also use the main 9patch element of the current interface to positioning the rest of elements like text or other graphics. I pretty much create the elements with vectors and design them to be used with 9 patch. The rest that can't be used like that I just use sprites.

  • Regarding the polygon object suggestion. Didn't Construct Classic support pixel based collisions, couldn't the code for that be ported?

    I know it was more of a "hack" back then but I guess if it works, it works.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)