Spell Rush

Android Game — Software Engineering Group project — Summer 2019

Get it on Google Play


Spell Rush is an action game with a focus on an innovative battle system that uses gesture recognition.


Intended Users

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.

There are 3 spells:


Fire beats Ground and Loses to Water


Water beats Fire and Loses to Ground


Ground beats Water and Loses to Fire

Other Major functionality

  • 3 Distinct levels with increasinly difficult opponents
  • A leaderboard that stores your highest scores



Chad Hillary

"I gained some great practice working with the Mockito and Espresso testing frameworks, as well as facilitating project planning within GitLab!"

William Ritchie

"I gained a lot of knowledge when it comes to Android development, especially with activities and Views!"

Earl John Placido

"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!"

Michael Winkler

"I learned how to write code without having to know every facet of the code base!"

Nathan Carriere

"The quality of my code has vastly improved, just by reviewing other team members' code and having them look through my code."

Menu and level music courtesy of Trevor Lentz
Level complete music courtesy of Avgvst


What went right in the development process?

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.

What went "wrong" in the development process?

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.

How did the project change from the initial vision?

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.