Localization. Part 1
This is a continuation of the Localization article . Start
Copper pipes
So, the first game is transferred, the money received as well as the satisfaction of the work done.
What changes after that?
After that, you start looking at the games in a completely different way. As an architect, who can no longer fully enjoy the beauty of the house, as a designer, who sees the advertising poster not like everything ... and the poor localizer, already looks at the game quite differently, mentally sorting it out into pieces.
Personally, I still have a habit. Having installed a fresh game that I want to watch, I don’t launch it. Not. I go to the directory where it is recorded and see how the data is organized, what the video is recorded in, what the sound is, where the textures are, where the texts are ... This happens so mechanically that you don’t think about it.
')
And only after all this, you start ...
The following observation is associated with visiting places where they sell discs. Here the copper pipes for the first time make you know:
- Did you play “Hostile Whirlwinds”? (Warwind)
- Not…
- On, play ... in Russian ... class!
And inside wakes up pride for the deed, a happy smile creeps on the face itself ...
Then the seller tries to sell you your transfer ...
This seriously affects your motivation and work on future games. And both in a positive and in a negative direction.
How we worked ...
However, let's continue and consider the stages of disassembling the game.
For the programmer:
- Install, climb into the directory to see what is where
- Start the game, set up, remember some text, preferably not “New Game”, but from the gameplay itself, ideally a piece of some briefing, or dialogue in text form
- Play a little to understand approximately: is there any text on the textures, what sound, how much is it
- Exit the game and search for text, in different DOS / WIN / UNICODE encodings, etc.
- Cut the text to give translators with comments
- Search for sound and cut it
- Calculate the duration in minutes, tell the manager, let him think “is it worth it?”
- Having received a positive response, to decrypt the sound as necessary
- Give sounds to translators
- Engage in decoding fonts in pictures
- Cut fonts into pictures and give to the artist
- Draw a couple of letters in the texture itself with the font, and a couple of Russian letters in the text
- Try to paste the texture with the font back
- if you had to decode the sound, write the encoder :)
- Try to insert your sound into the game.
- Get the first texts from translators
- Get texture from artist
- Collect the first version, show the manager
- If inaccuracies are noticed, write down in a piece of paper (this is important! Write down a piece of paper into a piece of paper! Otherwise it will be skipped)
- Collect fonts from ready-made textures
- Get all sound and text, collect
- Show first version to people
- Collect and show until you get bored, until comments and corrections run out or until it is decided, well enough, send ...
...
Approximately such a work plan. Slightly messy, of course, and not always everything happens that way, but mostly similar.
So, we have four main areas of work:
- Disassembly - assembly
- Text translation; Video translation and script writing for actors
- Drawing
- Sound engineering and sound cutting
Sound
Here mikeSP perfectly wrote about the sound.
I'd add from myself that everything was much simpler.
Storeroom / Toilet, many trays from under the eggs, copper wire with a stretched stocking (spittoon, ts :)) In order for the microphone not to record the sound of particles of saliva falling on it when you speak. And finally a microphone for crazy money. The sound was recorded in the presence of only a working actor and operator. All the others went “to the garden”, i.e. work at home.
Today I will try to tell you about the basic principles of disassembling the game into its component parts.
Break not build
Disassembly primarily requires a very good knowledge of various formats and file types. Graphics, objects, sound, text, encodings, basic encryption methods. What I am trying to figure out is whether the file is or not - you need to know how it looks, mostly in machine codes.
If the developer was lazy / low paid - he just sketched the files in directories. These cases are the most relaxing, here you do not need anything, just take it and copy it. But it happens differently.
If the data directory contains only files like: “textures.dat”, “sound.dat”, “music.dat”, “video.dat”, etc.
There will have to make a utility that will be able to disassemble / assemble such files. Such utilities are most often written for a specific game, because even the same person never writes the same programs.
Most often, data is organized according to the principle
- heading
- table placement
- data blocks
For example, take some hypothetical file “sound.dat” and open it with a simple (hehe) and handy hiew32.exe program. The name itself suggests that there should be a sound. The first thing you can look for in it is the abbreviation RIFF, i.e. standard media header, and if found, then you can safely cut the file from the header to the header - lucky. You can quickly cut the cutting program and listen to what and where, and if there is any sound, give it to the translator, let him sort and translate while you look for the table - the title to this / in this file to insert it later. Without a title, almost never files are found. I mean data files that are merged.
What I'm getting at is that if you are sure that you have found the beginning of some file inside a large file, which is called respectively: “dat”, “dta”, etc. - you can safely search in this file for a link to the initial offset of this piece, and with very high probability - this will be the table.
So, our actions:
- We are looking for familiar headers / identifiers of the beginning of files inside a large data file
- remember the initial offset
- read the file size by calculating "offset2" - "offset1"
- look for the found numbers in this file
- Analyze the found table structure. We try to align values ​​by 4 bytes, by 8m.
- We write a program that will parse the file on the basis of the table.
Do not forget that everything is written in the reverse order, i.e. the number 0x8FBD55 will be recorded in the file as 0x55BD8F. Those. from low byte to high (clever and frightening not familiar to him man the word little-endian :).
Disassembling on the basis of the table, and not just like that, you need first to collect everything back later.
The game should use the data we created and not suspect that they were changed, right?
A self-respecting developer, is trying with all his might to complicate the process of data parsing.
Sometimes the table is encrypted and hidden by all known methods. But after all, SoftICE and other excellent programs were invented for this. Working with these applications is another story. :)
It is necessary to add that lately a person who wants to organize data in his game and really does not need to write anything himself. Written a bunch of libraries that just take it and use it, notifying the author, or no need for notification at all (gzip for example)
Files created in this way can be easily understood with the help of utilities from the author of the method itself or with the utility already written by the wizards, which breaks the file into pieces.
For example MPQ format from Blizzard. Great job on writing your own file system with support for versions, localization and heaps of everything else. If I'm not mistaken, gzip is also used as a component there.
This is just a general principle of disassembly, which is known to me. I am a translator after all ...
And for a snack, the story about Tomb Raider .
This was our next game.
There was little text in it, the most difficult thing was to translate the video by ear, because the emphasis was present, especially in the passage, when the Gods of Atlantis judged Nuttle.
The idea of ​​the emblem on the passport was born by itself :) I just came home with a passport, put it next to the table and began to redraw pictures for the game, because There were few of them, I myself redrawn, the artist was not hired. And when I came across a picture of the passport, I could not resist.
The sound was made by hired guys, they were voiced too.
With an expression they were weak. The phrase "Kill her" in one of the passages sounded somehow mundane, as if Nuttle says "Bring me a beer ...".
But, nevertheless, the guys tried. There is a moment when, during training, Lara emerges from the water and says, “Oooh ... Ohhh ... Fresh air!” In the English version, this sounds like a simple joy with a little shortness of breath: “Oh! Fresh Air! Let's .... ” But in the Russian version, the poor girl’s mouth was squeezed so that she didn’t breathe at about the same time that the game was relegated to “swim once”, brought the text and microphone, and then let go. Selflessly, right?
Testing was carried out completely, because by the time when the utilities for the assembly were ready, I had already translated and passed the last level for two days.
This is the only game for which the parsing tools, for a reason already forgotten, were written in Assembler.
Below, for example, a piece of code that gets sound data in a draft format from the first Tomb Raider's RPL files.
The first piece is just reading / writing files, nothing interesting, just using the native 21e interrupt.
I will give only a piece of code that actually decodes:
Thanks for attention.
To be continued…
Copper pipes
So, the first game is transferred, the money received as well as the satisfaction of the work done.
What changes after that?
After that, you start looking at the games in a completely different way. As an architect, who can no longer fully enjoy the beauty of the house, as a designer, who sees the advertising poster not like everything ... and the poor localizer, already looks at the game quite differently, mentally sorting it out into pieces.
Personally, I still have a habit. Having installed a fresh game that I want to watch, I don’t launch it. Not. I go to the directory where it is recorded and see how the data is organized, what the video is recorded in, what the sound is, where the textures are, where the texts are ... This happens so mechanically that you don’t think about it.
')
And only after all this, you start ...
The following observation is associated with visiting places where they sell discs. Here the copper pipes for the first time make you know:
- Did you play “Hostile Whirlwinds”? (Warwind)
- Not…
- On, play ... in Russian ... class!
And inside wakes up pride for the deed, a happy smile creeps on the face itself ...
Then the seller tries to sell you your transfer ...
This seriously affects your motivation and work on future games. And both in a positive and in a negative direction.
How we worked ...
However, let's continue and consider the stages of disassembling the game.
For the programmer:
- Install, climb into the directory to see what is where
- Start the game, set up, remember some text, preferably not “New Game”, but from the gameplay itself, ideally a piece of some briefing, or dialogue in text form
- Play a little to understand approximately: is there any text on the textures, what sound, how much is it
- Exit the game and search for text, in different DOS / WIN / UNICODE encodings, etc.
- Cut the text to give translators with comments
- Search for sound and cut it
- Calculate the duration in minutes, tell the manager, let him think “is it worth it?”
- Having received a positive response, to decrypt the sound as necessary
- Give sounds to translators
- Engage in decoding fonts in pictures
- Cut fonts into pictures and give to the artist
- Draw a couple of letters in the texture itself with the font, and a couple of Russian letters in the text
- Try to paste the texture with the font back
- if you had to decode the sound, write the encoder :)
- Try to insert your sound into the game.
- Get the first texts from translators
- Get texture from artist
- Collect the first version, show the manager
- If inaccuracies are noticed, write down in a piece of paper (this is important! Write down a piece of paper into a piece of paper! Otherwise it will be skipped)
- Collect fonts from ready-made textures
- Get all sound and text, collect
- Show first version to people
- Collect and show until you get bored, until comments and corrections run out or until it is decided, well enough, send ...
...
Approximately such a work plan. Slightly messy, of course, and not always everything happens that way, but mostly similar.
So, we have four main areas of work:
- Disassembly - assembly
- Text translation; Video translation and script writing for actors
- Drawing
- Sound engineering and sound cutting
Sound
Here mikeSP perfectly wrote about the sound.
I'd add from myself that everything was much simpler.
Storeroom / Toilet, many trays from under the eggs, copper wire with a stretched stocking (spittoon, ts :)) In order for the microphone not to record the sound of particles of saliva falling on it when you speak. And finally a microphone for crazy money. The sound was recorded in the presence of only a working actor and operator. All the others went “to the garden”, i.e. work at home.
Today I will try to tell you about the basic principles of disassembling the game into its component parts.
Break not build
Disassembly primarily requires a very good knowledge of various formats and file types. Graphics, objects, sound, text, encodings, basic encryption methods. What I am trying to figure out is whether the file is or not - you need to know how it looks, mostly in machine codes.
If the developer was lazy / low paid - he just sketched the files in directories. These cases are the most relaxing, here you do not need anything, just take it and copy it. But it happens differently.
If the data directory contains only files like: “textures.dat”, “sound.dat”, “music.dat”, “video.dat”, etc.
There will have to make a utility that will be able to disassemble / assemble such files. Such utilities are most often written for a specific game, because even the same person never writes the same programs.
Most often, data is organized according to the principle
- heading
- table placement
- data blocks
For example, take some hypothetical file “sound.dat” and open it with a simple (hehe) and handy hiew32.exe program. The name itself suggests that there should be a sound. The first thing you can look for in it is the abbreviation RIFF, i.e. standard media header, and if found, then you can safely cut the file from the header to the header - lucky. You can quickly cut the cutting program and listen to what and where, and if there is any sound, give it to the translator, let him sort and translate while you look for the table - the title to this / in this file to insert it later. Without a title, almost never files are found. I mean data files that are merged.
What I'm getting at is that if you are sure that you have found the beginning of some file inside a large file, which is called respectively: “dat”, “dta”, etc. - you can safely search in this file for a link to the initial offset of this piece, and with very high probability - this will be the table.
So, our actions:
- We are looking for familiar headers / identifiers of the beginning of files inside a large data file
- remember the initial offset
- read the file size by calculating "offset2" - "offset1"
- look for the found numbers in this file
- Analyze the found table structure. We try to align values ​​by 4 bytes, by 8m.
- We write a program that will parse the file on the basis of the table.
Do not forget that everything is written in the reverse order, i.e. the number 0x8FBD55 will be recorded in the file as 0x55BD8F. Those. from low byte to high (clever and frightening not familiar to him man the word little-endian :).
Disassembling on the basis of the table, and not just like that, you need first to collect everything back later.
The game should use the data we created and not suspect that they were changed, right?
A self-respecting developer, is trying with all his might to complicate the process of data parsing.
Sometimes the table is encrypted and hidden by all known methods. But after all, SoftICE and other excellent programs were invented for this. Working with these applications is another story. :)
It is necessary to add that lately a person who wants to organize data in his game and really does not need to write anything himself. Written a bunch of libraries that just take it and use it, notifying the author, or no need for notification at all (gzip for example)
Files created in this way can be easily understood with the help of utilities from the author of the method itself or with the utility already written by the wizards, which breaks the file into pieces.
For example MPQ format from Blizzard. Great job on writing your own file system with support for versions, localization and heaps of everything else. If I'm not mistaken, gzip is also used as a component there.
This is just a general principle of disassembly, which is known to me. I am a translator after all ...
And for a snack, the story about Tomb Raider .
This was our next game.
There was little text in it, the most difficult thing was to translate the video by ear, because the emphasis was present, especially in the passage, when the Gods of Atlantis judged Nuttle.
The idea of ​​the emblem on the passport was born by itself :) I just came home with a passport, put it next to the table and began to redraw pictures for the game, because There were few of them, I myself redrawn, the artist was not hired. And when I came across a picture of the passport, I could not resist.
The sound was made by hired guys, they were voiced too.
With an expression they were weak. The phrase "Kill her" in one of the passages sounded somehow mundane, as if Nuttle says "Bring me a beer ...".
But, nevertheless, the guys tried. There is a moment when, during training, Lara emerges from the water and says, “Oooh ... Ohhh ... Fresh air!” In the English version, this sounds like a simple joy with a little shortness of breath: “Oh! Fresh Air! Let's .... ” But in the Russian version, the poor girl’s mouth was squeezed so that she didn’t breathe at about the same time that the game was relegated to “swim once”, brought the text and microphone, and then let go. Selflessly, right?
Testing was carried out completely, because by the time when the utilities for the assembly were ready, I had already translated and passed the last level for two days.
This is the only game for which the parsing tools, for a reason already forgotten, were written in Assembler.
Below, for example, a piece of code that gets sound data in a draft format from the first Tomb Raider's RPL files.
The first piece is just reading / writing files, nothing interesting, just using the native 21e interrupt.
I will give only a piece of code that actually decodes:
;------------------------------------------------------------
proc ctoh
mov dword ptr cs:[string],'0000' ;
mov dword ptr cs:[string+4],'0000'
mov cx,0
ctoh1: cmp byte ptr [si],30h
jc ctoh2
cmp byte ptr [si],3ah
jnc ctoh2
inc si
inc cx
jmp ctoh1
ctoh2:
mov di,offset cs:string+7
push si
dec si
std
rep movsb
pop si
inc si
mov bx,offset cs:string+7
mov edx,1
mov cx,8
mov dword ptr cs:[len],0
ctoh_loop1:
mov eax,0
mov al,byte ptr cs:[bx]
sub al,30h
imul eax,edx
add dword ptr cs:[len],eax
imul edx,10
dec bx
loop ctoh_loop1
ret
ctoh endp
Thanks for attention.
To be continued…
Source: https://habr.com/ru/post/63362/
All Articles