Skip to Content

Pluginable Games

18 replies [Last post]
larienna
larienna's picture
Offline
Joined: 07/28/2008

This thread looks like if I am talking about computer software, but I am really talking about board games. Still, it could be a way to bring computer science to board game design. Maybe I should take a look on how plug-ins for real software are actually designed.

I have a civilization like game in design what will be very expandable and that could become very complex to learn and design. But that complexity level is required to make the experience enjoyable. In fact, it's not complex because it's complicated, but rather because there could be a lot of stuff, and most of the time, I get lost in my design. It's very interesting, but there is so much things that it's hard to have a mental view of the game as whole.

This is were I had the idea of making a pluginable game. At first, I wanted to have some optional variant set that players could use as they want it, but I want to push it even further by making almost all aspect of the game pluginable. The way it will work is simple, player will start with the core rules which is a game playable by itself. Then players can add plugins by replacing core rules with the new plugins.

For example, in the core rules, combat could be resolved by matching cards randomly, but you could add the tactical map plugin which allows to play the combat using the same cards with a small tactical map. A second example, you could have a simple magic system where each player has a few special powers for their whole empire, or you could have the complete deck building game with spell casting.

Players can agree to use certain plugins at the beginning of the game. But players could also add or remove plugins in the middle of the game if they are hot swapable (sorry, computer geek terminology). In other words, some plugins must be used from the start of the game while some others could be added or removed during the game.


Plugin design could bring multiple advantages:

Easier to design: You do not have to see the whole game in your mind to design each plug-in. You just have to remember the core and only work on the plug-in it self. It should make the design of the game less overwhelming. Then plugins could be compared together for compatibility.

Progressive teaching: You could teach the game by adding plugins though the game. It makes it easier to learn the game as you assimilate and use gradually the rules.

Adaptable to Tastes: Players can use the plug-in set they want according to their tastes.

Expandable, even by players: It makes it easier to add or change rules by changing plug-ins since the game is design for it. Players will also be able to design their own plug-ins

Speed up on demand: You could speed up the game during the game. For example, you could need to end the game faster, it could be done by switching plugins. For example: we do not resolve tactical battles, we use the basic system from now on.

Print and Play Friendly: For print and play distributions, players can play without building everything. They just print the plug-in they needs when they want it.


Now I am trying to find, how could we design pluginable games. Here are a few guide lines:

Unused information: You could add unused informations to some concepts of the game so that this information could be used later by another plug-in. For example, I could give a creature size to the monsters of my game without ever using that variable. But another player could design a plug-in that will use that variable.

Common Interface: Making sure that the interface for a concept is the same so that all plug-in could communicate with the same interface. For example, I could say that civilizations is managed with 3 variables. By setting this as the standard input, all plug-ins for civilization management will expect to use 3 variables.

Define common concepts: When some game mechanics influence all game mechanics, it could be useful to have common concepts. For example, a common concept for a civilization could be to have a "building". The concept of building could be implemented differently in each plugin. It could be a tile with a power like in puerto rico, or it could be a progress track. The idea is that if I design an "earthquake" spell that destroys a "building", the element destroyed will be different according to the plugin used. But all plug-ins will have a concept called "Building" making sure the "earthquake" spell will always be valid what ever the plugin.

Sub Values: It could also be possible to define sub balues to basic values that could only be used by certain plug-ins. For example, in the 3 variable example above, each variable could have 2 sub values for example, creating 6 variables: 1A, 1B, 2A, 2B, 3A, 3B. If a simple plug in does not want to define the detailed values, it will set value 1,2,3 which will be the same for the sub values. So 1A and 1B will be the same as Value 1. But if a plugin want to go deeper in details, he could define different sub-values.


Do you like the idea?

Do you think it could be useful?

Could it create interesting games?

Will the plug-in structure be too complex to understand?

Any other comments are welcomed. If you have questions let me know.

NativeTexan
NativeTexan's picture
Offline
Joined: 03/04/2009
Modular Plugin Design

I am a software architect / engineer by trade. I totally get the plugin / modular design. In fact, that's the approach that I took for handling the Headquarters (HQ) expansion for Arctic Scavengers.

Blog Entry for Modular Expansion Design: http://www.bgdf.com/node/5446 [I have attached the rules to demonstrate an example of how this approach could be implemented]

Kyle Gabhart
Driftwood Games
www.driftwoodgames.com

innuendo
Offline
Joined: 05/25/2010
It seems like an expanded

It seems like an expanded take on how carcassone handles expansions? You can opt to play with any or all (or some mix therein) of all the released packs.

Is that essentially what you are going for?

Dralius
Dralius's picture
Offline
Joined: 07/26/2008
basic and advanced rules

I would call this basic and advanced rules.

War games have been doing it for years since some of the systems are just too hard to learn all at once. They usually will include several scenarios. The first uses the basic rules and then each scenario after that introduces one or more new elements.

KViki
Offline
Joined: 06/07/2010
Pluginable Games

I like this idea very much, though it seems to be used or called otherwise, as the other posters say. But, i think, you are going with this description somewhat farther. Yes, there are the plug-ins (expansions, scenarios, whatever...), but you are talking only about core rules, not core elements of the game. So there doesn't have to be anything common for every game? A game made only by the plug-ins, connected with a theme or variables only, seems interesting. So, the game parts should include everything needed by every plug-in (wouldn't it be too crowded? :D) and some plug-ins wouldn't use them, some would, but in a different way. In case of the size of the monsters, it would decide for example, how powerful they are (biggest isn't best), or whether they can enter some area (tunnels, deep river). If you add magic, it has not to be too powerful to disadvantage an another plug-in, which uses combat skills, or better production, and watch out for not making it less efficient, more independent from the choice of another plug-ins.
All of that depends only from the choice of plug-ins... Sure, the game wouldn't be playable by itself. It seems rather, as you would join multiple games into one complex, while you could play anything you want, at any difficulty, complexity, speed or lengthen/shorten the game even by its progress. That looks to me really interesting, as to a player. And sure it can make more interesting games than one civ-like game or one wargame. Its design could run in steps, as you design the plug-ins, but if the players are given the possibility to create their plug-ins... They wouldn't balance it and some other plug-in would be useless. You would be teaching them to design games (good news for BGDF) :-D. And with many plug-ins, the teaching will be really long and the players will need many games to get a good strategy for the new plug-ins.
I like this idea, but I'm not sure if it would be much fun with too many possibilities to handle. I'll think aboout it when designing my own games. Nice and structured definition of the plug-ins :-D!

larienna
larienna's picture
Offline
Joined: 07/28/2008
Quote:I would call this basic

Quote:
I would call this basic and advanced rules.

It has some similarities. But it's like if all the advanced rules were optional and could be used in various combinations. If the core is very thin, it could mean that the core game itself is just boring, you need a few plugins to start with.

Quote:
It seems like an expanded take on how carcassone handles expansions?

It does look similar to Carcasonne, but it's like if each expansion could have multiple versions. for example, you can play the "Inns and cathedral" with 2 different set of rules and/or tiles.

pelle
pelle's picture
Offline
Joined: 08/11/2008
I's just call them "optional

I's just call them "optional rules" like everyone else, so even the non-cs geeks will immediately understand.

Hate them for asymmetric games though . With n optional rules you have 2^n games to playtest to have a good quality product.

dplepage
Offline
Joined: 08/11/2010
Subgames

There was a GDS a while ago about games with minigames: . This might be more like what larienna means - certain game events trigger minigames and use the results, but the exact nature of the minigame is unimportant. Then you could have N "minigame slots" and have M possible minigames for each slot, but you wouldn't need to playtest all M^N possible combinations - you'd just need to confirm that each minigame is both fun and balanced, and that the main game is fun as long as each minigame is fair.

zmobie
zmobie's picture
Offline
Joined: 11/19/2008
MTG

I think a good example of modular design is magic the gathering. You have a core set of rules that apply in all situations, then with every expansion there are 2 or 3 different rules that overlay the core rules.

I've always thought you could come up with a system where you just define the interfaces between different elements of the game. For instance, in the base game you roll a d12 to determine something... but you can replace that mechanic with anything that generates a number between 1 and 12. Or to make it more generic, you could define your own levels (bad, good, better best)... then determine how your resolution mechanic maps to those levels. So in the d12 roll, you could say that 1-4 was bad, 5-8 is good, etc.

Relexx
Relexx's picture
Offline
Joined: 05/31/2010
An excellent idea

Killer Bunnies works on a similar principle, if I understand it correctly. Yours is more refined, I believe, by adding essentially mini-games to expand the experience of the greater game.

A similar approach could be to add a new game (in its entirety) that can expand on the experience of another.

larienna
larienna's picture
Offline
Joined: 07/28/2008
The mini game idea is

The mini game idea is partially what I had in mind. But it does look interesting. The important thing is that each mini game must be independent and have the same common interface to communicate with other mini games.

Another thing I realized is that it could be used as a development tool rather than be a game feature. Here is 2 methods I found so far that could be used as a development tool:

Quote:

So far, I find it very convenient to add unused information. For example, I thought that the special resources on the map could have a quantity. In the original rules, I never though of quantifying resources, it was more a "I [do/don't] have access to resource X". But adding that value could give options for more plug-ins. It follows the idea below that I can continue to progress in the design even if I am not sure how it is going to work.

About defining concepts, it makes it easier to design spells if for example I know that all civ dev systems will have a population and buildings even if I have no clue how these concepts will be used. So it allows me to get a certain structure I could use to build on even if there is uncertain stuff. It should allow me to progress more easily.

larienna
larienna's picture
Offline
Joined: 07/28/2008
OK, I made a schema so that

OK, I made a schema so that everybody can understand more easily what I want to achieve:

http://bgd.lariennalibrary.com/uploads/Mainsite/GameIdea/GameIdea2010032...

There are the explanations:

The game will have core elements, like building, heroes, cities, unit types, etc, which are present in every game. To interact with these elements you will need actions, there are different type of actions which are all performed once at a certain level. The level of action will have various effects on the core elements which will be the same from a game to another. For example, you need a growth level 4 to colonize a swamp.

For the basic system, you will roll 3 dice multiple times and keep a die after each roll. This will set value A, B, C which determines the level of the actions of type A,B,C. There will be buildings that will allow you to perform a certain action twice, or give you a +2 on a certain action level. So this is the core of the system.

Then players can decide to hook plug-ins which will allow certain actions to be performed and modify their level. In the basic rules, all actions can be performed, but plug-ins could restrict certain actions. Then player can add the plug-ins they want, according to their taste, before the game starts, or in the middle of the game. The only restriction is that plug-ins must not overlap (2 plug-ins trigger the same actions)

Then you can optionally add advanced actions which are the equivalent of the advanced rules. The advanced actions will require either regular plug-ins or specific plug-ins. Plug-ins never communicate with each other and they are not related in anyway.

Finally, magic spells will be able to influence actions but also plug-ins through concepts. These concepts are elements that could be present and influenced by spells, but their nature is currently unknown and could change from a plug-in to another. You could have a spell that raise population, but population could be used as worker placement in a plug in, while being a simple population level track in another.

rtwombly
Offline
Joined: 01/17/2009
Your "Unused information"

Your "Unused information" guideline reminds me of Race for the Galaxy, where there are unused icons on the cards that are only meaningful with an expansion.

IMO, your most important point is "Define common concepts". If you just build a game with a basic set of rules and plugins that add completely novel actions, you run the risk of allowing (even encouraging) game-breaking combinations. But if you keep the plugins tightly related to your core concepts, this risk is mitigated.

Rather than a plugin being a concept or rule, however, I would propose that each plugin should be its own physical addition to the game. So in your example of a dice-based combat system, the plugin would be a card onto which the player can place his dice to trigger a certain effect. It should be more than a lookup chart and certainly more than a ruleset. At a minimum, the plugin should be an "Unused Information" piece, such as an icon or portion of the gameboard.

The critical difference between designing for computers and designing for humans is that computers always do what you tell them to do. If you write a branch into your game rules, players will tend to either take all branches or none, and they'll be a huge learning curve to the game as players either jump in too deep for starters or have to unlearn portions of the core game. But if you give them physical modular components and draft official variants using progressively more advanced combinations, players are more likely to play the "normal" game to a level of competency before branching intelligently.

NativeTexan
NativeTexan's picture
Offline
Joined: 03/04/2009
Thumbs up!

I don't have anything meaningful to add to the dialogue at this point, but I wanted to give a big "thumbs up" to the evolution of this thread. I like where you are with this larienna and I also wholeheartedly agree with rtwombly's points regarding the need for clearing defining the interfaces and ensuring that the plugins / modules are tightly scoped and have a physical / tangible component to them.

Good stuff!

Kyle Gabhart
Driftwood Games
www.driftwoodgames.com

larienna
larienna's picture
Offline
Joined: 07/28/2008
Quote:If you write a branch

Quote:
If you write a branch into your game rules, players will tend to either take all branches or none, and they'll be a huge learning curve to the game as players either jump in too deep for starters or have to unlearn portions of the core game.

I think that the learning curve can be easy if plug-ins can be added during the game. It allows players to learn the game bit by bit in 1 game instead of playing multiple times.

Quote:
IMO, your most important point is "Define common concepts". If you just build a game with a basic set of rules and plugins that add completely novel actions, you run the risk of allowing (even encouraging) game-breaking combinations. But if you keep the plugins tightly related to your core concepts, this risk is mitigated.

One idea is that the "concepts" could be part of the core of the game but simply have undefined functions. The function would be defined by the plugin. For example, I could say that population is a value between 1 and 10. Then plug-ins could decide to use this population as worker placement if they want.

SilentFury
Offline
Joined: 10/23/2011
You also need to use some of

You also need to use some of the core principles of object oriented programming, such as designing your 'plugins' as objects. One very important feature is that every plugin for a given rules set needs to have identical inputs and outputs (like Combat - input armies, output casualties) - that way you can have seamless transitions when players swap out a plugin.

Also, for balance, you want to try for systems that produce similar results. You don't want players going into one plugin or the other based on their belief that this or that produces an advantage, as then choosing which plugins to use becomes part of the strategy - and if you're swapping plugins too much, that's more rules to deal with than the game really needs.

NativeTexan
NativeTexan's picture
Offline
Joined: 03/04/2009
Good OO design is all about interfaces

Silent, you make two main points. First...

SilentFury wrote:
You also need to use some of the core principles of object oriented programming, such as designing your 'plugins' as objects. One very important feature is that every plugin for a given rules set needs to have identical inputs and outputs (like Combat - input armies, output casualties) - that way you can have seamless transitions when players swap out a plugin..

I believe that Larienna has already accounted for this in the design of a 'common interface'...

larienna wrote:
Common Interface: Making sure that the interface for a concept is the same so that all plug-in could communicate with the same interface. For example, I could say that civilizations is managed with 3 variables. By setting this as the standard input, all plug-ins for civilization management will expect to use 3 variables.

Your second observation is regarding balance...

SilentFury wrote:
Also, for balance, you want to try for systems that produce similar results. You don't want players going into one plugin or the other based on their belief that this or that produces an advantage, as then choosing which plugins to use becomes part of the strategy - and if you're swapping plugins too much, that's more rules to deal with than the game really needs.

Fair point.

Robert K Gabhart
Driftwood Games
www.driftwoodgames.com

larienna
larienna's picture
Offline
Joined: 07/28/2008
Right now, I am thinking to

Right now, I am thinking to place all the "concepts" inside the core of the game, so that none of them gets undefined since it would be easier to design buildings and spells. Concepts could be added by plug-ins but they will be out of the scope of spells and buildings.

While explaining the system to my girl friend, she asked "What is the goal of adding plug-ins?" I answered that it is to make the game more interesting. Because the minimum required to play could be not fun enough even if playable. But that implies that adding mechanics makes it more fun. I think it really depends on the players.

NativeTexan
NativeTexan's picture
Offline
Joined: 03/04/2009
Plug it in

larienna wrote:
Right now, I am thinking to place all the "concepts" inside the core of the game, so that none of them gets undefined since it would be easier to design buildings and spells. Concepts could be added by plug-ins but they will be out of the scope of spells and buildings.

I think that makes the most sense. If you can truly add new 'concepts' or 'types' to the game, then you run the risk of developing plugins that are not truly compatible with other plugins and/or unbalance the game.

larienna wrote:
While explaining the system to my girl friend, she asked "What is the goal of adding plug-ins?" I answered that it is to make the game more interesting. Because the minimum required to play could be not fun enough even if playable. But that implies that adding mechanics makes it more fun. I think it really depends on the players.

Another goal of the plug-in concept could be that it empowers players to decide on the nature of the game that they want to play that night.
- "Let's play the core version of the game with the minimalist plugin. That's the one that accelerates the victory conditions and streamlines the standard 1.5 hour game to 45 minutes."
- "Tonight let's incorporate the two plugins that delve into the detailed steps involved in CREATING the raw materials for our factories rather than just sticking with the standard game where raw materials appear in your tableau every round based upon the mere existence of a particular type of resource structure."
-"I'm really jonesing for some player conflict. Let's add in the espionage plug-in that introduces a richer means of attacking other players. The core version of the game still supports the concept, but it's at a very abstract level. The espionage plugin allows you to step down into that element of the game and have more fine-grained control over how that whole dynamic plays out."
- "We're going to play the core version of the game tonight, then next week we plan on carving out a 3-hour block of time and we're going to play with the Campaign plugin and the Wonder plugin which introduce two end-game objectives that utilize the same core mechanics, but stretch the game arc over a longer period of time (and in turn make certain types of strategies more favorable than others)."

I'm not sure if this is exactly where you were going with the plug-in concept, but it's what occurred to me. It preserves the notion of interface-driven design, abstract type definition, and more specific implementations (even polymorphic ones if you want to get fancy). It's a hell of a lot of work and could lend itself to some pretty intense unit testing and regression testing, but it is certainly feasible.

Happy Gaming!

Robert K Gabhart
Driftwood Games
www.driftwoodgames.com

Syndicate content


forum | by Dr. Radut