[primeKeymaster]

First off - your game looks really great so far. Those are randomly generated levels? Awesome.

As far as the pathing issue - we think we know what that is, and we think it is fixed in the new version of RAIN we’ll be releasing this week. If you need the fix sooner, email jester (@rivaltheory.com)

Thanks

[primeKeymaster]

Good questions. RAIN isn’t really built for 2D. We’ve been wanting to add 2D support for some time, but just haven’t been able to get to it yet. Here are some of the difficulties:

1) 2D usually uses a different coordinate system. RAIN is build on the standard Unity 3D coordinates and makes some assumptions there in a few places.
2) RAIN doesn’t recognize 2D geometry or colliders when doing things like generating navmeshes, raycasting, etc.
3) Although you could work around these issues, you will probably need to create your own Motor and Navigator to do so.

Things that should generally work regardless of 2D/3D:
1) AI Memory
2) AI Behavior Tree
3) Entities/Aspects/Sensors that don’t do raycasting and use radius detection only.
4) Mecanim support
5) Audio support
6) Custom AI elements

On the one hand, it isn’t terribly difficult to write a 2D motor and navigator - much simpler than the 3D case - but on the other hand it does require some knowledge of RAIN. You are also free to use the HeuristicSearch class for your A* pathfinding.

If you decide to use RAIN, reach out to us directly (support@rivaltheory.com) when you have questions/issues.

[primeKeymaster]

Hmm. I suspect something can be done. One of the things that makes pre-generated navmeshes tough to work with in RAIN is that we don’t currently automatically support translation/rotation/scaling of navmeshes. So you could pre-create navmeshes for rooms, halls, and other components, but you would have to manually update the mesh points after the room is placed in the level.

We have this on our roadmap - to support arbitrary (and even dynamic) positioning of navmeshes at runtime, but haven’t been able to get to it just yet.

I’ll ask @sigil to jump in and answer this one - he’s the navmesh guru.

[primeKeymaster]

Sounds like a big project. We’ve had learning and education companies work with RAIN in the past to create libraries of behaviors that are stored in their LMS, then retrieved for situational training. Anyone else on the forums have experience with this?

[primeKeymaster]

What kind of tutorials are you making? Are these tutorials for learning game development, or do you want to use game dev tools to create tutorials for other types of work?

[primeKeymaster]

Not sure - it’s a little hard to tell from that screen shot. Is the destination target moving or stationary?

[primeKeymaster]

Typically you won’t do anything different in a custom action vs what you would do in any other Unity script. You probably want to do the SendMessage or similar as I suggested. The only tricky part is knowing which object to send the message to. However, if you are sending damage to the player, then you probably detected the player in a Detect node and have the object in ai memory. If so, then your Execute code will simply be:

GameObject tPlayer = ai.WorkingMemory.GetItem<GameObject>("player"); //assuming you store the player object in a variable called player
tPlayer..SendMessage(“Damage”, 1.0f, SendMessageOptions.DontRequireReceiver); //assuming you do 1.0 damage

[primeKeymaster]

When you say it is not stopping, do you mean it keeps moving past the target, or do you mean that it stops moving but continues animating?

[primeKeymaster]

Sorry for the delay - already gave my answer as a reply to the other post.

[primeKeymaster]

Next, you will probably want to use that in a SELECTOR:

SELECTOR
-SEQUENCER
—-CUSTOMACTION //Your IsDialogEnd
—-MOVE(waypoint) //Your move to waypoint action
-SOME OTHER BEHAVIOR

or, if you are simply waiting for a dialog to finish, then

SEQUENCER
— CUSTOMACTION (Repeat until success) //Your IsDialogEnd
— MOVE(waypoint) //Your move to waypoint action

[primeKeymaster]

Real quick clarification on Decisions vs. Actions. Decision nodes are typically container nodes that define how a set of child nodes are processed. Examples are Sequencer, Selector, and Parallel. Action nodes typically don’t have children and either perform some task, or evaluate some condition. So in this case I suspect you want a RAINAction, not a RAINDecision. You could use the result (SUCCESS/FAILURE) as your condition for taking action, much like an Expression node is used.

So your code becomes:

using UnityEngine;
using System.Collections;
using System.Collections.Generic;
using RAIN.Action;
using RAIN.Core;
using PixelCrushers.DialogueSystem;
[RAINAction("Is Dialog End")]
public class IsDialogEnd: RAINAction
{
    public override ActionResult Execute(RAIN.Core.AI ai)
    {
        return (DialogueLua.GetVariable("end").AsBool) ? ActionResult.SUCCESS : ActionResult.FAILURE;
    }
}

[primeKeymaster]

The MonoBehaviour that you can look for on the player object is an EntityRig. So

EntityRig tRig = playerGameObject.GetComponentInChildren<EntityRig>();
if (tRig != null)
  tRig.Entity.IsActive = false;

[primeKeymaster]

If you have two waypoints selected, it should add a connection between them.

[primeKeymaster]

There isn’t a built in node to do it. However, you could write a custom action to do it. It would look something like this:

using UnityEngine;
using System.Collections;
using System.Collections.Generic;
using RAIN.Action;
using RAIN.Core;
using RAIN.Representation;
using RAIN.Animation;
using RAIN.Motion;
[RAINAction("Check Mecanim Parameter Value")]
public class CheckMecanimParameter : RAINAction
{
    public Expression ParameterName = new Expression();
    public Expression ParameterValue = new Expression();
    private Animator _mecanimAnimator;
    public override void Start(RAIN.Core.AI ai)
    {
        base.Start(ai);
        if (_mecanimAnimator == null)
        { 
            if (ai.Animator is MecanimAnimator)
                _mecanimAnimator = ((MecanimAnimator)ai.Animator).UnityAnimator;
            if ((_mecanimAnimator == null) && (ai.Motor is MecanimMotor))
                _mecanimAnimator = ((MecanimMotor)ai.Motor).UnityAnimator;
            if (_mecanimAnimator == null)
                _mecanimAnimator = ai.Body.GetComponentInChildren<Animator>();
        }
    }
    public override ActionResult Execute(RAIN.Core.AI ai)
    {
        if (_mecanimAnimator == null)
            return ActionResult.FAILURE;
        if (!ParameterName.IsValid || !ParameterValue.IsValid)
            return ActionResult.FAILURE;
        string tParameter = ParameterName.Evaluate<string>(ai.DeltaTime, ai.WorkingMemory);
        bool tValue = ParameterValue.Evaluate<bool>(ai.DeltaTime, ai.WorkingMemory);
        if (_mecanimAnimator.GetBool(tParameter) == tValue)
            return ActionResult.SUCCESS;
        return ActionResult.FAILURE;
    }
}

[primeKeymaster]

Nice job figuring that out. We do something very similar in our Squad Command package - a path is calculated from soldiers taking cover behind buildings to various hotspots in the scene. We then use the path to determine which direction the soldier should face while taking cover.

One more thing to consider - although the path is smoothed, it is still possible that the first few steps in the path don’t lead in the direction of the final target. You might want to analyze the points for some distance along the path (maybe the distance traveled in a couple of seconds) to make sure the next waypoint isn’t a small detour or outlier.

[Author]

Posts