I have attached an image to this post showing my favorite Bard's Tale 3 party fighting an early game enemy. What do you think of my party? Do you think it's balanced? Do you think this would be a good party to play through the game with?

(If requested, I could tell you the classes of my characters.)

I think it could use a Bard.
And another spellcaster.
And a Monk.
And another spellcaster.
And a Hunter.
And another spellcaster.
And a Rogue.

Other than that, it looks just like the party I start the game with. :)

Who would you suggest I replace with these characters? I would prefer not to increase the size of this party. There's the old saying "zero's company, one's a crowd", right?

Another question I just thought up:

If I somehow managed to win a battle with this party, what would happen when it comes time for the game to divide up the experience between the (0) survivors?

Testing this would probably take either save state editing (for example, to set the program counter for the routine that's called after battle victory) or finding and using an arbitrary code execution exploit (I think the DOS version *might* have one, based on what I read on another forum).

Each character would get 65280 XP and 65280 Gold, because that where it maxed out. In BT2, anyway. (Those are burned into my memory after lots of fights with Miracle Mages, and it's also FF00 in hex.)

That cap isn't the case in all versions.

In the DOS version, XP and gold can get much bigger; I saw a video where the player earned over 200k XP per character after a fight with Dream Mages.

In the Apple 2GS version, the cap is actually 65,535 (FFFF in hex).

In 8-bit Bard's Tale 3, the cap is 100,000 (though getting over 65k from a single group of enemies will result in integer overflow and give you much less XP than you should); in 16-bit Bard's Tale 3, there is no such cap, as far as I am aware.

So, there are again version differences here.

(You are in a maze of twisty Bard's Tale versions, all different.)

Actually, I have thought of another reason I am unsure what would happen; different games and hardware behave differently when division by zero is attempted. Some behaviors I am aware of are:
* Division results in the largest possible value (Final Fantasy 6; possible by using Mantra/Chakra on a single enemiy); this would lead to the outcome you mention.
* Division results in 0 (SaGa 1 and 2; possible in 1 if a human's stat overflows to 0 and you try to increase it again (it increases by +2 in this case), and in 2 it always happens if an enemy uses the DNA attack (damage = target's HP divided by 0 plus a small random amount)).
* Division crashes the game (Civilization 2; using cheat menu to set a city's size to 0 (makes it disappear from the map) and then trying to take over the city).
* Division softlocks the game (Pokemon Red/Blue/Yellow; if attacker has >= 256 attack and defender has <4 defense, the damage calculation divides both values by a factor of 4, then tries to divide the resulting attack by defense).

So, as one can see, when a computer tries to divide by zero, the resulting behavior isn't always the same.

(This is just integer division; floating point division creates infinities, which could confuse a program not expecting them.)

I'm quite familiar with the floating points mucking things up, even when they're not going to give you an infinity. Fractions that are symbolically equal have given me "no, those aren't equal!" often enough that I always add in a little bit of a buffer when comparing floating points. Use a check like "abs(x-y)<1e-10" for equality.

Getting back on topic, as it were, I had the Apple IIc versions of the games back in the day, and that one topped out at 65280 XP and gold. Was the IIGS version different from the IIc?

It does appear to be a small difference here; the IIGS vesion caps out at 65535, just 255 points more. (This applies to both BT1 and BT2.) So, yes, there is a difference. (Also, the 2gs version has much better graphics than the 2c version, looking more like the DOS and Amiga versions; sadly, no 2gs version of the third game was released.) Of course, there's the risk of dividing by the difference between two floating point values. If, by chance, they happen to be exactly equal, you could end up with a division by zero, and therefore an inf or nan value.

Here's a video (not mine) that shows Super Mario 64 crashiing in this situation:
https://www.youtube.com/watch?v=8jd3A2euOjg