Hướng dẫn ban đầu cho những người muốn tạo game MMORPG

Chia sẻ: Nguyễn Thị Ngọc Huỳnh | Ngày: | Loại File: PDF | Số trang:7

Thêm vào BST

Báo xấu

269
lượt xem 30
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Hướng dẫn ban đầu cho những người muốn tạo game MMORPG (bài viết của Radu Privantu do ROOT dịch): Bài viết này sẽ tập trung vào bước cơ bản đầu tiên để tạo nên một game Multiplayer Online Role Playing Games (MMORPG). Đó là bước chuẩn bị để phát triển một game MMORPG, với kinh nghiệm và tài nguyên hạn chế($$$).

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Hướng dẫn ban đầu cho những người muốn tạo game MMORPG

Hướng dẫn ban đầu cho những người muốn tạo game MMORPG Hướng dẫn ban đầu cho những người muốn tạo game MMORPG (bài viết của Radu Privantu do ROOT dịch): Bài viết này sẽ tập trung vào bước cơ bản đầu tiên để tạo nên một game Multiplayer Online Role Playing Games (MMORPG). Đó là bước chuẩn bị để phát triển một game MMORPG, với kinh nghiệm và tài nguyên hạn chế($$$). Sau khi đọc xong bài viết này, bạn sẽ biêt bắt đầu như thế nào, sẽ biết cái gì nên làm cái gì ko nên làm. Kỹ năng và tài nguyên(resources) mà bạn có là điều tối quan trọng. Nếu ko có kỹ năng thì việc cố gắng xây dựng một game MMORPG chỉ gây lãng phí thời gian của bạn. Bước I: Quyết định về kỹ năng: I, Những yêu cầu về kỹ năng cơ bản để tạo 1 game MMORPG(level I): 1. Biết được ít nhất một ngôn ngữ lập trình. C++ là sự lựa chọn tốt nhất đây là ngôn ngữ thông dụng để làm 1 game. VISUAL BASIC, JAVA hoặc C# cũng có thể làm việc tốt nhưng còn tuỳ từng trường hợp. 2. Làm quen với một trong những thư viên đồ hoạ. Các thư viện đồ phổ biến hiện nay là SDL, OpenGL hoặc DirectX/Driect3D(mỗi cái đều có ưu và nhược điểm riêng). 3. Lựa chọn 1 phương thức giao tiếp mạng. Bạn có thể chọn lựa giữa WinSock, SDL_net hoặc DirectPlay trong bộ DirectX. 4. Bạn phải có kinh nghiệm trong việc lập trình. Ví dụ: Các vòng lặp sự kiên trong Win(event loop), phân luồng(MultiThreading), lập trình giao diện, v..v. II, Kỹ năng level 2(cái này dịch theo ý tui à ^^): 1. Lập trình theo mô hình Client/Server. 2. Lâp trình trên các Platform khác nhau(game tạo ra phải thích ứng với nhiều hệ điều hành cả trên server lẫn Client). Để làm được điều này tôi đề nghị bạn nên sử dụng SDL, OpenGL và SDL_net(có nghĩa là DX chỉ trên Windows thôi). 3. Phát triển WEBSITE. Điều này là cần thiết nếu bạn muốn gamer xem thông tin về nhân vật của mình, trạng thái server, đăng kí, giao tiếp cộng đồng v..v. 4. An toàn và bảo mật. Nếu bạn ko muốn hacker tấn công server của bạn hãy quan tâm đến điều này. 5. Kỹ năng làm việc theo nhóm. Chắc chắc 1 game MMORPG phải được một nhóm ít nhất 3 người xây dựng và phải có 1 ladder. Điều này là rất cần thiết nếu bạn muốn game được thực hiện nhanh chóng. Bước 2: Chuẩn bị thiết kế sơ bộ: Một tình trạng phổ biến hiệ n nay mà chúng ta hay gặp trên các forum là(ngay cả ở GVN cũng vậy - theo ý kiến chủ quan của tôi) rất có nhiều người bắt đầu một game bằng cách: "Chúng tôi hiện đang bắt đầu xây dựng một Game Studio/một news game và chúng tôi cần 3 Designers, 2 Programmer s, 1 Nhạc công, v..v, cho một ý tưởng về
game .......v..v. Chúng tôi sẽ trả lương cho bạn khi công việc hoàn thành và chúng ta kiếm được tiền"(nguyên văn). Nhưng đáng tiếc kỹ thuật khả năng lại ko cho phép(tác giả còn quan tâm đến cả BandWidth), bạn ko thể có được sản phầm. Mục tiêu của bạn bị sụp đổ và bạn chỉ thiết kế được một phần nho nhỏ trong cả một thế giới MMORPG rộng lớn. Thiết kế môt phần mềm cơ bản: Đầu tiên, hãy tập trung để tạo một phiên bản mẫu dựa theo mộ hình Client Server đơn giản. Phiên bản này có thể: 1. Tạo một nhận vật(character) 2. Lưu lại nhân vật đó (phía Server) 3. Login với nhân vật đó 4. Có thể chat với các nhân vật khác 5. Thiết kế trong mô hình 3D đơn giản(View các góc độ) Lưu lại một nhân vật(trên server) dường như là đơn giản. Nhưng sự thực thì không như vậy. Ví dụ, có hai cách để lưu lại nhân vật trên server: Sử dụng database hoặc sử dụng Flat Text(files). Cả hai đều có những ưu điểm và nhược điểm. Database Ưu điểm: - Dễ dàng thêm mới các trường(fields), hoặc chỉnh sửa. - Cập nhật thông tin người chơi dễ dàng hơn - Có thể dễ dàng lây thông tin ra một cách nhanh chóng và hiệu quả, thông qua các câu lênh truy vấn SQL (SQL Query). - Không cần tới việc thực hiện các phép đóng mở cơ sở dữ liệu (File thì ngược lại). - Dễ cập nhật và phục hồi. Nhược điểm: - Dễ dàng sinh lỗi. Nếu Query sai. - Database có thể chậm hơn file trong việc đọc ghi dữ liệu đối với lượng dữ liệu nhỏ. Nhưng với dữ liệu lớn thì tốc độ so với ban đầu thì thay đổi ko đáng kể. - Sử dụng Database phức tạp và phả i yêu cầu kỹ năng về Database và SQL. Điều này có thể khắc phục được bằng việc sử dung các thư viện giao tiếp(interface) giữa chương trình và cơ sở dữ liệu. Flat Text(tác giả gọi là files thì cũng vậy) Ưu điểm: - Truy cập nhanh(ko có nghĩa là tìm dữ liệu nhanh) - Dễ dang sử dụng. - Không cần các thư viện hỗ trợ - Ko phụ thuộc vào hệ quản trị CSDL.==> ko sợ bị hack CSDL dựa trên những lỗi của hệ quản trị CSDL. Nhược điểm: - Khó khăn trong việc thêm các trường dữ liệu. Trừ khi bạn thiết kế một các cẩn thận
cấu trúc file ngay từ ban đầu. - Khó khăn hơn trong việc phục hồi và sao lưu. - cần những đoạn Coding đặc biệt. Bây giờ bạn đã sẵn sàng trong việc chọn cách thức để lưu CSDL, tiếp theo cần phải chọn một giao thức mạng(Network Protocol) để sử dụng cho gia o tiếp Client/Server: TCP hay là UDP? TCP thì chậm hơn nhưng họat động chính xác, và cần thêm băng thông(bandwidth). Trong việc thử nghiệm, tôi ko có ý kiến gì về việc sử dụng TCP. Chỉ cần cung cấp đủ băng thông, TCP là sự lựa chọn tốt nhất đối với những người mới bắt đầu. UDP thì khó khăn hơn, đặc biệt là với những người mới bắt đầu. Khi đã xây dựng được thì tiếp theo bạn phải kiểm tra dữ liệu truyền trong mạng cục bộ, điều này sẽ thành công và ko có vấn đề gì xảy ra với các gói dữ liệu. Nhưng đối với mạng internet thì đây là cả một vấn đề, một số gói dữ liệu có thể bị mất, và đây là lỗi thường xuyên xảy ra. Tất nhiên bạn có thể thiết kế một cách thức truyền theo giao tiếp Cilent/Server mà có thể phục hồi lại được những gói dữ liệu bị mất. Nhưng đây chắc chắn là một công việc khó khăn và vất vả đối với những người mới bắt đầu. Bước 3: chọn một cách thức để truyền tải dữ liệu: Việc làm này ko đơn giản chút nào. Bạn ko thể chỉ gửi một chuỗi với kết thúc bằng „\0‟ như ở trong ngôn ngữ C được. Bạn sẽ phải cần đến một giao thức thích hợp, nó có thể chuyển được cả hai loại dữ liêu chuỗi(strings) và dữ liệu nhị phân(binary data). Không dại gì mà sử dụng 0 (hoặc bất kì chuỗi nào khác) là dữ liệu kết thúc, bởi vì nó có thể chứa một phần dữ liệu mà bạn muốn gửi (đoạn này ko hiểu lắm). Hơn nữa nếu bạn muốn truyền 20 bytes dữ liệu, và lại truyền 20 bytes dữ liệu khác, Server có thể sẽ ko nhận 20 bytes dữ liệu này rồi đến 20 bytes dữ liệu kia, thay vào đó nó sẽ nhận cả 40 bytes cùng một lúc, điều này để tránh lãng phí bă ng thông và các header(phần đầu của mỗi packet) ko cần thiết. Bạn cũng có thể sẽ gửi một gói 1KB dữ liệu, nhưng server sẽ tiếp nhận nó bằng hai gói dữ liệu nhỏ hơn. Vì vậy bạn cần phải biết đâu là khởi đầu đầu là kết thúc của một gói dữ liệu. Trong game Et ernal Lands, sử dụng phương thức sau: Offset 0: 1 byte, để đinh nghĩa lệnh Offset 1: 2 bytes, độ dài của dữ liệu truyền Offset 3: có độ dài được định nghĩa ở Offset 2, thân của thông điệp được truyền. Phương thức này có nhiều thuận lợi: tất cả dữ liệu được truyền đều theo một chuẩn nhất định. Nhược điểm gây ra một chút lãng phí cho băng thông. Điều tiết theo phải nghĩ đến là phiên bản server: "Non-blocking sockets, non threaded" hay "blocking sockets, threaded". Cả hai cũng đều có những ưu và nhược điểm. Threaded(Đa luồng): 1. Đây là cách thức để server chạy trơn tru hơn, nếu một người chơi nào đó cần một khoảng thời gian để đọc dữ liệu từ CSDL nó sẽ được xử lý trong một luồng riêng và không làm ảnh hưởng đến người chơi khác. 2. Rất khó debug và khó thực thi đúng: Bạn sẽ cần đến rất nhiều sự đồng bộ, và chỉ một sơ suất nhỏ có thể dẫn đến tai hoạ với game có thể bị ngừoi chơi khai thác (như đúp item, server crashing v..v).
3. Được thiết kế để sử dụng với hệ thống có nhiều bộ xử lý (Multiprocessors) hoặc Hyper Threading của INTEL. Non-Threading: 1. Triển khai và debug dễ dàng hơn. 2. Tuy nhiên thời gian xử lý chậm. Việc xây dựng server Multithreading sẽ phải cần nhiều tài nguyên hơn, tốn nhiều thời gian và công sức, nhưng muốn có một game chuyên nghiệp thì cần phải quan tâm đến vấn đề này. Bước bốn: Xây dựng bản Client Game 2D hay 3D? đó là câu hỏi đầu tiên? Một số ý kiến cho rằng làm game 2D dễ dàng hơn. Nhưng điều đó là sai lầm(ở đây tôi ko nói đến sử dụng engine như RPG maker). Nhưng theo tôi thì 3D dễ dàng hơn. Điều đó được giải thích như sau: Trong game 2D, bạn thường sử dụng các frame buffer, mà có lượng rất lớn các pixels(điểm ảnh). Định dạng mỗi điểm ảnh này khác nhau. Một số có chế độ RGB, số khác là BGR v..v. Bạn chỉ có thể làm game 2D tối ưu ở chế độ 16bit màu. 8bit thì chỉ có 256 màu, 24bit thì sẽ rất chậm. Việc sắp sếp các frame hình sẽ rất khó khăn sẽ làm bạn chán nản. Dĩ nhiên là bạn cũng có thể sử dụng thư viện OpenGL hoặc D3D cho game 2D, Nhưng điều tồi tệ sẽ xảy ra: thứ nhất là ko phải người chơi nào cũng có card đồ họa 3D hỗ trợ DirectX hoặc OpenGL, thứ hai là sử dụng thư viện 3D cho game 2D sẽ kết hợp nhược điểm của cả hai: ko phải ai cũng có thể chơi nó, bạn ko thể quay camera ở các góc độ, ko có các hiệu ứng 3D đặc biêt.(trò MUOnline là một ví dụ). Ở Game 3D, như tôi đã nói, dễ dàng hơn. Nhưng bạn cần phải có các kiến thức về toán học(đặc biệt là lượng giác). Các thư viện đồ hoạ ngày nay rất mạnh, bạn sẽ ko phải mất nhiều thời gian vào các tính toán đơn giản (ko cần phải sắp xếp đối t ượng, thay đổi màu hoặc texture của một đối tượng rất đơn giản v..v). Hơn nữa 3D game cho bạn nhiều khả năng sáng tạo, cho người chơi cảm giác tự do di chuyển quay camera v..v. Nhưng nhược điểm của nó là ko phải ai cũng có thể chơi được (ko có card đồ họa, một số người không quen với đồ họa 3D có thể chóng mặt khi chơi) và hình ảnh render quảng cáo thì bao giờ trông cũng đẹp hơn khi chơi trong game. Tiếp theo: Những vấn đề liên quan đến bảo mật: Rõ ràng là chúng ta không thể tin tưởng vào người chơi. Liệu bạn có thể chắc chắn rằng người chơi không thể nào phá được cách thức mã hóa của bạn, hay giao thức của bạn. Vì thế mọi dữ liệu mà người chơi truyền đến server đều phải được hợp thức hóa. Trên server của bạn phải chắc chắn rằng nó kiểm tra tràn bộ nhớ đệm (buffer). Ví dụ: Thông thường có một vùng nhớ đệm nhỏ(có thể là 4K) cho những dữ liệu truyền đến (từ socket), Một người chơi ác ý hay một hacker có thể gửi những gói dữ liệu dài hơn vùng nhớ đệm này, nếu dữ liệu đó ko được kiểm tra, sẽ xảy ra tràn bộ nhớ đệm. Kết quả là server bị sinh lỗi nhẹ thì sẽ phải khởi động lại, nhưng tồi tệ hơn là hacker có thể hack được server của bạn bằng những đoạn code ác ý có thể điều khiển cả server(hack tràn bộ đệm thì điều này chắc ai cũng biết). Như vậy mỗi một thông điệp
được gửi đến đều phải được kiểm tra: 1. kiểm tra độ lớn, 2. kiểm tra tính hợp lệ của dữ liệu(Ví dụ người chơi có thể gửi một thông điệp là “uống một lọ máu” –> đầy máu, mặc dù trên người nhân vật không hề có một lọ máu nào, hay “giết một con quái vật”, mặc dù con quái vật đó ở rất xa nhân vật v..v). Và tôi xin khẳng đinh một lần nữa rằng. Dữ liệu hợp lệ là vô cùng quan trọng. Sự vi phạm lúc nào cũng có thể xảy ra, vì vậy hãy ghi(log) lại username, IP, ngày giờ và những hành đ ộng vi phạm của người chơi. Thường xuyên kiểm tra log. Nếu bạn tìm thấy vài lỗi từ một số người chơi thì đây thường là lỗi của cllient, hoặc do lỗi của mạng. Tuy nhiên nếu tìm được rất nhiều lỗi từ cùng một user hay IP, thì đây rất có thể là ai đó đang đùa giỡn với server của bạn, đang cố hack nó, hay chạy những đoạn macro/script(cái này là bot ư). Mặc dù chúng ta ko bao giờ lưu dữ liệu trên client. Client nên nhận dữ liệu của nó từ server. Hay nói cách khác, Nó ko bao giờ giờ gửi những dữ liệu đại loại như : “Ok, đây đúng là danh sách các item của tôi” hay “Strength của tôi là 10, mana là 200, máu là 2000”. Và client cũng ko nên được nhận những dữ liệu ko cần thiết. Ví dụ: client sẽ ko đuợc biết người chơi khác đang ở vi trí nào trừ khi họ ở gần. Điều này là tất nhiên vì để gửi dữ liệu của tất cả người chơi trên server tới client sẽ cần tới một băng thông rất lớn, và một số người chơi có thể hack để có được một số lợi thế hơn những người chơi khác(có vị trí của người chơi khác trên bản đồ). Tất cả dường như đ ã rõ ràng, nhưng, một lần nữa, bạn sẽ thấy ngạc nhiên khi thấy rằng bao nhiêu người ko thực hiện những điều mà chúng tôi goi là hiển nhiên đó. Một vấn đề khác, khi đề cập tới vấn đề bảo mật: Tốc độ di chuyển(ở đây di chuyển còn có thể là 1 hành động) của người chơi nên được xử lý trên server, ko trên client. Server sẽ lưu giữ thời gian giữa hai bước di chuyển được tính từ khi client di chuyển một bước. Nếu thông điệp di chuyển đến nhanh hơn mức bình thường, thông điệp đó nên bị loại bỏ. ko cần xét đến chúng, bởi vì người chơi còn có thể bị trễ mạng(network latency) (VD: khi ngươi chơi bị lag tất cả dữ liệu trong vòng 10 giây bị lag sẽ đến cùng một lúc). (đọan này chắc có nghĩa là cần loại bỏ những dữ liệu thừa khi bị lag, một số trò như warcraft dữ liệu này vẫn ko loại bỏ vì thế có tình trạng là tự nhiên đứng khựng lại rồi một lúc sau quân cứ chạy vèo vèo) Kiểm tra khoảng cách. VD: nếu nhân vật trao đổi buôn bán với một nhân vật khác cách nhau rất xa. Hay nếu người chơi nhìn thấy hoặc sử dụng một đối tượng nào đó ở xa. Hãy log lại. Nhưng hãy cẩn thận với nhưng ID giả mạo, Bình thường mọi người chơi đều phải đuowcj gán một ID nhận dạng(ID có thể được gán khi người chơi đăng nhập, hoặc nó có thể được gán mãi mãi) Nếu như một ID được gán với một người chơi khi đăng nhập(hoặc một con quái vât xuất hiện trên bản đồ), Như vậy người chơi đầu tiên sẽ được gán ID bằng 0, người thứ 2 ID bằng 1, và cứ như vậy. Nhưng những con số ID này sẽ phải có giới hạn 2000 chí số chẳng hạn. Nếu như người chơi gửi đến một thông điệp là “hãy trade với người có ID=200.000” chẳng hạn. Điều này sẽ gây lỗi trên server. Nếu không chú ý server sẽ truy cập tới vùng nhớ không hợp lệ. Vì vậy hãy kiểm tra chúgn theo cách sau: "if actor id max players then log the violation and disconnect the player". Nếu bạn lâp trình trong C hay C++, thì hãy cẩn thận với khi sử dụng ID với số nguyên ko dấu(unsigned int) và kiểm tra cận trên, nói tóm lại là kiểm tra [0,max]. Tương tự như vậy hãy kiểm tra tọa độ trên bản đồ. Nếu bạn có một thuật tóan tìm đường trên server, và client di chuyển bằng cách click chuột vào một vị trí trên mặt đất thì phải đảm bảo rằng vị trí đó ko ở ngòai bản đồ. Tiếp theo: Thành lập nhóm phát triển:
Để làm ra một game cần phải bỏ ra rất nhiều công sức (ngoại trừ cá c game xếp hình, cờ carô v..v). Nhất là đối với một game MMORPG. Bạn ko thể một mình làm hết tất cả được. Một nhóm phát triển game nên: - Ít nhất là có 3 người lập trình: 1 cho server, và 2 cho client(một cho lập trình client, 1 sử dụng các công cụ thiết kế, world editor, v..v). Nếu như có đến 6 người lập trình thì càng tốt. Nhưng quá mức này thì có vẻ hơi nhiều. cái chính là còn phụ thuộc vào ladder của bạn. Số lượng người thiết kế đồ hoạ cũng nên có từ 1 đến 3 người. Nếu như là game 3D thì bạn cần phải có 1 cho thiết kế 3D, một cho 2D (texture, interface, v..v), một cho animator và một người nữa là ladder. - Build map cũng là một công việc đòi hỏi rất nhiều thời gian, và nó là chìa khoá dẫn tới một game thành công, và bạn cũng cần phải có một ladder để đ iều hành công việc này. Cần phải có sự phù hợp trong map được xây dựng. Bạn không thể đưa công việc này cho một ai đó làm mà ko có sự chỉ đạo được. - 1 Webmaster: cần phải có một webmaster để thiết kế web. Website là nơi để người chơi có thể đăng kí tài khoản, nhân vật, xem hệ thống ladder v..v. vì thế nó cũng rất quan trọng. - Sound and musician cũng rất quan trọng để quyết định game có thành công hay khống nhưng với những người bắt đầu thì điều này cũng chưa thực sự cần thiết. Chúng ta có thể sự dụng những tài nguyên sẵn có. Những tiếng hét, tiếng bước chân, tiếng đâm chém có thể tìm thấy rất nhiều trên mạng. - 1 người thiết kế game play(game's economy). Bạn có thể nghĩ rằng công việc này là dễ dàng. Nhưng thực sự nó là công việc phức tạp nhất trong tất cả các công việc chúng ta vừa kể trên. Nó quyết định yếu tố hấp dẫn trong game. Nếu Gameplay thiết kế ẩu(Ví dụ như các chỉ số nhân vật ko cân bằng, tài nguyên phân bố trên map ko đồng đều, hệ thống tính điểm EXP ko hợp lý v..v) người chơi sẽ chỉ chơi vài ngà y là chán. Về tác giả: "thời gian đầu chúng tôi gặp phải vấn đề rất lớn về Gameplay, bới vì nó được thiết kế bởi một lập trình viên, và đó ko phải là công việc phù hợp với anh ta. Vì vậy chúng tôi phải mất 2 tháng để thiết kế lại hệ thống gameplay mới. Và phải xoá hết toàn bộ Item mà chúng tôi đã tạo ra, điều này đã gây cho player sự bực bội ...." - Có một điều đơn giản của game MMORPG là thiết kế AI trong game đơn giản hơn so với các loại game khác. Vì thế chúng ta ko cần quan tâm nhiều lắm về vấn đề này. - Khi mới bắt đầu xậy dựng game bạn ko cần thiết phải có một nhóm quá lớn. Chỉ cần 1 lập trình và 1 artist là đủ. Nếu bạn là một lập trình viên thì hãy tìm trong số bạn của bạn có kỹ năng về đồ hoạ. Khi công việc đã tiến triển thì hãy tìm thêm người thiết kế. Một nhóm gồm những người thuộc dang begginer sẽ không là một nhóm có chất lượng. Ít nhất mỗi thành viên trong nhóm phải thông thạo về lĩnh vực của mình. - Và một khi đã có một chương trình game cơ bản được làm từ 1 lập trình viên và 1 artist, làm việc được trên client server hãy chụp vài cái screenshot. Như vậy sẽ có nhiều người muốn tham gia vào nhóm của ban. Bạn nên cấn nhắc xem game của bạn có nên là mã nguồn mở hay ko(chỉ mở soucre Client), nếu bạn open soucre Client bạn sẽ có thêm nhiều đồng minh t rong lập trình. - Đừng bao giờ khoe khoang về game của bạn cho đến khi nào bạn đã làm được một chút gì đó. Đừng lãng phí thời gian cho việc phát triển website cho đến khi bạn hoàn thành ít nhất 10% dự án(trên cả khía cạnh lập trình và đồ hoạ). Những vấn đề cần quan tâm khác: 1. Bạn không thể tạo ra được một game MMORP tốt nếu như bạn ko phải là một công ty lớn: tôi đồng ý với điều đó. Bạn không thể làm một game hoàn chỉnh như WOW, Ever
Quest 2, Asheron's Call 2, Lineage 2 với một nhóm nhỏ và làm việc độc lập. Nhưng tuy nhiên bạn có thể làm được những game khá để cung cấp kinh nghiệm. Cần tới 1000 giờ lập trình để có được một bản demo đơn giản, và có lẽ cần tới 10k tới 15k giờ để hoàn chỉnh một bản client/server. Nhưng nếu là một team leader bạn cần có nhiều việc phải làm hơn là ngồi lập trình, Giữ cho đội ngũ của bạn làm việc ăn ý với nhau, giải quyết những vấn đề tranh cãi, tạo mỗi quan hệ, hỗ trợ kỹ thuật, cài đặt server, sử dụng trí tuệ tập thể v..v. là những việc một ladder phải làm. Và bạn sẽ phải bận t úi bụi trong những công việc đó, Không có ai rời bỏ team của bạn thì đó là một điều may mắn, nhưng nếu điều này sảy ra thì đó là cả một vấn đề. Thử tưởng tượng rằng có một Artist rời bỏ công việc giữa chừng. Anh ta sẽ không cho bạn sử dụng những thành quả làm việc của anh ta. Dĩ nhiên, việc này có thể giải quyết bằng một bản hợp đồng, nhưng sẽ khá là vất vả để kiếm một artist khác thay thế. Sẽ có hai phong cách vẽ khác nhau trong game của bạn. Liệu bạn có muốn điều này xảy ra? 2. Cần một khoản tiền lớn (từ 4-6 chữ số tất nhiên là USD) để duy trì một Server MMORPG? Điều này thật sự không đúng, một server chuyên dùng cho game, với băng thông 1000GB/tháng bạn sẽ phải chi xấp xỉ 100USD/tháng (và một khoản 2 -300 USD cho phí cài đặt). Trừ khi bạn thiết kể một giao thức truyền tải qua mạng quá tồi tệ, 1000GB/month sẽ đủ cho server với 1000 người chơi(trung bình). Dĩ nhiên bạn cần một server khác để duy trì website về game và nơi download client(download client sẽ tốn rất nhiều băng thông một khi game trở nên phổ biến). Nếu Client của chúng ta khoảng 22MB,và ta có băng thông 400GB/tháng. Và game của chúng ta chưa phổ biến rộng rãi. Bạn không cần phải lo lắng khi bắt đầu dự án. Một server với đường truyền DSL có thể làm tốt việc đó, nó có thể duy trì 20 -30 người chơi online cùng một lúc. Khi đó bạn sẽ cần phải tìm một host free hoặc trả phí thấp để làm nơi đặt trang web và các thứ linh tinh khác.