FAQ: releases' producers
|#1 by eacil|
2020-02-02 at 17:50
|The FAQ says:|
The companies/groups/individuals involved in the development or publishing of this release. Does not include distributors. The following roles can be selected:
>The producer involved in the creation of the game itself, not necessarily of this specific release. Keep in mind that producers that have made modifications to a game but have not made the game itself should NOT be listed as developers.
>The producer responsible for publishing this specific release. The publisher may have made modifications to the game (e.g. translating all text or porting to a different platform), but was not involved in the creation process.
>When the release is developed and published by the same producer. This is often true for doujin games and the first releases of commercial games.
I propose to add some clarity to those rules as it clearly needs some additional writing, if only to explicit after the developer entry: "Additionally, do not link the original developer to a localization if it is not a main party involved in the creation of this release".
The problem is that we DO add original developers to ports... even though they are not involved. I mean, look at AiCherry.
So the rule is pretty much "do not add the original developer to localizations". I applied this rule mindlessly since I don't remember anymore why we do that. I assume it is because they are not involved and so they shouldn't be linked to not give false information. It is inconsistent with how we treat ports so I must be wrong somewhere. It is also inconsistent with the "not necessarily of this specific release" part of the definition.
That brings us to what I think is a major problem with vndb as an international db: it's impossible to make a list of localizations for a given producer. If I want to know what Eushully were translated in English, I can't. Same with other languages. It's painful to have to check dozens of release of a producer to find it has no translations. I think it's a query a lot of people are bound to ask as we less care for publishers like MG than the developers the work they localize. If you don't keep updated with English publishers and do not regularly check releases, you have no way to know that your fav brand had one of their game localized in English.
This is why I suggest to add a new type of relation: original developer. You could add it to localizations and ports.
But I digress as there are still a number of cases we need explicit rules, such as:
-what if the original developer is involved in a localization, not just to check if the publisher is doing an alright job? Sometimes, they do all the programming work.
We do not link them usually and I think it's fair.
-we add fantl teams when we know they are at the origin of the translation even though they aren't publishers anymore, even from a fantl pov. In fact, we add pretty much anyone who is involved with the localization process as a publisher even if they are not. I had this recent case: r52376.2. Maybe we need another relation as the publisher is not always the guy who actually do the (translating/porting) job. When I checked every entry of F&C, I found a number of times that they were the publisher for ports even though they did not port the game (edit: or maybe it was their publisher who didn't do the porting, I don't remember), but I couldn't add them because of the "Keep in mind that producers that have made modifications to a game but have not made the game itself should NOT be listed as developers" rule. Well, I assumed "porter" guys were not important enough to be worth an entry.
-I recently found another pickle when I removed Lose from r66780 as it was to me a localization made by Circle Entertainment. The problem being that it is an "international release, Japanese included", it means there is no Japanese-only Switch release. So, is it a localization or not? Do we add the original developer as a developer? My intuition says no but this straddles what we do as this release is as much a localization as it is not.Last modified on 2020-02-02 at 18:32
|#2 by rampaa|
2020-02-02 at 18:51
If I want to know what Eushully were translated in English, I can't.I've asked a developer tab to be added to VN filters a while ago (t12507.21) for this exact reason, but there's no indication it will ever be a thing. :\
But you can use this query in the meanwhile: linkLast modified on 2020-02-02 at 18:52
|#3 by yorhel|
2020-02-02 at 19:53
|Just quickly commenting on one thing:|
This is why I suggest to add a new type of relation: original developer.Based on current guideline wording, that's already exactly what the "developer" role is, except we don't set that field for localizations, because that'd suggest that the original developer created the game in that language. And, with the current way developers are displayed, that'd be super confusing. Actually, it already is super confusing for multilanguage initial releases. Maybe the "developer" field should be a VN property rather than one of the release.
As for not being able to see which VNs of a developer have been translated: That's purely a UI limitation, our current data model is sufficient for that use case.
|#4 by eacil|
2020-02-02 at 21:15
we don't set that field for localizations, because that'd suggest that the original developer created the game in that languageBut we do it for ports, "suggesting that the original developer created the game in that platform".
Can you give me an example of what confuses you with multilingual initial releases? I understand that this makes it impossible to distinguish what is the original language (though you can deduce what language it is by checking the producer's nationality) but no example comes to my mind where you can't distinguish who is the original developer. I am not sure I understand what you mean.
Maybe the "developer" field should be a VN property rather than one of the release.Yes, maybe set at least a global original developer and a global original language for a VN. Then, do we need to keep the developer field? Hmm... considering that "developer" on vndb pretty much is restricted to the original developer position, I don't think it would change anything.
I also forgot remakes! Some remakes don't change the script but the presentation is so different that it is almost an entire different game. I think of Kamaitachi no Yoru which was remade multiple times.
Let's say a producer remade a game but a different producer published it. Under current rules, the developer which remade the game shouldn't be listed and at best relegated to the note field even though the publisher didn't do a single thing worth of mention. Unfortunately, the release doesn't deserve its own entry, which might have allowed the "remaker" to be upgraded to the status of developer.
So I suppose we should also make explicit the fact that developers who remade a games shouldn't be listed either, alongside people who made ports?
With the developer field gone, new fields could be made for producers who do porting and remaking. Maybe repurpose the old developer field?
I personally have always hated how publisher always get the lion's share, like producers, even when they don't lift a finger. Why are they the only ones listed on stores? Who gives a rats ass about a guy who decided he wanted to publish your work? Publishers are at best relevant as a label, a selection. As a reader, a customer, I have always found that data to be completely irrelevant.
Edit: don't get me wrong, if a publisher does the translation, the porting or any developing job, it is important, but listed as such.
As for not being able to see which VNs of a developer have been translated: That's purely a UI limitation, our current data model is sufficient for that use case.Isn't it complicating things to add localizations to a producer pages by checking if they are the original developer of each VN listed on their page and then bringing back the non-liked releases under another label, if that's what you meant?Last modified on 2020-02-02 at 21:19
|#5 by uvix|
2020-02-04 at 04:23
Yes, maybe set at least a global original developer and a global original language for a VN.Global original developer makes sense. Global original language might be tricky. What do you pick if it's a multilingual initial release? And if you go with the language of the developer, what if it was never released in that language? (I can't think of VN examples right now, but there [i]have[/i] been games developed in Japan intended for only overseas release.)
Then, do we need to keep the developer field?I think repurposing the release developer field as an actual release developer field makes a lot of sense. Right now there's cases like Lemnisca LLC who've done localization work but haven't actually published anything. However, they're listed as publishers because that's the data field we have. Keeping a developer field on releases would let that distinction be made.
You must be logged in to reply to this thread.