Planning a Message System for the next Maker

[Andar]

Originally I planned to commission a new message system plugin for MV sometime this year, a message system that would add functions I miss in every other message system that already exists.
However with the news of the next maker that would be stupid to do, and instead I plan to look for people willing to develop this for the next maker - still paid of course, my original budget was 100$-150$ depending on which add-ons were made. And I always planned to make it publically available even after I paid for it.


Because this message system will most likely be the first to be programmed for the next maker, I want to use the opportunity to have it written in a way that will give other plugins the option to easily become multilingual if they check for this plugin.


The first step is to collect all features that should be in it - I already have a good list somewhere, but I want to use the time until the next maker is released to discuss and streamline these options. Feel free to add your opinions here, but try to keep in mind what is possible and what not.

After the new maker is released, we'll have to check what of the options are already included and how to make a plugin for the rest, and then to make the commission with whoever is interested and has helped in this design phase.




Here is an overview of the features I want:


1) redirect all texts into external text files with multilanguage options
This would work by having keystrings placed in the RM editor, and corresponding texts in external text files (one set per language). A new option screen would give a choice of available languages and then the engine would replace the keystrings in the game with the texts from the folder of the selected language.
And then the developer can easily adding of more languages by simply copying the text folder, translating it and adding the new folder/language to a language selection screen.


2) script functions for other plugins to redirect their vocabs
This is why such a plugin needs to be available as soon as possible: if the API is known, every other plugin can check if this multilanguage plugin is installed and get their vocabs from the language-based files instead of their own lists, making it multilingual without the need for code editing.


3) dynamic texts
This is what is missing in every existing message core/system for every existing maker.
No matter what, the show text command has always been static instead of dynamic, requiring a massive sequence of conditional branches to react to changes in the game story.
But because the texts are already redirected for the multilanguage option, it will only need minor programming to add an additional dynamic redirect for the show text commands.
This can then be used for newspaper posts, for quest messages, for random NPC-answers and more.

The following screenshot shows both the old/static and the new/dynamic way of handling answers for those who don't understand what I mean with the description above:



Basically this means to add a numbering/variable to the keystrings to allow for automated shifts to a different text. This could not only be used for a time-dependent newspost like the example above, but also for different quest hints based on quest progression or randomized NPC-answers and even (with an added eval-textcode) for random treasure chest messages.
It would even make adding more possible responses easier because it only requires adding more entries to the external text files instead of adding conditional branches and show texts to the event.


4) dynamic windowskin
The ability to switch between different windowskins during game, for example to give each character a different text frame when speaking


5) additional textframes
One of the biggest limitations of the existing engine is that show text has only one frame.
There are a lot of cases where a second or third text display frame would be invaluable, for example:
a help frame on the options of show choices, name frame over the text message, two text messages during a conversation, a text popup over events for short messages (conversation or "gained x gold" from chests and a lot more.


6) regular text formatting text codes
Basically what every other message system adds as well: text codes for font formats, changing message position and message size and so on.


7) image insert textcodes
This is also available as bust scripts, as image placements inside the texts, define how the message window transitions and similiar


8) special function text codes
anything that doesn't fit under the other points, and yes there are several like an eval-code.


9) plugin commands for changing message behaviour
Basically things like changing the number of lines or columns and positioning etc.


10) text codes in skill messages/battle log (optional)
I don't know if we will find a way to handle this, but in all previous makers the message scripts had problems when their text codes were used in the battle log of the battlescreen.
I'm reasonably sure that adding text codes there will be easier due to the redirect for multilanguage already in place, but on the other hand it can be that some codes (like adding pictures during the skill execution) will never work. That is why I declare this optional/add-on to be discussed later.


The main reason why I make this public at this moment is to collect wishes for the different text codes. The different programmers for the different message systems in VX, VXA and MV (Yanfly and Modern Algebra and others) all had different ideas of what text codes are needed, and as a result some of those text codes are not available everywhere.
Collecting all ideas before starting the work has a hope to make a message system that is really complete and will provide a standard for everyone.

This topic will have to be moved after the admins create new forum sections for the new maker of course.

 

[Andar]

Placeholder for definition of external text files and keystrings

Currently I think the keystrings that will be used as the placeholders in the editor should be defined as
file.group.key.number

The main use will become obvious in the examples below, but a short definition first:

The file is the textfile where the keys and their replacement will be stored, to give better options at managing the large number of keystrings.

group is a string to be used for sorting inside the text file. It's up to discussion if this should be fixed as a one-string option or if it should allow a hierarchy for better sorting.

key is the specific string that identifies where or what the texts are used for.

number is a number to be used in the dynamic redirect. It can be used either directly, or with a variable redirect, or with a random selection.


Example for the contents of the external textfiles
To be discussed: text parsing or json format or what else? The example below shows one possibility but it might be changed to another format for better use.

file: map0001.txt

[group:villagers]
  [key:tom]
    [n:1]Good Day, Stranger[\n]
    [n:2]Hello, my name is Tom[\n]
    [n:3]A nice day to you[\n]
  [\key]

  [key:margaret]
    [n:1]Hello, welcome to our village[\n]
    [n:2]Hello, my name is Margaret[\n]
    [n:3]I just wish it would rain more, the plants need it[\n]
  [\key]
[\group]

[group:news]
  [key:blackboard]
     [n:1]Day 1: Kingdom declared war on Empire[\n]
     [n:12]Day 12: Empire troops rampaging through town x[\n]
     [n:14]Day 14: King is looking for Adventurers to hire[\n]
  [\key]
  [key:townscryer]
     [n:1]All is peacefull[\n]
     [n:3]Soldiers required to travel to capital[\n]
  [\key]
[\group]

In the examples above the numbers at the end where basically set to show a time sequence (days counted), but in other cases different number definitions can be used - for example database IDs or random numbering or a lot of other options.

To help adapt the selection of whatever the number is used for, the message system will have several ways of manipulating or getting that number. Examples below are drawn either from the list above or from database entries:

No number in keystring means "use number 1"
map0001.villagers.margaret

direct number means "use that number"
map0001.villagers.tom.2

v[ID] means: load the number from the variable ID and use that number
map0001.villagers.tom.v[5]

r[n] means: select a random number between 1 and n and use that number for a random text
map0001.villagers.tom.r[3]

r (without number) means: select a random number between 1 and the highest number and use that
map0001.villagers.margaret.r
This is mostly so that a game developer can add random answers to the textfile for an NPC
without having to go back into the editor to change the random limit every time.

For the last option an example first:
database.actor.nickname.4 will get you the nickname of the actor with ID 4

p[index] will check for the ID of the party member in position index and use that ID to get info:
database.actor.nickname.p[2] will return the nickname of the actor in the second party slot.

if a number does not exist, use the next lower existing number instead (for example if the day has no news, news from the latest earlier day will be displayed)


The last point is the required database redirects. By using the number feature above to hold the ID of an entry, this can be very easily automated:



as can be seen there would be a specific file for the database entries, with the group being used for the database tab and the name of the field to be replaced. And then the number as the ID. That would add a lot of possibilities especially with the added codes for handling the numbers directly, randomly or indirectly.

There is one specific question to be discussed however: should these codes be used indirectly or hardcoded in? Both versions have advantages and disadvantages.
1) indirect coding
The plugin will look at the database, read the keystring entered there and then look for its replacement in the external text files.
The advantage is that everything works as usual. The disadvantage is that the additional step of getting the keystring from the database will make everything slower (whether detectable slower is not yet known)
2) hardcoded
The plugin will completely ignore the database and use the known keystring directly.
The advantage is that this will be faster to do. But it also means that there is no direct correlation to the editor, and that can make working there more difficult if the developer breaks discipline - he needs to enter at least the names into the database for the editor functions to be readable (like which actor to add - difficult with twenty empty lines that have no name). And if a mistake results in the names of the database being different than the names assigned in the external file - that will be a hell for bughunting.

That is one of the decisions where I would like opinions

 

[Andar]

Placeholder for list of textcodes
I removed all sample codes and the previous sorting, turning this into a true list of features that will be needed as text codes. I only divide between textcodes that will affect the entire show text command (like changing the frame) and those that only affect words inside the message (like changing text color).
The lists are currently unsorted, sorting will follow later.
Some commands might be changed or moved during planning as well (for example should a face be set for the entire message or should it be possible to change it halfway through the text?)



List of text features:
(affects next letters in the text, depends on position inside the texts)

• text replace (keystring): replace the keystring with whatever text is assigned to that keystring in the current language set of the external texts. Usefull both for macro functions, database placeholders and dynamic message construction.
• NOTE: The text replace above and a few other options might be handled by a preprocessing step on the developer's side to reduce the processing needed during playtime. This will require a design decision as to which codes would be changed during preprocessing and which ones have to be handled during playtime.
• change text color by windowskin definition
• change text color by RGB
• change text size (absolut or relative)
• change text font
• change text effects (underline, outline, italics, bold, shadow, highlight color, etc ON/OFF)
• change text speed (how many frames between two letters displayed)
• define text macro formats - shortcuts for sequences of formatting textcodes
• change face index inside faceset: for example to change expression during message.
• show icon (direct icon number or indirect by database reference for skill, weapon etc)
• eval javascript: both to trigger effects/switches during message and to have the message affect game data like adding items at the correct moment. Can be critical but it will be up to the developer to hunt bugs if he uses this for problematic code.
• conditional text: draw the next part of the text only if switch is on/off
• show animation (from database, should be screen-animation or needs target for other animation, target might be an event or the face of the message)
• show screen effect timed to text (shake, tint, overlay/weather etc)
• play soundeffect from database
• play audio/voice (possible to sync???) from filename
• play letter effects
• control default sound effects from above
• change volume and pitch of effects from above
• set sound effects on opening/closing of textbox
• set sound effect on show choice selection
• play balloon effect over character ID (event/player/vehicle)
• set wait/sync (number of frames until text continues, possible to sync with other things needs to be discussed)
• set pause prompt/wait for action button
• skip or disable controls by textcode
• replacement codes: probably not needed - a lot of the old message systems had text codes for accessing database names (like # \nw[n] - Draw the name of the weapon with ID n). This is automated because the multilanguage option requires the entire database names to be redirected anyway. However the regular text keystrings are longer than the old replacement codes, so in some cases shortcuts might be usable
• name of event n on the same map
• name of switch with ID (mostly for debugging messages)
• name of variable with ID (debugging)
• name of current map
• name of map with ID
• shortcuts to gamedata(?): text code for gold number instead of loading it in a variable and showing that variable and similar effects where they might be needed.
• shortcut for currency text
• line break/new line
• new page (if using longer texts and automated message windows)
• add variable spacing (number of letters or pixel??)
• show variable
• include default text codes

List of message features:
(affects entire show text command, might be limited to beginning of the texts)

• namebox (string): activates a name box above the show text message containing the text given. might or might not use a keystring instead of a direct text string
• position commands for namebox positioning (relative or absolute)
• helpbox (string): (show choices) activates a text box at the top of the screen with a text depending on the currently selected choice
• position commands for helpbox positioning (relative or absolute)
• secondary text (string): (show text, but might be the same as the helpbox code): activates a textbox at the top of the screen with a text that is displayed while the rest of this text goes into the regular textbox below. either to give comments/tutorial option or to better simulate two people discussing things or whatever.
• position commands for secondary text box (relative or absolute)
• show gold window (positioning commands similar to namebox)
• set windowskin for this message box to a different one
• set background picture (replace windowskin with a custom picture of a message frame)
• change face/faceset based on database ID.
• change face/faceset based on party index
• change faceset based on filename
• change face opacity
• change face tint (either absolute or take on whatever screen tint command is currently active)
• change face blend type
• change face border/frame width: show the face with or without a border drawn around it (and how thick a border)
• animate face: automatically cycle through given indices of the faceset after x frames or after x letters. might need other data, for example if using not all eight indices for animation.
• show bust picture left
• show bust picture right (mirrored?)
• show screen picture as background (behind busts if used, or dependent on setting z?)
• allow/set bust and screen pictures above for animation options
• change side for face inside textbox (left/right)
• change face position (X, Y, left, right, center, mirror, absolute values or relative to screen size, etc)
• set message box effect for opening (fade-in, scroll-in, slide-in, no effect)
• set message box effect for closing (fade-out, slide-out, vanish,...)
• set text border - how many pixels space should be between message frame and text? (this is especially important if the windowskin is replaced by a background picture
• set window size (pixel or number of lines and number of letters wide)
• fit window size to text amount
• enable/disable word wrapping: Especially important considering that the developer will write most texts in the external textfiles without seeing how they fit into the message window, but it needs to be toggable on a per message basis because some texts use linebreaks for effects.
• enable/disable message combining - automatically combine short show text messages to single boxes and automatically continue larger texts in additional show text boxes. Will help with different message sizes due to translation issues between languages. This can be very critical to implement as it would remove the developer decision on text pacing however.
• set text alignment (left, right, center) for the message. This is both more important and more complicated as the engine can now have different screen sizes and can change size of message windows as well
• set text speed (time for letters to appear) in general for the entire game, for specific text boxes and for specific parts of the text
• scroll speed controls for show scrolling text
• pause or skip message options (different buttons during gameplay)
• control scroll type (stop scrolling text per page and similar variants)
• manual scrolling in scrolling text (read back up etc)
• define default text formats for different window types (like every namebox with textcolor n etc)
• show choice formatting: allow choices to be set differently than 6 below each other (for example in a number of columns of a table, especially important if a lot of options are combined)
• show choice combining: automatically combine several show choice commands into one selection table if the commands are one after each other
• show choice optional: hide or disable any choice based on switch or scriptcode
• show choice effects: change helptext or audiofile or whatever on moving between choices, but have those commands read from a comment or text inside the choice branch due to limited editor space in the choice itself
• set default and cancel options for show choice by textcode - especially important for combining multiple show choices as the editor would have multiple defaults then.
• 
  

List of special features:
(basically where I'm not sure how to handle them)

• event text (short string): Instead of a regular message box, this string is displayed in a small text box above a targeted event. Might be better done as a function call instead of a textcode
• positioning commands for event text (relative to event, event ID or player or vehicle etc)
• bust-sets: I propose to use sets of bust pictures of actors in the same way as the face-sets, especially to allow the same options/commands for animations and changing expressions that are commonly used by faces as described above. This would also include a filename correlation between faceset-filename and bustset-filename, allowing the plugin to automatically switch between the face set in the database and a bust of the same actor/expression
• short macros: Basically every keystring is a macro as it will be replaced by whatever it stands for, just with the language selection and other features added in. And every developer can define some keystrings like macro.hero => \C[4]\P[9]\C[0] and more. But sometimes even such macros are too long to type and some special abbreviations should be made possible.
• Redefine face size (???) - this is for discussion. should the plugin have options to redefine the size of a face? on one hand this would be a nice feature, but on the other hand the new faces won't work in the editor (the message window could be adjusted in different ways for the new sizes)
• Allow for different languages having different text directions (right to left or left to right or even top to down). This might even be usable on a per-message base as a text effect in the game - but I'm not sure how easy it is to implement (should be easy at first guess, but I don't know how those other languages work)
• toggle display options: allow the player to choose between different sets of configuration to adapt to his display preferences (not only color scheme, but also different sets of pictures (if available) as to style, age preference, (N) SFW and more). This might be a nice feature, but question is which developer would really use it as it would be a lot more work.
• Actor ID from Party Index reference/calculate
• Check which textcodes will be usable in skill messages/battle-log. This has been a problem in previous message systems but need to be solved for multilingual redirects anyway.
• enable picture codes for skill messages (stop battlelog and battle while displaying them)
• text cypher/resequencing: exchanging letters based on code to simulate hidden messages or different languages. Has nothing to do with a messaging system, but can only be implemented on this level of the engine.
• Adding variants to default vocabs, for example making the battlestart message depending on troop ID instead of fixed for all troops.

Notes:
(reminders of what else might need to be done)
1)
faceset is limited to 8 by default. having different expressions and animated faces might need more pictures, or a way to mix pictures (for example a blinking animation only requires two pictures, so four expressions with two frames in would fit IF the plugin has some way to set how many frames an animation has etc.
it is also an option to define larger facesets of more than 8 pictures for use with this, but where is the limit to options? to be discussed.

2)
help/tutorial needs a reminder that different languages have different text lengths, and that might break some message boxes depending on wording. However the handling of this problem should be the responsibility of the develper and translator as there is no automatic translation anyway.

 

[Andar]

Placeholder for list of script functions and plugin commands


One of the most important functions will be a vocab-API for other plugins.

The base function should be a function that gets a keystring and returns the corresponding text from the textfiles, to be used in whatever other plugins to get their vocabs to whatever they do.
That function will allow other plugin programmers to easily give multilanguage functions to their screens and outputs.
Main problem is that this might disable the option to have the vocabs set in the plugin option screen for those cases where this plugin is not used, and that would cause the other plugins some problems - unless we find a way to implement this with both options.

 

[caethyril]

I feel like we need more info before being able to speculate on implementation-related stuff like this, but I get that you're mostly polling for ideas here.

One escape sequence I feel should be there from the start is something to select face image/index, e.g. face of party member 1, expression 3. I'm guessing that'd be included under "regular formatting codes", though, if it's not already present by default.

Some message escape sequences can be implemented via a generic approach: an eval at its simplest. This is only really valid for effects that process on the spot and/or exclusively use properties of the existing message system, e.g. run a common event, or randomly select a string from an array. It's a nice fallback option, but requires code for maximum flexibility: copy+pasted from examples or otherwise. (I wonder whether hybrid parameter types like "note + preset list" will be available?)

Some sequences may need specific overrides, e.g. adjust the message display rate (frames per character), or adjust face position/size/hue/etc. The former would be "generic" if the delay were variable, rather than a fixed value of 1 or 0 frames; the mutual face/text positioning would be "generic" if there were separate sprites for face and text, rather than them both being blitted onto the window.

Other requests I've seen include: play a sound, tint the screen, wait a random interval, and substitutions/"macros" (including stuff like \A = \c[5]\P[1]\c[0] and "rainbow text").

I'm hopeful, given how oft-requested multi-language support is, that the new RM will feature text banks by default: basically just an extension of the Terms tab seen in RMMV to cover all in-game text (including Show Text references). Guess we'll have to wait and see~

 

[Zeriab]

Good idea Andar

Internalization is difficult as language behave differently. Google have made an excellent article on the matter: https://material.io/design/typography/language-support.html
Apple has made an interesting take on how to handle plurals among different languages: https://help.apple.com/xcode/mac/current/#/devaf8b4090a
I hope they can be of some inspiration.

It would be cool to include some accessibility options such as larger font and/or greater contrast.

*hugs*

 

[Shaz]

I haven't read through your entire list, so apologies if I say something you've already got listed.

- name box
- faces vs busts, all dynamic
- word wrapping (will be needed with all the replacements happening)
- variable height
- right-to-left text

 

[Andar]

I feel like we need more info before being able to speculate on implementation-related stuff like this, but I get that you're mostly polling for ideas here.

yes, this is at the collection stage at the moment.
And I really hope that they add a default multilanguage option to the editor as well, but I highly doubt it. So far Enterbrain and Kadokawa have always developed for the japanese market first. But perhaps Degica has been able to put their foot into the door a bit farther by now, they got some more access and responsibility with MV compared to previous makers at least.

Internalization is difficult as language behave differently.

Quite correct, but that can't be handled beyond minimal help in the scope of any message system.
It has to be handled by the developer and translater, and the maximum we can do is give a hint in the help that this has to be checked.

- right-to-left text

Quite right, and I would have forgotten that option without your reminder.
Unfortunately I'm not sure if it is as simple as a redirected letter display a I don't know any language that uses right-to-left text.



I refomatted the lists for better readiblity, but I'm not yet finished with adding even the features I have in the rlists from older message script. Will do that over the next days.

 

[caethyril]

faceset is limited to 8 by default.

Just to note: in RMMV you can have facesets with more rows. You need to use an external graphics editor to make/merge the facesets, but I can confirm it works with four rows (16 faces in one file), both in the editor and in-game.

 

[Andar]

I've entered every feature I could find or think of so far, but if anything is missing please state so.

What I would like to discuss and hear opinions of first is how to handle faces and busts.

For easy handling I propose to organise busts in the same way as faces, and have them use similar filenames. The question is if this is possible due to the larger picture sizes of busts.

if actor1.png is the faceset filename, then !actor1.png would be the corresponding bustset filename.
$actor1.png would denote a single face filename, and !$actor1.png would be the corresponding single bust filename.
Optional: use # for corresponding battler pictures (#actor1.png) - might not work depending on other formats.
Optional: use # for a third type of picture (full body?) if not used for battler, to allow other options to be used on displays

I can confirm it works with four rows (16 faces in one file), both in the editor and in-game.

The sets would be 4 columns, but it would remain to be seen how many rows can be used.
The indexing would allow both counted indices (0..7 for two rows) and grid counting (row=2, column=1 for example). That is due to the next features.
Default use would be to use rows for different expressions and the columns for animation cycles (similiar to other cases).


The animated face options come from modern algebra's ATS series of scripts, and they animate by switching indices on facesets - both for blinking and frame animations. However those options were in my opinion needlessly complex by allowing too much settings like number of animations used.
Instead I propose to set only animation types and requiring the facesets to follow specific rules for them.

1) blinking
Blinking is changing two faces, allowing two different blinking expressions per row.
no matter which face is selected, blinking will switch either between column 0/1 or column 2/3 of the faceset.

2) animation cycle
The face will change through the entire row of faces in a sequence 0-1-2-3-0-1-2-3-

3) animation pong
The face will change through the entire row of faces in a sequence 0-1-2-3-2-1-0-1-

If a bust replaces the face in the message, then the animation settings should apply there as well.

Questions: is such a bustset possible? Or would that get to the limits of the picture size too fast?
If bustsets are too much, how best to handle alternatives?

 

[Solar_Flare]

I feel like the focus on localizable keystrings is perhaps misguided. The screenshot posted by Andar strikes me as quite a poor way to edit your database, as you have no idea what all those keystrings really mean. I suppose if you make your keystrings more descriptive it could be okay, but it still looks kinda bad. You're making it harder to edit your game by doing this.

There are other ways of localization than assigning all strings a unique key, but assuming you prefer that method, why not have the plugin automatically generate the key for you? Taking Andar's screenshot as an example, you could place your base language text directly in the name / nickname / profile fields in the editor, then add some note tag like <tag_base:database.actor.1>, and the plugin would know that the actual keystrings are then database.actor.1.name, database.actor.1.nickname, database.actor.1.profile.

Besides that, a few other features that would be nice to have in a messaging plugin (not sure if these were mentioned before):

• Built-in support for pictures (busts etc) instead of face graphics
• Substitution codes to print the name and icon of a skill, item, weapon, or armour. (It's not hard in MV, I already coded it for my own projects.) Could also add states and enemies (though obviously enemies don't have an icon), maybe there are other things too where you might want the name.

I don't actually plan to get the new maker, mind you... though that could change, I suppose.

 

[Andar]

why not have the plugin automatically generate the key for you?

That is the question I asked above about that, the question if the keys should be hardcoded in or not.
And it is a question because of the disadvantages you have when you automatically code that part.

If you automatically set the keystring, then the engine will ignore the database entry itself. And then a lot of people will not place anything in the name fields, or even place the wrong entires there (not even intentional - just add something later and forget to correct the other entry if it is automated).
But we have to assume that the editor itself can't be modified (that was never possible before), so all references would come from the now unused database fields. And having the editor lists be empty or having old versions will make referencing the events much more difficult.

you could place your base language text directly in the name / nickname / profile fields in the editor, then add some note tag like <tag_base:database.actor.1>

That is the worst idea possible, because then the coding would have to check and decide where to take the text from - not to mention that other places like the show text commands have no notes box and would need the keystring placed directly.
If the text is always in the external files, then referencing the correct one is a short code sequence.
If some language is placed directly and the other languages are external, then the code for deciding where to look for the real text is much more complex and will create additional lag for the game.
A redirect for the database is already problematical, but a conditional multibranch redirect to different places is much worse.

Substitution codes to print the name and icon of a skill, item,

no need because the redirects already exist. After all, every entry in the database is already redirected, and you can simply use that keystring as the substitution code.
In some cases a shortcut might be preferable to using the full keysting, but that is also one of the options already listed above - and the busts are also listed and given a specific definition together with the faces above.

 

[Solar_Flare]

That is the worst idea possible, because then the coding would have to check and decide where to take the text from - not to mention that other places like the show text commands have no notes box and would need the keystring placed directly.

That idea only applies to the database, and it's not really complicated to decide where to take the text from. For show text commands you'd probably just put the key value in like you're doing now.

If the text is always in the external files, then referencing the correct one is a short code sequence.
If some language is placed directly and the other languages are external, then the code for deciding where to look for the real text is much more complex and will create additional lag for the game.

I believe it could be done in a way that doesn't create any additional lag. That said, I don't feel that moving all text to external files is the correct answer - it makes it more complicated for the user to edit their game. The localization plugin that I am developing does not even use key strings at all - you just edit your game essentially the same as you would if you were not planning to localize. At most there might be a little lag when the user switches languages; I haven't experienced any (with the F8 window closed) but on a larger project maybe there could be some.

no need because the redirects already exist.

I don't believe those redirects account for the icon, do they?

 

[Andar]

and it's not really complicated to decide where to take the text from.

the problem is not how complicated it is. The problem is that this needs processing power for every single use.
If you look at earlier message systems for Vx and VXA, everyone that has the option to apply textcodes in the database has especially warned against overuse of that, because the database is already referenced very often and adding unrestricted text code handling to it would have caused the engine to slow down considerably. And in MV, the text codes available for database use is only a small part of the total options.
Making a total redirect should keep this lag within handable limits. Making a conditional redirect with different branches will increase the lag produced by this a lot. And yes, that is a lot of lag - not so much for a single decision, but since you have to do that decision for every database field every time it will add up a lot.


There are basically only two ways to handle multiple languages.
The first one is to start with the redirect like I did above. This will allow you to decide on the keystrings and make them human-readable like I did above. Then the translation work can be done by simply handing out the external text file to a translator who then translates them to any new language.
This does not even need editor access for translation, and a new language can be added at any time.
However it only is easy if it is prepared at the beginning of the development.

The second way is to have an external program replace the language inside the gamedata. This does not create a multi-language game, but creates multiple single-language games. And this can only really be done after the game is finished as each editing of the game would require a repeat to copy the edits into the other language versions.

I don't believe those redirects account for the icon, do they?

no, but the icon textcode already exists and is mentioned above, and I also included numerous examples of ID mathematics. The same can be applied to get the indirect referencing of the icons of other parts.
This might be one point where shortcuts or macros to shorten that are important, but I've mentioned those in the texts - and intentionally didn't specify details as to what textcode would get a shortcut or not, because I have several ideas on how to handle that and can't make everything of it work.

you just edit your game essentially the same as you would if you were not planning to localize

And that is the biggest disadvantage, one that I specifically try to prevent.
If the translator has to use the editor, then that would require him to own an editor licence and know enough of the editor to find and assign every place where there is a translation needed.
That is nice for cases where a single developer knows every language the game is supposed to be translated to, but it is bad for teamwork where the main game developer looks to hand out translation to other people, people he often finds over the internet and have limited download bandwidth or other access problems.

 

[Solar_Flare]

the problem is not how complicated it is. The problem is that this needs processing power for every single use.

Yeah, that could be a problem, but why do you need processing power for every single use? Just replace everything once whenever they switch languages. That could still lag, mind you, but it only lags once. It won't lag while you're playing, only when you switch languages.

There are basically only two ways to handle multiple languages.
The first one is to start with the redirect like I did above. This will allow you to decide on the keystrings and make them human-readable like I did above. Then the translation work can be done by simply handing out the external text file to a translator who then translates them to any new language.
This does not even need editor access for translation, and a new language can be added at any time.
However it only is easy if it is prepared at the beginning of the development.

The second way is to have an external program replace the language inside the gamedata. This does not create a multi-language game, but creates multiple single-language games. And this can only really be done after the game is finished as each editing of the game would require a repeat to copy the edits into the other language versions.

You might be surprised to learn that many, many programs do not use either of these options. There is a software library for translations known as "gettext", which is closer to your first option but still significantly different, without magic redirect codes. Mind you, redirect codes are also fairly common, and both ways have advantages and disadvantages...

And that is the biggest disadvantage, one that I specifically try to prevent.
If the translator has to use the editor, then that would require him to own an editor licence and know enough of the editor to find and assign every place where there is a translation needed.
That is nice for cases where a single developer knows every language the game is supposed to be translated to, but it is bad for teamwork where the main game developer looks to hand out translation to other people, people he often finds over the internet and have limited download bandwidth or other access problems.

I think you misunderstood. The translator doesn't need the editor - you just pass them a text file to translate, the same as with the first translation method you mentioned. The developer, however, can just edit their game normally without worrying about translations. Even if the translator did have an editor license, even if the developer is the one translating it, translating the game in the editor would be an awful experience... I wouldn't wish that on anyone...

 

[Andar]

Yeah, that could be a problem, but why do you need processing power for every single use? Just replace everything once whenever they switch languages. That could still lag, mind you, but it only lags once. It won't lag while you're playing, only when you switch languages.

You do know that the RPG-Makers use an interpreter, not a compiler?
That is one reason why they are always need more processing power than a compiled program for the same functions, but it is also the reason why they handle bughunting better than compiled programs, especially considering that they are used by hobbyists who know next to nothing about systematic bugunting.
And that means that the decision between languages will be recalculated every time the database is accessed, it cannot be done as a precompiler decision.

I think you misunderstood.

or could it be that you misunderstood?

Yes, there are many ways to handle translations - but they come down to variants of the same principle.
And you need to have a way to pinpoint which text is used where, and that should not be done by an automated assignment - because then the translater would not be able to get a context for the sentences he is translating. And believe me, I've seen translations from so-called professional translaters that were completely misleading because the translater missed the context, up to mistranslating the title of books if that title was a wordgame in itself and other cases (using an electrical lamp in medieval ages as another example and more).

if you think you know a better way to handle this - please feel free to explain that how instead of just pointing out what you consider a bad decision.

 

[Zeriab]

the problem is not how complicated it is. The problem is that this needs processing power for every single use.
If you look at earlier message systems for Vx and VXA, everyone that has the option to apply textcodes in the database has especially warned against overuse of that, because the database is already referenced very often and adding unrestricted text code handling to it would have caused the engine to slow down considerably. And in MV, the text codes available for database use is only a small part of the total options.
Making a total redirect should keep this lag within handable limits. Making a conditional redirect with different branches will increase the lag produced by this a lot. And yes, that is a lot of lag - not so much for a single decision, but since you have to do that decision for every database field every time it will add up a lot.

Not really. In VX and VX Ace the act of drawing the text takes vastly more time than such conditional handling would.
Hmm... in VX Ace with enough notes and the standard style of note parsing with a large number of regular expressions you could get slowdowns at startup. Is this what you are talking about?
This step is basically transform data in the notes in form of basic text data into a form better suited for use during gameplay. There is no need for the player to go through it, so a preprocessing step could be introduced where the dev does it before the game is released, and the game then just loads the result. Lag will be gone.

I suggest you try not to let your guesses at what might cause lag limit the design of the message system. There may be good solution which fixes or circumvent the issues you imagine.

*hugs*

 

[Solar_Flare]

You do know that the RPG-Makers use an interpreter, not a compiler?

Of course I know that...

That is one reason why they are always need more processing power than a compiled program for the same functions, but it is also the reason why they handle bughunting better than compiled programs, especially considering that they are used by hobbyists who know next to nothing about systematic bugunting.
And that means that the decision between languages will be recalculated every time the database is accessed, it cannot be done as a precompiler decision.

My point is you don't need to look up the string anew every time it's needed. You can look up all the database strings when the game starts, and map/event strings when the map loads, and then the string is just there when you need it, the same as if you weren't translating the game at all. (This is basically the same thing that Zeriab said, now that I think of it.)

or could it be that you misunderstood?

Whether or not I misunderstood, you said the translator needing to use the editor was a disadvantage of what I said, when I never intended to imply that it was even a feature of what I said. To be clear, I completely agree with you that needing the editor to translate the game is not good. But I think it's also not great if the developer has to keep track of the strings separately in an external file. If you are writing a program like the editor itself that's relatively light on text, then it would be fine, but for a game with narrative and dialogue, I think it could get confusing fast.

if you think you know a better way to handle this - please feel free to explain that how instead of just pointing out what you consider a bad decision.

I was resisting going into too much detail because I'd have to write it out again anyway if and when I post my localization plugin on these forums, but... the basic principle of my localization plugin is to directly edit the database (the $data* variables) at runtime and substitute in translated strings. (To be clear, when I say "editing the database" I mean the loaded copy of the database. It doesn't touch your game files, so the unaltered version of the database is still loaded every time the game begins.)

That doesn't catch all the nuances of it, of course - in order to switch languages on the fly (rather than requiring a restart), there has to be something that knows which string belongs where, for example (for this, I'm using an XPath-like syntax).

For the most part, the developer doesn't need to engage with this at all - the paths for each string are automatically determined by the plugin. The only thing the developer needs to do (assuming no other plugins, which is admittedly a bad assumption) is export the central text catalog to a file (specifically a .pot file, which as I understand is a de facto standard for localization catalogs and can be edited with a wide variety of external tools), translate it (or get it translated), and import the translation back in.

Again, there are a lot of complexities to it that this description doesn't really cover, and most of those complexities are caused by plugins, but that's the basic idea, and it works in all my testing so far.

Whether or not this is a better way to handle localization is probably a matter of personal preference. It works for me; perhaps some people would prefer a key-string method or translating the finished game as the last step to produce separate copies of the game in each language. Still, the fact that such a method exists is, in my opinion, a reason not to encode into every plugin an assumption that key-string is the only type of localization that exists.

 

[Andar]

Whether or not this is a better way to handle localization is probably a matter of personal preference.

your way works, but as you yourself said there are some disadvantages. But not at the places you think they'll be. For example if you're carefull with placing the exchange functions and do that very early in the engine sequence then most plugins will have no problems with this. But it will make the plugin order more important for all games that use your plugin.

What I would consider a worse disadvantage is that this basically only works for the database, it will be much more difficult to handle events with your way, and events will require a different process.
In my case everything will use the same principles, which will make it easier on the developer.
Additionally your solution is only for translation, it does not include any update to the message functions like face or bust options. You can't change anything there when going your way (it's a different access level) while I'm using the same text replacement functions for the translations to add in a lot more utility to the texts themselves, and hope to create synergies that way.

I suggest you try not to let your guesses at what might cause lag limit the design of the message system. There may be good solution which fixes or circumvent the issues you imagine.

That is one reason why I made this part public - to confirm or reject some of my assumptions while working on the design.
Although your idea of preprocessing only partially works, there are a number of options listed above that need to be handled at the exact moment of the player's gametime. Not the translations obviously, but things like the dynamic redirects and eval options.

But the question that needs to be answered in this is whether it would be better to split the options on those lines and handle them differently (preprocessing where possible, dynamic calculations where needed) or would the combination of both during runtime still be more effective than the gain by separating them.

I haven't fully placed my thoughts on how to handle the multilanguage options above as I was more concerned with the message system options themselves, but basically I would create a language folder with one subfolder for each language. And the language selection would simply change the language path that determines from which folder the textfiles are loaded.

But there are a number of textcodes that would be easier to handle with preprocessing, in that you're correct. So I'll edit in a reminder of that

 

[Solar_Flare]

your way works, but as you yourself said there are some disadvantages. But not at the places you think they'll be. For example if you're carefull with placing the exchange functions and do that very early in the engine sequence then most plugins will have no problems with this. But it will make the plugin order more important for all games that use your plugin.

I'm not sure what you mean about making plugin order more important. The method does work for some plugins. It doesn't work for the Kadokawa plugins, though; you have to modify the plugin to make it work. But for the plugins it does work with, they don't need to know anything about the existence of the localization plugin. They just do their thing as they normally do.

What I would consider a worse disadvantage is that this basically only works for the database, it will be much more difficult to handle events with your way, and events will require a different process.
In my case everything will use the same principles, which will make it easier on the developer.

It's true that handling maps and events with my method is trickier, but it does work. The process isn't any different. I do need to run the substitution each time you switch maps, though; but I don't resubstitute the entire database, only the newly-loaded map.

Additionally your solution is only for translation, it does not include any update to the message functions like face or bust options. You can't change anything there when going your way (it's a different access level) while I'm using the same text replacement functions for the translations to add in a lot more utility to the texts themselves, and hope to create synergies that way.

Well, my solution is explicitly for localization, yes. I'm not sure why it would have other options for the message system, as that seems like an entirely separate function to me. I'm not sure what you mean by "different access level"?