Với thời gian vừa đủ để hoàn thành các trò chơi do chúng tôi tạo ra, làm thế nào bạn có thể đạt được sự cân bằng tốt giữa kiến trúc phần mềm vững chắc và đạt được tiến bộ tốt để hoàn thành tất cả?
Thử thách cá nhân của tôi: Làm thế nào về việc có hiệu quả ngày hôm nay và suy nghĩ lâu dài cùng một lúc? Ngoài ra, trong khi bạn đang làm điều đó, bạn có thể cũng muốn học những điều mới trên đường thay vì dùng đến những mô hình lặp đi lặp lại giống như bạn đã sử dụng trong 5 năm qua?
Câu trả lời:
Bạn càng có ít kinh nghiệm, bạn càng lãng phí thời gian với thiết kế phía trước. Làm cho các thiết kế tốt là một cái gì đó mà bạn sẽ học bằng cách thực hiện nó và sau đó xem / đánh giá nó diễn ra như thế nào. Một số quyết định đã vươn xa nhưng hàm ý tối nghĩa. Sau một số trò chơi, bạn có thể sẽ có thể làm cho thiết kế ban đầu khá chắc chắn và nó sẽ được đền đáp để đầu tư thêm thời gian cho giai đoạn này.
Phương châm của tôi: hoàn thành công việc ngay từ đầu, nhưng sử dụng ý thức chung của bạn để phát hiện thành phần nào quan trọng hơn các thành phần khác và thiết kế những thứ đó khá tốt, trong giới hạn thời gian của bạn. Ví dụ: nếu AI rất quan trọng đối với trò chơi của bạn, hãy đảm bảo rằng bạn có thể dễ dàng mở rộng / thay đổi nó sau này. Hoặc, nếu bạn định viết một thành phần mà bạn sẽ sử dụng trong mọi trò chơi, hãy thiết kế nó để có thể sử dụng lại. Theo dõi thời gian của bạn và đừng tự hào về thiết kế. Đặt thời hạn thiết kế và sau đó, bắt đầu hack mọi thứ để có thời hạn phát hành. Nhưng hãy chắc chắn rằng bạn lưu ý những điểm cần tái cấu trúc / thiết kế lại sau đó và tính toán trong một thời gian trước khi bạn bắt đầu trò chơi tiếp theo để cải thiện những điều đó, để họ không phải cắn bạn trở lại!
Một lời khuyên tốt: nếu bạn phải lựa chọn giữa hai lựa chọn, đừng nán lại quá lâu về chi tiết. Thông thường, không có "tốt" hay "xấu". Trong một số tình huống, A sẽ tốt hơn, trong một số trường hợp, B sẽ và nói chung, sự khác biệt giữa cả hai có thể không phải lúc nào cũng đáng giá.
Có rất nhiều kinh nghiệm để đạt được trong việc thiết kế phần mềm hoặc trò chơi, vì vậy hãy đảm bảo bạn dành một chút thời gian cho nghiên cứu (ví dụ: đọc một cuốn sách về thiết kế, đọc về kinh nghiệm của người khác, nói chuyện với các lập trình viên về thiết kế của bạn, v.v ... ).
Mọi người rất tệ trong việc dự đoán tương lai. Điều này đặc biệt đúng với các trò chơi, nơi các yêu cầu có thể thay đổi hàng ngày.
Có một nguyên tắc gọi là YAGNI , còn gọi là "Bạn không cần nó", về cơ bản nói rằng bạn không nên thực hiện một cái gì đó cho đến khi bạn biết bạn sẽ cần nó.
Tôi đã thấy rất nhiều hệ thống bị sa lầy với sự cứng nhắc về kiến trúc mà thực tế không sử dụng bất kỳ hệ thống nào vì các tính năng mà mọi người nghĩ rằng chúng sẽ không bao giờ được sử dụng.
Triết lý cá nhân của tôi là làm điều đơn giản nhất có thể làm việc . Điều đó đang được nói, có một sự khác biệt giữa Làm cho xong và Hacking cùng nhau. Viết mã với mục đích không nên ngụ ý làm những việc tạo ra "mùi mã" như làm cho mọi thứ trở nên công khai, có các lớp blob làm mọi thứ hoặc bất kỳ thứ gì trong số hàng tá những thứ khác biểu thị mã "xấu".
Điều này đánh giá là đúng trong suy nghĩ của tôi ngày hôm nay:
Tôi là bạn của phần mềm tạo mẫu nhanh. Đặc biệt là trong quá trình phát triển game. Nó tốt cho việc học nhanh, thử nghiệm và sử dụng mọi thứ. Đối với gần với lập trình phần cứng hoặc các thuật toán phức tạp là phương pháp tốt nhất đối với tôi.
Theory();
RapidPrototype();
bool bOk = false;
while(!bOk)
{
Testing();
LotOfFixing();
PlayingWith();
bOk= AnalysingResults();
}
FinalFastAndNiceDataStructuresAndCode();Phiên bản Rapid Prototype của tôi phải có lớp vỏ nguyên mẫu phù hợp:
Ưu điểm:
Nếu bạn làm tốt, bạn có thể có phiên bản gỡ lỗi / tìm hiểu thực sự của sản phẩm của bạn ở cuối.
Chúng tôi đang sử dụng nó trong dự án của chúng tôi và chúng tôi hài lòng với nó.
Có một cái nhìn về phát triển phần mềm nhanh nhẹn . Mặc dù nó không phải là viên đạn bạc, nhưng nó nhằm mục đích làm cả hai (hoàn thành nó và có thiết kế phần mềm vững chắc).