Authors: Justin Pun, Maximiliano Moran Milian, Ryan Scott, Ethan Noh
- This project is a habit tracker with a gamified element to keep people engaged. The user will choose a Habit-Mon starter to start a journey together, leveling it up with successful habit completion streaks.
- It is interesting to us because it can be difficult to stay engaged with a habit. This additional incentive to collect XP for a Habit-Mon reinforces maintaining habits.
- There are two sections of the program, one where the user has a list of habits, and the other for viewing their Habit-Mon.
- In the habit section the user can view each habit's daily streak, how much XP they have earned from it, and how much XP is available if they have not yet completed it today. This is also where the user would mark a habit as completed for the day.
- In the Habit-Mon viewing section, the user can view their currently selected Habit-Mon and see their attributes. This includes how much XP they need to level up. It will also give a suggested task to complete to gain XP.
- If enough XP is obtained to level up a Habit-Mon, a special menu will appear congratulating the user.
- IDE: Visual Studio Code
- Language: C++
- Tools: CMake, Make, Git, Github, GoogleTest, C++ std::fstream (save data), FTXUI library
(Still Subject to Change and Add more)
- User Inputs
- Initial Setup :
- Starter selection & habit creation
- Daily Execution:
- Task Completion
- Navigation & Management Inputs
- Menu switching, habit management
- Initial Setup :
- System Outputs
- Habit Dashboard :
- Shows habits in progress
- Indicators for completion
- Streak numbers
- Habit Mon Visual :
- Stat block (XP)
- Suggestion for engagement (Habit-mon is hungry for tasks)
- Habit Dashboard :
- Backend Data I/O:
- Data Saving - Writes out to local .txt file to save info
- Data Loading - Loads in .txt file and parses to restore progress and habits
- Core Habit Management
- Habit Creation and Customization
- Task tracking
- Rests
- Habit-Mon System
- Starter Selection
- Xp Engine
- Visual Evolution
- Progression and Rewards
- Consistency
- Streaks
- Level up rewards
- System Architecture
- Data Loading and Saving
- Terminal UI Interface
2. This version of the UML diagram contained most of the essential data points and backend information necessary for the HabitMon project, but it sincerely lacked in which classes depended on which leading to a severe misunderstanding of which classes connect to where. The refactored form in Class Diagram (post-SOLID) helped these severe architecture flaws.
3. Habit-mon has the correct backend information, as well as Habit-manager with Habits connected to it. This was a good early architectural design, but it needed refactoring in our next sprint meeting.
2. Applied the single responsibility principle (SRP) to separate the responsibilities of the `ftxui::Component GetComponent() {}` function in each of the UI classes besides the UI_Controller. It is now separated into the GetComponent function, which returns the fully constructed ftxui component ready to render, and the UnifyComponents function, which prepares the components/elements on the UI page to be ordered in a specific way. This makes it much easier to keep the code organized in preparing the logical order of how the arrow keys should interact with the page (UnifyComponents) and the visual order/effects they have on the terminal (GetComponent).
3. Applied the open/closed principle (OCP) to make it easy to expand the UIPage class, but closed off the modification. We have a pure virtual class UIPage, which all the other separate files containing the page rendering classes inherit from. This makes it simple to overload the GetComponent function to create the custom render behavior for each. This allows us to have a tracking variable under the pointer UIPage in the main UI_Controller class that can house any of the page classes. We can track exactly which page is active. We do not have to hardcode the specific classes into the UI_Controller page for active tracking when a new one is created. This simplifies making new pages.
In order to run our program, you will first need to copy the github repository to your local device. To do this, open your OS's terminal command app (such as Mac's "Terminal"). Once openeed, you can copy and paste the following command into the terminal:
git clone --recursive https://github.com/cs100/final-project-rscot033-mmora272-jpun002-enoh008.git
Which is effectively copying the github repository onto your device.
Wait until that has finished downloading and then go into that folder. That can be done via your file manager application on your device or you can run:
cd final-project-rscot033-mmora272-jpun002-enoh008
to enter the repo folder.
Once you've entered the folder, you can run the following commands:
cmake .
make
./habitmon
BOOM! You will now be met with our terminal based application implemented with a more visually appealing UI that makes it easier to naviagate. You can navigate about the program via your mouse or use the arrow keys.
To properly test the functionality of our program, we made use of googletest. With googletest, we tested all of the backend functionality (such as adding a habit), ensuring that it is all working as intended. In this case, when the user launches our program, they can rest assured that we've thoroughly verified the behaviors of our program and that it will work as expected. All of these tests are stored in a test.cpp file.
As for the GUI, when launching the program, we verify that the UI appears as intended, where there are no unwanted boxes, characters, and other things of that nature. Not only that but as a reinforcement to our backend, our UI should perfectly reflect the expected behaviors, and that is verified but what the UI is displaying. With these two things, the googletest tests ensure that all backend functionality works as intended BEFORE it gets to the UI, and then the UI reflects these expected behaviors and updates the data accordingly as the user makes modifications.