Open
Conversation
Player must reveal all cells while avoiding hidden traps
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. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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