Jump to content
  • Advertisement

stumper52

Member
  • Content Count

    14
  • Joined

  • Last visited

Community Reputation

163 Neutral

About stumper52

  • Rank
    Member
  1. I see how that could work. Would being able to check the velocity in the collision system be an example of the collision system knowing whether the object intends to move work? Also, would there be a need to ensure that the collision system ticks at a certain rate relative to the object? Or is it ok if the collision system ticks at a different rate from the object?     For the first part I'd say that would be a bad practice if the number of objects grows. You would have to keep track of every object that can move and check it's velocity every tick to figure out whether you have to do anything to it or not. These loops would probably slow down your performance. What I would suggest is more of a trigger system or an event based system where an objects that wants to move triggers an event which tells the collision system the next time it ticks to take action on the object that triggered the event. Which pretty much also answers your second part of the question. Events can even be triggered by objects on other threads so no you don't need syncronous ticks.
  2. Would this separation of movement and collision logic also prevent objects from communicating their intent of moving to the collision system? If that is not the case, you could queue every intent of object moving to the collision system which would check the destination coordinates against the restricted set and return a go-ahead or a reasonable replacement destination.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!