DEVLOG #1: ORGANIZING OUR PIPELINE


Don't think I need to re-introduce myself but hi I'm Skai. I'm the acting director of this project and founder of God's Radio Dev. In this log, I'll discuss our process when it comes to dividing work and following through. I'll also be touching on a few all too relatable problems I have experienced.

HISTORY

Meteor Shower to me was an exercise in project management. I went into this with an idea and a vision, and our team was more than happy to make it happen. I’ve had several attempts at writing visual novels in the past but they ended up in development hell because I was alone. Being alone comes with the freedom of creative expression with the absence of checks and balances to actually push through with the product.

I touched upon this in our old dev log post from our demo release. This isn't the first time that I, individually, attempted to release a game. 

It was a dark time in my life when I decided to work on Ignis. It was meant to be a simple seven day long visual novel that would determine the fate of King Idris after a prediction he was given at the beginning of the story that marked his death.

At the time, I was a film school burnout who was beginning to realize just how much I would hate the industry if I ever graduated from that program. So, like the impulsive little gremlin that I am, I decided to drop out and come back to what brings me comfort: Visual Novels.

Over the months of working on assets and scripts, and trying to figure out how to do any and every form of rudimentary programming a solo dev like myself would have to suffer through, I felt the scope of the story increase and increase and increase until I could no longer recognize it compared to the original plan.

Working with God's Radio Dev, however, made me realize just how possible it would have been if I had just asked for help. And so Project Snowfall and Meteor Shower began production, and I'm happy to say that we're doing incredibly well.

THE TEAM

Jinn, Pyr and I were already close friends that I met my first year of high school. We've been friends for a decade so that makes it a whole lot easier for us to get along.

Pyr and I have been producing songs for fun since I'd say about 2018 so I already knew exactly how to work with him when the time came for making the OST. Jinn, on the other hand, I've never collaborated with before on anything creative. However, I know of her work ethic very well when it comes to writing papers and school requirements. All that translated well when it came to writing Meteor Shower.

In practice, there are many things I learned about my friends when it came to actually starting on the project.

For one, I learned that Pyr can't get started on music unless he had a good visual of how the world is supposed to feel. I generally assisted him by showing him the art and assets and guiding him through the script whenever he was ready to get started.

Jinn likes to work with an outline which is a huge relief for me because so do I, and she's been a great help at providing what I lacked when it came to the writing department: the ability to let the first draft be a draft. She would write every day like a machine, and while it wasn't perfect, it got the job done and it was so much faster for me to process it all through editing.

Of course, not all devs will have the luxury of being able to work in a team that they already know. I've been there before. Sometimes your real life friends just don't share your same interests. That's why you turn to people in the community online to help you make your little dream brain worm come true. I've only recently found a team of new people to work with myself in Impolite Society and it's been incredibly fun.

So when beginning to work with a stranger to help through a project, I like to keep in mind a few things.

  1. Make sure I get along with my collaborator - Before beginning, I'd try to vibe with my prospective collaborator. See if we get along well and gauge how they respond to my ideas and my jokes. I can't stress how important it might be to be on the same wavelength as people you're supposed to work with closely. It makes a huge difference when everyone is having fun compared to everyone just acting like co-workers.
  2. See if my collaborator's working process is compatible with mine - Next thing I do is figure out if we're creatively compatible. That means the difference between writing styles of plotters and pantsers, how they react to deadlines and scheduling, and how I usually impose standards upon myself.  If we're compatible then there's no issue. If we aren't but we still want to keep working together, see the next point.
  3. Be willing to make compromises - A team effort cannot be called a team effort if the members don't give way for each other to work in the best conditions that they can. Everyone is different and just because someone isn't working as efficiently as you think you are doesn't mean that they don't care or they aren't working at all.
  4. Be open to criticism and outside opinion - Tunnel vision is not a good thing for a collaborative project. Our raw ideas aren't flawless and we ultimately can't control every part of the process if we want to finish a project. Outside opinion is important. It keeps one grounded and it gets things done.
  5. Know when to put my foot down - That being said, I don't have to bend to every little suggestion I'm given. I listen to them carefully and consider them for awhile. If every idea is implemented even when one thinks it strays from the point of the project, then that will muddy the clear vision it was supposed to have.
  6. Have constant open communication - This means that each and every one of the people working on the project should be expected to comfortably share their progress with the team to gauge whether or not the team is on schedule. Expect honesty from each member and members should not be afraid to respectfully criticize each other's work for the good of the team.
  7. Rein each other in - Creative people can get too ambitious. We've all been there. An important part of finishing a project is simply to be able to remind each other that there is a deadline or a budget that needs to be followed and no matter how much you convince yourself that something is a good idea, if it's too costly, then it probably isn't worth investing energy in.

THE PROCESS

We were already working on Project Snowfall long before we even decided to take a crack at Meteor Shower. In that visual novel, Lori would have been in her twenties. Meteor Shower ended up being this prequel of sorts that we decided to run as a test trial for fun when we saw that Otome Jam was happening. I joked about it to the team and I didn't think they would agree but they did.

So, since we had two months to finish a demo, we began to draft how we were going to do it within that timeframe. I considered my strengths and the strengths of my team members to make our step by step process.

I knew that it was easy for Jinn to write with consistency as long as she had a direction to go to. So, I made a structured outline template. Pyr, on the other hand, needed to see the scenes finished before he can begin to feel out the music. So, I made it my duty to finish editing Jinn's drafts as early as possible to accommodate him. On my end, since I was the only artist, I gauged how much I could realistically draw within the timeframe while also editing the script and programming the game.

The resulting process step by step is the following.

  1. We defined the kind of game we were making: One love interest HS otome. Beyond that, we decided on how we would make it unique and so to make up for only having one LI, flavor text could make every playthrough different depending on Lori's personality determined by the choices.
  2. Next, we structured the outline accordingly. The demo would contain two chapters. There would be three more milestone chapters in the story and the rest of the chapters in between would be minor events that affect them. All in all we're looking at 17-18 chapters for the full game.
  3. I wrote down the outline of events for each chapter so that Jinn would have an easier time to write. We rearranged it accordingly every time we had a discussion or when we were in call.
  4. Pyr and I began looking into how we would approach the music. We would start with looking for the right inspirations, the right vibes. Canonically this story takes place in the 2010s, when we were all in high school. We ended up taking inspiration from the kind of music we thought Lori and Taylor listened to at the time. Lori loves Taylor Swift, and Taylor is super into Mayday Parade (he's even wearing that tacky plastic baller and we love him for it).
  5. While waiting for Jinn to finish the draft of the first chapter, I used the outline as a guide for what backgrounds I needed to draw, and then I began drawing the sprites. I put markers on where CGs might be needed here and there.
  6. When Jinn was done with the first chapter and moved on to the second, I began editing it for coding. I coded the game into Ren'Py simultaneously as Pyr began making the music now that he has scenes to work with.
  7. We did the same for chapter two, and once we were finished, it took a whole round of checking and rechecking as we passed the build around amongst ourselves and our friends.
  8. The marketing was an afterthought and we only began to actually post on social media when the jam was nearly over. We recognize in hindsight, that may have been a mistake later on but we're already here so we just pushed through.
  9. Throughout this whole process, we had the agreement to be prepared for any and every setback and to adjust the scope accordingly. Thankfully, we were able to meet all our deadlines which resulted in the finished demo today.

CONCLUSION

With all that done with, a word from the other members of the team.

Hi Jinn here. Collectively, Meteor Shower and Snowfall would be my first attempt at a creative project so I'm glad I have the support of a dev team. It helps because there's the feeling of accountability to get things continuously going, especially with the first draft. And knowing that Skai is there to help edit eases the frustration of doing revisions.

Overall, I'm still a newbie to VNs but I'm slowly starting to get the hang of the process and other things thanks to having Skai and Pyr around


I do believe that making Meteor Shower was the right move. It gave us the perspective we needed in making VN projects, and made us more comfortable in looking forward to future releases. In terms of the overall project management, even if music happens to be one of the last things to be implemented, you still need to follow aspects of the game as it is developed, like the art and narrative. Being involved in that regard definitely gives you a better perspective of the project as a whole, and it makes the music production/sound design process a bit easier.

As someone who is also just stepping in to making soundtracks for projects like these, having Skai and Jinn around to keep creative progress in check was invaluable.

Get Meteor Shower

Download NowName your own price

Leave a comment

Log in with itch.io to leave a comment.