Skip to content


Before start it’s important to make clear what plug-ins are and how Pluma works.

Plug-in architecture

A plug-in architecture allow an application to load/unload functional modules in runtime as needed. Those modules (plug-ins) may be developed by anyone and connected to the main application with no need to compile or link everything together. You’re probably interested in developing a core application and let functionalities be added later. Whoever code new functionalities doesn’t have to understand how the core application works, just have to respect the connection protocol, ie, the plug-in interface.

  • A host application can use any plug-in that meet the same connection interface.
  • A plug-in can be used by any host application that has a suitable interface where to connect it.

Main concepts

  • Host application: Load plug-ins in runtime and put them to work. Provide plug-ins the necessary environment to operate them. Eg.: a shark (plugin) can only swim in water (provided by a host application).
  • Plug-in: Independent module, implements a public shared interface. Eg.: A keyboard is an input device.
  • Connection interface: The way to connect a plug-in to a host application. Both share compatible interfaces (usually the exact same interface). The interface is usually defined by the host application and distributed to the plug-in developers. But can also be defined by an independent plug-in and distributed to developers that are interested on using it.

How Pluma works

Plug-ins in C++ are all but Object Oriented. Thus, Pluma uses a unique C-like function to connect a plugin to a host. That function provides host with factories of objects, whose type respects the protocol interface. This way we can simply forget the language limitations and use object-oriented code. Note: instead of factory, we call it a Provider (sounds less industrial, doesn’t it?).
If you didn’t get it yet, don’t worry. We’ll see it working with the tutorial example.

The tutorial example

Let’s consider a game about Aztec warfare. The game engine (host app) will have a built-in warrior class named SimpleWarrior. Let new warrior types be added later and picked by players in runtime (plug-ins). We define a Warrior interface which will be shared by host (uses) and plug-ins (implements).
We’ll then build a plugin named elite-warriors, which will introduce the Eagle and Jaguar warrior types. When the plug-in is connected to the host application, it give to the host a way of creating such kind of warriors. We call it providers. In this case, the plugin add an EagleProvider and a JaguarProvider to the host.
The host is now able to create warriors of the Jaguar and Eagle classes from the respective providers. Forget the plug-in architecture and use warriors at will.
As we’ll see, provider classes can be automatically generated with one line of code (macros), and so we only have to worry with the classes of our game, coded as usual with no interlaced code for plug-in support.


You have got the main idea behind Pluma. We’ll start by defining the plug-ins interface on the next page.

Index ||  Introduction >>  Shared Interface