Guidelines for Adding a New Entity, Behavior, or Attribute into Tequila | COMP 410, Study Guides, Projects, Research of Software Engineering

Material Type: Project; Class: SOFTWARE ENGINEERING METHODOLOGY; Subject: Computer Science; University: Rice University; Term: Spring 2005;

Typology: Study Guides, Projects, Research

Pre 2010

Uploaded on 08/16/2009

koofers-user-mp0-1
koofers-user-mp0-1 🇺🇸

10 documents

1 / 2

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Guidelines for Adding a New Entity, Behavior, or Attribute into Tequila
Jessica Wu
Comp 410
April 12, 2005
Before you start
Because we can install any new entity and attribute into the system, and because behaviors check for strings
rather than classnames, there is the potential for lots of bugs due to different strings being used. Therefore, I
have set up two databases to keep track of these names under Tequila Attributes and Tequila Behaviors at http://
www.bandgap.cs.rice.edu/sites/comp410s05/model/default.aspx.
When coding for a new scenario, you should always start with attributes, then behaviors, then entities. This was
chosen because attributes can be modified using different behaviors, and behaviors can be shared among
entities. Also, this order makes sure that the behaviors modify attributes that are potentially in the system
(rather than modifying some attribute that exists in the ether). With that in mind…
Attributes
Before you even start coding, go to http://www.bandgap.cs.rice.edu/sites/comp410s05/model/default.aspx and
fill out a new entry for your attribute under Tequila Attributes.
Attributes are very simple and require no actual code in Tequila. They exist purely as a data entry in the
relationship between entities, behaviors, and attributes. Entities contain attributes, and behaviors modify
attributes.
Each attribute contains
-EntityGUID: The guid of the entity that contains this attribute.
-AttributeKey: The name of this attribute, i.e. Name, HP, MovementSpeed, etc. AttributeKey’s can be
duplicated if attached to different entities.
-AttributeValue: The value of this attribute. Usually a string (for player names or entity names) or
integer (for anything that a behavior modifies).
-AttributeGUID: The unique guid associated with this attribute.
Behaviors
Before you even start coding, go to http://www.bandgap.cs.rice.edu/sites/comp410s05/model/default.aspx and
fill out a new entry for your behavior under Tequila Behaviors. All behaviors should be found under the
namespace SkyNet.Model.ServerAssembly.Behaviors.
Behaviors are what make Tequila into a game, well, game-like. Entities can execute behaviors to modify their
own or other entity’s attributes. A behavior requires you to write an actual class in Tequila under the
namespace SkyNet.Model.ServerAssembly.Behaivors.BehaviorName and inherit from ISendingBehavior or
IReactingBehavior. For more detail, read Clement’s document (which you should do before you code anyway).
From the database side, each SendingBehavior (or RespondingBehavior) contains
-EntityGUID: The guid of the entity that can execute this behavior.
-BehaviorClass: The full classname of this behavior. BehaviorClass tells Tequila what filename to
execute from. All classnames should end in Behavior. These names can be duplicated inside the
database, but each unique classname corresponds to only one behavior class in the namespace.
pf2

Partial preview of the text

Download Guidelines for Adding a New Entity, Behavior, or Attribute into Tequila | COMP 410 and more Study Guides, Projects, Research Software Engineering in PDF only on Docsity!

Guidelines for Adding a New Entity, Behavior, or Attribute into Tequila

Jessica Wu Comp 410 April 12, 2005

Before you start

Because we can install any new entity and attribute into the system, and because behaviors check for strings rather than classnames, there is the potential for lots of bugs due to different strings being used. Therefore, I have set up two databases to keep track of these names under Tequila Attributes and Tequila Behaviors at http:// www.bandgap.cs.rice.edu/sites/comp410s05/model/default.aspx. When coding for a new scenario, you should always start with attributes, then behaviors, then entities. This was chosen because attributes can be modified using different behaviors, and behaviors can be shared among entities. Also, this order makes sure that the behaviors modify attributes that are potentially in the system (rather than modifying some attribute that exists in the ether). With that in mind…

Attributes

Before you even start coding, go to http://www.bandgap.cs.rice.edu/sites/comp410s05/model/default.aspx and fill out a new entry for your attribute under Tequila Attributes. Attributes are very simple and require no actual code in Tequila. They exist purely as a data entry in the relationship between entities, behaviors, and attributes. Entities contain attributes, and behaviors modify attributes. Each attribute contains

  • EntityGUID : The guid of the entity that contains this attribute.
  • AttributeKey: The name of this attribute, i.e. Name, HP, MovementSpeed, etc. AttributeKey’s can be duplicated if attached to different entities.
  • AttributeValue : The value of this attribute. Usually a string (for player names or entity names) or integer (for anything that a behavior modifies).
  • AttributeGUID : The unique guid associated with this attribute.

Behaviors

Before you even start coding, go to http://www.bandgap.cs.rice.edu/sites/comp410s05/model/default.aspx and fill out a new entry for your behavior under Tequila Behaviors. All behaviors should be found under the namespace SkyNet.Model.ServerAssembly.Behaviors. Behaviors are what make Tequila into a game, well, game-like. Entities can execute behaviors to modify their own or other entity’s attributes. A behavior requires you to write an actual class in Tequila under the namespace SkyNet.Model.ServerAssembly.Behaivors.BehaviorName and inherit from ISendingBehavior or IReactingBehavior. For more detail, read Clement’s document (which you should do before you code anyway). From the database side, each SendingBehavior (or RespondingBehavior) contains

  • EntityGUID : The guid of the entity that can execute this behavior.
  • BehaviorClass : The full classname of this behavior. BehaviorClass tells Tequila what filename to execute from. All classnames should end in Behavior. These names can be duplicated inside the database, but each unique classname corresponds to only one behavior class in the namespace.
  • RequireMouseClick : A Boolean set to true if a mouse click is required, i.e. for MoveBehavior and AttackBehavior, or false if a mouse click is not required, i.e. for DefendBehavior.
  • SendingBehaviorGUID : The unique guid associated with this behavior.
  • Caption : A string that is put on the button that the user clicks to execute this behavior. Also referred to as the “short name” of the behavior.
  • DisplayedToUser : A Boolean set to true for SendingBehavior or false for RespondingBehavior.
  • OptionalTag : A string that can provide extra information the behavior might need. For example, it could provide the name of the entity to deselect in the deselect behavior (which is unique in that it lies solely on the userModel and has no corresponding serverModel behavior), or it could provide the filename of the *.xml file to load when creating a unit for CreateUnitBehavior. From the database side, each ReactingBehavior contains
  • EntityGUID : Same as for SendingBehavior.
  • BehaviorClass : Same as for SendingBehavior except all names should end in ReactingBehavior to easily distinguish it from a SendingBehavior, i.e. MoveReactingBehavior.
  • ReactingBehaviorGUID : The unique guid associated with this behavior. When coding a behavior, try to refrain from having to compare an attribute against a specific value that could degenerate into a huge list of comparisons. For example, in MoveReactingBehavior, do not compare the attribute name of the current entity against every possible type of terrain. Rather, make each terrain have an attribute that you would GetAttribute(AttributeName) in the behavior. If you want output to the user, put in a Console.WriteLine that outputs the name of the terrain entity through GetAttribute(“Name”).

Entities

The entity just ties everything together in the SQL database and provides a way for the user to actually do stuff in the game. Like attributes, there is no actual code in Tequila for an entity, just a data entry. Unlike attributes, entities are special in that everything in the SQL database is linked through the EntityGUID. Only after you have finished creating the attributes that belong to this entity and the behaviors that it can execute (as well as the referencing the correct mediaPackage) can you finally encode your scenario into the game. As a note, player entities are top level and do NOT contain a ParentGUID. All other entities must be linked to a player through the player’s guid. Player entities do not have an associated Area in the Area dataset while all other entities do.

Afterward

Make sure you run your own server and client to test what you have just added to the system!