Difference between revisions of "Behaviors"

From Valve Developer Community
Jump to: navigation, search
(this article still won't get a behviour working on its own, but it's a damn sight closer to that goal than it was before!)
m (Authoring a behavior)
Line 3: Line 3:
 
== Authoring a behavior ==
 
== Authoring a behavior ==
  
Behavior code, for the most part, behaves in the same way as AI code you would write directly into an NPC. There is a certain amount of 'glue' required between one and the NPCs that will use it however:
+
Behavior code, for the most part, behaves in the same way and uses the same framework as AI code you would write directly into an NPC. There is a certain amount of 'glue' required between one and the NPCs that will use it however:
  
 
=== The behavior ===
 
=== The behavior ===
Line 21: Line 21:
 
*Call <code>BehaviorSelectSchedule()</code> at some point in <code>[[SelectSchedule()]]</code>. This probably already happens if you're working with a stock NPC.
 
*Call <code>BehaviorSelectSchedule()</code> at some point in <code>[[SelectSchedule()]]</code>. This probably already happens if you're working with a stock NPC.
  
=== Activating a behaviour manually ===
+
== Activating a behaviour manually ==
  
 
Behaviours are evaluated on every [[NPCThink()|think]] with the logic in <code>CanSelectSchedule()</code>. If you want to manually enable a behavior until you disable it:
 
Behaviours are evaluated on every [[NPCThink()|think]] with the logic in <code>CanSelectSchedule()</code>. If you want to manually enable a behavior until you disable it:

Revision as of 17:13, 28 May 2008

Behaviors let you abstract AI code to a C++ class of its own which is not tied to any one NPC. You might want to create MensBathroomBehavior for male NPCs and WomensBathroomBehavior for female NPCs, for instance.

Authoring a behavior

Behavior code, for the most part, behaves in the same way and uses the same framework as AI code you would write directly into an NPC. There is a certain amount of 'glue' required between one and the NPCs that will use it however:

The behavior

  • Create bool CanSelectSchedule(), which defines whether or not an NPC will 'defer' to the behavior for a given think.
  • Create virtual const char *GetName() { return "MyBehavior friendly name"; }.
  • Use AI_BEGIN_CUSTOM_SCHEDULE_PROVIDER instead of AI_BEGIN_CUSTOM_NPC (in the body).
  • Use DEFINE_CUSTOM_SCHEDULE_PROVIDER instead of DEFINE_CUSTOM_AI (in the header).
  • Use GetOuter()-> to access the NPC object.

The NPC

  • Include the header for your new behavior, and ai_behavior.h.
  • Create an member instance of your behavior.
  • Register the instance in CreateBehaviors() with AddBehavior( &m_MyBehavior ).
    • None of Valve's NPC base classes have any behaviors registered - it may not be possible to do it at that level.
  • Call BehaviorSelectSchedule() at some point in SelectSchedule(). This probably already happens if you're working with a stock NPC.

Activating a behaviour manually

Behaviours are evaluated on every think with the logic in CanSelectSchedule(). If you want to manually enable a behavior until you disable it:

MyNPC::SelectSchedule()
{
	if ( m_MyBehavior.m_bActive )
	{
		DeferSchedulingToBehavior( &m_MyBehavior );	// Normally happens in BehaviorSelectSchedule()
		return BaseClass::SelectSchedule();		// This will now poll your behavior
	}

	...
}

Warning: Until you release it, this will lock the NPC into your behavior code and only your behavior code.