Some video footage:

https://www.dropbox.com/s/oom4k2v3l1jcd8o/Loap%202022-01-21%2010-01-47.mp4?dl=2

- While the framerate is capped, the camera movement with the mouse becomes very choppy and unpredictable. I switch to using keyboard briefly in the middle of the footage to show that works fine, then switch back to mouse.

https://www.dropbox.com/s/05i6ayfvm56dwtu/Loap%202022-01-21%2010-09-02.mp4?dl=2

- Shows that some frame skips still occur during gameplay if you watch closely.

I've updated to 0.0.5.1 as of this post

Some graphics rendering stuff. Take a Dive seems like a good level to use when trying to squash some of the current sprite-rendering bugs.


- Barrels rendering over the slope, and over the head of a lemming (Image 1-1 & 1-2).
- Barrels cutting into a slope (Image 1-2).
- Lemmings partially cutting through slopes and deflector blocks (Image 1-3).
- Also included one of Lemmings being gobbled up by slopes when traveling on them across-ways (Image 1-4).


- The lighting creates these random darker spots on the lower layer of blocks in It's A Run Around. Looking up videos of the level played in L3D, I don't see these spots, so they might be something funny with how lighting is being calculated? (Image 2-1) (EDIT: Pooty demonstrated these exist in the actual game.)


- The level preview for The M-A-Z-E is significantly off-center. (Image 3-1). It's also off center and too low for Attack of the Fifty Ft Lemmings (Image 3-2).
- Lemmings that touch mud in The M-A-Z-E die via electrocution instead of drowning. (Image 3-3)


- Some of the camera starting positions feel incorrect. In particular, they feel too low. You shouldn't start with a face full of tree in A Short Cut Through The Forest for instance (Image 4-1) Another where you can see it is Down the Middle We Go. I included loap (Image 4-2) a video with the original (Image 4-3) for reference.

Since the source is up, I've been playing around with a bit ahead of the official demo. I intend to do more tomorrow, but I couldn't help doing a little tonight. Time to nitpick!

Performance / Controls

1. Camera rotation seems to be tied to the framerate in some way? When the framerate is extremely high (over 1000 FPS), mouse rotation becomes extremely low sensitivity, where large mouse moves barely cause a rotation, but when I cap the framerate to 120 using the nvidia control panel, the sensitivity feels much more normal. Doesn't seem intended.

2. The game hitches for about an eighth of a second every 2-3 seconds, but inconsistently. I thought maybe it was doing it when it reads and prints the FPS reading to the console, but it doesn't always line up with that. If the camera is moving or rotating during the moment a hitch happens, it 'keeps its momentum' during that moment, causing the camera to suddenly jump. The effect is greatly exaggerated (multiplied?) at high FPSes, causing such hitches and jumps to be extremely noticeable. Hitches can be observed just by waiting on the level selection screen or level preview too, but seem to be much more infrequent compared to active gameplay.

3. Although the game physics are capped at 30 FPS, the rendering isn't, so currently the game maxes out the CPU core or GPU (whichever ends up being the bottleneck on the given system). This is fine currently, particularly since the FPS is useful for assessing performance at this stage, but consider adding an actual Frame cap or Vsync in future for people who don't want the game using unnecessary resources.


Blockers / Turners

4. In L3D, assigning a blocker or turner would cause that lemming to become a blocker/turner at the edge of that block no matter what. Currently in Loap, if you assign the skill in the last quarter or so of the block, they'll keep walking into the next grid square before becoming a blocker/turner. Visually, it looks like you moved the turners away from the block edge, so I suspect this is actually an intended change, but I wanted to make sure? If this change is kept, it might be worth considering if any puzzles are impacted by this (e.g. assigning blocker/turners directly out of a fall from a ledge / builder bridge for instance).

5. Following on from #4, if you assign a Turner to a lemming that is about to fall off a ledge, the lemming will not become a turner (either on the ledge, or after they land) but the Turner skill will still be consumed. This is probably true for Blockers too, but I didn't confirm for sure.

6. Related to #5, if a lemming is between two blockers on the same square (e.g. by assigning a blocker either side of the starting hatch), then Loap lets you attempt to assign the trapped lemming as a blocker and consumes the skill, but they'll never actually become one.

7. In L3D, if two lemmings were bunched up, assigning one of them as a turner while they were in the first half of a grid square (in the direction of travel) would cause the turner to turn the other lemming. This trick is used in LP3D Wafer Walkway, for instance. Currently in Loap this doesn't work - the trailing lemming always ignores the turner and goes through, even if you assign the turner as early as possible, as described in #4.

8. In L3D, two turners on the same grid square pointing the same direction could be used to simulate a blocker, and two pointing into each other would catch and compress the crowd. Neither trick currently works on Loap. Lemmings will turn at the first turner they encounter, and ignore all subsequent turners on the same block, walking through. Turners inside of splitter blocks or immediately adjacent to deflector blocks are ignored in the same way.

9. In L3D I don't think you could 'overlap' a blocker and turner by assigning both to the same edge. Currently you can in Loap, as seen in Attachment 1. I might be misremembering, though.

Cloners are fine, imo. The reason preplaced are disallowed is because the idea of the rule is that the lemmings all come from one starting location (the entry) but have to be evenly split among the exits.

I don't have a mic at the moment, so it wouldn't be for at least a few days... but would anyone maybe be interested in trying Keep Talking and Nobody Explodes?

For those unfamiliar with it, it's a communication-focused co-op puzzle game about defusing bombs! One person is the 'defuser' while one (or more) people are 'experts'. Experts can see the manual which has the instructions on how to disarm the bomb, while the defuser can see and manipulate the bomb itself... but the experts can't see the bomb and the defuser can't see the instructions, so it's all about communicating info back and forth to disarm it successfully!

Anyone can be an expert, even if they don't own the game, but you need to own the game to be a defuser. I might be willing to gift it to people. Expert is better for people who like math and solving puzzles. Defuser is better for group leaders, and people who like interacting with stuff. Of course, if multiple people own the game, you can swap back and forth. Can be played with 2+ players, I think 3 (1 defuser + 2 experts) is the ideal number, but I have no problem playing in a group of 2 or 4+ too.

I won't necessarily know what days I'll be unavailable until the day before. However, on days where I am available, I am available for a very big chunk of time. 6AM-8PM AEST comfortably. That's 1PM-3AM pacific, 4PM-6AM eastern, 9PM-11AM british.

EDIT: I got a new headset much earlier than I thought. Today, in fact. So I'm good to go whenever.

Feel free to post for round 1 if you'd like too. Nothing saying you can't do that.