thảo luận Lập trình game online

tulanhvip said:
Rất may là con godot này support headless build đấy thím. Em đang phân vân giả sử game có nhiều room thì logic tạo room tương tác với database lại phải code riêng à? Mỗi bàn lại tạo khởi chạy 1 cái process à?
Thím làm rồi thì xử lý như nào?


via theNEXTvoz for iPhone
Click to expand...
Hồi ấy bọn mình làm thế này:
  • Một server database: cái này kế thừa tự các dự án cũ, viết bằng ASP .NET để chạy trên hệ thống của cty. Lưu thông tin về user và chạy luôn game server. Riêng dự án đó dùng Photon API nên bọn mình tích hợp luôn cả Photon server vào nữa.
  • Game server: headless build dùng làm authoritative server, khi nào client request lên thì tạo process mới.

Có mấy vấn đề như này:
  • Headless build bọn mình làm rất sơ khai, chỉ là một branch xoá hết art assets thôi. Tại ban đầu làm mình còn không biết tới thuật ngữ authoritative server, sau bới ra làm thì sót chỗ này chỗ kia không kiểm soát được.
  • Memory cũng tốn, chạy 5 game server là máy server quá tải. Cũng công nhận là server yếu nữa.
  • DB server vốn đc thiết kế để xử lý các request non real time và chịu tải kém, khi bọn mở thêm thì gặp vấn đề load balancing. Chắc ai chuyên backend sẽ xử lý tốt còn mình khi ấy thì bó tay hoàn toàn.
 
Thớt hay đó cơ mà thím ôm hết cả đống thật á. E cũng muốn dev web service. Khổ nỗi đi làm kinh qua java, python, c# và e ưng đc mỗi c# giờ đang học thêm dotnet core mới nhất để làm đc đủ full BE. Note lại để chờ xin keywork của thím làm dần.
 
tao_la_giang said:
Hồi ấy bọn mình làm thế này:
  • Một server database: cái này kế thừa tự các dự án cũ, viết bằng ASP .NET để chạy trên hệ thống của cty. Lưu thông tin về user và chạy luôn game server. Riêng dự án đó dùng Photon API nên bọn mình tích hợp luôn cả Photon server vào nữa.
  • Game server: headless build dùng làm authoritative server, khi nào client request lên thì tạo process mới.

Có mấy vấn đề như này:
  • Headless build bọn mình làm rất sơ khai, chỉ là một branch xoá hết art assets thôi. Tại ban đầu làm mình còn không biết tới thuật ngữ authoritative server, sau bới ra làm thì sót chỗ này chỗ kia không kiểm soát được.
  • Memory cũng tốn, chạy 5 game server là máy server quá tải. Cũng công nhận là server yếu nữa.
  • DB server vốn đc thiết kế để xử lý các request non real time và chịu tải kém, khi bọn mở thêm thì gặp vấn đề load balancing. Chắc ai chuyên backend sẽ xử lý tốt còn mình khi ấy thì bó tay hoàn toàn.
Click to expand...
yeah, như vậy là sẽ code để có thể tạo nhiều process của cái headless. Em dự định dùng nakama để làm khoảng manage server này. Cuối tuần sẽ test thử xem sao.
 
colenao00 said:
Thớt hay đó cơ mà thím ôm hết cả đống thật á. E cũng muốn dev web service. Khổ nỗi đi làm kinh qua java, python, c# và e ưng đc mỗi c# giờ đang học thêm dotnet core mới nhất để làm đc đủ full BE. Note lại để chờ xin keywork của thím làm dần.
Click to expand...
cứ làm rồi thiếu đến đâu thì vọc đến đó thôi thím, còn đợi master hết mới bắt đầu làm thì già cmnr =)
 
Chia sẻ vs các thím 1 video khá hay, trước em có tìm hiểu về cách implement physic cho server game dạng authoritative. Video này cũng nói qua về 3 kỹ thuật có lẽ là phổ biến:

- Derterministic Lockstep (Chỉ gửi và nhận input của client, các client khác nhận được input từ server sẽ tái tạo lại hành vi của đối tượng, kiểu như 2 hay nhiều hơn 2 người chơi cùng 1 máy vậy. Cách này theo em hiểu thì sẽ tối ưu băng thông, nhưng nhược điểm là dễ bị hack - do server khó làm phần xác thực hành động của client. Làm theo cách này thì cũng phải đồng bộ được phần xung nhịp trên các thiết bị, em có nghe bạn em nói vậy, và còn phải xử lí được phần quay lui nếu có xảy ra lỗi)

- Snapshot Interpolation (Cách này thì là server sẽ ở dạng xác thực, client đóng vai trò là view hiển thị thông tin từ server. Cách này cũng giúp tối ưu băng thông, tin nhắn gửi từ server xuống client sẽ không quá nhiều, có thể chỉ ở 20 lần gửi trong 60 giây - snapshot. Lúc đó ở đó ở dưới client sẽ phải tự implement các kĩ thuật nội suy, ngoại suy để tái tạo lại chuyển động, vị trí của đối tượng)

- State Synchronization (Cách này là đồng bộ trạng thái giữa các client thông qua server. Theo em hiểu thì nó cũng là dạng server xác thực, nhưng chưa có tìm hiểu sâu)

 
Last edited:
Em thì đang muốn implement theo dạng authoritative server. Vậy nên ý tưởng của em cho việc cài đặt giao tiếp client - server với game MMORPG như sau, có gì các thím góp ý nhé:

1 client khi kết nối tới server, sẽ cần 3 connections:
  • Chat (TCP): Dùng cho việc chat, nhận thông báo, trao đổi giữa người chơi và game master
  • Action (TCP): Các lệnh trong game của người chơi. VD như đánh, tung skill, nhảy, ...
  • Move (UDP): Cập nhật vị trí các đối tượng trong màn chơi

Lý do:
  • Kênh chat nên được độc lập, vì khi có sự cố xảy ra với 2 kênh kia, thì người chơi vẫn có thể nhận biết được thông tin và hướng dẫn từ game master, hoặc trao đổi với nhau. Và cái này cần phải đảm bảo nên dùng TCP.
  • Kênh action dùng TCP để đảm bảo truyền nhận, action người chơi dùng với tần suất coi là thấp so với việc di chuyển, chạy loăng quăng trong game.
  • Kênh move này là kênh trao đổi thông tin nhiều nhất, người chơi di chuyển liên tục. Ở đây dùng UDP để có lợi thế tốc độ, nhưng phần xử lí client lại nhọc, do phải biết cách sắp xếp lại gói tin, xử lí gói tin quan trọng bị mất, nội, ngoại suy. Nếu em không nhầm thì nó sinh ra cái thứ gọi là RUDP để khắc phục vấn đề này: https://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol
Thím nào biết thì chỉ giáo thêm nhé. Thanks.
 
HeoRungDiNang said:
Em thì đang muốn implement theo dạng authoritative server. Vậy nên ý tưởng của em cho việc cài đặt giao tiếp client - server với game MMORPG như sau, có gì các thím góp ý nhé:

1 client khi kết nối tới server, sẽ cần 3 connections:
  • Chat (TCP): Dùng cho việc chat, nhận thông báo, trao đổi giữa người chơi và game master
  • Action (TCP): Các lệnh trong game của người chơi. VD như đánh, tung skill, nhảy, ...
  • Move (UDP): Cập nhật vị trí các đối tượng trong màn chơi

Lý do:
  • Kênh chat nên được độc lập, vì khi có sự cố xảy ra với 2 kênh kia, thì người chơi vẫn có thể nhận biết được thông tin và hướng dẫn từ game master, hoặc trao đổi với nhau. Và cái này cần phải đảm bảo nên dùng TCP.
  • Kênh action dùng TCP để đảm bảo truyền nhận, action người chơi dùng với tần suất coi là thấp so với việc di chuyển, chạy loăng quăng trong game.
  • Kênh move này là kênh trao đổi thông tin nhiều nhất, người chơi di chuyển liên tục. Ở đây dùng UDP để có lợi thế tốc độ, nhưng phần xử lí client lại nhọc, do phải biết cách sắp xếp lại gói tin, xử lí gói tin quan trọng bị mất, nội, ngoại suy. Nếu em không nhầm thì nó sinh ra cái thứ gọi là RUDP để khắc phục vấn đề này: https://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol
Thím nào biết thì chỉ giáo thêm nhé. Thanks.
Click to expand...
Mình dự định những cái liên quan đến authentication, user data, avatar, chatting các thứ là con server riêng. Còn server cho việc realtime là riêng biệt.

via theNEXTvoz for iPhone
 
tulanhvip said:
Mình dự định những cái liên quan đến authentication, user data, avatar, chatting các thứ là con server riêng. Còn server cho việc realtime là riêng biệt.

via theNEXTvoz for iPhone
Click to expand...
Vậy thím tách ra thành các services. Coi qua cái project của em xem có dùng được phần nào không nhé.
 
HeoRungDiNang said:
Em thì đang muốn implement theo dạng authoritative server. Vậy nên ý tưởng của em cho việc cài đặt giao tiếp client - server với game MMORPG như sau, có gì các thím góp ý nhé:

1 client khi kết nối tới server, sẽ cần 3 connections:
  • Chat (TCP): Dùng cho việc chat, nhận thông báo, trao đổi giữa người chơi và game master
  • Action (TCP): Các lệnh trong game của người chơi. VD như đánh, tung skill, nhảy, ...
  • Move (UDP): Cập nhật vị trí các đối tượng trong màn chơi
Click to expand...
Mình nghĩ có 2 vde này thím sẽ gặp khá nhiều khó khăn:
1. Sync action và moving.
2. UDP. Trừ khi thím xử lý cực tốt việc messages lost (cái này đòi hỏi nhiều kinh nghiệm, xử lý message priority, client prediction, compensation, và phụ thuộc vào thể loại game, game logic nữa chứ ko hẳn thuần kỹ thuật), còn không thì nên chơi TCP cho lành.
 
Cái core server và client nôm na là core engine. Còn engine chịu phần text, render, physic....

source c++ khá nhiều. Biết làm là dc.
nhưng sợ sức người làm ko nổi, vì cái server và client code lúc nào cũng cả team, chứ ko phải 1 2 người.

sau khi làm core engine xong, có engine đã hoàn thiện rồi thì mới viết game logic, là phần game server và giao tiếp giữa các server với nhau, như master server, login server, gate server, game server, world server.... dựa trên core engine đã có sẵn.
nói chung rất căng, khó mà 1 mình hoàn thiện từ đầu dc. Chưa kể art, bug, animation, ....

hiện tại unity có thằng atavism bán, source client, server cho unity Và sắp có cho unreal.

server viết bằng java, client unity c#.

còn nếu tích hợp vài source code đã có bao gồm core client/core server và đang code server. Thì sau migrate với unity cũng được. Đòi hỏi phải biết rành về network. Để viết đọc, ghi dữ liệu của server trả về. Nói chung là giao tiếp giữa client unity và server c++.
vì hiện tại chỉ có unity unreal mới hỗ trợ đa nền tảng, còn nếu chỉ pc, thì chơi engine riêng.
 
Last edited:
buonnguqua said:
5 tháng trôi qua.Ông thớt nghiên cứu đến đâu rồi
Click to expand...
Mới đó đã 5 tháng rồi ư. ;(( do dịch bệnh ảnh hưởng quá nhiều đến cuộc sống cơm áo gạo tiền thím ạ. Em gác lại đam mê để lo miếng cơm rồi. Hiện tại đang làm golang nuxtjs cho dự án cũng khá bự. Vẫn hy vọng có thời gian để hoàn thành mục tiêu của thread này

via theNEXTvoz for iPhone
 

Similar threads

G
kiến thức Hoàng Hậu Cát Tường Mod kim cương HHCT 2024
Replies
0
Views
124
gevgej
G
haiduhaidu
thảo luận Tiếp cận các mảng MMO cho người mới
4 5 6
Replies
108
Views
5K
haiduhaidu
haiduhaidu
Song Nguyen
thảo luận Game Triều Đại Tây Sơn
2 3 4
Replies
71
Views
6K
Song Nguyen
Song Nguyen
L
kiến thức Game đào coin miễn phí
2
Replies
27
Views
1K
langthang003
L
Anhlucky9x
kiến thức Hướng dẫn chơi game và kiếm lợi nhuận với Pixels update T11-2023
Replies
3
Views
2K
Shouko_Top_Fan
Shouko_Top_Fan

Share this page

Back
Top