tunepunk's Forum Posts

  • I use functions a lot. When online the event calls the function, when offline calls the function directly without photon.

    For example:

    Pressing Jump.

    - Player is Online. Raise event 2.

    - Player is Offline. Call function Jump.

    On Photon event 2. Call function Jump.

    Function "Jump".

    Simulate pressing Jump key..

    Something like that, so you can use the same mechanics for both online and offline. use all cahracter behaviour and movement in funcitons, then the function can be called either directly (if offline) or by a photon event.

  • I know it's still beta and probably a lot of work left to do on the Timeline, so I can just comment on the current state.

    Coming from a background in with a lot of motion graphics work, using software like AfterEffects, Maya, the timeline feature seems at his quite a long way to go to be a great timeline. It currently works but there is a lot to wish for.

    I tried it briefly yesterday, and apart from being very buggy, it lacks some of the most important features to be a useful animation tool. I will highlight some things I found very strange and hopefully not working as intended.

    Scrubbing

    Scrubbing is a pretty crucial part of animating things with a timeline. You need to be able to put the current time indicator (the red line) at a certain point and immediately get feedback to where the object would be at that current time position. You need to be able to click-drag to scrub the timeline back and forth to get a feeling of your animation, without having to press play every time.

    Editing Curves.

    At this point you can only choose various tween options between points, but in the future I hope it's planned to have a curve editor to manually edit curves. If there's no plan for it, at least the timeline could use a good visual representation of the type of tween between the points.

    I don't know if it's a bug, but previewing the animations in the layout object just jumped from one keyframe to the next, without any tween being previewed.

    Auto Keyframing or Record Keyframes

    Very useful for quick animations. It works like this: If the timeline is at position 0s, you then move the marker to 1s, and move the object a bit, to where to object is supposed to be at 1s, it will automatically place a keyframe there with the correct value. I don't know if there's a hotkey for add keyframe. Whenever I added a keyframe, I had to go to properties to set a value for that keyframe. Not very user friendly.

    Useful Keyboard shortcuts: (maybe they exist, but I havn't seen any documentation of what those are yet)

    Set keyframe: example (s, or k) or something like that.

    Play all timelines, (space or something similar)

    Quick add all translations

    When adding an object to timeline, it's good if you get an option to add all properties. X, Y, Rotation, Width, Height, opacity, in the timeline easily. This makes a lot of sense, if you already know you will be animating many properties of that object. This will work well with the Auto key function, when you have an object to animate, and if you edit any property of that object it will automatically make a keyframe, at current timeline position.

    Those were just some if the things I noticed on my quick tryout.

    Edit: Properties I was missing as well, was to set animation and animation frame. That's something i would like to control with the timeline as well. Maybe you can do it as a workaround by using instance variables, then setting animations, and animation frames to that variable.

  • Had some further ideas in another thread, so creating a new thread to not stray too much off topic.

    Editor plugin concept

    This plugin is intended to ease up process of creating and editing things in the layout editor. Often you find yourself using a lot of dummy sprites, and other things to control certain things, but they only work in runtime.

    An edittime plugin (or several seperate useful tools in the editor category) would have some simple but useful tools that you can link to object to add further control.

    Some of these could be:

    Crosshairs, rectangles, circles, lines, splines, toggle switches, sliders, handles, arrows, indicators, description text, etc.

    These objects, which essentially is dummy objects could be dropped on to layout and connected to other objects to control, positions, variables, angles, and anything you can think of.

    Example:

    I made this quick example to demonstrate a bit of how they would work in the editor. They can be used in runtime as well as regular objects, or dummy objects, but are by default not rendered, unless you choose to do so.

    In these example below, I've added 3 eddittime objects. 2 crosshairs and 1 slider. Crosshairs can be used for setting position of something, or setting the angle towards a crosshair. Sliders can be used to control for example the width of an object. The automatically hide when object is not selected, and show up when object is selected. Take a look at the example. Click the green box to drag it around, and try the handles.

    tunepunk.com/edittime

    The difference berween these and other objects is that, when you control things in the layout with these, it will update the default values fo that object, and you can see and control things very easily in edit time, to quickly get a visual representation of what they do.

    This is just a concept, but I'd like to get some feedback if something like this is doable.

    The Particle objects currently in C3 has 2 red lines to visualize the spray cone. This concept could do the same, but also add controls to control the cone angle by clicking and dragging.

    Let me know if you would find something like this useful, or have any further ideas.

    Ashley Is something like that technically doable?

    Tagged:

  • 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.

  • OddConfection Lol... kind of depressing when you think about it.

    Back in February 2018, the average sales per new indie game was ~50 and it's trending downwards

    Well, App stores and other online retailers are not really doing much to mitigate it. It has never been easier to create games than it is now, especially with tools like construct.

    It doesn't help that marketplaces are crowded with poor quality stuff, clones, and general shovelware either.

    Your best bet of earning money on game design is starting your own company, and offer small promotional games as part of campaigns to various companies in your area for the exposure.

    If your local Car Dealer pays you (per hour) to make a small funny promotional game for their campaign to host on their site, you would make way more than doing the exact same game and uploading it to a market place.

    Apart from making a good, nice looking game, that's fun to play... Unlelss you really know how to market your game and build a buzz, you've gotta be pretty lucky to earn money on your creations. First of all people need to find it, they need to like what they see, they need to try it, they need to buy it, and they need to actually enjoy your game, and recommend it to other people.

    There's nothing wrong with building games as a hobby. There's lots of bands that play music together as a hobby, with an occasional gig at the local pub, for free beer.

    I don't earn any money on my games, or have even released any, but I earn money using construct anyway, as it's part of my job to sometimes do so quick prototypes, or some cool interactive stuff for clients.

    Games are my hobby and I love fiddling around in construct, but I could say that my daytime job sometimes ask me to use construct... which is pretty cool... so you could say I still get payed to use it.

    An example: Of something I played around with lately for one client.

    tunepunk.com/crm

    These kind of simple things clients usually love.....interactive site elements. Construct can be used to make more than just games ya know ;)

    tunepunk.com/cal2

    A client wanted a funny app to promote a new feature, so I prototyped this for them, and their Devs created the app according to my design prototype.

    -

    Anyway what I wanna say that there's a lot more ways to earn money using construct than making games and uploading them to marketplaces. I get payed to do small little things like those...

  • 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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • 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

  • Updated my original post, and also posted this on the ideas suggestion.

    construct3.ideas.aha.io/ideas/C3-I-729

  • 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.

  • > Ashley If SVG would be off-canvas, couldn't we get around layering with z-index?

    No. It's a different element so can only appear above or below the WebGL canvas. Only things actually rendered in WebGL can appear layered between sprites.

    > ctx.drawImage should support drawing an SVG in the canvas.

    That's the canvas 2D context, not the WebGL context. The workaround is to upload that canvas to a WebGL texture, which is the rasterize-to-texture approach I mentioned previously.

    So what's the overhead of doing that? Has it been tested?

    I found this quite interesting..

    two.js.org

  • I did some further tests and was able to get an animation working as well using the same approach, but using setInterval to call the draw function. It stepped through the svg animation at the pace that I set, and could draw regular pixel images on top or below the drawn svg as well.

    Could be set to draw each frame, so I don't see why this would be very hard to implement at all.

    The best way would be to make it as a new object type plugin in C3.

    Of course you probably can't edit it directly in C3, but that doesn't matter, as long as you can preview it in the browser.

    There's a lot of differnet ways to animate svg's and most of them seemed supported, using ctx.drawImage

    en.wikipedia.org/wiki/SVG_animation

    There's even online vector editing tools like this one.

    editor.method.ac

    Using the inspector on this site, you can see how it would work to edit SVG's in construct even.

    drawing SVG's inside of a canvas doesn't seem very complex at all, and is probably supported by most browsers nowadays. ctx.drawImage drew most SVG's i threw at it, with transparency, gradients, etc.

    The same approach could be used to draw paths etc, for enemies to follow.

    I think it's about time Construct started supporting shapes, vectors, paths, splines, etc. ;)

  • Ashley Hmmm... Supporting animations and more andvanced stuff might be second step, but should be fairly easy to at least draw vector images on canvas.

    ctx.drawImage should support drawing an SVG in the canvas.

    jsfiddle.net/Na6X5

    Would something like that at least be feasible? There's a lot of benefits of using SVG's in some cases. Small size, scalable, perfect for crisp UI elements, icons, etc.

  • The engine already sopports import of SVG files, but could really use a way to use it in the engine.

    Vectors has a lot of cool uses, and is commonly used around the web, for both animations, and lightweight UI.

    UPDATE/EDIT: (edited my original post to reflect the many uses of vector shapes, other than graphics, discussed later in the thread)

    I also posted idea here --> construct3.ideas.aha.io/ideas/C3-I-729 explaining how some of the first steps of supporting vector shapes could improve Construct 3.

    Reasons for supporting vector shapes in the editor.

    First step, Simple shapes and curves (not rendered)

    1. Animating objects along paths, curves and shapes. (would be very needed with a timeline feature)

    2. Defining areas and collisions. (Could be used as a null object instead of using dummy sprites.

    3. Working as null object, and making the use of Dummy sprites a thing of the past.

    4. Could be used to deformation purposes similar to how spine and spriter works (deforming shapes along a path, deforming the shape containing a sprite)

    Further uses, (rendered shapes)

    1. Basic shapes for buttons, UI, icons, etc. (A very lightweight option that would scale well)

    2. Import of SVG, for more detailed vector graphics.

    3. Support for vector animation and tweeining individual points (much like how Flash used to work)

    Some interesting online tools that use vector, to take inspiration from.

    Proto.io

    Very powerful prototyping tool i often use to make UI prototyping for apps and web.

    proto.io/en/demos (take a the whack a monster demo)

    Animatron

    A pretty nice timeline animation editor, which is pretty close to how I invisioned the upcoming timeline feature to be implemented. Open link and check some of the examples. Really cool and easy to play around with.

    editor.animatron.com

    Gravit.io

    Very cool and competent online design tool.

    designer.io

    Vectr

    Nice online editor that supports

    vectr.com

    svgator

    No need to explain, just look at these beauitiful animations, that would fit well in any game.

    svgator.com/svg-path-animation

    Tagged:

  • I've been doing a bunch before. Almost 25% or so, but have not had much time since my son was born. Feel free to continue...

  • * No camera angles. Only option would be Orthographic and perspective with the same FOV as the new Z elevation.

    * No intersection needed, it's better to limit the plugin to one 3D file + texture per "3D sprite" object. Usage would be mainly as the gifs i've posted in this thread.. Very very simple objects. They act and behave like a sprite but can be rotated in all diretions that's it.

    * Transparency not really needed.

    * Shaders not needed. Surface shading model with any lights/shadows baked in texture.

    * Lights not need because of surface shading.

    * No bump maps, no specularity... just 1 - 3d mesh + texture per object.