Làm thế nào để bạn đối phó tinh thần với một tác phẩm rất dài [đóng]


8

Đây là công việc đầu tiên trong ngành công nghiệp trò chơi của tôi và nhiệm vụ của tôi là đưa ra một thành phần trò chơi chính và đưa vào một thành phần mới hơn.

Cho đến nay đã được 5 tuần và tôi vẫn chỉ nhìn chằm chằm vào lỗi. Tôi nghĩ rằng nó có thể là vài tháng trước khi nó có thể biên dịch. Nó thực sự làm tôi thất vọng. Tôi chỉ thay đổi mọi thứ, tôi không thực sự viết bất cứ điều gì bản thân mình. nó chỉ là vô tận. Tôi sửa một ngàn lỗi và chín nghìn thay thế chúng.

Tôi chắc chắn đây là một điều phổ biến, vì vậy tôi chỉ tự hỏi, làm thế nào để bạn đối phó với điều này? Dường như tôi không thể chia nó thành nhiều phần nhỏ.


3
Eeek. Ai sẽ viết mã xấu đến mức phải mất hàng tháng chỉ để biên dịch!? Bạn có thể muốn suy nghĩ lại về cách bạn sẽ làm điều đó ... Một khi nó được biên dịch, nó sẽ đầy lỗi logic.
MichaelHouse

7
Câu hỏi này có lẽ phù hợp hơn tại lập trình viên.stackexchange.com (nếu có).
George Duckett

3
@GeorgeDuckett Một câu trả lời dành riêng cho ngành công nghiệp trò chơi có thể được cung cấp cho câu hỏi này liên quan đến các vấn đề bạn chỉ gặp phải khi lập trình trong ngành này. Trích dẫn nguyên văn, một phần của Câu hỏi thường gặp quyết định liệu câu hỏi mã thuộc về đây hay trên SO cũng cung cấp sự khôn ngoan: Nhà phát triển trò chơi chuyên nghiệp có cho tôi câu trả lời tốt hơn / khác biệt / cụ thể hơn cho câu hỏi này so với các lập trình viên khác không? Nếu có, sau đó cảm thấy tự do để hỏi nó ở đây.
doppelgreener

5
Tôi cũng bỏ phiếu cho điều này như là một câu hỏi lập trình chung. Anh ta tái cấu trúc một mớ hỗn độn mã lớn, đó là một trò chơi. Anh ta cần tư vấn lập trình / tái cấu trúc chung, không phải lời khuyên phát triển trò chơi.
Tim Holt

1
Không thể bài đăng này và câu trả lời của nó được di chuyển thay vì chỉ đóng cửa?
SirYakalot

Câu trả lời:


21

Chào mừng đến với ngành công nghiệp game :)

Vì vậy, bạn đang làm một tái cấu trúc lớn. Tái cấu trúc lớn là Ác, nhưng đó không phải là chủ đề. Có lẽ bạn đã được giao nhiệm vụ này để kiểm tra thần kinh của bạn, vì vậy đừng từ bỏ nó.

Câu trả lời của tôi là: bạn phải chia nó thành nhiều phần nhỏ. Nó sẽ là thói quen hàng ngày của bạn trong một vài tháng, vì vậy bạn phải học cách phân chia và chinh phục. Về cơ bản đó là công việc của bạn. Một vài gợi ý:

  • Hãy chắc chắn rằng bạn hiểu những gì thành phần này được cho là để làm . Chơi với những gì bạn phải đưa ra và xem những gì nó làm, hỏi đồng nghiệp của bạn nếu giả định của bạn là đúng.

  • Bạn đang viết lại mô-đun này vì một lý do. Nó có thể không rõ ràng đối với bạn, nhưng nếu bạn được giao nhiệm vụ này thì rất có thể bởi vì một cái gì đó quá nhảm nhí đến nỗi mọi người cảm thấy tốt hơn là bắt đầu lại từ đầu. Hỏi xung quanh: những khuyết điểm đó là gì?

  • Hãy thử tìm tính năng cốt lõi của thành phần bạn đang viết lại, chính chất của nó, lý do nó tồn tại và bắt đầu bằng cách làm cho thành phần này hoạt động. Nó phải thực sự nhỏ bé, nhỏ như bạn có thể. Hỏi đồng nghiệp của bạn về những gì họ nghĩ tính năng này sẽ được. Nếu đó là hệ thống GFX, chỉ cần làm cho nó hiển thị một đa giác. Nếu đó là một hệ thống hoạt hình, chỉ cần đặt một xương đúng cách. Nếu đó là một hệ thống AI, chỉ cần làm cho nó phát một hình ảnh động. V.v. Chỉ cần bỏ rác mọi thứ cản trở và cung cấp cho bạn tất cả những lỗi đáng ngại đó. Đừng bị làm phiền bởi các chi tiết, chỉ cần làm cho tính năng cốt lõi này hoạt động nhanh nhất có thể. Việc triển khai của bạn sẽ rất xấu, đầy lỗi và hack và số ma thuật và bạn sẽ không để ai liếc vào mã của mình, nhưng đó không phải là vấn đề.

  • Khi bạn đã có tính năng cốt lõi này, bạn sẽ bắt đầu cảm thấy tốt hơn. Điều cần thiết là phải xem kết quả công việc của bạn càng sớm càng tốt 1) cho tinh thần của bạn 2) để có thể kiểm tra nó. Vì vậy, kiểm tra nó, căng thẳng kiểm tra nó, tra tấn nó . Nếu nó gặp sự cố hoặc hiển thị một số lỗi thực sự xấu, hãy sửa lỗi này. Đó là trái tim của mô-đun của bạn, vì vậy hãy làm lại nó một chút và làm sạch nó cho đến khi bạn cảm thấy thoải mái với nó.

  • Sau đó đưa nó cho đồng nghiệp của bạn và hỏi họ nếu đó là những gì trò chơi cần. Yêu cầu đánh giá mã : các đồng nghiệp của bạn có thể sẽ cho bạn biết về nhiều điều mà bạn không nghĩ tới. Bạn sẽ phải cấu trúc lại một lần nữa để đảm bảo việc triển khai của bạn phù hợp với những gì phần còn lại của nhóm muốn.

  • Sau đó, khi bạn cảm thấy sẵn sàng cho nó, hãy chọn một trong những tính năng khác mà bạn đã dọn rác trước đó, rửa sạch, lặp lại. Làm cho nó hoạt động nhanh nhất có thể, làm lại, yêu cầu xem xét, làm lại.

Tôi phải nhấn mạnh lần cuối cùng về điều này: giao tiếp . Hỏi bạn đồng nghiệp, không chỉ người dẫn của bạn, không chỉ các lập trình viên, mọi người sẽ sử dụng hoặc kiểm tra hoặc đánh giá hệ thống này. Đừng sợ hỏi những câu hỏi ngu ngốc: khi nghi ngờ, tốt hơn hết là lấy thông tin ngay bây giờ hơn là đợi hàng tuần cho một cuộc họp hoặc đánh giá.

Thực tế của lập trình trò chơi là bạn sẽ không tạo ra các hệ thống mới sáng bóng hàng ngày, đó là công việc giữ sự tập trung và hoàn thành công việc một cách nhanh chóng và hiệu quả. Kéo mình lại, đi làm, và chúc may mắn!

BIÊN TẬP

Có thêm thông tin tôi thấy hữu ích trong nhận xét của Leo và câu trả lời của dhasenan, tôi không biết xấu hổ rằng họ sẽ hoàn thành câu trả lời này.

Tôi đã không viết về cách đối phó với sự phụ thuộc lẫn nhau . Mô-đun bạn đang viết có thể được kết hợp sâu sắc với phần còn lại của trò chơi, đó là lý do tại sao bạn gặp quá nhiều lỗi khi thay đổi điều gì đó. Vì vậy, có hai giải pháp:

  • Nếu chỉ có một vài phụ thuộc, thì bạn thật may mắn. Mô-đun cũ và mô-đun mới có thể được giữ song song trong một thời gian, bạn thậm chí có thể có một công tắc cho người dùng của mình để họ có thể quyết định thay đổi giữa mô-đun cũ và mô-đun mới bất cứ khi nào họ cần. Chỉ cần đặt một công tắc ở đâu đó, trong tệp cấu hình hoặc trong menu gỡ lỗi và sử dụng nó ở bất cứ nơi nào mô-đun của bạn được cắm vào phần còn lại của trò chơi. Khi mô-đun mới của bạn đã sẵn sàng để sản xuất, hãy bật công tắc theo mặc định. Sau này, khi mô-đun cũ không được sử dụng nữa hoặc khi cần sản xuất, hãy loại bỏ mô-đun cũ và công tắc.

  • Nếu có nhiềuphụ thuộc, bạn phải rút và cắm lại từng cái một. Cố gắng giữ cả hai mô-đun ở chế độ nền và mỗi khi bạn có một tính năng mới để hoạt động, hãy chuyển sang mô-đun mới cho tính năng đó. Tức là rút phích cắm và cắm lại những gì liên quan đến tính năng này. Bạn sẽ mất một chút thời gian vì có lẽ sẽ hiệu quả hơn thay đổi chỉ một lệnh gọi: một số cấu trúc dữ liệu có thể thay đổi, luồng chương trình có thể thay đổi, v.v. Nhưng vẫn tốt hơn là viết lại mọi thứ một lần và mất hàng tuần để giết con thú biên dịch. Nếu điều đó thực sự không thể giữ song song cả mô-đun cũ và mô-đun mới vì mô-đun của bạn rất quan trọng đối với trò chơi, bạn có thể cân nhắc viết lại tại chỗ. Nhưng hãy cẩn thận rằng điều này có thể có nghĩa là nếu các khiếm khuyết nằm trong giao diện của mô-đun cũ, bạn sẽ có cùng một lỗi. Dù sao, nếu điều này xảy ra,

Nếu có điều gì đó cụ thể để phát triển trò chơi video, thì đó là: chúng tôi không làm khoa học tên lửa, hoặc một công việc nghiên cứu phức tạp, chúng tôi là một phần của quá trình sáng tạo. Khi làm một cái gì đó, bạn phải tạo ra một phiên bản đầu tiên càng nhanh càng tốt để nó có thể được thử nghiệm, chơi, nhăn mặt và sửa đổi. Bạn không thể dành hàng tuần để thực hiện "một công việc rất dài" mà không cung cấp một chút.


Câu trả lời tốt, rõ ràng áp dụng không chỉ cho các trò chơi mà bất kỳ dự án.
Tim Holt

1
+1, chìa khóa mang đến cho tôi: không chỉ thử nghiệm , mà là tra tấn mã :) Đối với tôi, đây là lời khuyên tuyệt vời.
Stefan Hanke

5
+1, bạn phải chia một phép tái cấu trúc lớn thành các phần nhỏ. Tôi hoàn toàn đồng ý rằng đó là cách duy nhất để hoàn thành tái cấu trúc lớn. Lý tưởng nhất là thay đổi đoạn mã theo từng đoạn, đảm bảo mỗi thay đổi sẽ khiến hệ thống hoạt động (điều này sẽ giảm số lượng lỗi rất nhiều). Nếu điều này là không thể đối với chức năng đầy đủ, ít nhất hãy làm điều đó đối với một số chức năng cốt lõi. Thay đổi mọi thứ cùng một lúc là một cách chắc chắn tạo ra vô số lỗi khó tìm.
Leo

1

Bạn phải chia nhỏ nhiệm vụ của mình, nhưng không ai đưa ra lời khuyên về cách thực hiện điều đó.

  • Các mô-đun mới và cũ làm việc cùng nhau? Đó là, bạn có thể biên dịch dự án của bạn với cả hai? Điều này sẽ cho phép bạn ít nhất biên dịch và có thể chạy thử nghiệm tự động tại một số mốc quan trọng.
  • Bạn đang viết mô-đun mới? Hoặc là một mã cũ mà bạn sở hữu? Viết lại tại chỗ (trong trường hợp API bên ngoài vẫn giữ nguyên). Nếu bạn sửa một chức năng tại một thời điểm, bạn sẽ có thể tiếp tục sử dụng API mongrel kết hợp ở một mức độ nào đó.
  • Có dự án nào khác tại công ty sẽ thực hiện một quá trình chuyển đổi tương tự không? Viết các hàm bao quanh các mô-đun này để làm cho quá trình dễ dàng hơn vào lần tới. Nó có thể là giá trị làm điều này trong thời gian đó.
  • Bạn có thể bình luận hoặc tránh biên dịch các chuỗi phụ thuộc của bạn? Nếu bạn có tổng cộng nửa triệu dòng mã, có thể bạn có thể chia nó thành hai mươi phần biên dịch độc lập, để một công việc trong một vài tuần, và sau đó chuyển sang tiếp theo. Có thể không hoàn toàn độc lập mọi lúc, nhưng sau đó bạn có thể làm điều đó theo thứ tự phụ thuộc.

Ngoài ra: yêu cầu người quản lý của bạn cho lời khuyên. Tôi có lẽ sẽ bắt đầu mô tả vấn đề: mất quá nhiều thời gian để mọi thứ được biên dịch đúng cách mà khó theo dõi các thay đổi, điều này sẽ khiến việc gỡ lỗi trở nên khó khăn hơn khi bạn có thể kiểm tra. Sau đó, tôi sẽ đề cập đến một giải pháp tiềm năng và hỏi: "Làm thế nào để bạn khuyên tôi thực hiện giải pháp này, hoặc có cách nào tốt hơn để làm điều này hoàn toàn không?"

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.