News Forums RAIN General Discussion and Troubleshooting Few questions from a new user

This topic contains 9 replies, has 2 voices, and was last updated by  prime 4 weeks, 1 day ago.

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #34895

    darkhog
    Participant

    1. How do I write Custom Motor?
    My game is using physics-based (rigid bodies) movement for objects. There is no such motor, that would move object around using physical forces and the wiki entry for a custom motor is empty: http://rivaltheory.com/wiki/customization/custommotor

    2. How to (at runtime) create a waypoint in a network and connect it to two other closest waypoints (in a network)?
    This is required for a level editor part of the game as I plan to bundle quite powerful level editor along with it which will actually be used to create levels for the game (main campaign).

    3. If I save enemy that has been set up for AI (behavior tree, etc.) in prefabs, will it load properly if I’ll instantiate (spawn) it later on, say, when level is being loaded?

    4. How to make areas that AI can jump over.
    Say I have small ridge in the level. It’s in fact so small that you could easily jump over it and so should AI.

    #34901

    prime
    Keymaster

    1) To create a custom motor, just create a new class that derives from either RAINMotor or BasicMotor. Physics based movement is tough, so I would suggest that you create a motor directly from RAINMotor.

    2) You can get a list of waypoints in a network from the WaypointSet. A WaypointSet is the underlying RAIN class attached to a WaypointRig. WaypointRigs are not necessary if you are creating waypoints at runtime. Each WaypointSet must have a unique name and be registered/unregistered when it is created or destroyed.

    WaypointSet _waypointSet = new WaypointSet();
                _waypointSet.Name = name;
    	    NavigationManager.Instance.Register(_waypointSet);
                NavigationManager.Instance.Unregister(_waypointSet);

    The WaypointSet itself has methods for adding and connecting waypoints to each other.

    3) Yes

    4) That’s a tough question, especially if you plan to use automatic NavMesh generation. First, you will probably need to set tags on the ridges so they are ignored by the NavMesh generator. If you don’t then they will appear unwalkable and the AI will never try to cross over them. Second, you will want to add markers (Entity/Aspects probably) at various “step over” locations along the ridge. The AI will need to detect these and go into a “step over” animation when it gets close enough. It will take some experimenting for you to get it right, but it is certainly doable.

    #35003

    darkhog
    Participant

    Thank you. Since I’ve got rid of movement bug regarding player character, I’ll start building a level editor soon and after that I’ll start implementing RAIN and make AI.

    I’ve thought some and I think I’ll try existing motors and see if they are good enough for what I’m trying to achieve, then if not I’ll get to writing physics-based one (1).

    As for (4), isn’t there a way to calculate “size” of the hole and do something based on it (e.g. if it’s smaller than say 2 units, AI will try to jump over instead of walking around, unless there’s a wall in the way)?

    I can’t go with tag solution as the level editor will be both dev tool and available to users, so I need to make it as user-friendly as possible and it needs not to require some black magic to use and make fun levels with it. So the best way would be to detect if hole in generated navmesh is small enough and there aren’t any walls in the way and do jump based on it.

    #35004

    prime
    Keymaster

    We don’t have an easy answer for you on (4) just yet. We don’t have a solution for detecting holes in the navmesh right now, nor a solution for triggering behaviors at certain points on the navmesh. We’re working on a few things that could help, but they will take a while to complete. (For example, we’re looking at dealing with “gaps” rather than holes. Not sure where we would stitch vs. where we would provide behavior links.)

    #35005

    darkhog
    Participant

    That’s okay. I guess I’ll just have to avoid holes/gaps in levels that are to be bundled with IndieGoGo demo (I intent to give potential backers something playable) and since “proper” game (all levels and all enemies/goal types) will take some time to finish I’m sure either you and I will be able to figure something up. If I’ll get over the funding goal, I may even give you some donation to encourage you to work on it faster ;).

    #35242

    darkhog
    Participant

    Hm… Is there a way to raycast through navmesh (and only navmesh)? Because I have somewhat clever idea that could check for gaps and then check if gap is big enough (involves raycasts).

    Gap check: Cast a ray downwards in front of enemy (“minimal” distance where having gap would matter). If it doesn’t connect with navmesh after distance being equal to character height, we have a gap.

    Checking if gap is small enough: Similarly, cast a ray in certain distance from enemy (in front of it), maximum distance AI can jump over, if it connects with navmesh gap is small enough.

    #35247

    prime
    Keymaster

    This method on the NavMeshGraph may do what you want:

    public override NavigationGraphNode QuantizeToNode(Vector3 aLocation, float aMaxYOffset)

    It returns the closest NavMeshPoly intersected by a vertical ray at the specified location. The ray starts at aLocation.y + aMaxYOffset and extends down infinitely. Then check the poly to determine the actual distance.

    poly.GetYInterceptPoint(point, out intercept)
    #35248

    darkhog
    Participant

    Thank you. But can’t it be done via regular Physics.Raycast? I’d prefer it that way, as it would make code easier for me to write.

    #35297

    prime
    Keymaster

    Yes. You just need to make a method call to determine if you are raycasting through the navmesh. That could be just the QuantizeToNode call (which would return null if the point is not on the mesh). Keep in mind that the raycast will be less reliable and significantly slower.

    #35298

    prime
    Keymaster

    Hmm. Not sure what I was thinking here. Of course the method I recommended won’t work. As you mentioned, you are checking for gaps. If there is a gap, then there definitely won’t be a navmesh covering it. On the other hand, that means you can’t test for “through the navmesh”. So, you could do 2 raycasts. One forward (is there an object blocking me) and one down (is there a gap).

Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.