Làm thế nào để hoàn thành một trò chơi? [đóng cửa]

Vấn đề của tôi là, bất cứ khi nào tôi bắt đầu lập trình một bản sao của trò chơi (để thực hành) hoặc trò chơi của riêng tôi hoặc một số vấn đề khác, tôi dừng lại ở đâu đó giữa quá trình phát triển, vì tôi mất hứng thú với nó.

Làm thế nào để bạn giữ mối quan tâm trong việc phát triển một trò chơi, hoặc phát triển nói chung?

Là một nhà thiết kế, tôi có xu hướng nghĩ về mọi người như là bộ sưu tập các số liệu thống kê và biến số. Khi bạn đặt câu hỏi của mình, tôi có thể dễ dàng hình dung [Pong_Dev_Interest] giảm và [Spa_Inv_Dev_Interest] tăng. Khi chênh lệch giữa hai mức lớn hơn [Dev_Project_Inertia] (phần nào liên quan đến [Dev_Completion_Desire]), hoạt động trên [Pong_Dev] tạm dừng và [Spa_Inv_Dev] bắt đầu.

Bằng tiếng Anh: Bạn không hoàn thành dự án vì mong muốn thô của bạn để xem một sản phẩm hoàn chỉnh bị ghi đè bởi sự thiếu quan tâm của bạn đối với dự án hiện tại. Nếu bạn thực sự muốn hoàn thành một, giải pháp duy nhất là chọn một (tôi sẽ đi với bản sao pong của bạn) và hoàn thành nó . Nói với chính mình "Bản thân tôi, tôi biết rằng có lẽ tôi có thể đã tinh chỉnh bản sao đó thêm một chút nhưng trời ơi, chắc chắn sẽ cảm thấy tốt khi đá một dự án ra khỏi cửa". Sau đó tiếp tục làm việc.

Khi bạn chán, hãy tiếp tục làm việc. Khi nó tuyệt vời, tiếp tục làm việc. Khi nó rơi xuống tào lao, tiếp tục làm việc! Kiên trì! Hãy là Dev nhỏ mà có thể! Tôi tin bạn!

À. Có một chút quá mức ở đó. Nhưng bạn có được sự trôi dạt.

Tôi đang làm theo lời khuyên của riêng tôi hàng ngày. Tôi đã làm cho môi trường của mình và các diễn viên hoạt động, được xây dựng trong điều kiện thắng và thua của tôi và tạo ra các đối tượng mà Người chơi sẽ sử dụng. Về cơ bản, tôi đã sẵn sàng để bắt đầu thực hiện một số thiết kế cấp độ và sự quan tâm của tôi giảm dần. Nhưng tôi làm một số mỗi ngày. Mỗi ngày. Một ngày nào đó tôi sẽ được thực hiện.

Và nó sẽ cảm thấy rất goooooood.

Tôi luôn tự hỏi mình cùng một câu hỏi và có một vài điều bạn có thể làm để thúc đẩy bản thân (rất nhiều trong số chúng đã được đăng ở đây). Điều làm việc tốt cho tôi là điều tôi đã nghe tại một trong những cuộc nói chuyện của Indie tại GDC năm nay, tôi nghĩ đó là người làm trò chơi ở Monaco :-)

Đầu tiên, tìm một dự án phù hợp với kinh nghiệm của bạn. Tức là đừng bắt đầu tạo FPS nếu bạn thậm chí không biết những điều cơ bản về OpenGL / DirectX. (trừ khi bạn đang sử dụng công cụ trò chơi nhưng đó không phải là vấn đề ở đây ;-))

Sau đó, tạo cho mình một danh sách những việc cần làm và các cột mốc bạn muốn đạt được, để bạn luôn biết nơi để đi. Các TODO là phần quan trọng. Xác định các nhiệm vụ của bạn sao cho mỗi nhiệm vụ có thể dễ dàng được thực hiện trong một ngày hoặc trong một vài giờ . Vì vậy, khi bạn bắt đầu viết mã, thiết kế, mô hình hóa, v.v. bạn đã thấy ánh sáng ở cuối đường hầm. Không có gì đáng buồn hơn là thiết kế và mã hóa Game Engine lớn của bạn trong một tháng mà không tiến gần đến đích. Chia nhỏ các nhiệm vụ lớn thành các nhiệm vụ nhỏ hơn. Hoàn thành một nhiệm vụ nhanh chóng thực sự bổ ích và giúp bạn tiếp tục. Ví dụ, đây là danh sách nhiệm vụ của tôi cho một game bắn súng không gian nhỏ cùng một lúc:

• Hiệu ứng âm thanh
• Âm nhạc
• Tàu sửa sang lại
• Tên lửa Remodel
• Phát hiện colination giữa các phát bắn và người chơi / kẻ thù
• Làm kẻ thù bắn
• Màn hình tiêu đề
• Điểm / Sống / Năng lượng Dù lớp phủ

Tất cả các nhiệm vụ này đều dễ thực hiện và một khi chúng hoạt động trong trò chơi, bạn có thể lặp lại trên các khu vực đó và đánh bóng chúng.

Và này, tôi đã hoàn thành một trò chơi nhỏ. Nó không đẹp nhưng về cơ bản nó đã được thực hiện rất xứng đáng :-)

Bạn phải xác định vấn đề trước khi bạn có thể giải quyết nó. Tại sao bạn mất hứng thú?

Đối với tôi, điều đó thường xảy ra bởi vì tôi dành quá nhiều thời gian cho khung công tác và sau nhiều tuần, tôi thậm chí không thể có được một yếu tố chơi trò chơi nào.

Một cách tôi tìm thấy để cải thiện động lực của mình là tạo mẫu lặp lại, hoặc một số hình thức Phát triển hướng thử nghiệm. Thông thường liên quan đến việc tự động hóa các trường hợp thử nghiệm, nhưng vì các trò chơi đòi hỏi nhiều đồ họa, bạn không thể tự động hóa màn hình và hoạt hình dưới dạng thử nghiệm, nhưng logic trò chơi của bạn có thể được tự động hóa.

Đối với những phần không thể tự động hóa, về cơ bản tôi sẽ lên kế hoạch cho một vài cột mốc cho trò chơi. Mốc 1 có thể sẽ được hiển thị một sprite trên màn hình và làm cho WASD hoạt động, ví dụ. Dần dần, tôi sẽ thêm nhiều tính năng và tái cấu trúc.

Đó là một hình thức phân chia và chinh phục. Chia thành các phần nhỏ, làm việc với người bạn cảm thấy thoải mái, sau đó hòa nhập. Rửa sạch và lặp lại. Cuối cùng, bạn có thể thấy một cách sắp xếp lại công cụ tốt hơn và bạn có thể cấu trúc lại mã của mình. Thật lộn xộn khi không có kiến ​​trúc phía trước, nhưng thông thường khi bắt đầu lập trình, thật khó để hình dung kiến ​​trúc cho đến khi bạn có một vài năm kinh nghiệm.

Tôi cố gắng tìm một số phần dễ dàng hơn để thực hiện. Giống như nếu tôi không thể tìm ra cách tạo ra thứ gì đó hoặc không làm, tôi chuyển bánh răng và làm mô hình hoặc viết một shader, v.v.

Xem bài này và bài khác.

Nếu bạn không biết cách cấu trúc chính xác một trò chơi, bạn nên bắt đầu học cách trừu tượng hóa các yếu tố của chúng thành các khối độc lập với trò chơi. Điều này có thể giúp bạn theo nhiều cách (ngoài việc thú vị), chẳng hạn như: trải nghiệm phân chia trừu tượng với việc triển khai, khai thác tốt hơn tính kế thừa và thiết kế giao diện hoặc chỉ cách đưa trò chơi vào nhiều tệp để nó trông chuyên nghiệp (hoặc để cung cấp tính khả thi của việc triển khai bằng cách sử dụng các thư viện liên kết động hoặc sử dụng giao diện khác). Sớm muộn gì bạn cũng sẽ nhận ra rằng mọi thứ đều có thể được thực hiện và sau đó bạn sẽ tìm thấy chính mình mà không gặp phải vấn đề động lực đó nữa (bạn chỉ cần làm điều đó).

Tôi đã gặp vấn đề tương tự khi tôi bị mắc kẹt lúc đầu, nhưng giải pháp tốt nhất là tiếp tục di chuyển, hoặc bạn có thể trì hoãn mãi mãi cho đến khi một cái gì đó đặt lại cho bạn bằng cách nào đó (và nó có thể mất quá nhiều thời gian). Sẽ không có vấn đề gì nếu bạn chỉ viết mã 2 dòng một vài ngày, nhưng mỗi ngày bạn ít nhất phải mở dự án và cố gắng cải thiện một cái gì đó (đó là một nhiệm vụ không bao giờ xảy ra nhưng đó không phải là vấn đề).

Nếu tại một thời điểm nào đó chương trình không hoạt động, bạn nên hoàn tác những gì bạn đã làm (giữ bản sao lưu sử dụng svn hoặc ít nhất là .rar với tên ngày) đến một điểm mà nó đã hoạt động và cố gắng thực hiện một lần nữa, hoặc làm việc với những thay đổi khác bạn cần làm cho đến khi bạn muốn thử lại.

Lúc đầu, bạn nên cố gắng sửa lỗi với sự trợ giúp của trình gỡ lỗi, nhưng tôi không biết liệu ngôn ngữ của bạn có hỗ trợ trình gỡ lỗi không ... nhưng nếu bạn tình cờ sử dụng C ++ hoặc một cái gì đó tương tự (tôi sẽ khuyên bạn nên muốn tạo trò chơi), bạn nên sử dụng trình gỡ lỗi tốt hơn vì nó sẽ giúp bạn rất nhiều trong việc tìm ra lỗi nhanh trong một lần chạy.

Đọc về lập trình trò chơi cũng là một điều tốt để tiếp tục chủ đề nếu bạn không muốn làm việc trên bất cứ điều gì cụ thể. Có một số sách và bài viết hay về công cụ và thiết kế trò chơi bạn có thể tìm thấy trực tuyến.

Bạn sẽ không thể làm bất cứ điều gì nếu bạn không thực hành. Cố gắng tìm một lỗi có thể rất khó chịu lúc đầu nhưng sau đó bạn biết rằng nó thực sự dễ dàng nếu bạn biết cách làm điều đó. Đây là điều bạn học được cách tránh theo thời gian, bằng cách mã hóa theo cách mà các thay đổi của bạn không tác động trong toàn bộ chương trình, giảm số lượng địa điểm tìm lỗi. Nếu mỗi khi bạn gặp khó khăn, bạn sẽ từ bỏ, sau đó mỗi lần bạn nghĩ đến việc làm một trò chơi, bạn sẽ từ bỏ trước khi bắt đầu. Chỉ cần học cách vượt qua khoảnh khắc tồi tệ bằng cách vượt qua nó: P Nếu bạn không vượt qua khoảnh khắc mà bạn mất động lực, sự lười biếng của bạn sẽ chiến thắng, và bạn sẽ thua, đó là cách nó hoạt động, cho đến khi bạn học cách lấy lại động lực không cần nỗ lực nhiều

Tái bút: Tôi đã tự hỏi ... bạn đang sử dụng cái gì để tạo ra trò chơi?

[có nghĩa là để lại như một bình luận cho câu trả lời của anon, đã bị xóa khi tôi đăng nó. Anh ta đề cập rằng anh ta có tất cả các chức năng này hoạt động, sau đó chia mã tập tin duy nhất thành nhiều tập tin, chỉ để mọi thứ tan vỡ]

Re: tái cấu trúc, công cụ có thể xảy ra, thậm chí để thuận. Đôi khi ngay cả với các công cụ tốt như Git, việc hợp nhất có thể thất bại vì vậy thay vì cả tính năng A và tính năng B đều hoạt động, cả hai đều không hoạt động! Lựa chọn duy nhất là quay lại A và thử lại. May mắn kiểm soát phiên bản sẽ lưu mã này cho bạn; nếu bạn không sử dụng kiểm soát phiên bản thực, ít nhất hãy thực hiện thủ công bằng cách nén thư mục dev của bạn thường xuyên - không gian HD rẻ! Để kết luận, hãy quay lại những gì hoạt động và tái cấu trúc trong các bước nhỏ hơn, đảm bảo trò chơi vẫn hoạt động ở mỗi bước. Thật là chán nản khi làm sạch mã chỉ để thấy mọi thứ sụp đổ. Chỉ cần trở lại mã cũ.

Để duy trì động lực, hãy tiếp tục nói với bản thân rằng bạn đang tạo ra một trò chơi, không phải là một công cụ trò chơi - tốt, trừ khi đó là điều của bạn. Và điều đó thật tuyệt, công cụ trò chơi rất tuyệt, nhưng chúng quá thường xuyên cản trở việc tạo ra các trò chơi.

Để minh họa quan điểm của tôi, tôi có thể cho bạn biết mọi thứ thường diễn ra như thế nào: lúc đầu bạn tạo một vài họa tiết, di chuyển chúng trên màn hình với khung proto của bạn và bạn sẽ rất hồi hộp! Bạn có thể thấy sự tiến bộ của bạn và nó đang diễn ra tốt đẹp; bạn có thể chỉ cho bạn bè của bạn.

Sau đó, một khi bạn đã chơi với khái niệm của mình một chút, bạn nhận ra rằng bạn cần làm cho khung (hoặc công cụ trò chơi) của bạn linh hoạt hơn. Hoặc là bạn nên xác định lại một số lớp không tuân theo các mẫu mới nhất. Và từ đó, bạn dấn thân vào vòng xoáy tử thần: bạn ngừng làm việc với một trò chơi và bạn bắt đầu làm việc với một công cụ trò chơi. Và công cụ trò chơi gần như không thú vị để thực hiện. Bạn có thể dành hàng giờ để tái cấu trúc và không có gì để hiển thị cho nó - trong trò chơi. Và sau đó, bạn mất hứng thú.

Vì vậy, hãy nhớ: làm cho trò chơi, không phải công cụ trò chơi. Chỉ tái cấu trúc khi bạn cần. Đừng quá linh hoạt - chỉ ở mức tối thiểu. *

*: tất nhiên tái cấu trúc và tính linh hoạt là quan trọng. Nhưng không quan trọng bằng việc thực sự có một trò chơi đã hoàn thành.

Cố gắng tạo một phiên bản có thể chơi trong một ngày, cho dù đơn giản như thế nào. Sau đó lặp đi lặp lại.

1. Đừng cố làm cho trò chơi của bạn quá phức tạp!

2. Chia nhiệm vụ của bạn thành các nhiệm vụ nhỏ, cụ thể, có thể đo lường được. Nếu bất kỳ nhiệm vụ con nào có vẻ quá lớn, thì hãy chia nhỏ nó hơn nữa.

3. Đảm bảo rằng bạn viết "DONE" bằng chữ lớn trong danh sách nhiệm vụ của mình (tôi sử dụng tệp .txt) khi tác vụ của bạn hoàn thành. Đừng xóa nhiệm vụ, vì sau đó nó sẽ không giống như bạn đang tiến bộ.

Đây là những gì tôi làm. Nó đã hoạt động trong quá khứ.