oosyrag's Forum Posts

  • Any particular reason you aren't using the tilemap object?

  • Convert the health to a percentage of total, then multiply that with your desired life bar display width.

    CurrentHealth/TotalHealth*DisplayWidth

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • If it uses standard input drivers compatible with gamepad/xinput, no problem (unlikely). Otherwise, you will probably need a custom plugin to communicate with their API.

  • Basically, the key is keeping track of the "previous" position and comparing it to the "current" position. In the tutorial, the object being flicked is the "TouchFollowMe" object, which in your case would be your projectile (and your sprite would not be invisible). You also don't need the scrolling part, so you wouldn't be using the Scroll To behavior. You may or may not need the inertia, which can be modified by either changing or removing the lerp() function.

    An alternative solution still utilizes the start and end positions of a touch event, but you can simply store the origin coordinates in variables, then use the angle() and distance() expressions with your start and end coordinates to set the properties of your projectile.

  • Break down and make a list of exactly what "actions" (what) you want your boss to under what "conditions" (when). Sound familiar? Then make an event for each one, with those conditions and actions.

  • The concept is here - https://www.scirra.com/tutorials/560/sw ... th-inertia. If you understand the concepts in the tutorial, it should be simple to apply to a projectile.

  • An example - https://www.dropbox.com/s/dzx2ycubr8wfl ... .capx?dl=0

    Here is a link to the system expressions for reference, in case you don't understand some of the expressions used - https://www.scirra.com/manual/126/system-expressions.

  • With a proper authoritative host set up, the only thing a peer should be sending to the host is their inputs, and the host already has all the data values to begin with.

    But since that isn't the approach you are using, the only things I can suggest is:

    a. Send multiple messages with different tags containing different information.

    b. Send a single message using a token to sperate different information, and on the host side parse it back out with the tokenat() expression. You can use the & operator to combine strings when building your message.

    As for identifying who sent the message, that should have been covered in the multiplayer tutorials. In an event with the "on peer message" condition, you can get the peerid of the originator with the "fromID" expression.

  • The first step is to upload your .capx project file of what you have tried so that you can get a precise answer. There are usually multiple ways to approach any problem, so it helps us give advice without having to guess what your events look like.

    What you describe should have nothing to do with any time based concept at all, depending on what movement system you have implemented.

    The simplest way to do this would be to use the bullet behavior. On bubble created, set speed to initialspeed+score/20*50, assuming you don't need the bubbles to change speed after they have been created.

    If you do, it would just be one additional event to set the triggering condition to whatever you want, with bubble-bullet set speed like above as your action.

  • Set "force own texture" in the layer's properties bar for the effect.

  • Think of it as four less objects you can move every tick (thousands?) or check collisions with normally (hundreds?), in the worst case scenario. Best case you can limit the pool of objects involved in any given collision test (https://www.scirra.com/tutorials/902/li ... raycasting), so it literally does not make a difference at all.

  • You can have a lot of things moving every tick.

    Of course design for your platform, but CPU is rarely the bottleneck. As commonly suggested, don't waste your time. More specifically, keep an eye out for too many physics/collision tests, which are exponential in cpu cost, rather than object position updates.

  • You definitely don't want a huge sprite, as transparent pixels require rendering as well. 4 instances of a 1 px sprite would be the way to go, with negligible performance impact (especially if positioned just outside of the viewport).

  • The first thing that comes to mind would be to utilize 4 invisible helper line objects positioned at each viewport border.

  • Rather than setting the platform vector x, try just setting player position x.