I've mostly played what I think is typically called Rummy 500, which rather than solely holding cards in your hand you instead play your sets visibly, and can play cards on the other player's sets as well. It also involves being able to pick up one or many cards from the discard pile. I enjoy the additional strategical elements that it involves. In general I prefer this version to Gin, but still enjoy both.

Rummikub is pretty fun. It kind of plays like Rummy (you're trying to make sets of at least three matching/three in a row), but one of the things I like most about it is that you can mix and match tiles that are on the board as long as everything ends up a valid set. So for example if I have a a red five, blue five, and green two, and the board has a green 3-4-5 set, I can play my 2 at the front to make it 2-3-4, then yoink the 5 to make a 5-5-5 set as well. Sometimes I'd end up rearranging half the board just to get one or two tiles out of my hand.

So I was thinking of a different approach to the graph problem, but I kept hitting snags in my logic so I might think that over longer.

For Geoo's issue, I'm not sure if I 100% understand the priority orders you laid out. I think I figured out your initial example and was just conceptualizing it differently. I'm still unclear on the second example. You first say that the hatches would go A1, B1, A2, C2 as 1,2,3,4 respectively, but in the side by side examples it looks like A1 is 1 and B2 is 2? I also don't really follow how the rearrangement happens there. Not sure if I'm just missing something.

Here's some thoughts, based on my assumption of how the ordering works:

I might join, not sure. I'm currently trying to grind through some stuff in another game before some time limited content, so I'll see how much of it I get through during the week. If you end up light on people I can probably be persuaded to join, though.

Debian wants you to only make major updates every 2 years? Dang, that's a heck of a lot to ask for software dev, especially in this day and age...Though, admittedly I'm unfamiliar with most things Linux, so maybe this isn't that weird.

Anyway, on the dev side of things, I think that there might be some middle ground to the two plans.

I think that reworking the server to allow multiple versions to connect to it but only allow connections to the same minor version makes sense to add in general, even regardless of Debian stuff. It might be the case that not everyone updates instantly even on other platforms (since far as I'm aware there's no auto update), and it might also be the case that you want to have someone help you test a beta feature or something without worrying about what happens if someone else mistakenly joins the server. Making this change I think can be what allows you to make riskier changes without worrying about the Debian problem.

On the topic of the level format, from my experience I would say that changing a format like that is generally the last thing I want to do, as it just causes so many headaches (what to do with old data, etc), so I would say it's at least worth exploring how something can fit in the existing format before just changing it. That said, sometimes there's just nothing you can do no matter how malleable you tried to make the initial format because of things you just didn't think about. It can be kind of a balance here; sure, you might spend X amount of time exploring how the new feature could fit in the old format, but if it takes 3X time to design the new format/change the parsing code/figure out how to handle old formats, then it might not be worth it. One thing maybe worth considering also is if you can support multiple level parsers in one version (I know nothing about how the levels are parsed now). Could it be possible to add some 'format version' to the level layout that tells the parser how to handle any given level (and assume anything without this field is the old format). Maybe not the most elegant, but sometimes better than worrying about how to update all the existing data somehow.

Another thing with experimental features, in relation to whether or not to worry about spending time making it agree with the rest of the software; you could always do a quick and dirty version of a feature first as a test (does the feature work well, is it actually as fun as we thought, etc) before doing a second pass to make it 'fit' better if needed. It obviously would require a bit of rework, but sometimes after making something once when you take a step back and think about how you would design it again I find that I have a better understanding and better ideas on how to go about it, so it might be easier to fit it in more agreeably when you already have a general understanding of what needs to be done. Also, in relation to not wanting to cut something in an experimental version, don't be afraid to cut a feature if it doesn't turn out well in testing. If a feature just isn't fun, or doesn't work well, or whatever, don't let it hang around just because of the sunk cost fallacy.

Anyway, this ended up a bit more long winded then expected Some of these are probably already things you've thought of, but figured it was at least worth stating in case you hadn't. I'm likely not the best coder here, but I'm always happy to bounce ideas around if you need more eyes. I even wouldn't be against getting my hands in there, but not being familiar with the source language might make that a bit trickier.

(unrelated, but I tried the 4 box puzzle that was the previous one for fun, here's my working out if anyone is interested)

For the current puzzle, going off Simon's post:

Apologies for the delay on these, been all over the place the past week. Here's the double team map pack. I did actually make a fix so that the chute is a 2px gap rather than 4px, to prevent the bridges that work for only one player. I also added even player versions just for completeness (except 2 players, because that seemed pointless, but maybe it could be interesting? I dunno).

Small disclaimer: I ordered the hatches/exits directly in the text file because it was easier than moving all of them around in the editor, but I did give them a once-over and I think all of them are in the right place. We can keep an eye out if anything is misplaced when playing, but i think it should be fine (honestly it's probably more likely everything is correct than if I moved them manually).

I can also include the original versions if you want, just in case, but I think the new versions should probably be fine.

Also, is there a file structure I should use for future reference? Right now it's just a zip with all the files in one folder, is it easier for you if I split them out the same way they're structured in the level navigator (with the network/user/#p structure?) or something along those lines?

Yeah, it seemed like something that wasn't unique enough an idea that it wouldn't have possibly come up/been used in other Lemmings games (I'm not really that familiar with Lemmings), but figured it was worth suggesting because it seems like it would be a fun thing to have.

Having them grey was my initial though, but since there's already so many colors in MP wasn't sure if that was something that would be good or not. One thought was it could be bad for colorblindness, but to be fair multiplayer as a whole likely would be anyway so maybe that's not really a big deal and grey is fine.