Embracing your tool’s limits vs jumping to other tools

<h1>What I wanted to achieve, why it didn’t work out?</h1> Breaking down a project into tasks is one thing. Another is arranging these tasks in a sequence so that you always know what stage you’re at. I have a cool method for that. Or so I thought. I start with the finished product. Once that ideal (perfect Snake, hehe) is on paper, I ask the question: what does the prototype/MVP of my game need to have? How do I know what that should be? I categorize all the possible features of the final game using the MoSCoW method, and for the prototype/MVP, I only select items from the “Must Have” column, leaving the rest for later (to be honest? It’s Snake, there is no “rest”). Just as a pearl begins with a grain of sand coated in layers of pearly substance, I too pick a grain of sand (the timer) and look for the next step and the next step. Each task becomes the predecessor to its next task. When I finish a task, I move to its parent, making sure there are no unfinished sub-tasks (tasks that need to be completed before working on the parent) and if there are none, I continue working on that. Simple, organized, and broken down into elemental factors. I know what’s done and I know what needs to be done now. If a task seems too complicated, I break it down into smaller tasks. <a href="https://medium.com/@MauriceKlimek/embracing-your-tools-limits-vs-jumping-to-other-tools-b17ae5320ee8">Website</a>