Vision Statement - ljackl/BubbleTrouble GitHub Wiki
Project Vision
Executive Summary
Our vision is to create a faithful re-mastering of the classic Miniclip game Bubble Trouble (See: https://www.miniclip.com/games/bubble-trouble/en/). Bubble Trouble Remastered will be a light casual 2D bubble shooter type game that aims to entertain casual gamers of all ages.
The Product
Scope/initial requirements
Bubble Trouble is a 2D bubble shooter type game. You and optionally one other play have to shoot randomly spawning bubbles and upon being shot will split into two more bubbles and so on until the bubble is gone. If a bubble hits a player they lose. The aim is to get as many points and last as long as possible.
- 1 player
- Controller mapping ability
- Avatar customization
- High score saving
- New graphics & sounds
- Local Multiplayer
- Player can save or play with someone online (wish list feature)
- Cross-platform
Use Case Diagram
UI Flow Diagram
Initial architecture
Bubble Trouble Remastered will be a native cross platform application.
The main alternative architecture considered was a web based application. This however was decided against due to a lack of experience in WebGL or other web based frameworks for game development. Web based would also mean that the application would need to be played online.
What problem does the product solve?
Adobe Flash is a dying and insecure platform, Bubble Trouble Remastered will be a remastered version of the original game as native application that won't require flash and will be cross-platform. Bubble Trouble Remastered is also playable offline unlike the original which requires the player to be online.
Target Group
As time goes on there will be less and less browser support for Adobe Flash. This will lead to many casual gamers, notable high school kids slacking off in class, no longer being able to enjoy classic Miniclip games. Bubble Trouble Remastered is aimed at these demographics, namely casual gamers of all ages who enjoy simple and entertain mini games.
The Project
Team Makeup and Resources
| Name | Number | Role | Hours Per Week |
|---|---|---|---|
| Patrick Kelley | 101082724 | Team leader | 04:00 - 06:00 |
| Sarah Howarth | 101265321 | Product Owner | 04:00 - 06:00 |
| Jack Howarth-Green | 101105692 | Team member | 04:00 - 06:00 |
Cost estimation & Funding strategy
| Requirement | Priority | Estimated Hours Required |
|---|---|---|
| Base game loop w/ SFML | 1 | 01:00 |
| Updated graphics/sound | 1 | 08:00 |
| Basic 1 player play | 1 | 24:00 |
| Save/view high-score | 2 | 04:00 |
| Avatar customization | 3 | 08:00 |
| Local multiplayer | 4 | 24:00 |
| Controller mapping | 5 | 02:00 |
| Cross-platform | 6 | 02:00 |
| Online multiplayer | 7 | 32:00 |
Assumptions
- Will use C++ as the programming language
- Will use Simple and Fast Multimedia Library (SFML)
- Will need new graphics
- Will need new sounds
Release plan
The project schedule showing number of iterations, their durations, and expected release dates. May use a high-level Gantt chart.
- Week 7
- Base project setup (game loop etc)
- Wiki pages completed:
- Features and Functionality
- Wiki pages created:
- Issues and Bugs
- Ideas and Extensions
- List of Files
- Project Planning
- Week 8
- Wiki pages completed:
- Ideas and Extensions
- Project Planning
- Wiki pages completed:
- Week 9
- Major development on game completed
- Base game requirements completed
- Client approval
- Major development on game completed
- Week 10
- Testing
- Unit testing of all features completed
- Addition of Wish list features
- If time is identified wish list features can be developed on
- Testing
- Week 11
- Final testing on game completed
- Ensure the addition of wish list features has created no bugs
- Deployment of game
- Game is ready to be released
- Final testing on game completed
Risks
A list of the critical project risks, mitigation strategies, and contingency plans.
| Risk | Probability | Mitigation Strategy |
|---|---|---|
| Going over scheduler | 70% | Team member |
| Lack of weekly resources | 60% | Ensure communication across the whole team |
| Lack of game resources | 50% | Purchase or source free game assets |
| Clashes with other classes | 30% | Ensure communication and organization across whole team |
Software development process
The software development we have chosen to go with is a Waterfall Model, as we are making a game the development process is altered slightly but this proves the most advantageous approach to take for our solution and is going to show the least risks meetings wise.
Communication Plan & Project Tools
Communication Tools
- Slack (for inter-business communication)
- Trello (task planning)
- Toggl (time management)
- Email (formal communication)
Development Tools
- GitHub (repository and artifact management)
- CLion (C++ IDE on Linux)
- Visual Studios 2015 (C++ IDE on Windows)
Communication Guidelines
- Regularly check slack for communications
- Update the Trello board in the moment
- Diligently use Toggl to log hours
Business Goals
How is the product going to benefit the company?
The benefits for us is having a non-flash Bubble Trouble that we can enjoy ourselves, agile/collaboration development experience and finally code development experience.
What are the business goals?
Bubble Trouble Remastered is going to be released free of charge, so the aim for our business at this stage is one of gathering exposure. Once we have a sizable fan-base, more lucrative projects can be undertaken. Regardless for now this venture's goals are to branch into new demographics and the casual gaming market.
Furthermore, another important goal for the business if for the team to gain experience in programming and working collaboratively as a team using a variety of tools.