One of the programming goals I have for my Innovating on Tetris game project is to take the craft of programming seriously.
Despite being a side project with no other contributors, I wanted to practice the oft-ignored ancillary parts of software engineering. Things like documentation, well defined PR's, etc.
With this being a side project, I also wanted to use these PR's as the canonical history of this project. By trolling through the history of PRs, you would discover a narrative of game development.
The advantage of all this extra work? I can take that narrative and convert them into running devlogs- the heavy lifting is already done. In today's digital economy, marketing is everything- and the key to marketing is a compelling narrative. By creating a narrative in PR's, I enable a derivative marketing pipeline.
Setting up the marketing pipeline is TODO, I'm thinking a GitHub Action that prints out the markdown of the PR into a blog post.
PR Anatomy
Taking the above PR, let's break down what I've done:
Link to Design
Regardless of using your PR's as a DevLog, having your PR's link to the requirements is going to be very useful- not just for yourself, but for the reviewers who may not have the context.
Major Components
This was major feature I was implementing, which required a couple of distinct steps. Much like the design links, we are communicating context here- allowing the reader to frame what we are doing (design links), where we are doing it (major components), and why (narrative)
Link to Commit
To complete this feature, there were a number of major changes required. By linking to each each major change, I continue to help the reader understand where each change is coming from.
Coupled with the power of open source, you can view the commit yourself.
One criticism I have is here I over-committed. Here I added the unused folder GameManagement folder even though it's unused. One thing I have to get better at is adding more, smaller commits.
Narrative
One one of those major components were completed, I used a commit to write the narrative of the change:
The previous refactor was useful for detangling the gameplay logic from the Board object. The resulting gameplay controller had several issues of its own, unfortunately.
As I define in Blog/multiboard_tetris_design, I want to structure how objects are created, destroyed, and managed throughout their lifetime.
Starting from the very top, I defined the GameManager as a holder of GameControllers. I defined the relationship between manager-controller to get the mandatory function a game controller would have.
With this structure defined, I was able to look at the Tetris GameController (renamed now to TetrisClassicController) and refactor it with a clearer goal in mind. This led to fixing ActivePiece and GhostPiece, having them more independent and properly managed by the Controller.
The result should be fairly clear object control. From the GameManager to the ActivePiece, control of an object is defined by its parent. Even more importantly, each object has a clearly defined way of how to be managed. Common functions for the control flow.
Practice Higher Standards
In many respects, the actual code you write is the least important part of programming. The design/requirement phase is as critical as the PR/merge phase. Good habits, started early and ingrained into even your side projects is critical to the long-term success of your projects.
Good habits are a force multiplier because it offers the opposite of technical debt- technical dividends. Instead of fighting toil, you're pivoting rapidly, or expanding easily.
By practicing higher standards, you are continuously honing the craft of software development. This is the only way to become a better developer.
Top comments (0)