Dev Log 6: The Agile Methodology of VN Dev



If you didn’t catch my earlier Version post titled “Version 1.01! or How I Learned to Stop Worrying and Love Agile (I don't)” you can guess that I am not the biggest fan of Agile development. I joke about it at work too.

Honestly I can’t say I have too much of a valid reason to dislike it. It is just popular to dislike it, but it does have trickle down effects in engineering and company philosophy that intrigue me.

Where I can say it has impacted me are these games which rely on subscription models and crowdfunding as they release many quick versions. I will be calling this Agile VN Dev or VNaaS, Virtual Novels as a Service.

What I mean is, I went out and dropped a full game on purpose.

While the idea of the vn was still in its infancy, I had thought a lot about various methods of releasing it. As an H Sandbox VN, I wanted to monetize it with patreon, and churn out H content at breakneck pace. You don’t have to think too hard to know where I got the idea from. If you know, you know. Believe it or not, what exists was supposed to be the first part of the H VN, much like the first level of persona. By the time I changed the idea of the VN, I also began thinking about changing the release model.

Why did I do that?

Isn’t agile dev better?

Agile Dev, even for something like VN dev has many perks. First, the constant minor patches and updates mean constant content for users to play, then drop, then play, then drop. It becomes a habit, or something active that a person looks forward to and becomes engaged in. They comment about updates, guess about the future, and drive other people to be excited as well. This is something which I hadn’t been able to replicate by releasing a full game. Had I released each scene as a weekly update, I’d have 40 chances to strike it big but it would also be silly.

This sort of almost haphazard and at will update approach can lead to what seems like a more active game or dev cycle. Things happen fast, updates come and go, and the dev responds always, making the game feel extra alive. While release schedules are advertised, both in game dev and real agile dev, it doesn’t always happen.

In addition to creating more buzz, agile dev allows a dev to have the tight feedback loop with their fans necessary to create what the fans want. In addition to using it to drive patreon subs, these votes allow devs to be able to best gauge what the fans want, and build on that. In many cases, this actually leads to fans preferring a certain character, or route, over all else, despite a game advertising many routes. In theory this means that the people who pay are getting what they want.

Where it becomes VNaaS is the subscription-like models. It isn’t strictly necessary to pay on patreon for most of these games, early access among other things get leaked more often than not. However, people are paying for the continued development of the game, and therefore are paying for continuing content. If people stop paying, in all likelihood the dev stops too.

VNaaS helps developers make more money as they dev. Much like kickstarter, these sorts of models can be thought of as investment money early in the game’s development to get them off the ground and into a place where they can sustain themselves.

However, VNaaS discourages completing games.

Among the best devs, and in some ways the most honest are the ones who do manage to complete the game people paid for and then can make another project, which those fans continue to support.

However, it is not a given that a fan will continue to support a dev after one project is complete. I think in most cases this happens, but many devs do not take the chance, and this is where trouble occurs.

How does a Dev “not take the chance?”

They never finish the game.

Either the Dev continues to elongate the game well past its saturation point as an idea, or the updates become more lacking in content that pushes the idea further. This could be in the case of where new plot developments that do not seem to make sense with an early part of the game pop up to continue the story, and often derailing things entirely, or a lot of fluff and side content appear without pushing the real story further. This could even be where the scope continues to build and build, and hint at a resolution, but before you know it, it has been a year.

Not all of this is greed.

In many cases, these devs are probably inexperienced too, and may burn out, find their ending lacking, or come up with so many new ideas that scope creep is in full effect. Had I released Achlys using this model, there would have been a year-ish pause before I finished it, and I would have fallen victim to the same thing, even if in the end I did finish and release.

Even in my own small project, there were many spots where I found time just leaked away, such as renders, or the expansion and contraction of features based on what I had learned. Maybe I would have added “How are you” dialogues for every scene until I realized people didn’t use it, or hated it, or I got bored. Then comes the questions, do I stick with it? Do I stop? Do I delete the old ones? Do I just remake the entire game?

VNaaS can be dangerous to creative vision.

The answer to the questions above has many factors to it, such as how it relates to the creative vision. I made the decision to trade off interactivity of clicking the “How are you” button for the simplicity of removing it, because in my creative vision, the unity and immersiveness of each scene individually was more important than the interactivity of the world. Had I chosen the other way, perhaps each scene would be a fourth as long but then maybe Chloe has extra scenes at the supermarket, or other minute details.

I was able to make the change and remove it from the future, only keeping it in the intro because it makes sense in context. Had I worked on VNaaS, suddenly a microscope is placed on that decision because I had already released the game. My choice now takes into account the current state as it is released.

But also something to consider, rather than an inane and genuine decision on a feature of the game, is that operating based off of the monetary incentive and fan support based on in the moment development of the game means that there is some degree of pandering (I do not inherently mean it negatively) built in.

There may be a place where I have to trade my creative vision for what people want, or worse, what I simply imagine people want which may not be reality at all. My dream for a creative vision is where the plan I have in mind exists in the Venn diagram where the circles of what I want and what people want overlap. If I were to solely focus on the other circle, my creative vision is diluted, and the product becomes inconsistent, moment to moment, and reactionary.

Achlys exists as a monolith, independent of time because it was released at once (save minor bug fixes) rather than as something meant to cater to, or pander to an audience for an income motive. If I started with the first section of Achlys and it wasn’t well received, I could have just stopped or turned it all around right after that first part. While it may lead to better numbers, I would consider it an incomplete, and corrupted vision.

In the future, chances are I will keep this release style.

This release style is probably the best for my personal aesthetic theory as well as my workflow.

If people like these dev logs, I may expand on them with more that dive into the characters of Achlys for instance.

Get Achlys: Book 1: The World as She Saw It

Leave a comment

Log in with itch.io to leave a comment.