Before coding or even documentation, it might be pretty important to disambiguate certain terms used in the variable naming, and establishing better semantics for the sake of future development. As this project got large I admittedly started forgetting where I used certain names earlier, so before that gets worse the names and some functions will have to be changed. Do this refactor after I finish reviewing/merging #55, but before this refactor is done there can't be any branch merging because of both refactoring and extensive variable renaming.
[DONE] Rename PieceStage and Palette sections; the latter didn't need to be implemented as its own class, so both these sections use the PieceStage. PieceStage's lists should be pieceQueue and piecePalette in the code, and the sections named to Queue and Palette.
[DONE] IdleUpdate, ActiveUpdate, AdvanceUpdate -> IdleUpdate, FallingUpdate, PlacementUpdate; do this for CoreState and all Cells
[DONE] BoundarySets naming is kinda wonky, figure out a better way to incorporate that as a helper with CoreState. Maybe just lose the class and bring it into Functions as a set of collision-checking functions which take in a Piece, since the boundary sets themselves can be replaced with for-looping.
[DONE] Consider a new name for each constants; things like "TICKS_TO_MOVE" are kinda vague.
[DONE] baseColor -> mainColor
[DONE] midLightColor -> 2h
[DONE] centerLightColor -> 4h
[DONE] dropzone -> callOnDropzone
[DONE] FillCheck -> FillLines; move target-related code into Target class itself
[DONE] baseObjects -> coreObjects, to make it clear these are the only classes that can couple with CoreState, whose "meat" in turn is a collection of these objects. Aside from that CoreState only couples with dependencies which provide these objects.
[DONE] Speaking of which, PieceStage, TargetStage -> PieceProvider, TargetProvider would also be good
[DONE] For sake of upholding this convention, also refactor emptyValue's functionality into a class called EmptyCellProvider.
[DONE] Put Action functions in GameAction and control directory in coreState
[NOT NEEDED] Put Cursor and Piece in coreObjects
[NOT NEEDED] Put all coreObjects except for Piece in a new directory elementaryObjects
[DONE] CanvaDefine piece base color list in Theme and have Constants import that
[DONE] Debug -> DebugDisplay
[DONE] Pipeline -> CanvasPipeline
[NOT NEEDED] boardSize -> boardSizeX and boardSizeY; Go through all the boardSize mentions and re-implement for rectangular boards where the height doesn't match the width; being restricted from square boards might not be ideal if designing the game with a single direction of gravity like normal Tetris.
[DONE] Get rid of "size" from anything at the graphic level; reserve Size for the actual size of the coreState board rather than for any canvas coordinates.
[DONE] mount -> activate, to avoid confusion with any React or DOM-related JS code
np-eazy
commented
1 year ago
Before coding or even documentation, it might be pretty important to disambiguate certain terms used in the variable naming, and establishing better semantics for the sake of future development. As this project got large I admittedly started forgetting where I used certain names earlier, so before that gets worse the names and some functions will have to be changed. Do this refactor after I finish reviewing/merging #55, but before this refactor is done there can't be any branch merging because of both refactoring and extensive variable renaming.
[DONE] Rename PieceStage and Palette sections; the latter didn't need to be implemented as its own class, so both these sections use the PieceStage. PieceStage's lists should be
pieceQueueandpiecePalettein the code, and the sections named to Queue and Palette.[DONE] IdleUpdate, ActiveUpdate, AdvanceUpdate -> IdleUpdate, FallingUpdate, PlacementUpdate; do this for CoreState and all Cells
[DONE] BoundarySets naming is kinda wonky, figure out a better way to incorporate that as a helper with CoreState. Maybe just lose the class and bring it into Functions as a set of collision-checking functions which take in a Piece, since the boundary sets themselves can be replaced with for-looping.
[DONE] Consider a new name for each constants; things like "TICKS_TO_MOVE" are kinda vague.
[DONE] baseColor -> mainColor
[DONE] midLightColor -> 2h
[DONE] centerLightColor -> 4h
[DONE] dropzone -> callOnDropzone
[DONE] FillCheck -> FillLines; move target-related code into Target class itself
[DONE] baseObjects -> coreObjects, to make it clear these are the only classes that can couple with CoreState, whose "meat" in turn is a collection of these objects. Aside from that CoreState only couples with dependencies which provide these objects.
[DONE] Speaking of which, PieceStage, TargetStage -> PieceProvider, TargetProvider would also be good
[DONE] For sake of upholding this convention, also refactor emptyValue's functionality into a class called EmptyCellProvider.
[DONE] Put Action functions in GameAction and control directory in coreState
[NOT NEEDED] Put Cursor and Piece in coreObjects
[NOT NEEDED] Put all coreObjects except for Piece in a new directory elementaryObjects
[DONE] CanvaDefine piece base color list in Theme and have Constants import that
[DONE] Debug -> DebugDisplay
[DONE] Pipeline -> CanvasPipeline
[NOT NEEDED] boardSize -> boardSizeX and boardSizeY; Go through all the boardSize mentions and re-implement for rectangular boards where the height doesn't match the width; being restricted from square boards might not be ideal if designing the game with a single direction of gravity like normal Tetris.
[DONE] Get rid of "size" from anything at the graphic level; reserve Size for the actual size of the coreState board rather than for any canvas coordinates.
[DONE] mount -> activate, to avoid confusion with any React or DOM-related JS code
gridCursor -> cursorGamePosition
[DONE] xCellSize, yCellSize -> cellWidth, cellHeight