I'm working on a similar problem, and I've decided to use a unique id number set. bassically you set a party id variable that changes as you add or drop characters from the party. every time a character joins the party you add their unique id to the party id, and when they leave you subtract it. in order to make it work with each possible party configuration generating a different party id you need to use a binary progression. so the first character you can add to your party is id = 1; the second is id = 2; the third is id =4; the fourth is id = 8; fifth is id 16 and so on. that way when you add the numbers there is only one possible party configuration that could lead to the party id you have.
With the five possible character listed above you could have char 1, 3, and 5 which would yield (1+4+16 = 21) no other combo of characters would equal 21 so you know you have those three character in your party. This would not tell you which order they were in, just that they were in the party. Also, given the scale of this set up, you should put any calculation to determine party members into common events to save time.
The upside of this method is that you can check which members are in your party with a single variable, the downside is that the number of possible combinations grows quickly as you add party members. for example, with the five party members above, there are 15 party id's that contain char 1 - they are:
1 (the character by him/herself);
3 (Char 1 and Char 2);
5 (Char 1 and Char 3);
7 (Char 1, Char 2 and Char 3);
9 (Char 1 and Char 4);
11 (Char 1, Char 2 and Char 4);
13 (Char 1, Char 3 and Char 4);
15 (Char 1, Char 2, Char 3 and Char 4);
17 (Char 1 and Char 5);
19 (Char 1, Char 2 and Char 5);
21 (Char 1, Char 3 and Char 5);
23 (Char 1, Char 2, Char 3 and Char 5);
25 (char 1, Char 4 and Char 5);
27 (Char 1, Char 2, Char 4 and Char 5);
and 29 (Char 1, Char 3, Char 4 and Char 5)
31 would be all 5 characters together, so with the default party size of 4 you should never get this number.
