Articles Page

Design Patterns and Character Archetypes are the same

I'm here to make the argument that Design Patterns and Characters Archetypes serve the same purpose in their respective fields. What is this purpose ? To answer that, let's recap what Design Patterns and Character Archetypes are.

Design Patterns

In Software Development, a Design Pattern is like a blueprint for solving a specific class of problem. With this simple definition, you can probably understand why it's named that way. I want to emphasis that it solves "classes" of problem, recurring problems that are similar in the trouble they cause, similar in the way they are solved (or more accurately, cleverly worked around), but may not look the exact same all the time.

I will use the term "Data Object" to talk about an element of the program holding any form of data. Here, a Data Object is the bare bone representation of something (power plant and movement instruction in the following cases), stored in the program.

To illustrate this, I'll take a famous and simple one called the Factory Pattern. It's goal is to make it easier to create Data Objects. Often, if it takes many instructions to create a Data Object, the Factory will make it so it only takes one instruction to do so.

Let's say you're making a game where you build complex and detailed power plants. A power plant may be made of a lot of small systems, which interacts between each others. To create a power plant, you would have to wire and configure all of these systems so that they work well together. This is a lot of instructions.

The Factory Pattern would give you a single instruction, which would, behind the scenes, call the necessary instructions to build the power plant.

For another example, let's say you're doing precise robotics. The robot's movements may be determined by a Movement Data Object, but to create it, you need to do some complex math, and everything would depend on the current position of the robot. With a Movement Factory, you only have to write the universal logic once for all major cases (step forward, crouch, dodge left...).

Character Archetypes

In Storytelling, Character Archetypes are personality types accompanied by behaviors driven by what the personality type wants. Knowing them makes creating consistent and believable characters require less effort.

For two examples, let's use the Explorer Archetype. The Explorer is driven by a need to explore. He may seek tangible reward through exploration, such as fame or money, but in the end, exploring is what he lives for. This archetype is by definition a risk taker, who, more often that not, works alone.

Stories speak more than Software to the average person so I won't get into as much detail as with the Design Pattern.

Your first story takes place in the distant future, with spaceships and aliens, in a battle zone with the (mostly) human military against the autonomous defense system of a long gone civilization.

Second story is an elementary school trip where our main character is a parent who was volunteer to help the teachers to make sure everything goes well, except the bus fall down the mountain in a jungle and they have to get back up, using whatever the kids packed to help themselves.

Adding an Explorer character to these story is one of the best things you could do to give them more potential.

For the first story, because the Explorer is a risk taker who works alone, having him surrounded by a cast of military members who would have a more careful and team based approach is a great way to introduce strong conflict between the characters.

For the second story, the Explorer having to take care of a group of injured kids, puts him in a situation he is not equipped for while still allowing him to do what he's good at. This is perfect for creating a story where the character changes himself.

Why they are the same

Design Patterns and Character Archetypes are not implementations. In an analogy about Software Development, they are not external libraries. In one about Storytelling, they are not existing characters from another story. For each, I specifically used two situations that are vastly different from each other as examples to show that they are vague blueprints, whose more specific implementations have been proven time and time again to work for specific situations.

They aren't super complex concepts you could never have figured out on your own, but they give you a non-negligible and reliable head start.

One great thing also is that you only need to read about each of them once, because it's enough to develop an intuition that one of the Patterns or Archetype you've read should fit here, and speaking from experience, just seeing their name in a list is enough to remember which one it is you need.