Jump to content

Why the "ten party member" goal? If you're going to do it, support arbitrary size!


jcompton

Recommended Posts

So it's come up twice today--once while browsing the GemRB wiki, and now when Lynx just mentioned it--why is the pie-in-the-sky goal for eliminating the six-character limit a ten-character limit?

 

If you're going to go through the trouble of dealing with the six-character cap, surely it would make more sense to do away with any fixed limits, and at the same time make it possible to process script triggers/actions more efficiently over a party of arbitrary size.

 

Borrowing what I've already said on the subject on the Beamhaul forum:

 

Removing party limits would, among other things, require a number of new scripting operations which target all members of a party generally. Infinity scripting can do some operations over a party (such as TakePartyItem, etc) but there's no general case in the scripting language to iterate one command over the player party (or an arbitrary group of creatures, items, areas, etc.)

 

That's one of the reasons that simply removing the mechanical six-character limit wouldn't make an Infinity game playable by a party of seven or 17 characters: Infinity scripts are loaded down with stupid (but necessary-given-the-script-language's-constraints) grunt work like

 

DoSomethingTo(Player1)

DoSomethingTo(Player2)

DoSomethingTo(Player3)

DoSomethingTo(Player4)

DoSomethingTo(Player5)

DoSomethingTo(Player6)

 

In an ideal world you'd have some syntax like

 

IterateMyCommandOverThisList(DoSomethingTo(), [ListOfPlayerPartyCreatures()])

 

(seriously, the ability to iterate a script command over any arbitrary list is hugely powerful, and I strongly recommend it.)

Link to comment

The 10 I mentioned was arbitrary, so do not worry.

 

The thread linked from the wiki is more informative - bigg suggested hacking weidu, but I don't have any will to learn ocaml. In the long run this solution would of course be better and more compatible with mods, but I'm pretty sure some smart regexing and manual handling of outliers is a good enough approach for the first implementation. Definitely easier and faster. Maybe even less fragile if you consider the horrible action system we're dealing with.

 

Adding new actions and mechanisms is possible, but wouldn't the original engine choke on them? I doubt Tobex has such reach and we definitely don't want to require all modders to add gemrb ifdefs or separate versions of files to their mods.

 

GemRB already is pretty liberated from the hardcoded number and there'd mostly be gui work on our side to fit the portraits (someone already started on that, but vanished). Beyond 8 some new actions would have to be added (PlayerXFill for example), but that's just a copy/paste job.

Link to comment

Adding new actions and mechanisms is possible, but wouldn't the original engine choke on them? I doubt Tobex has such reach and we definitely don't want to require all modders to add gemrb ifdefs or separate versions of files to their mods.

 

Oh, it would certainly choke on them. For all the reasons I keep trying to explain to everybody on the Beamhaul forum, trying to get past the six-character limit in a published game is ridiculously difficult. But if you're going to do it, then you'd pretty much end up with the definitive platform for people who don't like having to choose party members...

 

The easiest would be to add some actions that work on whole party.

Like LeaveAreaLUAParty, CreateVisualEffectParty, etc.

 

You'd also need some sort of way to deal with cutscenes and the like which rely on moving player1 to a certain spot, player2 to another nearby spot, and on and on and on. Essentially instructing the party to do an in-formation move to a spot and letting the pathfinding work out the details. (Something like a generalized version of Leader/Follow, which I actually didn't know about until I just looked it up in IESDP... and presumably the new action would have to, y'know, work.)

Link to comment

We're in beta and not bound by money or deadlines, so we do get to experiment and try more dangerous things. I can easily understand their reluctance, since they're also working with a worse codebase in this regard.

 

For the formation movements you mentioned, I planned to just jump everyone on the same coordinates as Player6 and leave the details to collision detection. It would only be problematic when there's really not enough space, but I can't think of any cases of that except for possibly the multiplayer CI start.

Link to comment

Having the option for more members engine-wise would be a great step anyway. It would mean that if anyone does generate a new game or suchlike, they could have the larger party size without worrying about the scripts because they won't be using any of them. You could also feasibly have the party size extended temporarily in-game, for example in a mission where you have an additional temporary party member. This would not reach the goal of making the whole game playable with 7+ characters, but it would be a major hurdle.

 

When it comes to the scripts, a lot can probably be automatically patched. A lot of specific cases, like anything which jumps the party to a new area by member could probably be detected and extended easily. Combat scripts could all be extended to have a NearestEnemy or a PC mask target in them somewhere. The problem is that there would surely be things which would slip the net that way.

Link to comment

For new games the limit is already at 8 and really trivially extended (just some copy/paste).

 

I actually started looking at this again just today and a single regex reliably takes care of most cutscenes and some other scripts (caveat: haven't checked dialogs yet). Turns out pcs are rarely mentioned in triggers explicitly. :)

Link to comment

Frankly, I never saw the need for having more than 5 minions. To be honest, one or two are hard enough to deal with, even if you don't micromanage. And if you don't do that, the fools will likely get themselves killed more often than not. That's fine if it's a handful of rogue archers backing your ass, but how many of those minions do you need? 8? 10? Give me a break. Summon Undead, Conjure Animals/Elementals/Demon Princes etc.... that stuff is good enough if you just need more muscle in a major battle. And if you don't, it's just an unnecessary hassle.

 

Honestly, GemRB dudes, I don't see the point, and I don't see why anyone else would either.

 

"Oh but I can have more storylines/romances and whatnot!" Well fine, either play more than one game or drop/recruit people as you need. The problem with expanding the party size to 10 (or whatever) is that *that* would not be sufficient for folks like that. As many NPCs as there are, they'd have them all following in their wake. They'd be leading a legion of slaves to the tune of hundreds, or even thousands. That's just wrong.

Link to comment

For me, it's not about extra dialogs, mod NPCs are already verbose (bordering on too much). It's not about having more muscle either — since there will be less XP per character, the difficulty will actually increase in high level encounters. That's one of the benefits, another being being able to try larger class/kit combinations.

 

It's one of the most often requested features, but I don't really know why.

Link to comment
It's one of the most often requested features, but I don't really know why.
Well, everyone else has refused...

 

Frankly, I never saw the need for having more than 5 minions. To be honest, one or two are hard enough to deal with, even if you don't micromanage. And if you don't do that, the fools will likely get themselves killed more often than not. That's fine if it's a handful of rogue archers backing your ass, but how many of those minions do you need? 8? 10? Give me a break. Summon Undead, Conjure Animals/Elementals/Demon Princes etc....
So you don't see any benefit of having a single class: 3 front liners, 2 divine casters(healers, etc), 2 mages and a rogue.

Yes, the mages can summon the front liners... but that's like a 1000-10k summon spell per a game... and indeed the variety of the single class characters come out best when you give them small room enough to shine.

Link to comment

Honestly, GemRB dudes, I don't see the point, and I don't see why anyone else would either.

This is an engine. The fewer the hardcoded limitations, the better the engine.

I don't really see much use of more than 8, but i think entirely removing the limit and implementing whole party actions would even benefit the regular 6 slot games too. As you don't have to write 6 actions, just one.

Link to comment

The most common occurence is ActionOverride though, which is a pseudoaction and can't be easily done in sets. Most of the time it is used with LeaveAreaLua* actions, which could be merged, like tob introduced a merged AddXPObject (AddXPParty or something like that).

 

Frequency distribution of Player6 mentions in a plain (or fixpacked?) tob install:

1 AttackReevaluate

1 !CheckStatGT

1 Detect

1 Dialog

1 Died

1 !InParty

1 InPartyAllowDead

1 PolymorphCopy

1 !Range

1 ReallyForceSpell

1 SetGlobal

1 Spell

2 Entered

2 Global

2 See

2 StartDialogNoSet

3 ApplySpellRES

3 CreateCreatureObjectCopy

3 IsOverMe

3 Kill

4 FakeEffectExpiryCheck

4 HasItemEquipedReal

4 Range

5 ClearActions

6 ForceSpell

9 MoveToObject

14 ApplySpell

14 !StateCheck

16 CreateVisualEffectObject

16 CutSceneId

29 GiveItemCreate

29 InMyArea

30 TakeItemReplace

40 AddXPObject

63 HasItem

425 ActionOverride

Link to comment

True.

 

Also, those HasItem checks are almost all about dealing with disintegrating drow equipment, which could've been done much more cleanly with a separate action and a 2da to list the relevant items.

 

iwd2 also has advanced scripting, while the other games have so few mentions they could be fixed by hand (pst only 20!) without it being cumbersome. I already have a script though ...

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...