Công cụ trò chơi và thiết kế điều khiển dữ liệu

Tôi đã nghe nói về thiết kế điều khiển dữ liệu và đã nghiên cứu về nó trong một thời gian. Vì vậy, tôi đã đọc một số bài viết để có được các khái niệm.

Một trong những bài viết là Data Driven Design được viết bởi Kyle Wilson. Như ông mô tả, đối với tôi, mã ứng dụng (tức là mã để kiểm soát các tài nguyên như bộ nhớ, mạng ...) và mã logic trò chơi nên được tách ra và mã logic trò chơi phải được điều khiển bởi các nguồn dữ liệu ngoài. Tại thời điểm này, tôi có thể tưởng tượng rằng nhà phát triển sẽ viết một số loại trình chỉnh sửa trò chơi chấp nhận dữ liệu bên ngoài về các đối tượng trong trò chơi (như thông tin nhân vật, thông tin vũ khí, thông tin bản đồ ...). Thiết kế kịch bản sẽ được viết kịch bản bằng ngôn ngữ / công cụ tùy chỉnh được viết bởi lập trình viên để cho phép nhà thiết kế trò chơi tạo ra sự tương tác giữa các đối tượng trong trò chơi. Nhà thiết kế trò chơi sẽ sử dụng ngôn ngữ kịch bản hiện có / tùy chỉnh để viết kịch bản cho trò chơi hoặc công cụ kéo và thả để tạo thế giới trò chơi. Ví dụ về cách tiếp cận công cụ tôi có thể nghĩ đến là World Editor, thường được đóng gói cùng với các trò chơi của Bliizard.

Tuy nhiên, một bài viết khác chống lại việc sử dụng Thiết kế hướng dữ liệu, Trường hợp chống lại thiết kế hướng dữ liệu . Tác giả đề nghị không để thiết kế trò chơi bị điều khiển bởi dữ liệu, bởi vì sẽ mất nhiều thời gian hơn để phát triển một trò chơi, vì nhà thiết kế trò chơi có gánh nặng lập trình. Thay vào đó, sẽ có một lập trình viên trò chơi lập trình trò chơi một cách tự do từ thiết kế phác thảo, và được nhà thiết kế trò chơi xác minh sau khi lập trình trò chơi kết thúc. Ông gọi đây là lập trình điều khiển. Những gì tôi nghĩ về phương pháp này tương tự như cách tôi từng làm: Logic trò chơi là chính ứng dụng, như được nêu trong ý tưởng trên, ứng dụng là trình chỉnh sửa trò chơi và trò chơi thực tế được thiết kế dựa trên công cụ.

Đối với tôi, phương pháp đầu tiên có vẻ hợp lý hơn, vì các thành phần trò chơi có thể được sử dụng lại cho nhiều dự án. Với phương pháp thứ hai phản đối thiết kế hướng dữ liệu, mã trò chơi chỉ thuộc về trò chơi đó. Đây là lý do tại sao tôi nghĩ Warcraft có rất nhiều thể loại trò chơi trong đó, chẳng hạn như Warcraft gốc và nhiều bản đồ tùy chỉnh khác nhau, và một trong những trò chơi nổi tiếng nhất: DOTA thực sự định nghĩa một thể loại mới. Vì lý do này, tôi nghe nói mọi người gọi World Editor là công cụ trò chơi. Đây có phải là một công cụ trò chơi nên như thế nào?

Vì vậy, sau tất cả những điều này, tôi chỉ muốn xác minh rằng có bất kỳ lỗ hổng nào trong sự hiểu biết của tôi về những ý tưởng này (điều khiển dữ liệu, ổ đĩa lập trình viên, kịch bản vv ...)?

Làm cho trò chơi của bạn (hoặc bất kỳ sản phẩm phần mềm nào) được điều khiển gần như luôn luôn là một lợi ích. Điều thực tế duy nhất là bạn có thể dành nhiều thời gian hơn một chút để xây dựng các hệ thống liên quan lên phía trước; mặc dù vậy, nó sẽ trả hết phần còn lại của sự nghiệp là một lập trình viên (ngay cả khi bạn không sử dụng lại các hệ thống đó trong toàn bộ thời gian đó, bạn sẽ sử dụng lại các kỹ thuật bạn sử dụng để xây dựng chúng).

Thách thức, và nơi mà các ngắt kết nối trong hai bài viết bạn liên kết do thỏa thuận hợp để chơi, là những gì bạn chọn để đưa vào dữ liệu và người bạn chọn để cung cấp cho truy cập vào dữ liệu đó. Về cơ bản, thiết kế và phát triển dựa trên dữ liệu chỉ có nghĩa là bạn đưa thông tin vào bộ nhớ ngoài, tải thông tin đó vào thời gian chạy và hành động theo nó. Mã ứng dụng của bạn thực hiện những gì dữ liệu bên ngoài nói với nó, thay vì bạn viết mã ứng dụng trực tiếp làm những gì bạn nghĩ là kết quả cuối cùng. Đó không phải là một ý tưởng phức tạp.

Bạn không phải xây dựng các "kiến trúc hướng thành phần" phức tạp (như là mốt nhất thời ngày nay). Đặt các hằng số để điều chỉnh vật lý (lực hấp dẫn, hệ số phục hồi) trong một tệp văn bản là dữ liệu điều khiển. Các tập lệnh (trong Lua hoặc một cái gì đó khác) được điều khiển dữ liệu. Mô tả dữ liệu cấp độ của bạn trong XML. Tất cả những thứ tương tự như vậy.

Bạn có thể lái bất kỳ thành phần nào của phần mềm có dữ liệu và bạn có thể chọn và chọn phần mềm nào bạn muốn làm như vậy. Thời gian phát triển là tốn kém; lập trình viên thời gian đặc biệt là như vậy. Nếu bạn có thể tiết kiệm thời gian cho bạn hoặc các lập trình viên khác bằng cách đặt hành vi và dữ liệu vào bộ nhớ ngoài và không yêu cầu trò chơi phải được biên dịch lại cho mỗi thay đổi nhỏ, bạn nên làm. Bạn sẽ tiết kiệm tiền và hoàn thành công việc nhanh hơn.

Hơn nữa, bạn gặp rủi ro rất lớn khi cố gắng biến "nhà thiết kế thiết kế" và khiến các lập trình viên "biến những thiết kế đó thành hiện thực", buộc một lập trình viên tồn tại trong vòng lặp cho công việc của nhà thiết kế: bạn có nguy cơ khiến lập trình viên cảm thấy như thế Anh ta chỉ là một con khỉ mã, thực hiện các chỉnh sửa nhỏ cho thiết kế liên tục. Điều này có thể làm mất tinh thần ồ ạt đối với phần lớn các lập trình viên, những người muốn làm việc với các thách thức kỹ thuật thú vị và không phải là một ủy quyền của nhà thiết kế.

Đối với câu hỏi cụ thể của bạn:

Đây có phải là một công cụ trò chơi nên như thế nào?

Một "công cụ trò chơi" không thực sự có một định nghĩa cố định. Nói chung, đó là tập hợp thống nhất của công nghệ cơ bản được sử dụng để tạo trò chơi, thường được hỗ trợ bởi một loạt các công cụ liên quan (và do đó hoàn toàn dựa trên dữ liệu). Nhưng nó thay đổi khá rộng rãi từ bối cảnh đến bối cảnh.

Vì vậy, sau tất cả những điều này, tôi chỉ muốn xác minh rằng có bất kỳ lỗ hổng nào trong sự hiểu biết của tôi về những ý tưởng này (điều khiển dữ liệu, ổ đĩa lập trình viên, kịch bản vv ...)?

Bạn dường như ít nhiều đi đúng hướng, mặc dù có lẽ bạn đang quá phức tạp về thiết kế và phát triển theo hướng dữ liệu bằng cách kết hợp nó với các hệ thống dựa trên thành phần.

Là tác giả của bài viết thứ hai, tôi muốn làm rõ một vài điểm.

1. Như Josh Petrie đã đề xuất, cấu trúc mã của bạn để sử dụng dữ liệu thay vì chỉ mã hóa cứng, mọi thứ luôn là một chiến thắng. Tôi đã không đề nghị khác. Tôi đã chỉ ra rằng đẩy tất cả mọi thứ lên nhà thiết kế không phải là một ý tưởng tốt. Thuật ngữ "thiết kế hướng dữ liệu" có nghĩa là những thứ khác nhau đối với những người khác nhau, vì vậy tôi có lẽ nên cụ thể hơn khi tôi viết bài báo gốc.
2. Tại mọi nơi tôi đã làm việc, chúng tôi tạo ra các cấu trúc dữ liệu có thể điều chỉnh trong động cơ. Để thay đổi, chúng tôi không phải biên dịch lại trò chơi. Chúng ta có thể thay đổi số động khi chạy. Các cấu trúc dữ liệu thường được lưu trữ trong mã, nhưng tùy thuộc vào người thay đổi chúng, chúng có thể dễ dàng được tải từ một "tệp dữ liệu".
3. Hầu hết các môi trường phát triển đều hỗ trợ một số hình thức chỉnh sửa và tiếp tục hoặc tải lại mô-đun cho C / C ++.
4. Hầu hết các studio phát triển trò chơi đều có lập trình viên chơi game. Công việc của họ thường là làm việc với nhà thiết kế trong việc tạo ra trải nghiệm thú vị. Mối quan tâm chính của họ không phải là những thách thức kỹ thuật mà là tạo ra niềm vui từ mã. Tôi đã làm việc như một lập trình viên trò chơi trong nhiều năm, và tôi thấy điều này thú vị hơn là chỉ cố gắng giải quyết các thách thức kỹ thuật. Trách nhiệm của tôi rất đa dạng, nhưng tôi thấy công việc của mình hoàn thành nhất khi tôi phụ trách thực hiện và tôi làm việc với các nhà thiết kế để tạo ra một thứ gì đó tuyệt vời. Vấn đề với các nhà thiết kế mã hóa hoặc viết kịch bản là các lập trình viên thường phải sắp xếp các lỗi, đây là một trong những điều ít thú vị nhất bạn có thể làm khi lập trình viên.
5. Những gì hoạt động tốt nhất cho một studio phụ thuộc vào trò chơi. Nếu bạn có một thời gian dài để tạo ra một trò chơi, và bạn muốn cung cấp chân trò chơi của mình cho cộng đồng mod và tạo ra một cái gì đó rất lớn trong phạm vi, thì làm cho một trò chơi hoàn toàn dựa trên dữ liệu có ý nghĩa. Rất nhiều trò chơi không có mục tiêu đó. Họ phải tạo ra một trò chơi mới trong hai năm và trừ khi họ có một nhượng quyền thương mại, đó có thể là một loại trò chơi khác với công việc trước đây của họ
6. Những gì một "nhà thiết kế" có thể thay đổi từ studio đến studio. Tôi đã nghe nói về một studio phát triển thuê các lập trình viên trò chơi từ các studio khác, gọi họ là nhà thiết kế và họ viết kịch bản cho hành vi của trò chơi. Điều này vượt qua vấn đề có những người không được đào tạo về lập trình / viết mã.
7. Luôn phải có sự phân định giữa mã logic trò chơi và mã động cơ. Đồng thời, bạn thường muốn có một số loại trình soạn thảo trực quan cho vị trí đối tượng. Tôi chưa bao giờ làm việc tại một studio nơi các địa điểm của kẻ thù được mã hóa cứng. Chúng được đặt trong một trình soạn thảo. Hãy để tôi đề xuất một ví dụ về những gì tôi đang nói về. Hãy nói rằng nhà thiết kế nghĩ ra một kẻ thù. Có phải nhà thiết kế hơn kịch bản hành vi của loại kẻ thù mới này? Đó là những gì tôi cho là thiết kế hướng dữ liệu (về những gì Tim Moss đã viết về nó). Theo cách tôi đề xuất, lập trình viên làm việc với nhà thiết kế, họ tạo ra một kẻ thù vui vẻ với nhau có lẽ với các tham số có thể điều chỉnh, và sau đó chúng được đặt ở cấp độ.
8. Mã riêng được viết bởi một lập trình viên sẽ thực thi nhanh hơn trong thời gian chạy so với một kịch bản được viết bởi một lập trình viên, nó sẽ thực thi nhanh hơn một kịch bản được viết bởi một người ít hiểu biết về kỹ thuật. Hiệu suất này có thể hoặc không quan trọng tùy thuộc vào loại trò chơi bạn đang làm và những gì bạn đang làm, nhưng đó là điều cần xem xét.
9. Bạn có thể chia sẻ mã trò chơi giữa các trò chơi bất kể bạn chọn phương pháp nào. Tôi không thực sự chắc chắn những gì bạn đang nhận được vào thời điểm này. Ngay cả khi bạn không sử dụng ngôn ngữ kịch bản hoặc công cụ trực quan để xác định một số hành vi, bạn vẫn nên thiết kế mã trò chơi của mình thành các thành phần có thể tái sử dụng nhiều nhất có thể. Sẽ luôn có những thứ không thể áp dụng cho trò chơi tiếp theo của bạn, nhưng mọi nơi tôi từng làm việc, khi chúng tôi bắt đầu trò chơi tiếp theo, chúng tôi bắt đầu với cơ sở mã từ trước đó - ngay cả khi đó không phải là phần tiếp theo. Sau đó chúng tôi giữ những thứ có ý nghĩa và loại bỏ những thứ cụ thể trong trò chơi.

Cuối cùng, không có câu trả lời đúng hay sai. Đó là một câu hỏi về cách bạn và đồng nghiệp của bạn thoải mái làm việc. Khi tôi viết blog đó một thời gian trước, có rất nhiều cuộc nói chuyện về cách tất cả các công việc nên được đẩy đến các nhà thiết kế, và tôi muốn viết về bao nhiêu công ty trò chơi thành công mà tôi biết đã tìm thấy sự cân bằng khác nhau.

Ngoài ra, như một lưu ý phụ, mục blog của tôi là 5 tuổi. Có vẻ như rất nhiều hãng phim đang chuyển sang ngôn ngữ kịch bản và không có gì trong những ngày này nhưng đang tạo ra các công cụ trưởng thành để gỡ lỗi chúng, đó là khiếu nại chính của tôi. Khi tôi viết nó, tôi không nghĩ Unreal Kismet tồn tại, cái mà tôi chưa từng sử dụng, nhưng có vẻ như họ đang cố gắng đơn giản hóa kịch bản và nó dường như có một trình gỡ lỗi. (Không biết nó hoạt động tốt như thế nào)

Đối với các trò chơi quy mô nhỏ hơn, tôi chắc chắn không nghĩ rằng bạn muốn thử và sử dụng ngôn ngữ kịch bản hoặc chức năng tương tự vào công nghệ của mình, nhưng nếu bạn có một đội ngũ lớn và dành nhiều thời gian để cống hiến cho công nghệ, bạn có thể làm điều này đúng và đầu tư thời gian có thể có ý nghĩa tùy thuộc vào cách nhóm phát triển của bạn thích làm việc. Cá nhân, tôi có thể sẽ bám lấy C ++ càng lâu càng tốt bởi vì đối với tôi, đó là cách dễ nhất và nhanh nhất vì tôi thường phải thử và xử lý các "tính năng" như bộ sưu tập rác.

Bạn nên xem Công cụ công nghệ BitSquid . Nó được xây dựng bằng cách sử dụng các khái niệm DOD. Blog của Niklas Frykholm rất thú vị. Có nhiều bài viết về cách thiết kế động cơ này.

Tại GDC 2011, Niklas đã trình bày về Data Driven Renderer .