Những loại quản lý dự án nên sử dụng dự án phát triển solo?

Tôi đang tự mình làm việc trong một dự án trò chơi mà sự phát triển của nó có thể được tách thành 3 phần độc lập (tạo bản đồ, công cụ vượt qua giới hạn và công cụ chiến đấu), nhưng khi quá trình phát triển tiến triển, tôi không chắc mình nên giải quyết như thế nào việc quản lý dự án này, đặc biệt liên quan đến 3 điểm sau:

1. Có đáng để sử dụng hệ thống kiểm soát phiên bản không, vì tôi đang làm việc một mình?

2. Tôi có nên sử dụng một phương thức chính thức để đăng ký các tính năng / lỗi được lên kế hoạch không (tôi chỉ cần nhớ những gì cần phải làm ngay bây giờ)

3. Câu hỏi quan trọng nhất: làm thế nào tôi có thể biết phải phát triển cái gì trước? Bây giờ, những điều cơ bản đã được thực hiện, tôi biết danh sách các tính năng để viết mã nhưng tôi không biết tôi nên làm theo thứ tự nào.

Tôi sẽ dùng:

1. Quản lý mã

GIT (và tài liệu tham khảo tuyệt vời ), một trình quản lý mã nguồn phân tán, để quản lý mã của tôi và lưu trữ nó trên GitHub như một dự án riêng nếu tôi muốn giữ nó vượt quá giới hạn.

(Có rất nhiều tùy chọn ở đây, chỉ cần google để quản lý mã nguồn, bạn thậm chí KHÔNG CẦN sử dụng GitHub hoặc bất kỳ trang web nào khác, Git sẽ hoạt động tốt trên máy tính cục bộ của bạn, nhưng sử dụng GitHub sẽ gây khó khăn cho việc quản lý sao lưu dễ dàng hơn nhiều

Nếu bạn có hai máy tính, bạn có thể tạo một kho lưu trữ trên một máy tính mà bạn sẽ gọi cho máy dự phòng của mình, sau đó bạn sao chép kho lưu trữ đó qua mạng cục bộ và sử dụng nó để phát triển, khi bạn hoàn thành một tính năng, bạn có thể đẩy nó vào máy dự phòng và bạn sẽ có bản sao lưu 1: 1!)

2. Quản lý vấn đề & tính năng

Tôi sẽ sử dụng quản lý vấn đề tích hợp của Trello hoặc GitHub để theo dõi các lỗi và những việc cần làm.

3. Có quy trình thiết kế

Tôi sẽ thiết kế trò chơi của tôi đầu tiên;

1. đầu tiên trong tâm trí của tôi,
2. sau đó trên giấy,
3. sau đó có thể sử dụng GameMaker hoặc PyGame để tạo nguyên mẫu cho ý tưởng của tôi và lặp lại 1-3 cho đến khi tôi có thứ gì đó mà tôi thích chơi.

4. Sử dụng Nguyên mẫu của tôi làm Hướng dẫn và Phát triển Trò chơi của tôi

Sau đó, tôi sẽ đặt nguyên mẫu của mình sang một bên và chọn một nền tảng mà tôi muốn phát triển. Sau đó tìm kiếm các công cụ hiện có và chọn một công cụ phù hợp nhất với ý tưởng trò chơi của tôi. Sau đó, tôi sẽ thực hiện các mục tiêu rõ ràng cho dự án của mình, cấu trúc chúng thành các nhiệm vụ nhỏ và sau đó bắt đầu làm việc để hoàn thành các nhiệm vụ. Khi bạn đạt đến trạng thái này, rất có thể bạn sẽ thấy rằng bạn có cách làm việc riêng phù hợp với bạn nhất, vì vậy hãy đi với điều đó!

Có một số phương pháp / triết lý khác nhau mà bạn có thể áp dụng cho phong cách phát triển của mình, XP, Waterfall, v.v. Chỉ cần đi với phương pháp bạn cảm thấy sẽ khiến bạn tiến bộ nhanh nhất.

5. Có rất nhiều Game Testers!

Khi bạn có một cái gì đó có thể chơi được, hãy nhờ bạn bè ngay lập tức dùng thử! Giúp họ dễ dàng giúp bạn bằng cách thiết lập các gói trình cài đặt nhanh nếu họ đang chạy Windows hoặc viết một số tập lệnh shell có thể tự động hóa quy trình cho họ nếu họ đang sử dụng Linux / Mac. Hãy cẩn thận với phản hồi của những người thử nghiệm của bạn và đừng quên thông báo cho họ về thiết kế trò chơi của bạn và loại trò chơi mà bạn đang cố gắng xây dựng.

6. Tạo một trang web cho trò chơi của tôi

Ngay khi tôi có điều gì đó tốt, có lẽ tôi sẽ tạo một trang web cho trò chơi của mình - để duy trì sự sáng tạo và nội dung của tôi khi nó không thể được áp dụng cho tiến trình trò chơi của tôi, ví dụ, nếu tôi tập trung vào nghiên cứu của mình hoặc cần nghỉ ngơi từ sự phát triển!

Nếu tôi sử dụng GitHub , tôi sẽ thiết lập trang dự án cho trò chơi của mình, nếu không thì lưu trữ blog WordPress / Jekyll hoặc một cái gì đó tương tự và viết bài đăng của tôi với điều đó.

Điều này sẽ giữ cho bản thân bạn có động lực cũng như có một nơi để giới thiệu các game thủ / người thử nghiệm tiềm năng!

7. Tham gia các cuộc thi

Có rất nhiều cuộc thi dev game diễn ra gần như mọi lúc. Tôi sẽ cố gắng tham gia một trong những điều này với trò chơi của mình nếu luật lệ cho phép. Điều này làm tăng động lực và khiến mọi thứ trở nên thú vị hơn - những người không thích chiến thắng!

(Nếu bạn đang phát triển theo một thời hạn nghiêm ngặt, bạn có thể bỏ qua điểm này ít nhất.)

Tôi thực sự khuyên bạn nên sử dụng một hệ thống kiểm soát phiên bản, ngay cả khi bạn làm việc một mình. Nó có thể giúp bạn tiết kiệm rất nhiều thời gian, một khi bạn vô tình xóa một cái gì đó hoặc tạo ra một thay đổi lớn hơn, chỉ để nhận ra sau đó nó là một ý tưởng tồi và bạn phải hoàn tác các thay đổi.

Chỉnh sửa : Có nhiều giải pháp kiểm soát nguồn miễn phí.

• Tôi đã sử dụng Máy chủ VisualSVN , dễ cài đặt và sử dụng trong Windows.

• Ngoài ra còn có các lựa chọn thay thế trực tuyến như Codeplex (có SVNhoặc Mercurial), SourceForge hoặc Google Code . Ưu điểm là bạn không phải thiết lập và duy trì một kho lưu trữ và dữ liệu của bạn nằm trên đám mây; Điều thú vị là, bạn không thể tự do lưu trữ các dự án nguồn đóng.

Đối với theo dõi lỗi và tính năng: Nếu bạn đã có đối tượng lớn hơn có thể quan tâm đến việc thử nghiệm bản beta trò chơi của bạn, báo cáo lỗi và yêu cầu các tính năng, hãy tiếp tục.
Tuy nhiên, nếu chỉ có một số ít người như vậy (hoặc không có ai), thì không cần thiết.

Và đối với các ưu tiên phát triển - đó là để bạn quyết định. Ai nên biết rõ hơn phải làm gì trong một dự án hơn là nhà phát triển duy nhất của nó?

Có đáng để sử dụng hệ thống kiểm soát phiên bản không, vì tôi đang làm việc một mình?

Tôi nghĩ vậy. Việc cài đặt khá đơn giản và tôi đã nhiều lần phát điên với việc tái cấu trúc hoặc làm điều gì đó ngu ngốc khác và khả năng phục hồi các thay đổi của tôi đã tiết kiệm rất nhiều thời gian. Ngoài ra, nếu nó được lưu trữ trên một máy chủ thì bạn có một bản sao lưu mã của chúng tôi trong trường hợp có lỗi xảy ra .

Tôi có nên sử dụng một phương thức chính thức để đăng ký các tính năng / lỗi được lên kế hoạch không (tôi chỉ cần nhớ những gì cần phải làm ngay bây giờ)

Tôi không nghĩ nó cần thiết. Tôi sẽ giữ một danh sách bằng văn bản về những gì bạn định làm mặc dù chỉ để đảm bảo bạn không quên một lỗi nhỏ, cộng với tôi thấy nó giúp bạn bắt đầu lại sau khi nghỉ mã hóa.

Câu hỏi quan trọng nhất: làm thế nào tôi có thể biết phải phát triển cái gì trước? Bây giờ, những điều cơ bản đã được thực hiện, tôi biết danh sách các tính năng để viết mã nhưng tôi không biết tôi nên làm theo thứ tự nào.

Lấy danh sách đó ở trên, nhắm mắt lại và chọc ngẫu nhiên. Làm việc trên bất kỳ tính năng nào mà ngón tay của bạn đang bật. Trừ khi các mặt hàng phụ thuộc vào nhau, điều quan trọng hơn là chỉ để duy trì dòng chảy hơn là đảm bảo mọi thứ xảy ra theo bất kỳ thứ tự cụ thể nào.

Chắc chắn sử dụng kiểm soát phiên bản

Kiểm soát phiên bản giống như một mạng lưới an toàn cho người đi bộ chặt chẽ: nó giải phóng bạn để thử những thứ điên rồ. Một bộ tái cấu trúc lớn xóa các đoạn mã lớn không có vấn đề gì nếu bạn có thể dễ dàng hoàn nguyên. Nó thậm chí còn ít hơn nếu bạn ở một nhánh thử nghiệm trong repo của mình và có thể quyết định không hợp nhất nó lại.

Nếu bạn không có loại tự do này, bạn có thể để lại mã nhận xét ở khắp mọi nơi vì sợ rằng bạn có thể cần nó.

Tôi đã bỏ phiếu cho Git. Cú pháp hơi kỳ lạ, nhưng hai điều tuyệt vời về nó là:

• Chi phí thấp . Thay đổi thành một thư mục và nhập git initvà bạn đã sẵn sàng để bắt đầu kiểm tra nội dung. Nếu bạn quyết định bạn không muốn kiểm soát phiên bản đó, rm -rf .gittrong thư mục đó và đó không phải là repo Git nữa.

• Phân phối qua SSH . Git được phân phối, có nghĩa là bạn có thể có nhiều bản sao đầy đủ của repo của mình (tất cả lịch sử, v.v.) ở nhiều nơi khác nhau và giữ chúng đồng bộ. Bạn có thể thiết lập một repo Git khác trên bất kỳ máy nào có quyền truy cập SSH, sau đó thêm repo khác đó làm điều khiển từ xa. Sau đó, bất cứ lúc nào bạn muốn sao lưu chỉ git pushđể repo đó.

  Đó là một lợi thế lớn so với Subversion, nơi toàn bộ repo sống trên một máy và máy đó phải chạy máy chủ Subversion.

Mercurial có thể có những điểm tương tự như vậy, nhưng tôi chưa sử dụng nó.

1. Đúng! Vì bạn đang hỏi tôi đoán rằng bạn được chấp nhận tốt với hệ thống kiểm soát sửa đổi. Nó là phải!

2. Về câu hỏi thứ hai của bạn, có phương pháp chính thức để đăng ký lỗi và bạn nên sử dụng nó. Đối với các tính năng lập kế hoạch, tôi nghĩ rằng việc sử dụng bất kỳ tuyến đường ít chính thức nào sẽ không bị tổn thương (khi bạn đang làm việc một mình)

3. Làm những tính năng đầu tiên sẽ làm cho trò chơi của bạn trở nên sống động. Cho một cảm giác về cách chơi trò chơi cuối cùng sẽ diễn ra.

1) Có, tất nhiên. Tôi khuyên dùng Mercurial thông qua BitBucket và TortoiseHg. BitBucket miễn phí cho tối đa 5 người dùng và vì nó được lưu trữ trên đám mây nên bạn sẽ có thêm một chút lưu ý (không cần sao lưu).

2) Lỗi phải được sửa trước khi thực hiện các tính năng mới. Tôi sẽ sử dụng danh sách TODO có thể truy cập đơn giản để theo dõi mọi thứ - đang chờ xử lý / đã hoàn tất. Bạn có thể chỉ cần sử dụng một tệp văn bản đơn giản, đừng quên thêm nó vào kho lưu trữ kiểm soát nguồn của bạn.

3) Làm những gì bạn muốn làm vào bất kỳ ngày nào, trong khi hãy nhớ rằng việc cung cấp thứ gì đó có thể chơi được bởi người dùng cuối là mục tiêu chính. Ví dụ: nếu bạn cảm thấy mệt mỏi với việc sử dụng vật lý đúng cách, hãy thực hiện kết xuất hoặc có thể thêm một số bài kiểm tra đơn vị bị thiếu cho AI đó.

Những công việc cần đủ nhỏ để hoàn thành trong vài ngày. Điều quan trọng là giữ cho bản thân bạn có động lực và tránh kiệt sức.

Nếu kiến ​​trúc được thực hiện đúng cách, bạn sẽ có thể dễ dàng thêm một phần sửa đổi của công cụ / trò chơi mà không ảnh hưởng đến nhiều người khác (nếu không thì bắt đầu với một số tái cấu trúc :).

1) Như mọi người nói: CÓ (Tôi thậm chí sẽ nói, thuê một người trực tuyến giá rẻ)

2) Giữ một danh sách đơn giản hoặc nếu dự án của bạn phát triển lớn và bạn nhận được bản thử nghiệm beta, hãy cài đặt Trình theo dõi lỗi của Mantis

3) Tôi không biết, nhưng tôi sẽ nói cho bạn biết tôi đang làm như thế nào: Trước tiên hãy phát triển những thứ ít can thiệp nhất và / hoặc khó nhất. Lặp lại cho đến khi mọi thứ được thực hiện. Bằng cách đó, sự phát triển trở nên hài hước và dễ dàng hơn (và bạn sẽ không gặp phải vấn đề đó mà bạn không thể giải quyết quá muộn nếu điều đó xảy ra).

Cảm ơn đã hỏi câu hỏi này. Đây chính xác là những gì tôi đang làm hiện tại.

1) Kiểm soát phiên bản: Nó là phải. Ngay bây giờ, tôi đang duy trì sao lưu thủ công. Nó rất hữu ích khi một cái gì đó đang hoạt động tốt đột nhiên xuất hiện lỗi (hoặc không hoạt động như mong đợi). Tôi so sánh các phiên bản và thường thấy những lỗi ngớ ngẩn (chủ yếu là nhận xét một cái gì đó)

2) Tôi đã tạo một tài liệu từ và liệt kê tất cả các tính năng mà trò chơi của tôi sẽ có theo thứ tự phân loại và với các mức độ thụt lề đa cấp liệt kê các tính năng phụ (và liên quan đến máy khách / máy chủ hoặc những gì có thể áp dụng).

3) Sau khi danh sách tôi nhận được (thường không đầy đủ, hãy tiếp tục thêm vào đó) Tôi nghĩ về dòng chảy trò chơi của mình và làm sáng tỏ tất cả những điểm cần thiết để tôi làm cho trò chơi chạy và bắt đầu thực hiện chúng. Tôi đánh dấu màu vàng có nghĩa là công việc đang tiến triển. xanh khi hoàn thành. màu cam để chỉ ra được cải thiện hoặc có một số lỗi đã biết

hi vọng điêu nay co ich

1.) Nó đáng để sử dụng kiểm soát phiên bản cho bất kỳ dự án. Ngay cả những cái rất nhỏ nếu bạn đã biết cách sử dụng nó. Tôi đã sử dụng Subversion trong nhiều năm trên Linux và Windows với TortoiseSVN . Ngay cả khi thực hiện một dự án nhỏ (<500 dòng) tôi sẽ tạo một kho lưu trữ cho nó để tôi có thể hoàn tác các thay đổi, theo dõi những gì tôi đã làm nếu tôi từ bỏ dự án trong một thời gian, v.v.

2.) Phụ thuộc vào mức độ lớn của dự án. Nếu bạn đang dự định chơi thử với một nhóm và phân phối, có lẽ nên có một hệ thống theo dõi lỗi. Tôi hiện đang làm việc một mình (mặc dù tôi có một nghệ sĩ) trong một dự án dài hơn 20 nghìn dòng và tôi chỉ giữ danh sách việc cần làm của mình trong một tệp văn bản cũng nằm trong kho SVN của tôi. Mặc dù hiện tại tôi chưa có nhu cầu chia sẻ nó với người khác, vì vậy hiện tại việc không theo dõi lỗi phù hợp với nhu cầu của tôi. Tôi sẽ không lo lắng về nó cho đến khi có nhu cầu. Điều tồi tệ nhất có thể xảy ra là bạn sẽ phải nhập bất kỳ lỗi nào bạn đã viết ra và xóa / sửa lại những lỗi bạn đã sửa. Khi bạn bắt đầu mất dấu vết tinh thần của ghi chú của bạn, hãy lấy một trình theo dõi lỗi.

3.) Vẽ nó ra giấy. Bắt đầu với những gì bạn muốn trò chơi đã hoàn thành của bạn, viết ra ý chính của nó. Sau đó chia nó thành những gì nó cần để làm cho nó: phát hiện va chạm? mã mạng? loại người chơi và quái vật? phân cấp lớp? Làm việc lạc hậu từ tầm nhìn của bạn để bạn có được một ý tưởng rõ ràng về cách xây dựng nó từ đầu. Tôi đoán bạn đang sử dụng một ngôn ngữ hướng đối tượng. Bước quan trọng nhất khi bắt đầu sẽ là thiết lập các hệ thống phân cấp lớp theo cách hợp lý. Hãy cố gắng hết sức để không có nhiều quyền thừa kế (mặc dù đôi khi điều đó là không thể tránh khỏi), vạch ra các mối quan hệ lớp trong trình soạn thảo sơ đồ (tôi sử dụng Dia ), v.v ... Hiệu trưởng cơ bản đi một chặng đường dài để tránh đau đầu sau này.