Tôi là một ngàn dòng mã để tạo ra trò chơi dựa trên không gian 2D của riêng tôi, tạo ra các mạng lưới các hệ sao được tạo ngẫu nhiên và tạo cho chúng một lựa chọn ngẫu nhiên các hành tinh, trạm, tàu và vũ khí.

Có khả năng sẽ có hàng trăm trạm / tàu / vv khác nhau mà trò chơi sẽ cần sử dụng - vì vậy đây là điều tôi đã tự hỏi. Tôi có nên dành thời gian để tạo một trình tải dữ liệu 'mã hóa mềm', sẽ lưu trữ tất cả thông tin này trong (ví dụ) các tệp XML, và do đó sẽ dễ dàng sửa đổi hơn sau đó, hoặc tôi chỉ nên đi với những gì tôi đã đang làm ngay bây giờ - mã hóa tất cả các đối tượng vào công cụ chính của trò chơi.

Tôi là người duy nhất trong dự án, và như tôi đã nói, đó chỉ là một sở thích mà tôi đang làm trong thời gian rảnh rỗi ở trường đại học. Nhưng cộng đồng có khuyên bạn nên đầu tư vào việc tạo ra toàn bộ hệ thống lưu trữ dữ liệu bổ sung trong các tệp bổ sung không?

Lợi ích của dữ liệu mã hóa theo cách như thế này, so với việc đơn giản hóa mã hóa tất cả thông qua các nhà xây dựng là gì? Có lợi ích lâu dài khi có các tệp bên ngoài có thể được sửa đổi - nếu tôi không tìm kiếm trò chơi để có 'mod', có cần phải có các tệp bên ngoài không? Nếu đó chỉ là một sở thích mà tôi có thể từ bỏ trong vài tuần hoặc vài tháng, tôi có nên lãng phí thời gian cho việc này không?

Vâng. Bạn nên thực hiện một hệ thống để tải nội dung bên ngoài công cụ chính của bạn.

Tiêu đề cho câu trả lời ngắn gọn.

Không. Nó không tiêu tốn quá nhiều thời gian.

Tôi nghĩ rằng câu hỏi liệu đó có phải là sự phân bổ hợp lệ thời gian giới hạn của bạn hay không; ngay cả khi chỉ vì thực tế rằng nó sẽ là một phần nhỏ trong tổng thời gian dự án.

Bạn sẽ dành hàng trăm (hàng ngàn) giờ cho một dự án trò chơi mà bạn mất để hoàn thành. Có lẽ không phải trên một bản sao của Pong, nhưng chắc chắn là như vậy đối với trò chơi không gian phức tạp của bạn. So sánh với một trình đọc tập tin cấu hình. Thực hiện một hệ thống để ống XML vào constructor chính của bạn, và sau đó khởi động lại để quá trình trò chơi, sẽ mất có lẽ 10 hoặc 20 giờ. Ngay cả khi bạn mất 50 hoặc 100, nó sẽ chỉ là một phần rất nhỏ trong tổng thời gian dự án.

Nó sẽ tiết kiệm thời gian

Đó không phải là một chi phí thời gian; đó là một khoản đầu tư thời gian. Và nó sẽ được đền đáp.

Vấn đề về quy trình làm việc và có một trình tải cấu hình sẽ giúp công việc của bạn tốt hơn. Bằng cách tạo một hệ thống cho phép bạn chỉnh sửa cấu hình một cách nhanh chóng, bạn sẽ tiết kiệm được vô số bản dựng lại. Bạn có thể xem trò chơi trong khi trò chơi đang chạy, điều chỉnh XML và kiểm tra lại sau vài giây. Hoặc bạn có thể xem mã, tìm một dòng mã (trong số hàng ngàn), chỉnh sửa giá trị của nó cực kỳ cẩn thận (bạn đang ở trong công cụ chính của mình), xây dựng lại, thực thi, đưa trò chơi trở lại trạng thái thử nghiệm, cố gắng hết sức nhớ những gì nó trông giống như trước khi thay đổi, và xem nếu thay đổi của bạn có ảnh hưởng mà bạn dự định. Giả sử không có gì phá vỡ trong động cơ của bạn, tàu của bạn mặc dù chắc chắn bị gián đoạn.

Từ góc độ comp-sci cơ bản hơn, hãy cố gắng nhớ rằng phần tốn nhiều thời gian nhất của phần mềm viết là không có thêm một vài lần nhấn phím hoặc khoảng trắng. Đó là săn bọ. Và nếu bạn dành thêm một chút thời gian để làm cho mọi thứ rõ ràng hơn bằng cách viết thêm mã dài dòng, bạn sẽ tiết kiệm cho mình nhiều thời gian hơn sau đó. Trong trường hợp của bạn, viết một trình nhập nội dung dẫn đến mã sạch hơn sẽ dễ đọc hơn. Thay vì dặm của các giá trị hardcoded, nguồn của bạn sẽ có một tải tập tin đơn giản. Tương tự như vậy, bạn có thể đọc tệp cấu hình mà không cần lội qua mã công cụ trò chơi. Cả hai phần trở nên dễ bảo trì hơn và dễ gỡ lỗi hơn.

Các đội một thành viên được hưởng lợi nhiều nhất

Nếu bạn thuê một nghệ sĩ để tạo ra một số nội dung đó, bạn sẽ cần phải tạo ra các công cụ để họ làm việc. Họ cần thực hiện chỉnh sửa pixel và xem hiệu ứng nhanh chóng. Bạn sẽ không dám buộc họ xây dựng lại mã để xem mọi thay đổi. Thời gian của họ rất tốn kém và bạn không muốn lãng phí nó.

Bây giờ hãy tưởng tượng rằng nghệ sĩ rất không có kỹ năng và chậm (nghệ sĩ lập trình viên), và có rất nhiều thứ khác phải lo lắng vì họ cũng là lập trình viên và nhạc sĩ chính. Bạn chắc chắn không muốn lãng phí thời gian đó, hoặc dự án sẽ không bao giờ kết thúc. Và, nghệ sĩ nhảm nhí đó sẽ ghét đào tạo để trở thành một nghệ sĩ tốt hơn, bởi vì họ dành toàn bộ thời gian để đổi tên chuỗi tài sản theo mã.

Đừng làm điều đó với chính mình. Tạo các công cụ, và bạn sẽ có nhiều thời gian hơn để làm một trò chơi.

Đây là một câu hỏi hay và câu trả lời tốt nhất tôi có thể đưa ra là chỉ có kinh nghiệm mới thực sự có thể cho bạn biết khi nào nên đi theo con đường khó khăn / tốn thời gian hơn. Nếu bất cứ ai nói với bạn rằng bạn LUÔN LUÔN làm theo cách 'đúng đắn', thì đơn giản là họ đã sai.

Bạn đã hiểu rằng đó là một tradoff. Một mặt, mã hóa rất hấp dẫn bởi vì nó nhanh chóng và dễ dàng để đi, nhưng về lâu dài việc thêm các tính năng và gỡ lỗi sẽ trở thành ác mộng. Mặt khác, viết một hệ thống tuyệt vời, linh hoạt, có thể mở rộng đòi hỏi một khoản đầu tư ban đầu lớn, nhưng làm cho cuộc sống trở thành một địa ngục dễ dàng hơn rất nhiều trong thời gian dài.

Mục tiêu là để hoàn thành một cái gì đó, và nếu bạn bị sa lầy vào việc tạo ra một hệ thống tuyệt vời, mục tiêu sẽ lùi xa hơn và bạn sẽ mất động lực. Công cụ mã hóa cứng là tốt trong một số trường hợp nhưng bạn phải hiểu sự phân nhánh của việc thực hiện nó. Dưới đây là một số lý do tại sao mã hóa cứng là một ý tưởng tồi:

• Bạn có thể nghĩ rằng dự án của bạn nhỏ, nhưng có thể nó phát triển khi bạn quyết định thêm nhiều tính năng hơn. Nếu bạn bắt đầu mã hóa, sẽ đến lúc năng lượng cần thiết để duy trì nó (cập nhật nó với các công cụ mới và sửa chữa vô số lỗi không thể tránh khỏi) sẽ bắt đầu nghiêm trọng hơn mức tăng ban đầu.

• Công cụ mã hóa cứng là theo định nghĩa cụ thể cho dự án hiện tại. Đối với dự án tiếp theo, bạn sẽ phải bắt đầu lại từ đầu, có thể là mã hóa lại công cụ (vì đó là những gì bạn sẽ thấy thoải mái). Nếu bạn đã dành thời gian vào một hệ thống tải tốt, bạn có thể bỏ qua công việc đó và đau đầu cho tất cả các dự án trong tương lai.

• Bạn có thể đang làm việc một mình tại thời điểm này, nhưng có thể sẽ đến lúc bạn muốn đưa người khác vào dự án. Bạn sẽ dành thời gian để giải thích hệ thống đơn vị kinh tởm của bạn và viết tài liệu cho nó?

• Mã hóa cứng thường liên quan đến việc phải biết một số phép thuật nhất định có nghĩa là gì, hoặc phụ thuộc lớp phức tạp. Bạn có thể có thể giữ tất cả trong tâm trí của bạn bây giờ, nhưng chỉ cần đợi cho đến khi bạn rời xa mã một lúc. Ngay cả với những bình luận sâu rộng, một cấu trúc được thiết kế tồi là địa ngục để quay trở lại.

Tôi muốn nói rằng bạn nên thoải mái với những thứ mã cứng chỉ trên những chi tiết nhỏ nhất. Nếu bạn có một khái niệm nhỏ nhất về yếu tố bạn đang làm việc đang được người khác sử dụng, ngày càng lớn hơn hoặc được sử dụng trong một dự án khác, thì hãy dành thời gian để làm điều đó ngay bây giờ.

Mặt khác, tôi nguyên mẫu như một người điên và mã hóa một số thứ nhất định là nhanh chóng và dễ dàng và để bạn tự do tập trung vào thử nghiệm. Nó phụ thuộc vào phong cách làm việc của bạn.

Những gì bạn đang nói là lập trình dựa trên dữ liệu .

Đối với các dự án nhỏ, nó có thể không đáng để đầu tư thời gian, vì thường có nhiều tính năng quan trọng hơn mà bạn có thể cải thiện.

Tuy nhiên, lập trình hướng dữ liệu có thể RẤT dễ thực hiện. Nếu bạn nghiêm túc về điều đó, có lẽ bạn nên sử dụng XML, JSON hoặc YAML, nhưng bạn cũng có thể sử dụng các tệp văn bản thuần túy.

Lập trình dựa trên dữ liệu

Ưu

1. Cho phép các nhà thiết kế truy cập và sửa đổi dữ liệu trò chơi mà không cần kiến ​​thức lập trình
2. Bạn có thể sửa đổi trò chơi mà không cần phải biên dịch lại . Điều này không nên được đánh giá thấp, vì bạn có thể phát triển một trò chơi nhanh hơn nhiều theo cách này. Trò chơi tốt đến sau nhiều lần lặp lại.

Nhược điểm

1. Phải mất thời gian và nỗ lực để thực hiện.
2. Nó có thể làm tăng sự phức tạp của chương trình.