What’s an architecture design paradigm in this context? I’m borrowing the term “paradigm” loosely here, but a design paradigm is any framework of ideas and philosophies that put forward a solution as optimal for a given problem. As in, the set of practices and philosophies that you utilize to build and manage your game’s architecture, decide where every feature should fit, and why.

Design Paradigm VS Architecture

To build architecture suitable for your case, you utilize a set of paradigms.

It’d be almost fairly impossible to explain every single architecture out there, and quite fairly unnecessary.

This is because every application could follow a completely different architecture, but there are usually a handful of paradigms that repeat among different use cases.

In essence, a “paradigm” is the theory behind your architectural choices. An architecture is the implementation of that theory for your specific case. If you can identify your project needs, you can identify the paradigms you need, which will guide your architecture decisions.

Many architectures share very similar philosophies and ideas. Not only that, but paradigms are often used in combination with each other. For example, a fighting game and a card game might have completely different architectures, but they both could be implemented by mixing a data-driven paradigm, and a paradigm that utilizes dependency injection for example.

Paradigm VS Design Pattern

It’s a common misconception that architecture or paradigm are the same thing as a design pattern.

A design pattern is a reusable architectural solution aimed to solve a common problem that might occur within your architecture. But a design pattern is not sufficient to solve the big-picture problems with said architecture.

A paradigm can act as a theoretical big-picture design pattern. You’ll notice how in this chapter, for example, some paradigms have names that include common design patterns. This is because they describe philosophies that suggest utilizing a design pattern in a specific way to address the areas a paradigm is concerned with, which simply knowing the design pattern won’t address.

Not only that, but a paradigm could suggest how to implement your architecture within a specific technology or engine.

A Paradigm’s Areas of Concern

A paradigm is too broad that it can mean practically anything unique in your implementation. For example, if you’re implementing a fighting game, your characters would have different hitboxes and hurtboxes depending on their current frame.

If you’re using a data-driven paradigm, where you’re describing the collision data for each frame in data files, then inherently, you’re utilizing a data-driven collision paradigm, which might lead you to implement your own collision logic, as the collision paradigm Unity provides isn’t suitable for your use case.

The term “paradigm” can also be extended to describe the default practices an engine provides you to work with.

What we’ll examine in this chapter

In this chapter we’ll briefly examine what I call “Unity’s default paradigm”, and introduce some common paradigms that might inspire your custom solutions.

These are mostly the criteria we’ll be focusing on

Feature placement

Where is your feature placed in the architecture? Is there a hierarchy? What does your feature connect to?

Reference handling

Will your features grab their references? Will the references be passed to them? How and why?

Scalability

How problematic could this paradigm be if you decide to implement more features?