Skip to content

Latest commit

 

History

History
72 lines (61 loc) · 7.81 KB

product-proposal.md

File metadata and controls

72 lines (61 loc) · 7.81 KB

Product Proposal Template

1. Title Page

  • Product Name: Blink
  • Proposal Prepared By: Carson Smith
  • Date: 2/12/2024

2. Executive Summary

  • Brief overview of the product, its purpose, and the value it aims to deliver.
    Blink is a P5.js horror game that utilizes eye blinking recognition to create an immersive and suspenseful experience for players. Eye-blinking will occasionally cause something unpredictable to happen that may help, hinder, or frighten the player. Adding eye-blinking as a form of involuntary interaction with the game environment provides a unique experience for players.

3. Product Vision

  • Purpose of the Product: Describe what the product is and its intended use.
    It is a short replayable horror game that uses the keyboard to control the player's character and eye-blinking input to trigger random events. It is intended to be simultaneously enjoyable and frightening.
  • Target Audience: Identify who will use the product and why.
    Horror lovers and gamers interested in trying a unique interactive experience.
  • Long-term Vision: Where do you see the product going in the future?
    We see the game having all core features by the time of the assignment deadline. After the semester is over, additional features may be added if the developers have continued passion for the project, however, it is not planned.

4. Product Value

  • Benefits: Detail the key benefits of the product for users and stakeholders.
    Our game benefits from its fresh and unique gameplay, high immersion, and it's ease of access through the web.
  • Cost Analysis: Provide an overview of the estimated costs to develop and maintain the product, both financially and in time and effort.
    Our product is planned to have no development or maintenance costs. We plan on using free assets and hosting; however, we may buy a domain name to possess a more unique and memorable URL. Each of our 10 members is expected to put in effort towards our goals for each weekly sprint leading up to the end of the semester.
  • Value Proposition: Explain how the benefits of the product outweigh the costs, including potential ROI.
    The amount of time and effort that is required is worth spending to create a unique and immersive game.

5. Product Creation Outline

  • Design Overview: Outline the basic design of the product, including features and functionalities.
    The game will consist of a procedurally generated map that the character can move through and interact with using keyboard input from the player. Eye blinking recognition will be used as a form of involuntary input to trigger random events. Unexpected enemy spawns and environment changes will evoke fear and provide a challenge for the player.
  • Development Plan: Step-by-step plan for the development phase, including key milestones.
    To begin, we will implement core game mechanics, most importantly movement, collision, and eye blinking as a trigger. After implementing the mechanics, they will be tested for bugs and potential improvements. After testing, any necessary changes will be made and retested. Once the core implementation is complete our focus will shift to enhancing the environment through visuals and sound effects. Any remaining time will be put towards additional non-essential features.
  • Development Methodology: Describe the engineering methodology used to manage the project, e.g. Scrum sprints with Kanban, etc.
    We plan on breaking the development of the game into many parts that can be split up amongst team members. Each part will be listed as an issue in the GitHub repository and put into the backlog in the KanBan where the priority will then be decided. In each weekly sprint, we will decide what features are most important and move the ones we want to work on for the week in the ready section in our KanBan. When an issue is complete it will be reviewed by two team members before the issue is closed.
  • Resource Requirements: List the resources needed, including personnel, technology, and materials.
    GitHub, art and sound assets, eye-tracking technology, and developers with Javascript experience

6. Quality and Evaluation

  • Quality Standards: Define the standards and benchmarks for the product’s quality.
    Accurate eye-blinking recognition, gameplay that is balanced and immersive, and an eerie environment
  • Testing Procedures: Describe how the product will be tested throughout development, including plans for TDD, regression testing, and system testing.
    The game will be playtested by developers with the implementation of each feature with occasional playtesting from outside players.
  • Evaluation Metrics: Outline how you will measure the product’s success against its objectives.
    Player reviews and total time spent playing amongst players.

7. Deployment Plans

  • Automation and Mechanisms: Describe how the product will be provided to users, including automated CI/CD plans, release mechanisms, release quality management, user experience monitoring
    The product will be available to the users through the web on a static web page. We will use GitHub actions to test each of our deployments. Unexpected issues experienced by players will be logged in a database.
  • Production Timeline: Provide a release timeline for milestone deployments from initial release to final product.
    Our expected timeline is to have the alpha build 8 weeks before the assignment's deadline, the beta build 4 weeks before the deadline, and the remaining time will be used for bug fixing and minor tweaks and features.
  • User Training: Describe how users will be trained to use the product, if necessary.
    The users will have access to a short tutorial and a sheet describing the controls and gameplay.
  • Marketing and Distribution Strategy: Outline how the product will be marketed and provided to your target audience.
    Our game will be marketed to horror gaming enthusiasts and will be advertised through word-of-mouth.
  • Risk Management: Identify potential deployment risks and mitigation strategies.
    One risk is that the eye-tracking technology could be unreliable or could be uncomfortable for players. If this is the case, we will look into other immersive input methods. We also need to make sure that our game maintains its suspenseful gameplay and doesn't become predictable. This will be difficult since as developers it is easier to predict what will happen. We will need to get players who have no relation to the game to play test and give feedback.

8. Maintenance Plans

  • Defects: Describe how discovered post-deployment defects will be addressed.
    Bugs will be detected and reported by the community and will then be fixed, reviewed, and deployed.
  • Evolution: Describe how evolving long-term use and maintenance of the product, if planned, will be managed, including plans for future versions.
    After the semester is over, any additions to the game will be done out of continued passion for the project by developers but it is not planned. It will continue to be managed the same way but most likely at a smaller scale since all developers may not want to continue. Additions could include bug fixes, new mechanics, or increased accessibility.

9. Conclusion

  • Summarize the proposal and reiterate the value and feasibility of the product.
    Blink is an immersive horror game that has a lot of potential due to its uniqueness. It experiments with eye blinking recognition as a form of involuntary input which will trigger random events intended to keep the game unpredictable. These unexpected events keep the game fresh when replayed and evoke fear in the player.

10. Appendices

  • Any supporting documents, such as detailed technical specifications, market research data, etc.

11. References

  • Cite any external sources referenced in your proposal.