Don't know what Nth Society is? Check out this post first.
Modular design in software is borrowed from mass production design. If you want to make a lot of something complex the best way we know of is to create it in smaller parts. These parts can be individually tested, have their own specialist machines and designers.
When we create software we're similarly making something to be mass produced. The replication process is a lot easier, as it's information. But in today's world of seamless technological integration it's important to remember that there's a lot going on under the hood. We still need to be wise in our designs and strive for maximum interoperability.
Modulular design in Nth Society game
For ultimate flexibility, I am working on the idea that every attribute, ability and feature will be implemented as a module.
Example, player modules
Here is a short list I created off the top of my head to give you an idea, in no particular order:
- childhood
- old age
- hunger
- thirst
- race
- sex (male / female)
- sexuality (activity)
- disease
You can see how already this could get quite contentious. Will everyone want to play in world where there is sexuality? Is it important to gameplay, or just a distraction? What about disease?
Some of the modules I see as fundamental to the idea, such as childhood, old age, hunger, thirst. Others might be important, like race and sex. Possible disease too.
And sexuality would certainly add a level of realism some players may think is essential. However it wouldn't be considered by most to be suitable for children to play, so it makes sense to have some modules optional.
The best idea so far in my opinion is to have these modules optional only at the time a world is generated. They are then locked to be on or off.
Maybe people will want to add more crazy modules, stuff to do with aliens, hobbits, or whatever to expand the world. That is not in my initial interest but by using modular design the game is infinitely extensible.
Pitfalls of modular design
Just making everything a module doesn't solve all your problems. In fact it can create a difficult system to manage.
As I see there are two contrasting pulls in software design: generalisation and simplicity.
For example some people thing that you should never copy/paste a bit of code from one part of a program to another. That means that there should be maximal reuse and generality. This is a sound approach, but being dogmatic with it can lead you to have to encompass too many edge cases and conditions.
Case in point: Project Ara
About a year and a half ago Google shelved it's much hyped modular smartphone product, codenamed Project Ara. Imagine you could switch out the camera for a higher power one if you needed it without replacing your phone? Only buying the parts you need for your own requirements, upgrading any time you want.
Fortune magazine had the best quote I could find summarizing why they shut it down:
[...] separating a phone into components threatened to slow communication between them, while also sapping battery life and making phones more expensive.
This boils down to a loss of efficiency due to over-generality. Critically also, the last point indicates cost. There's always and additional cost to generalization. In software this comes down to development time. It usually takes longer to make modules general, and even longer to make a general modules framework, but you do if you expect it to pay off in the long run. If there is no long run, if the project scope is small, hyper-generalization may not be needed.
The product itself looks so cool, and anyone who played with Lego as a child (or older... 😅) would have been attracted to high end build your own aesthetics.
The project was not only axed for direct reasons, there was also a restructuring of "out there" projects and moonshots at the time, with some top teir personale leaving also. This also shows us that more difficult projects are more stressful on teams and the most attractive to quit.
TLDR; I take the lesson here to be - stay realistic. Do no more than is necessary.
The argument for modularity in Nth Society
I've already stated this, but a top reason is customization. You have to ask, is this kind of customization going to be needed. I think think the answer is yes. Why?
Well because Nth Society is not just any game but an active experiment. Remember the founding objective:
To design, develop and play a game which explores life in a voluntary society.
The key word here is "explores". One explorative idea put forward is experimenting with which modules to use. Do we want players to have a race for example? What are we testing by including it? Will it be a positive or negative experience?
We can only know by trail and error. And if I were to guess I still think that peoples' preference will also have a role to play in this. I do not presume that every Nth Society world will test and enjoy the same things.
Finally
We are going to need game designers to detail the specs for these modules, first coming up with what can and should be separated into modules.
If you're interested in joining in the live conversation on this and other topics, hit me up on the comments and / or join the Discord server.
Thanks for reading! 😎
