----more notes on my plans for a game---

Block based physics.

I will try this and see how it goes in early testing. My initial thoughts are:

-should blocks be large or small? That is; a Lemming could be about the size of two blocks (two vertically placed). Or they're smaller so a Lemmings takes up more than that horizontally. With the former the position of each lemming is easier(?) to determine. Smaller blocks however may be easier to deal with the destructive skills and would look smoother.

Here's what chat GPT had to say about it (better than I could)

Pixel-Based Physics:
Pros:

    Precise Placement: Pixel-based physics allow for fine-grained control and precise placement of objects and characters. This can be useful for creating intricate levels with detailed designs.
    Smooth Movements: Since the physics are calculated at the pixel level, the movements of the characters can appear smoother and more fluid, resulting in a visually appealing experience.
    Detailed Interactions: Pixel-based physics can enable detailed interactions between objects and characters, allowing for more complex gameplay mechanics and puzzles.

Cons:

    Performance: Calculating physics at the pixel level can be computationally expensive, especially for large numbers of objects or complex interactions. This can impact the game's performance, particularly on lower-end devices.
    Limited Block-Based Mechanics: Pixel-based physics may not lend themselves well to block-based mechanics where objects interact at a higher level, such as pushing blocks or creating structures.

Block-Based Physics:
Pros:

    Simplified Interactions: Block-based physics simplifies the interactions between objects, allowing for easier implementation of mechanics like pushing or stacking blocks. This can lead to more accessible and intuitive gameplay.
    Performance Efficiency: Calculating physics at the block level can be more computationally efficient compared to pixel-based physics, particularly when dealing with larger levels or numerous interacting elements.

Cons:

    Reduced Precision: Block-based physics can lack the precision and fine control of pixel-based physics. This may limit the complexity and intricacy of level design and gameplay mechanics.
    Visual Limitations: Block-based physics can result in less visually detailed movements and interactions, as objects are constrained to block-sized increments.

Ultimately, the choice between pixel-based and block-based physics depends on the desired gameplay experience and the specific mechanics you want to implement in your Lemmings-style game. It's worth considering the trade-offs between precision, performance, and visual fidelity to determine which approach best suits your game's design goals.

@namida I'd love some more thoughts on this; or is there plenty of it in your threads on the matter (regarding L3D)? I haven't followed those closely until now.

--------------

Some other topics:
I agreed with Nester's view, when he was still around, that the game design and integrity should take precedence over "existing content" which can and should change if the need arises.

I decided to completely cut time limits and changeable RR/spawn interval from the game like Simon did with Lix (except maybe in a few edge cases but that remains to be seen).

carrying on from my first post:
The reason I don't believe in "true physics mode" is because I think the game should be designed such that it isn't necessary. Skill shadows are in a similar vein but a bit different but I'm not in a hurry to implement this; Lix doesn't have it after all and I never felt that I missed it terribly.

More generally; I honestly feel that both games (NL and Lix) have too much complication in their "ease-of-use features". This is just my personal preference yes. I think the game (level design in large part) should be simple enough that the magnitude of features we have in NL today aren't really necessary. Of course I want the game to lack the dullness and tedium that L1 had. But a lot of this can be mitigated by level design. For example you wouldn't rely so much on fast forward if your level simply didn't have a pointless long walk to the exit. My game will likely still have a fast forward, fyi. Although playing the game Temporal gave me the idea of having instead a "speed setting"

As for myself; a clone, no, but I am interested in hacking the game/fixing bugs/getting a level editor working.
In the coming days I'll try a few things out and give updates if it looks even remotely hopeful.

In the meantime here's work that's been done so far:

https://www.lemmingsforums.net/index.php?topic=1439.msg38226#msg38226

I started messing around with Chat GPT 4 recently. I gave it this puzzle:
https://www.lemmingsforums.net/index.php?topic=1389.msg39003#msg39003

It gave the correct answer; its description of the process was pretty thorough as well; more detailed than mine and used two tables. Of course this was a while ago and I can't remember exactly how I solved it myself except what I wrote there, but my description was much shorter than chat GTP's.

Next I gave it this puzzle;

https://www.lemmingsforums.net/index.php?topic=1389.msg96371#msg96371

This was the answer:

The minimum number of knights required to put on an 8x8 chessboard such that they attack every vacant square is 32. Here's one possible arrangement that achieves this:

mathematica

N . N . N . N
. N . N . N .
N . N . N . N
. N . N . N .
N . N . N . N
. N . N . N .
N . N . N . N
. N . N . N .

In this arrangement, the knights are placed on every other square of the board, such that they attack all the remaining squares. It's important to note that the knights only attack squares that are not occupied by other knights, so we can't simply place 64 knights on the board to cover every square.

Also, this is the minimum number of knights required to cover all the vacant squares on the board, but it doesn't necessarily mean that it's the only solution. There may be other valid arrangements that achieve the same result.

I then asked if it could do it with "all knights themselves are attacked by other knights" and the answer was; no none can be placed and then I realized why it got it wrong but I don't know how to word this correctly.

I was confused at first as well until I realized the question is... well as I said I don't know how to phrase the question correctly, but it is missing a bit of information imo, in the statement of the problem. Chat GPT is solving it as if each square can only be taken in one 'instance'.

also an oddity: why it "forgot" the last column on the chessboard? I'll ask it that later.

I've been getting into Nikoli-style logic puzzles recently, solving a few when I have the time, but I also went ahead and created some of my own puzzles. They're nothing too fancy, but I'm pretty happy with them for a first attempt. They use a ruleset which combines Simple Loops with Nonograms. I dub it, the Nonoloop.

Next I might try the loop puzzles and nonograms and other puzzles but idk if drawing and images is possible with this version I'm using.

Btw; those puzzles are fun but tough! I started trying one myself at work today

I'll plan to join. It's been a while since I played.

Gin Rummy (and many variants of Rummy) was common here in U.S. My favorite to play was so-called "Contract
Rummy". Works similar to 'plain' Rummy except as follows;

1) there are a set number of rounds, the version I played always had 5.
2) each hand has a specific assortment of hands you need to make before you can discard, to go out (get rid of all cards, thus ending the round). 2 sets or 2 runs or 1 run and 1 set etc. I can't remember the exact rules for each round anymore except that it got  more difficult as the game progressed.
3) I don't remember if this was singular to this particular game or not but a player could "buy" a (1) card from another player by taking another card from the pile, but only 1 per turn or something like that.
4) Every round played like normal rummy (players lay their cards down whenever and first person to throw their last card away ends the round). But the final round functioned like Gin Rummy; in order to lay out you have to have all the cards in your hand fit the contract, thus the first person to lay out also ends the round and everyone else is stuck with all the cards in their hand.

The rest I think functions mostly like Rummy. After the final round the player with most points wins.

There's also this game called Rummikub; which I never played but looks like a mix between Rummy and dominoes... no idea how it works.
https://en.wikipedia.org/wiki/Rummikub

here's another Yatzhee like game I've not really played but heard of:

https://en.wikipedia.org/wiki/Farkle

Yes, can reproduce in Chrome. Ticker shows all lines, then loads the forum title image, then ticker cuts to 3 lines of the first message. The entire board listing happily jumps around.

I want to cut the ticker altogether from the page, server-side, for everybody. It's outdated, 22th level design contest was over a year ago. Important stuff shouldn't roll in and out anyway. And moving stuff is distracting regardless of its importance. What do others think?

-- Simon

this is the second time I've heard someone say something along these lines "moving stuff is distracting". Some one said such about animating gif avatars. I never found this so in the slightest...

anyways I don't care about the news ticker

I took a peek so far; looks great! intriguing levels. I look forward to playing through this properly! [as much of it as I can]. Is the difficulty greater or lesser than QFK2? I've played part way though that (great pack once again).