Suggestion: Collision Conditions

This forum is currently in read-only mode.
From the Asset Store
Perfect Particles
$2 USD
80% off
Particles support animations, collisions, effects and etc.
  • I have found myself needing more collision conditions. Most importantly, I suggest a condition that checks if an object instance would collide with a solid/any object of a certain/any type if placed at a certain position. If I were to describe this condition as a function, it would be place_free(x,y,object,solid). The condition would return true if the current instance (self) placed at x,y would not overlap object. object could be a certain object, a "superclass" (I'm still not entirely sure how Construct's "families" and "containers" work.), or "any object". If solid is true, only solid instances of object are taken into account.

    Just to test Construct, I was creating a Pacman game, and I saw that by using the default movement systems, an object's speed ceases when the player presses a key that would move him into a solid object. But think of the game of Pacman. If Pacman is moving right and you press up while there is a wall on his top side, he won't just stop in his tracks. Since he would collide with a wall by moving up, the up keypress is "ignored", and his horizontal speed continues moving him to the right.

    I was able to simulate this kind of "place free" function by placing a collision sprite on Pacman's (and the Ghosts') left, top, right, and bottom sides, Always attaching those collision sprites to each object's position (This was repetitive, since I am still not entirely sure how object inheritance and Function objects work, and copying and pasting events and actions ceased to work after running Construct a few times), and checking if a collision sprite was overlapping a collision block when the corresponding key was pressed to move in a certain direction. Doing all of this has allowed me to achieve the movement I need, but I hope that simpler mechanisms are eventually built into Construct.

    So, in addition to more collision conditions such as place_free(x,y,object,solid), I suggest that the movement systems have an option to ignore the player's key press if he attempts to move in a direction that is blocked with a solid object.

  • That method of using detectors is a common one when restricting actions like you're doing. In fact, that's pretty much how it's done.

    If you wanted you could create your own testing routine that temporarily places an object in the direction you're pressing, and if it meets no resistance then runs the rest of the movement commands as a sub-event. It would only take a couple of events to do, so I really don't see much use in creating a whole new collision condition type to take care of that.

    But hey, it's open source. Maybe someone will come along and implement it <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" />

  • Yeah detectors are a common solution for this, but you could use the function object to make a function that does this. If the function saved the coordinates of the object, moved it, tested for a collision then moved the object back, you'd have something like your place_free function.

    The inherit option can pretty much be ignored unless you're using multiple instances of the object in question.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I tried using the Function object for another type of function, and it seemed to work fine as long as I didn't attempt to use parameters. Trying to use parameters caused my game to crash. I'm sure it's just me not knowing how to use them properly.... Parameters and "aliases" I'm just not sure about in Construct. Could either of you perhaps guide me on how to use these items and the conditions and actions needed to implement this place_free function?

    But yes, the thing is, Pacman and every Ghost object (and every object in any other game I would want to create) would need its own collision detector objects if I stayed the current route. Ideally, I would want to write an action that automatically creates instances of a single collider object for Pacman and every Ghost object rather than having to insert 20 collider objects into the layout. Now I think I can create all of the collider instances in a loop, but then how would I go about assigning each instance to their respective object? Since I want only one collider object, how would I go about retrieving each collider instance's unique id so that I can assign them to Pacman and all of the Ghosts?

    I think an option to refer to an instance id in conditions and actions instead of just an object would be great in the future if it can be implemented.

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