Solar Showdown
Each year, Brigham Young University students produce a complete video game that gets sent to student competitions and eventually published on Steam. I joined the game team in Summer 2022 as a game designer. During this time, I helped design key mechanics of the game, iterated on the level layout, and moderated weekly playtests with users outside of the production team. The game was produced in Unreal Engine 5.0.
Game Overview
Solar Showdown is a competitive 2-player resource management/real-time strategy game. In the game, players Players must be the first to charge their base laser by building 12 solar panels. They may build 4 different tower types: Solar Panels for collecting energy, Minion Factories for destroying enemy towers, Turrets for destroying enemy minions, and Shield Generators for limiting enemy movement. The average game takes 5-10 minutes to complete.
The following sections highlight a few of my key contributions to the project.
Mechanics Design - Claiming Turf
In our original prototype, it was possible for players to immediately move towards the opponent's side of the field and build offensive towers. This was a problem because it made early offensive strategies the only viable approach. Since two primary themes of the game are "farming" and "fighting", I pitched the idea of giving players an initial area of claimed land that they could build on. To build outside of this small area, players must expand their territory by "tilling" or "claiming" land.
This played into the game thematically, balancing offensive strategies by making them require more time to execute, and opening up new strategies of terrain management.
Mechanics Design - Turf Control
After the mechanics for claiming turf were accepted, playtesting showed that players liked the initial concept, but felt it was underdeveloped. So, I designed more changes to help integrate terrain control to other aspects of the game. After implementation and playtesting, all but one (the option for turrets, shown below) were accepted.
With these changes, each main factor of the game has a combative and terrain control component. Changing movement speed for players and minions is a strong incentive for tilling and maintaining more area, enabling players to react more quickly to events or hinger their opponent. Though the change for Turrets wasn't implemented, even they care about territory due to minion speeds. Minions slowed by terrain can be destroyed before they have a chance to harm any towers, but minions with a terrain speed boost can make multiple attacks before being destroyed. Altogether, these changes add depth to the gameplay, promoting creative strategizing.
Level Design - Iterating on Mechanics and Simplicity
Due to our limited production time, the team leads wanted a single map that could help players intuitively learn the mechanics of the game in a gradual manner, encourage a variety of strategies, balance offensive and defensive playstyles, and show-off the detailed art assets produced by our model and texture artists.
I created over 30 level layouts, altering the amount and/or location of pre-claimed tiles, sunspots, walls, and upgrade meteors as well as the map dimensions. Through a series of playtesting and evaluation from leadership, we found our ideal map.
The biggest factor in map design was getting the correct amount and positioning of sunspots. Solar Panels can only be built on sunspots, so having control over at least 12 sunspots is required to win the game. With a total 22 sunspots on the map, it is impossible for both players to meet the win conditions, requiring conflict. Players start with 5 sunspots near their bases so they can build up an initial stronghold, but then are thrown into conflict as they push towards the central sunspots. Since our playtesters tend to build defenses immediately around sunspots, we made sure to have sunspots appear in small groups. If sunspots were more evenly distributed or in large clumps, players' building patterns would become more haphazard, making screen readability difficult.
Once the spacing for sunspots was settled, we defined the perimeter of the playing field so that sunspots would always have at least one space in between themselves and the edge. Keeping the space confined to this size helps keep the majority of the battlefield and environment remain in-camera.
Additionally, we created an initial fence line from our old Wall assets to delineate the players' starting areas from the center. This gives players a safe space to learn the controls and mechanics, and helps with mechanical story progression, guiding the players from building up their defenses, tearing down the fences, and then charging the enemy.
Playtest Moderation - Pruning & Validating Mechanics
With few exceptions, the mechanics design team made a point of doing weekly, 2-hour playtests in the Student Center on campus. Students unconnected to the game were invited to play and give us their reactions or opinions on the game. I took point on having mini-interviews with playtesters at the end of their sessions.
In addition to the weekly playtests, I was asked by the project's producer to help moderate special playtests with groups of adolescent boys, our primary target demographic.
.jpg)
In order to meet our goals of making a simple 5-10 minute RTS game, we needed ensure that players would be able to quickly learn how to play. This was complicated by an additional goal to do this without a dedicated tutorial level. So, during playtests we kept track of which game mechanics players focused on, what strategies they implemented, and what aspects they failed to notice.
The original list of troublesome features was rather large, so we went to task deciding what could be taught better and what just needed to be pruned. Shield Generators were nearly one of the options removed from the game since their basic function is similar to Turrets, but I was able to validate them by adding their terrain mechanics and watching player interest. Clever players would use shields as an offensive strategy, placing them to reserve clusters of sunspots. Defensive players appreciated having multiple options for fortifying their territory. Ultimately, Shield Generators were kept, but we did trim 3 out of the 7 original building options from our early prototypes.
After pruning unneeded features, we still needed to make sure players could learn the game mechanics that remained. Players frequently forget the main goal of the game, when/where to till, and how to select and confirm building options. Alongside a fellow designer, I pitched an idea about having players start in a safe, walled off space and using explicit prompts to teach basic actions like tilling and building. Experienced players can move through this section quickly, but new players have the time to explore mechanics safely. This idea was accepted, though it took many iterations and playtests on top of contributions from both the mechanics designers and the UI team to fine-tune the concept.
Niagara FX - Player Feedback
Our weekly playtests reminded us about the need for FX to give players feedback whenever they succeed/fail at an action. Unfortunately, the project's original FX team didn't have enough man power to complete all the FX needed. So, I took the initiative to learn Unreal Engine's Niagara Effects system and help. Throughout the course of the semester, I developed FX for player walk speed, dust clouds, healing towers, players tilling, minions tilling, upgrading towers, sunspots, minion explosions, and more. These were quickly validated in our playtests, especially healing. Though players could previously see a health bar slowly fill up, seeing the FX made the experience much more satisfying for them. After the FX was added, we saw in increase in how often players would use healing.
In addition to creating the FX, I went into the UE5 coding blueprints to get the FX in-game. This was tricky for some blueprints, especially the dynamic walking dust clouds. Originally, they were linked up to an animation-notify, but the notifications had to be overridden so that the effect could change based on the players speed (players kick up more dirt when under a speed penalty). Other blueprinting contributions include hooking up audio cues, adjusting UI, and patching coding bugs.
Polar Showdown - Prototyping and Polish
In the final month development, our leadership decided to make a stretch goal of adding a new level, complete with an alternate game mode. I was asked to take the role of Lead Game Designer for seeing these last minute additions to fruition. The art team was interested in making a winter-themed environment, so I held a design ideation session with the other mechanics designers to come up with a fitting mechanic. Ultimately, we landed on throwing snowballs. In the standard version of the game, crystals occasionally fall from the sky and can be used to upgrade towers. In this alternate game mode, players could collect snow each time they claimed a neutral tile. After claiming six tiles, they could then roll a snowball to destroy enemy droids or damage towers. Since our playtesters frequently requested a way to directly harass the opposing player, we also added a feature for stunning a player when they get hit by a snowball.
In two days, I developed the game mode prototype and had a quick playtest to verify player interest. The prototype was rough, but players responded favorably. This was enough to get approval to finish the design. I delegated my teammates to work with the UI designers, sound designers, and programmers, and despite the short time window, the team came together and completed the new game mode.
After the new "Polar Showdown" level was completed, I spent the remaining time pouring through the game, tracking down as many bugs or tweaks as possible. I then rallied a group of programmers and designers to make these fixes, may they be as large as a game-breaking bug for the sunspots, or as small as changing the size of text in a UI element. Then, in celebration of the completion of the project, I created the above video, showing the history of the game from its first prototype, to the final build. It was a rush to the finish, but I thoroughly enjoyed my time on the project, and look forward to future opportunities to design games on a team.