Làm thế nào để chuẩn bị một trò chơi để bản địa hóa?

Nhiều dự án không nghĩ về nội địa hóa cho đến khi trò chơi được thực hiện. Sau đó, nội địa hóa được thực hiện dưới dạng hack và rõ ràng là nó đã được thêm vào sau đó. Một số lĩnh vực cụ thể quan tâm:

• Chuỗi văn bản (rõ ràng)
• Các clip âm thanh như âm nhạc và / hoặc tường thuật
• Văn bản được hiển thị trên kết cấu (ví dụ: nhãn trên thùng)
• Văn bản được hiển thị trong khung trong phim được kết xuất sẵn
• Bộ phông chữ / ký tự cho các ngôn ngữ khác nhau
• Vân vân.

Một số cách tốt để chuẩn bị cho những thách thức này trong giai đoạn phát triển ban đầu là gì, để bạn có thể làm cho nó dễ dàng hơn mà không phải chịu quá nhiều chi phí phía trước?

Tôi không phải là chuyên gia, nhưng đây là một số nội dung cơ bản:

Hãy chắc chắn rằng chuỗi của bạn có thể xử lý nhiều hơn chỉ ASCII

Bạn sẽ cần một số ký tự trang trí không phù hợp với ASCII và lớp chuỗi của bạn tốt hơn không nên dùng chúng. UTF-8 là một mã hóa phổ biến vì nó hiệu quả về không gian. Dù bạn làm gì, hãy kiểm tra sớm và giải quyết những khúc mắc.

Đó là một ý tưởng thực sự tốt để sử dụng một lớp chuỗi thực tế và không chỉ char *ở mọi nơi hoặc bạn sẽ ở trong một thế giới đau khổ.

Đừng quên phông chữ của bạn. Đảm bảo rằng tất cả các phông chữ bạn đang sử dụng có các ký tự bạn cần.

Kéo chuỗi của bạn ra khỏi mã

Đây là một trong những quan trọng nhất. Đảm bảo rằng các chuỗi văn bản của bạn được lưu trữ bên ngoài mã trong một số tệp dữ liệu mà bạn có thể trao đổi. Có được một đường ống được thiết lập cho việc này có thể là một việc vặt trước, nhưng sẽ giúp bạn tiết kiệm rất nhiều thời gian sau đó. Bạn sẽ muốn một số API đơn giản để bất cứ khi nào bạn cần một chuỗi mã, nó đơn giản như:

String text = Locale::getString("some unique identifier");

Không nối hoặc xây dựng chuỗi trong mã

Điều quan trọng là không đưa ra bất kỳ giả định nào về cách một đoạn văn bản được tạo ra từ những từ nhỏ hơn. Ngay cả một cái gì đó vô hại như:

String currency = Locale::getCurrencyString() + money.toString();
// creates $123

là một vấn đề vì các ngôn ngữ khác có thể đặt dấu tiền tệ sau số. Thay vào đó, hãy sử dụng các chuỗi định dạng được bản địa hóa như:

String format = Locale::get("currency format"); // returns "${0}" in English
String currency = String::Format(format, money.toString());

Bằng cách đó, người bản địa hóa có thể sắp xếp lại các từ trong chuỗi định dạng.

Giảm thiểu số lượng văn bản xuất hiện trong nghệ thuật, đặc biệt là video

Ngã ba tài sản nghệ thuật là một việc vặt. Bạn có thể sẽ cần phải làm điều đó ít nhất một chút cho một số yếu tố UI, nhưng thật rắc rối. Ngã ba FMV là một nỗi đau rất lớn bởi vì bây giờ bạn phải kết xuất và lưu trữ các bản sao FMV trùng lặp.

Kiểm tra ngôn ngữ khác nhau kỹ lưỡng

Trong hầu hết các cơ sở mã, thật dễ dàng để nói printf("Hi there");hoặc loadTexture("someTexture");quên rằng những người đó cần thông qua API bản địa hóa của bạn. Ai đó sẽ quên và bạn sẽ kết thúc với một cái gì đó đúng trong ngôn ngữ chính của bạn nhưng sai ở người khác. Cách duy nhất để tìm những thứ này là kiểm tra người kiểm tra của bạn bằng các ngôn ngữ không chính.

Làm thiếu văn bản địa phương rõ ràng

Bạn thường dịch văn bản của mình vào cuối chu kỳ, vì vậy trong phần lớn thời gian, sẽ không có dữ liệu cho một số ngôn ngữ. Điều đó tốt bởi vì nó cho phép bạn lặp lại nội dung của bạn mà không phải liên tục truyền lại. Nhược điểm là nó dễ khiến bạn bỏ lỡ mọi thứ và quên dịch một số thứ.

Một điều rẻ tiền bạn có thể làm là làm cho văn bản bị thiếu hiển thị rất rõ ràng như "!!! DỊCH DỊCH CẦN THIẾT CHO ID #blah blah !!!" trong trò chơi khi nó mất tích.

Thiết kế giao diện người dùng của bạn xung quanh ngôn ngữ trường hợp xấu nhất

Các ngôn ngữ khác nhau có xu hướng có các từ dài hơn hoặc ngắn hơn. Một giao diện người dùng trông đẹp bằng tiếng Anh có thể có văn bản chạy qua ranh giới của nó, bị cắt hoặc kết thúc không chính xác trong một ngôn ngữ dài hơn. Bạn sẽ phải thực hiện các thay đổi UI để phù hợp với ngôn ngữ trong trường hợp xấu nhất (hoặc rẽ nhánh UI của bạn, nhưng đó có thể không phải là điều bạn muốn làm.)

Khó chịu, tiếng Anh thường là ngôn ngữ ngắn nhất trong số những ngôn ngữ thường được bản địa hóa, vì vậy các nhà thiết kế của bạn có thể đang vô tình thiết kế cho trường hợp tốt nhất. Làm cho họ sử dụng văn bản dài thêm cho trình giữ chỗ của họ khi họ thiết kế. Giả sử bất kỳ đoạn văn bản đã cho nào có thể dài hơn khoảng 30% so với tiếng Anh. Google Dịch có thể tốt để có được một đoạn văn bản gần đúng cho trình giữ chỗ.

Ngân sách thời gian dịch

Dịch văn bản thường xảy ra muộn khi nhóm mệt mỏi và không thực sự quan tâm. Tuy nhiên, bạn sẽ gặp rất nhiều lỗi khi nó xảy ra. Các từ sẽ chạy qua ranh giới, dịch giả sẽ mắc lỗi, v.v. Để làm cho vấn đề tồi tệ hơn, thời gian quay vòng để lặp lại văn bản có thể kéo dài nếu bạn phải gửi văn bản cho mọi người ở nước ngoài và chờ đợi những thay đổi của họ. Phân bổ thời gian cho công việc này.

Ngoài các đề xuất khác, một điều tôi đã làm trong quá khứ giúp tìm kiếm văn bản dịch bị chảy ra khỏi các thành phần UI là có một chế độ ngôn ngữ đặc biệt cho trò chơi của bạn, khi hiển thị bất kỳ chuỗi nào, sẽ xem xét tất cả các ngôn ngữ và chọn phiên bản dài nhất của chuỗi đó. Bằng cách đó, một khi bạn đã làm cho tất cả các chuỗi phù hợp trong chế độ đó, bạn sẽ biết rằng bạn đã sửa tất cả các văn bản bị chảy trong mọi ngôn ngữ.

Bản địa hóa một trò chơi chính xác là rất khó .

Bạn có thể duyệt internet, đọc các bài đăng trên blog hoặc câu trả lời StackOverflow; bạn có thể tìm hiểu các khung i18n truyền thống như gettext ; đọc các trang Wikipedia về quốc tế hóa và bản địa hóa trò chơi ; tham khảo hướng dẫn ngôn ngữ tuyệt vời của Microsoft - nhưng việc bản địa hóa các trò chơi thực sự khó hơn thế. Trên thực tế, với các trò chơi, có lẽ khó hơn bất kỳ ứng dụng hoặc giao diện web nào khác. Điều này là do các trò chơi rất năng động hơn, sống động hơn, sống động hơn (tốt, ít nhất là các trò chơi hay).

Hơn nữa, các bước sau đây có thể sẽ cần phải được thực hiện:

Thiết lập ranh giới.

Bạn muốn đưa ra quyết định cực kỳ quan trọng đối với ngôn ngữ nào bạn muốn hỗ trợ sớm. Sự lựa chọn của bạn càng rộng, càng có nhiều giả định về cách ngôn ngữ có thể hành xử sẽ bị phá vỡ. Thông thường những giả định này được in sâu trong não của chúng ta, đến mức chúng ta thậm chí không thể tưởng tượng rằng chúng có thể không chính xác mà không có ai chỉ ra. Điều này đưa chúng ta đến điểm tiếp theo:

Tìm các chuyên gia cho từng ngôn ngữ bạn muốn hỗ trợ.

Chuyên gia có nghĩa là một người có đủ kỹ năng phân tích và kiến ​​thức về ngôn ngữ, rằng anh ta sẽ có thể chỉ cho bạn những giả định mà một người nói tiếng Anh không nắm giữ bằng ngôn ngữ của mình. Sau đó, bạn sẽ cần đưa ra một chiến lược làm thế nào để giải quyết những giả định đó.

Ví dụ: trong các ngôn ngữ phương Tây, chúng tôi biện minh cho văn bản trong một đoạn văn bằng cách chèn thêm khoảng trắng giữa các từ. Trong ngôn ngữ Ả Rập, văn bản được chứng minh bằng cách chèn các ký tự kashida bên trong các từ. Nó có thể trông như thế này .

Một ví dụ khác: trong tiếng Nga, có 2 dạng số nhiều cho phần lớn các từ. Vì vậy, ví dụ, bạn sẽ dịch "1 đồng xu" / "3 đồng xu" / "5 đồng xu" là "1 chữ", "3 chữ", nhưng "5 chữ". Các thủ tục thực tế để quyết định hình thức số nhiều chính xác trông như thế này:

function LocalRU::GetPlural(n, form0, form1, form2) {
    return (n%10) == 0 || (n%100) >= 5 && (n%100) <= 20? form0 : 
           (n%10) == 1? form1 : 
           (n%10) <= 4? form2 : form0;
}

Tạo một mô-đun dịch nhận biết ngữ cảnh.

Bạn có thể biết rằng dịch thuật luôn phụ thuộc vào ngữ cảnh. Và bạn biết rằng bối cảnh trong một trò chơi luôn thay đổi. Điều gì xảy ra nếu chúng ta đặt hai tuyên bố này cùng nhau? Nói chung, bản dịch của bạn nên năng động như trò chơi của bạn.

Ví dụ, một cụm từ đơn giản "Tôi đồng ý" dịch sang tiếng Nga là một trong những "Я о Я о о о о о о о о о о о о о о о Nếu đây là một trong những dòng hộp thoại của bạn, thì mô-đun ngôn ngữ sẽ phải chọn một trong những bản dịch có thể có trong thời gian chạy tùy thuộc vào giới tính của nhân vật của bạn (giả sử bạn cung cấp cho người chơi của mình một lựa chọn như vậy).

Cùng một cụm từ khi dịch sang tiếng Nhật sẽ lại có các bản dịch khác nhau, tùy thuộc vào mức độ chính thức của mối quan hệ giữa người nói và người nghe. Do đó, nếu bạn giới thiệu trong trò chơi của mình ý tưởng về danh tiếng, hoặc tình bạn, hoặc mức độ ưu việt khác nhau (giả sử, nhân vật của bạn có thể phát triển từ Rookie thành General), thì bạn sẽ phải tính đến điều này khi hình thành bản dịch. (Trên thực tế, đây không phải là tiếng Nhật cụ thể. Ngay cả bằng tiếng Anh, trong quân đội, bạn không bao giờ nói "Thưa ông, vâng, thưa ngài!"

Có một cách để nhảy vào bối cảnh.

Người dịch của bạn nên có khả năng xem ngữ cảnh nơi một cụm từ cụ thể xuất hiện. Đôi khi bối cảnh là rõ ràng, đôi khi bạn phải tự nhìn / nghe / trải nghiệm nó để dịch một cái gì đó chính xác.

Ngay cả câu đơn giản như "Cuốn sách này là màu xanh." không thể được dịch rõ ràng mà không cần tôi nhìn vào cuốn sách và xem nó có sắc thái đặc biệt nào của màu xanh.

Tránh chơi chữ, chơi chữ và các yếu tố ngôn ngữ cụ thể khác.

Hoặc có thể không tránh, nhưng ít nhất phải có một chiến lược trong đầu để làm gì khi trò chơi chữ không thể dịch được. Bởi vì có lẽ nó sẽ không.

Ít nhất bạn không nên tạo ra bất kỳ nhiệm vụ / câu đố / đối tượng trò chơi nào dựa trên một số từ nhất định có nghĩa kép hoặc tương tự như một số từ khác. Bởi vì một khi dịch bạn sẽ phá vỡ trò chơi của riêng bạn. (Ví dụ, trong một trò chơi cũ Fallout2, nhiệm vụ chính là tìm ra vật thể có tên là GECK; cũng có rất nhiều quái vật "tắc kè" (thằn lằn đột biến) xung quanh trò chơi; tự nhiên chúng tạo ra nhiều tài liệu tham khảo và nhiệm vụ xung quanh sự giống nhau này của tên, mà thực hiện tốt bản dịch cực kỳ khó khăn).

Vui lên!

Bản địa hóa một trò chơi là khó. Nhưng nó khó cho tất cả mọi người. Nếu bạn nỗ lực và thực hiện nó một cách chính xác, nó sẽ không được chú ý bởi các nhà phê bình trò chơi ở quốc gia mục tiêu của bạn. Một trò chơi với bản dịch tốt sẽ nổi bật và kiếm được lợi nhuận cao hơn. Xét cho cùng, văn bản cũng quan trọng để tạo ra bầu không khí trong trò chơi, như đồ họa (đây là lý do tại sao các game nhập vai dựa trên văn bản cũ rất đắm đuối).

Wil Shipley cho đến nay là hướng dẫn tốt nhất về nội địa hóa mà tôi từng đọc. Thật không may, đó là iPhone cụ thể, nhưng người ta vẫn có thể lấy được thông tin hữu ích chung. Hơn nữa, ông giải quyết việc bản địa hóa tài sản và giao diện người dùng - hai trong số những thách thức lớn hơn trong việc bản địa hóa trò chơi mà tôi có thể tưởng tượng.

Luôn luôn, LUÔN LUÔN coi ngôn ngữ nguồn là ngôn ngữ địa phương.

Vì vậy, nếu ngôn ngữ nguồn của bạn là EN thì hãy giữ tất cả các tài sản và chuỗi EN trong một thư mục EN riêng và kéo từ đó.

Kéo tài sản EN thông qua đường ống nội địa hóa dự định của bạn.

Bằng cách thực hiện điều này một cách đơn giản, bạn sẽ nắm bắt được 80% các vấn đề nội địa hóa và được đặt cho quy trình bản địa hóa dễ dàng hơn nhiều .

Tôi đã bản địa hóa nhiều trò chơi và luôn dẫn đầu với nugget này.

Tôi thấy một số lời khuyên thực sự tuyệt vời ở đây!

Tôi sẽ cố gắng đưa ra một danh sách các lỗi phổ biến nhất có thể từ việc khiến việc bản địa hóa của bạn trở nên khó khăn hơn đến làm hỏng hoàn toàn trò chơi của bạn:

• Suy nghĩ về nội địa hóa là bước cuối cùng của phát triển trò chơi
• Không tách chuỗi văn bản của bạn khỏi mã nguồn
• Nối / ngắt dòng ở giữa câu.
• Giả sử thời gian, ngày tháng và đơn vị không cần nội địa hóa
• Không cung cấp đủ tài liệu tham khảo cho người dịch / Không trả lời câu hỏi của họ
• Giả sử tất cả văn bản từ trò chơi của bạn sẽ ở ASCII
• Có văn bản trong hình ảnh
• Có hộp văn bản / UI cứng nhắc
• Giả sử tất cả các ngôn ngữ có cùng độ dài với tiếng Anh
• Sử dụng Google Dịch / dịch máy
• Bỏ qua yếu tố văn hóa
• Không phân bổ đủ ngân sách cho nội địa hóa

Bản địa hóa nên được tích hợp để phát triển càng sớm càng tốt và bạn nên luôn luôn ghi nhớ nó khi thiết kế một trò chơi.

Với kế hoạch đúng đắn và nghiên cứu thị trường cẩn thận, bạn sẽ tiết kiệm cho mình rất nhiều rắc rối và chi phí tiếp theo.

Tôi tình cờ là người sáng lập một công ty bản địa hóa trò chơi và chúng tôi đã đề cập đến việc chuẩn bị một trò chơi để bản địa hóa một vài tháng trước trong blog của chúng tôi.

Đây là infographic tổng hợp bài đăng đó: https://magic.piktochart.com/output/18317297-9-steps-to-cheaper-game-development-with-localization

Liên kết đến bài viết đầy đủ bao gồm những lời khuyên đó chi tiết hơn là ở dưới cùng của nó.