#1 by yorhel

2019-07-15 at 10:59 < report >...and make sure to repair them in case they fail.



This took a while to get started, but we now have an "Engine" field for releases (t7121). It is effectively a free-form input field, but the edit form provides a list of common engines you can select from. For engines not in that list, please try to use the *exact* same name for all releases.



I expect that this may get a little messy anyway, so I'll post data dumps of all used engine names at periodic intervals so that we can keep them consistent.



Happy editing!

#2 by sakurakoi

2019-07-15 at 12:21 < report >Sweet, now... do we go with In-house/Custom (Company) Engines like Eushully's ARCGameEngine as only "other"? It does not really justify it's own entry since it is used for like a dozen or two of works while "Other" will clutter the "Other" search needlessly since one can be more precise than that.



I think the search field would also like a drop down/auto-suggestion menu since after all it wants the exact name, no abbreviated version and no lower/upper case character in place of the other.



Also, I think for certain Engines one might like to have distinct versions available. Like RPG VX Ace/Pre MV vs MV. Just exclude version numbers at least below 1 or define special rules for something like Unity. Someone more into tech can tell more than just "MV and previous RPG Maker Versions are obviously vastly different".



Oh, and a guide on how to identify engines is always nice. Especially since right-click on the .exe->properties->details will not always mention the product name, and version.



Incidentally Wolf RPG Editor version which work with hook software is still named エディター and has version number 1.0.0.0 while those who don't are named Wolf RPG Editor and have different version numbers above 2, luckily, or sadly, we have none of those here if I am not mistaken, even though plenty of titles are as much if not more of a hybrid closer to VNs than some listed RPG Maker games. But that can apply to other engines as well.



On a side note, I wonder if you can reproduce the little issue I found, trying to edit the format of a patch, link the above drop down menus are not working

It might be intended (to clutter the search less even without excluding patches) but it is neither intuitive nor does it apply to all possible patches, which might indeed add something like animation, voices or resolution when there was neigh before. Either it should be greyed out or, well, not blocked.

#3 by japanesebeggar

2019-07-15 at 15:24 < report >Why folks here are obsessed with Hook codes? why is so important to extract Hook codes?

#4 by harleyquin

2019-07-15 at 15:33 < report >Hook codes are the crutch for people who can't read the VN in its original language.

#5 by lucumo

2019-07-15 at 16:05 < report >@sakurakoi: I think DBs should generally be as precise as possible. So an extra field for the version number or something like that would be one idea. The base would be "RPG Maker" for instance, followed by "2000" or "XP" or whatever in the version field.

#6 by kiru

2019-07-15 at 20:08 < report >^Those aren't versions. Those are completely different engines. These engines have versions themselves. (obviously) So basically, that doesn't make sense.



And I don't think we need to care about versions. It'll be too hard to figure that out all the time anyway. "Rpg Maker" isn't an engine by itself. "Rpg Maker MV" or "Rpg Maker XP" are, so versions aren't needed here.Last modified on 2019-07-15 at 20:11

#7 by eacil

2019-07-15 at 22:24 < report >Need Tyranobuilder and LiveMaker entries.



Starting from how many releases an engine can pretend to its own entry? I was gonna add Floating Frame Director to Littlewitch's releases but I don't want to start adding it if it's to be converted later like I added a boatload of System-NNN I am sure have a good chance to be converted.



I agree that RPG Maker need more granularity as I am pretty sure there are some incompatibilities between the engines (I think it happened to me with Abaddon which couldn't be opened in the latest RPG Maker somethingsomething).

#8 by sakurakoi

2019-07-15 at 22:28 < report > Those are completely different engines. Nah, by no means are they completely different. The difference between one of the first, RPG Maker 2000, and the last one before MV, VX Ace is much smaller than between VX Ace and MV. The engines were remade before they made a new engine that has similar designs but is based on something completely different. Heck, there aren't really any patches/new versions for the "old" (non MV) RPG maker engines for back then developers actually sold complete products.



It'll be too hard to figure that out all the time anyway. It depends completely on the engine and this is the reason why specific guidelines for the engines would prove more than just a little helpful. And with guidelines I primarily mean how to find out the engine while those more into the software matter can discern if it is simple to find out the version number and whether it actually matters for the consumer in the first place. (After all, by deciding to provide this field, it is acknowledged that engine does matter in some way and not purely based on trivia, otherwise we'd also have fields for the file size, number of base CG, base HCG, script size... which also serve some purpose)

#10 by eacil

2019-07-16 at 05:58 < report >I mean converting an Other+note into a proper searchable list option.

I initially thought Other was the same as Staff+note for staff, but as I understand it now, using Kirikiri list option directly would be the same as writing Kirikiri using Other? Ok, I see, having in-house engines in the list has little interest by itself and should be reserved for more common engines. However, an updated list like this one would be useful for standardization purpose.



While TyranoScript is a scripting only multi-platform visual novel engine, TyranoBuilder is a complete visual interface that builds on TyranoScripts functionality, making producing multi-platform visual novels easier and faster than ever. Seems like TyranoScript is the engine and TyranoBuilder the GUI.



Edit: uh oh, I found a release that use TWO different engines. -_____-



Edit2: Yorhel, can you make the engines clickable? Like I click on Kirikiri in a release and it directs me to link ?Last modified on 2019-07-16 at 07:05

#11 by sakurakoi

2019-07-16 at 06:57 < report > Then somebody's going to have to write them. :) or pilfer them for that... ah, TLwiki still down, it must be forever gone now I guess. On towards the wayback machine, some reddit post or whatever. Though it won't be me with my limited knowledge but I am sure if you let it be known (with a placeholder link) that you accept contributions (in this thread), I'm sure one few many will gladly contribute.



What can I do at most without looking up too much?

KiriKiri files end with .xp3

Older RPG Maker Engines end with different .rgssa (.rgss3a for VX Ace .rgss2a for VX, .rgssa for XP, 2k/2k3 I have to dig up)

Wolf RPG Editor file end with .wolf

SiglusEngine come with an .exe with the very same name (or I only recognize it because of that)

If it has a .asset and a Managed folder with Assembly-CSharp.dll it is most likely Unity, never mind the many files in the same folder which read UnityEngine.

Well, I could also "package"/write it more nicely and offer details on the engines if actually deemed useful.

#12 by kiru

2019-07-16 at 08:25 < report >@7: If you can open a game in an RPG maker that didn't create it, it would probably just be an "import" feature, as these are simply different things. Even today there are plenty of people who use "older" Rpg Maker engines because they prefer how they work.



@8: It's the same dev, but similarities between the engines isn't making them "the same". Of course they are going to reuse things that worked well, also to make migration to the new engine easier and perhaps attractive. Keep things liked, improve things disliked. It's still not "versions" though. From the outside it may look like it, but these engines have their own updates, versions and whatnot. As such there is no such thing as "the most up to date Rpg Maker version". You can have the most up to date Rpg Maker XP or Rpg Maker MV. That's about that.



Obviously you can argue that they only make them "different releases", but I'm not sure. Unreal 3 and Unreal 4 are also different engines by the same dev with the same roots. Still different engines, that have separate licenses and whatnot. Unreal 4 isn't just the "newest version" of Unreal. You can still work with Unreal 3 even today. Similarly you can still use and buy older Rpg Maker engines even today. (even on Steam)Last modified on 2019-07-16 at 08:26

#13 by kilicool64

2019-07-16 at 08:47 < report >What would be the best way to handle in-house engines that don't have official names? Not all companies who use their own engines bother naming them, yet they still often re-use them for multiple VNs.

#14 by yorhel

2019-07-16 at 09:28 < report > can you make the engines clickable? Done.



However, an updated list like this one would be useful for standardization purpose. I was planning on posting a list regularly, but you know what, here's a real-time updated list instead.



What would be the best way to handle in-house engines that don't have official names? Hmm, are these even interesting? I'd say don't add an engine in those cases.



EDIT:

Seems like TyranoScript is the engine and TyranoBuilder the GUI. Alright, changed all entries to use TyranoScript.Last modified on 2019-07-16 at 09:48

#15 by kiru

2019-07-16 at 10:16 < report >If we don't really care about inhouse engines, we can just make this easy and list the common engines that are used over a fairly broad spectrum. One could simply call the others "inhouse" and leave it at that.

Would remove all the weird engines with names nobody really needs to know anyway. That way we could get to a "defined engine names" approach, so we don't have random things added all the time and need to clean up.



I'm generally thinking that "inhouse" is something we might need to think about a bit more. For example Moonstone and all sub-brands use the Moonstone engine. Can't we just call that inhouse? It's not like much else is going to use that engine. Probably nothing else, unless it's related to Moonstone.

So in other words, we should probably just actually list engines you can license in one way or another. (be it for free or for money, but not only by "having a connection with the company")



edit: one could actually add a comment field in that case, where people can write down the engine name for the inhouse ones, the release's newest version available and whatever else. Things you don't need to search a database for, but can be useful information for some... although we do kinda have that already anyway. It's just never really used for that so far.Last modified on 2019-07-16 at 10:24

#16 by yorhel

2019-07-16 at 10:24 < report >Inhouse named engines seem useful in that you can search for them and track which releases use that and which use another. Unnamed inhouse engines don't really have that advantage. Grouping all of those under a single 'inhouse' doesn't seem very useful either.



That way we could get to a "defined engine names" approach, so we don't have random things added all the time and need to clean up. The current implementation is by no means final, depending on how things are working out I was planning to (pseudo-)lock the engine list down after we've finalized something.

#17 by sakurakoi

2019-07-16 at 11:28 < report > Inhouse named engines seem useful in that you can search for them and track which releases use that and which use another. Unnamed inhouse engines don't really have that advantage Did you forget already you implemented a producer filter? Of course I personally find "Inhouse Engine (Moonstone)", "Inhouse Engine (Eushully)", "Inhouse PoS (Waffle)" &c better but... information value is still there, albeit less than it could be



On a side note: This "double engine" is no good, one better streamlines it as "Several Engines" or "More than one Engine" and be done with it.



Similarly you can still use and buy older Rpg Maker engines even today. Again, everything better be judged on a case by case bases and slowly develop guidelines that ain't strictly followed. Unity after all offers several versions still link



Having only "the same" or "completely different" as the only two points is by no means helping to decide each and every case. Again, Unity pretty much ruins that case because

projects made in 5.x will not open in 4.x. However, Unity 5.x will import and convert 4.x projects it's an entirely automatic system and my bet is not only that not all of those 6 will have their separate version listed here (4 of which were updated this year) but that it will stay as only one, Unity. The differences for the end VN reader are way too subtle or at the very least one has to note what change is not, like available resolutions. Similarly VN creators' "mere" preferences do usually amount to too little, it only matters when one could not use the other because i.e Ruby is no more or has vastly more/less functionality which can not just be changed by/labeled as a not noteworthy update.Last modified on 2019-07-16 at 11:28

#18 by vdz

2019-07-16 at 11:30 < report >In-house engines should be cared about as they have technological implications that can be interesting. I frequently read VNs on an x86 tablet, and some engines just don't work on those; for example, Malie engine can't handle touch input and Liarsoft's in-house Rscript does not render properly on certain graphical setups (works on one of my tablets but not the other), while a game using Doddler's Unity-based engine, only used in-house for MangaGamer ports, will guarantee a game works 100% fine on both of my tablets.



Speaking of which, should everything running on Unity be grouped into the same big Unity category? It's not a VN engine, so you'd have to build a VN engine inside Unity (as Doddler did) or clumsily manually implement everything in Unity (I've seen some weird VNs do similar things, though not in Unity); I'd assume most releases would go for the former, and in that case there's a massive difference between Doddler's highly-polished engine and some clumsily made makeshift engine from someone who wasn't aware there's actual engines for this kind of stuff.

#19 by kiru

2019-07-16 at 11:33 < report >Few companies have more than one inhouse engine, and if a release uses another engine that can be licensed, then that engine is used there. A function to exclude specific engines from the search would help here, so you can see which games don't use "inhouse" of a given producer.



Not sure if we need to make different inhouse engines searchable, given that this is rather rare. We have the comment field already, where details can be written down. That'd just need to be encouraged. If there are tons of engines around, because every single inhouse engine gets a name, we get the same issue we already have with traits and tags.

And, like already mentioned, producers are searchable. So a simple "inhouse" as a category for engines is actually quite powerful on its own.Last modified on 2019-07-16 at 11:35

#20 by vdz

2019-07-16 at 11:48 < report >By the way, this might be a useful link. It's a mirror of the 'VN/Eroge script sizes' page that used to be on TLWiki, which includes the engine for a lot of games.



EDIT: @Yorhel, the forum's URL tag doesn't support links with spaces without replacing them with %20 :(Last modified on 2019-07-16 at 12:46

#21 by rampaa

2019-07-16 at 15:23 < report >Release filters>Misc>Engine field doesn't make any autocompletion while typing but it probably should.

#22 by lucumo

2019-07-16 at 19:25 < report >@kiru: As sakurakoi has already said, they aren't "completely different engines". I have worked with 2000 and 2k3 myself for instance and there is nothing "completely different" about it. Also, if you don't like that they are called versions, maybe tell the internet that it is wrong because they are generally referred to as such.

#23 by kilicool64

2019-07-16 at 21:58 < report >@18 While I agree with your argument, your examples aren't really the best. In-house engines that have official names like Malie and RScript can easily be identified and tagged accordingly. I was referring to engines that are not known to have a name. For example, many of KID's VNs seem to run on nameless in-house engines. And they clearly didn't use a completely new engine for each one, though it may not be feasible to determine how similar they are without close examination.



It's tricky (potentially even impossible) to document nameless engines in a way that isn't either too generic to be of any use, or impossible to utilize without guesswork or reverse-engineering. That's why I asked for suggestions.

#24 by eacil

2019-07-16 at 23:56 < report >To those who are working, not talking, here are 385 doujins that can be tagged with LiveMaker > link

On Freem, doujins tend to specify the tool they used (制作ツール/使用ソフト). You can search for LiveMaker link (387 results), then look at the doujin's page to see if it matches (i.e. if LiveMaker is under 制作ツール label or a another one you can translate online).

Also ティラノ (Tyrano(builder/script)) (764 results).

RPG Maker is called RPGツクール but it's pointless to search for that on freem for the purpose of tagging on vndb.



Edit: compilations of games shouldn't be tagged for the same reason they are not tagged with a developer. I tagged some but only if the engine was the same across all relations. I don't mind if they are removed.

My example of one release with two engines is not like that. Midnight Collection 1 has three stories, two of them being built with Kirikiri, the third one being built with LiveMaker. It's the only time I ever saw that so it shouldn't trigger the use of a dedicated table for engines.Last modified on 2019-07-17 at 00:04