arcs digital and other considerations

 it has only been 3 weeks and this endeavour has already been a very informative one. 
I have no idea if I’ll be able to “cross the finish line” with this project, but I don’t really care. 
 in the last few months I’ve been looking at game development in a different perspective: as if it were any other trade (carpentry, for example), where the only way to get proficient at it, is by practice - by doing lots of it. this might sound like an obvious truth, but when we’re talking about creative output, there’s always purpose and intent involved. 
  it’s difficult to make something “just because”, without caring if it will see the light of day. but it’s necessary. and that’s why I’m putting most of my energy in getting better and more efficient at doing it, more than anything else.

key takeaways:

assessing the project’s scope

• it’s getting more clear to me the importance of this very first step. usually I’m just very excited about some idea for a cool project, and think about in a general way what kind of stuff I need to implement in order to make it happen. I feel like I’m getting better at reflecting in a more profound way on an idea for a project, sitting down and list out what are its main features, what are the biggest hurdles.
• this gives me confidence for the future, that I’ll be able to more easily pick what projects to tackle, based on an estimated manageable scope
• the digital adaptation of Arcs is, in scope, much larger than the first 2 projects I’ve finished, but less ambitious than the last two, which fell through

spliting the whole project into small chunks

• it’s very daunting to think of any project as a whole and, for the longest time, this has been my greatest struggle. I’ve been very ambitious with my ideas and whenever I reach a point where I need to restructure something structural, I feel anxious just thinking about the whole endeavour.
• for this reason, I’ve been actively splitting - from the very beginning - this project into smaller chunks and working on them separately. it has resulted in a collection of systems that function independently from one another.
• this approach has helped greatly my productivity and, has given room for what-I-will-call “background thought” on features, when I’m not actively working on them.
• it is also a great solution for the struggle of having to restructure anything, as this re-write will be contained to that one block of the game.

plan ahead

• after slicing up the project, I made a list of what tasks need to be done in order to complete each chunk and assigned a completion date (even if irrealist) for each task.
  this makes the overview of the project more granular, and helps connect (and sometimes re-adjust) some of tasks.
• having estimated completion dates helps grasping the actual development time, and provides a way to check if the project is on track

tackling the “boring stuff”

• sitting down and write every little thing that needs to be done and how to implement it; come up with a more or less realistic calendar for task completion; set a consistent schedule;
  these are all things that bring me some degree of boredom when I’m working on something exciting. they are not fun, they attenuate the flame lit at the very moment the idea was formed, and doing them (seemingly) stops me from doing the very thing I set myself to do.
  
• from that last paragraph alone you can tell I’m not much of a planner. but I’m trully commited to get better at game development. and for that, I’m not skipping any steps and I recongnize how important pre-production is, specially when the excitement fades and all you have is work to do.

the upside of doing the “boring stuff”

• I get an overall idea and scope of the project, as well a clear task list that I can work on through
• if I ever take any intended/unintended breaks, I have a source I can rely on to jump back into a specific task, without wondering about what to do next
• I can more easily plan my life and daily schedule around the project I’m working on
• I can be more practical on how to go about doing things, by allocating the reasonable amount of time for each task. this should help to avoid losing much time on exploring various options on low-priority tasks

being less intimidated by my own code

• this was something that ressonated strongly with me when it was refered by an infamous veteran indie developer: “to be afraid of one’s own code”.  
  
• it’s very real. it’s quite daunting - for me - to go back to some feature and restructure it or re-write it from scratch. I’ve drop several project just because of this.
• to tackle it, I’ve been implementing most features with a modular, more generic structure, leaving room for their input and output to be changed in a future iteration.

opting for a modular approach to gamedev

• this title might not be the best way to put it, but at some point I realize that I was approaching development in a linear way: I did ‘X’, so I can do ‘Y’, and that will bring me to ‘Z’.
• by sitting down and listing everything that needs to be done, and organizing the result by priorites, I’m now able to tackle each task independently and - following the previous example - after finishing task ‘C’, I can jump straight to task ‘M’, because there’s now a context for that task.
• as I’ve laid down the whole project structure beforehand, even if I’m not certain, for example, of what should be exactly the output of a method I just wrote, I have a general idea of where to/how that information will be communicated.

upsides of a modular approach

• one of my favorite things about implementing features in a modular fashion is that I try to approach each one in the most generic way I can, for them to be re-used in future projects in any capacity.
  I have a general idea of what kind of projects I’d like to work on next and, with that in mind, even if I don’t bring this digital adaptation to completion, I know that I’m already getting chunks of work done for the future.
  as of now, one of those projects will also have both a card and a dice systems, and the other one will also be a turned-based multiplayer.
• another great thing of this approach is that I can tackle more exciting and creative tasks in between more repetitive or complex tasks

focus and intent

• in this year of 2025 I’m taking things a bit more serious. I’m longer doing things just to see them done, nor to just get an idea out of my head.
• my intent for the next 3 projects is to land a job in the industry. I don’t like my current employment situation and hate the time it takes me away from game dev. on top of that, none of these projects will be commercially-viable for a couple of reasons:
  for one, I don’t feel confident enough about my skills for a proper launch and doing post-launch support, and secondly, I do not own the IP for any of them.
• this might seem like a bad move of my part, but my intent is to do a proper job with each one and be noticed by someone relevant to the job I’m aiming for. (INTENT)
• at the very worst I end up with a great portfolio and quite a skill set. (I hope you can tell I’m not backing down on doing a proper job - FOCUS)

I do love what I’m doing

• it feels great to come home with a breakthrough for a specific problem, or to have a crazy idea, run with it and see it come to fruition.
• it’s amazing to create a functioning interactive object from nothing.
• it feels organic to be away from coding in GDscript for over a year, and come back to it and feel like it was last week the last time I wrote anything in this language