Working within frames


Welcome to the Positron Dev Log!

The development is still in it's infancy, but I hope this week update will provide a more interesting experience so you can feel better the vision I have for this game~ As always, every feedback is very welcomed!

For this week, I want to discuss about a little bit about my working process. Maybe not super exciting, but very important to actually make progress.

Scrum Framework

For those who work with software development this is probably just common knowledge, but bare with me a little. So, one of the problems that software development teams (and, I suppose, any development team) have is how convoluted it is to make a product the way the client wants. Imagine a complex software being developed by hundreds of people for several months, and when presenting to the client, they say that there is a problem with how the system works, and then the team must fix it. But even changing the smallest portion of a software, like every complex system, will most likely have some unintended effect on the large scale, thus creating bugs. It could take many days of work just to track down every repercussion this change made, and after months reworking the software, they present it to the client, the team finds out that, again, it's just not exactly what the client wanted.

Well, this is not only unproductive, but also very annoying. That's why Scrum (and other Agile  frameworks) was created. I don't want to keep this too long, so just my tl;dr on Agile methodology (checkout the agile manifesto if interested!): What we want is faster production and better communication. We can achieve this with smaller but more flexible teams that can work on whatever is needed at the moment, with frequent communication with the client and between the team members, to find out as fast as possible how the system is actually supposed to work.

Scrum My Framework

Okay, but what does this have to do with this game?

Right, so I don't really have a team, but I do have clients (that would be myself and the players). And, like anyone doing a hobby project, I have to juggle between it and my everyday life. Having a framework keeps myself organized, aware of what are my current objectives, and don't let me fall into "slackery". You could think of it as maybe a communication between me and myself? 

So, to keep the workflow going, I borrowed some of the concepts from Scrum:

  • Backlog

Basically, a giant to-do list with everything I have to get done so I consider can my game "complete" (as the quote goes, "Art is never finished, only abandoned."). Of course, sometimes I just put something big and generic first like "Compose BGM", but as I start tackling it, it's better to break it into smaller and more manageable items, like "Compose Main Menu theme". Also, chances are the list is not thorough, but you can always add new items as the project moves forward. To manage all this, I've always been using Trello, which is a quite simple, yet powerful card board application.

  • Sprints

To see just a giant monolithic to-do list is quite daunting, you usually don't even know where to start. Then, why not organize your work for just the next couple of weeks? This way you have to choose only a handful of the items of the list, and you have a deadline to finish them. I like to keep my sprints a week long, but they could last from 2 weeks to a month, depending on the project.

  • Planning "meeting"

Every start of sprint, it should be decided what are the activities planned for it. I find it's very hard to change your mind set too frequently, like start the day working on programming and end it composing BGM, so I try to choose the activities for the sprint in a themed fashion, like a week for music and graphics.

  • Daily "meeting"

Having a (very) short daily meeting is actually very useful for the team communication, to check where everybody is at, and, even though I'm alone, it's still useful to have a couple of minutes of the day to reflect on how my work is going, plan for the day and make adjustments on my scheduling to complete my sprint.

  • Review "meeting"

By the end of the sprint, it's good to look back and see what you accomplished and take a moment to reflect what went well and what went bad, and make decisions about how to make your process better. That's actually something that I do not only for work, but also for my life. One of the things I also like to check is my efficiency, so I time all my activities using Toggl and check how much work I was about to pull out in the time frame, and to have a better projection for the next sprints. I usually try to dedicate around 4 hours a day, but that's not always possible due to life, so I at least try to keep with my deadlines, though health (body, mental, social etc) should always be priority.

Conclusion

To conclude with another tl;dr, I made these rules to keep myself with weekly work with a deadline to maintain productivity, and I systematically reflect on the past, to see what I can do better for the future. This is not something I only apply to work, but also my life, and always keep in mind that health should be priority.

Last words

So, I said I didn't want to keep it long, but in the end... Not a problem, though! I just hope this was somehow interesting and you didn't get bored reading through it. For the next one, I will be discussing about the stylistic choices of the game! Stay tuned~

Get Positron

Leave a comment

Log in with itch.io to leave a comment.