I'm at a loss. How should I handle parties?

ID:265945
 
Oct 28 2009, 9:18 am
Or groups, however you prefer to call them. I was thinking:
mob
    var/list/party
    verb/create_party()
        if(src.party) src<<"A party was made by you already!"
        else
            src.party=list()
            src.party["People"]+=src
            var/pname=input("What do you wish to name the party?") as text
            src.party["Name"]=pname

Basic, I know. Probably much better ways of handling it too, but that was just an idea.
Oct 28 2009, 9:23 am
You might want to take a look at the mob/group variable.
Oct 28 2009, 12:27 pm
In addition to Nadrew's suggestion, if you want to have plenty of functionality behind the party, make a datum for it.
[link]
Oct 28 2009, 12:54 pm
Use the forum search to look for example implementations of parties, guilds, clans... it's all the same thing.
At the basic level you can just use a list to represent the group, for more complex and feature-ful implementations you'd use a datum to do so. As Nadrew hinted, you can choose to include the built-in group list in the matter, which has the benefit of being available to use in verb src settings (and it also has a special handling by default in mob/Bump()).
Whether you choose to use a list object or a different (datum) object, ultimately you only need to keep one object per guild, no matter how many players are in that guild; the reference to the single object will simply be reused by all the members.

Quick implementation examples (among other things, I skipped saving&loading, which need to be handled specially, handling of offline guild members (which requires you to store a list of guild member keys, perhaps together with character identifiers/names) and giving the guild verbs only once the player is actually in a guild):
List:
var/list/guilds = new
mob/player
   var/list/guild_members
   verb/Create_Guild()
      src.guild_members = list(src) //the first member in the list is the leader
      guilds += src.guild_members //add the list representing the guild to the master list of guilds, which would be saved

      //you could actually name the list (and guild) using tag:
      //src.guild_members.tag = "guild name" //you can then find it with locate()
   verb/Guild_Invite(client/C as anything in players) //assuming you have a global players list
      if(!C) return
      if(src != src.guild_members[1])
         src << "You're not the guild founder!"
         return
      src.guild_members += C.mob
      C.mob.guild_members = src.guild_members //copy the list reference over
   verb/Guild_Say(msg as text) src.guild_members << "[src]: [msg]"
   verb/Guild_Leave()
      if(src == src.guild_members[1])
         src << "Guild will be disbanded"
         for(var/mob/player/a in src.guild_members)
            a.guild_members = null
         guilds -= src.guild_members
      else
         src.guild_members -= src
         src.guild_members = null

Datum (an article about datums): 
var/list/guilds
guild //this is defined on the base/leftmost level, so it's a datum object, not an obj mob or even atom
   //we use this object to represent our guild. it keeps \
     track of the info the guild needs to know, such as:
   var
      name
      list
        members //these 2 vars are defined as of /list type
        houses //whatever houses the guild might own
      rank //rank or possibly score of the guild
      money
   New(name,mob/player/leader)
      ASSERT(name && leader)
      src.name = name
      src.members = list(leader)
      guilds += src
   proc
      AddMember(mob/player/newmember)
         newmember.guild = src
         src.members += newmember
         newmember << "You're now in the [src.name] guild!"
      RemoveMember(mob/player/member)
         if(!(member in src.members)) return 0
         member.guild = null
         src.members -= member
         member << "You're no longer in the [src.name] guild."
      Disband()
         for(var/mob/player/p in src.members)
            p << "Your guild, [src.name], has been disbanded."
            p.guild = null
         guilds -= src
      Message(t) src.members << t     

mob/player
   var/guild/guild
   verb/Create_Guild(name as text)
      if(!name) return
      var/cname = ckey(name)
      if(!cname) {src << "Bad name.";return}
      for(var/guild/G in guilds)
         if(ckey(G.name) == cname)
            src << "A guild with a similar name already exists."
            return
      src.guild = new /guild(name,src)
   verb/Guild_Invite(client/C as anything in players) //assuming you have a global players list
      if(!C) return
      if(src != src.guild.members[1])
         src << "You're not the guild founder!"
         return
      src.guild.members += C.mob
      C.mob.guild = src.guild //copy the datum reference over
   verb/Guild_Say(msg as text)
      src.guild.Message("[src]: [msg]")
   verb/Guild_Leave()
      if(src == src.guild.members[1])
         src << "Guild will be disbanded"
         src.guild.Disband()
      else src.guild.RemoveMember(src)

Design note: guild/group belonging is something that you may consider attaching to a player by player identity itself (by key, and if wanted computer_id and as such) instead of attaching it to each character separately (which means a player could be in different guilds on different chars). Doing so would mean the variable isn't declared on the player's mob but on his client, and is so saved and loaded separately, and always is, irregardless of which character the player decides to load. BTW, this is something that should always be done with punishments (muting, etc), though people commonly do the silly act of relating punishments to the mobs.
Oct 28 2009, 1:07 pm
In response to Loduwijk
Loduwijk wrote:
[link]

I'd just like to point out that new datums are defined by putting them at the 'leftmost indentation level', i.e. under no node at all, like so: 
datum_name
   //stuff on the datum

Therefore, writing this: 
datum/datum_name

Actually ends up defining 2 new datums; one with the type path /datum (that's right, apparently; a /datum entry will appear in the object tree, and it's not normally there, meaning it might not normally even fully exist, although you can define and override stuff under /datum and use it as a type path), and one under it with the path /datum/datum_name (not /datum_name).
Oct 29 2009, 5:15 am
Oct 29 2009, 5:41 am
In response to DivineTraveller
DivineTraveller wrote:
Shameless self plug:
http://www.byond.com/developer/DivineTraveller/PartySystem.

I'm not saying mine is in anyway better or worst, I just thought that you could read over it to gain a better understanding...

http://www.byond.com/developer/Haywire/H_Groups