Best way of handling enemy movement in platform games?

0 favourites
  • 3 posts
From the Asset Store
Best car suspension with spring effect and very cool terrain generation.
  • In many of the Construct 3 platform game tutorials, the authors recommend handling enemy movement by a) using the 'simulate platform' action to move the enemy, b) using an instance variable to handle direction of movement, and c) checking for collisions with invisible boundary sprites in order to know when the enemy needs to change direction.

    The first two items make perfect sense, but I've often encountered weird janky glitches when students use invisible boundary sprites to handle enemy movement calculations. In any given class of 15 students, at least one or two students is likely to encounter glitches which cause their enemies to randomly plummet off the platforms in unexpected ways. Sometimes, this seems to be a function of the frame rate. At other times, it has to do with the collision areas not lining up correctly. In some cases, the student has *never* been able to solve the problem and the C3 forums have also been at a loss to solve the problem.

    It seems like a more reliable way of handling this situation might be the addition of minimumX and maximumX instance variables in the enemy sprites. Then, the programmer simply needs to update the values of these instances once when they are populating their layouts. From that point forward, the direction calculations should work just fine without any weird glitches.

    Does this seem like a plausible alternative to invisible collision boxes? Am I overlooking something?

  • Using the min/max values could be more efficient and less work than placing sprites, it takes away any of the placement problems. Whether it would fix the glitches is difficult to say as it depends on the cause. The issue could be with the enemy's own collision box, the environment collision such as the floor, or physics related values on the platform behaviour, FPS as you mentioned, or conflict with other movement related events on the event sheet.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Using discrete coordinates should mostly bypass collision related issues entirely, so that would seem to be a good solution.

    I would argue that learning about the pitfalls of collisions and collision detection (and by extension the effects of fps and the concept of updates/ticks) is pretty fundamental, but that's just my opinion and it really depends on what your class is focusing on teaching.

    If I were to approach this issue with values rather than helper sprites, I would try to implement a flexible, automatic system. Assuming there are no situations where an enemy can come into contact with multiple platforms, use two instance variables to keep track of the lower and upper bounds to patrol. These variables can be set on collision with a platform object, based on the position and width of the platform. If the position of the enemy object exceeds these bounds, turn around (trigger once while true).

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