Deliverable 1: Project definition and Software Requirements Specification - QuitoTactico/DnD-AI GitHub Wiki

Table of Contents

1. Introduction

1.1. Purpose

Dungeons and Dragons is a role-playing game in which several people come together and play as fictional characters in a world with a story of their own creation. The Dungeon Master is in charge of this task of creating and directing the players' campaign, a person who dedicates large amounts of time to thinking, designing and writing the history, culture, geography and other aspects of the world, and in addition to that, the course of story that the characters will follow.

DnD AI is a solution so that the Dungeon Master's work does not become so exhausting and extensive, and so he and the other players can enjoy such role-playing games in a much more comfortable, simple and calm way. In addition to this, role-playing games depend entirely on the imagination of their players, so DnD AI serves as an assistant to make this imaginative process much easier, creating illustrations of the actions that players are taking, thus generating a better experience of the game.

1.2. Scope

DnD AI is a game assistant service that will provide the players with a world that they can play in. This world will be written by an AI and will have its own history and culture and will be guiding the players through certain scenes, like the square of a game board, where they must act based on a few options. Every time a scene is over, depending on the players’ choices, the AI will write the next course of action and the history of the players will continue.

Also, at every action that the players take, we will provide him with an AI-generated illustration of that action, providing this way a much better and visual experience.

Our goal is to make DnD AI not just a game assistant but a platform that will serve as an online game board for role-playing games, in which players from all over the world can connect and experience easy, fun and exciting adventures.

1.3. Product Overview

1.3.1. Product Perspective

Our project has a user interface divided into three (optionally four) different components:

  • The console (left): Here, the player can see the initial story options, the campaign goal, how the campaign develops, the results of the battles, his recommended actions.

  • The input zone (bottom left): Is where the player writes what does he wants to do in the actual turn. Natural language inputs will be allowed (probably in the second functional deliverable) because that’s our differentiating factor. The results of his actions can be seen in the console.

  • Character zone (right): The player’s character image (OPTIONAL, upper right corner) and actual statistics (bottom right) can be seen from here.

  • Map zone (OPTIONAL, upper left, above the console): The map will show the actual player and monster’s positions through a tile system. The actions of the player can now be seen in a more visual way, allowing a new strategical approach.

Our project also has an admin view automatically generated by Django, where the administrators and developers can add, modify and delete monsters, items and their stats and coordinates manually.

Is specifically oriented to be used in a computer, not in mobile devices.

Django has a default database and that’s the database engine we are going to use, SQLite. Django is a high-level web framework that encourages rapid development made with and for Python projects.

The project will have connection with two APIs: OpenGL and Dall-E, both are going to be used for AI generation of text and images respectively.

The host will communicate with the project using HTTP protocol.

1.3.2. Product Functions

  • The user's first interaction with DnD AI will involve the initial creation of the world. Initially, the user will instruct the system to create a new game session and, consequently, generate a new world. The system will present the user with a summarized description of the world and offer the option to create a new one if they are dissatisfied.

  • Following this, users will receive three possible introductory stories of the world, each one with a goal that the player must archieve to finish the game. The player must select one of them.

  • Enabling them to create their characters in a fully customized manner. They will have the ability to customize their characters' physical appearance, race, stats, skills, and weapons.

  • As the story progresses to points where player action is required, users will be presented with a menu of actions from which they can select their desired course of action using natural language.

  • The actions taken by the players will dynamically influence the direction of the story. Consequently, each action taken will prompt corresponding modifications to the storyline.

  • Additionally, whenever players undertake a significant action, an illustration depicting the situation as accurately as possible will be provided.

  • During encounters with monsters, the damage inflicted or sustained by players will be accurately reflected. If a player's character dies, the game will conclude.

  • If the player fulfills the campaign (playable story) goal, the game is won and then concludes.

1.3.3. User Characteristics

The target audience of DnD AI includes both experienced and inexperienced role-playing players. DnD AI serves as a solution not only for addressing the time constraints and burnout experienced by dungeon masters and players alike across various role-playing games but also for overcoming the barrier that prevents non-players from engaging due to assumptions about the games being overly complex and time-consuming.

As such, users do not require any prior experience or knowledge to utilize DnD AI; all they need is a love for exploring uncharted worlds and a passion for immersing themselves in the campaign.

1.3.4. Limitations

  • Our project needs connection with the OpenAI API, which is the one that makes the initial story and develops the campaign route and understands the commands provided by the player in natural language. It’s indispensable, but it’s a paid API, so our balance could empty at anytime.

  • Also, DnD-AI must need connection with Dall-E API if we develop the AI Image Generation requirements for the character icon and epic scene images. At least that API is free.

  • For the course, we will deploy our project in google cloud, which has a 5 USD price per month.

  • All our requests (user-project and project-APIs) will be via HTTP.

  • An Internet connection is needed to use our project.

  • At least, all of the API requests must be faster than 10 seconds, so the player doesn’t get bored waiting for the story to develop, or his desired actions to be performed.

  • Our project is only usable from a computer, mobile devices sessions are not supported

  • The host’s computer should have a microphone entry to use the optional audio input, an alternative way to perform actions

  • The host’s computer must have a keyboard, to use the default terminal input. For our sake, that requirement is commonly fulfilled.

  • For the first functional deliverable, we will only support one simultaneous session of the game. We will see if the project could support more simultaneous sessions in the future.

  • For the first functional deliverable, we will only support one player per session. We will see if the project could support more players in the same session in the future.

1.4. Definitions

  • AI (Artificial Intelligence): Technology that enables machines to perform tasks that typically require human intelligence.
  • API (Application Programming Interface): Set of rules allowing interaction between different software applications or components.
  • Authentication: The process of verifying the identity of users or systems attempting to access the project, ensuring security.
  • Authorization: Defines the permissions and access levels granted to authenticated users, contributing to a secure environment.
  • Campaign (DnD): A series of connected adventures and narrative elements forming a larger story arc in Dungeons and Dragons.
  • Cloud Deploy: The process of deploying and hosting applications or services on cloud infrastructure, providing scalability.
  • Console: Gaming platform or electronic device designed to run video games.
  • Dall-E: Artificial intelligence model developed by OpenAI to generate images based on textual descriptions.
  • Database: A structured collection of data that the project utilizes for storing, retrieving, and managing information.
  • Django: High-level web framework for Python that encourages rapid development and clean, pragmatic design.
  • Git: Distributed version control system for tracking changes in source code during software development.
  • GitHub: Web-based platform for version control and collaborative software development using Git.
  • HTTP (Hypertext Transfer Protocol): Protocol for transmitting data over the internet.
  • Host: A computer or system that provides services to other connected devices on a network.
  • Input: Data or commands provided to a system, often through devices like keyboards, mouse, or other input interfaces.
  • Logging: Recording events, actions, or errors within the project for debugging, monitoring, and analysis.
  • Middleware: Acts as a bridge between different components of the project, facilitating communication and data exchange.
  • OpenAI: Artificial intelligence research company that develops technologies such as GPT (Generative Pre-trained Transformer).
  • Python: High-level programming language known for its readability and versatility.
  • Races (DnD): Different fantasy species or groups of characters with unique traits and abilities in Dungeons and Dragons.
  • Role (DnD): The character's function or purpose in a particular context, often referring to designated responsibilities or behavior in games or social situations.
  • Routing: Defines how the project directs incoming requests to the appropriate endpoints or functions.
  • Session: A period of interaction between a user and a system, often involving the exchange of information or data in a specific time frame.
  • Stats (Character and Monster Stats) (DnD): Statistical data describing the abilities and characteristics of characters or monsters in role-playing games.

2. References

Python: We will be using python as our main code language in the development of DnD AI.

Django: Django will be our python framework for the development of the back and front-end of the webpage.

Chat GPT: We will be using Chat-GPT as our writing provider, leaving it in charge of the creation of the stories and the continuation of them.

Google Cloud: For our database needs, we will be using Google Cloud services with the help of django.

Dall-E: Dall-E will be used for the creation of the illustrations of the players story.

3. Specific Requeriments

3.1. External Interfaces

User-System connection:

  • At the start of a game, the player can input the character he wants to be, like a magician, a warrior, or something else, with his statistics according to a point-limited system, into the console’s input label. Then, he would see his character stats on the character stats interface with an AI generated image of him (using Dall-E, that image generation is optional).

  • At the start of a game, the initial story generator offers three campaign options to the player (this contains the world context and the goal which the player needs to fulfill). The player can select his desired campaign using the console’s input label (writing 1, 2 or 3). Then, the campaign generator will develop the campaign according to the selected initial story, showing that development after each user action or decision.

  • If the player is not in a battle, the user can write his desired actions or decisions (like walking somewhere, opening a door or approaching an enemy) in natural language on the console’s input label. Then, according to the “actual circumstances” (like the ubication possible actions) the campaign generator will write the result of that action or decision, this will be showed to the user via game console.

  • If the player is in a battle, the user can write his desired actions (like attack or defense) in natural language on the console’s input label. The results of those actions depending on the user stats, position and the enemy stats are seen on the console (text), wrote by the campaign generator, and in the user stats interface (int), calculus made by the battle calculator.

  • In a battle, the dice roller generates a random integer number between 1 and 20 and gives it to the battle calculator. The battle calculator needs it to calculate the output, as the dice number affects the effectiveness of an attack or a defense.

  • In a battle, if through action inputs and battle development the player reaches 0 HP (health points, an integer showed up in the character interface) by enemy attacks or something else (the circumstances can be unique and strange depending on the player’s creativity), the console shows him a “You Lose...” text, then the campaign and game session ends.

  • If through action inputs and campaign development, the player reaches or fulfills the campaign goal (like reaching a zone, killing a specific enemy or finding an item), the console shows him a “You WIN!” text, then the campaign and game session ends.

  • Optionally (in future deliverables), the player could see a tiled-based map of his game. That’s an alternative output for the player actions.

  • Also, optionally (in future deliverables), the player could use an audio record button to input his decisions. An alternative action input for the user.

Project-Database connection:

  • At certain moments defined in the logic database requirements (DR0X), the game should need to save the character, items and monsters’ statistics (and optionally coordinates) in the database, so the game can continue where is left in the next game of the same session or take that data to do calculations. This statistics group consists in this:

image

  • Also, the database should save 4 forms of the same initial story (the selected one), as: the long one presented to the user (string), the short one used in the prompts (string), the list of keywords also used in some prompts (list of strings), and just the goal (string).

Project-APIs connection:

The project will have connection with two APIs, OpenAI for text generation and Dall-E for image generation.

  • OpenAI will receive text-based inputs, like the initial story and player actions to write the development of the campaign in each turn. Also interpreting the player input as a list of keywords so the system can understand them as commands to execute (like movement in any direction or place, open doors and attack enemies, also being helpful in the creation of the character). Both the initial story/campaign generation and input interpretation are very important for our game.

  • Dall-E will receive text-based inputs, like the character description, to generate an image of the character. We will put that generated image in the character interface. Also, could receive a situation description, so it will generate image of the “epic scenes” presented through the game (mostly in battles).

3.2. Functions

FR01. If the player wants to do certain actions, the dice roller must output an integer number between 1 and 20, so the action can or cannot be done, the action efectiveness also could be affected by the dice output.

FR02. At the end of every non-battle turn the campaign generator must redact the next situation that happens in the campaign using AI, writing the things that happens after the action is taken. Also being coherent with the past situations, actions and initial story.

FR03. The map visualizer shall show functional actions and dialogues at the designated squares so the players can interact with them

FR04. At the start of a game, the character creator shall help the player to create its character bringing him the options to fully customize its appearence and to select his statistics (stats) according to a points system

FR05. The player interface could show an AI generated illustration of the character after the player has chosen its appearence.

FR06. The player Interface must show the player's actual stats

FR07. When the player executes an "epic scene", the interface shall show an AI generated image of that "epic" scene. An "epic" scene is when a player attacks a monster for the first time, or when he finds a chest.

FR08. When a turn ends, the interface's console must show the current situation in the campaign, enabling it to progress. (It could be like "then, he was capable to open the door")

FR09. In the start of a turn, the interface's console must show the avaliable recommended actions that the player can execute. Besides they are recommended actions, the player can do almost anything they want (if his character and skills let him to do so), because thats the heart of the game, the creativity.

FR10. In the start of a game, the interface's console should show at least three different initial histories to the player so he can choose in which world he wants to play. The initial histories are AI generated,

FR11. In the start of a game, the interface's console should receive the input from the player, choosing his initial story option.

FR12. In the start of a turn, the input interpreter could receive the input as an audio from the player as an alternative form of controlling the character. The system must understand what's the player saying and then do the actions requested.

FR13. The map visualizer could show the player's and monster's icon, so the player can locate himself and the monsters to understand the situation.

FR14. The input interpreter must understand the player's natural language to transform it into actions that the program can excecute

FR15. The interface must be understandable and intuitive enough, so any player can learn how to play without any difficulty

FR16. After each action in a battle turn, the battle calculator must calculate the player's and monster's stats in a fight, according to the dice roll, attack and defense of the participants in the battle.

FR17. After the initial story is created, the map generator shall create a tile map to play in that session. The map is generated automatically without any player intervention.

FR18. At the start of each turn, the input receiver could allow the user to move with the WASD keys. The player can move his character using WASD

FR19. At the end of every battle. the campaign generator must follow a coherent battle result based on the stats calculator's final calculus. Then enabling the player to continue with the campaign.

FR20. At the start of a game, the session system must enforce the user to start a session so the game progress can be saved, and then the campaign should continue where it ended the last time.

3.3. Usability Requeriments

UR01. The session system must use the same play session that has been used previously everytime, until that campaign finishes

UR02. At the start of a game, the campaign generator must create three possible initial stories. At least one of them must be logic enough to be usable in the campaign, so the player can select it.

UR03. After the user selects the initial story, the map generator must create a map large enough to be played, with at least 100 tiles.

UR04. After the user selects the initial story, the map generator must create a map with the items and monsters required to complete the campaign according to the selected initial story

UR05. When the campaign goal has been fulfilled, the campaign generator must recognice that the player reached the end so the game can finish. The goal can be kill a specific monster, a number of monsters, found an item or reach a location.

UR06. In a battle, the battle calculator must recognice when a monster or a player is dead so the battle can finish and the player can continue doing actions in the campaign, or the game is finished if he dies.

3.4. Performance Requeriments

PR01. In an important scene, the image generator shall generate the illustration of that scene the most accurately possible within 5 seconds

PR02. The system must function fast and without interrumptions regardless the amount of sessions being played at the same time

PR03. After an user takes action, the system must query and send the information of the story of the actual campaign to the AI so it knows how to continue the story coherently.

PR04. When a player attacks a monster, the system shall reflect the damage inflicted and sustained in the most efficient way possible so the data updates quickly, fluently and correctly. This way, the game experience can be logic and playable.

PR05. At the start of the campaign, if the player wants different options of story, the story generator shall provide them new stories and worlds to choose within 10 seconds.

3.5. Logical Database Requeriments

DR01. After the initial story is created, the database must save that initial story, so the campaign generator can develop the game story according to it. There are four versions: The long one presented to the user, the short one used in the prompts, the list of keywords also used in some prompts, and just the goal.

DR02. After the character is created and after each battle, the database must save the actual character's stats, so the next battle can use them to do the calculus.

DR03. After the map is created and after each battle, the database must save the actual monsters' stats for each monster.

DR04. After each turn, the database shall save the actual monsters and character coordenades so the map can use them to render.

DR05. After the character is created, the database shall save the character's own story and description so the AI image generator can use that description to make his icon and epic scenes images. Character description is conformed by: race characteristics, role characteristics, abilities, age and clothes.

3.6. Design Constraints

As our project relies on various AI tools for different aspects, as it grows, the number of prompts will increase. Consequently, we will eventually need to start paying for the use of these AI tools.

The project will be deployed in google cloud according to the course route. The hardware limitations will be the google servers' limitations (not known already).

4. Video

https://github.com/QuitoTactico/DnD-AI/assets/99926526/99ad7610-7972-40ab-9b66-211375090546

https://www.youtube.com/watch?v=kHyDvGl2Yt0

5. Project Management

5.1. Project (Backlog)

https://github.com/users/QuitoTactico/projects/1

5.2. Weekly Meetings

https://github.com/QuitoTactico/DnD-AI/wiki/Weekly-Meetings

5.3. Report Retrospective

  • What should we continue to do (best practices)?

Esteban: We divided the work in a great manner, we were strong as a group, participative and proactive. It's the best group i've had in a long time.

Miguel: We had a really good work flow having reunions every week so we were always knowing what to do.

Sebastián: I'm very happy about our interactions and cooperation while making the First Deliverable, because the three of us where very involved in every part and everyone is very open to help and resolve the problem. Also we reviewed each other's work constantly so we could give feedback and make sure everything was alright.

  • What should we start doing (process improvements)?

Esteban: Start documentating maaany many days before the deliverable, we will not have always the same free time, it's better to feel secure.

Miguel: Since we are going to start to code more, I think the reunions should be longer planning carefully what the next steps in the implementations will be.

Sebastián: In the next sprints we should communicate a lot better and distribute the files separately, in order to be able to don't commit errors while merging the branches in the github.

  • What should we stop doing (process problems and bottlenecks)?

Esteban: Improve our critic reading and comprehension. I'll probably ask more things to the teacher to be sure about some points of the deliverable (sorry for that XD). This way we don't have to understand what does the point of the deliverable is really trying to tell us through debates and some luck. Also improving our english talking (the accent and pronunciation is fine but maybe not the fluidity) and writing (mostly the redacting and use of logic connectors between ideas). I'm not so sure about some of our answers yet, but we'll see. I hope it went well for us.

Miguel: This assignment we split the work a lot but from now on we well work more on everything and help more each other.

Sebastián: We should do a little bit of everything from now on, so everyone can learn to make everything that takes place in a web development.

5.4. Class Assignments

https://github.com/QuitoTactico/DnD-AI/wiki/Class-Activities,-Diagrams-and-Models