Ren'Py How developers measure content added and present new updates?

[NesteroV]

As someone who wants to develop own game, I find myself curious how that actually works. Have no experience with presentations nor the ways to count mechanics, dialogue lines, etc. Would appreciate some help.

 

[osanaiko]

There's no rules about it. And if you ask people, you will receive lots of conflicting opinions. It also depends on the game type, because a visual novel progresses differently to a RPG, and a mostly-linear story progression is different to a more open-world game with many quests.

Counting lines of dialogue, or number of renders, is not very useful because how many is "enough" is very relative to the game type. You might have a management simulation game with 10000s of lines of code and only small amounts of dialogue.

One common theme you see is a dev targetting a certain "unit" of storyline - a chapter of a VN for example. Or perhaps "a day" of a slice-of-life story.

The actual metric that matters to players feeling "satisfied" with the size of the update is going to be playtime - how much time did it take to go through all the new content. If you manage to produce 30 mins of new playtime every three months you will be WAAAAY ahead of the average.

 

[aereton]

To add onto prior answers, it's important to set milestones with tasks for your releases when developing them.
Organisational advantages aside, that way you already have a rough outline of how to present your updates in a readable format.

You could use GitHub (even with an empty repo) for that, or some specific software, or just a simple Google document or even pen and paper.

 

[cryptob]

As someone who wants to develop own game, I find myself curious how that actually works. Have no experience with presentations nor the ways to count mechanics, dialogue lines, etc. Would appreciate some help.

In my opinion, as a software developer, it doesn't make any sense to have a "count" of what have i done, but more a changelog where i explain, for yours and eventually for your team members, what has been done inside the last build of your project.

For example, if you make the release v0.1 you can report just as "Initial Release" or elaborate more, like describing what's implemented in the first release, which mechanics and so on.

In more advanced stages of development or with more complex projects, you can just do as follows:

v2.4:
- Reworked chapter X because of typos, now can experience a more clear dialogue
- Added event X and Y and Z to chapter X
- New feature X (ex. map for you game, or new menu in some phone-ish interface) that does Y

I hope that my comment has answered in part for your doubts and you catched an idea of how a changelog can be structured properly and effectively

 

[CircleJerks]

A interesting way you can you can set your updates is the end of means from your development workflow

Let's say you have a gallery mode you want to add into your NTR furry game, alright the next update post should be "Gallery added" since its your goal.

But what if 2 things happened while you are adding your gallery.

1) You found out a better way to load your CGI scenes into the game that will make it easier to add gallery mode:

That shouldn't be an written update, when you write an update you need to keep in mind that it is a way to make players wasn't to either check the game out again or as a marketing tool that will attract new player( "oh, it has gallery mode so now I want to play it and masturbate on the gallery mode). Although it is a really good change for you in terms of project development to better load your CGI scenes, it is not relevant for the players since they will end up seeing the CGI no matter what when playing.

2) While testing you found out that there where some CGI with some kind of errors( bad drawing, bad load, bugged, etc.):

Although not a big written update it would be nice for player interaction to have some way to tell them that some issues that they can witness are fixed, helping out in them going to play the game again(Also players like when they are heard).

For planning updates, its not a goal, its a biproduct of your work flow:
You have a big block called game, you divide that block in smaller blocks that are features, and those features you divide in even smaller rocks that are the roadblocks to reach those features implementations. Next thing you know, when you finally reach the end of one of those blocks in development that will be tangible to the player to witness and interact you think "hey that would be nice to write it up for them to know".

 

[<Code/>]

It largely depends on the game type. Since they are structured differently. I don't know what other people look at, but I mostly look at how many new images were added, and generally look at how often the game has updates, and how many images are added per update.