Phần mềm là dịch vụ, cơ sở hạ tầng là dịch vụ, nền tảng là dịch vụ, nền tảng truyền thông là dịch vụ, hội nghị truyền hình là dịch vụ, còn trò chơi trên đám mây là một dịch vụ thì sao? Đã có một số nỗ lực tạo ra trò chơi trên nền tảng đám mây (Cloud Gaming), chẳng hạn như Stadia, được Google ra mắt gần đây. sân vận động , nhưng những người khác có thể sử dụng WebRTC theo cách tương tự không?
Thanh Nguyen quyết định thử nghiệm cơ hội này trên dự án nguồn mở CloudRetro của mình. CloudRetro dựa trên Pion, Thư viện WebRTC dựa trên Go (cảm ơn từ nhóm phát triển Pion vì sự hỗ trợ của họ trong việc chuẩn bị bài viết này). Trong bài viết này, Thành cung cấp cái nhìn tổng quan về kiến trúc dự án của mình, đồng thời nói về những điều hữu ích mà anh đã học được cũng như những thách thức anh gặp phải trong quá trình làm việc.
Nhập
Năm ngoái, khi Google công bố Stadia, tôi đã rất ngạc nhiên. Ý tưởng này độc đáo và sáng tạo đến mức tôi không ngừng tự hỏi làm thế nào điều này có thể thực hiện được với công nghệ hiện có. Mong muốn hiểu rõ hơn về chủ đề này đã thôi thúc tôi tạo ra phiên bản trò chơi đám mây nguồn mở của riêng mình. Kết quả đơn giản là tuyệt vời. Dưới đây mình xin chia sẻ quá trình làm việc trong năm của mình .
TLDR: phiên bản slide ngắn có điểm nổi bật
Tại sao chơi game trên nền tảng đám mây là tương lai
Tôi tin rằng Cloud Gaming sẽ sớm trở thành thế hệ tiếp theo không chỉ của chơi game mà còn của các lĩnh vực khoa học máy tính khác. Chơi game trên nền tảng đám mây là đỉnh cao của mô hình máy khách/máy chủ. Mô hình này tối đa hóa khả năng quản lý phụ trợ và giảm thiểu công việc giao diện người dùng bằng cách lưu trữ logic trò chơi trên máy chủ từ xa và truyền hình ảnh/âm thanh đến máy khách. Máy chủ thực hiện xử lý nặng để máy khách không còn phải chịu những hạn chế về phần cứng.
Về cơ bản, Google Stadia cho phép bạn chơi (tức là game bom tấn cao cấp) trên giao diện như YouTube. Phương pháp tương tự có thể được áp dụng cho các ứng dụng ngoại tuyến nặng khác như hệ điều hành hoặc thiết kế đồ họa 2D/3D, v.v. để chúng tôi có thể chạy chúng một cách nhất quán trên các thiết bị có thông số kỹ thuật thấp trên nhiều nền tảng.
Tương lai của công nghệ này: Hãy tưởng tượng nếu Microsoft Windows 10 chạy trên trình duyệt Chrome?
Chơi game trên đám mây là thách thức về mặt kỹ thuật
Chơi game là một trong những lĩnh vực hiếm hoi yêu cầu phản hồi nhanh và liên tục của người dùng. Nếu thỉnh thoảng chúng tôi gặp phải độ trễ 2 giây khi nhấp vào một trang thì điều này có thể chấp nhận được. Các luồng video trực tiếp có xu hướng bị trễ vài giây nhưng vẫn mang lại khả năng sử dụng hợp lý. Tuy nhiên, nếu trò chơi thường xuyên bị trễ 500 mili giây thì đơn giản là trò chơi đó không thể chơi được. Mục tiêu của chúng tôi là đạt được độ trễ cực thấp để khoảng cách giữa đầu vào và phương tiện càng nhỏ càng tốt. Do đó, cách tiếp cận truyền phát video truyền thống không thể áp dụng ở đây.
Mẫu trò chơi đám mây chung
Dự án nguồn mở CloudRetro
Tôi quyết định tạo mẫu thử nghiệm của trò chơi trên đám mây để xem liệu tất cả những điều này có khả thi với những hạn chế về mạng chặt chẽ như vậy hay không. Tôi đã chọn Golang làm bằng chứng về khái niệm vì đó là ngôn ngữ tôi quen thuộc nhất và rất phù hợp cho việc triển khai này vì nhiều lý do khác, như sau này tôi đã phát hiện ra. Cờ vây đơn giản và phát triển rất nhanh; Các kênh trong Go rất tốt để quản lý đa luồng.
Dự án là một dịch vụ chơi game đám mây mã nguồn mở để chơi game cổ điển. Mục tiêu của dự án là mang lại trải nghiệm chơi game thoải mái nhất cho các trò chơi cổ điển truyền thống và thêm nhiều người chơi.
Bạn có thể tìm hiểu thêm về dự án tại đây: .
Chức năng CloudRetro
CloudRetro sử dụng các trò chơi cổ điển để chứng minh sức mạnh của trò chơi trên đám mây. Điều này cho phép bạn có được nhiều trải nghiệm chơi game độc đáo.
- Tính di động của trò chơi
- Phát lại tức thì khi mở một trang; không cần tải xuống hoặc cài đặt
- Hoạt động trên trình duyệt di động nên không cần phần mềm để chạy nó
- Các phiên trò chơi có thể được chia sẻ trên nhiều thiết bị và được lưu trữ trên đám mây cho lần đăng nhập tiếp theo của bạn
- Trò chơi có thể được phát trực tuyến hoặc có thể được chơi bởi nhiều người dùng cùng một lúc:
- Crowdplay như TwitchPlayPokemon, chỉ đa nền tảng hơn và thời gian thực hơn
- Trò chơi ngoại tuyến trực tuyến. Nhiều người dùng có thể chơi mà không cần thiết lập mạng. Samurai Shodown hiện có thể được chơi bởi 2 người chơi qua mạng CloudRetro
Phiên bản demo của trò chơi nhiều người chơi trực tuyến trên các thiết bị khác nhaucơ sở hạ tầng
Yêu cầu và ngăn xếp công nghệ
Dưới đây là danh sách các yêu cầu mà tôi đặt ra trước khi bắt đầu dự án.
1. Một người chơi
Yêu cầu này có vẻ không quá quan trọng hoặc rõ ràng ở đây, nhưng nó là một trong những điểm quan trọng nhất của tôi, nó cho phép trò chơi trên đám mây tránh xa các dịch vụ phát trực tuyến truyền thống nhất có thể. Nếu chúng tôi tập trung vào trò chơi một người chơi, chúng tôi có thể loại bỏ máy chủ tập trung hoặc CDN vì chúng tôi không cần phải phát trực tuyến cho đại chúng. Thay vì tải các luồng lên máy chủ chìm hoặc chuyển các gói đến máy chủ WebSocket tập trung, các luồng dịch vụ được phân phối trực tiếp đến người dùng thông qua kết nối WebRTC ngang hàng.2. Luồng phương tiện có độ trễ thấp
Đọc về Stadia, tôi thường thấy WebRTC được đề cập trong một số bài viết. Tôi nhận ra rằng WebRTC là một công nghệ vượt trội và hoàn hảo để sử dụng trong trò chơi trên đám mây. WebRTC là một dự án cung cấp cho trình duyệt web và ứng dụng di động khả năng giao tiếp theo thời gian thực thông qua một API đơn giản. Nó cung cấp khả năng kết nối ngang hàng, được tối ưu hóa cho phương tiện truyền thông và được tích hợp sẵn các codec tiêu chuẩn như VP8 và H264.Tôi ưu tiên đảm bảo trải nghiệm người dùng tốt nhất có thể hơn là duy trì đồ họa chất lượng cao. Một số tổn thất được chấp nhận trong thuật toán. Google Stadia có thêm một bước là giảm kích thước hình ảnh trên máy chủ và các khung hình được nâng cấp lên chất lượng cao hơn trước khi truyền đến các máy ngang hàng.
3. Cơ sở hạ tầng phân tán với định tuyến địa lý
Cho dù thuật toán nén và mã được tối ưu hóa đến đâu thì mạng vẫn là yếu tố quyết định góp phần nhiều nhất vào độ trễ. Kiến trúc phải có cơ chế ghép nối máy chủ gần người dùng nhất để giảm thời gian khứ hồi (RTT). Kiến trúc phải có 1 điều phối viên và một số máy chủ phát trực tuyến được phân bổ trên toàn thế giới: Miền Tây Hoa Kỳ, Miền Đông Hoa Kỳ, Châu Âu, Singapore, Trung Quốc. Tất cả các máy chủ phát trực tuyến phải được cách ly hoàn toàn. Hệ thống có thể điều chỉnh phân phối của nó khi máy chủ tham gia hoặc rời khỏi mạng. Do đó, với lưu lượng truy cập lớn, việc bổ sung thêm máy chủ sẽ cho phép mở rộng quy mô theo chiều ngang.4. Khả năng tương thích trình duyệt
Chơi game trên đám mây hoạt động tốt nhất khi nó đòi hỏi ít nhất từ người dùng. Điều này có nghĩa là nó có thể chạy trong trình duyệt. Trình duyệt giúp trải nghiệm chơi game trở nên thoải mái nhất có thể cho người dùng, giúp họ không phải cài đặt phần mềm và phần cứng. Trình duyệt cũng giúp cung cấp chức năng đa nền tảng giữa phiên bản dành cho thiết bị di động và máy tính để bàn. May mắn thay, WebRTC được hỗ trợ tốt trên nhiều trình duyệt.5. Tách biệt rõ ràng giữa giao diện trò chơi và dịch vụ
Tôi xem dịch vụ trò chơi trên đám mây như một nền tảng. Mọi người đều có thể kết nối mọi thứ với nền tảng. Bây giờ tôi đã tích hợp với dịch vụ chơi game trên nền tảng đám mây vì LibRetro cung cấp giao diện giả lập trò chơi đẹp mắt cho các trò chơi retro như SNES, GBA, PS.6. Phòng dành cho nhiều người chơi, chơi theo đám đông và liên kết bên ngoài (liên kết sâu) với trò chơi
CloudRetro hỗ trợ nhiều cách chơi mới như CrowdPlay và Online MultiPlayer cho các trò chơi cổ điển. Nếu nhiều người dùng mở cùng một liên kết sâu trên các máy tính khác nhau, họ sẽ thấy cùng một trò chơi đang chạy và thậm chí có thể tham gia trò chơi đó.Hơn nữa, trạng thái trò chơi được lưu trữ trong bộ lưu trữ đám mây. Điều này cho phép người dùng tiếp tục chơi bất cứ lúc nào trên bất kỳ thiết bị nào khác.
7. Chia tỷ lệ theo chiều ngang
Giống như bất kỳ SAAS nào hiện nay, trò chơi trên đám mây phải được thiết kế để có thể mở rộng theo chiều ngang. Thiết kế điều phối viên-công nhân cho phép bạn thêm nhiều công nhân hơn để phục vụ nhiều lưu lượng truy cập hơn.8. Không có kết nối với một đám mây
Cơ sở hạ tầng của CloudRetro được lưu trữ trên các nhà cung cấp đám mây khác nhau (Digital Ocean, Alibaba, nhà cung cấp tùy chỉnh) cho các khu vực khác nhau. Tôi cho phép chạy trong bộ chứa Docker cho cơ sở hạ tầng và định cấu hình cài đặt mạng bằng tập lệnh bash để tránh bị khóa vào một nhà cung cấp đám mây duy nhất. Bằng cách kết hợp điều này với NAT Traversal trong WebRTC, chúng tôi có thể linh hoạt triển khai CloudRetro trên mọi nền tảng đám mây và thậm chí trên bất kỳ máy nào của người dùng.Thiết kế kiến trúc
Công nhân: (hoặc máy chủ phát trực tuyến được đề cập ở trên) nhân rộng các trò chơi, chạy quy trình mã hóa và truyền phát phương tiện được mã hóa đến người dùng. Các phiên bản Worker được phân phối trên toàn thế giới và mỗi Worker có thể xử lý nhiều phiên người dùng cùng một lúc.
Điều phối viên: chịu trách nhiệm ghép nối người dùng mới với nhân viên phù hợp nhất để phát trực tuyến. Điều phối viên tương tác với công nhân thông qua WebSocket.
Lưu trữ trạng thái trò chơi: lưu trữ từ xa trung tâm cho tất cả các trạng thái trò chơi. Bộ lưu trữ này cung cấp các chức năng quan trọng như lưu/tải từ xa.
Kiến trúc cấp cao nhất của CloudRetroTập lệnh tùy chỉnh
Khi người dùng mới mở CloudRetro ở bước 1 và 2 được hiển thị trong hình bên dưới, điều phối viên cùng với danh sách nhân viên có sẵn sẽ được yêu cầu chuyển đến trang đầu tiên. Sau đó, ở bước 3, máy khách sẽ tính toán độ trễ cho tất cả các ứng viên bằng cách sử dụng yêu cầu ping HTTP. Danh sách sự chậm trễ này sau đó sẽ được gửi lại cho điều phối viên để anh ta có thể xác định nhân viên phù hợp nhất để phục vụ người dùng. Bước 4 bên dưới tạo trò chơi. Kết nối phát trực tuyến WebRTC được thiết lập giữa người dùng và nhân viên được chỉ định.
Tập lệnh người dùng sau khi có được quyền truy cậpCó gì bên trong công nhân
Các đường dẫn trò chơi và phát trực tuyến được lưu trữ riêng biệt bên trong nhân viên và trao đổi thông tin ở đó thông qua giao diện. Hiện tại, việc giao tiếp này được thực hiện bằng cách truyền dữ liệu trong bộ nhớ thông qua trong cùng một quá trình. Mục tiêu tiếp theo là sự phân biệt, tức là. khởi động trò chơi độc lập trong một quá trình khác.
Tương tác của các thành phần công nhânCác thành phần chính:
- WebRTC: một thành phần máy khách chấp nhận đầu vào và đầu ra của người dùng được mã hóa từ máy chủ.
- Trình giả lập trò chơi: thành phần trò chơi. Nhờ thư viện Libretro, hệ thống có thể chạy trò chơi trong cùng một quy trình và chặn nội bộ phương tiện cũng như luồng đầu vào.
- Các khung hình trong trò chơi được ghi lại và gửi đến bộ mã hóa.
- Bộ mã hóa hình ảnh/âm thanh: một đường dẫn mã hóa lấy các khung phương tiện, mã hóa chúng ở chế độ nền và xuất ra hình ảnh/âm thanh được mã hóa.
Thực hiện
CloudRetro dựa vào WebRTC làm công nghệ xương sống, vì vậy trước khi đi sâu vào chi tiết về cách triển khai Golang, tôi quyết định nói về chính WebRTC. Đây là công nghệ tuyệt vời đã giúp tôi rất nhiều trong việc đạt được độ trễ dưới giây khi truyền dữ liệu trực tuyến.
WebRTC
WebRTC được thiết kế để cung cấp kết nối ngang hàng chất lượng cao trên các ứng dụng di động gốc và trình duyệt bằng cách sử dụng các API đơn giản.
Truyền tải NAT
WebRTC được biết đến với chức năng NAT Traversal. WebRTC được thiết kế để giao tiếp ngang hàng. Mục tiêu của nó là tìm ra con đường trực tiếp phù hợp nhất, tránh các cổng NAT và tường lửa để liên lạc ngang hàng thông qua một quá trình gọi là . Là một phần của quy trình này, API WebRTC tìm địa chỉ IP công cộng của bạn bằng máy chủ STUN và chuyển tiếp địa chỉ đó đến máy chủ chuyển tiếp () khi không thể thiết lập kết nối trực tiếp.
Tuy nhiên CloudRetro chưa khai thác triệt để tính năng này. Các kết nối ngang hàng của nó không tồn tại giữa những người dùng mà giữa những người dùng và máy chủ đám mây. Phía máy chủ của mô hình có ít hạn chế liên lạc trực tiếp hơn so với thiết bị người dùng thông thường. Điều này cho phép bạn mở trước các cổng đến hoặc sử dụng trực tiếp các địa chỉ IP công cộng vì máy chủ không nằm sau NAT.
Trước đây, tôi muốn biến dự án thành nền tảng phân phối trò chơi cho Cloud Gaming. Ý tưởng là cho phép người sáng tạo trò chơi cung cấp trò chơi và tài nguyên phát trực tuyến. Và người dùng sẽ tương tác trực tiếp với các nhà cung cấp. Theo cách phi tập trung này, CloudRetro chỉ là một khuôn khổ để kết nối các tài nguyên phát trực tuyến của bên thứ ba với người dùng, giúp nó có khả năng mở rộng cao hơn khi không còn được lưu trữ nữa. Vai trò của WebRTC NAT Traversal ở đây rất quan trọng trong việc hỗ trợ khởi tạo kết nối ngang hàng trên các tài nguyên phát trực tuyến của bên thứ ba, giúp người tạo kết nối với mạng dễ dàng hơn.
Nén video
Nén video là một phần không thể thiếu của đường ống và góp phần rất lớn vào sự trôi chảy. Mặc dù không cần thiết phải biết mọi chi tiết về mã hóa video VP8/H264 nhưng việc hiểu các khái niệm này có thể giúp bạn hiểu các tùy chọn tốc độ phát trực tuyến video, gỡ lỗi hành vi không mong muốn và điều chỉnh độ trễ.
Việc nén video cho dịch vụ phát trực tuyến là một thách thức vì thuật toán phải đảm bảo tổng thời gian mã hóa + thời gian truyền mạng + thời gian giải mã càng thấp càng tốt. Ngoài ra, quá trình mã hóa phải nhất quán và liên tục. Một số cân bằng mã hóa không được áp dụng—ví dụ: chúng tôi không thể ưu tiên thời gian mã hóa dài hơn kích thước tệp và thời gian giải mã nhỏ hơn hoặc sử dụng tính năng nén không nhất quán.
Ý tưởng đằng sau việc nén video là loại bỏ các bit thông tin không cần thiết trong khi vẫn duy trì mức độ chính xác có thể chấp nhận được cho người dùng. Ngoài việc mã hóa các khung hình ảnh tĩnh riêng lẻ, thuật toán còn phỏng đoán khung hình hiện tại từ khung hình trước đó và khung hình tiếp theo, do đó chỉ có sự khác biệt của chúng được gửi đi. Như có thể thấy từ ví dụ với Pacman, chỉ có các điểm khác biệt được truyền đi.
So sánh các khung hình video sử dụng Pacman làm ví dụnén âm thanh
Tương tự như vậy, thuật toán nén âm thanh sẽ loại bỏ những dữ liệu mà con người không thể cảm nhận được. Opus hiện là codec âm thanh hoạt động tốt nhất. Nó được thiết kế để truyền sóng âm thanh qua giao thức datagram có thứ tự như RTP (Giao thức truyền tải thời gian thực). Độ trễ của nó thấp hơn mp3 và aac và chất lượng cao hơn. Độ trễ thường vào khoảng 5~66,5ms.
Pion, WebRTC ở Golang
là một dự án nguồn mở mang WebRTC đến Golang. Thay vì gói các thư viện WebRTC C++ gốc thông thường, Pion là một triển khai WebRTC gốc của Golang với hiệu suất tốt hơn, tích hợp Go và kiểm soát phiên bản trên các giao thức WebRTC.
Thư viện cũng cho phép phát trực tuyến với nhiều tính năng tích hợp tuyệt vời với độ trễ dưới giây. Nó có triển khai STUN, DTLS, SCTP riêng, v.v. và một số thử nghiệm với QUIC và WebAssugging. Bản thân thư viện nguồn mở này đã là một tài nguyên học tập thực sự tốt với tài liệu xuất sắc, cách triển khai giao thức mạng và các ví dụ thú vị.
Cộng đồng Pion, được lãnh đạo bởi một người sáng tạo rất nhiệt huyết, khá sôi nổi với nhiều cuộc thảo luận chất lượng đang diễn ra về WebRTC. Nếu bạn quan tâm đến công nghệ này, hãy tham gia - bạn sẽ học được rất nhiều điều mới.
Viết CloudRetro ở Golang
Triển khai một công nhân trong GoĐi kênh đang hoạt động
Nhờ thiết kế kênh đẹp mắt của Go, các vấn đề về phát trực tuyến sự kiện và đồng thời được đơn giản hóa rất nhiều. Như trong sơ đồ, các GoRoutine khác nhau có nhiều thành phần chạy song song. Mỗi thành phần quản lý trạng thái của nó và giao tiếp thông qua các kênh. Khẳng định có chọn lọc của Golang buộc một sự kiện nguyên tử phải được xử lý mỗi lần trong trò chơi (đánh dấu trò chơi). Điều này có nghĩa là không cần khóa cho thiết kế này. Ví dụ: khi người dùng lưu, cần có ảnh chụp nhanh đầy đủ về trạng thái trò chơi. Trạng thái này phải được duy trì liên tục, đăng nhập cho đến khi quá trình lưu hoàn tất. Trong mỗi lần đánh dấu trò chơi, phần phụ trợ chỉ có thể xử lý thao tác lưu hoặc nhập, giúp chuỗi quy trình trở nên an toàn.
func (e *gameEmulator) gameUpdate() { for { select { case <-e.saveOperation: e.saveGameState() case key := <-e.input: e.updateGameState(key) case <-e.done: e.close() return } } }Fan-in/Fan-out
Mẫu Golang này hoàn toàn phù hợp với trường hợp sử dụng CrowdPlay và Nhiều người chơi của tôi. Theo mẫu này, tất cả đầu vào của người dùng trong một phòng đều được tích hợp vào kênh vào trung tâm. Phương tiện trò chơi sau đó được triển khai cho tất cả người dùng trong cùng một phòng. Bằng cách này, chúng tôi đạt được sự phân chia trạng thái trò chơi giữa một số phiên trò chơi của những người dùng khác nhau.
Đồng bộ hóa giữa các phiên khác nhauNhược điểm của Golang
Golang không hoàn hảo. Kênh chậm. So với việc chặn, kênh Go đơn giản là một cách dễ dàng hơn để xử lý các sự kiện đồng thời và theo luồng, nhưng kênh không mang lại hiệu suất tốt nhất. Có logic chặn phức tạp bên dưới kênh. Vì vậy, tôi đã thực hiện một số điều chỉnh trong quá trình triển khai, áp dụng lại các khóa và giá trị nguyên tử khi thay thế các kênh để tối ưu hóa hiệu suất.
Ngoài ra, trình thu gom rác ở Golang không được quản lý, điều này đôi khi gây ra tình trạng tạm dừng kéo dài đáng ngờ. Điều này gây trở ngại lớn cho ứng dụng phát trực tuyến theo thời gian thực.
RĂNG CƯA
Dự án sử dụng thư viện Golang VP8/H264 mã nguồn mở hiện có để nén phương tiện và Libretro cho trình giả lập trò chơi. Tất cả các thư viện này chỉ đơn giản là các trình bao bọc của thư viện C trong Go bằng cách sử dụng . Một số nhược điểm được liệt kê trong . Những vấn đề tôi gặp phải:
- không thể khắc phục sự cố trong CGO, ngay cả với Golang RecoveryCrash;
- không xác định được các tắc nghẽn về hiệu suất khi chúng tôi không thể phát hiện các vấn đề chi tiết trong CGO.
Kết luận
Tôi đã đạt được mục tiêu là hiểu rõ các dịch vụ trò chơi trên đám mây và tạo ra một nền tảng giúp tôi chơi các trò chơi cổ điển hoài cổ với bạn bè trực tuyến. Dự án này sẽ không thể thực hiện được nếu không có thư viện Pion và sự hỗ trợ của cộng đồng Pion. Tôi vô cùng biết ơn sự phát triển sâu rộng của nó. Các API đơn giản do WebRTC và Pion cung cấp đảm bảo khả năng tích hợp liền mạch. Bằng chứng đầu tiên về khái niệm của tôi đã được công bố cùng tuần đó, mặc dù trước đó tôi không có kiến thức gì về giao tiếp ngang hàng (P2P).
Mặc dù dễ tích hợp nhưng phát trực tuyến P2P thực sự là một lĩnh vực rất phức tạp trong khoa học máy tính. Cô phải giải quyết sự phức tạp của các kiến trúc mạng lâu đời như IP và NAT để tạo ra phiên ngang hàng. Trong khi thực hiện dự án này, tôi đã thu được nhiều kiến thức quý giá về tối ưu hóa hiệu suất và mạng, vì vậy tôi khuyến khích mọi người thử xây dựng các sản phẩm P2P bằng WebRTC.
CloudRetro đáp ứng tất cả các trường hợp sử dụng mà tôi mong đợi từ quan điểm của tôi với tư cách là một game thủ cổ điển. Tuy nhiên, tôi nghĩ có nhiều lĩnh vực trong dự án mà tôi có thể cải thiện, chẳng hạn như làm cho mạng trở nên đáng tin cậy và hoạt động hiệu quả hơn, cung cấp đồ họa trò chơi chất lượng cao hơn hoặc khả năng chia sẻ trò chơi giữa những người dùng. Tôi đang làm việc chăm chỉ về việc này. Hãy theo dõi và ủng hộ nó nếu bạn thích nó.
Nguồn: www.habr.com