Expanding the use of the speech voice files (naming limits and translations)

[ghost]

Current situation with speech voice-over is:

• only 1 speech.vox pack is supported and read from;
• there's no automatic solution to adjust played voice clips depending on selected translation;
• voice clip filenames are restricted to NNNNXXXX.ext format, where NNNN is four first letters of character's script name and XXXX is a number 1-9999. I believe this name format may be a legacy of DOS support (8.3 filenames).

The name rule may cause conflicts between characters with similar script names and usually forces gamedev to edit script names to make first 4 letters unique.

Limit of 9999 clips per character may be less critical, but sometimes being ran into. (In such case they usually use dummy characters to increase number of slots. AFAIK they may also use this trick to merge different languages into one VOX.)

My suggestions are:

1. Regarding multiple translations

1.1 Create multiple VOX packages.

Game compiler will treat any subfolder inside Speech folder as a separate VOX content. Resulting VOX will be called "sp_N.vox" where 'N' is a subfolder's name. Files from Speech folder itself go into "speech.vox" like they do now.

1.2 Support switching VOX package at runtime

There are two alternatives here: automatic and manual.

Automatic solution looks for the "sp_N.vox" with 'N' being equal to the current translation name. If "sp_N.vox" is not found, then looks for default "speech.vox".

Manual solution would require introducing new script commands to set translation explicitly for voice-over. This would also allow to have text in one language and voice-over in another language.

These two solutions may co-exist.

2. Remove old naming rule

Instead voice clip format should be "NX.ext", where N is full character's script name and X any number, let's say, fit into 32-bit integer.

@messengerbag has suggested an alternative to this: introduce new Character's property to define voice-name, which is equal to its script name by default.

[morganwillcock]

Sub-suggestion: to also support a game compiler that packs sprites that it finds on disk, rather than have import performed in the editor, there is a similar requirement to map some named (or numbered) resource to data that has been built into game data. If there were a generic method for defining the mechanism that can be used to find a resource, it could be used as a generic loader to retrieve any type of data. So something like a resource loader that can be be configured to take tokens (like a character name), or a glob pattern (to find based on the original folder structure), or whatever method was needed for a particular resource.

Also, I think that console ports have already introduced a virtual file system, so perhaps there is some crossover here.

[ghost]

Sub-suggestion: to also support a game compiler that packs sprites that it finds on disk

Well, speech file is already gathered from disk, so the only change necessary there is to redirect it to different folder. Nothing new has to be implemented (and my idea was to do as less as possible in this case).

Sprites are different, a number of things has to be remade first. So I don't think this is related task.

EDIT: And there's another thing, right now editor can do "lazy compilation" when it does not pack audio files unless doing full rebuild and lets engine read them right from the disk. But engine cannot do same thing with sprites, because... well, for various reasons: it needs different loading logic, and some kind of a reference table to match numeric IDs to filenames (right now it matches IDs to file offsets). What I am trying to say, this looks like a big topic on its own, not a subtopic within this issue.

[morganwillcock]

it needs different loading logic, and some kind of a reference table to match numeric IDs to filenames

Yes, the suggestion would be to offer a direct mapping from game resource to data offset as one option of a loader, but also add other mappings which could dynamically load data based on other rules.

[ghost]

Also, I think that console ports have already introduced a virtual file system, so perhaps there is some crossover here.

Yes, the suggestion would be to offer a direct mapping from game resource to data offset as one option of a loader, but also add other mappings which could dynamically load data based on other rules.

I begin to think there may be 2 levels of virtualization, one is virtual assets system (it's already implemented but limited in use case) which aim is to map asset ID to the loading rule (and maybe bundled with asset caches), and second is virtual file system which controls access to raw data.

[ivan-mogilko]

The multi-VOX feature is resolved by #1453.

Extracted the naming rule part into the separate ticket: #1456.