I have been fortunate enough to have convinced some people I know online (some strategy game enthusiasts, some game designers focused on other genres) to give the current build of S.C.R.A.P. a try, and it has served to clarify some of what I see as the major stumbling blocks of the game’s design. As the designer of S.C.R.A.P., my goal is to try and maximize the game’s depth and array of interesting strategic options, while remaining as intuitive as possible. The testing that has been conducted so far has successfully shown me areas in which I can increase the game’s depth, improve affordances that illuminate the basics of how the game is to be played, and to streamline the design to get to the ‘fun bits’ more quickly.
The First Moments
As in Round 1 of testing, players seem a bit confused as to how to proceed when the game first launches. As you can see above, the player starts a match with 4 game pieces (units) at their disposal: the Fabricator itself, one Relay, and three Scrappers. For those who are unfamiliar, the Fabricator is the primary unit for this faction, and builds all units and structures. Relays add to the faction’s population cap, allowing for more units to be brought onto the field. Scrappers are the faction’s primary harvester unit, procuring resources that the Fabricator in turn converts into additional units, or structures.
The first action the game asks a player to take is to build a Generator to establish their first base. This is currently accomplished via the following action chain: the player selects the Fabricator, clicks the ‘build Generator’ button, and places the Generator on the nearby Generator Wreck. This results in the player obtaining control over the relevant base location, and allows them to build other structures. Initially, the Generator was in the Build menu with other structures, but I have since moved it out to make it more obvious. Additional testing is needed to determine if this is at all helpful.
What Does The Relay Do?
Players have some trouble determining the importance of the Relay. As mentioned above, the Relay serves as a “farm” or source of supply for the Fabricators faction. That is, Relays unlock additional supply or population cap for use by the player. They also support combat units by providing one of two auras: either speed boost, or damage reduction. Each Relay can only provide one aura at a time, so the ideal number of Relays to bring along with your forces is 1 or 2, depending.
I should here note that the Relay itself was added in anticipation of the Dendrites being more mechanically complex to manage than my Fabricator’s faction: the Dendrites produce more units than the fabricators, and have a constant production churn as they convert Assemblers into groups of units, and I didn’t want the game to have an “easy faction” and a “hard faction” – the requirement of Relays was intended to somewhat balance the two factions’ demands on the player. In practice, the Relay is a pretty simple unit to use: you just have to set pick which aura you need and keep the Relay with your army, adjusting its position for optimal coverage.
My intent with the unit (much like with the Fabricator’s Scrapper unit) is to make its inclusion in an army interesting by implication. The Relay impacts your ability to train more units, but it’s important to bring along into a fight. Therefore, protecting the Relay while utilizing the benefits it provides, not actually using it, is intended to be the interesting aspect of its inclusion in a fighting force. Thus far, opinions on this have been mixed: some users don’t mind it, some seem to resent that its use case is so simple. I’m currently relatively happy with how the Relay works, so I’m not terribly concerned with modifying its use case.
But players don’t seem to intuitively grok that they need to build Relays in order to train units. Players often get stuck right out of the gate because of the game’s initial supply cap, and because it’s unclear to them how to increase it. I see two main options in this regard. First, would be removing the concept of supply management from the game entirely. As a scarce-resource RTS with limited access to build queues, building and rebuilding armies takes a while anyway. This is a somewhat attractive option – early playtests of the Dendrites have also shown confusion with their supply management model. This would allow the Relay to be modified or otherwise re-purposed.
The other choice, as I see it, is to improve the affordances surrounding the Relay: a name change would be the first step in this process. Other options would be to create an audio notification that plays when the supply cap is reached. Something like “Build more Relays to continue unit production.”
The Fabricator’s Tech Tree
Right now, Fabricators have 4 structures: the Engineering Module, the Survival Module, the Pattern Co-Processor, and the Memory Module. After a Generator is built, the Engineering Module and the Survival Module become available. The Engineering Module allows for the production of Recyclers (this unit is a resource drop off point that can build defensive structures), and contains primarily defensive upgrades for the Fabricator: armor upgrades, Energy reserves upgrades, et cetera. The Engineering Module basically indicates that the player is focusing first on economy or defense.
The Survival Module is the other building that unlocks initially at the beginning of the game. This structure does not unlock any units itself, but has a variety of primarily offensive upgrades for the Fabricator: the player can switch between Fabricator weapons options, and choose either passive energy regeneration for their Fabricator, or an area-denial damage-over-time ability. The Survival Module would be an appropriate choice if the player wanted to be more aggressive in the early game.
The Memory Module improves the function of Relay auras, and unlocks an air-based scout unit. The Pattern Co-Processor unlocks Fabricator offense units, and allows the Fabricator to build 2 units at once.
Unfortunately, all of this has thus far been incredibly dense for players. Some of this may be naming related: I’ll be trying out some alternate names for these buildings that might be more descriptive (e.g. Economics Module, Weapons Module, Support Module et cetera). It may also be that in attempting to create “tech paths” for players that I have been trying to be too clever and am sabotaging myself. I think additional testing and conversations will be required to pin down a solid solution for this issue.
The un-intuitive nature of the Fabricator faction is frustrating to me: My intent was to create… options for the player: each tech structure is not strictly necessary (with the possible exception of the Pattern Co-Processor, which unlocks anti-air units and a variety of combat options) but instead provides additional functionality that allows the player to tailor their actions to the situation at hand (or, how they want to approach the game). That’s the goal: I expect and desire that bases will change hands pretty regularly, and want the player to be relatively autonomous (at least for a short while) without a base location. But something in my approach has been confusing play-testers, to my great frustration. I will be putting a lot of energy into solving this issue over the coming weeks.
I have long been planning at least one more map redesign, but the very design of the S.C.R.A.P. map has been confusing to players. No one has attempted to capture a Data Node (victory point) – possibly because the game’s objective is not clearly communicated, possibly because the Data Cores are hidden in the map’s corners.
One piece of interesting feedback that I have received is that map structures – which are destructible, and drop resources when killed – are “sneaky.” That is, that they don’t read as important or worth destroying. I’ll be looking for additional confirmation of this: some players tend to focus on these structures to their detriment (it’s a lot quicker in the early game to focus on open resources that can be harvested without whittling down a building’s health bar) while others tend to ignore buildings. I need a bigger sample for this, I think. But I’ll also be reviewing neutral structure models to see if I can find better distinctions between atmospheric doodads and destructible resource stores. Potentially, the simplest solution is to make most map assets destructible resource stores.
Other map-focused feedback relates to the fact that the map is currently a 2v2. I have recently decided that the game (at least this first version) needs to be in 1v1 format, so a new map will be forthcoming. Currently though, the number of resources, base locations, and the scale of the map itself, aren’t really conducive to 1v1 play: there’s too much stuff for the number of people involved.
Creep camps have been a point of contention: early iterations of the creep camps were horribly punishing: hordes of Dark Templar and Hydralisks waiting to shred unsuspecting players that pathed into the wrong area of the map. Even once I added some new, less annoyingly lethal creeps, I had problems with players accidentally critically injuring themselves on creep camps. Currently, creeps are almost non-existent on the map, and kind of feel like an afterthought. Finding the right balance is something that might take a while, but I definitely still want creep camps: the units themselves will decay into resources, and certain creeps will drop Victory Points, meaning that focusing on killing and harvesting creeps will get players closer to winning the game. Some additional feedback has been: respawning waves of weaker creeps, or creeps that run away instead of attacking. Both are great ideas, and may be added in the near future.
… Total Annihilation?
I keep hearing people relate S.C.R.A.P. to Total Annihilation and/or Supreme Commander, which has been… really weird to me. Thinking of the game in terms of economics vs tactics and in terms of scale, I have traditionally seen no real similarities: in turn, someone comparing my little mod to Homeworld, Company of Heroes, or Dawn of War would be a sign I’m moving in the right direction (these are clear influences, even if I am unable to make the Galaxy Editor support Relic-style unit squads.
Speaking in depth with one of my testers, I was told that my mod’s requirements for map presence and taking/holding territory are mostly evocative of SupCom- or TA-style RTS, as well as the fact that essentially there is a single resource (unit Energy is a secondary resource, but testing indicates to me that few people pay significant attention to unit Energy reserves at this time). I have also had testers liken my unit design to SupCom, though this confuses me.
My intent for combat is this: I want general unit lethality to be low enough that driving units away (instead of outright slaughter) is possible, and that incapacitating enemy units (through debuffs, Energy removal et cetera) is a viable alternative to outright destroying them. I am not convinced this is possible given the other constraints of my game (namely the fact that units are actual stores of value – they explode into resources when killed) or that such gameplay would be sufficiently interesting if implemented according to my desires.
But in most – virtually every – RTS, the focus is on just breaking the other guys’ toys. Relics games are relatively unique in that driving units off is often just as effective as killing them: break an infantry squad’s morale, and the player is required to retreat back to base and try another approach. Destroy a tank’s weapon or damage its treads, the same. This puts a time burden on the driven-off player that I find interesting and fascinating. I want to create something similar in my game. I’m not there yet, but that’s the direction I want to head.
It’s clear after the last couple of tests that I still have a ways to go. Once players grasp some of the basics, they seem to generally have a pretty good time, but getting a grasp on how the game is intended to be played presents a pretty big challenge. Some things may need to be streamlined, renamed, or have different art assets chosen. Some systems are incomplete. Some are not functioning as intended.
Game design is a fascinating, difficult journey – more challenging than I’d thought in my imagination. I am hopeful that S.C.R.A.P. will continue to improve, with your help, and that some day (hopefully soon) I’ll have a pretty engaging little RTS to get into your hands. Thanks for reading.