KF4011 System Analysis Group Project Project: Procrastination Station 2 Team members : Josselin Muntzer, Adam Eltarzi, Alfie Graves Adam - 20000343 Introduction This document's purpose is to outline our team's assessment for the module KF4011 Systems Analysis 2021. Our team has closely followed the guidelines we were provided with and this document will follow as such. Code of Conduct Work Ethic All members of the team will be treated with respect at all times, with everyone having an important role to play. We plan to communicate before starting any of the work within the project and divide it equally. We also decided that when we work on areas of the project individually we will finalise our work as a team. When selecting which tasks to complete individually we plan on focusing on the content in which we are most confident, whilst maintaining clarity and understanding with the other team members. If/when there are arguments within the group we will tackle them by having a respectful conversation on why the argument/issue occurred and how it can be resolved. Communication We will use Discord to communicate. This will allow us to easily communicate to each other and share project decisions on a platform which most people here frequently use. We thought discord was also optimal for our project as it saves chat history so we can always reference back any ideas or discussions we have had previously on the project. We are currently planning on meeting Mondays and Fridays, with Fridays being our focus day to work through the project objectives for that week (we plan on using Mondays if there is an overflow of work from the previous week). On these days we plan to meet as an entire group to brief each other on what needs to be completed that day and then split into subgroups if necessary. Source Control We will use GitHub for source control. Progress Tracking - Excel spreadsheet on Google Docs. GitHub Discord Project brainstorm - Basic dungeon style 8-bit game Time wasting app (fake bubble wrap, small puzzle, time based brain games, etc.) Plant checker (when to water, how to help with certain conditions, etc.). Bulk file renamer Sequel to time wasting app Project Skeleton - Dungeons - Dungeon based game - Game starts with a video story of a player getting lost and then trapped in the dungeon. Each room will be built randomly from a set of elements, there will be a total of 9 variations for each element. Time limits for each room? Labyrinth style? If enemies are in game how complex will they be etc? Music sfx 8-bit design - Project Skeleton - Time wasting - App designed that when you open it, it loads a game randomly from a library The games would be designed as stupid mini games to waste time(e.g.: bubble wrap popper, bin toss) Add level of complexity to the games by adding in leader boards or time limits for the games. Project Skeleton - Plant checker - App where u register your plant The app then provides you information on how to keep your plants alive It will notify the user when their plants need to be watered, etc. - Project Skeleton - Bulk file renamer - Removes repeat data Used to tidy up data Time Wasting Web App The objective of this system is to provide the user with a simplistic but engaging experience in order to fill ‘awkward time’ that they have to waste. The system will be made up of a simple web page and a library of 10 mini games that will be randomly selected upon entry to the site, the web app will then cycle through the games until all are played and then give the user the option to recycle the games to see if they can achieve a better score, or waste more time, etc. The design for the system is intended to be simplistic to make it usable for anyone, to achieve this we plan to make the UI simple and easy to understand by limiting the amount of information on the page by limiting it to what is needed. To enforce the simplistic layout of the app we plan on keeping the style simple, by using simple shapes such as circles, squares, etc. and a basic colour scheme that's easy on the eyes. After discussing the matter with our professor and team members, we have decided to progress with the idea of making a sequel to the Time Wasting App. This is due to us already creating a game beforehand and have collected data on this application. Methodology We have chosen the scrum methodology due to how agile and flexible said methodology is.Although the scrum methodology is not ideal for unfamiliar technologies and complex systems, this should not be an issue here, due to our familiarity with this type of system from last semester. Adam Eltarzi has been elected Scrum master(person in charge of keeping everyone as productive as they can be). Josselin Muntzer and Alfie Graves are team members. -Adam Eltarzi (Scrum master) -Josselin Muntzer (Scrum team member) -Alfie Graves( Scrum team member) Ethical approval Our team member Josselin Muntzer has submitted and has gotten approval from the university's website. Requirements After discussing which method of data collection technique we were going to use, we have decided to use the following - Questionnaires (conversational) Research familiar games(Analytical) Watch people play our prototype game (The prequel to this system)(Synthetic) The creation of our prototype. 1- Questionnaire Adam Eltarzi then created various versions of the questionnaires until the questionnaire was approved by all team members and our professor. Our questionnaire has tried to capture both functional and nonfunctional requirements from our users . A participation sheet was then created which the user reads before filling in our questionnaire Questions asked in the questionnaire: 1- What would you describe yourself as 2-What is the most important aspect of a video game? 3-What kind of music would you like playing in the background? 4- What type of animation style would you prefer? 5- How would you want the game to end? 6-How random do you want your games to be? 7-What would you want in a pause menu? 8-What type of control scheme would you prefer? 9- What type of Operating system do you use? We found that the questionnaire was very useful and found that it was a very appropriate capture tool to capture what users wanted in more detail and in both functionality and non-functionality. A more in depth analysis of the results of this questionnaire will be given in the deployment section of this document. 2- Research of familiar games What we are looking for: - UI and hud - Graphics of similar games - What platform do these games use - How do these games end 3- Watch people play our prototype game What are we looking for: -Helpful criticism on how to improve our prototypes -See if users enjoy our games 4- The creation of our prototype What are we looking for: - A working prototype which fits our users needs which will be given to us -By 25/09 we will have a working prototype which fits users needs on invision Deployment 1- Researching similar games What we gained: A clearer vision on what our system should look like and a good reference on what our game should do. We then took a look at some popular time wasting games and applications which are similar to what our users wanted. We then started testing these games to know more about how the games run and the intricacies of said games. This we found very helpful and has started giving us a vision on how our prototype should look and feel like. Below are some games and comments we tried and what we learnt from said games Ingame screen Gameover Comments Flappy Bird was a popular application which was deleted due to the creators personal reasons. People can still access this application online. Flappy bird is a simple game which focuses on you clicking and making sure your character goes through obstacles. Simple click controls. Flappy Bird https://flappybird.io/ Ingame screen Game over screen Passage https://www.addictinggames.com/action/passage Comments: Passage is an online game which has a mobile variant. It has a similar idea to flappy bird where you have to go through obstacles. However, the control scheme is different, point and drag to move your character. More simplistic and sharp images rather than sprites. Ingame screen Main menu screen Red Tie Runner https://www.construct.net/en/free-online-games/red-tie-runner-1463/play?via=mp Comments: Red tie runner had a main menu and level select screen. WASD control scheme. An online game which has a mobile variant. Goal of the game is to jump and to make it to the other end to progress through levels. A bit more complicated but still rather simple. Very simple animation, focuses more on smooth animation rather than how detailed the environment and the character is. Game Controls Comment Flappy Bird Point and click Very simple , user must click his pointer to make sure the bird does not fall Passage Drag and move Simple, user must drag his pointer whilst holding Left click to move his sprite through obstacles Red Tie Runner WASD keys A bit more complex compared to our other games, uses WASD movement keys to move a stickman through a platformer Game Platform Flappy bird Originally was on Apple and android, removed from the store and now is Online Passage Has an online and mobile variant Red tie runner Exclusively online. Conclusion of what we learnt: We learnt that we should not put such importance towards the quality of sprites and animation and focus more on replayability of said games. Although all the games we played are online and have mobile variants, we have still chosen to have our games on a desktop. This is due to all team members being comfortable with that platform the most, this will help us avoid issues regarding the game’s functionality and keeps us on track in terms of time. It also has given us an idea on how to develop our UI design for our main menu and how to present a game select in our main menu. All these games end by the user not going through an obstacle and or falling into an obstacle. We concluded that we need to focus more on a sense of achievement through time to make the game more replayable. 2- Watching people play our games What we gained: not much. We asked people close to us who are in our close bubble to play our prototype games and give us some helpful criticism, although they played said games, most users just said that they enjoyed it and they would like to have an improvement on graphics. They also said that they enjoyed the sense of difficulty and progression. Questionnaire Results: The questionnaire helped us gather more analytical answers and helped us know what features we should prioritize in our system. Below is what we learnt From question 1 we found that we had a mix of different types of systems in which people use to play games. Most people were computer gamers with a total of 50% of people. The others were a mix of mobile, console or other. This helps us as the system was computer based meaning most users were already playing games on a computer anyway. Question 2 showed us that a sense of achievement is very important across the system. With a few people answering both difficulty and progression as the most important aspect, the main thing we must focus on is giving the user a sense of achievement. We think this can be done through a high score system giving the user an aim to beat and this would ensure a goal in which the player can aim for. The answers for question 3 were very split with both dark and light music preferred all depending on the person. We think that a mix of music would be the best for the system, maybe changing the music across each game to keep as many people satisfied as possible. One thing we did learn is that nobody thought that we should have retro 8-bit music in our system. Again question 4 was very split however 3D rendered was preferred. This is going to be hard to create across all the games so we think that as long as we create different types of games it should keep multiple users happy as there is a good mix of animation styles. Just like the question above we think as the most popular way for a game to finish was other with 50% off the users preferring this, we should create multiple ways for a game to finish so if you take too long, if you lose lives, if you reach a certain score or complete a level the game/round will end. For question 6 we asked about randomness of the games in the system. The main idea which the users gave us was that a bit of randomness is very much preferred. We think this could mean where and when an enemy spawns or what colours flash in Simon says however the basis of the games stay the same. After asking what a pause menu should include we realised that the only thing people didn't select was level select meaning the most likely will just want to play from start to finish. We decided to try and include a quit main menu, a reset level, sound controls and a options/settings tab on all menus if possible which would keep every user happy. For controls we have decided that WASD is the best option as 80% of people prefer this. However certain games seem unrealistic to use WASD keys for a game in which requires a single click for example a Simon says style game or a reaction time test type game. The final question was about the operating system in which most people use. We expected windows or IOS to be the most common. This means we will make the system for a windows OS computer as it is the most used OS for stakeholders. Finally we asked the user of consent to use the data in the questionnaire and all allowed us to use this data. The results can be found at the link below if required. https://www.surveymonkey.com/results/SM-3JXD6QFD9/ Requirement stories Below We will show the requirement stories which we have gained through our capture tools and will present the musts/shoulds/coulds. Requirement Type Priority Use case Source Start Game Functional Must have Play Game Questionnaire/ similar games Control select Usability Should have Control layout Questionnaire Leaderboard Non-functional Must have Game over Questionnaire Score system Non-functional Must have Play game Questionnaire/simil ar games/people playing our games Game Select Non-functional Could have Main Menu Questionnaire Level Select Non-functional Could have Level select Similar games Quit game Functional Must have Quit game Similar games Sound settings Usability Must have Sound settings Questionnaire Resume Game Functional Must have Resume Game Similar Games Moving Enemies Non-functional Should have Varies from level to level Questionnaire/simil ar games Obstacles Non-functional Must have Varies from level to level Similar Games Runs on windows Functional Must have Play game Questionnaire Element of randomness Non-functional Should have Play game Questionnaire Music type: Light and chirpy Non-functional Should have Play game Questionnaire Increase in difficulty throughout the game Non-functional Could have Play game Questionnaire Animation style: 3D rendered Non-functional Will not have time. Play game Questionnaire Sense of achievement. Non-functional Should have Play game Questionnaire Life system Non-functional Could have Play game Similar games Reset level Functional Could have Reset level Questionnaire Use case diagram Zombie Game. Prototype We finally then created a prototype which we think fits all of most of our users needs which we collected from our capture tools. However, we did not collect any data about what our participants thought of our prototype Prototype link: https://procrastinationsystem.invisionapp.com/console/share/E62ZXWV4PM/756604526 Use Case Description Use Case Move right Summary This use case covers the player moving to the right Actor Player Trigger The player tries to move the zombie (his character) to the right Primary Scenario 1 : Zombie moves to the right [A1: Zombie moves into an enemy or obstacle] [E1: Zombie cannot move to the right anymore] 2 : Use case terminated Alternative Scenario A1: Zombie moves into an enemy or obstacle 1: Player loses a life [A2: No lives are left] 2: Zombie returns to the beginning of the level A2: No lives are Left 1: A game over prompt is shown 2: Player is asked if they want to restart the level or return to main menu [E2: Player quits] A3: Zombie walks into a collectable 1: Score increases by one Exceptional Scenario E1: Zombie cannot move to the right anymore 1: If Zombie is on the extreme right or something is stopping him, all commands to move to the right are ignored 2: Use Case is terminated E2: Player quits 1: player quits 2: main menu is presented 3 Use case terminated Pre-Conditions Game is being played and has loaded Post-Conditions Player is at main menu Assumptions None
