Spell Rush
Android Game — Software Engineering Group project — Summer 2019
Android Game — Software Engineering Group project — Summer 2019
Spell Rush is an action game with a focus on an innovative battle system that uses gesture recognition.
Our intended audience is casual android users anywhere from 7 - 90 years of age with as little as 5 minutes to spare to play a fast-paced, challenging game.
Spell rush is a game where you draw different shapes on the screen to create different "spells". Your goal is to get your attack to the opposite end of the screen and damage your opponent.
These shapes can be viewed from the games tutorial menu on the main menu screen.
Fire beats Ground and Loses to Water
Water beats Fire and Loses to Ground
Ground beats Water and Loses to Fire
"I gained some great practice working with the Mockito and Espresso testing frameworks, as well as facilitating project planning within GitLab!"
"I gained a lot of knowledge when it comes to Android development, especially with activities and Views!"
"I Never had taken part in making a game before, so it was really cool to see and learn the process of creating a game from the ground up. I also thought the HSQLDB stuff was really neat and getting to play around with your own local database was pretty cool to do and learn!"
"I learned how to write code without having to know every facet of the code base!"
"The quality of my code has vastly improved, just by reviewing other team members' code and having them look through my code."
Our group did very well at team and project organization. We were able to set up consistent team meetings, twice a week, which were always productive. We also set up a slack group with an integrated GitLab bot.
Early on, we decided on our merge request and review process and documented our programming practices, which helped to organize our efforts. We also made use of the GitLab tags feature to organize our work on the planning board.
There were times when we did not collectively have a cohesive vision of the project, both architecture-wise and vision-wise. For about the first half of the project, we lacked a cohesive vision of the game mechanics — wheater it would be two human players, or a space-invaders type game, a bullet-hell style game, or a speed-based game with multiple lanes. This lead to some confusion on how to implement our code in a way that would be modular enough for these future mechanics. We addressed this by spending time in meetings, talking about what each of our visions for the game was, and workshopping the idea while keeping scope in mind.
In the first few iterations of the project, we were planning on creating a more shoot-em-up style game, with multiple levels, enemies, and bosses. After we came significantly short on our iteration 1 velocity, we decided that it would be best to limit our scope, and create a much simpler game that used a rock-paper-scissors mechanic.
We also thought of adding features like a "Rate our game" popup, and the option to share your score on social media. These features were decided to be low-priority, however, and were closed to limit our scope.