Thư viện hoặc khung công cụ Game Engine [đã đóng]


8

Tôi đang trong giai đoạn lập kế hoạch cho một công cụ trò chơi nội bộ mà tôi sắp bắt đầu tạo, sẽ được sử dụng cho tất cả các trò chơi của tôi trong tương lai. Nhưng tôi đang vật lộn một chút với cách nó nên được xây dựng.

Các lựa chọn đi xuống: khung hoặc thư viện.

Mục tiêu cơ bản của tôi là ẩn chi tiết công cụ càng nhiều càng tốt để duy trì sự phát triển trò chơi cấp cao trên các tập lệnh và tập tin cấu hình càng nhiều càng tốt. Nhưng cũng để sử dụng lại công cụ cốt lõi cho bất kỳ công cụ nào chúng ta có thể phát triển trong tương lai.

Các khung có thể làm cho mọi thứ tốt đẹp và dễ dàng để phát triển, nhưng sau đó bạn bị khóa. Thư viện rất tốt nếu bạn chỉ quan tâm đến một hệ thống con cụ thể. Nhưng chúng ta cần phải dán mọi thứ lại với nhau trong một trò chơi theo cơ sở trò chơi.

Ngoài ra còn có một công cụ khác, xây dựng công cụ như một exe độc ​​lập xử lý tất cả các tài nguyên trò chơi và tất cả các hệ thống con. Logic trò chơi (và các công cụ động khác trên mỗi trò chơi) được thực hiện riêng trên các tập lệnh với các tệp cấu hình để định cấu hình từng hệ thống con công cụ nội bộ.

Cái nào sẽ cho tôi linh hoạt hơn trong tương lai.

Cảm ơn.

Chỉnh sửa: Cảm ơn tất cả mọi người, đoán tôi đã nhìn vào điều này trong quan điểm sai. Chúng tôi thực sự không thể lập kế hoạch cho một cái gì đó như thế này mà không có kiến ​​thức chuyên môn về những gì các trò chơi cần, đoán đây là lý do tại sao không có thứ gọi là công cụ chung cho tất cả các thể loại.

Trước tiên tôi sẽ tập trung vào trò chơi, sau đó phân tích lặp lại vào cuối mỗi trò chơi để tạo ra sự trừu tượng hóa tốt cho các thư viện hoặc khung tùy thuộc vào luồng công việc của tôi (hoặc có thể là của nhóm tương lai).


3
Cũng không. Bạn nên xây dựng trò chơi, không phải động cơ.
5

Tôi đồng ý. 'Các khung có thể làm cho mọi thứ tốt đẹp và dễ dàng để phát triển, nhưng sau đó bạn bị khóa.' Tôi nghĩ rằng bạn đang thực sự tự khóa mình. :) Xây dựng trò chơi, không phải động cơ. Động cơ sẽ theo sau, sau - nhiều sau này. Nó phát triển ra một số dự án.
jacmoe

@Jacmoe: Hoặc là hoặc bạn cố gắng xây dựng trò chơi tiếp theo của mình trên trò chơi trước đó và nguồn được chứa đầy mã không có cấu trúc rất khó để làm việc. Theo thời gian, bạn có thể tạo ra một khoản nợ kỹ thuật khổng lồ, cuối cùng sẽ dẫn đến một điểm nhất định mà bạn không thể phát triển bất cứ điều gì với mã đã nói đó. Tôi không nói rằng nó sẽ xảy ra, nhưng nó có thể :)
Simon

Tôi không khuyên bạn nên tạo mã không có cấu trúc. :) Tạo một trò chơi thay vì một công cụ không đồng nghĩa với việc tạo ra một mớ hỗn độn - không phải lúc nào cũng ..
jacmoe

Câu trả lời:


15

Đừng lo lắng về tương lai. Lo lắng về trò chơi hiện tại của bạn, bây giờ. Nếu không, bạn sẽ không nhận được bất cứ nơi nào vì bạn đang băn khoăn về các chi tiết.

Bạn nên tập trung vào việc xây dựng trò chơi trước và sau đó, nếu trò chơi đủ thành công, bạn có thể trích xuất nó thành thứ gì đó có thể tái sử dụng cho trò chơi tiếp theo của bạn. Điều này sẽ giữ cho bạn khỏi bị khóa vào một cái gì đó khác và cung cấp cho bạn toàn quyền kiểm soát dự án của bạn.


10

Xây dựng khung.

Tôi có kinh nghiệm xây dựng cả hai. Tôi thích sử dụng các thư viện trên khung. Các khung cảm thấy rất hạn chế và "hách dịch" . Vì vậy, khi tôi xây dựng trò chơi đầu tiên của mình, tôi muốn xây dựng một công cụ bao gồm nhiều thư viện có thể dễ dàng sử dụng lại trong các dự án khác.

Đó là một thảm họa. Nó đã dành một nửa thời gian của tôi để viết mã keo giữa các thư viện khác nhau của tôi. Các thư viện của tôi cũng có xu hướng bị phình to với sự trừu tượng hóa thêm, do đó nó trở thành một công việc lớn để thêm các tính năng cho các thư viện / thành phần.

Bây giờ, tuy nhiên các công cụ của tôi được xây dựng với trò chơi tôi đang viết. Tôi vẫn để mắt mở cho những thứ trừu tượng sẽ cho phép tôi sử dụng lại nó hoặc các tính năng mới mà tôi sẽ thêm vào trong các trò chơi sau này. Tôi hạnh phúc và năng suất hơn nhiều.

Đối với tôi, bước ngoặt là quyết định không công bố động cơ của tôi. Tôi vẫn có thể xuất bản nó, nhưng bây giờ biết rằng tôi không cần phải chứng minh các vụ hack cụ thể trò chơi của mình cho những người dùng khác đã cho phép tôi xây dựng một công cụ phù hợp hơn với các trò chơi của mình.


5
+1 về điều đó. Trên thực tế, tôi nghĩ người ta nên tập trung vào việc viết trò chơi của bạn, thay vì một công cụ để viết một trò chơi. Một động cơ sẽ xuất hiện sau khi một số trò chơi hoàn thành thành công. Đọc: scientificninja.com/blog/write-games-not-engines Quá nhiều dự án chết sớm vì họ đã cố gắng để viết một người mẹ chung của tất cả các động cơ ..
jacmoe

4

Tôi thấy cách này quá thường xuyên.
Tại sao phải xây dựng một công cụ, để sử dụng trong các trò chơi trong tương lai, khi bạn không biết những trò chơi nào cần?
Tại sao không xây dựng trò chơi trước, rồi sau đó, và một trò chơi khác, tái sử dụng thường xuyên nhất có thể.
Sau đó, bạn có một thư viện mã, có thể không có tổ chức, nhưng tất cả đều hiển thị là hữu ích.
Sau đó, bạn có thể đi về tổ chức nó.

Và đối với 'khung so với thư viện', tôi sẽ căn cứ vào việc bạn cảm thấy mệt mỏi như thế nào khi viết một vòng lặp trò chơi hết lần này đến lần khác. ;)

Một khung không nhất thiết phải khóa bạn. Hãy nhìn vào XNA.


Bạn có nghĩa là nói XNA không khóa bạn? Đó chính xác là những gì nó làm.
jsimmons

Tôi không thể thấy nó thực sự khóa bạn như thế nào. Bạn có muốn giải thích không?
Vịt Cộng sản

4

Giữ cho nó đơn giản.

Nếu bạn không chắc chắn cách nào để đi - chỉ cần làm bất cứ điều gì trò chơi của bạn yêu cầu. Cố gắng viết các thư viện nhỏ, cơ bản cho những thứ mà bạn cảm thấy có thể sử dụng được trong tương lai. Nhìn vào phát triển phần mềm dựa trên dữ liệu. Tôi đề nghị xem xét các hệ thống thực thể dựa trên thành phần. Đừng căn cứ mã xung quanh những thứ độc nhất như người chơi. Một người chơi chỉ là một đối tượng khác, giống như mọi thứ khác. Một thực thể có các thành phần, có lẽ là một danh sách các thành phần.

Bằng cách viết các thư viện nhỏ, chứa tương tác với nhau, bạn có thể tiếp tục và xác định thư viện nào sẽ sử dụng lại cho trò chơi tiếp theo của mình. Cá nhân tôi có những thứ như thư viện "container" cho các kiểu lưu trữ dữ liệu. Tôi có một thư viện toán học cho những thứ như vậy. Có một số thứ như thế này mà bạn có thể sắp xếp và viết dưới dạng các mô-đun. Máy ảnh, hiệu ứng, đầu vào, thực thể, chuyển động, vật lý, kết xuất, xử lý tài nguyên, luồng, danh sách tiếp tục.

Viết các thành phần độc lập nhỏ thường làm tăng khả năng đọc và gỡ lỗi mã của bạn.

Mike Acton và các trò chơi mất ngủ (www.insomniacgames.com) đã viết rất nhiều chủ đề và thảo luận liên quan đến phát triển trò chơi, đặc biệt là dựa trên dữ liệu. Nhìn chúng và xem loại thông tin nào quá phức tạp và bạn thấy thú vị và dễ hiểu. Họ là những nhà phát triển tuyệt vời với rất nhiều kinh nghiệm.


Trò chơi mất ngủ Yay! Một trong những văn phòng của họ ở gần tôi, ở Durham, NC và một số nhân viên đã có những buổi nói chuyện TUYỆT VỜI tại Hội nghị Trò chơi Tam giác vào mùa xuân vừa qua.
Ricket

Tôi đã xem xét một chút về phát triển theo hướng dữ liệu và chắc chắn là thứ tôi sẽ sử dụng. Đối với các thành phần tôi sẽ kiểm tra nó, đặc biệt là vì tôi không hoàn toàn hài lòng với phương pháp "chức năng" mà tôi đang làm ngay bây giờ.
Daemoniorum

@Daemoniorum: Nghe có vẻ hay, chỉ cần ném cho tôi một bình luận khác nếu bạn có thêm bất kỳ câu hỏi nào hoặc nếu bạn muốn một số trợ giúp / ý tưởng để thực hiện.
Simon

3

Tôi nghĩ rằng bạn đang làm khái quát hóa sớm. Đừng bị mắc kẹt quá nhiều cho các câu hỏi sử dụng trong tương lai ngay bây giờ. Chọn một câu trả lời và chạy với nó, học hỏi từ nó. Lật một đồng xu nếu bạn không có sở thích.

Bắt đầu bằng cách xây dựng một trò chơi. Khi bạn xây dựng trò chơi thứ hai của mình, bạn sẽ có ý tưởng tốt hơn những phần nào có thể sử dụng lại và có thể được chuyển thành các chức năng thư viện mạnh mẽ. Khi bạn xây dựng trò chơi thứ ba của mình, bạn sẽ có ý tưởng tốt hơn về cấu trúc nào có thể sử dụng lại được và có thể biến thành một khung mạnh mẽ.


2

Về tính linh hoạt, tôi nghĩ bạn đã trả lời câu hỏi của riêng mình: "Các khung có thể làm cho mọi thứ trở nên tốt đẹp và dễ dàng để phát triển, nhưng sau đó bạn bị khóa ." Điều này không có nghĩa là các khung phải không linh hoạt; mỗi trò chơi, ví dụ, có một vòng lặp trò chơi. Khuôn khổ XNA của Microsoft là 99% thư viện, nhưng trò chơi của bạn mở rộng lớp game mà chỉ cung cấp một vài chức năng trống cho những điều mà được đảm bảo để có trong mỗi trò chơi: LoadContent, Update, Draw. Đó là một ví dụ điển hình của khung không hạn chế.

Người ta có thể nói một khung công tác không gì khác hơn là một thư viện kết hợp với (các) lớp mẫu được nối vào thư viện, ít nhất đây là kinh nghiệm của tôi.

Tôi có xu hướng thích các thư viện hơn các khung. jMonkeyEngine , chẳng hạn, thật tuyệt nhưng đó là một khung và kết quả là tôi đã nhận thấy nó nhận được hàng tấn flak. SDL , mặt khác, là phổ biến đáng kinh ngạc; nó chỉ là một thư viện Nó cung cấp những gì bạn cần nhưng tránh ra để làm bất cứ điều gì bạn muốn với nó.

Với một thư viện, không nhất thiết phải dán nhiều thứ trên cơ sở từng trò chơi - đặc biệt nếu bạn viết các phần của thư viện để hỗ trợ từng phần của vòng lặp trò chơi; Chẳng hạn, bộ đếm thời gian / bộ đếm khung hình mỗi giây sẽ ngăn phần được viết lại thường xuyên không cần phải được phát minh lại với mỗi trò chơi.

Ngoài ra, các thư viện có thể chung chung hoặc cụ thể như bạn muốn làm cho chúng. Nếu bạn đang làm một trò chơi đua xe và bạn muốn thư viện của mình có các tính năng dành riêng cho đua xe, thì tốt thôi. Đó là sáng tạo của bạn và bạn có thể chọn chính xác mức độ linh hoạt mà bạn muốn. Điều này sẽ rất khả thi trong trường hợp bạn đang ký hợp đồng dài hạn với Nreb để phát triển nhiều game đua xe chẳng hạn. Bạn không nhất thiết muốn có một khung để có khả năng ràng buộc bạn vào một trò chơi đua xe vòng tròn cổ điển khi Nreb đến và yêu cầu một trò chơi offroad, nhưng bạn sẽ muốn có một thư viện dành riêng cho game đua xe vì bạn biết rằng Nreb không Sẽ không yêu cầu một game bắn súng.

Đây cũng là một mẹo để phát triển: nếu bạn viết thư viện cùng với một trò chơi, chắc chắn bạn sẽ vô tình kết hợp thư viện với trò chơi, hoặc làm cho nó quá không linh hoạt, cho dù bạn có lập kế hoạch bao nhiêu đi chăng nữa. Bạn sẽ tìm ra nó ngay khi bạn cố gắng tạo ra một trò chơi khác với nó, và bạn sẽ dành thời gian để tách nó ra; đây không hẳn là một điều xấu và bạn có thể quyết định làm điều này một cách có ý thức, vì bạn sẽ có nhiều thời gian rảnh hơn sau khi trò chơi đầu tiên của bạn được phát hành. Nhưng nếu bạn đang nhắm đến một thư viện xuất sắc từ việc di chuyển , hãy thử tạo hai trò chơi hoàn toàn khác nhau cùng một lúc và trích xuất các phần tương tự vào thư viện của bạn. Bạn sẽ nhận được rất ít khớp nối, nó sẽ linh hoạt hơn rất nhiều và trò chơi thứ ba của bạn có thể vẫn sẽ để lộ một số điểm yếu nhưng cuối cùng thư viện của bạn sẽ tốt hơn nhiều. Tuy nhiên, rõ ràng là khó hơn nhiều và tốn nhiều thời gian hơn để làm.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.