Scalable components are the tools, components, pieces of your game that can change and adapt. It’s a character controller with adjustable jump height so two different types of character can have their own abilities. Or making yourself bigger when you collect a power mushroom. 

It’s a quest system that allows you to add new quests, easily expand, edit the text, translate it into a new language. It’s an item system that pulls from a central list and updates the name of your healing potion everywhere it’s used instead of hard coding values into a component. And then when you rename “healing potion 4” to “Superior health potion” you need to edit it in 3 places. Otherwise, the quest offers a “Superior Health Potion”, the player picks up “Healing potion 4” and in the inventory they see “Health potin 4” spelling mistake and all.

Scalable systems include building game managers, and blackboards to hold data. It means you can add a quest location or a new town to your map and it automatically works as expected. And they’re amazing systems to have. A well designed game is going to have a lot of them. 

A well designed game is going to have systems that make it easy to edit, expand and modify your content. And we’re going to talk about that during Phase 3. In fact we’ll have a couple of weeks entirely dedicated to tools and systems you need. It’ll seem a little contradictory. But that’s too simple of a view.

These tools are amazing when you have the time to build them. A well built quest system lets you easily add quests, assign them to things.

But it takes time to build them. It could be hours, days, weeks of work to build a strong enough quest system. Do you have that time now? Do you have that time after the MVP and before December 1st? Maybe you do. 

You might not. And that means building non scalable systems.

That means building a simpler quest system without a master list, that exists entirely within components. It means building your first suitable quest and copying the component onto a new NPC and repeating. It could mean your quests always start and end with the same NPC. One guy, gives a quest and rewards it. All driven on a single component. And when his quest is finished? So is he. Another NPC offers the second quest.

Well what if I need 7 quests Timps? Then put 7 NPCs in this village. Because this component is non scalable. But the NPCs are.

There’s a hard cap on how many NPCs you can fit in a town. Mostly.  But are you going to hit it? How quickly can you fill in some simple text, set one of 4 selectable mission objectives and drop a reward into a field.

Your path to an MVP meant cutting some corners. And as you go to a finished game, you’re going to keep cutting them.

Some of those corners you’ll fix later. Some of them you never will.

Don’t let perfect get in the way of done. Far more games than you realise are held together under the hood with duct tape and tears.

Smashing pumpkins, lighting torches, freeing chained dragons and more. These tasks need abilities, abilities need to be cast. You have races, classes, different levels. So, there needs to be a simple way to interact with different things.

The answer? A weapon. A custom weapon that does a specific type of damage with a specific animation. It can cast TorchLighting damage for 100 points, and when a TorchLighting bunny dies? He triggers a script that turns on a light.

The custom quest item you got is a weapon, it contains the logic to do the right damage, the right distance, and the right animation. Class and race independent.

Almost every quest item that asks you to click on things, cast, or “use” is really a weapon. A weapon that damages an invisible rabbit, found only in a specific area.

Long live the bunnies.

So what do the bunnies teach us?

The World of Warcraft team could have easily built a bunch of custom quest systems. They could have built mechanics that all used their own methods. They’d need to limit them to the right classes and players, make sure you’re turning lamps on and smashing nests from the right distance.

They could have chosen to build these systems entirely separate. And likely put a lot of limitations on them. In the middle of crunch time or a new expansion, suddenly you can’t get approval to build the functionality for the cool quest you want to design. And instead, it becomes one more “Kill Wolves to collect Wolf Tails”.

But the use of the bunnies, empowers and enables the quest team. There’s already systems in place to put objects in players hands. To make them “cast” an animation. To do damage, and to call a script that makes changes. These systems built for combat already handle the distance checks, global cooldowns, prevent two things being cast at once, or casting when moving. All of the things you’d need to build are already there.

An existing set of systems was used in a creative way instead of building other complex systems on top of it.

When designing and building your game. Think about the things the player does, and the systems behind them. Does something need to happen? Or does the player simply need to see it? Do you need to build a complex AI system to strategise, or will it be good enough if you code in 3 choices and choose them at random?

Do you need physics on this bridge that opens, with working chains on the drawbridge? Or can you just make an animation of the wheel turning, and the bridge lowering? Does the chain need physics and to wrap around the gear? Or can you just position the camera so the player can’t see the perfectly straight chain sticking out in the air behind it?

Your time is limited. Spend it wisely. Spend it where it matters.