Làm thế nào tôi nên mô hình hóa một trò chơi dựa trên nền kinh tế trong mã?


10

Tôi muốn tạo ra một trò chơi kinh tế dựa trên nền văn minh cổ đại. Tôi không chắc làm thế nào để thiết kế nó. Nếu tôi đang làm việc trên một trò chơi nhỏ hơn, như một bản sao của "Kẻ xâm lược không gian", tôi sẽ không gặp vấn đề gì khi cấu trúc nó như thế này:

  • Lớp điều khiển chính
  • Lớp đồ họa
  • Lớp người chơi
  • Lớp kẻ thù

Tôi không hiểu làm thế nào tôi làm điều này cho các dự án lớn hơn như trò chơi kinh tế của tôi. Tôi có tạo một lớp quốc gia có chứa một loạt các thị trấn không? Các thị trấn có chứa nhiều lớp xây dựng, hầu hết có chứa các lớp người không? Tôi có tạo một lớp tìm đường mà người chơi có thể truy cập để đi xung quanh không?


3
Bạn có thể muốn sử dụng một số dạng của Hệ thống thành phần thực thể (đây là tài liệu tham khảo chính tắc ) - hoàn toàn không có các thực thể tự vẽ (đặc biệt là nếu bạn có rất nhiều trong số chúng).
ThorinII

9
Bạn sẽ vô cùng ngạc nhiên khi thấy hầu hết các trò chơi "lớn" khủng khiếp, vô tổ chức và bị hack cùng nhau. Chúng được xây dựng xung quanh thời hạn và các mốc quan trọng. Chỉ cần viết một trò chơi và bất kỳ cấu trúc nào rơi ra khỏi những gì bạn cần viết sẽ trở nên tốt đẹp nếu không tốt hơn hầu hết các trò chơi AAA ngoài kia.
Sean Middleditch

Ngay cả khi bạn không thực hiện đầy đủ ECS, vẫn không bị trùng lặp mã, hãy để bộ điều khiển lặp lại các thực thể và gọi trình kết xuất hoặc thậm chí để trình kết xuất quét. Thực hiện cập nhật mã nhỏ ở 100 nơi là một nỗi đau.
MickLH

1
Theo tôi, việc nhảy từ Space Invaders sang một game phức tạp như bạn mô tả là hơi quyết liệt. Có nhiều bước học hỏi hơn giữa hai trò chơi này, trước khi bạn tham gia vào một dự án trò chơi lớn. Cân nhắc xây dựng một nền tảng hai bên 2D và tăng độ phức tạp của các trò chơi của bạn dần dần. Di chuyển từ thiết bị thứ nhất đến thứ năm có thể đưa bạn lên tới 120km / h, nhưng không có cùng hiệu quả (thời gian / công sức) sẽ có nếu bạn di chuyển từ cấp độ theo cấp độ.
Tiểu vương quốc Lima

2
Dường như bạn có hai câu hỏi ở đây và tôi không thể biết câu nào quan trọng hơn với bạn. Đầu tiên là về cách tránh truyền nhiều tham chiếu đến các đối tượng và thứ hai là về cách bạn nên tiếp cận ánh xạ các thực thể logic trong trò chơi của mình vào các lớp trong mã. Những câu hỏi có câu trả lời riêng biệt, và tôi nghĩ bạn nên đăng câu hỏi riêng biệt cho họ. Tôi sẽ chỉnh sửa phần "tránh chuyển tham chiếu" của bạn. Vui lòng đăng lại nó (và cũng xem xét việc tìm kiếm trang web này cho các chủ đề về "tránh các singletons và toàn cầu", vì các câu trả lời rất giống nhau).

Câu trả lời:


5

Tôi có tạo một lớp quốc gia có chứa một loạt các thị trấn không?

Chắc chắn rồi.

Các thị trấn có chứa nhiều lớp xây dựng, hầu hết có chứa các lớp người không?

Chắc chắn rồi.

Tôi có tạo một lớp tìm đường mà người chơi có thể truy cập để đi xung quanh không?

Chắc chắn rồi.

Tất cả mọi thứ bạn đã đề nghị ở trên có vẻ hợp lý. Nó có thể không phải là cách tốt nhất cho bạn về lâu dài, nhưng điều đó tốt. Nó rõ ràng có ý nghĩa với bạn biết vì đó là mô hình tổ chức lần đầu tiên đến với bạn. Điều quan trọng là bạn lấy nó và bắt đầu thực hiện từ nó. Cả hai sẽ giúp bạn bắt đầu, giúp bạn vượt qua "sự tê liệt thiết kế" ban đầu này thường gây khó khăn cho các nhà phát triển khi bắt đầu một nhiệm vụ và (nếu nó chứng tỏ là thiếu sót theo một cách nào đó) sẽ dạy cho bạn một vài điều về ưu và nhược điểm của phương pháp đặc biệt đó để thiết kế.

Bạn đã tự nhiên lấy các khái niệm trong đầu và nhóm chúng thành mã theo một số quy tắc đơn giản:

  • Khái niệm này có khác biệt đáng kể về hành vi hoặc dữ liệu từ các đối tượng khác mà tôi đã có không? (Các quốc gia và mọi người chia sẻ rất ít, nếu có, dữ liệu hoặc hành vi có ý nghĩa, vì vậy họ nên được thể hiện bằng các loại khác nhau trong trò chơi).
  • Tôi thậm chí có cần phải điều khiển khái niệm này theo mã một cách đáng kể không (nếu trò chơi của bạn giao dịch với từng người, bạn có thể cần Personlớp đó , nhưng nếu trò chơi chỉ quan tâm đến họ trong tổng hợp, như trong các phiên bản trước của SimCity, bạn có thể không cần loại đó cũng như các thể hiện của loại đó để tạo bản đồ 1: 1 về dân số của thị trấn. int populationCountcó thể là đủ).
  • Liệu khái niệm này đòi hỏi nhà nước ? Nếu vậy nó nên được gói gọn bằng cách nào đó cho phép tôi lưu trữ trạng thái này (một lớp) chứ không phải là một loạt các hàm miễn phí. (Việc triển khai tìm đường không có đối tượng trong thế giới thực tương tự, nhưng nó yêu cầu theo dõi dữ liệu như các nút trong bản đồ mà nó đã xem xét và điều đó được thực hiện tốt hơn thông qua một lớp hơn là lưu trữ trong một bó của các quả cầu ẩn và thực hiện các chức năng tự do).

Mặc dù đơn giản, việc trả lời những câu hỏi đó có thể mang lại lợi ích lớn cho bạn khi cố gắng quyết định xem và làm thế nào để chuyển đổi một khái niệm tinh thần thành mã nguồn. Bạn cũng có thể muốn đọc các nguyên tắc RẮN của thiết kế hướng đối tượng .

Lưu ý rằng đề xuất của một hệ thống thực thể / thành phần được đưa ra trong các nhận xét cũng là một cách tiếp cận hợp lệ, mặc dù tôi sẽ tránh nó ở đây trừ khi bạn tái phạm vi dự án của mình nhỏ hơn (đơn giản là vì thực hiện hai thách thức mới, lớn trong một dự án có thể quá nản chí và có thể làm loãng lợi ích giáo dục mà bạn sẽ nhận được nếu chỉ tập trung vào một). Trong mô hình hướng thành phần, "loại" trong các câu hỏi ở trên trở nên rõ ràng hơn: không phải là loại cụ thể trong mã, mà là loại ẩn được xác định bởi tập hợp các thành phần tạo thành một thực thể. Các nguyên tắc hướng dẫn tương tự có thể áp dụng.


1

Những gì bạn đã mô tả (một lớp cho mọi loại đối tượng trò chơi logic chính) có ý nghĩa hoàn hảo cho trò chơi đơn giản. Nếu đây là lần đầu tiên bạn viết một trò chơi kiểu này, tôi sẽ khuyên bạn nên làm theo cách này.

Chỉ cần một vài lời khuyên:

  • Là một chơi thực sự khác biệt so với một Enemy ? Rất nhiều chức năng có thể giống nhau, vì vậy những thứ này thường phải là cùng một lớp hoặc được mở rộng từ cùng một lớp cơ sở. Hãy xem xét một lớp cơ sở AbstractPlayer với hai lớp con HumanPlayerAIPlayer - tất cả các chức năng phổ biến có thể có trong AbstractPlayer .
  • Thích cấu hình các đối tượng với thành phần hơn là kế thừa. Đừng làm cho hệ thống phân cấp thừa kế của bạn quá sâu. Nếu bạn bắt đầu gọi một lớp ForgeWithSteelAnvil thì bạn nên lo lắng: Một Forge có thể là một lớp con của Tòa nhà , nhưng loại đe được sử dụng phải là một đối tượng có trong tòa nhà.
  • Tương tự như vậy thích các thuộc tính cho phép bạn định cấu hình các đối tượng thay vì thêm hàng trăm lớp đối tượng hơi khác nhau.

Trong các trò chơi phức tạp hơn, bạn có thể sử dụng các kỹ thuật nâng cao hơn, nhưng tôi khuyên bạn không nên sử dụng các kỹ thuật này cho đến khi bạn cảm thấy rất thoải mái với phương pháp OOP cơ bản (nghĩa là đã thực hiện thành công một vài trò chơi). Các phương pháp nâng cao hơn có thể bao gồm:

  • Các mô hình đối tượng dựa trên nguyên mẫu - sử dụng một lớp duy nhất cho tất cả các đối tượng trò chơi và mô hình hóa tất cả các đối tượng của bạn thông qua các thuộc tính / thuộc tính và thành phần. Linh hoạt / năng động hơn nhiều so với OOP tiêu chuẩn, nhưng khó quản lý hơn (đặc biệt, trình biên dịch sẽ không giúp bạn nhiều nếu bạn làm điều gì đó ngu ngốc). Tôi đã sử dụng điều này để tạo hiệu ứng tốt trong trò chơi Roguelike nhỏ của mình Tyrant ( https://github.com/mikera/tyrant )
  • Các hệ thống thành phần thực thể - tốt nếu bạn có nhiều hành vi phức tạp mà bạn muốn trộn và kết hợp trong nhiều loại đối tượng trò chơi khác nhau. Rất mạnh mẽ, nhưng khó để có được đúng.

0

Có một vài phương pháp mà bạn có thể sử dụng để tiếp cận tổ chức các thực thể và tập dữ liệu của mình. Tôi thích viết một tài liệu bảng tính và kiểm tra dữ liệu di chuyển qua lại để đảm bảo rằng tôi đang hoạt động hiệu quả. Nếu bạn đang tự làm game, hãy nhớ rằng nó cần có ý nghĩa với bạn. Đôi khi, lộ trình hiệu quả nhất là mã kém hiệu quả hơn một chút để làm cho dự án đơn giản hơn.

Nếu bạn muốn có thêm trợ giúp về cấu trúc nội dung của mình thì hãy tìm một mã nguồn trò chơi cũ sử dụng cấu trúc hoặc kiểu tương tự và tìm giải pháp của họ. Sau đó tinh chỉnh nó và sửa nó theo ý thích của bạn.


-1, vì điều này dường như không giải quyết được việc tổ chức mã và đề nghị sao chép một cách mù quáng những gì một số trò chơi khác làm mà không thảo luận về cách hiểu sự đánh đổi của bất kỳ quyết định thiết kế nào mà trò chơi đưa ra.
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.