-
Notifications
You must be signed in to change notification settings - Fork 0
Software Requirements Specification
This Software Requirements Specification (SRS) describes all specifications for the application "Decksterous". It includes an overview of this project and its vision, detailed information about the planned features and boundary conditions of the development process.
The game is going to be realized as a Web application.
Planned Subsystems are:
- Account System:
Users can create accounts so sessions can be connected to a person as well as join requests. User data must be stored alongside the posting data. - Storing Data:
User data for accounts and possibly profiles have to be stored. The data storage will form the foundation for the visualization, account system, search and gameplay feature. - Game Lobbys:
For players to find and join a game, there is a lobby system. Every possible game will be listed. - Authentication Page:
The authentication page is our initial landing page for new users. There is an option to signup and sign in, as well as reset your forgotten password. It contains only minimal information to not confuse any user. Any navigation to unauthorized sites will lead to the redirection of this page. - Navigation Page:
This is a collection of more subsystem/-pages for users to easily navigate to. It contains a sorted and grouped navigation menu on the left-hand side of the screen. - Profile Page:
All information about a user itself is displayed here. This contains level, ranking, inventory/items, etc.
Title | Date | Publishing organization |
---|---|---|
Decksterous Blog | 06.04.2023 | Decksterous |
GitHub | 06.04.2023 | Decksterous |
Software Requirements Specification | 06.04.2023 | Decksterous |
Create new Decks (Use-Case) | 06.04.2023 | Decksterous |
Trade Items (Use-Case) | 06.04.2023 | Decksterous |
Invite Friend (Use-Case) | 06.04.2023 | Decksterous |
Show Rankings (Use-Case) | 10.06.2023 | Decksterous |
Buy Shop Items (Use-Case) | 10.06.2023 | Decksterous |
The following chapter provides an overview of this project with a vision and Overall Use Case Diagram.
Our idea is to make a battle and collection card game with fully customisable rules. Players will be able to challenge others and compete against them in different game modes. Before a battle, players can pick their cards for their deck to play with. Each game can have different rules that are even customisable by players themselves. In certain modes it is even possible to lose cards permanently, so choose wisely with what cards you want to play! There will also be an option to upgrade your cards.
Decksterous is a web application realized with Node.js as a backend service. It will be powered with Express.js for web capability (like HTTP) and Socket.io for WebSocket handling. We are going to use MariaDB as our database for all data that needs to be stored.
- Node.js which will be powered by:
- Express.js for web capability
- Socket.io for WebSocket handling
- Seqeuelize as ORM (Object Relation Model) adapter for database connection
- JWT (JSON Web Token) for authentication
- MariaDB for storing data
The frontend is going to be designed in TypeScript with the Angular and Material framework. The whole art design of our game will be created with the help of an image generation AI such as Stable Diffusion. Our gameplay will be run with Three.js as a renderer.
- TypeScript with:
- Angular framework
- Material Design framework
- Socket.IO Client for WebSocket
Two members of our team use IntelliJ and one uses Visual Studio Code as their IDE.
- IntelliJ
- Visual Studio Code
For our project we make use of GitHub for version control and YouTrack for time tracking.
- YouTrack
- GitHub
- Discord
For code formatting we use Prettier for a standard format style.
- tbd
This chapter (Requirements Specification) delivers more details about the specific requirements in terms of functionality, usability and design parameters.
This section will explain the different use cases, you could see in the Use Case Diagram, and their functionality.
Until December we plan to implement:
- 3.1.1 Login & Account
- 3.1.2 Picking cards for your deck
- 3.1.3 Challenging other players
- 3.1.4 Competing in tournaments
- 3.1.5 Levelling up
- 3.1.6 Unlocking achievements
Our first milestone is that everyone can log in or if they have no account yet, can register. After that, we need to make sure every player has all unlocked cards available to select.
Since the player has their cards available, they should be able to create different decks with these cards.
Once the deck is created, there will be an option to challenge other players. It will be a round based 1v1 game, where each player can choose his actions (e.g. play a card, attack with an already played card, ...)
There is a tournament function planned, where players can get rewards for competing and especially placing well.
The possibility to level up your cards is planned, but we are not sure yet how this will be implemented.
There will be achievements to unlock through playing the game.
We plan on designing the user interface as intuitive and self-explanatory as possible to make the user feel as comfortable as possible using the game. Another big point is the fun factor, which should be always given.
We want to implement a web app with familiar designs and functions. This way users can interact in familiar ways with the application without having to learn new interfaces. The plan is to make everything as easy as possible for the players.
The server should be available 95% of the time. This also means we have to figure out the "rush hours" of our game because the downtime of the server is only tolerable when as few as possible players want to play.
Our goal is that we have no loss of any data. This is important so that the game sessions can carry on, even after one player disconnects.
The system should be able to manage thousands of requests. It should be possible to register as many players as necessary as well.
To provide the best performance we aim to keep the response time as low as possible, which will make the user experience much better. This is given because we only put out requests if we need a component, so nothing gets loaded unnecessarily.
We are going to write the code by using all of the most common clean code standards. For example, we will name our variables and methods by their functionalities. This will keep the code easy to read for everyone and make further development much easier. Our code formatting is going to be handled by 'Prettier', which is a tool that allows all developers to have the same formatting.
We are trying to provide a modern and easy-to-handle design for the UI as well as for the architecture of our application. All functionalities will be kept as modular as possible, to achieve that goal.
We don't have any purchased components yet (tbd). If there will be purchased components in the future we will list them here ( e.g Card packs).
The User interfaces which are going to be implemented are:
- Login - page to log in
- Register - form to signup
- Forgot password - form to reset a forgotten password
- Dashboard - summary of many different things, such as short user information, last games played etc.
- Profile - contains all player information such as level, ranking, inventory/items
- Friend List - lists all friends of a player
- Lobbies - lists all available game lobbies a player can join, as well as create a new lobby
- Market - a marketplace for players to exchange items
- Story - this page is for single-player games
- Settings - shows different settings (page display etc.)
The development will follow the common clean code standards and naming conventions.
The Team Members are:
- Mats Fischer
- Benedikt Müll
- Oliver Saar