Skip to content

Conversation

@hleb-rubanau
Copy link

@hleb-rubanau hleb-rubanau commented Jan 11, 2026

A new example includes implementation of grid-based puzzle game focused on revealing cells while avoiding hidden traps. :)

This greenfield implementation is named Trapsensor to avoid any trademark issues.

Patch is submitted against sprint_perf as its the latest stable code merged into upstream.

Codebase complexity issue

While this example provides complete implementation of classical gameplay, there is a notable pitfall: codebase size

I am not sure the 660-lines monolith, even if well-structured, is suitable as-is for educational purposes, and am open to discuss possible simplifications. However, any I could think of all come with tradeoffs:

  1. Removing extra functionality (switching difficulties, floodfill) would only neglectably reduce the codebase size, while making experience much less playable. Its worth to admit that Daniel asked for stripping initial version of flood-fill anyway, to be itroduced later. But floodfill is just about 10 lines of code.

  2. Flattening functions structure may save some space... but not reduce cognitive load. There will be less separation between state management, actions handling and rendering logic, with code becoming extremely fragile.

  3. Factoring out functions into separate 'modules'. Fuctions are already grouped by purpose so it seems most logical solution. However, when done naively (just mechanically moving the code to be 'required' from main.lua ), functions will still rely on a handful of shared global variables, and this dependency may look weird in module context. Doing refactoring more conventionally would mean introducing modules and encapsulation, which may or may not be preliminary from educational perspective.

  4. Rewriting everything from scratch in a radically simpler way... could be an option, but I'd ask for any practical advises, hints and thoughts on the matter. At first glance I do not see any obvious path for radical simplification, but maybe its perception bias. Would be happy to make a pivot, if there's a good way.

UPD: simplified example added

See ./src/examples/trapsensor_simple/main.lua

@hleb-rubanau
Copy link
Author

Regarding complexity issue, I've just added radically simplified version (trapsensor_simple) -- it has 432 LOC

I would say this is close to the absolute minimum. For further readability code could be split to 2-3 chunks, but as said before, I am not sure its a good idea, as functions are already heavily using shared global variables (even more in simplified version), and code splitting therefore may introduce more confusion regarding these vars management.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant