Example/trapsensor #10
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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_perfas 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:
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.
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.
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.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