{"id":355,"date":"2024-06-23T04:44:06","date_gmt":"2024-06-23T11:44:06","guid":{"rendered":"https:\/\/kdcinfo.com\/blog\/?p=355"},"modified":"2024-06-23T13:44:28","modified_gmt":"2024-06-23T20:44:28","slug":"fun-with-practical-prototyping-project-one","status":"publish","type":"post","link":"https:\/\/kdcinfo.com\/blog\/2024\/06\/23\/fun-with-practical-prototyping-project-one\/","title":{"rendered":"Fun with Practical Prototyping: Project One"},"content":{"rendered":"\n

… … … I relished the thought of
… … … … creating a “simple” open-sourced Flutter app in around three days.<\/p>\n\n\n\n

\n

tl;dr: The functional design took a week;
\u2014 read, ‘how three days turned into near three months’.<\/p>\n<\/blockquote>\n\n\n\n

On the bright side, ChatGPT and GitHub Copilot reduced the coding time by about 20-30%. What would likely have taken ~3-4 months was completed in ten weeks.<\/p>\n\n\n\n

Granted, a prototype isn’t meant to be a “final” product, and although there are still some features in the queue, I believe the ‘prototype’ portion of the effort could’ve been called ‘done’ weeks ago. But then, I love a quality working product, and, this project was as much about Flutter development practice with OOP and SOLID as it was about practical prototyping. So while I aim to continue advancing my prototyping prowess, don’t we all want what we’re working on to be the best we can make it?<\/p>\n\n\n\n

\n

“whatever is worth doing at all, is worth doing well”<\/p>\nPhilip Stanhope, 4th Earl of Chesterfield, 1746<\/cite><\/blockquote>\n\n\n\n

In the end, I do aim to continue practicing prototyping (and better learning where that cutoff line is). The good news is that aside from the more critical time element of the project, and knowing I’m only a year into learning OOP and design patterns, the resulting code did indeed end up with a few intentional OOP-based structures. Plus, I can soundly say my future self will have much less anxiety going back into this project than my recent refactored apps.<\/p>\n\n\n\n

Project One<\/span>: Tic Tac Tuple<\/strong><\/h2>\n\n\n\n

The first app I opted to begin practicing practical prototyping with was Tic Tac Toe. The project was later renamed to Tic Tac Tuple<\/a><\/strong> in considering the game board supports three sized grids; 3×3, 4×4, and 5×5, as well as 1-4 players. And being the art of calculating winning tiles within those grids involved chunking the tiles into tuples, thus, the name change made sense.<\/p>\n\n\n\n

As referenced earlier, the architectural design of the app’s functionality took a week. Knowing when<\/em> the design was “done” was a challenge in and of itself. But as with all projects, time and effort helped morph that design into class structures, and further down into properties and methods.<\/p>\n\n\n\n

As the design neared completion, I was eager to start into coding via TDD. Admittedly, however, it didn’t last long. As the project wore on, testing got done mostly after coding patterns were resolved, which is how it was done for over a year at my last Flutter position. For some, TDD could well be an ever-elusive pipe dream \u2014 at least without a paradigm shift in thinking such as that between procedural and OOP.<\/p>\n\n\n\n

The App<\/h3>\n\n\n\n
\n

Introducing: Tic Tac Bot<\/p>\n<\/blockquote>\n\n\n\n

Also referenced earlier, the Tic Tac Tuple board can be a grid of either 3×3, 4×4, or 5×5. And with an attempt at OOP for this feature, in theory, a 6×6 and 7×7 could be added . . . quite . . . easily? No matter the case, the contrast in simplicity is stark in comparison if it had been done with JavaScript and PHP, as I would have back in the day (i.e. 3+ years ago). The number of players and the player symbol markers could be added to as well.<\/p>\n\n\n\n

When playing with only one player, a friendly opponent, Tic Tac Bot, will join you. For some really great news, <\/p>\n\n\n\n

\n

if you’ve ever wanted to win at Tic Tac Toe, now is your chance!<\/em><\/strong> <\/p>\n<\/blockquote>\n\n\n\n

As referenced in the ‘Current Shortcomings’ section below, currently TicTac is only prepared to defend against wins. What that means, and what the future feature list below provides insights into, is that TicTac does not play to win, and what’s more, does not even yet check for blocks between split tiles. Those are actually future features that are slated to be bot-level difficulty preferences.<\/p>\n\n\n\n

Despite Tic Tac Toe being one of the simplest games to consider creating, in hindsight, there’s a LOT that goes into creating a game (or any app) that goes beyond the creation of the game itself. Perhaps a simple 3×3 grid with 2 players may have been an easier challenge, but then there’s still the game flow design, UI design and theming, images and icons, app- and local-level state management, storage, navigation, etc., etc.. Most of the initial design aspects even had to be changed along the way \u2014 so much so I had to remove the ‘initial design’ notes from the top of the main class files (although meant as insights into the designing of the app, those notes were better suited for the readme anyways).<\/p>\n\n\n\n

Current Shortcomings<\/h3>\n\n\n\n