You talked about how making system with an edge case/additional functionality (namely the boss’ elite units acting as a unit with cover fire/focused targeting). Can you explain why it is harder/more time consuming to add unanticipated functionality in later?

I’ll use a different example to answer your question today. There’s a well-known long-running MMORPG called Star Wars: The Old Republic that was famous for its companion characters as a major game feature.

SWTOR Smuggler and his companionsALT

The way that the companion system was built for launch was designed around every class having an equal number of companions within the data. Companions at launch were mapped by class - every player class had six different companions, each with a set role (melee tank, ranged tank, melee DPS, ranged DPS, healer, ship droid) in a specific numbered slot. In all of the code systems that had anything to do with companions, the code wouldn’t ask for a specific companion by ID number, but rather by the player’s class and companion slot number. The system was built such that companion lookup could not be sparse (that is, you couldn’t have empty companion slots for any class), or systems like companion affection, equipment, companion stats and stat scaling, many parts of combat, companion UI, certain cinematics, etc. would fail in a cascade. Every class had to have the same number of companions or all kinds of game systems would break. This also meant that there wasn’t just two different faction ship droids, there were eight (a different one for each class).

Geralt the Witcher mutters "Fuck"ALT

It was when the game designers added the first and second additional companions to the original roster that they ran into the wall. They couldn’t add just one companion - they had to add eight companions - a different version of the new companion for each class. The costs were so great that the leadership deemed it too expensive to build new companions after the first two (HK-51 and Treek). It also meant that there was no way that they could reuse existing companions for other classes - the Sith Warrior couldn’t ever recruit a companion character that was designed for the Imperial Agent, because it wouldn’t be the same companion, it’d have to be a separate instance of that old companion data. New companion characters were one of the most highly requested and popular features among players, but actually adding them to the game was a nightmare in terms of the amount of work that needed to be done and complexity of data (since design quailed at the thought of having to keep track of up to eight different versions of every new companion added to the game). This problem was a continuous thorn in the side of the leadership too because they knew this could open up massive new opportunities - faction reward companions, microtransaction companions, temporary companions that could actually die as part of the story, different versions of companions, etc. - but could not feasibly do anything about it due to the development cost of having to rebuild the entire system.

Brooklyn 99's Gina says ALT

Eventually, circumstances granted the SWTOR team additional headcount for a year and the leadership wisely tasked a strike team of engineers and designers for nearly the entire expansion cycle to rebuild the companion system from the ground up in order to decouple the player classes from their static companion slots. For the first time, designers could set a list of player classes that the companion could be recruited by without needing to create a duplicate of that companion’s data for each class. All classes could share the same companion’s data, which meant that classes could recruit each others’ companions, and that new companions were much, much easier to add to the game. Design would no longer need to create eight different versions of the same companion anymore.

John Wick says "Consequences"ALT

As you may have surmised, the reason that it was so expensive to add unanticipated functionality in later is because a lot of other critical systems were built upon the assumptions made during that initial implementation. Changing the underlying system meant that all of the other systems built on top of it would either fail spectacularly, or would also need to be rebuilt to work with the new hotness. These game systems do not exist in a vacuum - there are often shockwaves that affect other secondary systems which can set off their own shockwaves to affect tertiary systems, and so on. It isn’t always as huge an issue as SWTOR’s companion system, but it is a really good example of bad assumptions made during initial development haunting the team for years after launch.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *