Software Requirements Specification

Wings by Daedalus

Table of Contents
Table of Contents
1 Introduction
1.1 Contact Information
1.1.1 Daedalus Development Team
1.1.2 Project Sponsor
1.1.3 Project Advisor
1.2 Purpose
1.2.1 Iterative Development Methodology
1.3 Scope
1.4 Definitions and Acronyms
Table 1-2 Acronyms
1.5 References
2 General Descriptions
2.1 Product Perspective
Figure 2-1 Leadwerks Flowgraph Editor
Figure 2-2 Leadwerks Editor
2.2 Users
2.2.1 Game
2.2.2 Game Developer
2.2.3 System Context
Figure 2-3 Wings System Context Diagram
2.3 Agent Models
Figure 2-4 Approaches to Defining Agents
Figure 2-5 Model of a Wings Agent
2.4 Use Case Models
Figure 2-6 Wings Primary Use Case Diagram
Figure 2-7 Manage Wings Flow Diagram
Figure 2-8 Create Agent Flow Diagram
Figure 2-9 Design Agent Flow Diagram
Figure 2-10 Modify Agent Flow Diagram
Figure 2-11 Manage Agent Interactions Flow Diagram
2.5 Non-Functional Requirements
Figure 2-13 Non-Functional Requirements
2.6 General Constraints
2.7 Assumptions and Dependencies
3 Specific Requirements
3.1 Use Case Specification

SRS 1
 3.1.1 Manage Wings
3.1.2 Create Agent
3.1.3 Design Agent
3.1.4 Modify Agent
3.1.5 Manage Agent Interactions
3.1.8 Additional Functional Requirements
3.1.9 Object Model
Figure 3-1 Object Model Diagram
3.2 Performance Requirements
3.3 Design Constraints
3.4 Quality Attributes
3.4.1 Tinkerability
3.4.2 Reliability
3.4.3 Maintainability
3.4.4 Portability
3.4.5 Program Quality Attributes
Robustness
Performance
3.4.6 Security
3.4.7 Testability
3.5 Deployment Configurations
4 Approvals
4.1 Version History
Table 4-1 Version and Revision History
4.2 Signatures
5 Appendices
Appendix A: Data Dictionary
A-1 Elements
A-2 Data Structures

1 Introduction
This document is the software requirements specification for the Wings project sponsored by Josh Klint,
CEO of Leadwerks Software.

This project is undertaken by the Daedalus development team. The team is comprised of undergraduate
students majoring in Computer Science at California State University, Sacramento. The team members
are enrolled in a two-semester senior project course required of all undergraduate majors. Successful
delivery of the software product will fulfill the senior project requirement for the student team
members.

1.1 Contact Information

1.1.1 Daedalus Development Team
SRS 2
 Tim Shea Ethan Weidman Chris Lawson
Removed Removed Removed

Ken Barnett Tate Chamberlain

Removed Removed

1.1.2 Project Sponsor

Josh Klint
Chief Executive Officer
Leadwerks Software
Removed

1.1.3 Project Advisor

Ahmed Salem
Associate Professor
California State University, Sacramento
Removed

1.2 Purpose
This document will serve to formalize and document the requirements of the Wings project. Upon
approval, this document will serve as an agreement that the elicited requirements fully specify the
functions and behaviors required of the system. It will additionally be used to evaluate the solutions
proposed during the modeling phase and validate the implementation during the construction phase.

1.2.1 Iterative Development Methodology

Daedalus has adopted a formal development methodology which incorporates iterative and incremental
development of all major project deliverables. This document will not be considered final until the final
planning phase is concluded (approximately April 2014). Sections of this document will be omitted or
included in draft form until that time. Prior to the conclusion of each planning phase, requirements for
that iteration will be fully specified and approved by the project sponsor and advisor.

1.3 Scope
This document includes formal requirements for the Wings project. It also describes assumptions,
constraints, and project limitations, and documents the context in which the system will operate. For a
description of the development team, refer to the team prospectus. For a descriptive summary of the
project and the development plan, refer to the project charter. For a description of the software solution
and technical planning information, refer to the software requirements specification. Finally, for a

SRS 3
description of the testing plan, refer to the software test specification.

1.4 Definitions and Acronyms

Table 1-1 Definitions
Word/Phrase Definition

Action A mechanism by which an Agent affects the state of its environment.

Actor The term Actor has 2 distinct meanings, depending on context:

1. When referring to the system as a whole, an Actor is anything
(persons or devices) that communicates with the system and is
external to the system itself. An Actor is a role that people or devices
play as they interact with the system. Actors in this sense are
sometimes referred to as users.
2. When referring to agent theory and the inner working of the
system, an Actor is any entity in a game that has Perceptions and can
take Actions. An Actor is the means by which an Agent interacts with
its Environment.

Agent An entity which perceives and acts in an environment according to a

reasoning process. Note: See Agent Models for a more detailed
consideration of Agents.

Agent State The set of goals, plans, knowledge, and characteristics that influence
an agent’s reasoning process.

Application Programming A set of classes and functions available to an application programmer,

Interface including the parameters that are passed to each function and the
return values the programmer can expect.

Artificial Intelligence The ability of an Agent to act in a way that achieves its goals or
satisfies its motives.

Environment The virtual world of a video game. Consists of entities and defined
interactions.

Entity An object physically represented within the Leadwerks game world.

Goal A specific, reachable state of the environment which is desired by an

Agent.

Integrated Development A software application that provides comprehensive facilities to

Environment computer programmers for software development. This often
consists of a GUI source code editor, build automation tools, a
debugger, and a compiler and/or interpreter.

Perception A mechanism by which an Agent determines the state of its

SRS 4
 environment.

Software Requirements The documentation of the essential requirements

Specification (functions/features/uses, performance, design constraints, and
attributes) of a system and its external interfaces; this document.

Stakeholder A person or persons with a stake in the successful outcome of the

project.

System A software product and its associated tools and materials.

System Context Diagram A diagram that defines the boundaries between the system and its
environment, as well as showing the Actors that interact with the
system.

Use Case A description of a system’s behavior under various conditions as the

system responds to a request from one of its stakeholders.

Table 1-2 Acronyms

Acronym Full Phrase

AI Artificial Intelligence

API Application Programming Interface

CSUS California State University, Sacramento

FR Functional requirement

IDE Integrated Development Environment

NFR Nonfunctional requirement

SCD System Context Diagram

SRS Software Requirements Specification

UC Use Case

UML Unified Modeling Language

1.5 References
“AI Architectures: A Culinary Guide” Dave Mark, Game Developer Magazine: August 2012.
http://intrinsicalgorithm.com/IAonAI/2012/11/ai-architectures-a-culinary-guide-gdmag-article/

AI for Game Developers David M. Bourg

SRS 5
AI Game Engine Programming Brian Schwab

Artificial Intelligence: A Modern Approach 3rd Edition Stuart J. Russell and Peter Norvig

“Guide to Preparing the Software Requirements Specification Document” R. Buckley,

athena.ecs.csus.edu/~buckley/CSc190/SRS.pdf

“Introduction to Behavior Trees” Björn Knafla,

http://www.altdevblogaday.com/2011/02/24/introduction-to-behavior-trees/

“Understanding Second Generation Behavior Trees” Alex J. Champandard, video

http://aigamedev.com/insider/tutorial/second-generation-bt/

2 General Descriptions
This section includes general descriptions of Wings and the context in which it will operate. Diagrams are
provided to model the system context, features, and related concepts.

2.1 Product Perspective

The Wings artificial intelligence library will be deployed in two configurations: a development
configuration for use by game developers and a production configuration as a component of distributed
games.

In the development configuration, Wings will provide a library and set of tools for creating intelligent
agents in a game. The game engine will provide for input, graphics, physics, audio, and other general
purpose functionality. Wings will interface with these systems indirectly through the Wings Agent API.

The Wings library will be independent of any particular game engine. The library and game engine will
interact through an adapter for the Wings Agent API. In addition to creating the standalone AI library, the
Wings project will include the development of a Leadwerks adapter for Wings.

The Leadwerks adapter for Wings will adapt Leadwerks engine features for use in Wings and
encapsulate Wings features for use in Leadwerks games. The Leadwerks editor, an IDE for the
Leadwerks engine, will allow Game Developers to use Wings features in a graphical environment.

In the production configuration, Wings will be delivered as a component of the game application. The
Wings library and adapter will be initialized and invoked by the game during each execution. Wings will
interact with embedded game engine systems through the adapter.

SRS 6
 Figure 2-1 Leadwerks Flowgraph Editor
Figure 2-1 displays the Flowgraph Editor, an existing tool for designing interactions in Leadwerks.
Entities in Leadwerks can have scripts attached to them through the editor. These scripts can be
connected through the Flowgraph Editor or through C++.

SRS 7
 Figure 2-2 Leadwerks Editor
Figure 2-2 displays the Leadwerks Editor with a map file loaded. The tabs to the right provide access to
all the assets in the project and objects in the scene. The Asset Tab is where Game Developers can
access the Wings Lua interface from the Editor.

2.2 Users
Two users will use Wings: Game and Game Developer. Each actor is briefly described below, and a
system context diagram is provided to show the associations each actor has with Wings.

2.2.1 Game
A Game is a system that is designed and created by Game Developers, and its creation is facilitated by
using the Leadwerks game engine. Leadwerks Software produces and maintains Leadwerks. Leadwerks
is a game engine which renders 3D graphics, simulates physics, detects collisions, produces sound,
scripting, animation, and memory management. Leadwerks assists Game Developers by economizing
many time-consuming development tasks so they can focus on game design. If Wings has been
connected to a Leadwerks project, the Game will initialize Wings via the Leadwerks adapter. Leadwerks
will provide an interface to engine components and game objects to interact and manipulate Wings
components via the Agent API. Wings will produce behaviors for the Game and AI content for the
Leadwerks IDE, in a manner configurable by the Game Developer. The Game is also responsible for
dynamically updating the logic of Wings Agents, and manipulating Wings Agents during runtime due to
triggers, events, or gameplay rules specified by the Game Developer at design time.

SRS 8
2.2.2 Game Developer
A Game Developer is a person or group that creates video games using Leadwerks and wants to
incorporate the advanced artificial intelligence techniques within Wings into their games. This is in order
to provide more interesting gameplay for their Game. As part of their game design process, Game
Developers will configure AI content using the Wings API and the Leadwerks IDE. The parameters and
techniques from Wings they will wish to use will vary, and will depend on the type of game they are
creating and their own creative vision for their software.

2.2.3 System Context

The Wings system will consist of the core library, indicated by the blue oval in Figure 2-1, the Agent API,
and the Leadwerks adapter. The Agent API will encapsulate AI algorithms and provide a uniform,
user-friendly interface that Game Developers can use to specify actions, perceptions, goals, and motives
to characters and objects within a game. The Leadwerks adapter will be the portion of Wings designed
specifically to bridge the internal techniques of Wings with an interface compatible with Leadwerks. The
system will be used by the Game Developer and Game as identified in Figure 2-3.

Figure 2-3 Wings System Context Diagram

2.3 Agent Models

A primary goal of the Wings project is to provide game developers with artificial intelligence
functionality in a format that is accessible and customizable. In the field of artificial intelligence, self
contained intelligent systems are referred to as Agents. Wings will allow game developers to design and
manage agents using an abstract Agent API. Numerous use cases and functional requirements refer to
the Agent API as it comprises the core of the system and establishes the terms under which other
features can be successfully analyzed. However, the notion of an intelligent agent on which the API is
based has numerous definitions across academic and industrial literature. For this reason, a simplified
discussion of agents is included here to reflect the working definition adopted by the Daedalus team.

SRS 9
 Figure 2-4 Approaches to Defining Agents
The two most common approaches to defining agents in artificial intelligence are by characteristics and
by components as shown in Figure 2-4. These approaches could be described as implicit and explicit
respectively. The implicit approach lends itself to more flexible definitions based on intelligence,
rationality, or human behaviors. However, the definition can only be as concrete as the characteristics
which can result in confusion during analysis and implementation. The component approach leads to an
unambiguous, practical definition of agents, although one that is more exclusive.

For the Wings project, Daedalus is adopting a component view of agents. This decision will eventually
contribute to the design of the Agent API, but more immediately defining the components of an agent
allows the development team to apply common and consistent terminology throughout the planning
process and to functionalize business requirements.

SRS 10
 Figure 2-5 Model of a Wings Agent
In this document and in the Wings library an agent will refer approximately to an entity in a game
environment with several components: a reasoning process which possibly makes use of some internal
state, perceptions, and actions. A possible schema for an agent is depicted in Figure 2-5. Reasoning
refers to a self-contained algorithm or set of algorithms for selecting actions based on perceptions.
Perceptions collect information about the agent’s environment as input to the reasoning process. Actions
modify the environment when invoked by the reasoning process.

2.4 Use Case Models

Each of the users identified in Section 2.2 will expect certain features and functionality from the Wings AI
library. The features Wings will provide are modeled here in UML Use Case Diagrams and described in
greater detail in Section 3.

SRS 11
 Figure 2-6 Wings Primary Use Case Diagram
The primary Wings use cases represent the major groups of functionality which the system is to provide.
The Game Developer and the Game will each invoke various features for managing the Wings engine as
a whole, agents in the engine, and the agent environment. Much of the functionality crosses over from
design to runtime, with the Game Developer using Wings to design and the Game invoking the library to
run AI.

SRS 12
 Figure 2-7 Manage Wings Flow Diagram
Figure 2-7 elaborates UC 1 Manage Wings. This use case encompasses the management of the library as
a whole. The use case consists of eight required functions and one optional function

SRS 13
 Figure 2-8 Create Agent Flow Diagram
Figure 2-8 elaborates UC 2 Create Agent. The Create Agent use case includes designing and instantiating
intelligent agents in a game.

Figure 2-9 Design Agent Flow Diagram

Figure 2-9 elaborates UC 3 Design Agent. This use case is included in UC 3 Create Agent. Designing an
agent includes defining components and state.

SRS 14
 Figure 2-10 Modify Agent Flow Diagram
Figure 2-10 elaborates UC 4 Modify Agent. This use case includes runtime modifications to an agent’s
design and state.

Figure 2-11 Manage Agent Interactions Flow Diagram

UC 5 Manage Agent Interactions is elaborated in Figure 2-11. This use case involves defining, adding, and
removing interactions.

2.5 Non-Functional Requirements

NFRs represent the quality attributes of the system. They define how the system is supposed to be in
terms of the performance and quality of the system as a whole. Figure 2-13 depicts the major NFRs for
Wings ordered in terms of priority. However, it should be emphasized that each NFR implies a different

SRS 15
set of considerations which are discussed in more detail in Section 3.4. Tinkerability is the primary
indicator of quality for this project. Wings should be as configurable as it can be, and ease of use for
game developers is a priority. This will possibly have a negative impact on the maintainability and
testability, but a flexible system is desired from the project sponsor to allow for user freedom. Reliability
is also a primary indicator of quality for Wings. If a compromise must be made between reliability and
robustness or performance, Daedalus will focus on maximizing reliability. The project sponsor has
indicated that a smaller set of reliable features is preferable to the maximum set of features with
varying levels of reliability. Daedalus will not be implementing multithreading for Wings, but our sponsor
requires Wings to be thread-safe for increased extensibility.

Figure 2-13 Non-Functional Requirements

2.6 General Constraints

Team members will have access to the Leadwerks software. As Leadwerks is updated during the Wings
project, the team and sponsor will decide whether to target the prior or the updated version.

The Wings project must be completed by the end of the second semester (May 2014). No extensions
can be made and no ongoing maintenance responsibilities are assumed by the team.

The Computer Science department of CSUS reserves the right to use senior project products as
examples of student work.

Delivery of the project documentation, software, and supporting materials to the sponsor is a condition
of the completion of the project. Upon delivery, the senior project is assumed to be jointly owned by the
development team and the project sponsor in the absence of a specific agreement regarding ownership.

The sponsor will be responsible for deciding how to distribute or integrate Wings. No distribution system
is required to be developed during the project.

SRS 16
2.7 Assumptions and Dependencies
Sponsor: Leadwerks is shifting focus to higher end gaming computers and away from mobile. Wings will
not be developed for mobile Operating Systems. Development and performance concerns will focus on
desktop and laptop systems.

Sponsor: Leadwerks’ entities get an agent by having data loosely coupled to them by accessing script
data from C++. Wings will then update these entities by knowing only the data they hold. This is assumed
as it is not well documented and we are not to inherit directly from the Entity class.

Section 2.1: With regard to the design of the use cases, the team is working under the assumption that
Leadwerks is the only game engine with which Wings will be used. Games which incorporate Wings will
be created with the Leadwerks game engine. This assumption will help the team develop more concise
use cases.

Section 2.1: Wings distribution is assumed to be done in the Leadwerks’ Asset Store, Werkspace. A site
for Wings is also a possibility for distribution but the Leadwerks’ Asset Store is a more unified way to
reach Game Developers. This will allow for Game Developers to easily integrate it with their Game(s).

Section 2.2.1: Wings will be used to develop agents for video game AI for recreational games with an
emphasis on first-person shooters. Games are robust tools but we should only assume our techniques
are used for video games in the traditional entertainment sense.

Section 2.2: The project specifies two actors, Game Developer and Game. The Leadwerks Engine is
modified to become the Game itself. Interaction with the Game from outside sources (i.e. players) is
handled by the Game Developer. This assumption will allow us to focus on the Game Developer and their
product, the Game.

Section 2.7: Wings loosely coupled interface with entities will allow editing of agent components within
the Leadwerks Editor. This assumption will allow modification of agents to be done with scripting as
oppose to lower-level C++ implementation. Allowing Game Devs with less programming experience to
use Wings in their Game.

3 Specific Requirements
This section includes specific functional and nonfunctional requirements for the Wings library. Functional
requirements are documented in Section 3.1. Nonfunctional requirements and related information are
specified beginning in Section 3.2

3.1 Use Case Specification

The use case specification describes the functional requirements of the Wings library in terms of the
major features provided to actors. Each use case consists of a goal, a description of conditions, a set of
flows, and supporting information. The goal describes a need of the actor that Wings will satisfy. The
conditions describe the state of the system and context before and after the application of the use case.
The flows describe the functional requirements related to achieving the goal functionality.

SRS 17
3.1.1 Manage Wings
Use Case 1 Manage Wings

Actors Game Developer, Game

Goal Description Game Developer wants to connect the Wings library to a game based on the
Leadwerks engine. Game needs to initialize and configure Wings, manage Wings
Agents, and shutdown Wings at runtime.

Use Case Type Primary Task

Preconditions Game Developer has installed a valid copy of Leadwerks, has access to a copy
of Wings, and has created a game project within Leadwerks.

Postconditions Wings has been connected to the Leadwerks game project.

Wings configuration has been saved for future use.
Game has successfully initialized, executed, and terminated Wings.

Primary Flow 1.1 Game Developer connects the Wings library to the Leadwerks IDE.
1.2 Game initializes Wings:
1. Game will create Wings objects.
2. Game will create Wings environment.
1.3 Game configures Agent performance settings.
1.4 Game loads Agents into the environment:
1. Game will create Entities and apply saved state.
2. Wings will intercept Entities and create attached Agents.
3. Wings will load Interactions.
4. Wings will load Shared Resources.
1.5 Game updates the collection of Agents.
1.6A Game saves Agents from the environment:
1. Game will save Entities and current state.
2. Wings will output Agents.
3. Wings will output Interactions.
4. Wings will output Shared Resources.
1.7 Game shuts down Wings:
1. Game will destroy the Wings environment.
2. Game will destroy Wings objects.

Sub Variations If Wings has been previously connected to Leadwerks, the actor initiates the
use case from 1.2:
1.2 Game initializes Wings.
1.3 Game configures Wings (UC 2)
1.4 Game loads Agents into the environment.
1.5 Game updates the collection of Agents.

Exceptions 1.1.E1 Game fails to locate some or all components of Wings library.
1.2.E1 Wings fails to initialize.
1.3.E1 Game fails to apply a valid Agent performance configuration.

SRS 18
 1.4.E1 Game fails to load Agents.
1.5.E1 Game updates an Agent to an impossible state.
1.6.E1 Game fails to save Agents.

Includes

Priority High

Frequency of Use Frequent

Assumptions 6A. Game Developer will have access to the mechanism for saving and loading
Agents.

Created By Ken, Tim, Ethan

Created On 10/18/2013

Updated By Ken

Updated On 2/8/2014

3.1.2 Create Agent

Use Case 2 Create Agent

Actors Game Developer, Game

Goal Description Game Developer wants to assign intelligent behavior to an entity within their
game.

Use Case Type Primary Task

Preconditions Wings has been connected to Leadwerks.

There exists an Entity that an Agent can be attached to.

Postconditions An Agent has been designed and attached to an Entity in the game.

Primary Flow 2.1 Game Developer designs a new Agent. (UC 3)

2.2 Game instantiates the Agent:
1. Game Developer will be able to attach an Agent to a selected Entity
from the Leadwerks Editor.
2. Wings will assign a unique identifier to the Agent:
a. Game Developer will specify the unique identifier.
b. Wings will generate a unique identifier if none is specified.
3. Wings will allocate resources for the Agent during initialization.
4. Wings will create the Agent and add it to the environment.
2.3 Game attaches the Agent to an Entity:
1. Wings will attach saved Agents to the correct Entities on load.
2. Game will be able to dynamically attach an Agent to an Entity after

SRS 19
 creation.

Sub Variations If the Agent to be created has been previously designed, the actor initiates the
use case from 2.2:
2.2 Game instantiates the Agent.
2.3 Game attaches the Agent to an Entity.

Exceptions 2.1.E1 The Agent designed by the Game Developer is invalid.

2.2.E1 The Agent fails to instantiate.
2.2.E2 The Game Developer attempts to assign an already used unique
identifier.
2.3.E1 The Game attempts to assign an Agent to an Entity that already has an
Agent attached.

Includes UC 3

Priority High

Frequency of Use Frequent

Assumptions

Created By Ken, Tim, Ethan

Created On 10/18/2013

Updated By Tim

Updated On 10/19/2013

Updated By Ken

Updated On 2/8/2014

3.1.3 Design Agent

Use Case 3 Design Agent

Actors Game Developer

Goal Description Game Developer wants to design a new type of intelligent Agent for use in a
game.

Use Case Type Primary Task

Preconditions Wings has been connected to Leadwerks.

Postconditions A new type of Agent exists that can be added to the game environment by the
Game Developer or Game.

SRS 20
Primary Flow 3.1 Game Developer will define Agent component:
1. Define reasoning process
2. Define actions
3. Define perceptions
3.2 Game Developer selects the components of the Agent:
1. Select a reasoning process
2. Select a set of actions available to agent
3. Select a perception type and perceptible distance
4. Wings will assign the selected components to the Agent upon
instantiation.
3.3A Game Developer sets the initial state of the Agent:
1. Game Developer will assign values to the properties of the reasoning
process.
2. Wings will apply the assigned initial state to the Agent upon
instantiation.

Exceptions 3.2.E1 The Game Developer does not completely define an agent component in
a format Wings can understand.
3.2.E1 The Agent is assigned an invalid Reasoning process.
3.2.E2 The Reasoning process assigned to the Agent uses Perceptions or
Actions that are not available to the Agent.
3.2.E3 The Agent is not assigned any valid Perceptions.
3.2.E4 The Agent is not assigned any valid Actions.
3.3.E1 An invalid state is assigned to the Agent.

Priority High

Frequency of Use Infrequent

Assumptions 1. The Agent being designed by the Game Developer doesn’t already exist.

Created By Ken, Tim, Ethan

Created On 10/18/2013

Updated By Tim

Updated On 10/19/2013

Updated By Ken

Updated On 2/8/2014

3.1.4 Modify Agent

Use Case 4 Modify Agent

Actors Game

SRS 21
Goal Description Game needs to modify an Agent in some way during runtime.

Use Case Type Primary Task

Preconditions The Agent the Game needs to modify exists in Wings and has been attached to
an Entity in the game environment.

Postconditions The Agent has been modified in the intended way.

Primary Flow 4.1 Wings will allow the Game to retrieve Agents:
1. Wings will maintain a collection of uniquely identified Agents.
2. The Game can request an Agent using the unique identifier.
3. The Game can access an Agent using a saved reference.
4.2A Game will be able to attach the Agent to an Entity.
4.2B Game changes the Components that the Agent uses:
1. Game will be able to assign a reasoning process to the Agent.
2. Game will be able to modify the set of Perceptions available to the
Agent.
3. Game will be able to modify the set of Actions available to the Agent.
4.2C Game deletes the Agent from the game environment.

Exceptions 4.1.E1 A requested Agent does not exist.

4.2A.E1 The Agent is attached to an Entity that does not exist.
4.2A.E2 Multiple Agents are attached to a single Entity.
4.2B.E1 The Agent is assigned an invalid Reasoning process.
4.2B.E2 The Reasoning process assigned to the Agent uses Perceptions or
Actions that are not available to the Agent.
4.2B.E3 The Agent is not assigned any valid Perceptions.
4.2B.E4 The Agent is not assigned any valid Actions.

Priority High

Frequency of Use Frequent

Assumptions

Created By Ken, Tim, Ethan

Created On 10/18/2013

Updated By Ken

Updated On 2/8/2014

3.1.5 Manage Agent Interactions

Use Case 5 Manage Agent Interactions

Actors Game Developer, Game

SRS 22
Goal Description Actor wants to manage an agent interaction, such as an entity property or a
hierarchical relationship.

Use Case Type Primary Task

Preconditions Wings has been connected to Leadwerks.

Postconditions An Interaction in the environment has been added, modified, or removed.

Primary Flow 5.1 Game Developer will be able to define Interactions:

1. Wings will define basic Interaction types.
2. Game Developer will be able to extend basic Interactions.
3. Game Developer will be able to implement custom Interactions.
5.2A Wings will allow the Game to retrieve Interactions:
1. Wings will maintain a collection of uniquely identified Interactions.
2. Game will be able to request an Interaction using the unique identifier.
3. Game will be able to access an Interaction using a saved reference.
5.2B Game Developer will add Interactions to the environment:
1. Game Developer will be able to add Interactions from the Leadwerks
Editor.
2. Wings will instantiate Interactions during initialization.
3. Game will be able to dynamically instantiate Interactions during
execution.
5.2C Remove Interactions from environment:
1. Game Developer will be able to remove Interactions from the
Leadwerks Editor.
2. Wings will release Interactions during shutdown.
3. Game will be able to dynamically release Interactions during execution.

Sub Variations If the Interaction to be managed has been previously defined, the actor initiates
the use case from 5.2:
5.2A Wings will allow the Game to retrieve Interactions.
5.2B Game Developer will add Interactions to the environment.
5.2C Remove Interactions from environment.

Exceptions 5.1.E1 The defined Interaction is invalid.

5.2A.E1 Two or more Interactions have colliding identifiers.
5.2A.E2 A requested Interaction does not exist.
5.2A.E3 A reference is accessed to an Interaction that does not exist.
5.2B.E1 An Interaction fails to instantiate.
5.2C.E1 An Interaction is removed from the environment without being
released.

Priority Medium

Frequency of Use Infrequent

Assumptions 1. The AI techniques to be developed in subsequent iterations will make use of

SRS 23
 the Interactions in ways that improve reasoning, cooperation, and competition.

Created By Ken, Tim, Ethan

Created On 10/18/2013

Updated By Ken

Updated On 2/8/2014

3.1.8 Additional Functional Requirements

1. Agent-to-Agent Interaction

Wings will enable interaction between two or more agents in a variety of ways. Agents must
consider other agents in their decision making process.

Coordination: Agents will be capable of working together to achieve a certain goal. An agent
may have the same goal as another agent, or differing goals, but the agent will try not to
interfere with another it is coordinated with and assist in the completion of shared goals. This
manifests itself in two scenarios: Flocking and Teams. Flocking agents will act as a group with
regards to movement, and attempt to optimize their collective pathfinding. Teams are a broader
concept, that enable multiple agents to band together strategically and make decisions based
on optimizing expected value as a group rather than individually.

Hierarchical Systems: Agents will be capable of utilizing a chain of command to make decisions.
Game developers will be able to specify an agent as a group leader, or if configured to do so,
agents will select a leader among themselves at run-time. Agents will defer some or all
decision-making authority to the designated group leader.

Competition: Agents will be also be capable of an antagonistic relationship with other agents.
Unlike coordination, in this case agents will work to hinder the actions and thwart the goals of
other agents rather than aid and assist. They may share a goal, or have differing goals that are
mutually exclusive. Three specific situations have been identified that could be manifestations of
agent competition. Confronting agents will attempt to attack, interfere with, or move toward
another agent to directly oppose it. Avoiding agents will attempt to move away from or hide
from another agent. Resource Denying agents will attempt to steal, destroy, sabotage, or hide
in-game objects that opposing agents value. A resource denying agent may also deny physical
access to a location to another agent if possible.

2. Agent-to-Object Interaction

Wings will enable interaction between one or more agents and non-agent game objects. Agents
must consider specially designated objects within the game world that may have special
significance, as determined during development by the game developer.

SRS 24
 Points-of-Interest: A game developer will be able to choose a game object that, upon agent
interaction, will affect one or more properties of an agent. A point-of-interest could affect the
perceptions, available actions, goals, or even reasoning technique of an agent.

Waypoints: A specific object within a game may be selected as a waypoint. An agent will then
be assigned to periodically travel to each of the waypoints it is aware of. A waypoint may be
selected and assigned by a game developer, or by an agent itself in order to achieve its goal.

3. Agent-to-Player Interaction

Wings will enable interaction between one or more agents and a player playing the game.
Agents must consider the player within the game world: how the player and the player’s actions
modify the agent’s goals, perceptions, and available actions. Players may be considered an ally
or an enemy. A game developer may elect to have an agent always act as an ally to a player,
always act as an antagonist to the player, or to allow for both depending on player actions and
agent goals.

Conversation System: Agents will be able to be configured to initiate a dialogue with the
player. The specifics of the dialogue will be left to game developers to implement, Wings is only
concerned with the ability to begin and end a “conversation.”

Coordination: Agents will be capable of attempting to working with a player to achieve a

certain goal. An agent may have the same goal as a player, or differing goals, but the agent will
try not to interfere with with the player it is coordinating with and assist in the completion of
shared goals. This manifests itself in two scenarios: Following and Teams. Following agents will
attempt to follow and stay close to the player as much as possible. Teams are a broader
concept, that enable an agent to band together strategically with a player and make decisions
based on optimizing expected value as a group rather than individually. This will likely manifest
itself as an agent choosing a course of action that helps the player rather than themselves.

Competition: Agents will be also be capable of an antagonistic relationship with players. Unlike
coordination, in this case agents will work to hinder the actions and thwart the perceived goals
of the player. They may share a goal with the player, or have differing goals that are mutually
exclusive. Three specific situations have been identified that could be manifestations of agent
competition. Confronting agents will attempt to attack, interfere with, or move toward a player
to directly oppose it. Avoiding agents will attempt to move away from or hide from the player.
Resource Denying agents will attempt to steal, destroy, sabotage, or hide in-game objects that
players may value. A resource denying agent may also deny physical access to a location to a
player if possible.

4. Agent Design

Wings will allow game developers to design and customize agents for use within their game.
Theoretically, each agent could be considered to consist of four elements: Behaviors, Goals,
Perceptions, and Reasoning Process. These elements may be implemented in various ways

SRS 25
 and may vary based on the type of reasoning process used. They are addressed in figure 2-5 in
section 2.3 of this document.

Behaviors: Game developers will assign an agent a set of available actions. Agents will also be
capable of changing their available actions as they become available. A behavior is the tangible
result of the other elements that make up the agent. Specific behaviors that will be addressed
by Wings are Patrolling and Conversation. Patrolling agents navigate between a list of
game-world objects as described in the Agent-to-Object Interaction section above. Conversing
agents are able to initiate and end an interaction with the player, as described in the
Agent-to-Player Interaction section above.

Goals: Game developers may assign an agent a goal or list of ranked goals. Agents will also be
capable of changing their goals as they become available. A goal is a more abstract concept, the
“motivation”for an agent to make its decisions based upon.

Perceptions: Game developers may configure an agent to have varying degrees and means of
perception. This will determine the information an agent is capable of considering in its decision
making process. An agent may have perfect information about the game-world, or any level of
imperfect information based on line-of-sight, physical proximity, or perception as a group (group
of agents with shared perceptions.

Reasoning Process: Game developers will assign an agent a reasoning technique from a list of
Wings provided algorithms. This is the method by which an agent will process its goals and
perceptions into actionable behavior.

5. Agent Addition and Removal

Wings will allow game developers to add and remove agents from the game world they create.
This could be a fixed modification during design, or a scripted modification/removal at run-time.

6. Agent Loading and Saving

Wings will allow game developers to load and save agents to and from the game world they
create. This includes the ability to load multiple copies of the same agent to different entities,
each of which will process and diverge as a separate agents at run-time.

7. Wings Agent API

Wings will provide a set of interfaces and abstract classes that are not Leadwerks specific. The
Agent API is used by the Leadwerks Adapter to access the internal methods of Wings. The Agent
API will receive input in a specific format and return output in a specific format.

8. Leadwerks Adapter

Wings will provide an adapter that interfaces the Leadwerks engine with the Wings Agent API.
The adapter will be necessary because Wings will be loosely coupled with the Leadwerks

SRS 26
 engine. The reason that Wings will be loosely coupled with Leadwerks is twofold: Firstly,
Daedalus does not have access to the Leadwerks source code, making tight coupling nearly
impossible. Secondly, it is our goal to make Wings flexible and generic enough that it could
potentially be adapted to other game engines in the future. Such adaptations are outside of the
scope of this project.

Library Connection: Wings will provide a class that inherits from the Leadwerks Object class, to
bridge the Leadwerks assets and the Wings methods and classes.

Memory Management: Wings will work within the memory management scheme established
by Leadwerks.

Script Tab Interface: Wings will be designed with the “Script Tab” interface in mind. The Script
Tab interface is an element of the Leadwerks editor that will be the means of Wings
configuration for a game developer. Wings may eventually be integrated more deeply into the
Leadwerks editor’s user interface, but this is beyond the scope of the project.

3.1.9 Object Model

The Object Model Diagram shown below in Figure 3-1 represents a high level view of the various objects
that exist in the Wings library as well as their relationships to one another.

The central object in Wings is the Agent. An Agent is composed of multiple component objects. For
additional information on Agents, refer to Section 2.3.

An Agent is required to have one ReasoningTechnique object attached to it. Wings will contain multiple
pre-built techniques, such as FSM, Planner, and BehaviorTree, that Game Developers can choose from
when designing their agents.

An Agent must also have one or more Perceptions. Perceptions are how the Agent views what is
happening in the Game environment. Example Perceptions include LineOfSight and Proximity to other
game object. Game Developers will extend pre-built Perceptions or add new Perceptions of their own
and expand on them for their game.

Finally, an Agent has access to a set of Action objects. These actions represent how the Agent reacts to
its perceptions and are chosen based on the output of the Agent’s ReasoningTechnique. These actions
implicitly or explicitly affect the Game Environment. Some Action object might have Condition objects
associated with them. The YES/NO conditions specified by these object must be evaluated before an
action is executed, and the execution of an Action might be dependent on a specific outcome of the
Condition.

SRS 27
 Figure 3-1 Object Model Diagram

3.2 Performance Requirements

Wings is designed to be incorporated into video games. The primary performance requirement,
therefore, is that Wings should not unacceptably reduce the performance of any game into which it is
incorporated. A good metric for this performance would be to measure the frame-rate of the game.
Most games seek to maintain a frames per second (FPS) of 30 or greater. 30 FPS is the minimum because
below this is when the human eye can start seeing imperfection in the games animation or the motion of
objects as they move. Therefore, if the game draws fewer than 30 FPS its performance has become too
slow.

This is an imperfect metric, however, when we consider the wide variety of games that can use Wings,
and the wide variety of platforms on which the games may run. Leadwerks currently is capable of making
games for a variety of systems, ranging from smartphones to high-end PCs. These games may be very
SRS 28
simple or very complex. They may have a small or large number of agents, resulting in a minor or major
need for the methods found in Wings. Therefore, a uniform metric will be insufficient for measuring the
performance of Wings.

In order to accommodate the variety of ways Wings can be used, Wings will be built with configurable
performance settings. Game developers with only basic AI needs can choose a lower setting, as can
developers for mobile games or games with a large number of agents. Developers making games for
high-end systems can choose a higher setting. In addition, game developers may decide to allow the end
user to choose the setting. This also supports the overall Tinkerability requirement for Wings (3.4.1).

These performance settings will determine the level of detail for the various AI techniques used by
Wings. They will also include a time limit for the decision-making process, either for an individual agent,
the system as a whole, or both. Wings will be designed so that the behavior of agents is defined for any
given time limit or level of detail. Wings will allow for any agent without a reasoning process to be
attached to an Entity without an impact on performance.

In future iterations as more of the capabilities and limitations of Leadwerks are discovered, Daedalus will
develop specific performance metrics regarding:

● Processing speed: per second, per frame

● Memory usage: Wings library, per Agent, for Shared Resources
● Memory allocation: Wings library, individual objects, grouped allocation
● Number of engine calls: raycasts, collision checks
● Threading and process management: due to the difficulty and risk involved in developing a
threaded execution model, Wings will prioritize thread safety over a multi-threaded
implementation
● Maximum number of Agents, Interactions, and Shared Resources
● Size and data types permitted in the Leadwerks editor
● Concurrent execution and synchronization

3.3 Design Constraints

The team will not have access to the source code for the Leadwerks Engine.

The target version of Leadwerks for Wings compatibility is 3.1, scheduled for late 2013 release. This
may be revised during future iterations of the project.

The library will utilize the C++ Standard Library and the Leadwerks API to ensure portability of the code
between operating systems. If any third party libraries are used, they will be open-source and portable.

The Wings library will be thread-safe with an emphasis on minimizing shared data structures.

In order to avoid tight coupling and design restrictions, Wings will not inherit directly from the Leadwerks
Entity class. This class is the primary interface between the Leadwerks API and Editor. Instead, Wings will
create and modify Agents and properties using the undocumented functions GetUserData() and

SRS 29
SetUserData().

The Wings library will be capable of invoking and updating Leadwerks Lua scripts.

Design priority will be given to AI techniques and properties that most improve the First-Person Shooter
genre of video games.

Leadwerks already includes robust pathfinding that should be utilized by Wings rather than reinvented.

3.4 Quality Attributes

Quality attributes describe the static traits of the software, runtime traits, and traits of the user
documentation. They include nonfunctional requirements and general guidance that applies broadly to all
aspects of the Wings project. Quality attributes have implications that can be evaluated for specific
features of the system as well as general properties that have to be evaluated with respect to the
project as a whole.

3.4.1 Tinkerability
Tinkerability is a domain-specific composite of usability and customizability. This is the most important
NFR for the Wings project. The Wings library will prioritize ease of connecting the software, learning the
functionality, and using it effectively and creatively.

The public interface to Wings will be intuitive to use. Public members and methods will be descriptively
named. Function arguments will be named and ordered to promote memorability. Return parameters will
be implied by function names and clearly documented. Properties assigned in the Leadwerks Editor will
be organized to emphasize simplicity.

Wings will help the user maintain productivity. The Wings library will be accessible to Leadwerks Lua
scripts, and through the Leadwerks Editor for rapid iteration. The Agent API within Leadwerks will
provide a layer of abstraction to the most complex Wings features.

Wings will provide complete and easy to use documentation and tutorials. End user documentation will
be provided for the Wings library in the format established by Leadwerks’ public documentation. Each
command, its syntax, parameters, and return values will be described in said documentation. Additional
learning materials, including documented examples or extended tutorials will be provided for complex
features.

The Wings library will be heavily customizable. Game Developers will be able to design new Agent types
using Wings functionality in scripts or the graphical editor. Advanced Wings functionality will be exposed
at the API level. Game Developers will have the ability to derive and extend artificial intelligence
techniques. Finally, Wings will provide an interface for the global properties and settings of the library,
allowing Game Developers to modify the way the engine operates.

3.4.2 Reliability
As an optional component which is intended to simplify game development and empower game
developers, it is essential that Wings have minimal impact on the reliability of the games into which it is
SRS 30
incorporated. Therefore, Wings will adopt a flexible approach to reliability.

First, Wings will be thoroughly tested in keeping with the project management plan. Software defects
will be reported, analyzed, and resolved as they arise throughout the course of the project. Overall
reliability will be supported through the iterative development process in that iteration goals can be
adjusted to allow more time for defect resolution.

Second, Wings will provide a global setting for Game Developers to select the error handling behavior
that aligns with their goals. Wings will implement a default strategy of providing as much information as
possible about exceptions to the Game Developer and avoiding catastrophic termination of the game.
Additional strategies, such as default fallbacks or conditional retries, will be possible.

3.4.3 Maintainability
Leadwerks Software will receive access to the Wings source code, internal documentation, and
supporting project infrastructure to allow for ongoing maintenance.

Wings will be sufficiently documented to allow developers unassociated with the initial development
effort to understand the system design and functional relationships. Source code will be documented
using a consistent style established by the team. This documentation includes describing each class,
function, parameter, return value, and variable used in Wings as well as providing examples of usage
where necessary.

Wings will be flexible in its design, so as to enable functional enhancements to the software.

3.4.4 Portability
Wings will be deployed to Game Developers on Windows, Mac OS X, and Linux. The library and tools will
be tested on each of these platforms.

Wings will be structured to support portability and minimize platform dependencies.

Wings will use only standard cross-platform libraries.

Wings will be incorporated into games delivered on Windows, Mac OS X, and Linux, with additional
operating systems possible in the future. The delivered system will be tested on each of these
platforms.

Leadwerks 3.1, to be released in December 2013, will discontinue support for Windows XP. Therefore,
the Leadwerks adapter will not be required to run on that operating system.

3.4.5 Program Quality Attributes

Program Quality Attributes describe runtime characteristics of the software.

Robustness
Wings will constrain input options where possible to prevent validation failures. Property types will be
selected to minimize the opportunity for errors. Value lists and validation ranges will be applied to

SRS 31
properties as appropriate.

Upon a validation failure, Wings will apply the current error handling strategy to respond. The default
error handling behavior in the event of an invalid value will describe the failure to the Game Developer
and attempt to avoid termination of the game.

Performance
By its nature, AI processing tends to take a great deal of CPU time; however, it is required that the
various AI techniques implemented by Wings will be efficient enough such that they will not hinder the
execution speed of a video game to the point at which it restricts the Game Developer.

Running on mobile platforms is not a concern for this project, so Wings will not be concerned about
performance on those systems.

3.4.6 Security
Wings will not incorporate any extraordinary security measures beyond avoidance of obviously unsafe
methods. Securing Wings will be the responsibility of the Game Developer if desirable.

3.4.7 Testability
Each Use Case primary flow, as well as any alternate flows the UC might have, must be testable such that
a test plan can be created for each flow of the UC .

Wings agents and their behaviors must be testabled within the confines of a video game created using
the Leadwerks IDE.

3.5 Deployment Configurations

Wings will be deployed to Game Developer workstations alongside the Leadwerks game engine. Wings
will provide a set of tools and interfaces which will be accessed through the Leadwerks IDE and in code.
The library will compile and run in debug and release modes.

Wings will also be embedded in games which are deployed to the personal computers of players. In this
configuration, Wings will provide a compiled software library and will run in release mode only.

SRS 32
4 Approvals
This section includes the history of revisions to the SRS and the formal approvals from each member of
the team, the advisor, and the sponsor.

4.1 Version History

Version Date Sections

0.1 10/21/201 1, 2, 3, 4, A
3

0.2 2/13/2014 1.4, 2.3, 2.4, 2.5, 3.1, 3.3, 4.1, A

Table 4-1 Version and Revision History

4.2 Signatures
Upon signed approval by all members of the development team, the advisor, and the sponsor, the
software requirements contained in this document will be officially adopted for the Wings project.

1. Team Members

a. Tim Shea ____________________________________________

b. Ethan Weidman____________________________________________

c. Chris Lawson ____________________________________________

d. Ken Barnett ____________________________________________

e. Tate Chamberlain ____________________________________________

2. Advisor

a. Ahmed Salem ____________________________________________

3. Sponsor

a. Josh Klint ____________________________________________

SRS 33
5 Appendices
Appendix A: Data Dictionary
The following section contains tables which list the data that will be used by the Wings system. The data
is split into two distinct groups: Elements and Data Structures.

A-1 Elements
Name agents

Description A collection of Agent objects that currently exist in the Game environment.

Definition agents = {Agent}n

Value Type List

How it is Set The Game Developer sets the initial collection of agents or the Game loads a
saved set of agents from a previous execution of the Game.

How it is Used The Game Developer or Game will retrieve individual Agents from this
collection. The Game will update Agents in this collection as a group or
according to a processing structure.

Data Structures
Used In

Supplementary none

Name reasoningTechnique

Description The ReasoningTechnique an Agent is set to use to make its decisions.

Definition reasoningTechnique = ReasoningTechnique

Value Type ReasoningTechnique

How it is Set Game Developer chooses and sets the technique an Agent will use to make
decisions when designing the Agent.

How it is Used Used by Game to update the decision making of the Agent.

Data Structures Agent

Used In

Supplementary none

SRS 34
Name perceptions

Description A collection of Perception objects.

Definition perceptions = {Perception}n

Value Type List

How it is Set Game Developer adds which perceptions an Agent will use when designing
the Agent.

How it is Used Used by the Agent’s reasoningTechnique to make a decision.

Data Structures Agent

Used In

Supplementary none

Name actions

Description A collection of Action objects.

Definition actions = {Action}n

Value Type List

How it is Set Game Developer adds which actions an Agent will use to affect the Game
environment.

How it is Used Used by an Agent to get a specific Action based off of decisions made by the
Agent’s ReasoningTechnique.

Data Structures Agent

Used In

Supplementary none

A-2 Data Structures

Name Agent

Description An object which perceives and acts in an environment according to a

reasoning process.

SRS 35
How it is Set An Agent is designed and initially created by the Game Developer. An Agent
can also be created dynamically by the Game.

How it is Used An Agent is modified and updated by the Game.

Data agents collection.

Structures/Stores
Included In

Composition Reasoning Technique, perceptions, actions

Supplementary none

Name ReasoningTechnique

Description Represents a decision making technique an Agent may use to update its state
and initiate one or more of its actions.

How it is Set Game Developer can design their own technique or use a pre-built technique
that ships with Wings.

How it is Used

Data reasoningTechnique
Structures/Stores
Included In

Composition

Supplementary FSM, Planner, BehaviorTree

Name FSM

Description Represents a Finite State Machine as a pre-built ReasoningTechnique for an

Agent.

How it is Set Game Developer constructs the FSM with custom states, actions, conditions,
and transitions.

How it is Used

Data reasoningTechnique
Structures/Stores
Included In

SRS 36
Composition

Supplementary none

Name Planner

Description Represents a Planning decision making technique as a pre-built

ReasoningTechnique for an Agent.

How it is Set Game Developer constructs the Planner with a set of custom pre-defined
goals .

How it is Used

Data reasoningTechnique
Structures/Stores
Included In

Composition

Supplementary none

Name BehaviorTree

Description Represents a Behavior Tree decision making technique as a pre-built

ReasoningTechnique for an Agent.

How it is Set Game Developer constructs a BehaviorTree using a set of pre-built nodes,
and custom actions and conditions.

How it is Used

Data reasoningTechnique
Structures/Stores
Included In

Composition

Supplementary none

Name Perception

Description Represents a way in which an Agent can perceive Entities in the Game
environment.

SRS 37
How it is Set Game Developer can design their own Perception or use one of the pre-built
Perceptions that ship with Wings.

How it is Used

Data perceptions
Structures/Stores
Included In

Composition Leadwerks Entities

Supplementary none

Name Action

Description Represents something that an Agent can do in the Game environment.

How it is Set Game Developer designs the Action.

How it is Used

Data actions
Structures/Stores
Included In

Composition

Supplementary none

Name Condition

Description Represents a boolean TRUE/FALSE condition object.

How it is Set Game Developer designs the Condition and assigns it to an Action.

How it is Used Is used by ReasoningTechnique to determine if the Action should be

performed.

Data Action
Structures/Stores
Included In

Composition

Supplementary none

SRS 38
SRS 39