Groovelet Social Design & Tribes
Path, here, the designer responsible for social design in Groovelet.
Brief introduction: I like Travel and Food Blogs, and my avatar is a Bengal Cat. I want to bring people together. I’m something of an #influencer and a #digitalNomad, and I do a lot of my work fixing things from exotic places - for example, sailing around the world in my beat-up old Catalina 385 #40YearOldBoatLife.
Anyways, being as this Groovelet project might be the “last chance for the human race to survive” #lastChanceLol, I’ve been pressed into service by Cystam to be the product’s lead social interface designer. Before the #Catastrophe a project like this could never afford a designer of my caliber (or the #influencerCred that I bring), but… well, lately, there hasn’t been a lot of work for someone with my unique skillset, so I’m mostly just glad to have something to work on, even if I’m doing it out of the goodness of my own heart. #VolunteerLabor #PressGang.
Anyways, it’s become increasingly clear to me that while a lot of time and effort has gone into developing a system that can support social features, nobody has spent any time at all imagining what those features would be. (Enter me) #heSaysInParentheses
So here’s where we’re going to start: the shape of the #defaultSocialGroup. The Tribe.
The model here is going to be private-by-default, with join links. If you remember Discord (is everyone here old enough to remember Discord, it was a popular chat client in the '20s #retroTech), it’ll work something like that:
User A creates a Tribe,
then creates a join link
any user with the join link can join the Tribe
if User A disables the join link or leaves the tribe, the join link can no longer be used
In this way, these users are joined and can then engage in other social activities together. Still working on what those other social activities might entail, see #squadGoals below for more details.
Once User B is in the Tribe, they can also send links to other people to join the tribe. Each join link will be unique to its originating user, and we’ll keep track of who-invited-who into the Tribe.
This layer of #optIn sands some of the roughest barnacles off of social interactions. The people users will find themselves in a group with are friends, or friends of friends, or friends of friends of friends, not complete strangers.
One of the most important things that a tribe will provide to the player, and early on, is #goals. Shared goals. Goals that the entire tribe can work towards.
I don’t totally #💯PercentUnderstand the gameplay ramifications of the Goals, that’s more World’s deal (#boardGameFreak), but I do know that apparently “GAMEPLAY NEEDS GOALS TO BE FUN” - so they’re important in the sense that they’ll give players something to work towards.
Everybody in the tribe works on Goals together, and every goal completed by the tribe benefits #everyone in the tribe. Which might turn out to be important later, when we need to determine whether or not people are #activeContributors to a tribe.
Democracy, and Removing Bad Actors
One idea I had, and I’m not sure if this is necessarily a good idea, is that while anybody can create a Tribe, tribes aren’t owned or managed by the creator of the tribe. If 10 people join a Tribe, the tribe’s originator is fully equal in the tribe to every other member.
This solves some problems, but raises many others - notably, the problem that it becomes significantly more difficult to remove #badActors from a community.
Let’s think about that a bit: If a tribe is fully owned by the player that created it, it’s prone to corruption, #playingFavorites and abandonment - #goneWithTheWind; the simple problem of the tribe’s captain simply abdicating any responsibility to moderate their space. On the other hand, having just one person be #TheCaptain, responsible for management decisions for the whole tribe, well, that’s a practical, simple model that’s easy to build and manage.
On the other hand, leaving the decision-making of the tribe up to the whole tribe:
it’s significantly more effort to develop, #democracyIsHard - voting raises questions like “how long does a vote take?” “how are users alerted to a vote?” “what constitutes a quorum?” and “how can all of the rules we’ve put in place get completely ruined by a sufficiently noxious group of trolls?”
what if loads of users become #inactive? do votes become impossible? or, alternatively, if we allow small quorums (#quora?), can small numbers of malicious users make nasty decisions during times when the rest of the constituent are away?
it’s prone to “rolling votekick” attacks where a sufficiently large group of bad actors can cruise around joining and dismantling societies
The rolling votekick problem can be somewhat addressed by giving new members voting powers equivalent to their contributions to the tribe in question, but that becomes even more complicated to implement.
When it comes to removing #badActors, one question is “to what extent is it even going to be possible to be a bad actor?”
I’m assured that a big part of Groovelet’s design is to make being a bad actor extremely difficult. Hopefully, almost everything a player can do contributes positively, and almost nothing they can do contributes negatively.
However, as Habbo Hotel discovered, no matter how restrictive the environment, life, uh… finds a way.
Most of these problems, though, they’re #futureProblems. Like, far future problems. We don’t have any Groovelets online yet, let alone trolls - so figuring out what to do with 10,000 of them might be #overthinking.
That being said, I’ve seen what happens when bad social decisions get baked into the fabric of a community early on — once you build a #community it’s pretty danged hard to unbuild it.
How Big Can A Tribe Get?
This is probing to be one of the hardest things to figure out.
I was thinking “arbitrarily big”. I mean, I’m kind of a #bigDeal, and my online following is in the tens of thousands - imagine if my reach online were capped.
My more development-minded team members are fond of reminding me that infinite-sized anything can hit problems of scale pretty quickly, and also @World thinks that it’ll make “BALANCING THE GAME’S GOALS UNNECESSARILY HARD”.
If, for example, goal difficulty aggressively scales with group size, then using the voting tools to clear out stragglers starts to become really important. On the other hand, if goal difficulty doesn’t scale well with group size, large groups will quickly #steamroll though all of the game’s content with no difficulty or challenge.
So, to start, I was thinking of capping Tribe size at 100 Groovelets #dunbarsNumber #monkeysphere.
This is both very small - #myFollowingIsBigger - and quite large - most people having less than 100 actual friends.
You can have a somewhat-but-not-entirely-meaningful relationship with each person in a 100 person group - and if that’s not #ideal, I don’t know what is.
Automatic Eviction Is Probably A Mistake
The problem with capped tribes? Well, what if a tribe fills up with people who leave the game? #splitters. The last few stragglers in the tribe will be trapped, alone, in an #abandonedVillage. That’s a pretty bad user experience.
I guess players are also always free to leave an #underperforming Tribe, but they might leave the Tribe and also the game entirely.
Rather than having to use voting tools to clear out stragglers, what if stragglers just got cleared out, on their own? That’ll also make voting quorums easier to meet, and scaled goals easier to hit. Maybe any user who hasn’t contributed anything during a year-in-game (2-week-IRL) cycle should be automatically evicted from a group? That plays along with some of our pre-established themes of “punishing players for not playing the game”. #youSnoozeYouLose #walkThePlank
… but, actually, it’s possible that punishing players with tribe excommunication for not playing the game enough, especially on a pretty tight two week cycle, is possibly #tooCruel.
Scaling Requirements & Citizenship
It seems like the problem of #inactiveUsers strikes whether or not we actually cap the group size. Group goals and voting quora need to scale with group size, but we don’t know how many people in any given group are actually still engaged with the game in any sort of practical way, so any given Tribe is going to be filled with innumerable #ghost users.
So here’s an idea: A Citizen is any Groovelet who has contributed to a shared tribal goal in the past 26 hours, and Citizen-ship is not granted until the day-in-game (hour-IRL) after the Citizen has contributed.
Only Citizens can vote, only Citizens benefit from the completion of shared tribal goals, and voting rights and shared tribal goals are scaled to the number of Citizens in any given community, rather than the total number of users. #citizenshipIsResponsibility #weLiveInASociety
That way, everything can just be scaled to the number of players who are likely to be able to contribute, and players will want to maintain their citizenship (by popping in about once a day) so that even if they’re not playing, they’re still harvesting the #benefits from everybody else who’s contributing to the Tribe.
Oh, Kiro has a #franklyIncomprehensible mockup of some working-but-ugly “Join a Tribe” flow in the application. I can’t for the life of me understand why he’s building all of his early prototype functionality to look like some antiquated turn-of-the-century operating system. Is it an intentional stylistic choice? Is he 80 years old?
Huh, automatically generated names, huh? I know that’s one of Mer’s weird obsessions, I wonder if she’s on this project, too.