Cách tiếp cận Chaos Goblin để phát triển trò chơi trong Unity

Một trong những cảm giác tê liệt nhất khi bắt đầu bất kỳ dự án phát triển trò chơi nào là cảm giác bạn nhận được ngay sau khi hoàn thành thiết kế trò chơi ban đầu của mình, cho dù đó có thể là một vài ý tưởng được ghi lại trên khăn ăn để giải quyết vấn đề hay thiết kế 10 trang truyền thống tài liệu.

Bởi vì sau khi bạn đã quyết định rằng trò chơi của mình sẽ trở thành ROGUELITE-RTS-MMORPG, bạn thực sự phải xây dựng thứ đó, hiểu không?

Và giả sử bạn đã quyết định thứ đầu tiên bạn sẽ xây dựng là phần RTS của nó. Vì vậy, bạn ghi lại câu chuyện của người dùng, nhiệm vụ hoặc bất kỳ đơn vị công việc nào bạn sử dụng để tự tổ chức.

Sau đó, giả sử rằng mục đầu tiên trong danh sách đó là “Triển khai Bản đồ có thể cuộn”.

Và rất tiếc! Bạn chưa bao giờ triển khai bản đồ có thể cuộn. Nhưng đừng bận tâm, Google sẽ giải cứu, phải không?

Nhưng điều gì xảy ra nếu giải pháp bạn tìm thấy trực tuyến không thực hiện chính xác những gì bạn cần? Hay lời giải bạn tìm được là 15 tuổi? Hoặc có vô số bình luận bên dưới nói rằng giải pháp đó tệ đến mức nào nhưng không có một bình luận nào chỉ định giải pháp nào tốt hơn[^0]?

Vì vậy, bạn không thể tìm thấy tham chiếu mã cho bất kỳ thứ gì bạn đang cố gắng xây dựng. Nhà phát triển trò chơi phải làm gì?

Câu trả lời là vào chế độ Chaos Goblin.

Bước vào chế độ Chaos Goblin

Đối với những người không quen thuộc với yêu tinh, chúng là chủng tộc thường xuất hiện trong một số tác phẩm giả tưởng, thường được miêu tả là anh em họ nhỏ hơn với loài Orc hoặc hobgoblin nghiêm túc hơn. Trong một số thuộc tính khác, chúng được mô tả là thành thạo về máy móc theo một cách rất cụ thể. Và cách đó là không đáng tin cậy. Có nghĩa là những thứ yêu tinh tạo ra đôi khi hoạt động hiệu quả, không phải vì chúng được thiết kế hay chế tạo tốt, mà là do sự khéo léo và sự cứng rắn tuyệt đối.

Đó là bản chất của cách tiếp cận Chaos Goblin để phát triển trò chơi. Bây giờ, tôi chắc chắn rằng tôi đang bắt đầu lạc hướng bạn một chút ở đây, vì vậy hãy để tôi quay lại và tóm tắt bản chất của Chaos Goblin:

Để minh họa thêm cho điểm này, hãy để tôi kể cho bạn nghe về Trưởng tàu điện ngầm của Tổng thống trong Fallout 3 (bạn có thể đọc toàn bộ câu chuyện tại đây ). Ý chính của nó là trong một cảnh trong trò chơi mà người chơi nghĩ rằng họ đang đứng bên trong một tàu điện ngầm, thì chiếc mũ đội đầu của người chơi đã thực sự được thay thế bằng mô hình của một chiếc xe điện ngầm và đó là mô hình của chính người chơi đang di chuyển trên một đường đã định sẵn.

Một số người chơi có thể đọc điều này và nghĩ rằng các nhà phát triển đã lười biếng. Nhưng sự thật của vấn đề là các nhà phát triển luôn làm điều này.

Và chính kiểu thực hành đó đã hình thành nguyên lý của chế độ Chaos Goblin, cụ thể như sau.

Những gì người chơi không biết không thể làm hại họ

Giả sử rằng trong một phần trò chơi của bạn, người chơi đang đứng bên trong tòa tháp của lâu đài và đang bắn tên vào một con rồng đang bay bên ngoài. Thỉnh thoảng con rồng lại gần và thò đầu qua cửa sổ để cố cắn người chơi.

Bây giờ, đối với người chơi, con rồng thực sự đang bay ra khỏi đó. Nhưng chúng tôi, với tư cách là nhà phát triển trò chơi, có thể đã sử dụng một số thủ thuật để giúp loại bỏ ảo tưởng này và để tối ưu hóa tình hình.

Một số điều có thể được thực hiện như sau:

• Sử dụng các mô hình khác nhau tùy thuộc vào khoảng cách của con rồng với người chơi. Người chơi chỉ có thể nhìn thấy các chi tiết của con rồng khi nó ở gần, vậy tại sao không thay thế mô hình 3D của con rồng bằng thứ gì đó ít chi tiết hơn nhưng cũng sẽ chiếm ít dung lượng hơn trong bộ nhớ?

  
  

• Tắt con rồng khi người chơi không nhìn vào nó. Bằng cách theo dõi nơi người chơi đang tìm kiếm, chúng tôi có thể bật và tắt mô hình 3D một cách có chọn lọc để tiết kiệm kết xuất.

  
  

• Ngăn người chơi nhìn thấy công việc chưa hoàn thành. Đành rằng vì lý do gì mà nghệ thuật vì môi trường bên ngoài tòa tháp còn dang dở. Vì vậy, nếu người chơi bước ra gờ cửa sổ, họ sẽ không thấy gì. Để giải quyết vấn đề này, các nhà thiết kế trò chơi đã quyết định rằng gờ cửa sổ sẽ trở thành một điểm chết ngay lập tức. Vì vậy, khi người chơi đứng trên mỏm đá, âm thanh tiếng gầm của rồng kéo dài 3 giây sẽ phát ra và màn hình của người chơi sẽ bắt đầu tối đi. Sau khi âm thanh 3 giây kết thúc, chúng tôi phát hoạt ảnh nhanh về con rồng đang ăn thịt người chơi (có thể sử dụng lại âm thanh mà chúng tôi đã có). Đối với người chơi, mỏm đá chỉ là nơi mà con rồng có thể hạ gục họ; họ không cần biết nó đã được thực hiện để ngăn họ nhìn thấy công việc chưa hoàn thành.

  
  

• Có lẽ khi con rồng ló đầu qua cửa sổ, chúng tôi thay thế mô hình rồng đầy đủ bằng một mô hình đầu nhỏ hơn nhưng chi tiết hơn. Điều này sẽ cho phép chúng tôi giải phóng bộ nhớ khỏi một mô hình mà chúng tôi không sử dụng đồng thời cho phép chúng tôi cung cấp cho người chơi trải nghiệm được cải thiện.

  
  

Nếu bạn đã làm việc trong ngành công nghiệp trò chơi trong một thời gian dài, bạn có thể nhận ra những điều trên là những thông lệ tiêu chuẩn, nhưng đã có lúc những kỹ thuật này được coi là mánh khóe thông minh và khá sáng tạo.

Giờ đây, tùy thuộc vào bạn là nghĩ ra những cách mới để đánh lừa người chơi nghĩ rằng còn nhiều điều hơn nữa đối với những gì họ đang thấy.

Giải pháp tốt nhất là giải pháp hiện đang hoạt động

Rất nhiều nhà phát triển trò chơi gặp khó khăn vì họ cố gắng đưa ra các giải pháp bao gồm tất cả các tình huống có thể xảy ra trong tương lai. Thái độ này có thể có giá trị trong những trường hợp thích hợp, nhưng khi bạn ở chế độ Chaos Goblin, mục tiêu là làm cho thứ gì đó hoạt động nhanh nhất có thể.

Một phụ lục cho điều này:

Một nguyên mẫu không hoàn hảo có giá trị hơn bất kỳ kiệt tác chưa hoàn thiện nào

Tương tự như điểm trên, nhiều nhà phát triển bị đóng băng khi cố gắng triển khai một tính năng vì họ cố gắng tối ưu hóa quá sớm.

Việc tối ưu hóa nên được để lại cho đến khi dự án có nhu cầu chạy trên các máy ngoài tầm kiểm soát của nhà phát triển[^1].

Tôi cần biết bao nhiêu trước khi làm X? Câu trả lời là, bất kể lượng kiến thức bạn có bây giờ là đủ

Đây là một trở ngại khác mà nhiều nhà phát triển trò chơi mới bắt đầu gặp phải. Họ sẽ hoãn triển khai một tính năng để có thể tham gia thêm một khóa học nữa, thêm một hướng dẫn trực tuyến nữa, xem thêm một video và sau đó họ sẽ sẵn sàng triển khai trò chơi của mình.

Tôi đặc biệt có tội về điều này và biết nó có thể quỷ quyệt như thế nào.

Để cung cấp cho bạn một ví dụ cụ thể hơn, giả sử bạn được giao nhiệm vụ lập trình trò chơi Pong từ đầu.

Tùy thuộc vào những gì bạn biết hoặc không biết, có thể có các cách tiếp cận khác nhau để thực hiện việc này:

• Nếu bạn đã quen thuộc với hệ thống Vật lý của Unity, thì đó là một nỗ lực tương đối đơn giản. Bạn chỉ có thể sử dụng một vài vật thể cứng và máy va chạm, tác dụng lực và vận tốc, sử dụng vật liệu vật lý cho độ nảy của quả bóng và thế là xong. Một bản sao Pong xương trần.

  
  

• Nhưng giả sử rằng bạn không quen thuộc với hệ thống va chạm của Unity, bạn chỉ biết cách sử dụng các thành phần biến đổi của Unity, vì vậy tất cả những gì bạn có thể nhận được là vị trí và kích thước của đối tượng.

  • Nhưng! Điều đó là đủ để thực hiện Pong, bạn có thể viết một kịch bản theo dõi vị trí và kích thước của quả bóng và so sánh nó với vị trí và kích thước của mái chèo để kiểm tra xem có va chạm hay không.

    
    

• Hoặc có lẽ bạn thậm chí không biết Unity, tất cả những gì bạn biết là C++ và cách in ra bảng điều khiển.

  • Nhưng như vậy cũng là đủ! Bạn có thể sử dụng thủ thuật đầu cuối để in các hàng và cột biểu tượng đại diện cho quả bóng, mái chèo và khu vực chơi. Điều đó, cùng với khái niệm vòng lặp trò chơi, đủ để lập trình một giao diện người dùng mới đáp ứng đầu vào.

    
    

• Hoặc bạn thậm chí không có nền tảng về Khoa học máy tính hoặc không học lớp C++ và chỉ biết Javascript?

  • Không có gì! Bạn có thể sử dụng Phaser sử dụng JS làm ngôn ngữ chính và đi kèm với cả thành phần kết xuất và vật lý.

    
    

• Thậm chí không thể lập trình? Hoàn toàn không có vấn đề gì.

  • Gamemaker là một công cụ trò chơi thương mại có phiên bản miễn phí và có tùy chọn không cần mã.
  • GDevelop là một công cụ trò chơi mã nguồn mở miễn phí với tùy chọn không có mã.

Bạn đã tìm ra nơi tôi sẽ làm với điều này, phải không?

Không có dự án thất bại, chỉ có đống phế liệu chờ được tái sử dụng

Hầu hết các nhà phát triển trò chơi thường có một hoặc hai (hoặc 10.000) dự án bị bỏ rơi nằm đâu đó. Không có ý nghĩa trong việc lãng phí chúng. Nếu có mã trong đó như Hệ thống tạm dừng, hãy sử dụng lại mã đó. Không có ý nghĩa trong việc viết lại điều tương tự. Ngay cả khi bạn nhớ chính xác cách viết nó, hãy sao chép nó; nếu khó thích nghi thì hãy lặp lại nó để lần sau sẽ dễ dàng hơn.

Có lẽ bạn thậm chí còn có một dự án hội thảo[^2] có một số đoạn mã mà bạn có thể sử dụng lại.

Thấy một thứ sáng bóng? Lấy một thứ sáng bóng

Cần một hệ thống đối thoại? Tìm một mã nguồn mở và tái sử dụng nó. Liệu nó đáp ứng tất cả các yêu cầu của bạn? KHÔNG? Nó có đáp ứng trên 50% không? Đúng? Sau đó, nó đáng để sử dụng thay vì tạo một cái mới từ đầu.

Hệ thống hàng tồn kho? Tìm một trò chơi mã nguồn mở trên itch.io và sử dụng hệ thống của họ.

Cần một máy ảnh người thứ nhất? Sử dụng nội dung dựng sẵn để xử lý nội dung đó[^3].

Có rất nhiều nhà phát triển trò chơi xuất sắc ngoài kia, chắc chắn là thành thạo hơn bạn hoặc tôi.

Trừ khi bạn có lý do cụ thể, mọi thứ nên được coi là ứng cử viên cho việc sử dụng hệ thống dựng sẵn. Tuy nhiên, vẫn tồn tại những ngoại lệ hợp lý, chẳng hạn như: Không sử dụng mã mà bạn chỉ sao chép và dán làm xương sống cho trò chơi của mình (ít nhất hãy đảm bảo rằng bạn hiểu mã đó, làm sạch mã và nhận xét về mã đó) và tránh sử dụng mã mô-đun đã có tuổi đời cả thập kỷ, với tác giả của nó có lẽ đang thơ thẩn ở đâu đó vùng nhiệt đới, nhâm nhi Mai Tais với Elvis, Tupac và Marilyn Monroe trong một thiên đường không có tay săn ảnh.

Khi nghi ngờ, hãy sao chép

Nếu bạn không chắc chắn về việc triển khai một tính năng nào đó, hãy tìm một trò chơi đã thực hiện điều gì đó tương tự như những gì bạn muốn và bắt chước nó.

"Sao chép", ý tôi là các khía cạnh thiết kế như xử lý điều khiển, chế độ xem camera và cơ học, chứ không phải là phong cách nghệ thuật, câu chuyện hoặc nhân vật.

Chẳng hạn, tốc độ cuộn trong ROGUELIKE-RTS-MMORPG giả định hiện đã bị lãng quên của chúng tôi là bao nhiêu?

Thay vì đoán, bạn có thể xem một RTS khác đã quản lý nó như thế nào. Giả sử bạn quan sát Age Of Empires II (một RTS có ý nghĩa lịch sử) và phát hiện ra rằng nó cho phép người dùng kiểm soát tốc độ di chuyển con trỏ của họ. Bạn thậm chí có thể đặt trò chơi của mình cạnh AoEII và điều chỉnh con trỏ cho đến khi cảm thấy tương đương. Bạn sẽ ngạc nhiên về số lượng nhà phát triển dựa vào các giải pháp công nghệ thấp, đơn giản như thế này để hoàn thành mục tiêu của họ.

chia tay suy nghĩ

Vì vậy, bạn nên làm gì sau khi kết thúc trò hề Chaos Goblin của mình? Chà, hãy nghỉ ngơi, pha cho mình một tách cà phê và quay lại mã của bạn sau.

Sau khi để mã của bạn nghỉ ngơi (dưới một chiếc khăn ẩm nếu thời tiết quá khô), bạn nên làm mới mã của mình một chút và chia sẻ mã. Đúng! Chia sẻ nó, lý tưởng nhất là với một nhà phát triển cấp cao, đồng nghiệp, bạn học hoặc trong trường hợp xấu nhất là với cộng đồng trực tuyến[^4].

Tại sao bạn chia sẻ nó? Bởi vì trở thành Yêu tinh hỗn loạn không phải là tạo ra thứ gì đó lâu bền hay tối ưu; đó là về việc xây dựng thứ gì đó HOẠT ĐỘNG. Nó không cần phải hoạt động hoàn hảo hay trông đẹp đẽ, nó chỉ cần phải HOẠT ĐỘNG. Kiểu phát triển này tạo ra kết quả, nhưng kết quả hiếm khi sẵn sàng để sản xuất ngay lập tức. Vì vậy, việc tham khảo ý kiến của ai đó để cung cấp phản hồi là cực kỳ quan trọng.

Tùy thuộc vào giai đoạn dự án của bạn, bạn có thể không có thời gian để thực hiện nhận xét của người này ngay lập tức. Nếu đúng như vậy, ít nhất bạn nên ghi lại những nhận xét đó trong mã[^5].

Và thế là xong! Giờ đây, bạn đã sở hữu kỹ thuật số 1 được các nhà phát triển trò chơi chuyên nghiệp trên toàn thế giới sử dụng để giải quyết vấn đề.

Tôi muốn đề nghị đã đến lúc uống cốc thứ hai, phải không?

ghi chú

[^0] - Đây là một hiện tượng phổ biến đáng ngạc nhiên và nó được đặt tên là “Dụ ngôn Denver”, để biết thêm thông tin, hãy tham khảo bài viết học thuật sau đây .

[^1] - Đây là một chút khái quát hóa và giống như hầu hết các khái quát hóa, nó có thể không hữu ích bằng phân tích kỹ lưỡng các yêu cầu của dự án của bạn. Tuy nhiên, nguyên tắc chung là trì hoãn việc tối ưu hóa cho đến khi thực sự cần thiết. Ngày nay, việc tối ưu hóa các trò chơi điện tử đã bớt khó khăn hơn nhiều so với trước đây. Một số công ty công cụ trò chơi, như Unity, thậm chí có thể đề nghị hỗ trợ tư vấn miễn phí cho bạn. Xét cho cùng, việc bạn khởi chạy thành công trò chơi của mình là vì lợi ích tốt nhất của họ.

[^2] - Hội thảo là một trong những bài tập kata hoặc thực hành tôi sử dụng để nâng cao hiểu biết của mình về Unity. Bạn có thể đọc thêm về nó và các kỹ thuật khác ở đây .

[^3] - Bạn có thể tìm thấy gói bộ điều khiển FPS thực sự tốt cùng với các công cụ hữu ích khác trong bài viết này

[^4] - Điều này báo trước rằng khoảng 95% nhận xét mà bạn nhận được trực tuyến có thể là vô nghĩa, không đầy đủ, lỗi thời hoặc phản ánh niềm tin cá nhân sâu sắc của tác giả, bất kể chúng có thể là gì. Do đó, hãy luôn tiếp cận những phản hồi như vậy với một mức độ hoài nghi nhất định. Cố gắng tìm kiếm những nhận xét hữu ích, bỏ qua hoặc loại bỏ phần còn lại và nỗ lực thực sự để tìm ai đó mà bạn có thể chia sẻ mã của mình.

[^5] - Các nhóm khác nhau duy trì các tiêu chuẩn khác nhau về nơi họ duy trì tài liệu mã của mình và bạn nên tuân thủ điều đó. Tuy nhiên, nói chung, tôi ủng hộ tài liệu của mã nằm liền kề với chính mã đó. Nếu điều đó không khả thi, hãy cân nhắc sử dụng mô-đun con git hoặc mô-đun con tương đương trong hệ thống tạo phiên bản mã đã chọn của bạn. Nếu tài liệu không thể nằm trong kho lưu trữ chính, thì ít nhất nó phải nằm trong mô hình con git.