@MeoDenLuoi mình ko rành như bạn nghĩ đâu chẳng qua mình muốn thử làm online nhưng giờ mình thấy nó rất phức tạp, phải khó gấp 10 lần offline liên quan đến speed truyền nên nó có rất nhiều sai sót bởi vậy cái game kia của mình vẫn để đó h phải chuyển qua cái game off đơn giản. @Focker_C ok bạn làm đi mình ủng hộ ^^
Hệ thống Online : Hệ thống này hoạt động theo TCP/IP. Tức là một người tạo host và người kia sẽ tham gia vào qua IP của host.
Internet Protocal thôi. Còn muốn làm real-tile game thì phải kết hợp giữa TCP và UDP, mà UDP là protocal chính cho phần gameplay. TCP chỉ cho mấy cái phải đảm bảo tránh loss packet ví dụ chat, trading. Khi được chọn giữa TCP và UDP để làm real time game thì chả developer nào chọn TCP đâu.
Làm chơi LAN với nhau thì còn có lẽ làm được, chứ còn muốn chơi qua Internet thì 99.9% dự án này drop rồi, mình xin lỗi vì nói xui nhưng thật vậy. T_T Không có ý gì ngoài việc là muốn nói bạn trong thời gian hiện tại, lúc này chưa hiểu bản thân cần phải làm gì và sẽ đối mặt với những thứ gì đâu. Đảm bảo security, xử lý latency và nếu bạn nghĩ 2 cái này thật đơn giản thì bạn đã sai lầm rất lớn rồi, kể cả bỏ security thì xử lý latency trong real-time game thôi cũng đủ để 1 lập trình viên có kinh nghiệm về game và networking chết lên chết xuống. Đâu phải chỉ mới cách đây không lâu mới xuất hiện mmorpg non-target đâu và đâu phải Mapple Story không có hệ thống PVP do người phát triển họ không muốn cho vào, do giới hạn kĩ thuật cả đấy. stick
Đừng bảo làm online khó hơn 10 lần offline, qua phần networking trong game online nhất là mô hình server - clients nó trở thành 1 thứ hoàn toàn khác so với lúc làm game offline, nhất là khi làm real-time game và độ khó sẽ tăng theo cấp số nhân. Bạn phải trở thành 1 người lập trình game có kĩ năng tốt, là 1 nhà bảo mật tự tin với khả năng của mình và là 1 nhà ảo thuật, thậm chí là 1 nhà tâm lý học có máu mặt. Người ta thường nói làm real-time multiplayer online game chủ yếu là tạo ra những ảo ảnh giúp che đậy latency khỏi mắt người chơi và cho họ thấy cái họ muốn thấy (dĩ nhiên thực tế diễn ra không giống cái người chơi thấy). Căn bản hơn nữa là bạn phải tối ưu client-side hết mức có thể để khi 1 message gửi đi nó phải gửi đi nhiều thông tin nhất vì thường thì header trong mỗi message có khi còn nặng hơn những thông tin bạn cần gửi đi, gửi nhiều message 1 cách không cần thiết là NO-NO.
Nhìn chung thì turn-based dễ hơn real-time nhiều do đỡ thằng latency, ngoài ra quá trình gửi và nhận message cũng rõ ràng hơn rất nhiều để bạn có thể đảm bảo phần security và tối ưu hệ thống mạng. Vậy nên mình có lời khuyên là bắt đầu với turn-based game dễ như tic-tac-toe đã rồi hẵng qua real-time, và để bắt đầu bạn phải tìm hiểu thêm những kiến thức sau:
1. Xem lại cách thức mà bạn làm game nào giờ, sắp xếp làm sao để mỗi 1 message gửi đi chứa được nhiều thông tin nhất.
2. Xem lại 2 thằng TCP và UDP, xem 2 thằng này có những ưu khuyết điểm nào và do đó mỗi thẳng sẽ đảm nhận trách nhiệm nào trong việc thiết kế MO game.
3. Học kĩ về Network Architectures.
4. Hiểu về Security và đảm bảo nó ở mức đủ trong game.
5. Tìm hiểu kĩ về Synchronization trong MO game. Không ít người sẽ bỏ giấc mộng không làm real-time MMO nữa khi đến phần này.
6. Tìm hiểu kĩ về Interpolation trong MO game và cố chịu đựng những cơn đau đầu. Sẽ có 3 khái niệm cơ bản giúp bạn trở thành 1 ảo thuật gia đó là deception, extrapolation và prediction. 3 thằng này sẽ giúp bạn cho người chơi thấy "cái ảo ảnh mà họ muốn thấy". (Làm turn-based game có thể bỏ phần này). Nhiều người sẽ bỏ giấc mộng không làm real-time MMO nữa khi đến phần này.
7. Nối tiếp và để kết thúc phần trên là có 1 cái nhìn tổng quát về Latency và đi sâu vào nó "thêm 1 tí". (Làm turn-based game có thể bỏ phần này). Đa số mọi người sẽ bỏ giấc mộng không làm real-time MMO nữa khi đến phần này.
Và kể cả bạn đã đi hết cả 7 phần trên thì mình vẫn không nghĩ bạn có thể hoàn thành được cái dự án ở #1 đâu, nhưng khi ấy bạn sẽ hiểu vì sao và chọn cho bản thân cái gì đó phù hơp hơn.
Hệ thống Online : Hệ thống này hoạt động theo TCP/IP. Tức là một người tạo host và người kia sẽ tham gia vào qua IP của host.
Với phương thức này, game sẽ cho phép 2 người chơi tỉ thí với nhau. Đây chính xác và đỉnh cao "Tranh Hùng" của Việt Võ. Cũng là lý do đặt tên cho game. Lưu ý một điều rằng khả năng PK và cách build mới là yếu tố quyết định thắng thua. Người chơi nào chơi nhiều hoặc chơi trước ko có gì lợi thế hơn ngoài kinh nghiệm điều khiển nhân vật. Người chơi mới , chưa làm nhiều nhiệm vụ thì chỉ ko có nhiều trang bị và skill để build chứ chỉ số không có gì thua kém. Qua đây, tác giả muốn thể hiện một điều : người Việt từ xa xưa đã có định nghĩa Fair Play ^^
Với hệ thông online này, 2 người chơi còn có thể giao dịch với nhau những item trang bị, vũ khí hoặc những item yêu cầu của nhiệm vụ. Qua đây hình thành nên việc farm quái, kiếm đồ, bán cho người chơi khác để kiếm tiền rồi lại mua trang bị phù hợp với mình. Việc farm quái sẽ không còn quá nhàm chán như Maple Story hay Ghost Online.
Một điều nữa là người chơi có thể mua hàng xịn qua admin bằng tiền thật. Admin tạo host để giao dịch , chuyển hàng.
vậy thông số nhân vật được save ở client à nếu vậy thì việc trao đổi mua bán item không khả quan lắm.
Đừng bảo làm online khó hơn 10 lần offline, qua phần networking trong game online nhất là mô hình server - clients nó trở thành 1 thứ hoàn toàn khác so với lúc làm game offline, nhất là khi làm real-time game và độ khó sẽ tăng theo cấp số nhân. Bạn phải trở thành 1 người lập trình game có kĩ năng tốt, là 1 nhà bảo mật tự tin với khả năng của mình và là 1 nhà ảo thuật, thậm chí là 1 nhà tâm lý học có máu mặt. Người ta thường nói làm real-time multiplayer online game chủ yếu là tạo ra những ảo ảnh giúp che đậy latency khỏi mắt người chơi và cho họ thấy cái họ muốn thấy (dĩ nhiên thực tế diễn ra không giống cái người chơi thấy). Căn bản hơn nữa là bạn phải tối ưu client-side hết mức có thể để khi 1 message gửi đi nó phải gửi đi nhiều thông tin nhất vì thường thì header trong mỗi message có khi còn nặng hơn những thông tin bạn cần gửi đi, gửi nhiều message 1 cách không cần thiết là NO-NO.
Nhìn chung thì turn-based dễ hơn real-time nhiều do đỡ thằng latency, ngoài ra quá trình gửi và nhận message cũng rõ ràng hơn rất nhiều để bạn có thể đảm bảo phần security và tối ưu hệ thống mạng.
Khó là đối với em, đang off mà chuyển sang onl thì nó thay đổi hoàn toàn nó quá khác biệt. Turn-base dễ hơn bởi vì nó có đủ thời gian để truyền thì phải, mới đầu em định làm turn-base nhưng ở GM off thì code cực hơn real-time.
Mình thực ra mới chỉ biết làm theo kiểu turn-based massage. Và cứ ngỡ rằng nó có thể làm real-time game ^^
Ko đc ak ?
Đơn cử như cái game Ping-pong đó mà. Vẫn làm đc đấy thôi ?
Phần online mình rất còn hạn chế. Và cũng chưa làm lần nào hết.
Khả năng drop thì mình tự nhận định là rất cao rồi. Nhưng mình đâu hứa hẹn là hoàn thành đâu.
Làm để trải nghiệm - làm để giao lưu - làm để trưởng thành !
^^
Lâu mới thấy ông này xuất hiện ^^
Mà xin có 1 lưu ý nho nhỏ thế này ^^
Game này hoàn toàn ko phải MMORPG. Data của người chơi hoàn toàn vẫn ở trên máy. Hoàn toàn ko có hệ thống truy nhập gì hết. Còn phần online thì hoạt động như kiểu Little Fighter 2 mà thôi ^^
Một game như little fighter làm đc online như vầy. Mình cũng có thêm hy vọng phần nào ^^
Nãy cũng nghĩ bạn tính làm Client - Client nhưng đọc sơ post 1 thấy giống 1 mmo quá. Làm multiplayer online nó khó lên theo cấp số nhân, nên ping pong là 1 chuyện mà thêm thắt vào tí là phần networking nó đi xa cả cây số rồi. Ví dụ giờ 2 người chơi có framerate khác nhau thì bạn tính làm sao để đồng bộ hóa 2 bên và làm mượt game? Bên fps thấp thì họ tự chịu khi chất lượng gameplay kém rồi nhưng kéo theo cả bên fps cao xuống là không hay. Dĩ nhiên cái vấn đề fps khác nhau này chỉ là ví dụ điển hình và không phải khó để giải quyết, vấn đề là từ đây còn có nhiều cái khó khăn hơn nhiều. Mình nghĩ cứ 1 game turn-based đơn giản với mô hình client - client là được rồi. Game như Little Fighter 2 thì hạn chế latency là rất quan trọng, nếu không giải quyết nó thì game dù có playable nhưng vẫn sẽ xảy ra nhiều điều kì quặc khi chơi. Hiện tại bạn chưa nắm được cơ bản về 2 protocal UDP và TCP thì khoan vội làm gì, cứ từng bước mà học, TCP nó có latency cao hơn UDP rất nhiều. stick
Giờ nghĩ lại mới thấy thế ... haiz ...
Kiểu như đang PK mà cứ chậm dề dề ... Mình chơi LFighter2 và cũng gặp trường hợp này. Chơi online với thằng FPS thấp ức vãi cả chế ra.
Nhưng thôi, kệ ^^
LF2 nó cũng chỉ làm đc thế. Thì mình cũng thế thôi ^^
có 2 phướng án giải quyết :
1. Ko làm gì. Người FPS cao phải chịu thôi. PK mà, chậm thì quan sát càng dễ ^^
2. Có đòi hỏi yêu cầu máy. FPS thấp quá, không thể tham gia phần online ^^
Khó là đối với em, đang off mà chuyển sang onl thì nó thay đổi hoàn toàn nó quá khác biệt. Turn-base dễ hơn bởi vì nó có đủ thời gian để truyền thì phải, mới đầu em định làm turn-base nhưng ở GM off thì code cực hơn real-time.
Cứ từ từ mà học thôi bạn, đâu cần phải vội. Cứ làm những cái vừa phải với sức mình, đảm bảo hoàn thành để có tinh thần. Turn-based nó dễ hơn real-time vì đỡ sợ cái độ trễ, đơn giản hơn khi đồng bộ client và dễ dàng để quản lý hơn cho bảo mật cũng như tối ưu hệ thống mạng.
// @Focker_c:
Flash chỉ có thể dùng giao thức TCP nên bạn sẽ thấy đa số online multiplayer flash game là mô hình turn-based, real-time thì ít khi mang tính chất pvp, nếu có thì gameplay cũng rất chậm. Vậy nên bạn đừng dại chỉ dùng TCP mà làm real-time game, flash developers người ta muốn dùng UDP muốn chết mà không được dùng, bạn dùng được tội gì không dùng chứ.
// Cái wysiwyg editor mới của TTC củ chuối, xài khó chịu quá. +_+
có 2 phướng án giải quyết :
1. Ko làm gì. Người FPS cao phải chịu thôi. PK mà, chậm thì quan sát càng dễ ^^
2. Có đòi hỏi yêu cầu máy. FPS thấp quá, không thể tham gia phần online ^^
Không, không cái nào trong cả 2 cái này cả.
1. Game sẽ cực kì kì quặc, ko đơn giản như bạn nói đâu. Dễ dàng khiến game unplayable, cái này tự bạn làm tự trải nghiệm.
2. FPS không phải là giá trị cố định. Player đang chơi với fps cao tự nhiên có ai pm yahoo họ chẳng hạn, làm fps đột ngột xuống thấp.
Cách giải quyết: Chỉ có 1 cách là dùng elapsed time để đồng bộ hoạt động khi framerate khác nhau thôi. Bạn lấy thời gian thực khác biệt giữa frame trước và frame hiện tại khi update game và dùng nó để tính các giá trị như khoảng cách. Như vậy sẽ động bộ được thông tin của 2 bên kể cả khi fps khác biệt, chỉ có ai bị fps thấp mới bị lag còn người fps cao vẫn chơi bình thường.
Đừng hiểu lầm em. Ý em không phải nói khó để làm người chưa rành họ sợ mà không làm. Nhưng phải đi từng bước, cứ tà tà vừa làm vừa học lấy kinh nghiệm từng nấc 1 rồi cũng sẽ tới lúc đi lên tới nơi thôi. stick Còn vừa đi vừa nhảy té lộn cổ à.
1. UDP . Chưa có khái niệm về nó ^^
2. elapsed time để đồng bộ frame. Mình nghĩ chắc hẳn cái này được xài bởi đa phần các game. FPS kém thì lag còn thằng cao vẫn chạy như thường ^^
1. UDP và TCP thuộc lớp Internet Protocal, sử dụng IP làm địa chỉ truyền nhận các gói tin.
Trong đó TCP là giao thức dùng để đảm bảo gói tin đến được đích, khi packet đến được đích sẽ có reply thông báo từ receiver trả về cho sender. Trong trường hợp sender sau khi hết timeout mà không nhận được gói tin thông báo là việc truyền dữ liệu đã thành công thì nó sẽ gửi lại dữ liệu cho đến khi được thì thôi. Ghi chú là mọi hoạt động truyền nhận dữ liệu đến 1 receiver sẽ bị tạm hoãn trong thời gian chờ reply từ receiver đó, cũng như trong lúc gửi lại gói tin. => Header của mỗi gói tin gửi qua giao thức TCP nặng, thời gian truyền nhận dữ liệu lớn.
UDP thì không đảm bảo việc gói tin sẽ đến đích do đó không cần phải chờ reply từ receiver, không bị đình trệ việc truyền tải dữ liệu khi 1 lần gửi tin bị thất bại. => Header nhẹ và thời gian truyền nhận dữ liệu nhỏ.
Vậy nên bạn phải xem cái nào quan trọng cần đảm bảo đến được đích, lâu lâu mới gửi thì hẵng dùng TCP ví dụ như chat, trạng thái giao dịch của nhân vật. Những dữ liệu phải gửi đi liên tục và dù không tới nơi cũng không có hại gì mấy thì dùng UDP, ví dụ như tọa độ của nhân vật.
2. Elapsed time không dùng để đồng bộ frame, cách nói này là rất sai. Dùng elapsed time để tính toán là để đảm bảo đồng bộ giá trị thông tin trong thời gian thực (không phải đồng bộ framerate), như vậy dù frame rate khác nhau thì các giá trị nhận được tại 1 điểm trong thời gian thực vẫn sẽ được giữ cho bằng nhau.
Ví dụ:
var _et = previewTime - currentTime; //Tính khoảng cách thời gian thực giữa lần update liền trước và hiện tại. Tính bằng giây đi.
player.x = hSpeed * _et; // Cho hSpeed là 5 và tọa độ X hiện tại là 0 đi.
previewTime = currentTime;
+ Như vậy nếu fps của player thấp đến mức chỉ còn 2 thì _et sẽ là 0.5. Game update với tốc độ 2 lần trong 1 giây và tọa độ x của người chơi sau mỗi lần update sẽ tăng lên 2.5 và sau 1 giây trong thời gian thực thì tọa độ x của người chơi là 5.
+ Với 1 player khác có fps cao hơn là 10, vậy _et sẽ là 0.1. Game sẽ update 10 lần 1 giây và như vậy sau 1 giây thì x của người chơi cũng sẽ là 5, với mỗi lần update player.x tăng lên 1 giá trị là 0.5.
Ý 2 vẫn còn hơi bị mù ^^
Tức là như ở ví dụ ta sẽ nhân speed của nhân vật với hệ số cân bằng thời gian phải ko ?
Nhưng thực ra cách giải quyết của mình nó đại khái thế này :
có 1 thằng nhân vật. Nhưng 2 người chơi cùng nhìn vào.
thằng nhân vật này nó cứ chạy đều đều.
- máy có FPS cao sẽ nhìn là chạy đều đặn, mượt.
- máy có FPS thấp sẽ nhìn thấy thằng nhân vật vẫn xuất hiện đúng ở các tọa độ theo từng giây (hoặc từng 0.5 giây). Nhưng cái độ mượt về chạy sẽ ko được đảm bảo. Tức là sẽ nhìn theo kiểu giật giật ấy.
Lý do mình nói ra hướng này là do thấy rất nhiều game online như thế.
Thực ra cũng ko hiểu lắm. Chỉ biết biểu hiện của nó như vầy ^^
Mong bạn nói dùm
Comments
@Focker_C ok bạn làm đi mình ủng hộ ^^
Cái base game là platform mà. Với mình là 1 cái đó quá thân thuộc rồi
Internet Protocal thôi. Còn muốn làm real-tile game thì phải kết hợp giữa TCP và UDP, mà UDP là protocal chính cho phần gameplay. TCP chỉ cho mấy cái phải đảm bảo tránh loss packet ví dụ chat, trading. Khi được chọn giữa TCP và UDP để làm real time game thì chả developer nào chọn TCP đâu.
Làm chơi LAN với nhau thì còn có lẽ làm được, chứ còn muốn chơi qua Internet thì 99.9% dự án này drop rồi, mình xin lỗi vì nói xui nhưng thật vậy. T_T Không có ý gì ngoài việc là muốn nói bạn trong thời gian hiện tại, lúc này chưa hiểu bản thân cần phải làm gì và sẽ đối mặt với những thứ gì đâu. Đảm bảo security, xử lý latency và nếu bạn nghĩ 2 cái này thật đơn giản thì bạn đã sai lầm rất lớn rồi, kể cả bỏ security thì xử lý latency trong real-time game thôi cũng đủ để 1 lập trình viên có kinh nghiệm về game và networking chết lên chết xuống. Đâu phải chỉ mới cách đây không lâu mới xuất hiện mmorpg non-target đâu và đâu phải Mapple Story không có hệ thống PVP do người phát triển họ không muốn cho vào, do giới hạn kĩ thuật cả đấy. stick
Đừng bảo làm online khó hơn 10 lần offline, qua phần networking trong game online nhất là mô hình server - clients nó trở thành 1 thứ hoàn toàn khác so với lúc làm game offline, nhất là khi làm real-time game và độ khó sẽ tăng theo cấp số nhân. Bạn phải trở thành 1 người lập trình game có kĩ năng tốt, là 1 nhà bảo mật tự tin với khả năng của mình và là 1 nhà ảo thuật, thậm chí là 1 nhà tâm lý học có máu mặt. Người ta thường nói làm real-time multiplayer online game chủ yếu là tạo ra những ảo ảnh giúp che đậy latency khỏi mắt người chơi và cho họ thấy cái họ muốn thấy (dĩ nhiên thực tế diễn ra không giống cái người chơi thấy). Căn bản hơn nữa là bạn phải tối ưu client-side hết mức có thể để khi 1 message gửi đi nó phải gửi đi nhiều thông tin nhất vì thường thì header trong mỗi message có khi còn nặng hơn những thông tin bạn cần gửi đi, gửi nhiều message 1 cách không cần thiết là NO-NO.
Nhìn chung thì turn-based dễ hơn real-time nhiều do đỡ thằng latency, ngoài ra quá trình gửi và nhận message cũng rõ ràng hơn rất nhiều để bạn có thể đảm bảo phần security và tối ưu hệ thống mạng. Vậy nên mình có lời khuyên là bắt đầu với turn-based game dễ như tic-tac-toe đã rồi hẵng qua real-time, và để bắt đầu bạn phải tìm hiểu thêm những kiến thức sau:
1. Xem lại cách thức mà bạn làm game nào giờ, sắp xếp làm sao để mỗi 1 message gửi đi chứa được nhiều thông tin nhất.
2. Xem lại 2 thằng TCP và UDP, xem 2 thằng này có những ưu khuyết điểm nào và do đó mỗi thẳng sẽ đảm nhận trách nhiệm nào trong việc thiết kế MO game.
3. Học kĩ về Network Architectures.
4. Hiểu về Security và đảm bảo nó ở mức đủ trong game.
5. Tìm hiểu kĩ về Synchronization trong MO game. Không ít người sẽ bỏ giấc mộng không làm real-time MMO nữa khi đến phần này.
6. Tìm hiểu kĩ về Interpolation trong MO game và cố chịu đựng những cơn đau đầu. Sẽ có 3 khái niệm cơ bản giúp bạn trở thành 1 ảo thuật gia đó là deception, extrapolation và prediction. 3 thằng này sẽ giúp bạn cho người chơi thấy "cái ảo ảnh mà họ muốn thấy". (Làm turn-based game có thể bỏ phần này). Nhiều người sẽ bỏ giấc mộng không làm real-time MMO nữa khi đến phần này.
7. Nối tiếp và để kết thúc phần trên là có 1 cái nhìn tổng quát về Latency và đi sâu vào nó "thêm 1 tí". (Làm turn-based game có thể bỏ phần này). Đa số mọi người sẽ bỏ giấc mộng không làm real-time MMO nữa khi đến phần này.
Và kể cả bạn đã đi hết cả 7 phần trên thì mình vẫn không nghĩ bạn có thể hoàn thành được cái dự án ở #1 đâu, nhưng khi ấy bạn sẽ hiểu vì sao và chọn cho bản thân cái gì đó phù hơp hơn.
vậy thông số nhân vật được save ở client à nếu vậy thì việc trao đổi mua bán item không khả quan lắm.
Khó là đối với em, đang off mà chuyển sang onl thì nó thay đổi hoàn toàn nó quá khác biệt. Turn-base dễ hơn bởi vì nó có đủ thời gian để truyền thì phải, mới đầu em định làm turn-base nhưng ở GM off thì code cực hơn real-time.
Mình thực ra mới chỉ biết làm theo kiểu turn-based massage. Và cứ ngỡ rằng nó có thể làm real-time game ^^
Ko đc ak ?
Đơn cử như cái game Ping-pong đó mà. Vẫn làm đc đấy thôi ?
Phần online mình rất còn hạn chế. Và cũng chưa làm lần nào hết.
Khả năng drop thì mình tự nhận định là rất cao rồi. Nhưng mình đâu hứa hẹn là hoàn thành đâu.
Làm để trải nghiệm - làm để giao lưu - làm để trưởng thành !
^^
Lâu mới thấy ông này xuất hiện ^^
Mà xin có 1 lưu ý nho nhỏ thế này ^^
Game này hoàn toàn ko phải MMORPG. Data của người chơi hoàn toàn vẫn ở trên máy. Hoàn toàn ko có hệ thống truy nhập gì hết. Còn phần online thì hoạt động như kiểu Little Fighter 2 mà thôi ^^
Một game như little fighter làm đc online như vầy. Mình cũng có thêm hy vọng phần nào ^^
Kiểu như đang PK mà cứ chậm dề dề ... Mình chơi LFighter2 và cũng gặp trường hợp này. Chơi online với thằng FPS thấp ức vãi cả chế ra.
Nhưng thôi, kệ ^^
LF2 nó cũng chỉ làm đc thế. Thì mình cũng thế thôi ^^
có 2 phướng án giải quyết :
1. Ko làm gì. Người FPS cao phải chịu thôi. PK mà, chậm thì quan sát càng dễ ^^
2. Có đòi hỏi yêu cầu máy. FPS thấp quá, không thể tham gia phần online ^^
@[where?] : có cao kiến gì hơn ko ??? ^^
Cứ từ từ mà học thôi bạn, đâu cần phải vội. Cứ làm những cái vừa phải với sức mình, đảm bảo hoàn thành để có tinh thần. Turn-based nó dễ hơn real-time vì đỡ sợ cái độ trễ, đơn giản hơn khi đồng bộ client và dễ dàng để quản lý hơn cho bảo mật cũng như tối ưu hệ thống mạng.
//
@Focker_c:
Flash chỉ có thể dùng giao thức TCP nên bạn sẽ thấy đa số online multiplayer flash game là mô hình turn-based, real-time thì ít khi mang tính chất pvp, nếu có thì gameplay cũng rất chậm. Vậy nên bạn đừng dại chỉ dùng TCP mà làm real-time game, flash developers người ta muốn dùng UDP muốn chết mà không được dùng, bạn dùng được tội gì không dùng chứ.
// Cái wysiwyg editor mới của TTC củ chuối, xài khó chịu quá. +_+
Không, không cái nào trong cả 2 cái này cả.
1. Game sẽ cực kì kì quặc, ko đơn giản như bạn nói đâu. Dễ dàng khiến game unplayable, cái này tự bạn làm tự trải nghiệm.
2. FPS không phải là giá trị cố định. Player đang chơi với fps cao tự nhiên có ai pm yahoo họ chẳng hạn, làm fps đột ngột xuống thấp.
Cách giải quyết: Chỉ có 1 cách là dùng elapsed time để đồng bộ hoạt động khi framerate khác nhau thôi. Bạn lấy thời gian thực khác biệt giữa frame trước và frame hiện tại khi update game và dùng nó để tính các giá trị như khoảng cách. Như vậy sẽ động bộ được thông tin của 2 bên kể cả khi fps khác biệt, chỉ có ai bị fps thấp mới bị lag còn người fps cao vẫn chơi bình thường.
vậy mà các bạn nói đơn giản như không, game sẽ có tính năng online
1. UDP . Chưa có khái niệm về nó ^^
2. elapsed time để đồng bộ frame. Mình nghĩ chắc hẳn cái này được xài bởi đa phần các game. FPS kém thì lag còn thằng cao vẫn chạy như thường ^^
1. UDP và TCP thuộc lớp Internet Protocal, sử dụng IP làm địa chỉ truyền nhận các gói tin.
Trong đó TCP là giao thức dùng để đảm bảo gói tin đến được đích, khi packet đến được đích sẽ có reply thông báo từ receiver trả về cho sender. Trong trường hợp sender sau khi hết timeout mà không nhận được gói tin thông báo là việc truyền dữ liệu đã thành công thì nó sẽ gửi lại dữ liệu cho đến khi được thì thôi. Ghi chú là mọi hoạt động truyền nhận dữ liệu đến 1 receiver sẽ bị tạm hoãn trong thời gian chờ reply từ receiver đó, cũng như trong lúc gửi lại gói tin. => Header của mỗi gói tin gửi qua giao thức TCP nặng, thời gian truyền nhận dữ liệu lớn.
UDP thì không đảm bảo việc gói tin sẽ đến đích do đó không cần phải chờ reply từ receiver, không bị đình trệ việc truyền tải dữ liệu khi 1 lần gửi tin bị thất bại. => Header nhẹ và thời gian truyền nhận dữ liệu nhỏ.
Vậy nên bạn phải xem cái nào quan trọng cần đảm bảo đến được đích, lâu lâu mới gửi thì hẵng dùng TCP ví dụ như chat, trạng thái giao dịch của nhân vật. Những dữ liệu phải gửi đi liên tục và dù không tới nơi cũng không có hại gì mấy thì dùng UDP, ví dụ như tọa độ của nhân vật.
2. Elapsed time không dùng để đồng bộ frame, cách nói này là rất sai. Dùng elapsed time để tính toán là để đảm bảo đồng bộ giá trị thông tin trong thời gian thực (không phải đồng bộ framerate), như vậy dù frame rate khác nhau thì các giá trị nhận được tại 1 điểm trong thời gian thực vẫn sẽ được giữ cho bằng nhau.
Ví dụ:
+ Như vậy nếu fps của player thấp đến mức chỉ còn 2 thì _et sẽ là 0.5. Game update với tốc độ 2 lần trong 1 giây và tọa độ x của người chơi sau mỗi lần update sẽ tăng lên 2.5 và sau 1 giây trong thời gian thực thì tọa độ x của người chơi là 5.
+ Với 1 player khác có fps cao hơn là 10, vậy _et sẽ là 0.1. Game sẽ update 10 lần 1 giây và như vậy sau 1 giây thì x của người chơi cũng sẽ là 5, với mỗi lần update player.x tăng lên 1 giá trị là 0.5.
Đại khái thế
Ý 2 vẫn còn hơi bị mù ^^
Tức là như ở ví dụ ta sẽ nhân speed của nhân vật với hệ số cân bằng thời gian phải ko ?
Nhưng thực ra cách giải quyết của mình nó đại khái thế này :
có 1 thằng nhân vật. Nhưng 2 người chơi cùng nhìn vào.
thằng nhân vật này nó cứ chạy đều đều.
- máy có FPS cao sẽ nhìn là chạy đều đặn, mượt.
- máy có FPS thấp sẽ nhìn thấy thằng nhân vật vẫn xuất hiện đúng ở các tọa độ theo từng giây (hoặc từng 0.5 giây). Nhưng cái độ mượt về chạy sẽ ko được đảm bảo. Tức là sẽ nhìn theo kiểu giật giật ấy.
Lý do mình nói ra hướng này là do thấy rất nhiều game online như thế.
Thực ra cũng ko hiểu lắm. Chỉ biết biểu hiện của nó như vầy ^^
Mong bạn nói dùm