Bearly Tennis is an arcade tennis game where you play as animals who have reclaimed an abandoned town from humans, discovering tennis in the process. In order to play Tennis, you search the world for objects you can crush into makeshift tennis balls. These makeshift balls have different properties causing them to perform differently from each other in a match.
Bearly Tennis was created by Mangrove Interactive as a project in Unreal Engine 4 for our Senior Capstone class.
Mangrove Interactive:
Producer: Zach Frye
Producer: Aaron Marques
Designer: Ryan Swanson
Programmer: Adam Clarke
Artist: Katrina Mason
Artist: Alex Mannion
As the sole designer on this project, I had my hands on many different parts of this game. I served as Project Owner where I helped direct the development to fit within our design and within our timeframe. I worked hands-on in the engine building out the tennis town, implementing all the UI elements, and balancing and tuning all the gameplay-related systems.
Recreating Tennis Our Own Way:
When starting on this project our goal was to create our own unique spin on a classic sports game. As a team, we got behind the idea of playing tennis in an untraditional way using objects you would find in the world as the balls we play with. This idea adds an exploration element before you even play tennis where you and your opponent have to go out into the world to find the balls you would inevitably play with. The thought of an exploration game and a tennis game seemingly clash with each other and so it was important that both of these concepts feed into each other.
When you load into the game you start off in exploration mode where you explore a small town. Players will search the environment for 3 props that they will turn into tennis balls to use during their match. Once both players have selected their 3 balls, the match can begin. It was important to us that the props in the environment caught the player's curiosity to help them figure out what balls to use.
In creating the tennis game loop, we needed to draw importance to the decisions players made during the exploration phase. This meant adjusting the classic 4 point sets to a scoring system that was more focused on the balls a player has to remain. A player's score is reflected by how many of their balls they have left. When a player serves, they choose one of their balls to use, losing that ball from their inventory after they serve. In traditional tennis, once the player serves they take turns to hit the ball back and forth, competing with each other to win a point. When one player cannot return a ball or hits it out, they would lose the point. Rather than increasing the winning player's score, when a player wins a point they force the losing player to serve. The value of the score is then tied to how many balls you have left. A player would then win the game when their opponent loses the point with no balls left. Because the Tennis lingo can confuse, internally we thought of this as more akin to a traditional lives system. The balls reflect how many lives (serves) you have left, and if have no more lives (serves) left then you can't respawn (serve again) and so you would lose the game if you die (lose the point) with no lives left.
Creating The Ball Properties:
It was our goal to make sure each of the makeshift balls behaves somewhat differently from each other. The choice of what balls to pick before the match begins should be meaningful to each player. All stats associated with the balls need to have a visible impact when being used to reinforce this.
The challenge in this was figuring out values we could change and associating a trait to it. For our tennis serves we modified simple kinematic equations. The ball's landing position is calculated on swing depending on the user's input but we realized we could affect the overall arch of the ball's travel and the speed of its travel depending on the time it takes to travel from its initial position to its destination. The speed of the ball travels also needed to depend on whether or not the player was charging their shot or not.
Because of this, we had to create a max and min value for the projectile time allowing us to change the time based on how charged a player's shot is. The higher the projectile time the bigger the arch and the slower the ball travels, whereas the lower the projectile time means the lower the arch and the faster it would travel. Using this knowledge I associated the variables with different stats so that the player could better interpret their meaning.
The max projectile time was to be associated with bounce as the longer the projectile time would be the higher the arch. The min projectile time was then to be associated with speed as a lower travel time means a faster maximum potential speed the ball could obtain traveling its fixed distance. The third and final stat was to be size, which would be based on the overall scale of the balls, leading to some comically sized balls.
Once the stats and their associated variables were determined, I created a range of values for each stat. We could then assign the different variables on each of the ball actors, allowing us to obtain the variables on the balls in different parts of the game, like the UI. This also made it easy to change the different values after user testing.