Baseball Rising
"BASEBALL RISING is a team based multiplayer action game set during the turn of the last ice age. You play as early hominid dreaming of a life beyond mere survival. Your goal is to team up to build and play the very first game of Baseball. But the world isn’t ready for baseball and its going throw obstacles at you. You’ll need to deal with angry mammoths, bubbling tar pits, and disorganized teammates in order to turn your Baseball dream into reality."
As a designer on Baseball Rising, I have the exciting opportunity to develop and explore the bizarre but interesting ways the mechanics and features of a baseball game can interact with those of an Ice-Age survival game. Finding and further refining these points of overlap is a challenging but rewarding part of working on the game, and continues to lead me to some strange but intriguing design questions (Would a sleeping wooly mammoth wake up if a foul ball landed on its head? How would a saber-tooth tiger feel after eating a stadium hot dog?), that are consistently just as fun to answer and implement in-engine as they are to ask and ponder via documentation and diagrams.
2023-2024
Design Documentation
Behavioral Map Design
Project Lead:
Davíd Padrón-Harris
Design Lead:
Dexter Knaack
Baseball Rising is my most recent project, and one I've been a part of since the summer of 2023.
I work with another game designer as a part of a 20+ person development team, on a variety of tasks both in and outside of engine, ranging from the creation and organization of behavioral diagrams to the implementation and prototyping of new game systems and mechanics with Unity and C#.
Over the course of the project, I've had to opportunity to work with Unity, C# scripting, Figma, and Perforce.
Below is an example of the full breadth of my responsibilities as a designer and the role I played in the creation of a core mechanic: the behavior system for in-game enemies. I was involved in every step of the process, from the initial brainstorming to its implementation in the build.
Early brainstorming documentation/spreadsheet, showing the possible behavior states for different enemies in response to player actions
Amazing concept art (by me) depicting an enemy that unfortunately didn't make it into the final version of the game: "Saber Toothed Squirrel Covered in Salsa"
Early Brainstorming
At the outset of the project, I worked closely with other department leads to help determine overall creative direction and determine which features and mechanics we wanted to focus on as part of our core experience.
We knew we wanted environmental hazards to play a very big role in the gameplay, so a big part of this process was brainstorming how different obstacles and enemies would behave and affect the player.
As with any brainstorm, the hardest part was narrowing down our long list of possible creatures and behaviors to include into one that fit well within the scope and core themes of the project.
Field Test
Our next step was an unconventional one, but one I really enjoyed and hope to use in future projects! We ran an outdoor, in-person "Field Test" of the game to make sure our core mechanics and systems were fun and engaging for players, and encouraged the behaviors and teamwork we were hoping to see.
To prepare for the field test, I created a short document that could be passed out to players that gave short descriptions of the different in-game roles and what they could do to help their team. I also created a much longer document for us to use as Game Masters that spelled out a more detailed version of the rules.
The behavior of in-game enemies was a big part of this documentation, with my goal to instruct players to act as similarly as possible to the sequence of "decisions" that would be made by the enemy AI in the game. The feedback we collected from participants after the playtest and our own observations gave us a lot of great information that informed a lot of our decisions in developing enemy behaviors.
Rules sheet that was handed out to player participants in the field test
.jpg)
A picture from the Field Test. The player with the blue striped shirt is attempting to use a potted plant to lure a wooly mammoth (the player in the bottom right with the elephant hat) off of a base so that he can use it.
An excerpt from the GM Rule Sheet, detailing enemy behaviors and rules for Game Masters and players performing the role of enemies for the field test
Behavior diagrams for the boar, a passive animal that would fall asleep on bases and prevent them from being used, and the tiger, an aggressive hunter that would seek out and attack players, unless placated by food.
Behavior Diagrams
With a good understanding of how we wanted to set up the enemy behavior system, our next task was making sure we would be able to communicate it effectively with the other teams. We met with the art team to determine which animations we could add for the different enemy states, and with the engineering team to outline the underlying infrastructure that would allow the enemies to switch between the different states and track important variables.
For these meetings, I used Figma to create diagrams outlining the behavior systems for our two main enemies: the hostile saber-tooth tiger and the passive wild boar. The diagrams were designed to include all relevant information on the behavioral system, and was used as a reference throughout the project.
We also drafted a design spec for the behavior tree system for the engineering team to work off of while creating the infrastructure for the enemy functionality, and create a tool for the design team to use while implementing the enemies in-engine.
In-Engine Implementation
After working with the engineering team to develop the behavioral tree system in Unity, we set up the enemies and their AI in the game scene. Each enemy state was set up as a scriptable object, which could be integrated as a node in the behavior tree with references to adjacent nodes, and C# code for actions performed and conditions for switching between states.
A big part of this process was working closely with the usability team, and watching playtests to see how players interacted with the enemies and how they affected the gameplay. For instance, in our early playtests, the value we'd set for the boar's "flee" radius was based on a single player, so when we had multiple players all spaced out around the scene for the playtest, the boar was constantly in flee mode and never stopped sprinting around in circles.
We adjusted this and many other variables as needed while we continued playtesting to make sure the player experience was what we were looking for.
Below is some footage from the last version of the game before the project went on hiatus. In it, you can see the functionality of the boar and bee behavior trees, as well as players interacting with the throwable, edible, and swingable in-game objects.
The boar enemy in-scene, with a gizmo set up to show its detection radius and colliders
The behavior tree for the boar enemy, allowing it to transition from idle to different behavioral/animation states and then back again as needed.
 Triggering a boar's aggro to lure it off of the base it's sleeping on |  Player picking up and throwing a skull to earn "Baseball Points" |  The player sets down home plate, the first step to setting up the baseball diamond |
|---|