Introduction
Greetings everyone. We’ve previously mentioned that we’d start off 2022 with a major gameplay design revamp. In this update I’d like to provide some more details on what to expect, and what we’re planning for the revamp.
I’d like to start by saying that we’re pretty happy with the core loop gameplay, our “30 seconds of fun”. The feedback we’ve received from players is pretty unanimous: the huge chaotic battles involving hundreds of ships, exciting dogfights, and visual effects of explosions lighting up the battle smog have made some fairly unique experiences in gaming. This is clearly the strongest part of our game, so we don’t intend on changing the core experience much beyond balance tweaks.
However as we scale game systems up, the experience has tended to break down. This includes gameplay features that distract from our core combat experience. Our general conclusion is that we need to re-enforce what’s been working (build on our strengths) and clearly define the broader gameplay loops.
So, in January, we took a step back, and looked at Battlescape from an unbiased and broad perspective (as much as we could). In order to better understand what parts of the game work, and how to expand and improve its gameplay at a larger scale. As part of this “reflection” we looked at other games with similar concepts in scope, such as Planetside 2.
We still want the game to support hundreds of players per server, but the gameplay needs to be more engaging when the number of players on that server is low. All current game systems need to complement each other, and any extra complexity that does not bring value to that gameplay needs to be trimmed down. Reducing gameplay complexity and streamlining current game systems will have a direct impact on the development time required long term. This reduction in complexity will enable us to spend more time on improving game systems, and further refine the gameplay experience.
Please note that none of the following has been “set in stone” yet, and the gameplay revamp plan that we’re presenting here is wholly hypothetical. We still need to implement new features, conduct internal tests, make revisions, and test some more until we’re satisfied enough to push the design to our game servers.
So, now is the best time to provide feedback, before we venture too far down the rabbit hole…
Full Match loop
Currently, matches are structured around the total destruction of your opponent’s bases within a match. We plan on keeping the “destruction” condition for bases (no capture mechanics) but change the flow of battles as they move from base to base in the larger match.
Battle flow is currently directed by the AI Commander, and determines which team goes on offense based on the outcome of the previous battle. Battle wins keep an attacker on the offensive from battle to battle, whereas the loss of a battle places the losing team on the defensive. In this system, Team A could (and often does) snowball victory after victory on Team B, as each victory is rewarded with another battle on offense.
The new design is a turn based system that tracks team wins and losses. Instead of victory resulting in another offensive battle, the next battle’s offense / defense roles are reversed. In this proposed system, a battle begins with Team A on offense, and Team B on defense. Upon conclusion of the battle, Team A will go on defense, and it’s Team B’s turn on offense.
In the current game, multiple battles can spawn on the same base over time, so long as the base has not yet been destroyed. In the new design, battles will only happen once at each location. However, the outcome of those battles will contribute directly to team victory points.
Which brings us to “victory points”. We’ll start by keeping things simple, with each base worth a point or two for a victorious attack. Larger bases may have more points than smaller bases (yet to be determined via testing). A successful defense will prevent the attacking team from achieving their primary objective (destroying the reactor) and prevent the attacker from gaining the “Victory points” associated with that objective.
Once either team has some # (10) of accumulated victory points, a “decisive” (sudden death) battle is triggered. If the attacking team wins that battle then they win the match. If the attacking team loses, then the defending team will have another opportunity to attack. This continues until a “decisive” battle is won by the attacking team.
Hypothesized outcomes:
- The match will become more predictable in terms of progression, duration and how many bases are left to attack or defend.
- Team objectives become more clearly defined
- The game is more accessible to new players and everybody knows at any point in time what the current state of the match is
Economy and Progression
Addressing the economic side of the game has been a major challenge. Unfortunately, we’ve never really found the ideal balance. In terms of design, the major issue is the conflict we have between the nature of match progression (bases get destroyed so there are less and less active bases as the match progresses) and economy.
More specifically, team “credits” income is highest at the beginning of a match and dwindles towards the end. This means that the longer the match goes on and the more it snowballs in favor of one team. After the mid-game it becomes near impossible for the losing team to make a comeback and players have diminishing motivation to remain on the losing team.
The new design separates the team’s economies from in-game match progression. A way to think of this, is each corporation funds their military campaign from outside the battlescape (or star system). Instead of tying team resources and currency directly to the number of factories and successfully docked haulers within the match.
This means both teams’ economies are fixed at the start of the match, and will maintain balance throughout the early, mid, and late game phases. We feel this could solve the match balance and “victory snowballing” issues, and provide the losing team a chance to reverse momentum.
For the player, we’ve decided to separate the in-game credits used to purchase new ships, and career “credits” which will be persistently tied to your personal account or pilot progression.
The in-game credits will be referred to as “ship points” or (SP temporary name):
- Starting # of SP will be high enough to afford a capital ship
- The SP will increase at a fixed rate over time
- SP reset at the end of each match
- SP are capped, at cost of the “most expensive ship” in game
Our expectation is that capital ships will become more accessible, while becoming more valuable. As the decision to spawn one depletes available SP, and the cost to re-spawn another one requires time to wait for SP to re-accumulate. Ideally, this will reduce “Cruiser Spam” wherein players amass massive quantities of in game credits, and produce a never-ending supply of buffed out cruisers spawn after spawn… snowballing along with team credits etc.
In addition to player rank, a player’s “career” will advance via the accumulation of “personal credits.” They will be earned in-game based on individual actions; collecting bounties, accomplishing battle objectives, maintaining kill streaks, etc.
These personal credits or (PC temporary name) will be used to permanently unlock weapons and upgrades. Once unlocked, the item will be available to mount on any ship it can be fitted to, without impacting SP cost to spawn that ship.
This will allow players to predictably unlock items, build custom loadouts, and consistently have those unlocked items available to them in future matches. Additional factors, such as rank, may also have an impact on which items are able to be unlocked.
We’ll also be introducing a third personal “currency” cosmetic points (CP temporary name) which you’ll receive as rewards for various achievements. CP will eventually be used to unlock cosmetics like ship skins, tags, bobbleheads and other in-game goodies.
Battle Staging: Base Assault
One of the core issues with the game is the chaotic, unstructured and primitive nature of the battles. We currently throw two fleets at each other in proximity to a ground base or space station, and “let it play out.” Ships fly chaotically toward each other, pick off targets, and without any clear objectives, wind up duking it out until the last ships have been ground down to spare parts…
Our new design will introduce asymmetrical team objectives. Once a battle starts, the attacking team’s goal will be to destroy the core reactor of the enemy’s base. The base is protected by a large base shield, which can be taken down by destroying the base’s shield generators. Shields also protect the base integrity, defenses and other modules from incoming capital ship’s fire. Secondary optional objectives include base defenses (including strong AMS), hangars (that can be temporarily destroyed) or warp interdiction towers. Once the shields on the reactor go down it can be attacked directly and destroyed, marking a clear victory for the attacking team.
We’ll expand on the Base Assault “loop” as we further develop it through testing.
The defending team’s objective will be to protect their base from the incoming assault, destroy the incoming fleet and target the enemy’s carrier(s).
We’ll rebalance the carrier around its deploy abilities (both for players and AI squads) to further define its role as “momentum maintenance” for the attacking team. After a great deal of discussion, we’ve decided to remove the “Take-Over-AI” feature. This should further increase the carrier’s tactical value (as a forward spawn) for the attacking team; we can reintroduce it if needed.
This new battle staging plan will require major AI improvements. AIs will need to be able to attack tactical objectives just like players, and learn how to fly in squads, form up and regroup after an attack.
Ideally, battles should feel less chaotic and more structured with clear objectives. Players will see those objectives highlighted on the HUD, and will be rewarded for accomplishing those objectives through battle progression feedback, and career progression through in-game actions taken.
Simplifications
The changes made to our in-game economy has made factories, and the haulers, somewhat purposeless. We’ll be able to re-use the factory assets for ground bases, by merging them with the existing military bases, and expanding military base layouts.
We aren’t sure what to do with the hauler yet, though, as we had been considering it as a player-flyable ship. It is possible that we’ll simply cut the hauler from the game entirely, we’re open to ideas here.
We are also removing the “tech levels” and the “scouting/scanning” mechanics. This was already handled by the AI Commander, and makes the early match a hide and seek nightmare, especially for new players.
What’s on the Horizon?
Despite some simplifications, and removing some features, we still have plans to add more content to the game. In particular, we’re continuing to work on new weapons systems, passive mines, spinal mounted weapons for the cruiser, and nukes for orbital bombardment.
From the beginning we’ve had plans to broaden the scale of the solar system to include multiple Battlescapes. This is still something we’d like to do, however it could re-introduce the same complexity problems, and extend match time. While we haven’t decided to cut this feature completely, it may yet be. Especially if the new match loop works well. In this case, we’ll still add more planets and environments to the game for match variation.
Feedback and Expectations
I’ll conclude, by restating the hypothetical nature of this new design direction. While nothing has been “set in stone” yet, we do have an established general direction. We regularly take player feedback into account when discussing new design elements / features, and will often spend time reflecting on proposed solutions offered by members of our active player base. So while this post is not complete in scope, or completely detailed, do let us know what you think.
We’ll be testing internal builds of the new design soon, and will have more information on public release timelines / schedules once we’ve tested the larger design elements, and game progression.
-Flavien Brebion
