Software Requirements Specification Document (SRS)
The aim of this document is to comprehensively outline the functional and non-functional requirements of the game Rule and Munus. This document is intended to serve as a guiding framework for the development team, ensuring a clear understanding of the game's objectives, mechanics, and technical specifications. Its primary purpose is to guide the development process by providing a detailed roadmap, ensuring all functionalities align with the intended design and user expectations.
Modern games often struggle to offer a seamless blend of diverse gameplay elements such as combat, resource management, strategy, and AI integration, leading to limited replayability and predictable experiences. Rule and Munus addresses this gap by combining dynamic turn-based combat, and a human-like AI opponent that evolves alongside the player. The game's unique dice-based mechanics and the integration of inspired features from acclaimed titles create an engaging, unpredictable gaming experience. The primary problem it seeks to solve is the lack of truly adaptive AI that mirrors player actions and evolves in complexity, providing a competitive yet balanced challenge.
Rule and Munus is a single-player, turn-based strategy game blending tactical RPG and roguelike elements. Set in a richly detailed isometric world, the game features two primary phases:
- Peace Phase: Players manage a town by constructing and upgrading buildings, crafting/selling/buying items, and developing their character through stat allocation.
- War Phase: Players roll dice to gather materials, engage in combat, or participate in gladiator tournaments. Combat is strategic, turn-based, and influenced by dice rolls.
The game’s highlight is its dynamic AI opponent that grows alongside the player, the King of the Gladiators, which shares player actions, grows over time, and serves as the ultimate opponent. The project boundaries include:
- Platform: PC
- Language: C#
- Graphics: 2D isometric view
- Target audience: Fans of tactical RPGs and turn-based strategy games
By combining resource management, dice mechanics, and adaptive AI, the project aims to deliver a unique, replayable experience that challenges players’ tactical and strategic skills.
| Term | Description |
|---|---|
| AI (Artificial Intelligence) | A computational system designed to mimic human-like decision-making. In this game, the King of the Gladiators is controlled by a human-like AI that adapts to player actions. |
| Action Points (AP) | A resource consumed by the player or AI during combat to perform actions such as attacking, defending, or using skills. |
| Colosseum | A game mode where players participate in gladiator tournaments, facing opponents in staged battles to progress in the story and earn rewards. |
| Combat Interface | A tactical grid system where players engage in turn-based combat with opponents. |
| Dice Mechanics | A feature where dice rolls determine the success of actions, quality of crafted items, and outcomes of events. Examples include d20 for material gathering and d100 for item crafting quality. |
| Encounter | A random event during the War Phase, where the player faces an enemy or gathers materials based on dice roll outcomes. |
| Heuristic-based Decision-making | A method used by the game’s AI to make decisions based on simplified rules rather than complex calculations, balancing performance and adaptability. |
| Isometric View | A visual perspective used in the game to present the town and combat scenes, offering a pseudo-3D appearance on a 2D plane. |
| Peace Phase | The gameplay phase focused on town management, crafting, and character development. |
| Roguelike | A sub-genre of games characterized by procedurally generated challenges, randomness, and a high degree of replayability. |
| Stat Points | Points allocated by players to improve their character’s attributes, such as Strength, Dexterity, or Intelligence, enhancing performance in combat and other activities. |
| Turn-based Combat | A combat system where players and opponents take turns performing actions based on available resources like action points. |
| War Phase | The gameplay phase where players gather materials, engage in combat, or participate in the Colosseum. |
| Unity Engine | A game development platform used for creating the game, handling graphics rendering, physics, and AI behaviors. |
| User Interface (UI) | The visual and interactive components of the game that allow players to perform actions, manage inventory, and navigate game menus. |
| XP (Experience Points) | Points gained by the player through actions like combat and crafting, used to level up the character. |
This document is structured to provide a clear understanding of the game, user profiles, system requirements, functional features, user interface designs, and UML models. Starts with an explanation and continues with the overwiew, system requirements, UI designs and use case descriptions.
Rule and Munus operates as a standalone game, drawing inspiration from popular titles while integrating unique gameplay mechanics and a sophisticated AI. The game’s context is influenced by the following elements:
- Standalone Operation: The game is independent and does not rely on external systems or services to function. Players interact with the game through an intuitive interface on a PC, with no dependencies on third-party platforms for gameplay.
-
Relation to Existing Systems:
- Inspired by Swords and Sandals, it adopts similar combat mechanics while introducing new strategic layers in town-building and AI-driven opponent interactions.
- Borrowing from Dungeons and Dragons, it uses dice-based mechanics for randomness and decision-making, adding depth to gameplay.
- The turn-based structure of Sid Meier's Civilization VI is adapted to combine strategic peace and war phases.
- The town development and crafting mechanics are influenced by Loop Hero, tailored to create a personalized player progression.
- Innovative Features: The game introduces a human-like AI opponent, the King of the Gladiators, which evolves dynamically based on player actions. This AI mirrors player strategies, grows in strength, and serves as a persistent challenge throughout the game, providing a unique and adaptive gameplay experience.
- Gameplay Integration: The game seamlessly combines resource management, character progression, and turn-based combat, creating a balanced and engaging experience. Players navigate between Peace and War Phases, making strategic decisions that directly influence their progression and success. This perspective establishes Rule and Munus as a unique entry in the turn-based strategy and tactical RPG genres, innovating upon existing systems while addressing gaps in adaptive AI and replayability.
Users can play the game with a standard PC device that runs a compatible operating system. Necessary hardware requirements are.
- Game Console: User can interact with the system by corresponding buttons of Game Console to take actions.
- Keyboard: User can interact with the system by corresponding keys such as selecting an action from the action bar in combat by numbers.
- Mouse: User can interact with the system by clicking an action from the action bar or a building to see corresponding actions.
Asset Management:
- Asset management refers to how the game's assets, such as textures, sounds, and models, are handled. This is achieved through operating system calls, which allow the game to interact with the file system to load or save assets dynamically during gameplay.
Unity Requirement:
-
Unity is essential for developing and implementing the functional requirements of the game. It provides the tools and framework necessary for building gameplay features, UI elements, and overall mechanics.
-
Windows and macOS Compatibility:
- The game, Rule and Munus, is designed to run on Windows and macOS computers. This ensures that it is accessible to a wide range of players using these platforms.
-
Physics Computations:
- The Unity3D game engine is utilized for handling all physics-related computations in the game, such as gravity, collisions, and force applications. This simplifies the implementation of realistic interactions within the game world.
-
Object Collisions and Interactions:
- Unity3D is responsible for managing object collisions and interactions. For instance, when characters or objects collide, Unity's physics system calculates the outcome, ensuring seamless interactions.
-
Animations:
- Unity3D handles the animations of characters and objects, allowing for smooth transitions, movements, and visual effects. This includes character walking, jumping, or object-specific animations like rotating or glowing.
Key interface components include:
- Main Menu: Provides access to play, settings, and credits buttons.
- Town Interface: A detailed isometric view of the town, allowing players to interact with buildings to construct, upgrade and interact with the corresponding NPC.
- Character Menu: Displays character stats, inventory and equipped items.
- Combat Interface: A tactical grid system for turn-based combat, featuring action points, dice roll results, and combat options like attack, defend, use skill, and flee.
- War Phase Interface: Allow user to choose either gather or go to coliseum. The interface is tailored for mouse-and-keyboard or game console inputs, offering smooth navigation and control.
Key Features and Functions of Rule and Munus:
-
Peace Phase:
- Town-building and upgrading.
- Crafting items using collected materials.
- Buying and selling items from the market.
- Stat point allocation for character progression.
-
War Phase:
- Material gathering via dice rolls and turn-based events.
- Combat mechanics with options to attack, flee, use skill, or defend.
- Participation in gladiator tournaments to earn rewards and progress in the story.
-
Human-like AI:
- Dynamic evolution sharing player actions.
- The AI-controlled main opponent (King of the Gladiators) who adapts strategically and grows in strength over time.
-
Dynamic Gameplay Elements:
- Randomized events and loot via dice rolls.
- Strategic decision-making influences story progression and AI behavior.
-
Primary Audience:
- Gamers interested in turn-based strategy, tactical RPGs, and rouge-like games.
-
Goals:
- To experience strategic decision-making in improving character and combat actions.
- To challenge a dynamic AI opponent.
- To progress through a basic story while improving their character.
-
Skills:
- Basic familiarity with PC gaming controls (keyboard and mouse or game console).
-
Assumptions:
- Players will have access to PCs meeting at least the minimum hardware requirements.
- No external server or online connection will be required for core gameplay.
-
Dependencies:
- Development relies on the Unity Engine and C# programming language for implementation.
- Graphics and UI assets will depend on third-party design tools like Adobe Photoshop or Blender.
- AI components will leverage machine learning frameworks integrated into Unity.
Input:
- Player inputs using mouse and keyboard for selecting actions, managing inventory, and interacting with game menus.
- Dice roll mechanics triggered via player commands, with visual feedback displayed on the screen. Output:
- Visual representation of the town, character, and combat scenarios in an isometric view.
- Turn-based feedback on dice rolls, actions, and AI decisions.
- Notification system displaying resource changes, loot collected, and combat outcomes. Behavior:
- Seamless transition between Peace and War Phases based on player actions.
- AI dynamically adapting to player strategies in combat and town development.
- Consistent feedback for player decisions, ensuring clarity and engagement.
The game progresses through the Peace and War Phases, each offering distinct gameplay experiences. During the Peace Phase, players manage their town, organize their inventory, check materials, and construct new buildings. For example, building the Blacksmith opens up the option to craft items, and players can also spend stat points as they level up to enhance their character’s attributes. The War Phase shifts the focus to action, where players can gather materials, engage in combat, or participate in gladiator tournaments. The transition between these phases ensures a balance between strategic preparation and active gameplay, allowing players to refine their strategies in the Peace Phase before diving into the challenges of the War Phase.
Players can build and upgrade buildings throughout the game. Initially, basic buildings such as the Market are constructed to facilitate trade and basic operations. As buildings are upgraded, more advanced features become available. For example, upgrading the Blacksmith and Wizard buildings allows the player to craft higher-quality items, increasing the chances of obtaining rare or powerful gear. Upgraded buildings also enhance the materials that can be gathered and the types of actions that can be performed, enabling more efficient and powerful progression in the game. Thus, as buildings level up, players gain access to higher-quality items and resources, providing them with stronger advantages in their journey.
Players, through the process of building and upgrading structures in their town, gain the opportunity to interact with NPCs for trade and crafting. The marketplace is already established, allowing players to trade basic items and materials from the start. As the town develops and buildings are upgraded, new NPCs emerge, offering more valuable and powerful items for sale. These interactions provide players with the opportunity to gather resources. Similarly, crafting NPCs like the Blacksmith allow players to create new items from the materials they gather. While the crafting process initially focuses on simple items, upgrading town buildings unlocks the ability to craft more advanced and powerful items. The quality of crafted items is determined by a d100 roll, which increases the chances of creating rare, powerful items. NPCs guide players with crafting recipes and required materials. Building and upgrading structures empowers players to take a stronger role in managing the town. Interacting with NPCs enables trade, crafting, and strategic decision-making. This process provides players with opportunities to strengthen themselves and generate resources.
Character attribute points directly influence success and performance in combat and other game aspects. Strength increases the damage dealt with equipped items and is essential for all actions that require physical power. Intelligence boosts the character's maximum mana and enhances the effectiveness of spells, making magic abilities more potent. Constitution increases the character's health points, improving survival chances. Dexterity reduces the damage taken while defending and enhances mobility, making the character more agile. Charisma plays a crucial role in trading, allowing the player to buy items at lower prices and sell them at a higher value. These attributes can be strategically allocated to fit different playstyles and provide advantages in various challenges throughout the game.
AI behaviors are shaped by the game structure and the player's interactions. The AI adapts to the player's chosen role and the progression of the game. It analyzes the player's movements and preferences to devise strategies. In combat, the AI analyzes the player's defense tactics and creates counter-attack plans. Additionally, the AI's actions and decisions change according to different stages of the game, requiring it to adjust to both peace and combat scenarios. The AI responds according to the player's role and continuously improves these responses based on game dynamics. This ensures that the game experience remains dynamic by constantly presenting new challenges to the player.
The type and number of enemies the player will encounter are randomly determined during the Gathering phase using a dice mechanism. This system influences the difficulty level and variety of enemies. After the battle, the player obtains loot through the Loot system. The type and amount of loot are determined based on the outcome of the battle and are added to the player's inventory.
The gathering and looting processes are carried out using a dice mechanism. Dice rolls determine the number and type of enemies, as well as the success rate of attack and defense actions during combat. This feature enhances the game's dynamism, preventing it from becoming monotonous and providing a more engaging experience for players.
If the player engages in turn-based combat, the battle scene is loaded. Within the battle scene, the player has several tactical options: they can attack using an equipped weapon, utilize scrolls or mana to perform powerful skills, reposition by moving left or right, choose to wait and observe the enemy's next move, or adopt a defensive stance to reduce incoming damage. These diverse combat choices provide strategic depth, allowing players to adapt their approach based on the situation and the enemy's behavior.
The player is presented with three options in the Coliseum: Encounter, Gladiator, or King. By selecting one of these options, the player enters the arena and engages in a battle based on the chosen difficulty level. Each option offers a unique type of challenge, encouraging the player to make strategic decisions.
To ensure a smooth and engaging experience for players, the following performance metrics will be prioritized:
- Response Time:
- User Input to Action Execution: Less than 100 milliseconds for town management actions, inventory management, and combat commands.
- Dice Roll Feedback: Results displayed within 1 second of the roll being triggered.
- Phase Transitions: Peace-to-War or War-to-Peace transitions should be completed in under 2 seconds.
- Throughput:
- Support for up to 100 active AI decision processes per second to simulate the King of the Gladiators’ human-like behavior.
- Scalability:
- The game must maintain consistent performance on both minimum and recommended hardware specifications.
- Towns with up to 10 buildings, inventories holding 100 items, and combat involving up to 2 opponents simultaneously should function without framerate drops below 60 FPS on recommended specifications and 30 FPS on minimum specifications. The minimum and recommended hardware specifications are as follows:
-
Minimum Requirements:
- Processor: Dual-core CPU (2.0 GHz or faster)
- RAM: 4 GB
- Graphics Card: Integrated GPU supporting DirectX 10 or OpenGL 3.3
- Storage: 2 GB free space
- Operating System: Windows 10 or newer
These specifications are selected to balance performance and accessibility, ensuring smooth gameplay and high-quality visuals for most players.
-
Regulatory Compliance:
- The game must adhere to copyright laws and licensing agreements, particularly concerning inspirations drawn from other games and systems.
- The game must comply with data protection laws, ensuring that any saved game files or user profiles are stored securely and locally.
-
Environmental Constraints:
- The game is designed exclusively for PC platforms and is not intended to run on mobile devices or consoles.
- Offline operation is a requirement, with no dependency on internet connectivity.
-
Technical Limitations:
- The AI system relies on heuristic-based decision-making rather than advanced neural networks to reduce computational complexity and meet performance requirements on minimum hardware.
- Graphics are limited to 2D isometric rendering to ensure compatibility with lower-end systems while maintaining visual clarity and style.
- The dice mechanics and their associated randomization functions must be lightweight, deterministic, and optimized for fast execution without impacting other game systems.
-
Development Constraints:
- The game is developed in C# using the Unity Engine, restricting certain features to those supported by the engine.
- A fixed development timeline requires prioritization of core gameplay mechanics over extended features such as multiplayer or extensive cutscenes.
- The system must be able to handle all expected inputs and should response without a crash. If any fail occurs, mean time to repair should be between 1 to 24 hours.
- Save and load functionality must be reliable, with no data corruption under typical use cases.
- Key gameplay systems (e.g., combat, crafting, AI behavior) must perform as intended under all defined scenarios, with error handling for unexpected inputs or states.
- The game will be available offline and should function without requiring an internet connection.
- It should be ready for use immediately after installation, with no dependency on external services or updates.
- Access to debug tools or administrative features must be restricted to developers during production builds.
- The codebase will follow best practices in modularity, with clear separation between gameplay logic, AI routines, and UI components.
- Documentation will be provided for each major system to facilitate updates and bug fixes.
- Error logs will be generated for crashes or abnormal behavior to simplify troubleshooting.
- The game is designed for the Windows operating system. However, the use of the Unity Engine and C# ensures future compatibility with macOS or Linux, should there be demand for additional platforms.
- System configurations such as resolutions and graphical settings can be adjusted to accommodate various hardware capabilities.
- User interface will guide players through complex mechanics such as crafting, combat, and town management.
- Tutorials will introduce core features and dice mechanics in a step-by-step manner to minimize the learning curve.
- Visual and auditory feedback will confirm player actions, ensuring clarity in outcomes like dice rolls, combat results, and crafting success.
- The game will support expansions, such as additional skills, AI behaviors, or new item sets, without significant reworking of core systems.
- AI computation scales proportionally to player actions to ensure a consistent challenge without impacting performance.
Rule and Munus does not involve any real-world physical threats but must address safety-critical software aspects to protect the user’s experience:
-
Data Safety:
- Backup mechanisms will ensure that save files are not corrupted, even during unexpected power loss or system failure.
- Autosave functionality will operate at key gameplay moments, preventing significant progress loss.
-
System Integrity:
- The game will not perform unauthorized operations on the player’s device, ensuring no interference with other applications or system files.
- Resource management in the game engine will prevent memory leaks or overuse of system resources, ensuring smooth operation without crashes.
-
Player Well-being:
- The game will include options to adjust visual settings to reduce strain, such as brightness control and a mode for colorblind accessibility.
- The random nature of dice rolls, and AI evolution will be balanced to ensure fairness.
Figure 1: Use case diagram.
Play Use Case Description
| Elements | Details |
|---|---|
| ID and Name | UC-01, Play |
| Primary Actor | User |
| Secondary Actor | System |
| Description | The player selects the Play option to continue a previous game, start a new game, or return to the main menu. |
| Pre-Condition | * The player is on the main menu screen. |
| Main Flow | * Player clicks on the "Play" button in the main menu. * The system displays the options: Continue, New Game, and Return. * Player selects one of the following: * Continue: Loads the last saved game. * New Game: Begins the character creation process. * Return: Returns to the main menu. |
| Post-Condition | * The game continues from the saved state, begins a new game, or returns to the main menu. |
| Alternative Flow | -. |
| Special Requirements | Smooth transition between game states and visual feedback for selected options. |
| Related Use Cases | UC-02,UC-04 |
New Game Use Case Description
| Elements | Details |
|---|---|
| ID and Name | UC-02, New Game |
| Primary Actor | User |
| Secondary Actor | System |
| Description | The player selects the New Game option to create a character by selecting a class/race and distributing attribute points. |
| Pre-Condition | * The player selects New Game from the Play menu. |
| Main Flow | * Player selects New Game. * The system displays class and race options that affect attributes and gameplay. * Player selects a class and race, and the system shows an Attribute Point Distribution screen. * Player allocates attribute points and confirms choices. * System shows a character preview screen. * Player either starts the game or returns to the main menu. |
| Post-Condition | * The character is created, and the game begins, or the player returns to the main menu. |
| Alternative Flow | The player may return to the main menu without starting a new game. |
| Special Requirements | Real-time effects for attribute point allocation and visual character preview. |
| Related Use Cases | UC-01, UC-03 |
Character Attribute Selection Use Case Description
| Elements | Details |
|---|---|
| ID and Name | UC-03, Character Attribute Selection |
| Primary Actor | User |
| Secondary Actor | System |
| Description | The player allocates points to character attributes such as Strength, Dexterity, and Intelligence. |
| Pre-Condition | * The player is on the Attribute Point Distribution screen. |
| Main Flow | * System shows available attributes and point pool. * Player allocates points to attributes. * System shows real-time updates based on allocations. * Player confirms or resets the allocation. |
| Post-Condition | * The character attributes are updated based on the allocation. |
| Alternative Flow | The player resets the allocation and redistributes points. |
| Special Requirements | Real-time feedback and visual updates for attribute allocation. |
| Related Use Cases | UC-01, UC-05 |
Continue Use Case Description
| Elements | Details |
|---|---|
| ID and Name | UC-04, Continue |
| Primary Actor | User |
| Secondary Actor | System |
| Description | The player continues gameplay from the last saved state. |
| Pre-Condition | * A saved game exists. |
| Main Flow | * System checks for saved game data. * The saved game is loaded. |
| Post-Condition | * Gameplay resumes from the saved state. |
| Alternative Flow | If no saved game exists, the system notifies the player. |
| Special Requirements | Quick and smooth game loading. |
| Related Use Cases | UC-02, UC-05 |
In-Game Actions Use Case Description
| Elements | Details |
|---|---|
| ID and Name | UC-05, In-Game Actions |
| Primary Actor | User |
| Secondary Actor | System |
| Description | The player performs actions such as movement, combat, and interaction during gameplay. |
| Pre-Condition | * The player has an active game session. |
| Main Flow | * Player inputs a command or action. * The system processes the action and updates the game state accordingly. |
| Post-Condition | * The game state is updated based on the performed action. |
| Alternative Flow | The player may cancel or undo certain actions if allowed. |
| Special Requirements | Responsive input processing and minimal latency. |
| Related Use Cases | UC-03, UC-04, UC-06, UC-18, UC-27 |
Peace Phase Actions Use Case Description
| Elements | Details |
|---|---|
| ID and Name | UC-06, Peace Phase Actions |
| Primary Actor | User |
| Secondary Actor | System |
| Description | This use case describes the actions and activities available to the player during the Peace Phase of the game. During this phase, the player can manage resources, trade, and perform other peaceful activities without engaging in combat. |
| Pre-Condition | * The game must be in the Peace Phase, and there should be no active combat or conflict. |
| Main Flow | * The game transitions into the Peace Phase. * The player accesses the peace-related activities menu (e.g., manage resources, trade). * The player selects an action (e.g., trading, managing resources). * The system processes the selected action (e.g., updating resource counts, completing a trade). * The player performs the selected peaceful activities (e.g., trades, upgrades, manages buildings). * The system confirms the successful completion of actions or activities. |
| Post-Condition | * The player’s resources are updated based on the actions taken during the Peace Phase (e.g., resources are gained or spent, buildings are upgraded, trades are completed). |
| Alternative Flow | If the player does not have enough resources or is unable to perform a selected action, the system will notify the player and cancel the action. |
| Special Requirements | The player must not be in any active combat situation, and the game must be in the Peace Phase for these actions to be available. |
| Related Use Cases | UC-05, UC-07, UC-10, UC-09, UC-17 |
Manage Inventory Use Case Description
| Elements | Details |
|---|---|
| ID and Name | UC-07, Manage Inventory |
| Primary Actor | User, AI |
| Secondary Actor | System |
| Description | This use case describes how the player (or AI) manages their inventory, adds, removes, and organizes items. The player (or AI) selects, moves, or uses items in their inventory. |
| Pre-Condition | * The player (or AI) must have access to the inventory, and there must be at least one item in the inventory. |
| Main Flow | * The player (or AI) accesses the inventory menu. * The system displays the player's (or AI’s) current items. * The player (or AI) selects an item from their inventory. * The player (or AI) chooses an action for the selected item (e.g., use, sell). * The system performs the chosen action. * The player (or AI) updates their inventory. |
| Post-Condition | * The player's (or AI's) inventory is updated based on the performed action, with the item either used, sold, or moved. The inventory count and item status are updated accordingly. |
| Alternative Flow | If there is not enough space in the inventory, the system displays a notification and informs the player (or AI) that the item cannot be added. |
| Special Requirements | The system must be able to correctly update the number, type, and condition of the items in the inventory. |
| Related Use Cases | UC-08, UC-06 |
Equip Item Use Case Description
| Elements | Details |
|---|---|
| ID and Name | UC-08, Equip Item |
| Primary Actor | User |
| Secondary Actor | System |
| Description | This use case describes how the player equips an item to their character. The player can equip items such as weapons, armor, and accessories to enhance the character's abilities or improve stats. The system checks the player's inventory and the item’s requirements before allowing the player to equip it. |
| Pre-Condition | * The player must have an item in their inventory that can be equipped. |
| Main Flow | * The player accesses their inventory. * The system presents the list of items in the inventory. * The player selects the item they wish to equip. * The item is equipped, and the player's stats or abilities are updated. * The system updates the inventory, removing the equipped item from the available inventory items. * The player’s character's visual representation is updated. |
| Post-Condition | * The item is equipped, and the character’s stats or abilities are updated. The item is no longer available in the inventory as it is now equipped. |
| Alternative Flow | - |
| Special Requirements | The system must handle equipment that has associated visual changes. |
| Related Use Cases | UC-07 |
Attribute Point Distribution Use Case Description
| Elements | Details |
|---|---|
| ID and Name | UC-09, Attribute Point Distribution |
| Primary Actor | User, AI |
| Secondary Actor | System |
| Description | This use case describes how the player (or AI) allocates attribute points to customize their character. Attribute points can be distributed across attributes such as Strength, Intelligence, Constitution, Dexterity, Charisma, and Luck, affecting various aspects of gameplay. |
| Pre-Condition | * The player (or AI) must have earned new attribute points and reviewed their character's current status. |
| Main Flow | * The player (or AI) checks their character's current status and available attribute points. * The system presents an interface to allocate the attribute points. * The player (or AI) distributes points across the following attributes: - Strength: Increases damage dealt and enhances physical power. - Intelligence: Boosts mana capacity and spell effectiveness. - Constitution: Improves health points and survival chances. - Dexterity: Enhances agility and reduces incoming damage. - Charisma: Affects trading efficiency, improving buying and selling prices. - Luck: Increases critical success chances in various gameplay aspects. * The system saves the changes and displays the updated character status. * The player (or AI) proceeds with other actions. |
| Post-Condition | * The player’s (or AI’s) attribute points have been allocated, and the character's updated status has been saved. |
| Alternative Flow | If points are left unused, the system notifies the player and encourages completing the allocation. |
| Special Requirements | The system should accurately calculate the impact of attributes on the player’s performance. |
| Related Use Cases | UC-06 |
Select Buildings Use Case Description
| Elements | Details |
|---|---|
| ID and Name | UC-10, Select Buildings |
| Primary Actor | User |
| Secondary Actor | System |
| Description | This use case describes the process of selecting a building to interact with, upgrade, or use its functionalities. Actions include initiating construction, performing upgrades, or interacting with NPCs. |
| Pre-Condition | * The player must have access to the building interface, and the building must be visible and interactable. |
| Main Flow | * The player opens the game interface displaying buildings. * The player clicks on a building they wish to select. * The system highlights the selected building and displays available actions (e.g., upgrade, NPC interaction). * The player selects an action. * The system processes the action and provides feedback. * The interaction concludes. |
| Post-Condition | * The building's status is updated based on the selected action (e.g., construction begins, upgrades initiated, or NPC interaction completed). |
| Alternative Flow | If resources are insufficient for the action, the system notifies the player and offers alternative options. |
| Special Requirements | The building must be interactable, and the player must have the resources required for actions like upgrades or construction. |
| Related Use Cases | UC-06, UC-13 |
Construct Buildings Use Case Description
| Elements | Details |
|---|---|
| ID and Name | UC-11, Construct Buildings |
| Primary Actor | User |
| Secondary Actor | System |
| Description | This use case describes the phase where players construct buildings in their village during the peace period. Players use their available resources to select a building and place it in a suitable location. This action is only available during the peace period and is strategically important. Initially, only basic buildings can be constructed, which serve as the foundation for game progression. |
| Pre-Condition | * The player accesses the building menu or interface. |
| Main Flow | * The player selects a specific building type to construct. * The game switches to building placement mode. * The player chooses a suitable location for placement. * The player clicks or taps on the selected location to initiate building placement. |
| Post-Condition | * The building construction is completed. * The required resources are deducted from the player’s total resources. |
| Alternative Flow | If the player does not have enough resources, the game checks for sufficient resources before placement. If resources are insufficient, a notification is displayed, and the process is canceled. If an invalid location is selected, the game notifies the player and prompts for a new location. |
| Special Requirements | The player must have sufficient space and resources. The selected building must be placed in a suitable location, and infrastructure conditions must be met. |
| Related Use Cases | UC-10, UC-12 |
Upgrade Building Use Case Description
| Elements | Details |
|---|---|
| ID and Name | UC-12, Upgrade Building |
| Primary Actor | User, AI |
| Secondary Actor | System |
| Description | This use case describes the process where players upgrade existing buildings to enhance their avatars, granting them new abilities or stronger traits. The upgrade process depends on the player’s resources and progress. Upgraded buildings provide the player with improved features, enabling strategic game advancement. |
| Pre-Condition | * The player (or AI) has selected an existing building to upgrade. * The player has sufficient resources and tools for the upgrade. |
| Main Flow | * The player (or AI) selects an existing building to upgrade. * The player (or AI) accesses the upgrade option for the selected building. * The game checks if sufficient resources and tools are available. * If requirements are met, the upgrade is confirmed, and the process proceeds. * The game completes the upgrade, and the building grants new abilities or powers. |
| Post-Condition | * The upgrade is completed, and the building grants new abilities or powers to the player. |
| Alternative Flow | If the player (or AI) lacks the necessary resources or tools, a notification is displayed, and the process is canceled. |
| Special Requirements | The player (or AI) must have the necessary resources for the upgrade. |
| Related Use Cases | UC-11, UC-10 |
Interact with the NPC Use Case Description
| Elements | Details |
|---|---|
| ID and Name | UC-13, Interact with the NPC |
| Primary Actor | User |
| Secondary Actor | System |
| Description | This use case describes the process of the player interacting with NPCs. Interactions with NPCs can include trading, accepting quests, initiating dialogue, or other activities. |
| Pre-Condition | * The player must be in the vicinity of an NPC, and the related building must be dry to initiate interaction. |
| Main Flow | * The player clicks on a building or structure to open the interaction menu. * The player selects the "Talk to NPC" option from the menu. * The system displays available interaction options (e.g., trade). * The player selects an interaction option. * The system processes the selected option. * The NPC interaction concludes. |
| Post-Condition | * The interaction is completed, and relevant changes (e.g., resources deducted, quests accepted) are reflected. |
| Alternative Flow | If the player lacks the necessary resources for trade, the NPC rejects the interaction. |
| Special Requirements | The related building must be dry in order to interact with the NPC. |
| Related Use Cases | UC-10, UC-14, UC-15, UC-16 |
Craft Item Use Case Description
| Elements | Details |
|---|---|
| ID and Name | UC-14, Craft Item |
| Primary Actor | User, AI |
| Secondary Actor | System |
| Description | This use case describes how the player (or AI) crafts a new item using available resources. Crafting is only possible if the blacksmith building has been constructed. The player selects the desired item, and the system deducts the required resources. Once crafting is complete, the new item is added to the player’s inventory. |
| Pre-Condition | * The blacksmith building must be constructed. * The player (or AI) must have sufficient resources to craft the item. |
| Main Flow | * The player (or AI) accesses the crafting menu at the blacksmith building. * The player (or AI) selects the item to craft. * The game checks if the player has enough resources to craft the item. * If sufficient resources are available, the game proceeds with crafting and deducts the resources. * Upon completion, the crafted item is added to the player’s (or AI’s) inventory. |
| Post-Condition | * The crafted item is added to the player’s (or AI’s) inventory. * The required resources are deducted. |
| Alternative Flow | If the player (or AI) does not have enough resources to craft the item, a notification is displayed, and the crafting process is canceled. |
| Special Requirements | * The blacksmith building must be constructed. * The player (or AI) must have the necessary resources to craft the item. |
| Related Use Cases | UC-13 |
Sell Item Use Case Description
| Elements | Details |
|---|---|
| ID and Name | UC-15, Sell Item |
| Primary Actor | User, AI |
| Secondary Actor | System |
| Description | This use case describes the process of the player (or AI) selling an owned item through the market. The player selects an item from their inventory, and the market transaction occurs. After the sale, the player’s (or AI’s) resources are increased by the item’s selling price. |
| Pre-Condition | * The player (or AI) must have the item they wish to sell in their inventory. |
| Main Flow | * The player (or AI) accesses the market. * The player (or AI) selects the item to sell. * The game checks the selling price of the item and the available resources. * If the transaction is valid, the sale proceeds. * After the sale, the player’s (or AI’s) resources are increased, and the item is removed from the inventory. |
| Post-Condition | * The sale is completed. * The player's (or AI’s) resources are increased, and the item is removed from their inventory. |
| Alternative Flow | If the item cannot be sold, the game notifies the player (or AI) and cancels the sale. |
| Special Requirements | The player (or AI) must have the item in their inventory that they wish to sell. |
| Related Use Cases | UC-13 |
Buy Item Use Case Description
| Elements | Details |
|---|---|
| ID and Name | UC-16, Buy Item |
| Primary Actor | User, AI |
| Secondary Actor | System |
| Description | This use case describes how the player (or AI) buys a new item from the market, which is already established at the start of the game. The player selects an item and purchases it using available resources. After a successful purchase, the item is added to the player’s (or AI’s) inventory. |
| Pre-Condition | * The player (or AI) must have sufficient resources for the purchase. |
| Main Flow | * The player (or AI) accesses the market. * The player (or AI) selects the item to purchase. * The game checks if the player has enough resources. * If sufficient resources are available, the required amount is deducted from the total. * The purchased item is added to the player’s (or AI’s) inventory. |
| Post-Condition | * The item is added to the player’s (or AI’s) inventory. * The player’s (or AI’s) resources are updated accordingly. |
| Alternative Flow | If the player (or AI) lacks enough resources, the game shows a notification, and the purchase is canceled. |
| Special Requirements | The player (or AI) must have sufficient resources for the purchase. |
| Related Use Cases | UC-13 |
End Phase Use Case Description
| Elements | Details |
|---|---|
| ID and Name | UC-17, End Phase |
| Primary Actor | User |
| Secondary Actor | System |
| Description | This use case outlines the process of completing the current phase of the game and preparing for the next. Once the player completes the current phase, the game transitions to the next phase. |
| Pre-Condition | * The player must have completed all requirements for the current phase. |
| Main Flow | * The system checks if the current phase is complete. * The player is notified that the phase is finished. * The system records the player’s progress. * Necessary preparations for the next phase are made. * Once the end phase is completed, the game is ready to transition to the next phase. |
| Post-Condition | * The player's progress is recorded, and preparations for the next phase are completed. |
| Alternative Flow | If the phase is incomplete or the requirements are not met, the system informs the player and provides guidance on completing the phase. |
| Special Requirements | The system must accurately record the player's rewards and progress. |
| Related Use Cases | UC-18, UC-06 |
War Phase Actions Use Case Description
| Elements | Details |
|---|---|
| ID and Name | UC-18, War Phase Actions |
| Primary Actor | User |
| Secondary Actor | System |
| Description | This use case outlines the actions the player can perform during the war phase. The player can gather materials, engage in combat, or participate in tournaments. These actions influence the outcomes of the war phase. The system processes the player’s input and provides feedback. |
| Pre-Condition | * The war phase must be active. * The player must be able to make choices based on the current phase. |
| Main Flow | * The system starts the war phase and presents the player with an overview of the battlefield or available options. * The player chooses an action (e.g., Gather Materials, Go to the Colosseum, or other strategic options). * The system processes the action, considering factors such as resources, environmental conditions, AI actions, and player stats. * If "Gather Materials" is selected, the system rolls a d20 die to determine: - Whether an encounter occurs. - The multiplier for gathered materials (0.5x, 1x, 2x). * If an encounter occurs, the player can choose to: - Flee: A d20 die is rolled to check for success. If successful, materials are safely collected (1x). - Engage in combat: A turn-based combat scene is initiated. * If "Go to the Colosseum" is selected, the player participates in a gladiator tournament, fighting sequential opponents. * After each action’s outcome, the player evaluates the results and chooses the next step. * The system ends the war phase, calculates the final outcomes, and prepares for the next phase. |
| Post-Condition | * The war phase ends, and the player’s actions and decisions are recorded. * The system calculates the final outcomes and prepares for the next phase. |
| Alternative Flow | If a sudden event occurs, the system dynamically adjusts the results and informs the player. |
| Special Requirements | The system must generate realistic and dynamic war outcomes based on the player’s stats and decisions. |
| Related Use Cases | UC-05, UC-17, UC-20 |
Gather Use Case Description
| Elements | Details |
|---|---|
| ID and Name | UC-19, Gather |
| Primary Actor | User, AI |
| Secondary Actor | System |
| Description | This use case determines the type and number of enemies the player (or AI) will encounter during a gathering action. It specifies which enemies will appear and how many. |
| Pre-Condition | * The player (or AI) interacts with a section of the game where enemy selection occurs. |
| Main Flow | * The system determines the types and numbers of enemies using dice rolls. * The selected enemies and their numbers are displayed to the player (or AI). |
| Post-Condition | * The player (or AI) proceeds to fight the selected enemies. |
| Alternative Flow | If the player uses a special item or ability, it may affect the type and number of enemies. For instance, using a "hard level" item could result in stronger enemies appearing. |
| Special Requirements | The results of the gathering action should be communicated to the player with visual and sound effects. |
| Related Use Cases | UC-18, UC-21 |
Go to Colosseum Use Case Description
| Elements | Details |
|---|---|
| ID and Name | UC-20, Go to Colosseum |
| Primary Actor | User, AI |
| Secondary Actor | System |
| Description | This use case involves the player (or AI) choosing one of three options in the Colosseum: Encounter, Gladiator, or King. By selecting one of these, the player enters the arena and engages in battle based on the chosen difficulty level. Each option offers a unique challenge, encouraging strategic decision-making. |
| Pre-Condition | The player (or AI) decides to enter the arena. |
| Main Flow | * The system presents three options: Encounter, Gladiator, or King. * The player (or AI) selects their desired challenge. * The system determines the appropriate difficulty and enemies for the chosen option and initiates the battle. |
| Post-Condition | The player (or AI) proceeds with the chosen strategy to succeed in the battle. |
| Alternative Flow | If the player (or AI) loses the battle, they can return to the arena, select a different option, or try a new strategy. |
| Special Requirements | Unique enemy structures and strategies must be designed for each type of combat. |
| Related Use Cases | UC-18, UC-21 |
Combat Actions Use Case Description
| Elements | Details |
|---|---|
| ID and Name | UC-21, Combat Actions |
| Primary Actor | User, AI |
| Secondary Actor | System |
| Description | This use case occurs when the player (or AI) engages in turn-based combat. During the battle, the player has multiple tactical options, including attacking with an equipped weapon, using scrolls or mana for powerful skills, repositioning, waiting and observing the enemy's next move, or adopting a defensive stance to reduce incoming damage. |
| Pre-Condition | The player (or AI) decides to enter turn-based combat. |
| Main Flow | * The player (or AI) enters the battle scene. * The system presents the tactical options to the player (or AI). * The player (or AI) selects an action based on the current situation (attack, defense, skill use, movement, waiting, etc.). * The chosen action affects the battle's outcome. |
| Post-Condition | The player's (or AI's) selected tactic impacts the outcome of the battle. |
| Alternative Flow | If the player (or AI) chooses to attack and the attack is successful, but the enemy counters and returns the attack, the player may take damage, but the battle continues. |
| Special Requirements | * Visual and sound effects should be customized to the action (e.g., sword attack, magic use). * The success of actions depends on the player's (or AI's) abilities and resources (e.g., mana, stamina). * Enemy reactions should dynamically respond to the player’s (or AI's) actions. * Actions should be flexible, allowing the player (or AI) to change their strategy during combat. |
| Related Use Cases | UC-19, UC-20, UC-22, UC-23, UC-24, UC-25 |
Attack Use Case Description
| Elements | Details |
|---|---|
| ID and Name | UC-22, Attack |
| Primary Actor | User, AI |
| Secondary Actor | System |
| Description | In turn-based combat, the player (or AI) can attack an enemy using an equipped weapon. This action deals damage to the enemy and affects the course of the battle. |
| Pre-Condition | The player (or AI) has equipped a weapon for the attack. |
| Main Flow | * The player (or AI) selects the "attack" option to use the weapon. * The system calculates the damage based on the player's (or AI's) attack power and the enemy's defense. * The attack is applied to the enemy, and the damage is displayed. |
| Post-Conditions | The enemy reacts to the damage received. |
| Alternative Flow | If the player's (or AI's) weapon is damaged or there is not enough power to attack (e.g., low durability or lack of skill), the player cannot attack. In this case, the player must choose another action, such as defense or using a skill. |
| Special Requirements | * Attack success percentage should be proportional to the player's (or AI's) attack power and the enemy's defense value. * Attack animations and effects should be customizable according to the attack type (e.g., sword attack, arrow shooting). * Sound and visual effects should align with the attack type. |
| Related Use Cases | UC-21 |
Defend Use Case Description
| Elements | Details |
|---|---|
| ID and Name | UC-23, Defend |
| Primary Actor | User, AI |
| Secondary Actor | System |
| Description | In turn-based combat, the player (or AI) can reduce incoming damage by taking a defensive stance. This minimizes the damage received from enemy attacks. |
| Pre-Conditions | The player (or AI) selects the "defend" option. |
| Main Flow | * The system reduces the damage based on the player’s (or AI’s) defense power. * The enemy's attack is applied to the player (or AI) in the defensive stance. |
| Post-Conditions | The player takes less damage as a result of the defensive stance. |
| Alternative Flow | If the player (or AI) does not have enough resources (e.g., mana or skills) for defense, the defense fails, and the player takes damage. |
| Special Requirements | * The defense mechanism should dynamically calculate defensive strength (e.g., based on armor, skills, or temporary buffs). * Defensive animations and visual effects can be customized based on the type of defense (e.g., shield, positioning). * Appropriate feedback should be given when defense fails. |
| Related Use Cases | UC-21 |
Use Skill Use Case Description
| Elements | Details |
|---|---|
| ID and Name | UC-24, Use Skill |
| Primary Actor | User, AI |
| Secondary Actor | System |
| Description | The player (or AI) can use powerful skills during combat by utilizing scrolls or mana. These skills can affect the enemy or provide advantages to the player. |
| Pre-Condition | The player (or AI) has a skill and the necessary resource (mana or scroll). |
| Main Flow | * The player selects the "use skill" option. * The system considers the effect of the selected skill and the required resource (mana or scroll). * The skill's result applies damage to the enemy, provides defense, or grants another advantage to the player (or AI). |
| Post-Condition | After using the skill, the resource level (mana or scroll) decreases. |
| Alternative Flow | If an error occurs during skill use (e.g., incorrect skill selection or target), the skill fails. The player will spend the resource but the skill will have no effect. |
| Special Requirements | * Visual effects and sounds during skill use should be customized based on the skill type (e.g., magic damage, armor break, speed increase). * The effect of skill use should vary depending on the skill type and the resource used. * The skill success percentage should depend on the player's (or AI's) skill level and resource amount. |
| Related Use Cases | UC-21 |
Flee Use Case Description
| Elements | Details |
|---|---|
| ID and Name | UC-25, Flee |
| Primary Actor | User |
| Secondary Actor | System |
| Description | The player (or AI) attempts to flee from a battle or dangerous situation to avoid defeat or damage. |
| Pre-Conditions | The player presses the flee button. |
| Main Flow | * The user is informed of the consequences if they escape. |
| Post-Conditions | The player either escapes successfully or continues the encounter after a failed attempt. |
| Alternative Flow | The player does not select the flee option and continues the combat/danger scenario. |
| Special Requirements | * Clear notification of success/failure and immediate transition to safe locations on success. |
| Related Use Cases | UC-21 |
Credits Use Case Description
| Elements | Details |
|---|---|
| ID and Name | UC-26, Credits |
| Primary Actor | User |
| Secondary Actor | System |
| Description | The player views information about the development team and contributors. |
| Pre-Condition | The player is on the main menu screen. |
| Main Flow | * Player clicks on the "Credits" button. * The system displays a list of contributors. * Player scrolls through or exits to return to the main menu. |
| Post-Condition | The player views the credits or returns to the main menu. |
| Alternative Flow | - |
| Special Requirements | The credits list should be easy to read and navigate. |
| Related Use Cases | UC-30 |
Settings Use Case Description
| Elements | Details |
|---|---|
| ID and Name | UC-27, Settings |
| Primary Actor | User |
| Secondary Actor | System |
| Description | The player adjusts game settings such as effects, music, and graphic quality. |
| Pre-Condition | The player is on the main menu screen. |
| Main Flow | * Player clicks on the "Settings" button. * The system displays options: Effects, Music, Graphic Quality, and Return. * Player adjusts settings and confirms or selects Return to go back. |
| Post-Condition | Changes are applied (if selected) or the player returns to the main menu. |
| Alternative Flow | - |
| Special Requirements | - |
| Related Use Cases | UC-29, UC-28, UC-05 |
Adjust Sound Use Case Description
| Elements | Details |
|---|---|
| ID and Name | UC-28, Adjust Sound |
| Primary Actor | User |
| Secondary Actor | System |
| Description | The player adjusts sound settings such as effects and music volume. |
| Pre-Condition | The player is on the Settings screen. |
| Main Flow | * System shows sound options. * Player adjusts sliders. * System applies changes in real-time or upon confirmation. |
| Post-Condition | The sound settings are updated. |
| Alternative Flow | - |
| Special Requirements | Real-time audio feedback for sound adjustments. |
| Related Use Cases | UC-27, UC-29 |
Adjust Graphics Use Case Description
| Elements | Details |
|---|---|
| ID and Name | UC-29, Adjust Graphics |
| Primary Actor | User |
| Secondary Actor | System |
| Description | The player adjusts graphic settings such as quality and resolution. |
| Pre-Condition | The player is on the Settings screen. |
| Main Flow | * Player selects a graphical setting. * System applies changes in real-time or upon confirmation. |
| Post-Condition | The graphical settings are updated. |
| Alternative Flow | - |
| Special Requirements | Real-time preview of graphical changes. |
| Related Use Cases | UC-27, UC-28 |
Show Contributors Use Case Description
| Elements | Details |
|---|---|
| ID and Name | UC-30, Show Contributors |
| Primary Actor | User |
| Secondary Actor | System |
| Description | The player views a list of contributors from the Credits menu. |
| Pre-Condition | The player is on the main menu screen. |
| Main Flow | * The player selects the "Credits" button. * The system displays the list of contributors with names and roles. * The player can scroll through the list or return to the main menu. |
| Post-Condition | The player views the contributors or exits to the main menu. |
| Alternative Flow | - |
| Special Requirements | The list of contributors must be displayed in a clear and visually appealing format. |
| Related Use Cases | UC-26 |
- Doç. Dr. Gül TOKDEMİR - Advisor
- Dr. Öğr. Üyesi Talha KARADENİZ - Advisor
- Arş. Gör. Sezer UĞUZ - Advisor
- Dorukhan YILDIZ – Designer, Developer
- Sezer Can EKİZ- Developer
- Ömer YURTALAN - Developer
- Semih OĞUZ- Developer
Figure 2: Work Plan.
Figure 3: Agile Methodology.
This SRS serves as a foundational document that encapsulates the game’s objectives, features, and technical requirements. It highlights the blend of innovative gameplay mechanics, including strategic actions and decisions, dice-based combat, and a human-like adaptive AI opponent. Each requirement detailed in this document aims to guide the development team. The document establishes a clear framework for collaboration among team members and stakeholders, providing a shared understanding of the project's scope and constraints. It also serves as a reference point for future phases of the project, from implementation to testing and eventual deployment.