Liquidfun JavaScript - LFJS - [behavior]

Post reply
4 favourites

  • Might want to think about an editor to make prefabs.

    Creating groups of instances in the Construct editor, and via events can be problematic.

    Loading a shape, not so much.

  • newt - Yeah, creating a large group of sprites in the editor can be a pain. The plugin takes care of all of that behind the scenes, all you do is nominate the sprite type you want to use. The plugin then creates and moves instances to that type to the particle positions. Particles can only be created in groups in shapes (circle, box, polygon), with the polygon selection giving you the choice to derive the shape from an array.AsJson set of points or another sprite's collision polygon.

  • Mmmm, if only there was a color picker for the editor.

  • Ahh, ok.

    Also, calculator.

  • It will be really interesting to see how this goes with particles, as folks have talked about, it could be really nice for pixel art, where there are a manageable number of particles to represent the entire image. I'm glad I gave you a little bit of inspiration. As you say, programmatic building and loading are the keys to make it useable, like the function I created in my example to make the sprite rectangle build of smaller sprites.

    One thing I noticed with the larger sprite block size was that setting the collision polygon a little smaller than the actual sprite image made the collapse look more natural (I did this in later test.) When the blocks can overlap slightly it has a more natural feeling of a collapsing structure and jumble of blocks. I think this may not be an issue for the particle system, but if it is, might want to think about making the particles able to overlap a little (or have a parameter or setting for it.)

  • Mikal,

    Yes - the size of the particle sprite is separate from the particle radius - by setting the default instance width/height in the normal construct way. Thus you can adjust both the sprite and particle dimensions to get the effect you're after.

    Getting the particles to render in the correct colors and to behave as one group was a massive headache, but here it is! :D

    The above example is just proof that the basic algorithm works. Of note, there is a slight delay when the sprite image texture is copied to an off-screen canvas and this won't be acceptable to everyone. So, I'm going to add methods so you will be able to obtain the image-to-particle data in a separate project from the game and then load the data into a particle system at runtime (array.AsJson, probably). Programmatic simplicity is the objective here, and I will include an image data extraction c3p example to demonstrate how it should be used.

    Edit: deleted web-worker compatibility paragraph. I think it was actually a bug in Chrome Canary...

  • Great work, it looks so good. I am also thinking about using it with that elastic effect you demonstrated before, so it can hold shape while still being stretched and changed. Thanks for answering my questions.

  • OMG....

  • Holy Moly... you better release this soon unless you want me to implode.

  • Thanks Mikal NetOne WackyToaster

    Update: I think that the web-worker issue I encountered previously was because I was testing in Chrome Canary - an update has fixed the problem!

  • Can the particles have behaviors?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Mikal - I tried the same demo with the particles as Elastic and it literally took 10 seconds to create the particle group. Although fun, I don't think it's viable, unfortunately!

    newt - yes, in a way. Liquidfun supports different particle types, each of which has its own set of behavior attributes. When testing, there were a couple that didn't seem to be any different to the Water type, so they have been ignored. In LFJS the following particle types are available:

    Rigid / Fluid - Rigid particle groups are ones whose shape does not change, even when they collide with other bodies.

    Water - Basic particle.

    Spring - Spring particles produce the effect of being attached to one another, as by a spring.

    Elastic - Elastic particles deform and may also bounce when they collide with rigid bodies.

    Viscous - Viscous particles exhibit clinginess or stickiness, like oil.

    Powder - Powder particles produce a scattering effect such as you might see with sand or dust.

    Tensile - Tensile particles are used to produce the effect of surface tension, or the taut curvature on the surface of a body of liquid.

    Pressure - Static pressure particles are subject to compression when pressure acts upon them.

    Repulsive - Repulsive particle groups repel each other.

    I've yet to add methods to allow you to change some of the attribute parameters, but it's on my TODO list.

    I realise that I need to add Color-Mixing to that list as well...

  • I mean like plug in behaviors.

    Flash, Fade, etc.

  • newt - ah, I see. Yes - the particle objects are just Sprite instances that have their position managed by the plugin, so you can do anything with them that you can do with a normal Sprite.

    On the first tick after particles are created in an action, the plugin creates the required number of sprites to draw their positions. If some particles are destroyed (by action or timeout) then the spare sprites are moved to outside the layout, in case they will be needed again later (practically no performance hit and there is an action to delete them).

    If you were to delete a sprite instance (by events or through other behavior like fade) then the plugin would just make another to ensure its particles are displayed.

  • Elastic - ah that's too bad. I'll probably look at a way to 'pre-bake' that before runtime, but I will wait for the release, so I can see more details. Keep up the good work, looking forward to the release.

Post reply
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)