---

Software Requirements Specification (SRS)

Maze of Shadows

Group Number: 6

Group Members:
Logan Falkenberg (llf46@txstate.edu)
Farrah Omar (xwo6@txstate.edu)
Bradley Hayes (blh197@txstate.edu)
Collin Reisman (jps191@txstate.edu)

---

Table of Contents

1. Introduction
   1.1 Purpose of the SRS
   1.2 Problem Statement
   1.3 Intended Audience and Document Conventions
   1.4 Product Scope
   1.5 References
2. Functional Requirements
   2.1 Procedural Maze Generation
   2.2 Lighting and Visibility Mechanics
   2.3 Enemy Behavior and AI Pathfinding
   2.4 Power-ups and Item Collection
   2.5 Game Interface and User Interaction
   2.6 UML Diagrams
3. Non-Functional Requirements
   3.1 Performance
   3.2 Security
   3.3 Usability
   3.4 Maintainability
4. Design and Implementation Constraints
   4.1 Standards Compliance
   4.2 Development Constraints
5. References and Sources of Information

---

1. Introduction

1.1 Purpose of the SRS

The purpose of this Software Requirements Specification (SRS) document is to outline the functional and non-functional requirements for Maze of Shadows, a 2D top-down rogue-like maze game developed in Unity. This document will serve as a reference for the development team, providing clear guidance on the game’s expected functionality, design constraints, and usability expectations.

1.2 Problem Statement

Many maze-based games offer straightforward gameplay but lack suspense and immersive mechanics. Maze of Shadows enhances traditional maze-solving with dynamic lighting, intelligent enemy AI, and moveable tiles, creating a tense and engaging experience. The combination of procedural maze generation and survival elements ensures a unique playthrough every time, offering replayability and challenge.

1.3 Intended Audience and Document Conventions

This document is intended for:

• The development team responsible for implementing the game in Unity using C#
• Course instructors and evaluators reviewing the project for grading
• Game testers who will provide feedback during iterative development

The document follows IEEE 830-1998 standards, ensuring clear organization and specification of software requirements.

1.4 Product Scope

Maze of Shadows is a single-player rogue-like maze game featuring:

• Procedural maze generation ensuring unique layouts in every playthrough.
• Dynamic lighting mechanics, restricting player vision to a small radius.
• Enemy AI with pathfinding that hunts and reacts to the player.
• Item collection system, requiring players to gather essential items to escape.
• Moveable tiles, there will be premade tiles that players are able to move in any direction emulating a puzzle slide game to solve the maze.
• An intuitive UI for player controls and in-game feedback.
• Desktop (Windows & Mac) compatibility, developed in Unity.

1.5 References

• IEEE 830-1998 Software Requirements Specification Standards
• Unity Documentation (https://docs.unity3d.com/)
• C# Scripting for Unity (https://learn.microsoft.com/en-us/dotnet/csharp/)

---

2. Functional Requirements

2.1 Procedural Maze Generation

• The game generates a maze for a players to be able to shift around the rooms.
• The maze consists of doors to be able to traverse to the next room.
• The maze layout supports pathfinding algorithms for both enemies and power-ups.

2.2 Lighting and Visibility Mechanics

• The player’s visibility is limited to the room that the charcter is currently in.
• Static lighting in each room.
• room becomes visible once door has been opened (use of door is subject to change)
• Certain rooms may adjust light radius.

2.3 Enemy Behavior and AI Pathfinding

• Enemies spawn in various locations within the maze.
• Enemies either patrol or actively chase the player upon detection.
• AI uses a pathfinding algorithm (such as A*) to navigate the maze.
• Some enemies may have different behaviors (e.g., fast but short-ranged, slow but persistent).

2.4 Item Collection

• Players must collect specific items before reaching the exit.
• Items will be randomly placed but always accessible via a valid path.
• Available items that a player can collect include:
  • Coins: A type of currency that could be used in a shop.
  • Weapon: A little weapon to fight back enemies.
  • Health: Restores player health if damaged.

2.5 Game Interface and User Interaction

• Players control movement using WASD or arrow keys.
• A HUD (heads-up display) shows collected items, health, and power-ups.
• A mini-map (if implemented) provides limited directional guidance.

2.6 Moveable Tiles

• Have a top level view of a maze to build that the player will use to play in.
• Each moveable tile will be displayed a 3x3 where the minimized abstract tile view of the creator can be mapped to a much larger room that will be built when the player loads in.
• There will be premade tiles that the player has a blank slot to slide tiles above, below, left, or right of it to form the maze they will play in, emulating a puzzle slider game.

2.7 UML Diagrams

To better illustrate the system’s functional architecture, the following UML diagrams are provided:

• Use-Case Diagram – Displays how users (players) interact with the game system.
• Class Diagram – Represents the structure of major classes and their relationships.
• Sequence Diagram – Outlines interactions between the player, enemies, and game systems.

UML Diagram File:

---

3. Non-Functional Requirements

3.1 Performance

• The game should run smoothly at 60 FPS on modern mid-range PCs.
• Maze generation time should be under 3 seconds.

3.2 Security

• No online components, so security concerns are minimal.
• Save files (if applicable) should be protected against corruption.

3.3 Usability

• Controls should be simple and intuitive.
• Difficulty should scale appropriately to avoid frustration.
• The UI must be clear and readable.

3.4 Maintainability

• The game will use modular code, making it easy to update.
• Power-ups and enemies should be easily expandable in future iterations.
• A version control system (GitHub) will be used for collaboration.

---

4. Design and Implementation Constraints

4.1 Standards Compliance

• The game follows IEEE 830-1998 SRS standards.
• Unity development adheres to best practices outlined in Unity’s documentation.

4.2 Development Constraints

• The game must be completed within the semester.
• Team members have varying experience levels with Unity and C#.
• The scope must be feasible given available time and resources.

---

5. References and Sources of Information

1. IEEE 830-1998 SRS Documentation
2. Unity Documentation: https://docs.unity3d.com/
3. C# Scripting in Unity: https://learn.microsoft.com/en-us/dotnet/csharp/
4. A* Pathfinding Algorithm Reference: https://www.redblobgames.com/pathfinding/a-star/

---