The project, "Subterranean Script," is my innovative approach to the text-based, choice-driven adventure genre, deeply rooted in the spirit of iconic Choose-Your-Own-Adventure books. It adds a unique twist by plunging players into a sprawling, enigmatic dungeon world, with their destiny dictated by the doors they elect to pass through.
Drawing inspiration from the rich tradition of Dungeons & Dragons, Subterranean Script incorporates a series of well-established rules and mechanics from the legendary tabletop game. This blend of elements aims to enrich the gameplay experience, inviting players to engage with a complex web of decisions that mirror a D&D campaign's depth and dynamism.
At its core, Subterranean Script aims to capture players with its layered, immersive narrative and dynamic choice-driven gameplay, challenging their decision-making skills at every turn. It is meticulously crafted for those who appreciate the immersive allure of traditional text-based games but crave an additional level of interactive mystery and suspense, reminiscent of a well-rounded D&D adventure.
As a First Time user, I want to easily understand the main concept of the game and its gameplay mechanics.
As a First Time user, I want to be able to effortlessly navigate through the game commands and decision-making processes.
As a First Time user, I want to experience a compelling introduction to the game world and its narrative.
As a Returning user, I want to find and explore new paths, narratives, and experiences within the game that deepen my immersion.
As a Returning user, I want to see the consequences of my previous choices and understand how they shape my current gameplay.
As a Returning user, I want the ability to reset the game or make different decisions, enabling varied experiences and outcomes.
As a Frequent user, I want to continue my ongoing adventure, with the game storing my progress.
As a Frequent user, I want to see if there are any new updates or developments in the game’s narrative or mechanics.
As a Frequent user, I want to share my gaming experience with others or compare my decisions and game outcomes with them.
As a Command Line Application Owner, I want to offer an intuitive and immersive text-based adventure game that engages users and draws them into its narrative world.
As a Command Line Application Owner, I want to notify users of new game content or changes, keeping them interested and up-to-date.
As a Command Line Application Owner, I want to gather user feedback and experiences, which can be used to refine and expand the game.
As a Command Line Application Owner, I want to build a community of engaged players who are invested in the game's world and narrative.
As a Command Line Application Owner, I want to be able to showcase the creative team behind the game, to promote their work and foster a deeper connection with the player base.
- Intro to game.
- Player can pick up weapon.
- Player can choose a door to progress.
- Player can fight an enemy.
- Help text to educate the player.
- Languages: Python
- Library: Colorma.
- More dyanmic flavour text.
- Defend battle option so player can stay in the pocket for a counter-attack.
- Entities having special attack based off their entiity_type
- Longer game with more choices.
- Sound such as music and attack sounds.
- Update to 3.10 so switch statements are available.
- Languages: Python.
- Library: PyAudio.
- Ability to save.
- Adaptive difficulty levels.
- Player choices affect other people's games.
- Social mnedia presense.
- Monetisation.
- Languages: Python.
Touchpoints - Command Line Interface
Whilst the player has the choice of left and right, this choice will be populated by a dictionary. This design will help for expansion in later scripts. In the first sprint I plan to have the first room and then a choice to enter the second room, but this diagram is an example of how it would be in the future.
Colours will be based on the Colorma library. They will be used to add to the atmosphere of the game.
- Codeanywhere This is was my IDE for the project.
- CodePen I used this to test code outside of Codeanywhere so that I didn't use up hours unnecessarily.
- Git Used to commit and push code to Github.
- Github This was used as a remote repository.
- Heroku I used this to deploy my app.
- PEP - Python This was used to learn more about PEP-8.
- Python Tutor Used to test logic of my code.
- Conventional Commits Used to learn and stick to a conventional commit framework.
- Photoshop Used for readme images.
- Text to ASCII Used to create start screen ASCII.
The Start Screen State serves as the introduction and entry point to the text-based adventure game "Subterranean Script." It's a combination of two phases that guide the player into the game world.
Initialisation Phase (handle_initialise method): This part displays the game's visually engaging ASCII title and presents a welcome message, providing players with a glimpse into the game's mysterious dungeon environment. It hints at the choice-driven nature of the game, inspiring comparisons to classic Choose-Your-Own-Adventure books and Dungeons & Dragons. It also informs the player that they can whisper 'help' at any time to view a list of commands. After presenting this information, the game transitions to the start state.
Start State (handle_start_state method): This state handles the next stage where the player is prompted to enter the game. The player must type 'enter' to proceed, reinforcing the thematic atmosphere of stepping into a dark and unknown world. If the input is valid, a foreboding message wishing the player "Good luck" is displayed, and the game moves to the character creation state. If the player enters anything other than 'enter,' a ValueError is raised, and the shadow-themed error message is printed to guide the player.
Together, these two stages form a cohesive starting experience, introducing players to the tone, setting, and mechanics of the game. The Start Screen State not only welcomes players but also challenges them to take the first step into an adventure filled with choices, mysteries, and uncertainties.
The Name Input State is a critical stage in the game where the player is prompted to name their character. This state provides an opportunity for personalisation, setting the tone for the player's relationship with their character.
Valid Name Input: The player must enter a name consisting solely of alphabetic characters, not exceeding 20 characters, and not being 'exit'. If these conditions are met, the character's name is assigned, followed by a reflective print statement that appears to come from the character itself. The game then proceeds to roll and print the character's stats before transitioning to the room pickup state.
Invalid Name Input: If the player's input contains non-alphabetic characters or exceeds 20 characters, a ValueError is raised with an in-game themed error message to guide the player towards a valid name.
By weaving game mechanics with storytelling elements, the Name Input State establishes a connection between the player and their character while maintaining the immersive atmosphere of the game. It ensures that the character naming process is not only a functional requirement but also a meaningful step in the player's journey within the game world.
The Pick Up Object State manages the gameplay scenario when a player encounters an object they can collect. In this state, the player is faced with the choice to either 'pick up' or 'leave' the object.
If the player chooses to 'pick up': The method processes a series of actions, such as making the object part of the character's stats and marking it as picked up. An emotional description is printed to engage the player, and the game transitions to the room door choice state.
If the player decides to 'leave': A message is printed reflecting the character's resolve, and the game moves directly to the room door choice state.
For any other input: A ValueError is raised, accompanied by an error message guiding the player to make a valid choice.
This state intricately ties the player's decisions with the game's mechanics and storytelling, enhancing immersion and strategic planning.
The Room Door Choice State represents a crucial juncture in the game where players are faced with the decision to choose between two doors: 'left' or 'right'. This moment encapsulates the essence of choice-driven gameplay, embodying the adventure's core mechanic of branching paths and the unknown consequences that lie beyond each decision.
Making a Choice: The player's input is processed, expected to be either 'left' or 'right'. The chosen direction determines the room they will discover, randomly selected from a predefined set of dungeon areas.
Discovering a Room: Upon making a valid choice, the player's chosen door opens to reveal a room with a specific name and description. This provides flavor text to the scenario, immersing the player in the mysterious dungeon environment and setting the stage for the next challenge.
Transition to the Fight State: The door choice state also includes a prompt that segues into the fight state, the next phase of gameplay where players must confront challenges within the room they've discovered.
Error Handling: If the player's input is anything other than 'left' or 'right', a ValueError is raised, and an atmospheric error message is printed to guide the player. This guidance, framed within the game's shadowy and mystical theme, maintains immersion even in the face of an incorrect choice.
The Room Door Choice State serves as a metaphorical crossroads within "Subterranean Script." It challenges players to make decisions without knowing what lies ahead, echoing the unpredictable and mysterious nature of the game's dungeon environment. By integrating thematic storytelling, user choice, and a transition to further gameplay challenges, this state effectively builds tension and engagement, keeping players invested in their adventure.
The Battle State within "Subterranean Script" is an intense and dynamic part of the game that pits the player's character against an enemy in a turn-based combat scenario. This state encapsulates the heart-pounding action of the dungeon experience, providing an engaging gameplay loop that challenges the player's decision-making and strategy.
Initialisation: A Fight object is created, and the initiative (who attacks first) is determined between the player and the enemy. Dodge flags are set to False at the beginning, meaning no one is prepared to dodge.
Turn-Based Combat: The battle ensues in turns until either the player or the enemy's hit points reach 0.
Player's Turn: If the player is the attacker, they are prompted to choose between 'quick' attack, 'heavy' attack, or 'dodge'. Each choice has implications for the attack's success, damage dealt, and the likelihood of dodging an incoming attack. Enemy's Turn: If the enemy is the attacker, a random choice is made between the same set of actions ('quick', 'heavy', 'dodge'), and the chosen action is executed. Attack Mechanics: The attack method within the Fight class is called to resolve the combat action. The attack's success and damage depend on the type of attack and whether the defender is dodging.
Dodge Mechanics: Both players and enemies can choose to dodge an attack. If successful, this move prevents damage in the following attack. Dodge flags are used to track whether a character is prepared to dodge.
Switching Turns: After each turn, the attacker and defender switch roles, and the dodge flags are reset.
Resolution and Transitions: When the battle ends, victory or defeat messages are printed based on the outcome. Thematic flavor text conveys the aftermath of the battle, enhancing immersion.
Victory: If the enemy is defeated, a victory message emphasises the intensity of the battle and hints at the mysterious nature of the dungeon. Defeat: If the player is defeated, a defeat message conveys the dramatic end and the triumph of the enemy. Game Reset: After the fight concludes, the game resets, and the player is transitioned back to the character creation state, allowing them to start anew.
The Battle State's complexity and depth lie in the interplay between choice and randomness, strategy, and adaptability. By weaving together mechanics of attack, dodge, and turn-based dynamics, this state creates a thrilling and unpredictable combat experience. The detailed feedback and atmospheric text further deepen the immersion, making each battle a memorable and integral part of the overall dungeon adventure.
Within "Subterranean Script," the player might need guidance on their available options or access to certain universal commands that are applicable across different game states. These functionalities are managed by two distinct methods: print_help and handle_universal_commands.
- Help State (print_help method) The Help State provides contextual assistance to players, offering tailored guidance based on the current and previous states of the game.
Basic Structure: The method begins with a thematic introduction, signaling that the player is seeking assistance from the shadows of the dungeon. It then provides general commands like 'Return' and 'Exit'. Contextual Guidance: Depending on the player's location or situation within the game, specific commands and information are provided. These might include navigation options, combat actions, character creation instructions, etc. Return to Gameplay: The help text encourages players to 'Return' to resume their previous action or to explore additional options pertinent to their current situation. The help text effectively serves as a dynamic guide, adjusting its content to match the player's needs at any given point in the game.
- Universal Commands State (handle_universal_commands method) The Universal Commands State handles common commands that can be invoked in various game states, adding consistency and flexibility to the player's control scheme. The recognised universal commands include:
- 'help': Transitions to the Help State, where players receive information on available commands based on their current situation.
- 'stats': If the player's name has been initialised, this command displays the character's statistics and provides the option to 'return' to the previous state.
- 'exit': Allows the player to exit the game with a thematic farewell message.
- 'return': Enables the player to return to the previous state from the 'help' or 'stats' screens, ensuring a smooth navigation experience.
These universal commands add an extra layer of accessibility and usability, allowing players to call upon essential functions from nearly any point in the game.
The scalability of the project is largely derived from the thoughtful use of data structures, such as dictionaries to contain entities like enemies and dungeon areas, and classes to represent characters and enemies. By organising data into well-defined structures, it will easier to manage, expand, and modify various aspects of the game, as detailed below:
-
Integration with Classes: My project's use of classes for character and enemy modelling complements the dictionary-based approach. Classes encapsulate behaviours, making it easy for me to define how characters interact with objects or enemies. By combining classes with rich data structures, I've set the project to offer seamless integration of content and logic, making the system adaptable and scalable.
-
Making Enemies Feel Different: The current structure of the enemy dictionary sets the stage for customisation, allowing for further differentiation among enemies. Here's how I can accomplish this:
Behavioural Patterns: By implementing different AI behaviours or attack patterns for various enemy types, I can create a more diversified combat experience. This can be done by adding methods to the enemy class or adding attributes to the dictionary that describe specific actions or responses in given situations.
Visual Representation: I can associate different sprites or visual effects with different enemies. By linking an image or visual identifier to each enemy in the dictionary, I can render unique appearances for each creature quickly.
Sound Effects: Integrating unique sounds for different enemies can enhance the immersive experience. Associating specific audio files or sound effects with particular enemies in the dictionary can achieve this.
Special Abilities: Introducing unique abilities or special attacks for specific enemies can make encounters more engaging. Adding an "abilities" list to the enemy dictionaries and implementing corresponding methods in the enemy classes will allow for this differentiation.
-
Room Definition: Another use of dictionaries can be found in defining the dungeon's rooms within my project. I've structured the ROOMS dictionary in layers, with each room possessing specific attributes like "name," "description," and "prompt." This layered approach enables me to add new rooms or modify existing ones easily, allowing for the dynamic scaling of the dungeon as the game evolves.
-
Object Management: I've also used dictionaries to manage objects that can be found in different layers of the dungeon. These objects have specific attributes like "name" and "description," and even stat changes, making them vital to the gameplay. By organising these objects within dictionaries, I've made it simple to add new items or modify existing ones without altering the core game code.
- Capitals would break the code - I added the
.lower()method so that errors aren't raised if the player types in capitals. - While loop when starting game - Start screen was stuck in an infinite loop due to being in
While True:. - ASCII escape sequence - I added more characters to ensure the 'escape sequence' error wasn't displayed, whilst maintaing the shape of the text.
- Ensure player can't enter stat state until a certain point - Add logic so that the
statstate can't be entered. - Inifnite Loop - Conditional was looking for words with uppercase first letters, but the input was being converted to lowercase so there was a loop. Changing these words to be lowercase fixed this.
- Flavour text appearing after user input - Moved the order of the flavour text.
- Weapon wasn't being randomly selected -
weapon_choicewas getting applied in theget_prompt method, so I changed it to being handled in thehandle_room_pickupmethod. - Weapon generated multiple times - Weapon was being generated multiple times if the user went back to the
ROOM_PICKUP_FIRST_LAYER, so I changed it to only generate a weapon from the dictionary randomly if theself.object.choicehadn't been made. - Unreachable and redundant code - Code was unreachable and actually redundant, so I removed it.
- Unnecessary code in regards to Stat Rolling - Removed unnecessary assignment of rolled stats. The method now directly modifies the character's attributes.
- Handle invalid room pickup input - Added error handling in the
handle_room_pickupmethod to gracefully handle situations when the user enters an invalid choice. Instead of raising an exception, it now prints a meaningful error message, guiding the user to make a valid choice. - Weapon assignment in room pickup - Removed the unnecessary use of
selfin object choice during room pickup handling. The weapon assignment now directly uses the randomly chosen object, ensuring that the character's weapon is correctly assigned. - Stat changes not being applied - Stat changes from picking up objects were printing initially but weren't actually getting applied, so printing stats again wouldn't show them. Added attribute to ensure this is something that can be tracked throughout the game.
- Redunant .lower method - The
.lower()method is being handled elsewhere so having the method elsewhere for theuser_inputwas redundant. - Add try/except block to room choice - Added a try/except block to handle user inputs.
- Printed lines above 24 - I removed some of the flavour text so that the printed lines didn't exceed 24 lines.
- Varied naming convention - I had
typeinstead ofentity_type, in my enemies.py file. I added entity_ so that the naming convention is consistent. - Enemies spawning incorrectly due to room choice handling - Replaced
room_choicewithroom_choice_name' androom_choice_dictto correctly handle the room selection. Also modified thespecific_enemy` retrieval to correctly access the specific enemy according to the current room. - Update battle handling logic - Add appropriate code so if an enemy doesn't already exist, it generates a new one based on the current room's name. Then, it initiates or continues the battle by calling the handle_battle method with the user's input, player character, and the enemy instance.
- Ensure battle logic loops based on user input - The battle logic would play out until one of the entities died, so I added user_input to be within the correct logic so that each phase of the battle waits for
user_input. - Unwanted user prompt in transition to fight state - Modified the main loop in the
class Gameto only prompt for user input when required based on the current game state. This fixes an issue where an extra newline was being printed when transitioning to the fight state, requiring the user to press enter before the fight started. Now, the fight prompt is printed directly to the console without requiring additional input from the user. - Inf loop in battle func by resetting userinput - The infinite loop issue in the battle function was caused by the persistence of the
user_inputthroughout the loop iterations. If the player chose to dodge once, thedefender_dodgingwould always evaluate toTruefor all subsequent enemy turns. - Entities health being double printing - Moved the print statement for player and enemy HP outside the nested conditionals in the
handle_battlemethod. This ensures that the HP values are printed only once per turn, correcting the previous behavior where they were printed twice when the dodge command was input. - Missing parenthesis in battle func - A missing parenthesis was found in the handle_battle function, which led to a syntax error.
- Ensure proper handling of dodging - When dodge was typed the player would sometimes attack so I added flag to ensure this doesn't happen.
- Ensure object choice persits once chosen - In the original code, the object choice was randomly selected but not consistently referenced throughout the function, leading to potential inconsistencies in the user experience.
- Ensure reference to enemy is correct in battle func - I was referencing the
enemy_instancein my code instead ofenemy. - Ensure player doesn't get stuck in loop - If the user went into the help state and then into the stat state and typed return they would go back to the help state but then return would move them back to the stat state, and so on. So I changed the way general game states states are handled to stop this from happening.
I used the PEP-8 Validator to validate the Python code used in this application. Below you can see the success of each file in the project.
- Expected -
INITIALISEstate is expected to load when the user opens the app, with theGAME_STARTstate (user input) below it. - Testing - Tested the feature by loading the app.
- Result - The feature responded as expected.
- Expected - Typing Enter is expected to transition to the
CHARACTER_CREATIONstate. Typing anything other than Enter will give them a prompt telling them what to do and gives them the previous prompt afterwards. - Testing - Tested the feature by typing Enter. Capitlisation doesn't matter due to .lower() method.
- Tested the feature by typing other strings, number & symbols into user input which raise the correct
ValueError. - Result - The feature responded as expected.
- Expected - Typing a string that doesn't exceed 20 characters will proceed to the
ROOM_PICKUP_FIRST_LAYERstate. Typing anything other than a string will throw oneValueErrorand reprint the original prompt and typing a string longer than 20 character will throw a separateValueError. - Testing - Tested the feature by typing a string under 20 character which transitioned to the correct state. Capitlisation doesn't matter due to .lower() method.
- Tested the feature by typing in anything other than a string which raises the correct
ValueErrorand reprints the state's prompt. - Tested the feature by typing in a string longer than 20 characters which raises the correctValueErrorand reprints the state's prompt. - Result - The feature responded as expected
- Expected - The user's entered name will get reprinted and their stats will get rolled. A weapon should be randomly selected from a dictionary. The user is then prompted to Pick Up or Leave the weapon. Anything else typing in should raise the correct
ValueErrorand the prompt gets reprinted. If the correct keyword is typed in then it should transition to theROOM_DOOR_CHOICE_FIRST_LAYERstate. - Testing - Tested the feature by typing Pick Up which transitions to the correct state. Capitlisation doesn't matter due to .lower() method.
- Tested the feature by typing Leave which transitions to the correct state. Capitlisation doesn't matter due to .lower() method.
- Tested the feature by typing in anything other than these keywords which raises the correct
ValueErrorand reprints the state's prompt. - Result - The feature responded as expected
- Expected - If the user enters Pick Up the stats will be printed with an update to stats based on the weapon and the correct weapon should be apployed. Leave will print the stats without any stat change. Either choice will then prompt the user to pick between the Left or Right door. Either choice will transition to the
FIGHT_SECOND_LAYERstate. - Testing - Tested the feature by typing Left which transitions to the correct state. Capitlisation doesn't matter due to *.lower() method.
- Tested the feature by typing Right which transitions to the correct state. Capitlisation doesn't matter due to *.lower() method.
- Tested the feature by typing in anything other than these keywords which raises the correct
ValueErrorand reprints the state's prompt. - Result - The feature responded as expected
- Expected - Either choice should pick a room randomly based on a dictionary and based on the room that gets picked an enemy will be randomly spawned from a dictionary of
COMMON_ENEMIES(spawned in any room) orSPECIFIC_ENEMIES. The prompt text should be correctly populated from these random choices and then the user should be prompted to fight after the player's and enemies' HP is correctly printed. The choices are to 'Quick' attack, 'Heavy' attack or 'Dodge'. The player and enemy will take turns, with the enemy randomly choosing the same choices. Damage should be applied to the HP when either entity hits. When either entity reach 0 HP, thehandle_battlemethod should end by printing relevant text and restarting the game, by transitioning back to theCHARACTER_CREATIONstate. - Testing - Tested the feature by typing Dodge and the player correctly holds their move, increasing their AC to hopefully dodge the next attack. This works when the enemy choose Dodge too. Capitlisation doesn't matter due to *.lower() method. - Tested the feature by typing Quick where the player then proceeds to unleash a quick attack. Damage is correctly applied when either entity chooses this attack. Capitlisation doesn't matter due to *.lower() method. - Tested the feature by typing Heavy where the player then proceeds to unleash a heavy attack. Damage is correctly applied when either entity chooses this attack. Capitlisation doesn't matter due to *.lower() method. - Tested the feature by seeing each entity win, where the correct text get's printed based on the users success or defeat. The game then transition correclty.
- Result - The feature responded as expected
- Expected - After the battle is won or lost, the game should clear any changes made in the previous iteration and start from scratch.
- Testing - Tested the feature by typing playing through multiple iterations to make sure anything set in the previous iteration wasn't carried through to the new one.
- Result - The feature responded as expected
- Expected - Help can be typed at almost all points in the game, except during the
handle_battlemethod. It should display relevant information based on the state the user is currently in. - Testing - Tested the feature by typing Help in every possible state, and the relevant commands appear in each state. Capitlisation doesn't matter due to *.lower() method.
- Tested the feature by typing Help in the
handle_battlemethod where it doesn't work. - Result - The feature responded as expected.
- Expected - Typing Stats should display them once the stats have been rolled (After
CHARACTER_CREATIONstate), except during thehandle_battlemethod. It should display the up-to date stats, such as the stat changes from picking up an object. - Testing - Tested the feature by typing Stat in every state where avaliable, and the up-to date stats appear as expected. Capitlisation doesn't matter due to *.lower() method.
- Result - The feature responded as expected.
- Expected - Typing Return while in the
HELPorCHARACTER_STATSstat should return the Layer State that they were originally in. - Testing - Tested the feature by typing Return in from the
HELPandCHARACTER_STATSstate when entering them from all available stats. Capitlisation doesn't matter due to *.lower() method. - Result - The feature responded as expected
First Time Visitor Goals Understanding Gameplay:
- As a First Time user, I want to easily understand the main concept of the game and its gameplay mechanics.
- I believe I have acheived this via the simple inputs and the Help state giving relevant commands throughout the game.
Navigating Commands:
- As a First Time user, I want to be able to effortlessly navigate through the game commands and decision-making processes.
- There are only a few inputs that the user needs to use to navigate through each state, all of which are correctly signposted to the user.
Experiencing Narrative:
- As a First Time user, I want to experience a compelling introduction to the game world and its narrative.
- Through the flavour text, I believe I've created the right tone for the game, and an excellent starting point for an engaging narrative.
Returning Visitor Goals Exploring New Content:
- As a Returning user, I want to find and explore new paths, narratives, and experiences within the game that deepen my immersion.
- There is lots more to do with this but I think the random object, enemy and room choices can keep the game fresh.
Understanding Consequences:
- As a Returning user, I want to see the consequences of my previous choices and understand how they shape my current gameplay.
- Also a lot more to do with this but I have the skeleton laid out. The user can see that their object choice changed their stats and certain decision in the battle will give different results.
Varied Experiences:
- As a Returning user, I want the ability to reset the game or make different decisions, enabling varied experiences and outcomes.
- The game is built to reset whether the player wins the battle or loses. There are further narrative reasons for this which I didn't get a chance to lay out, but again the foundations are there. The plan is to have the user discover bodies in the various rooms which will have various letters from the users name randomly etched on their arm. Giving the idea that they've been at this for a long time.
Frequent Visitor Goals Ongoing Adventure:
- As a Frequent user, I want to continue my ongoing adventure, with the game storing my progress.
- This is something I will need to work on going forwards, and wasn't on the list for sprint 1.
Updates and Developments:
- As a Frequent user, I want to see if there are any new updates or developments in the game’s narrative or mechanics.
- This wasn't going to be possible for sprint 1 but I have an excellent starting point to continue building.
Social Interaction:
- As a Frequent user, I want to share my gaming experience with others or compare my decisions and game outcomes with them.
- The idea here is to have the app on a website with a forum so people can share their experiences. Also wasn't important for sprint 1.
CLI Owner Goals Engaging Gameplay:
- As a Command Line Application Owner, I want to offer an intuitive and immersive text-based adventure game that engages users and draws them into its narrative world.
- Sprint 1 was mostly focused on the code and features, but I believe it achieves this to an extent.
User Notification:
- As a Command Line Application Owner, I want to notify users of new game content or changes, keeping them interested and up-to-date.
- This would also be achieved by the site that I previous mentioned.
Gathering Feedback:
- As a Command Line Application Owner, I want to gather user feedback and experiences, which can be used to refine and expand the game.
- This would need a webiste or a social media presence.
Community Building:
- As a Command Line Application Owner, I want to build a community of engaged players who are invested in the game's world and narrative.
- Outside of the scope of sprint 1 as it's important to build something good first and then the players will be attracted to quality.
Showcasing Creativity:
- As a Command Line Application Owner, I want to be able to showcase the creative team behind the game, to promote their work and foster a deeper connection with the player base.
- Something more achievable with a website and/or social media presence.
Clone a GitHub Repository To make a clone of this repository, follow these steps: Login to your GitHub account.
- Go to the repository by visiting the link: Charlie McGoldrick Github - Subterranean Script Repo.
- Click the "Code" button and then use the copy button next to the link to copy the link.
- In your IDE of choice, open a new terminal and use the following clone command: git clone
https://github.com/CharlieMcGoldrick/ci-ms3-subterranean-script. - You will now have a copy of the repository in you local version.
Forking the GitHub Repository To fork this repository, follow these steps:
- Log in to your GitHub account.
- Go to the repository you want to fork, which is located at: Charlie McGoldrick Github - Subterranean Script Repo.
- In the top-right corner of the repository page, click on the "Fork" button
- GitHub will prompt you to select where you want to fork the repository. Choose your personal account or organization.
- Wait for the forking process to complete. Once it's done, you will be redirected to your forked repository under your GitHub account.
NOTE: Any changes pushed to the main branch automatically show up on the website.
Heroku To host the app, I used Heroku. Follow the steps below for deployment:
- Clone or fork Charlie McGoldrick Github - Subterranean Script Repo.
- Log into your Heroku account.
- Click the New button and then click Create new app.
- Give the app a name, choose your desired region and click the Create app button.
- Navigate to Settings and click Add buildpack.
- Add Python and then Nodejs.
- Navigate to the Deploy tab and choose your Deployment method.
- Find the repository you want to use.
- Choose the correct branch
- Click the Deploy Branch button
NOTE: You might want to turn on Enable Automatic Deploys
- Python Docs Used to learn more about Python.
- Python Docs - Random For help with the random module.
- Python Docs - Exceptions For help with try/except syntax.
- Python Docs - @staticmethod For help with @staticmethod.
- Python Docs - Super For help with super proxy object.
- NumPy For help with NumPy Style Docstrings.
- Colorama For help with Colorama Syntax.
- D&D Inspiration for how to handle stats and rolls.
- Text to ASCII Used to create start screen ASCII.