Kỷ niệm 10 năm robot chiến tranh và suy ngẫm từ góc độ kỹ thuật

War Robots kỷ niệm 10 năm thành lập vào tháng 4 này! Và cho đến ngày nay, chúng tôi tiếp tục phát triển và hỗ trợ nó, không chỉ phát hành các tính năng mới cho người chơi mà còn cải thiện nó về mặt kỹ thuật.

Trong bài viết này, chúng tôi sẽ thảo luận về kinh nghiệm nhiều năm của chúng tôi trong việc phát triển kỹ thuật cho dự án lớn này. Nhưng trước tiên, đây là ảnh chụp nhanh về dự án:

• Hàng trăm ngàn DAU (Người dùng hoạt động hàng ngày)
• Hàng trăm triệu lượt cài đặt
• Hàng chục nghìn trận đấu 12 người cùng lúc
• Có sẵn trên bốn nền tảng chính (iOS, Android, Steam, Amazon)
• Hàng chục nghìn thiết bị được hỗ trợ, bao gồm cả Android và PC
• Hàng trăm máy chủ
• Khoảng 20 nhà phát triển ứng dụng khách, 9 nhà phát triển máy chủ, nhóm phát triển nhiều dự án gồm 8 người và 3 DevOps
• Khoảng 1,5 triệu dòng mã phía máy khách
• Sử dụng Unity bắt đầu từ phiên bản 4 năm 2014 và hiện đang sử dụng phiên bản 2022 LTS vào năm 2024.

Để duy trì chức năng của loại dự án này và đảm bảo sự phát triển chất lượng cao hơn nữa, chỉ làm việc với các nhiệm vụ sản phẩm trước mắt là không đủ; đó cũng là chìa khóa để cải thiện tình trạng kỹ thuật, đơn giản hóa quá trình phát triển và tự động hóa các quy trình – bao gồm cả những quy trình liên quan đến việc tạo nội dung mới. Hơn nữa, chúng ta phải liên tục thích ứng với sự thay đổi của thị trường các thiết bị người dùng hiện có.

Văn bản này dựa trên các cuộc phỏng vấn với Pavel Zinov, Trưởng phòng Phát triển tại Pixonic (MY.GAMES) và Dmitry Chettorikov, Nhà phát triển chính của War Robots.

Sự bắt đầu

Hãy quay trở lại năm 2014: dự án War Robots ban đầu được tạo ra bởi một nhóm nhỏ và tất cả các giải pháp kỹ thuật đều phù hợp với mô hình phát triển nhanh chóng và cung cấp các tính năng mới cho thị trường. Vào thời điểm này, công ty không có nguồn lực lớn để lưu trữ các máy chủ chuyên dụng và do đó, War Robots đã gia nhập thị trường với tính năng nhiều người chơi trên mạng dựa trên logic P2P.

Photon Cloud được sử dụng để truyền dữ liệu giữa các máy khách: mỗi lệnh của người chơi, dù là di chuyển, bắn súng hay bất kỳ lệnh nào khác, đều được gửi đến máy chủ Photon Cloud bằng các RPC riêng biệt. Vì không có máy chủ chuyên dụng nên trò chơi có một ứng dụng khách chính, chịu trách nhiệm về độ tin cậy của trạng thái trận đấu cho tất cả người chơi. Đồng thời, những người chơi còn lại đã xử lý đầy đủ trạng thái của toàn bộ trò chơi trên máy khách cục bộ của họ.

Ví dụ: không có xác minh về chuyển động - khách hàng cục bộ đã di chuyển robot của mình khi thấy phù hợp, trạng thái này được gửi đến khách hàng chính và khách hàng chính tin tưởng trạng thái này một cách vô điều kiện và chỉ chuyển tiếp nó đến các khách hàng khác trong trận đấu. Mỗi khách hàng độc lập giữ nhật ký trận chiến và gửi đến máy chủ khi trận đấu kết thúc, sau đó máy chủ xử lý nhật ký của tất cả người chơi, trao phần thưởng và gửi kết quả trận đấu cho tất cả người chơi.

Chúng tôi đã sử dụng Máy chủ Hồ sơ đặc biệt để lưu trữ thông tin về hồ sơ người chơi. Điều này bao gồm nhiều máy chủ có cơ sở dữ liệu Cassandra. Mỗi máy chủ là một máy chủ ứng dụng đơn giản trên Tomcat và các máy khách tương tác với nó thông qua HTTP.

Hạn chế của cách tiếp cận ban đầu của chúng tôi

Cách tiếp cận được sử dụng trong trò chơi có một số nhược điểm. Tất nhiên, nhóm đã biết về những điều này, nhưng do tốc độ phát triển và cung cấp sản phẩm cuối cùng ra thị trường nên một số thỏa hiệp đã phải được thực hiện.

Trong số những nhược điểm này, trước hết là chất lượng kết nối máy khách chính. Nếu máy khách có mạng kém thì tất cả người chơi trong trận đấu đều gặp phải hiện tượng lag. Và, nếu ứng dụng khách chính không chạy trên điện thoại thông minh quá mạnh, thì do tải trọng lớn đặt lên nó, trò chơi cũng gặp phải tình trạng chậm trễ trong việc truyền dữ liệu. Vì vậy, trong trường hợp này, ngoài khách hàng chính, những người chơi khác cũng bị ảnh hưởng.

Hạn chế thứ hai là kiến trúc này dễ gặp vấn đề với kẻ gian lận. Vì trạng thái cuối cùng được chuyển từ máy khách chính nên máy khách này có thể tùy ý thay đổi nhiều tham số trận đấu, chẳng hạn như đếm số vùng đã bắt trong trận đấu.

Thứ ba, có vấn đề với chức năng mai mối trên Photon Cloud: người chơi lớn tuổi nhất trong phòng Mai mối Cloud Photon sẽ trở thành khách hàng chính và nếu có điều gì đó xảy ra với họ trong quá trình mai mối (ví dụ: mất kết nối), thì việc tạo nhóm sẽ bị ảnh hưởng tiêu cực. Sự thật thú vị liên quan: để ngăn quá trình mai mối trong Photon Cloud đóng lại sau khi cử một nhóm đến trận đấu, đôi khi, chúng tôi thậm chí còn thiết lập một chiếc PC đơn giản trong văn phòng của mình và điều này luôn hỗ trợ việc mai mối, nghĩa là việc mai mối với Photon Cloud không thể thất bại .

Tại một thời điểm nào đó, số lượng sự cố và yêu cầu hỗ trợ đã đạt đến mức nghiêm trọng và chúng tôi bắt đầu suy nghĩ nghiêm túc về việc phát triển kiến trúc kỹ thuật của trò chơi – kiến trúc mới này được gọi là Cơ sở hạ tầng 2.0.

Quá trình chuyển đổi sang Cơ sở hạ tầng 2.0

Ý tưởng chính đằng sau kiến trúc này là tạo ra các máy chủ trò chơi chuyên dụng. Vào thời điểm đó, nhóm của khách hàng thiếu lập trình viên có nhiều kinh nghiệm phát triển máy chủ. Tuy nhiên, công ty đang đồng thời thực hiện một dự án phân tích có tải trọng cao, dựa trên máy chủ mà chúng tôi gọi là AppMetr. Nhóm đã tạo ra một sản phẩm xử lý hàng tỷ tin nhắn mỗi ngày và họ có chuyên môn sâu rộng trong việc phát triển, cấu hình và kiến trúc chính xác của các giải pháp máy chủ. Và vì vậy, một số thành viên của nhóm đó đã tham gia vào công việc về Cơ sở hạ tầng 2.0.

Vào năm 2015, trong một khoảng thời gian khá ngắn, một máy chủ .NET đã được tạo ra, được bao bọc trong khung Photon Server SDK chạy trên Windows Server. Chúng tôi đã quyết định từ bỏ Photon Cloud, chỉ giữ lại khung mạng SDK Photon Server trong dự án máy khách và tạo Máy chủ chính để kết nối máy khách và máy chủ tương ứng để mai mối. Một số logic đã được chuyển từ máy khách sang máy chủ trò chơi chuyên dụng. Đặc biệt, tính năng xác thực thiệt hại cơ bản cũng như đưa tính toán kết quả trận đấu lên máy chủ đã được giới thiệu.

Sự xuất hiện của microservice

Sau khi tạo thành công Cơ sở hạ tầng 2.0, chúng tôi nhận ra rằng mình cần tiếp tục hướng tới việc tách rời trách nhiệm của các dịch vụ: kết quả của việc này là tạo ra kiến trúc vi dịch vụ. Microservice đầu tiên được tạo trên kiến trúc này là clans.

Từ đó, một dịch vụ Truyền thông riêng biệt xuất hiện và dịch vụ này chịu trách nhiệm truyền dữ liệu giữa các microservice. Khách hàng được hướng dẫn cách thiết lập kết nối với “nhà chứa máy bay” chịu trách nhiệm về cơ chế meta trên máy chủ trò chơi và thực hiện các yêu cầu API (một điểm truy cập duy nhất để tương tác với các dịch vụ) bằng cách sử dụng UDP qua Photon Cloud. Dần dần, số lượng dịch vụ tăng lên và kết quả là chúng tôi đã tái cấu trúc vi dịch vụ mai mối. Với điều này, chức năng tin tức, Hộp thư đến, đã được tạo.

Khi chúng tôi tạo bang hội, rõ ràng là người chơi muốn giao tiếp với nhau trong trò chơi – họ cần một số hình thức trò chuyện. Điều này ban đầu được tạo dựa trên Photon Chat, nhưng toàn bộ lịch sử trò chuyện đã bị xóa ngay khi khách hàng cuối cùng ngắt kết nối. Do đó, chúng tôi đã chuyển đổi giải pháp này thành một microservice riêng biệt dựa trên cơ sở dữ liệu Cassandra.

Cơ sở hạ tầng 4.0 và vị trí máy chủ

Kiến trúc vi dịch vụ mới cho phép chúng tôi quản lý thuận tiện một số lượng lớn các dịch vụ độc lập với nhau, điều này có nghĩa là mở rộng quy mô toàn bộ hệ thống theo chiều ngang và tránh thời gian ngừng hoạt động.

Trong trò chơi của chúng tôi, các bản cập nhật diễn ra mà không cần phải tạm dừng máy chủ. Cấu hình máy chủ tương thích với một số phiên bản máy khách và đối với máy chủ trò chơi, chúng tôi luôn có một nhóm máy chủ cho phiên bản cũ và mới của máy khách, nhóm này dần dần thay đổi sau khi phát hành phiên bản mới trong các cửa hàng ứng dụng và máy chủ trò chơi biến mất theo thời gian khỏi phiên bản cũ. Phác thảo chung về cơ sở hạ tầng hiện tại được gọi là Cơ sở hạ tầng 4.0 và trông như thế này:

Ngoài việc thay đổi kiến trúc, chúng tôi còn phải đối mặt với một vấn đề nan giải về việc đặt máy chủ của mình ở đâu vì chúng được cho là sẽ phục vụ người chơi từ khắp nơi trên thế giới. Ban đầu, nhiều dịch vụ vi mô được đặt trong Amazon AWS vì một số lý do, đặc biệt là do tính linh hoạt mà hệ thống này mang lại về mặt mở rộng quy mô, vì điều này rất quan trọng trong những thời điểm lưu lượng truy cập trò chơi tăng đột biến (chẳng hạn như khi nó được giới thiệu trong các cửa hàng và để tăng cường UA). Ngoài ra, vào thời điểm đó, rất khó tìm được nhà cung cấp dịch vụ lưu trữ tốt ở châu Á có chất lượng mạng tốt và kết nối với thế giới bên ngoài.

Nhược điểm duy nhất của Amazon AWS là chi phí cao. Do đó, theo thời gian, nhiều máy chủ của chúng tôi đã chuyển sang phần cứng của riêng chúng tôi – những máy chủ mà chúng tôi thuê ở các trung tâm dữ liệu trên khắp thế giới. Tuy nhiên, Amazon AWS vẫn là một phần quan trọng của kiến trúc vì nó cho phép phát triển mã liên tục thay đổi (đặc biệt là mã cho các dịch vụ Giải đấu, Bang hội, Trò chuyện và Tin tức) và không được đảm bảo đầy đủ về độ ổn định. các bài kiểm tra. Tuy nhiên, ngay khi nhận thấy microservice đã ổn định, chúng tôi đã chuyển nó đến cơ sở của mình. Hiện tại, tất cả các dịch vụ vi mô đều chạy trên máy chủ phần cứng của chúng tôi.

Kiểm soát chất lượng thiết bị và nhiều số liệu hơn

Vào năm 2016, những thay đổi quan trọng đã được thực hiện đối với cách kết xuất của trò chơi: khái niệm Ubershaders với một tập bản đồ kết cấu duy nhất cho tất cả các máy trong trận chiến đã xuất hiện, giúp giảm đáng kể số lượng lệnh rút thăm và cải thiện hiệu suất trò chơi.

Rõ ràng là trò chơi của chúng tôi đang được chơi trên hàng chục nghìn thiết bị khác nhau và chúng tôi muốn cung cấp cho mỗi người chơi những điều kiện chơi game tốt nhất có thể. Do đó, chúng tôi đã tạo Trình quản lý chất lượng, về cơ bản là một tệp phân tích thiết bị của người chơi và bật (hoặc tắt) một số tính năng kết xuất hoặc trò chơi nhất định. Hơn nữa, tính năng này cho phép chúng tôi quản lý các chức năng này theo kiểu thiết bị cụ thể để chúng tôi có thể nhanh chóng khắc phục các sự cố mà người chơi của chúng tôi đang gặp phải.

Cũng có thể tải xuống cài đặt Trình quản lý chất lượng từ máy chủ và tự động chọn chất lượng trên thiết bị tùy thuộc vào hiệu suất hiện tại. Logic khá đơn giản: toàn bộ nội dung của Người quản lý chất lượng được chia thành các khối, mỗi khối chịu trách nhiệm về một số khía cạnh hiệu suất. (Ví dụ: chất lượng của bóng hoặc khử răng cưa.) Nếu hiệu suất của người dùng bị ảnh hưởng, hệ thống sẽ cố gắng thay đổi các giá trị bên trong khối và chọn một tùy chọn sẽ dẫn đến tăng hiệu suất. Chúng ta sẽ quay lại quá trình phát triển của Trình quản lý chất lượng sau đó một chút, nhưng ở giai đoạn này, việc triển khai nó khá nhanh và cung cấp mức độ kiểm soát cần thiết.

Công việc trên Trình quản lý chất lượng cũng cần thiết khi quá trình phát triển đồ họa tiếp tục. Trò chơi hiện có các bóng động xếp tầng, được thực hiện hoàn toàn bởi các lập trình viên đồ họa của chúng tôi.

Dần dần, khá nhiều thực thể xuất hiện trong mã của dự án, vì vậy chúng tôi quyết định rằng sẽ tốt hơn nếu bắt đầu quản lý vòng đời của chúng, cũng như phân định quyền truy cập vào các chức năng khác nhau. Điều này đặc biệt quan trọng trong việc tách biệt nhà chứa máy bay và mã chiến đấu vì nhiều tài nguyên không bị xóa khi bối cảnh trò chơi thay đổi. Chúng tôi bắt đầu khám phá nhiều vùng chứa quản lý phụ thuộc IoC khác nhau. Đặc biệt, chúng tôi đã xem xét giải pháp StrangeIoC. Vào thời điểm đó, giải pháp này có vẻ khá phức tạp đối với chúng tôi và vì vậy chúng tôi đã triển khai DI đơn giản của riêng mình trong dự án. Chúng tôi cũng giới thiệu bối cảnh nhà chứa máy bay và chiến đấu.

Ngoài ra, chúng tôi bắt đầu thực hiện công tác kiểm soát chất lượng dự án; FirebaseCrashlytics đã được tích hợp vào trò chơi để xác định sự cố, ANR và ngoại lệ trong môi trường sản xuất.

Bằng cách sử dụng giải pháp phân tích nội bộ có tên AppMetr, chúng tôi đã tạo các bảng thông tin cần thiết để theo dõi thường xuyên trạng thái khách hàng và so sánh những thay đổi được thực hiện trong quá trình phát hành. Hơn nữa, để cải thiện chất lượng của dự án và tăng độ tin cậy vào những thay đổi được thực hiện đối với mã, chúng tôi đã bắt đầu nghiên cứu các thử nghiệm tự động.

Sự gia tăng số lượng tài sản và các lỗi đặc biệt trong nội dung khiến chúng tôi phải suy nghĩ về việc tổ chức và thống nhất các tài sản. Điều này đặc biệt đúng đối với máy móc vì cách xây dựng của chúng là duy nhất đối với mỗi máy; Để làm được điều này, chúng tôi đã tạo ra các công cụ trong Unity và với những công cụ này, chúng tôi đã tạo ra các hình nộm máy móc với các thành phần chính cần thiết. Điều này có nghĩa là bộ phận thiết kế trò chơi sau đó có thể dễ dàng chỉnh sửa chúng – và đây là cách lần đầu tiên chúng tôi bắt đầu thống nhất công việc của mình với máy móc.

Nhiều nền tảng hơn

Dự án tiếp tục phát triển và nhóm bắt đầu nghĩ đến việc phát hành nó trên các nền tảng khác. Ngoài ra, một điểm khác, đối với một số nền tảng di động vào thời điểm đó, điều quan trọng là trò chơi phải hỗ trợ càng nhiều chức năng gốc của nền tảng càng tốt, vì điều này cho phép trò chơi được nổi bật. Vì vậy, chúng tôi bắt đầu làm việc trên phiên bản thử nghiệm của War Robots cho Apple TV và ứng dụng đồng hành cho Apple Watch.

Ngoài ra, vào năm 2016, chúng tôi đã ra mắt trò chơi trên một nền tảng mới đối với chúng tôi — Amazon AppStore. Về đặc tính kỹ thuật, nền tảng này độc đáo vì nó có một dòng thiết bị thống nhất, giống như Apple, nhưng sức mạnh của dòng này chỉ ở mức Android cấp thấp. Với suy nghĩ này, khi khởi chạy trên nền tảng này, công việc quan trọng đã được thực hiện để tối ưu hóa việc sử dụng bộ nhớ và hiệu suất, chẳng hạn như chúng tôi đã làm việc với tập bản đồ, nén kết cấu. Hệ thống thanh toán Amazon, một hệ thống tương tự của Game Center để đăng nhập và thành tích, đã được tích hợp vào ứng dụng khách và do đó quy trình làm việc với thông tin đăng nhập của người chơi đã được làm lại và những thành tích đầu tiên đã được đưa ra.

Cũng cần lưu ý rằng, đồng thời, nhóm khách hàng lần đầu tiên đã phát triển một bộ công cụ cho Unity Editor và những công cụ này giúp bạn có thể quay video trong trò chơi bằng công cụ này. Điều này giúp bộ phận tiếp thị của chúng tôi làm việc với tài sản, kiểm soát chiến đấu và sử dụng máy ảnh dễ dàng hơn để tạo ra các video mà khán giả vô cùng yêu thích.

Đấu tranh chống lại những kẻ lừa đảo

Do thiếu Unity và đặc biệt là công cụ vật lý trên máy chủ, hầu hết các trận đấu tiếp tục được mô phỏng trên thiết bị của người chơi. Vì điều này, các vấn đề về gian lận vẫn tiếp diễn. Theo định kỳ, nhóm hỗ trợ của chúng tôi nhận được phản hồi từ người dùng bằng video về những kẻ gian lận: họ tăng tốc vào thời điểm thuận tiện, bay vòng quanh bản đồ, giết chết những người chơi khác từ một góc, trở thành bất tử, v.v.

Lý tưởng nhất là chúng tôi sẽ chuyển tất cả cơ chế sang máy chủ; tuy nhiên, ngoài thực tế là trò chơi đang được phát triển không ngừng và đã tích lũy được một lượng mã kế thừa khá lớn, cách tiếp cận với một máy chủ có thẩm quyền cũng có thể có những nhược điểm khác. Ví dụ: tăng tải cho cơ sở hạ tầng và nhu cầu kết nối Internet tốt hơn. Do hầu hết người dùng của chúng tôi chơi trên mạng 3G/4G, cách tiếp cận này, mặc dù rõ ràng, không phải là giải pháp hiệu quả cho vấn đề. Là một cách tiếp cận khác để chống lại những kẻ gian lận trong nhóm, chúng tôi đã nảy ra một ý tưởng mới – tạo ra “số đại biểu”.

Quorum là một cơ chế cho phép bạn so sánh nhiều mô phỏng của những người chơi khác nhau khi xác nhận thiệt hại đã gây ra; nhận sát thương là một trong những tính năng chính của trò chơi, điều mà hầu như phần còn lại của trạng thái của nó phụ thuộc vào. Ví dụ: nếu bạn tiêu diệt đối thủ của mình, họ sẽ không thể bắt được đèn hiệu.

Ý tưởng của quyết định này như sau: mỗi người chơi vẫn mô phỏng toàn bộ thế giới (bao gồm cả việc bắn những người chơi khác) và gửi kết quả đến máy chủ. Máy chủ đã phân tích kết quả từ tất cả người chơi và đưa ra quyết định xem cuối cùng người chơi có bị hư hại hay không và ở mức độ nào. Các trận đấu của chúng tôi có sự tham gia của 12 người, vì vậy để máy chủ xem xét rằng thiệt hại đã xảy ra, việc đăng ký thực tế này trong mô phỏng cục bộ của 7 người chơi là đủ. Những kết quả này sau đó sẽ được gửi đến máy chủ để xác nhận thêm. Về mặt sơ đồ, thuật toán này có thể được biểu diễn như sau:

Kế hoạch này cho phép chúng tôi giảm đáng kể số lượng kẻ gian lận khiến bản thân trở nên bất khả chiến bại trong trận chiến. Biểu đồ sau đây hiển thị số lượng khiếu nại đối với những người dùng này cũng như các giai đoạn kích hoạt tính năng tính toán thiệt hại trên máy chủ và kích hoạt số đại biểu thiệt hại:

Cơ chế gây sát thương này đã giải quyết được các vấn đề gian lận trong một thời gian dài bởi vì, mặc dù thiếu tính chất vật lý trên máy chủ (và do đó không thể tính đến những thứ như địa hình bề mặt và vị trí thực của robot trong không gian), kết quả của mô phỏng cho tất cả khách hàng và sự đồng thuận của họ đã mang lại sự hiểu biết rõ ràng về việc ai đã gây ra thiệt hại cho ai và trong những điều kiện nào.

Phát triển hơn nữa của dự án

Theo thời gian, ngoài bóng động, chúng tôi đã thêm các hiệu ứng hậu kỳ vào trò chơi bằng cách sử dụng Unity Post Treatment Stack và kết xuất hàng loạt. Bạn có thể xem ví dụ về đồ họa được cải thiện nhờ áp dụng các hiệu ứng xử lý hậu kỳ trong hình bên dưới:

Để hiểu rõ hơn những gì đang xảy ra trong các bản dựng gỡ lỗi, chúng tôi đã tạo một hệ thống ghi nhật ký và triển khai một dịch vụ cục bộ trong cơ sở hạ tầng nội bộ có thể thu thập nhật ký từ những người thử nghiệm nội bộ và giúp tìm ra nguyên nhân lỗi dễ dàng hơn. Công cụ này vẫn được QA sử dụng cho các cuộc chơi thử nghiệm và kết quả công việc của nó được đính kèm với các vé trong Jira.

Chúng tôi cũng đã thêm Trình quản lý gói tự viết vào dự án. Ban đầu, chúng tôi muốn cải thiện công việc bằng nhiều gói và plugin bên ngoài khác nhau (trong đó dự án đã tích lũy đủ số lượng). Tuy nhiên, chức năng của Unity không đủ vào thời điểm đó, vì vậy nhóm Nền tảng nội bộ của chúng tôi đã phát triển giải pháp riêng với phiên bản gói, lưu trữ bằng NPM và khả năng kết nối các gói với dự án chỉ bằng cách thêm liên kết vào GitHub. Vì vẫn muốn sử dụng giải pháp công cụ gốc nên chúng tôi đã tham khảo ý kiến của các đồng nghiệp từ Unity và một số ý tưởng của chúng tôi đã được đưa vào giải pháp cuối cùng của Unity khi họ phát hành Trình quản lý gói vào năm 2018.

Chúng tôi tiếp tục mở rộng số lượng nền tảng có sẵn trò chơi của chúng tôi. Cuối cùng, Facebook Gameroom, một nền tảng hỗ trợ bàn phím và chuột, đã xuất hiện. Đây là giải pháp của Facebook (Meta), cho phép người dùng chạy ứng dụng trên PC; về cơ bản, nó là một cửa hàng tương tự trên Steam. Tất nhiên, đối tượng Facebook khá đa dạng và Facebook Gameroom đã được ra mắt trên một số lượng lớn thiết bị, chủ yếu là những thiết bị không chơi game. Vì vậy, chúng tôi quyết định giữ lại đồ họa di động trong trò chơi để không tạo gánh nặng cho PC của đối tượng chính. Từ quan điểm kỹ thuật, những thay đổi quan trọng duy nhất mà trò chơi yêu cầu là việc tích hợp SDK, hệ thống thanh toán và hỗ trợ bàn phím và chuột bằng hệ thống đầu vào Unity gốc.

Về mặt kỹ thuật, nó khác một chút so với cách xây dựng trò chơi cho Steam, nhưng chất lượng của thiết bị thấp hơn đáng kể vì nền tảng này được định vị là nơi dành cho những người chơi bình thường với các thiết bị khá đơn giản không thể chạy gì hơn ngoài một trình duyệt, với điều này trong tâm trí Facebook hy vọng sẽ thâm nhập vào một thị trường khá lớn. Tài nguyên của các thiết bị này bị hạn chế và đặc biệt là nền tảng này thường xuyên gặp các vấn đề về hiệu suất và bộ nhớ.

Sau đó, nền tảng này đóng cửa và chúng tôi chuyển người chơi của mình sang Steam nếu có thể. Để làm được điều đó, chúng tôi đã phát triển một hệ thống đặc biệt có mã để chuyển tài khoản giữa các nền tảng.

Dùng thử Robot chiến tranh trong VR

Một sự kiện đáng chú ý khác trong năm 2017: sự ra mắt của iPhone X, điện thoại thông minh đầu tiên có tai thỏ. Vào thời điểm đó, Unity không hỗ trợ các thiết bị có rãnh khía, vì vậy chúng tôi phải tạo một giải pháp tùy chỉnh dựa trên các tham số UnityEngine.Screen.safeArea, giải pháp này buộc giao diện người dùng phải mở rộng quy mô và tránh các vùng an toàn khác nhau trên màn hình điện thoại.

Ngoài ra, vào năm 2017, chúng tôi đã quyết định thử một điều khác – phát hành phiên bản VR của trò chơi trên Steam. Quá trình phát triển kéo dài khoảng sáu tháng và bao gồm thử nghiệm trên tất cả các mũ bảo hiểm có sẵn tại thời điểm đó: Oculus, HTC Vive và Windows Mixed Reality. Công việc này được thực hiện bằng API Oculus và API Steam. Ngoài ra, phiên bản demo cho tai nghe PS VR đã sẵn sàng cũng như hỗ trợ cho MacOS.

Từ góc độ kỹ thuật, cần phải duy trì FPS ổn định: 60 FPS cho PS VR và 90 FPS cho HTC Vive. Để đạt được điều này, chúng tôi đã sử dụng tính năng Loại bỏ vùng tự viết kịch bản, bên cạnh Frustum và Occlusion tiêu chuẩn, cũng như các phép chiếu lại (khi một số khung được tạo dựa trên các khung trước đó).

Để giải quyết vấn đề say tàu xe, một giải pháp kỹ thuật và sáng tạo thú vị đã được áp dụng: người chơi của chúng tôi trở thành phi công robot và ngồi trong buồng lái. Cabin là một phần tử tĩnh, vì vậy bộ não cảm nhận nó như một loại hằng số nào đó trên thế giới, và do đó, chuyển động trong không gian hoạt động rất tốt.

Trò chơi cũng có một kịch bản yêu cầu phát triển một số trình kích hoạt, tập lệnh và dòng thời gian tự chế riêng biệt vì Cinemachine chưa có sẵn trong phiên bản Unity đó.

Đối với mỗi loại vũ khí, logic nhắm mục tiêu, khóa, theo dõi và tự động nhắm mục tiêu đã được viết từ đầu.

Phiên bản đã được phát hành trên Steam và được người chơi của chúng tôi đón nhận nồng nhiệt. Tuy nhiên, sau chiến dịch Kickstarter, chúng tôi quyết định không tiếp tục phát triển dự án vì việc phát triển một game bắn súng PvP chính thức cho VR tiềm ẩn nhiều rủi ro kỹ thuật và sự chưa sẵn sàng của thị trường đối với một dự án như vậy.

Xử lý lỗi nghiêm trọng đầu tiên của chúng tôi

Trong khi chúng tôi đang nỗ lực cải thiện thành phần kỹ thuật của trò chơi, cũng như tạo ra các cơ chế và nền tảng mới và phát triển hiện có, chúng tôi đã gặp phải lỗi nghiêm trọng đầu tiên trong trò chơi, lỗi này ảnh hưởng tiêu cực đến doanh thu khi tung ra chương trình khuyến mãi mới. Vấn đề là nút “Giá” được bản địa hóa không chính xác thành “Giải thưởng”. Hầu hết người chơi đều bối rối vì điều này, họ đã mua hàng bằng tiền thật và sau đó yêu cầu hoàn lại tiền.

Vấn đề kỹ thuật là vào thời điểm đó, tất cả các bản bản địa hóa của chúng tôi đều được tích hợp vào ứng dụng khách trò chơi. Khi vấn đề này xuất hiện, chúng tôi hiểu rằng chúng tôi không thể trì hoãn việc tìm ra giải pháp cho phép chúng tôi cập nhật bản địa hóa được nữa. Đây là cách tạo ra một giải pháp dựa trên CDN và các công cụ đi kèm, chẳng hạn như các dự án trong TeamCity, giải pháp tự động tải các tệp bản địa hóa lên CDN.

Điều này cho phép chúng tôi tải xuống bản bản địa hóa từ các dịch vụ chúng tôi đã sử dụng (POEditor) và tải dữ liệu thô lên CDN.

Sau đó, server profile bắt đầu thiết lập liên kết cho từng phiên bản client, tương ứng với dữ liệu bản địa hóa. Khi ứng dụng được khởi chạy, máy chủ hồ sơ bắt đầu gửi liên kết này đến máy khách và dữ liệu này đã được tải xuống và lưu vào bộ nhớ đệm.

Tối ưu hóa công việc với dữ liệu

Chuyển sang năm 2018. Khi dự án phát triển, lượng dữ liệu được truyền từ máy chủ đến máy khách cũng tăng theo. Tại thời điểm kết nối với máy chủ, cần tải xuống khá nhiều dữ liệu về số dư, cài đặt hiện tại, v.v.

Dữ liệu hiện tại được trình bày ở định dạng XML và được tuần tự hóa bởi bộ tuần tự hóa Unity tiêu chuẩn.

Ngoài việc truyền một lượng dữ liệu khá lớn khi khởi chạy ứng dụng khách, cũng như khi liên lạc với máy chủ hồ sơ và máy chủ trò chơi, các thiết bị của người chơi đã dành rất nhiều bộ nhớ để lưu trữ số dư hiện tại và tuần tự hóa/giải tuần tự hóa nó.

Rõ ràng là để cải thiện hiệu suất và thời gian khởi động của ứng dụng, cần phải tiến hành R&D để tìm các giao thức thay thế.

Kết quả nghiên cứu trên dữ liệu thử nghiệm của chúng tôi được hiển thị trong bảng này:

Do đó, chúng tôi đã chọn định dạng MessagePack vì việc di chuyển rẻ hơn so với việc chuyển sang FlatBuffers với kết quả đầu ra tương tự, đặc biệt là khi sử dụng MessagePack với các khóa số nguyên.

Đối với FlatBuffers (và với bộ đệm giao thức), cần phải mô tả định dạng thông báo bằng một ngôn ngữ riêng, tạo mã C# và Java và sử dụng mã được tạo trong ứng dụng. Vì chúng tôi không muốn chịu thêm chi phí tái cấu trúc máy khách và máy chủ nên chúng tôi đã chuyển sang MessagePack.

Quá trình chuyển đổi gần như diễn ra liền mạch và trong các bản phát hành đầu tiên, chúng tôi đã hỗ trợ khả năng quay lại XML cho đến khi chúng tôi tin rằng không có vấn đề gì với hệ thống mới. Giải pháp mới giải quyết tất cả nhiệm vụ của chúng tôi – giải pháp này giảm đáng kể thời gian tải ứng dụng khách và cũng cải thiện hiệu suất khi thực hiện yêu cầu tới máy chủ.

Mỗi tính năng hoặc giải pháp kỹ thuật mới trong dự án của chúng tôi đều được phát hành dưới một “cờ”. Cờ này được lưu trong hồ sơ của người chơi và đến với khách hàng khi trò chơi bắt đầu, cùng với số dư. Theo quy định, khi một chức năng mới được phát hành, đặc biệt là chức năng kỹ thuật, một số bản phát hành ứng dụng khách sẽ chứa cả hai chức năng – cũ và mới. Việc kích hoạt chức năng mới diễn ra tuân thủ nghiêm ngặt trạng thái cờ được mô tả ở trên, cho phép chúng tôi theo dõi và điều chỉnh thành công kỹ thuật của một giải pháp cụ thể trong thời gian thực.

Dần dần, đã đến lúc cập nhật chức năng Dependency Insert trong dự án. Phiên bản hiện tại không còn có thể xử lý được số lượng lớn các phần phụ thuộc và trong một số trường hợp đã đưa ra các kết nối không rõ ràng, rất khó phá vỡ và tái cấu trúc. (Điều này đặc biệt đúng đối với những đổi mới liên quan đến giao diện người dùng theo cách này hay cách khác.)

Khi chọn một giải pháp mới, sự lựa chọn rất đơn giản: Zenject nổi tiếng, đã được chứng minh trong các dự án khác của chúng tôi. Dự án này đã được phát triển trong một thời gian dài, được hỗ trợ tích cực, các tính năng mới đang được bổ sung và nhiều nhà phát triển trong nhóm đã quen thuộc với nó theo một cách nào đó.

Từng chút một, chúng tôi bắt đầu viết lại War Robots bằng Zenject. Tất cả các mô-đun mới đều được phát triển cùng với nó và các mô-đun cũ dần dần được cấu trúc lại. Kể từ khi sử dụng Zenject, chúng tôi đã nhận được trình tự tải dịch vụ rõ ràng hơn trong bối cảnh mà chúng tôi đã thảo luận trước đó (chiến đấu và nhà chứa máy bay) và điều này cho phép các nhà phát triển dễ dàng đi sâu hơn vào quá trình phát triển dự án cũng như tự tin hơn khi phát triển các tính năng mới trong những bối cảnh này.

Trong các phiên bản Unity tương đối mới, có thể hoạt động với mã không đồng bộ thông qua async/await. Mã của chúng tôi đã sử dụng mã không đồng bộ, nhưng không có tiêu chuẩn duy nhất nào trên cơ sở mã và do phần phụ trợ tập lệnh Unity bắt đầu hỗ trợ async/await, nên chúng tôi quyết định tiến hành R&D và chuẩn hóa các phương pháp tiếp cận của chúng tôi đối với mã không đồng bộ.

Một động lực khác là loại bỏ địa ngục gọi lại khỏi mã - đây là khi có một chuỗi các lệnh gọi không đồng bộ tuần tự và mỗi lệnh gọi sẽ chờ kết quả của lệnh gọi tiếp theo.

Vào thời điểm đó, có một số giải pháp phổ biến như RSG hay UniRx; chúng tôi đã so sánh tất cả và tổng hợp chúng thành một bảng duy nhất:

Cuối cùng, chúng tôi đã quyết định sử dụng async/await gốc làm tiêu chuẩn để làm việc với mã C# không đồng bộ mà hầu hết các nhà phát triển đều quen thuộc. Chúng tôi quyết định không sử dụng UniRx.Async vì các ưu điểm của plugin không đáp ứng nhu cầu dựa vào giải pháp của bên thứ ba.

Chúng tôi đã chọn đi theo con đường có chức năng yêu cầu tối thiểu. Chúng tôi đã từ bỏ việc sử dụng RSG.Promise hoặc chủ sở hữu, bởi vì, trước hết, cần phải đào tạo các nhà phát triển mới cách làm việc với những công cụ này, thường là những công cụ không quen thuộc và thứ hai, cần phải tạo một trình bao bọc cho mã của bên thứ ba. sử dụng Nhiệm vụ không đồng bộ trong RSG.Promise hoặc chủ sở hữu. Việc lựa chọn async/await cũng giúp tiêu chuẩn hóa phương pháp phát triển giữa các dự án của công ty. Quá trình chuyển đổi này đã giải quyết được các vấn đề của chúng tôi – chúng tôi đã đạt được một quy trình rõ ràng để làm việc với mã không đồng bộ và loại bỏ địa ngục gọi lại khó hỗ trợ khỏi dự án.

Giao diện người dùng dần được cải thiện. Vì trong nhóm của chúng tôi, chức năng của các tính năng mới được phát triển bởi các lập trình viên khách hàng và việc phát triển giao diện và bố cục được thực hiện bởi bộ phận UI/UX, nên chúng tôi cần một giải pháp cho phép chúng tôi song song hóa công việc trên cùng một tính năng – để người thiết kế bố cục có thể tạo và kiểm tra giao diện trong khi lập trình viên viết logic.

Giải pháp cho vấn đề này đã được tìm thấy khi chuyển sang mô hình MVVM làm việc với giao diện. Mô hình này cho phép người thiết kế giao diện không chỉ thiết kế giao diện mà không cần đến người lập trình mà còn xem giao diện sẽ phản ứng như thế nào với dữ liệu nhất định khi chưa có dữ liệu thực tế nào được kết nối. Sau một số nghiên cứu về các giải pháp sẵn có, cũng như tạo mẫu nhanh cho giải pháp của riêng chúng tôi có tên là Pixonic ReactiveBindings, chúng tôi đã tổng hợp một bảng so sánh với các kết quả sau:

Ngay sau khi hệ thống mới đã chứng tỏ được khả năng của mình, chủ yếu là về mặt đơn giản hóa việc sản xuất các giao diện mới, chúng tôi bắt đầu sử dụng nó cho tất cả các dự án mới, cũng như tất cả các tính năng mới xuất hiện trong dự án.

Remaster của trò chơi dành cho thế hệ thiết bị di động mới

Đến năm 2019, một số thiết bị của Apple và Samsung đã ra mắt khá mạnh về mặt đồ họa nên công ty chúng tôi đã nảy ra ý tưởng nâng cấp đáng kể War Robots. Chúng tôi muốn khai thác sức mạnh của tất cả các thiết bị mới này và cập nhật hình ảnh trực quan của trò chơi.

Ngoài hình ảnh được cập nhật, chúng tôi cũng có một số yêu cầu đối với sản phẩm cập nhật của mình: chúng tôi muốn hỗ trợ chế độ trò chơi 60 FPS cũng như các chất lượng tài nguyên khác nhau cho các thiết bị khác nhau.

Người quản lý chất lượng hiện tại cũng yêu cầu làm lại, vì số lượng chất lượng trong các khối ngày càng tăng, được bật nhanh chóng, làm giảm năng suất cũng như tạo ra một số lượng lớn các hoán vị, mỗi hoán vị phải được kiểm tra, điều này buộc phải bổ sung thêm chi phí cho nhóm QA với mỗi lần phát hành.

Điều đầu tiên chúng tôi bắt đầu khi làm lại client là tái cấu trúc việc chụp ảnh. Việc triển khai ban đầu phụ thuộc vào tốc độ kết xuất khung hình vì thực thể trò chơi và hình ảnh hiển thị trực quan của nó trong máy khách là một và cùng một đối tượng. Chúng tôi đã quyết định tách các thực thể này để thực thể trò chơi của cảnh quay không còn phụ thuộc vào hình ảnh của nó nữa và điều này giúp mang lại lối chơi công bằng hơn giữa các thiết bị có tốc độ khung hình khác nhau.

Trò chơi xử lý một số lượng lớn các phát bắn, nhưng thuật toán xử lý dữ liệu của những phát bắn này khá đơn giản – di chuyển, quyết định xem kẻ thù có bị bắn trúng hay không, v.v. Khái niệm Hệ thống Thành phần Thực thể hoàn toàn phù hợp để tổ chức logic chuyển động của đạn trong trò chơi nên chúng tôi quyết định gắn bó với nó.

Ngoài ra, trong tất cả các dự án mới của chúng tôi, chúng tôi đã sử dụng ECS để làm việc theo logic và đã đến lúc áp dụng mô hình này cho dự án chính của chúng tôi để thống nhất. Sau khi hoàn thành công việc, chúng tôi nhận ra một yêu cầu quan trọng – đảm bảo khả năng chạy hình ảnh ở tốc độ 60 FPS. Tuy nhiên, không phải toàn bộ mã chiến đấu đều được chuyển sang ECS nên tiềm năng của phương pháp này không thể phát huy hết. Cuối cùng, chúng tôi đã không cải thiện hiệu suất nhiều như mong muốn nhưng cũng không làm suy giảm nó, đây vẫn là một chỉ báo quan trọng với sự thay đổi kiến trúc và mô hình mạnh mẽ như vậy.

Đồng thời, chúng tôi bắt đầu làm việc trên phiên bản PC của mình để xem chúng tôi có thể đạt được mức đồ họa nào với hệ thống đồ họa mới của mình. Nó bắt đầu tận dụng Unity SRP, lúc đó vẫn đang ở phiên bản xem trước và liên tục thay đổi. Hình ảnh được đưa ra cho phiên bản Steam khá ấn tượng:

Hơn nữa, một số tính năng đồ họa hiển thị trong hình trên có thể được chuyển sang các thiết bị di động mạnh mẽ. Điều này đặc biệt dành cho các thiết bị của Apple, vốn có đặc tính hiệu suất tốt, trình điều khiển xuất sắc và sự kết hợp chặt chẽ giữa phần cứng và phần mềm; điều này cho phép họ tạo ra một bức tranh có chất lượng rất cao mà không cần bất kỳ giải pháp tạm thời nào từ phía chúng tôi.

Chúng tôi nhanh chóng hiểu rằng chỉ thay đổi ngăn xếp đồ họa sẽ không thay đổi hình ảnh. Rõ ràng là ngoài các thiết bị mạnh mẽ, chúng ta còn cần nội dung dành cho các thiết bị yếu hơn. Vì vậy, chúng tôi bắt đầu lên kế hoạch phát triển nội dung cho các mức chất lượng khác nhau.

Điều này có nghĩa là máy móc, súng, bản đồ, hiệu ứng và kết cấu của chúng phải được tách biệt về chất lượng, nghĩa là các thực thể khác nhau sẽ có chất lượng khác nhau. Nghĩa là, các mô hình vật lý, kết cấu và tập hợp kết cấu cơ khí sẽ hoạt động ở chất lượng HD sẽ khác với các cơ chế hoạt động ở chất lượng khác.

Ngoài ra, trò chơi dành một lượng lớn tài nguyên cho bản đồ và những bản đồ này cũng cần được làm lại để phù hợp với những phẩm chất mới. Rõ ràng là Người quản lý chất lượng hiện tại không đáp ứng được nhu cầu của chúng tôi vì nó không kiểm soát chất lượng tài sản.

Vì vậy, trước tiên, chúng tôi phải quyết định những phẩm chất nào sẽ có trong trò chơi của mình. Dựa trên trải nghiệm của Trình quản lý chất lượng hiện tại, chúng tôi nhận ra rằng trong phiên bản mới, chúng tôi muốn có một số phẩm chất cố định mà người dùng có thể chuyển đổi độc lập trong cài đặt tùy thuộc vào chất lượng tối đa hiện có cho một thiết bị nhất định.

Hệ thống chất lượng mới xác định thiết bị mà người dùng sở hữu và dựa trên kiểu thiết bị (trong trường hợp iOS) và kiểu GPU (trong trường hợp Android), cho phép chúng tôi đặt chất lượng tối đa hiện có cho một trình phát cụ thể. Trong trường hợp này, chất lượng này, cũng như tất cả các phẩm chất trước đó, đều có sẵn.

Ngoài ra, đối với mỗi chất lượng, có một cài đặt để chuyển FPS tối đa trong khoảng từ 30 đến 60. Ban đầu, chúng tôi dự định có khoảng năm chất lượng (ULD, LD, MD, HD, UHD). Tuy nhiên, trong quá trình phát triển, rõ ràng là số lượng phẩm chất này sẽ mất rất nhiều thời gian để phát triển và sẽ không cho phép chúng tôi giảm tải cho QA. Với suy nghĩ này, cuối cùng, chúng tôi đã đạt được những phẩm chất sau trong trò chơi: HD, LD và ULD. (Để tham khảo, tỷ lệ phân bổ khán giả chơi với những phẩm chất này hiện tại như sau: HD - 7%, LD - 72%, ULD - 21%.)

Ngay khi chúng tôi hiểu rằng mình cần triển khai nhiều phẩm chất hơn, chúng tôi bắt đầu tìm cách sắp xếp nội dung theo những phẩm chất đó. Để đơn giản hóa công việc này, chúng tôi đã đồng ý với thuật toán sau: các nghệ sĩ sẽ tạo nội dung có chất lượng (HD) tối đa, sau đó, bằng cách sử dụng tập lệnh và các công cụ tự động hóa khác, các phần của những nội dung này sẽ được đơn giản hóa và sử dụng làm nội dung cho các chất lượng khác.

Trong quá trình làm việc trên hệ thống tự động hóa này, chúng tôi đã phát triển các giải pháp sau:

• Trình nhập nội dung – cho phép chúng tôi đặt các cài đặt cần thiết cho kết cấu
• Mech Creator – một công cụ cho phép tạo một số phiên bản mech dựa trên Biến thể Unity Prefab, cũng như cài đặt chất lượng và kết cấu, được phân phối trong các thư mục dự án tương ứng.
• Text Array Packer – một công cụ cho phép bạn đóng gói họa tiết vào mảng kết cấu
• Trình tạo bản đồ chất lượng – một công cụ để tạo nhiều chất lượng bản đồ từ một nguồn bản đồ chất lượng UHD

Rất nhiều công việc đã được thực hiện để tái cấu trúc các tài nguyên bản đồ và máy móc hiện có. Các máy móc ban đầu không được thiết kế với các đặc tính khác nhau và do đó được lưu trữ trong các nhà lắp ghép đơn lẻ. Sau khi tái cấu trúc, các phần cơ bản được trích xuất từ chúng, chủ yếu chứa logic của chúng và sử dụng Biến thể Prefab, các biến thể có kết cấu cho chất lượng cụ thể đã được tạo. Ngoài ra, chúng tôi đã thêm các công cụ có thể tự động chia mech thành các phẩm chất khác nhau, có tính đến thứ bậc của các thư mục lưu trữ kết cấu tùy thuộc vào chất lượng.

Để phân phối nội dung cụ thể đến các thiết bị cụ thể, cần phải chia tất cả nội dung trong trò chơi thành các gói và gói. Gói chính chứa các nội dung cần thiết để chạy trò chơi, các nội dung được sử dụng ở mọi chức năng cũng như các gói chất lượng cho từng nền tảng: Android_LD, Android_HD, Android_ULD, iOS_LD, iOS_HD, iOS_ULD, v.v.

Việc phân chia tài sản thành các gói có thể thực hiện được nhờ công cụ ResourceSystem do nhóm Nền tảng của chúng tôi tạo ra. Hệ thống này cho phép chúng tôi thu thập nội dung thành các gói riêng biệt rồi nhúng chúng vào ứng dụng khách hoặc lấy riêng chúng để tải lên các tài nguyên bên ngoài, chẳng hạn như CDN.

Để cung cấp nội dung, chúng tôi đã sử dụng một hệ thống mới, cũng do nhóm nền tảng tạo ra, có tên là DeliverySystem. Hệ thống này cho phép bạn nhận bảng kê khai do ResourceSystem tạo và tải xuống tài nguyên từ nguồn được chỉ định. Nguồn này có thể là bản dựng nguyên khối, tệp APK riêng lẻ hoặc CDN từ xa.

Ban đầu, chúng tôi dự định sử dụng các khả năng của Google Play (Play Asset Delivery) và AppStore (Tài nguyên theo yêu cầu) để lưu trữ các gói tài nguyên, nhưng trên nền tảng Android, có nhiều vấn đề liên quan đến cập nhật ứng dụng khách tự động cũng như các hạn chế về số lượng tài nguyên được lưu trữ.

Hơn nữa, các thử nghiệm nội bộ của chúng tôi cho thấy hệ thống phân phối nội dung có CDN hoạt động tốt nhất và ổn định nhất, vì vậy chúng tôi đã từ bỏ việc lưu trữ tài nguyên trong các cửa hàng và bắt đầu lưu trữ chúng trên đám mây của mình.

Phát hành bản remaster

Khi công việc chính của bản remaster hoàn thành cũng là lúc phát hành. Tuy nhiên, chúng tôi nhanh chóng hiểu rằng kích thước dự kiến ban đầu là 3 GB là trải nghiệm tải xuống kém mặc dù một số trò chơi phổ biến trên thị trường yêu cầu người dùng tải xuống 5-10 GB dữ liệu. Lý thuyết của chúng tôi là người dùng sẽ quen với thực tế mới này vào thời điểm chúng tôi phát hành trò chơi được làm lại ra thị trường, nhưng than ôi.

Nói cách khác, người chơi chưa quen với những loại tệp lớn này dành cho trò chơi di động. Chúng tôi cần phải nhanh chóng tìm ra giải pháp cho vấn đề này. Chúng tôi đã quyết định phát hành một phiên bản không có chất lượng HD nhiều lần sau đó nhưng chúng tôi vẫn cung cấp phiên bản đó cho người dùng sau đó.

Song song với việc phát triển bản remaster, chúng tôi tích cực làm việc để tự động hóa việc thử nghiệm dự án. Nhóm QA đã làm rất tốt việc đảm bảo rằng trạng thái của dự án có thể được theo dõi tự động. Hiện tại, chúng tôi có máy chủ với máy ảo nơi trò chơi chạy. Bằng cách sử dụng khung kiểm thử tự viết, chúng tôi có thể nhấn bất kỳ nút nào trong dự án bằng các tập lệnh – và các tập lệnh tương tự được sử dụng để chạy các kịch bản khác nhau khi kiểm thử trực tiếp trên thiết bị.

Chúng tôi đang tiếp tục phát triển hệ thống này: hàng trăm bài kiểm thử chạy liên tục đã được viết để kiểm tra độ ổn định, hiệu suất và khả năng thực thi logic chính xác. Kết quả được hiển thị trong một bảng điều khiển đặc biệt nơi các chuyên gia QA của chúng tôi cùng với các nhà phát triển có thể kiểm tra chi tiết các khu vực có vấn đề nhất (bao gồm cả ảnh chụp màn hình thực tế từ quá trình chạy thử nghiệm).

Trước khi đưa hệ thống hiện tại vào vận hành, việc kiểm thử hồi quy mất rất nhiều thời gian (khoảng một tuần đối với phiên bản cũ của dự án), cũng nhỏ hơn nhiều so với hiện tại về khối lượng cũng như nội dung. Nhưng nhờ thử nghiệm tự động, phiên bản hiện tại của trò chơi chỉ được thử nghiệm trong hai đêm; điều này có thể được cải thiện hơn nữa, nhưng hiện tại, chúng tôi bị giới hạn bởi số lượng thiết bị kết nối với hệ thống.

Để hoàn thành bản remaster, nhóm Apple đã liên hệ với chúng tôi và cho chúng tôi cơ hội tham gia buổi giới thiệu sản phẩm mới nhằm chứng minh khả năng của chip Apple A14 Bionic mới (được phát hành cùng với iPad mới vào mùa thu năm 2020) bằng cách sử dụng của chúng tôi đồ họa mới. Trong quá trình thực hiện dự án nhỏ này, một phiên bản HD hoạt động hoàn toàn đã được tạo ra, có khả năng chạy trên chip Apple ở tốc độ 120 FPS. Ngoài ra, một số cải tiến về đồ họa đã được thêm vào để chứng minh sức mạnh của con chip mới.

Là kết quả của một cuộc tuyển chọn mang tính cạnh tranh và khá khó khăn, trò chơi của chúng tôi đã được đưa vào buổi giới thiệu mùa thu của Sự kiện Apple! Toàn đội đã tụ tập lại để xem và ăn mừng sự kiện này, và nó thực sự rất tuyệt!

Từ bỏ Photon và chuyển sang kiến trúc WorldState.

Ngay cả trước khi ra mắt phiên bản làm lại của trò chơi vào năm 2021, một nhiệm vụ mới đã xuất hiện. Nhiều người dùng đã phàn nàn về các sự cố mạng, nguyên nhân của sự cố này là giải pháp hiện tại của chúng tôi vào thời điểm đó, lớp truyền tải Photon, được sử dụng để hoạt động với Photon Server SDK. Một vấn đề khác là sự hiện diện của một số lượng lớn RPC không đạt tiêu chuẩn được gửi đến máy chủ theo thứ tự ngẫu nhiên.

Ngoài ra, còn có vấn đề về việc đồng bộ hóa thế giới và làm tràn hàng đợi tin nhắn khi bắt đầu trận đấu, có thể gây ra độ trễ đáng kể.

Để khắc phục tình trạng này, chúng tôi đã quyết định chuyển ngăn xếp kết nối mạng sang một mô hình thông thường hơn, trong đó giao tiếp với máy chủ diễn ra thông qua các gói và nhận trạng thái trò chơi chứ không phải qua các cuộc gọi RPC.

Kiến trúc trận đấu trực tuyến mới được gọi là WorldState và nhằm mục đích loại bỏ Photon khỏi trò chơi.

Ngoài việc thay thế giao thức truyền tải từ Photon sang UDP dựa trên thư viện LightNetLib, kiến trúc mới này còn liên quan đến việc hợp lý hóa hệ thống liên lạc giữa máy khách và máy chủ.

Nhờ phát triển tính năng này, chúng tôi đã giảm chi phí ở phía máy chủ (chuyển từ Windows sang Linux và từ bỏ giấy phép Photon Server SDK), tạo ra một giao thức ít đòi hỏi hơn nhiều đối với các thiết bị cuối của người dùng, giảm số lượng sự cố với tính năng không đồng bộ hóa trạng thái giữa máy chủ và máy khách, đồng thời tạo cơ hội phát triển nội dung PvE mới.

Sẽ không thể thay đổi toàn bộ mã trò chơi chỉ sau một đêm, vì vậy công việc trên WorldState được chia thành nhiều giai đoạn.

Giai đoạn đầu tiên là thiết kế lại hoàn toàn giao thức liên lạc giữa máy khách và máy chủ, đồng thời chuyển động của máy móc sang các đường ray mới. Điều này cho phép chúng tôi tạo một chế độ mới cho trò chơi: PvE. Dần dần, các thợ máy bắt đầu chuyển sang máy chủ, đặc biệt là những máy chủ mới nhất (hư hỏng và hư hỏng nghiêm trọng đối với máy). Công việc chuyển dần dần mã cũ sang cơ chế WorldState vẫn tiếp tục và chúng tôi cũng sẽ có một số cập nhật trong năm nay.

Vào năm 2022, chúng tôi đã ra mắt một nền tảng mới: Facebook Cloud. Ý tưởng đằng sau nền tảng này rất thú vị: chạy trò chơi trên trình giả lập trên đám mây và truyền trực tuyến chúng tới trình duyệt trên điện thoại thông minh và PC mà không cần người chơi cuối phải có PC hoặc điện thoại thông minh mạnh mẽ để chạy trò chơi; chỉ cần có kết nối Internet ổn định.

Từ phía nhà phát triển, hai loại bản dựng có thể được phân phối làm loại chính mà nền tảng sẽ sử dụng: bản dựng Android và bản dựng Windows. Chúng tôi đã đi theo con đường đầu tiên do có nhiều kinh nghiệm hơn với nền tảng này.

Để khởi chạy trò chơi của mình trên Facebook Cloud, chúng tôi cần thực hiện một số sửa đổi, chẳng hạn như thực hiện lại ủy quyền trong trò chơi và thêm điều khiển con trỏ. Chúng tôi cũng cần chuẩn bị một bản dựng với tất cả các tài nguyên tích hợp vì nền tảng không hỗ trợ CDN và chúng tôi cần định cấu hình các tích hợp của mình, vốn không phải lúc nào cũng có thể chạy chính xác trên trình mô phỏng.

Rất nhiều công việc cũng được thực hiện ở khía cạnh đồ họa để đảm bảo chức năng của ngăn xếp đồ họa vì trình giả lập Facebook không phải là thiết bị Android thực sự và có những đặc điểm riêng về triển khai trình điều khiển và quản lý tài nguyên.

Tuy nhiên, chúng tôi thấy rằng người dùng nền tảng này gặp phải nhiều vấn đề – cả kết nối không ổn định và hoạt động không ổn định của trình giả lập, và Facebook đã quyết định đóng cửa nền tảng của họ vào đầu năm 2024.

Những gì liên tục xảy ra về phía các lập trình viên và không thể thảo luận chi tiết trong một bài viết ngắn như vậy là làm việc thường xuyên với các rủi ro kỹ thuật của dự án, giám sát thường xuyên các số liệu kỹ thuật, làm việc liên tục với bộ nhớ và tối ưu hóa tài nguyên, tìm kiếm các vấn đề trong giải pháp của bên thứ ba về SDK đối tác, tích hợp quảng cáo và hơn thế nữa.

Ngoài ra, chúng tôi tiếp tục nghiên cứu và thực hiện công việc khắc phục các sự cố nghiêm trọng và ANR. Khi một dự án chạy trên một số lượng lớn các thiết bị hoàn toàn khác nhau như vậy thì điều này là không thể tránh khỏi.

Riêng biệt, chúng tôi muốn ghi nhận tính chuyên nghiệp của những người làm việc để tìm ra nguyên nhân của vấn đề. Những vấn đề kỹ thuật này thường có bản chất phức tạp và cần phải chồng dữ liệu từ nhiều hệ thống phân tích lên nhau, cũng như tiến hành một số thí nghiệm không hề tầm thường trước khi tìm ra nguyên nhân. Thông thường, hầu hết các vấn đề phức tạp đều không có trường hợp tái tạo nhất quán để có thể kiểm tra được, vì vậy dữ liệu thực nghiệm và kinh nghiệm chuyên môn của chúng tôi thường được sử dụng để khắc phục chúng.

Cần phải nói đôi lời về các công cụ và tài nguyên mà chúng tôi sử dụng để tìm ra vấn đề trong một dự án.

• AppMetr – một giải pháp phân tích nội bộ cho phép bạn thu thập dữ liệu ẩn danh từ các thiết bị để nghiên cứu các vấn đề của người chơi. Một số công cụ tương tự có thể được người đọc biết đến nhiều hơn là: Firebase Analytics, Google Analytics, Flurry, GameAnalytics, devtodev, AppsFlyer, v.v.
• Google Firebase Crashlytics
• Google Play Console – Android Vitals
• Nhật ký – một hệ thống nhật ký trong các bản gỡ lỗi, cho phép bạn giảm thiểu việc tìm kiếm các vấn đề trong các lần chơi thử trong studio
• Vương quốc thử nghiệm công khai – trò chơi của chúng tôi có các máy chủ thử nghiệm công khai cho phép bạn thử nghiệm những thay đổi mới và tiến hành nhiều thử nghiệm kỹ thuật khác nhau
• Trình hồ sơ thống nhất
• Công cụ XCode

Đây chỉ là một danh sách nhỏ các cải tiến kỹ thuật mà dự án đã trải qua trong suốt thời gian tồn tại. Thật khó để liệt kê tất cả những gì đã hoàn thành vì dự án không ngừng phát triển và các nhà quản lý kỹ thuật không ngừng làm việc để lập và thực hiện các kế hoạch nhằm cải thiện hiệu suất của sản phẩm cho cả người dùng cuối và những người làm việc với nó trong studio, bao gồm cả nhân viên. bản thân các nhà phát triển và các bộ phận khác.

Chúng tôi vẫn còn nhiều cải tiến mà sản phẩm sẽ có trong thập kỷ tới và chúng tôi hy vọng rằng chúng tôi có thể chia sẻ những cải tiến này trong các bài viết tiếp theo của mình.

Chúc mừng sinh nhật War Robots và cảm ơn đội ngũ chuyên gia kỹ thuật đông đảo đã biến tất cả những điều này thành hiện thực!