Nepeo's Forum Posts

  • I'm not involved in the development of the tween plugin, and haven't really used it in any of my projects so I can't really comment on what features it has. You might have more success creating a new thread asking other users about it.

    If you think it's missing a specific feature you would find useful I recommend submitting it to ourfeature request page.

  • Interesting technique. Something very similar is actually used by robot vacuum cleaners. They have a sensor on the leading edge facing down that checks the proximity of the floor. If it moves forward and the sensor reports that the floor is far away then it's reached an edge, and knows to move away.

    Fun fact that most models suffer issues with black rugs, if they use an IR photo-diode to check for proximity then it appears as an infinite abyss to it.

  • Google Play Games has some pretty extreme caching systems that can easily catch you out, particularly around things which aren't expected to change ( like leaderboard configuration ).

    I actually published a revision which should have resolved some of these issues yesterday, but I guess I introduced a different bug?

    There is a kind of disconnect between there being a logged in user ( managed by device service ) and the app actually thinking it's signed in. The actual state can change underneath the app and there's no magic event that fires to tell you that. Hence the plugin has code that updates the sign in state when the value is expected to change ( after signing in for instance ), but I've heard of at least one crash from being signed in but the plugin being out of sync. The patch is supposed to update the login state at the entry point to each action if it didn't match the actual sign in state.

    I'm out of office for a couple of days so I've rolled it back and will review further when I have the chance.

  • No worries dop2000 I hope it comes in handy. I ended up just putting in options for doing an x/y transpose. It seemed the simplest and the most useful. You can also choose to transpose a single layer or the whole editor, due to transposing swapping the width/height of the array you can only transpose a single layer if the width and height are the same.

    I spent a fair amount of time considering what adjustments could be made to the data editor regarding improving memory usage, but the files would be so massive anyway I don't think there is much point! So yeah just did this the simple way, but it might be slow for massive files.

  • Looks nice! Glad I could help :) Yeah I'm not surprised that there's issues with neighbouring platforms, it's a flaw of using the "pick nearest" condition. You can kind of work around it using careful level design. If they are only going to walk on a single platform you could add a "platform id" instance variable and pick the platform using that. So they would only look at the platform they are assigned to.

  • Actually the doc appears to be saying what I did, so the documentation is correct about this behaviour. Picking IS happening on all conditions, but the effect is cumulative. If you start with 10 instances and the first condition picks 5 then the next condition can only pick from those 5, if that condition picks 0 instances then any following conditions have no instances to pick from and hence are all false.

    In the example you gave each condition is picking from 2 sets of instances, the observer and the targets. Because the observer is used in each condition if any are false the following conditions has 0 instances of the observer to pick from, but because the targets are unique to each condition they have the full set. So it's nothing to do with "else", just how "OR" behaves.

    I admit this behaviour feels a little weird to me, I would have assumed that picking wouldn't work like this in OR blocks, but I'm not familiar with the history of this. There might even be a good reason it works like this that I'm not aware of, but the design of the event system predates me joining Scirra by quite a few years.

    About the reply the website sometimes has caching issues with posts, so they don't show up for awhile or until the thread is updated again. Typically editing the post is enough to make it appear.

  • Well you don't need marker objects, but they don't really add any notable overhead.

    If you want to just use the use the positions you can just compare the delta between the bounding box of the platform and the enemy like so.

    Enemy and Platform are both sprites in this example. Enemy has a single instance variable called direction and the platform behaviour. The platform behaviour has the default controls disabled so we can simulate the control input using events. The Platform object has the solid behaviour.

    The events visit each enemy character, and find the closest platform instance to them. Then checks the distance between the left bounding box edges, then the right bounding box edges. If it's close to the left edge we change direction to "right" if it's close to the right edge we change the direction to "left". Then finally we check the direction variable, and simulate the control for the desired direction.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I'm guessing you want something like this old platforming tutorial for C2? The game has enemies that move back and forth along their platform. The trick being to place invisible markers at either end of the platform, when the enemy collides with it the direction of movement it flipped. Useful technique, can be used for other AI systems as well in top down games.

  • I didn't really get what the issue was before, but I think I got it from tarek2s example. Picking is preserved across an event block, so that you can filter down from a large set of objects using multiple conditions. I believe the LOS is filtered out on the first condition if it cannot see the target instance. Hence on the following conditions you are checking 0 LOS instances against 1 target instance.

    So the solution is either check against all targets in one condition ( so families ) or use separate blocks for each target ( else if ).

  • Lumicreative.com ah yeah I was suggesting a slightly more intensive solution, which is to basically replace the bullet behaviour with raycasting. I think in your example is a little broken, with some tweaks it would probably work after a fashion. But under some circumstances it would fail, when passing near to an object the center of the ball may not pass through a box, but the ball would overlap with the box. In that situation the raycast would never report a collision, but the bullet behaviour would.

    This is your project adapted to what I meant. It works well, but it will occasionally not collide when it appears to due to being considered a particle. Using a smaller ball makes it look more convincing. There's some tricks you can do to simulate the ball as a polygon, but you end up back with the problem of flat edges vs curved.

    You can kind of do collision with other ball instances, but it causes some strange collisions because we have a single position buffer which we are read/writing to at the same time.

    I was thinking you could also solve this using signed distance fields and raymarching ( subtly different to what the LOS plugin uses ) but you would basically have to write all this logic from scratch.

  • The bullet behaviour provides a reasonable approximation for bouncing, but it's not perfect.

    If you can get away with simulating the ball as a particle ( no size ) you can do a good job by using Line of Sight to raycast the bullet path. Although I don't think this will work if your using gravity on the ball, as the path changes from a ray to curve in most situations. You can make some tweaks to this to make it behave a little more like a circle, but it's not ideal for most situations.

  • SSL is a fun hurdle, but at least you know a bit about it now!

    If you have issues with networking in future I recommend looking up how to use the Chrome Developer tools, it has an excellent networking tool for checking what requests a page is making. With contents, response, headers, errors. All that jazz.

  • Well generally I would just advise using a host that supports HTTPS, browsers quite aggressively prefer them nowadays.

    Exporting as a HTML game and putting it on a local HTTP server would work. Using something like XAMPP, MAMP or simple-http-server.

  • I had a look and there's some stuff about adding languages to a xcode project online. I think it's supposed to be used with the storyboard system, but I think it's where the app store is also pulling the data from.

  • Under most situations the slowest part will be the terrain generation logic itself. So this is the place you should optimise. Most of the tweaks you can do here will increase your complexity significantly, so you should avoid making these changes unless you have a need to optimise!

    One of the easiest tricks is to decrease the density of the terrain. If you double the size of your tiles you decrease the number of tiles you need to process by 4. A more advanced version of this is to generate your world at a reduced density, but use the same number of tiles. Using interpolation to stretch the world over the tiles.

    A more complicated trick is to break up your world generation into zones, then only generate a small number of zones at a time. With this technique your world generation takes the same amount of time, but your player can play the game while the world is generating.

    Getting good quality out of procedural generation can be tricky, but it's quite good at creating lots of content rapidly. You can make it look like your logic is better than it is by running lots of permutations yourself, and picking only the good ones to go into your game. Depending on how you go about that you could have a world creator tool which does the random world generation and allows you to edit the world to add extra details, then just load the world into your game. That way world generation doesn't need to be done during gameplay. If you want the world to appear random to the user then you can pick 16 or so worlds and put them in the game, then pick one of those at random.

    It's worth remembering that most forms of optimisation are compromises.

    • Adding more logic to make a specific case faster makes your logic more complicated, and harder to work on.
    • Reducing density might improve performance at the cost of visual quality.
    • Picking good worlds for your user reduces the level of uniqueness each player experiences, but enhances the quality.
    • Generating the world while the user is playing means they can play immediately, and can open the game up to "infinite" worlds. However, the game might cause lag if you do too much work on each frame.