Sign in to follow this  

Unity Decoupling physics

This topic is 1108 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm having a problem with my current game architecture design; I'm using the ECS pattern but I'm still having trouble decoupling some of the physics code. Especially in case the player wants to place a block somewhere: this gameplay-related code needs to cast a ray, and aside from that check if that position is free. First, I had casted rays by emitting events, and letting the physics system handle them and invoke a callback function. But since the gameplay code now needs to check whether a position is free, it would need to emit a second event. This method already felt hacky and slow, but better than direct access.

 

I'm curious to how this is usually handled. I know that you can cast a ray from anywhere when using Unity, but I doubt this is the correct approach. How have you handled this kind of problem?

Share this post


Link to post
Share on other sites

Why are you doubting that this is the correct approach?

The physics systems acts as a service in this case and the other systems are consumers.

 

Events or not, your picking system is dependent on the physics system either way, as without it your code would not work.

Share this post


Link to post
Share on other sites

To add a bit to Madhed's post:

 


this gameplay-related code needs to cast a ray, and aside from that check if that position is free.

 

First: it's not clear how (or whether) you've separated collision detection from physics response. That is, why is the determination that a position is "free" not done by an entity attempting to move?

 


I had casted rays by emitting events, and letting the physics system handle them

 

Given no information on what "entities" or "positions" are, that's a common approach. Detect collisions (or lack thereof) and let physics determine responses.

Share this post


Link to post
Share on other sites

"player wants to place a block somewhere"

 

i assume you mean in a minecraft type game, as opposed to simple entity movement.

 

 

i personally prefer non-deferred processing.

 

"player wants to place a block somewhere"

 

so your in the process_input part of the game loop.

 

you need a raycast with collision check that returns space_is_empty: true | false.

 

if space_is_empty, add_block.

 

so your parts are a raycaster, a collision checker, and an add_block routine.

 

" I had casted rays by emitting events, and letting the physics system handle them and invoke a callback function....  This method already felt hacky and slow, but better than direct access."

 

sounds rather hacky and slow. think of all the unnecessary typing and processor cycles involved.

 

the non-deferred way:

 

process_input gets an "addblock" input. calls process_addblock.

 

process_addblock is the controlling code. it calls the raycaster. raycaster calls collision checker repeatedly as it steps though the scene. raycaster returns intersection point to process_addblock. process_addblock tests intersection point to determine if space_is_empty. if space_is empty, process_addblock calls addblock routine.

 

after all that input processing continues with the next input tested for or queued.

 

so your modules are:

process_input

process_addblock

raycaster

collision checker

addblock routine

 

the collision checker can be part of the physics engine or you can code a simple dedicated raycast and intersection check  specifically for the task (often simpler).

Edited by Norman Barrows

Share this post


Link to post
Share on other sites

Why are you doubting that this is the correct approach?

The physics systems acts as a service in this case and the other systems are consumers.

 

Events or not, your picking system is dependent on the physics system either way, as without it your code would not work.

The extra function calls and callback functions add additional overhead and indirection. And in this situation you would be able to replace the physics system, without changing anything to the side.

 

First: it's not clear how (or whether) you've separated collision detection from physics response. That is, why is the determination that a position is "free" not done by an entity attempting to move?

Collision detection while moving is done by the physics system. The logic code simply sets a velocity and forgets about it. Preventing an object from moving when there is a block in its face is something else than casting a ray, where you need the result instantly to perform a specific action.

 

Given no information on what "entities" or "positions" are, that's a common approach. Detect collisions (or lack thereof) and let physics determine responses.

I should have given more information; the physics system calculates if and where the ray hit, and then invokes a callback function. I didn't think it would be a good idea to let the physics system handle placing blocks.

 

...

Thanks for the suggestion! My problem is however, that I want to decouple my code as much as possible. If the logic code needs references to the world etc. to cast rays, it will be harder to maintain, I can't switch out the physics system, and the logic code does things it shouldn't do.

Edited by ProtectedMode

Share this post


Link to post
Share on other sites

I didn't think it would be a good idea to let the physics system handle placing blocks.

 

Sorry. I didn't understand the emphasis of the OP as placing blocks.

 

Not knowing what capabilities your "entities" have, and IF a block is an entity, you can create a block entity (perhaps at a hidden, always "free" location), attempt to move it to the desired position, and, if the entity says "Can't do it," inform the user, and keep the block for later. If the block can be placed, add it to your "world," and create another "for-later-use" block at that hidden location.

Edited by Buckeye

Share this post


Link to post
Share on other sites

 

Why are you doubting that this is the correct approach?

The physics systems acts as a service in this case and the other systems are consumers.

 

Events or not, your picking system is dependent on the physics system either way, as without it your code would not work.

The extra function calls and callback functions add additional overhead and indirection. And in this situation you would be able to replace the physics system, without changing anything to the side.

 

I was actually talking about your Unity example here and your doubting their approach.

 

I think the confusion here stems from the fact that you see ECS as a catch-all pattern for gaming related systems design.

The pattern originated because people were trying to find an alternative to the dilemma posed by heavy inheritance trees and the resulting god classes.

 

You still have plenty of different patterns at your disposal for dealing with other aspects of your game.

I would describe your situation as follows:

 

 

Physics system

responsible for maintaining the physical representation of your game. Rigid bodys, collision shapes, velocity rotation.

Maintains and encapsulates physics state, advances physics state in discrete timesteps.

 

Provides an interface to manipulate/query the physics state.

This interface includes components where you can apply forces/torque on single entities and a global view where you can query information about all physics components.

A raycast is just a query in this case: Return to me a list of all colliders/rigid bodies that intersect with this ray.

 

You can still use the interface pattern to abstract away the specific physics implementation.

Share this post


Link to post
Share on other sites

If the logic code needs references to the world etc. to cast rays, it will be harder to maintain, I can't switch out the physics system, and the logic code does things it shouldn't do.

 

mathed's approach divvies things up rather nicely. raycast is simply a query method of the physics engine's api. 

 

that way process_addblock, the controlling or logic code, need not know about the world representation used by the physics engine. it just calls a physics routine and gets back a result, from which it computes space_is_empty, and then possibly calls addblock depending on the value of space_is_empty.

 

by making raycast part of the physics api, you can swap physics engines with no change to process_addblock, assuming you use a translation layer (interface pattern?) between your code and the swappable libraries.

 

when re-organizing api's like this results in such lucid code as the example above, you're pretty much guaranteed to be on the right track as to how things should be organized and what should be a part of which API. IE if an API change results in godlike simplicity and clarity, you're doing something right - VERY right.

Edited by Norman Barrows

Share this post


Link to post
Share on other sites

This topic is 1108 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Forum Statistics

    • Total Topics
      628651
    • Total Posts
      2984044
  • Similar Content

    • By arash khalaqhdoust
      hey guys i hope you doing all well. last night i released my first game in google app store, i really appreciate you guys  to download it. and share your reviews about it
      the idea of game comes from mini hackgame of Bioshock.
       link of download:
      https://play.google.com/store/apps/details?id=com.RVBinary.piperist
      many thanks
    • By ForgedInteractive
      Who We Are
      We are Forged Interactive, a small team of like-minded game developers with the sole purpose of making games we love! Currently, we're progressing very quickly with our first project and there are plenty of opportunities and work for new interested programmers. With this project, our development platform is Unity 5.5.2 and C# as our behavioral language. Since this project is our first release, the game itself is a smaller project though progress is moving quickly. We are looking to finalize the current project and get started on future projects in the near future and are expanding our team to do so.
       
      Who We Are Looking For:
      Programmer Level Designer  
      About the Game
      Ours is the tale of two siblings, thrown into a world of chaos. Living in the shadow of their parents' heroic deeds and their Uncle's colorful military career, Finn and Atia are about to become the next force to shape our world. How will you rise through the ranks of Hereilla and what will be your legacy? Once defeated your enemies turn coat and join you in your adventures. Players can enjoy a range of troops and abilities based on their gameplay style which become more important as maps introduce more challenging terrain, enemies and bosses. Strong orc knights, dangerous shamans, and even a dragon are out on the prowl. Knowing when to fight and when to run, and how to manage your army is essential. Your actions alone decide the fate of this world.
       
      Previous Work by Team
      Although we are working towards our first game as Forged Interactive, our team members themselves have worked on titles including and not limited to:
      Final Fantasy Kingsglaive FIFA 2017 Xcom 2 Civilization  
      What do we expect?
      Reference work or portfolio. Examples what have you already done and what projects you have worked on academic or otherwise. The ability to commit to the project on a regular basis. If you are going on a two-week trip, we don't mind, but it would be good if you could commit 10+ hours to the project each week. Willingness to work with a royalty based compensation model, you will be paid when the game launches. Openness to learning new tools and techniques
       
      What can we offer?
      Continuous support and availability from our side. You have the ability to give design input, and creative say in the development of the game. Shown in credits on websites, in-game and more. Insight and contacts from within the Industry.
       
      Contact
      If you are interested in knowing more or joining, please email or PM us on Skype. A member of our management team will reply to you within 48 hours.
       
      E-mail: Recruitment@ForgedInteractive.com
      Skype: ForgedInteractive
       
      Regards,
      David, Colin and Joseph
       
      Follow us on:
      Facebook: https://www.facebook.com/ForgedInteractive/
      Twitter: @ForgedInteract
      Youtube: https://www.youtube.com/channel/UCpK3zhq5ToOeDpdI0Eik-Ug?view_as=subscriber
      Reddit: www.reddit.com/user/Forged_Interactive

    • By dell96
      I'm trying to make my first project but I'm stuck i don't know how to make my crate to start to spawn again when i hit the start button after i die.
      hoping someone can help!!!
      Crate.cs
      CrateSpawn.cs
      Cratework.cs
      GameController.cs
      GameManager.cs
  • Popular Now