One4All is a 4 player, team based puzzle game. Each player is given a different task and completing it successfully is critical to the team’s success. The player doesn’t control their own lives, but another teammate does. If one team member fails, everyone fails.
#Report
There are numerous mobile games already on the market. Not many of them, however, employ team based elements. Even further still, there are no team based games where success or failure is determined by the weakest link. We wanted to achieve the goal of adding a unique game to the mobile marketplace. The mobile game marketplace has seen a large amount of growth in recent history. We wanted to add a niche and unexplored cluster to this large market. This project will also give our team members an opportunity to work on a mobile app that incorporates multiplayer functionality, which is in high demand in the current job market. Even though the mini games will be fairly easy for the average person to complete, the game as a whole will be challenging and a breath of fresh air to the growing app market.
Our game application is designed to run on Android phones, where four users play a co-operative game. In our multiplayer function, we have it designed that one user hosts the game and they invite three other friends. In this game, each user plays one minigame at a time. Our application is designed so the weakest player defines the success of the whole team. If one player cannot complete their minigame, one of their teammates loses a life. Once one player loses all hislives, the whole team loses. We designed these games to be random so there will be variation in the games on repeated playthroughs.
We designed our game in a way to promote the gaming process. This entails a black background, which most gamers seem to enjoy. We also wanted the simple design to not distract from the focus of understanding these games. In terms of the flow of our app, we separated this into three different managers. One to handle the loading of resources, another to handle the minigames, and the last to handle transitioning between scenes. This design helps for understanding the code, along with reusability of the code. In addition, loading in all the resources before the game starts reduces wait time for the user.
Our original goal for this project was for all four players to play on the same screen. This entails having every player’s activity shown on all four phone screens. Our group did not have any experience in Android development. Furthermore, there was only a limited time to develop all the components in addition to this feature. Therefore, we decided to just display the lives of all players to everyone. Our multiplayer function is only designed to work over local multiplayer as a result of our group’s lack of multiplayer development experience. Overall, the biggest constraints of this project were the lack of experience in Android and multiplayer development, along with the short time period that the class requires.
Through the process of our project, we decided to scrap the idea of four screens in one design, along with the selection of the more simple multiplayer function. Furthermore, we added a loading screen in case of a longer delay in the loading process. We continued with our simple design, but added logos and text fonts to fit our game design. We edited the lives design to give the game a nicer, but still simplistic look. From the midway point of the semester we added one more game to get to our goal of four to six games and we have some prototypes that are not fully complete. To finish the development of our application, we went through testing and polished everything off.
Design of the Project: We have designed our game application in a specific way to enhance the gaming process. We intentionally incorporated a black background in every game because most gamers tend to like it in a gaming atmosphere. This helps people to focus on the tasks at hand. We also made the game timer fifteen seconds to make these simple games become more difficult under this time crunch.
Matthew DeMott, Minigame Programmer and Design Manager: Throughout the project he was in charge of programming minigames and working on the design of the menu features. In addition, he worked on the written progress reports as well as the presentation slides.
Mark Easterly, Structural Programmer and Overall Programming Manager: Mark was our best programmer and was in charge of overseeing the programming aspects of our project. He created the whole structure of our application as well as programming minigames. He also edit presentation slides and delegated programming responsibilities.
Nick Gross, Minigame Programmer and Assistant Design Manager: Nick worked on programming minigames and helped with the design of the lives display. He also worked on the overall design of the project.
Parth Patel, Graphic Designer, Team Manager, and Main Tester: Parth was in charge of any graphics we needed for our project. As the team manager he oversaw the written portions and the design of our presentation slides. He was also our main tester and worked on the design of the menu functions as well as the design of the lives function. Parth was also in charge of setting up everything on Google docs.
Cole Pillars, Main Minigame Programmer: Cole was one of our best programmers and was responsible for a sizeable portion of the minigame programming. Cole was also responsible for setting up our Git repository.
Dave Stager, Multiplayer Programmer: The multiplayer function of our application was one of the most challenging parts because it was new to basically all of us. Therefore, we delegated this responsibility to one member. Dave worked mostly on this function so we could implement it in time for the final presentation.
Based on the feedback from the five users, we have seen that our game is satisfactory to what we wanted. Some games are harder than others which is what we were going for. Our games seem to be easy to understand for the users and the timer is the proper amount on average. When picking interview subjects, we aimed for our target market, thus giving us the proper feedback. Four of the five users liked our basic gaming environment. We found some bugs that we have now fixed and obtained good suggestions for games we could add in the future. Overall, the users liked our application.
With the time constraint we only had time to complete four different minigames. To improve the game in the future, we could make more minigames. In addition, our multiplayer is only over local wifi and limited to two players. We would like to improve this by making our players be able to connect with players elsewhere too and expand the multiplayer to work with four players simultaneously. We could also continue to get feedback from users to improve the design of our application if they do not like the way it looks. In order to achieve these goals we would have to implement more games into our application and do further testing to get feedback from users on whether they like the design or not. Furthermore, we would need to do more research on how the multiplayer function works and implement the global multiplayer function.
Demonstrate ability to elicit and formulate requirements and scope of software projects: One of the first requirements for this class was the project proposal. This required us to foresee the tools and time needed to complete an application. This was not an easy task because our group had never programmed a mobile application. We formulated an implementation plan that projected how much time was needed for each responsibility and which team member would be in charge of each task. In addition, we were required to predict what tools we would need for the completion of this project. Effectively use software engineering tools to develop and manage software project: In regards to programming a mobile application, we chose to use android studio because of its accessibility and documentation. This made it easy for every member to obtain it and learn about it on their own. In addition, android studio had a built in version control software manager. To manage our code and to keep every member of our group on the same page, we used Git to control our code. Furthermore, we used AndEngine, which is a game engine that allowed us to not have to build our games exactly from scratch. AndEngine allowed us to use functions that were built in for us to use in our application.
Demonstrate ability to effectively work in a team environment: Throughout the semester, our team worked diligently as a group to complete our project. We set up team meetings every Friday in addition to the team meetings on Tuesdays, whether in class or as a group elsewhere. Furthermore, we set up a Google documents forum to share information and to work on documents together. In combination with our group text message was an effective way to keep in touch. We used Git to share code and to further work on other group members code if needed. Another key element of this project was to present as a group. Beforehand, our group went through the presentation slides together and properly delegated which slides would go to which group member. Overall, we are very satisfied with our group’s communication and teamwork as a whole.
Illustrate and apply concepts of ethics: During the process of making our project, we always made sure to use the five steps of ethical analysis. One key ethical principle we used as a group was the Golden Rule. Every group member treated each other as we would want to be treated. When criticizing another group member, we always did it constructively and make sure it wasn't a personal attack. Another principle we used was the “no free lunch rule.” When using software tools, we made sure that it was all open source or that the author’s intentions were for others to use their product or idea.
Demonstrate competency in oral and written communications: It was required of our group to have three presentations in front of the class and for us, as a group, to have three formal written reports. We were required to follow guidelines and present our idea, the progress made, and then the final product orally and in written form. In our first presentation, our group successfully presented our ideas clearly and in an orderly fashion to the class. In addition, for our progress presentation we were able to present a prototype to the class and explain exactly what we had completed. In the final presentation, we successfully demonstrated our final product and described our testing process along with what we found from this process. For every oral presentation we were required to have a written report as well. In these written reports we went further into depth about our ideas, our progress, and how we have achieved the goals of the class. We successfully did all of these and believe we have learned much from this project.