Lemmings Forums
Lix => Lix Main => Topic started by: Simon on March 30, 2017, 02:39:20 PM
-
Hi,
Lix 0.6.30 has per-level variable for number of players. This doesn't do anything at all. geoo wanted it. Let's revise what that should do. Only display markings in the editor? Prevent level start with wrong number of players? Distribute hatches to teams before examining how many teams play, then remove hatches for nonexistant teams?
Re level format: Mark hatches in the level text file as belonging to a player, or keep round-robin hatch distribution to teams? How to do neutral hatches? Neutral hatches shouldn't be distributed round-robin in the first place.
-- Simon
-
This thread is almost 6 years old, but in December, I'll start worrying about these things again.
What will happen if, in the editor, we assign hatches directly to player seats, but then, during a networking session, we want to play the level with a different number of players than seats?
- Allow any smaller number of players. Remove remaining seats' hatches.
- Allow only those smaller numbers of players that evenly divide the number of seats. Each player's lix will spawn round-robin from the hatches of several seats.
- Allow any smaller number of players. Find the biggest multiple of the number of players that doesn't exceed the number of seats. Spawn round-robin, and remove only the hatches from the division remainder of seats. E.g., 3 players play a 7-seated map. Seats are ABCDEFG. Merge seats A+D, merge B+E, merge C+F, and remove the hatches of seat G.
- Don't allow smaller number of players at all. You shall play at the god-given player count, and at that count only.
If I tie hatches to seats, I'll also tie exits to seats.
-- Simon
-
Should this be determined by the level rather than a single hardcoded behavior?
To some extent, this could be solved with multiple variants of a level (ie: levels with identical layout, but different number of players). This could get messy. Alternative: Allow a level to contain multiple seating arrangements, for different numbers of players, including a "discard" option (eg. in a map designed for 7 players, when playing with 3, it specifies that the 7th seat's exit / entrance are removed entirely, while the rest are distributed two seats per player). Then, do not allow - or at least give a visible warning - playing that map with a number of players that it does not contain a seating arrangement for. Between these two options, it allows the level designer to figure out and provide what works best for their level. The editor could also provide options to quickly set all seating arrangements based on some default pattern.
-
Playing with fewer players than seats feels uncommon enough to avoid any support for that in the level format.
Most levels need different terrain for different number of players. Existing culture is to build several independent maps with the same name, one per player count, and always pick the map for the exact count. With the different terrain, the map will look clearly different.
Situations where we play with fewer:
- No variant of that map exists for the player count. We pick the variant of the map for the next higher available count. We accept an imbalanced match over pausing the session to create the missing variant. This is rare.
- Race maps that have only a single hatch and a single exit. Everybody spawns a few lix from that hatch. I didn't think of this, then Rubix started creating race maps, and the existing format/rules haven't choked on that concept.
The concern is case 1, what to do in the rare case where we lack the map for the exact player count. My feeling is to warn before play. To allow as much as possible without offering any support in editor/format, I'd prefer to prune/merge the seats with a hardcoded algorithm. I'm tending towards algorithm #3 from two posts up, it's the most lenient.
For case 2, race maps, I'm considering to support hatches/exits that go on every seat. This special case seems worth it. For every hatch/exit, you can choose either exactly one seat or every seat. Doesn't feel 100 % nice -- why support this and then not arbitrary subset of seats.
-- Simon