Jakiego zarządzania projektami powinien używać projekt solisty?

Pracuję sam nad projektem gry, którego rozwój można podzielić na 3 niezależne części (generowanie map, silnik „overworld” i silnik bitewny), ale w miarę rozwoju nie jestem pewien, jak powinienem sobie z tym poradzić zarządzanie tym projektem, szczególnie w odniesieniu do tych 3 punktów:

1. Czy warto używać systemu kontroli wersji, ponieważ pracuję solo?

2. Czy powinienem użyć formalnej metody, aby zarejestrować planowane funkcje / błędy (po prostu pamiętam, co trzeba teraz zrobić)

3. Najważniejsze pytanie: skąd mam wiedzieć, co najpierw opracować? Teraz, gdy podstawy są już gotowe, znam listę funkcji do kodowania, ale nie wiem, w jakiej kolejności powinienem to zrobić.

Użyłbym:

1. Zarządzanie kodem

GIT (i niesamowite referencje ), rozproszony menedżer kodu źródłowego, do zarządzania moim kodem i hostowania go w GitHub jako prywatny projekt, jeśli chcę go trzymać z dala od limitów.

(Istnieje wiele opcji, po prostu google do zarządzania kodami źródłowymi, nawet NIE POTRZEBUJESZ korzystania z GitHub lub innej strony internetowej, Git będzie działał dobrze na twoim komputerze lokalnym, ale korzystanie z GitHub sprawi, że zarządzanie kopiami zapasowymi będzie uciążliwe dużo łatwiej.

Jeśli masz dwa komputery, możesz utworzyć repozytorium na jednym, który nazwiesz kopią zapasową, a następnie sklonujesz to repozytorium za pośrednictwem sieci lokalnej i użyjesz go do programowania, a gdy skończysz z funkcją, możesz przenieść go do maszyna do tworzenia kopii zapasowych, a będziesz mieć kopię zapasową 1: 1!)

2. Zarządzanie problemami i funkcjami

Korzystam z wbudowanego zarządzania problemami Trello lub GitHub, aby śledzić błędy i rzeczy do zrobienia.

3. Przeprowadź proces projektowania

Najpierw zaprojektowałbym swoją grę;

1. najpierw w mojej głowie
2. potem na papierze,
3. następnie prawdopodobnie wykorzystaj GameMakera lub PyGame do prototypowania mojego pomysłu i iteruj od 1 do 3, aż będę mieć coś, co sprawi mi przyjemność.

4. Użyj mojego prototypu jako przewodnika i rozwijaj moją grę

Następnie odłożyłem prototyp na bok i wybrałem platformę, dla której chciałbym się rozwijać. Następnie wyszukaj istniejące silniki i wybierz ten, który najlepiej pasuje do mojego pomysłu na grę. Następnie wytyczyłem jasne cele dla mojego projektu, ułożyłem je w małe zadania, a następnie zacząłem pracować nad ich zakończeniem. Po osiągnięciu tego stanu najprawdopodobniej zauważysz, że masz swój własny sposób pracy, który najbardziej Ci odpowiada, więc idź z tym!

Istnieje kilka różnych metod / filozofii , które możesz zastosować w swoim stylu rozwoju, XP, wodospadzie itp. Po prostu idź z tą, która Twoim zdaniem przyspiesza postęp.

5. Mają dużo testerów gier!

Gdy masz coś do gry, poproś swoich najbliższych przyjaciół, aby to wypróbowali! Ułatw im to, konfigurując pakiety szybkich instalatorów, jeśli korzystają z systemu Windows lub napisz skrypt powłoki, który może zautomatyzować ten proces, jeśli używają systemu Linux / Mac. Zachowaj ostrożność w opiniach testerów i nie zapomnij poinformować ich o swoim projekcie gry i typie gry, którą próbujesz zbudować.

6. Stwórz stronę internetową dla mojej gry

Gdy tylko coś mi się powiedzie, prawdopodobnie stworzę stronę internetową z moją grą - aby utrzymać moją kreatywność i przepływ treści, gdy nie można jej zastosować do postępu mojej gry, na przykład, jeśli skupię się na studiach lub potrzebujesz przerwy w rozwoju!

Jeśli korzystam z GitHub , stworzyłbym stronę projektu dla mojej gry, w przeciwnym razie prowadzę bloga WordPress / Jekyll lub coś podobnego i piszę przy tym moje posty.

Dzięki temu będziesz zmotywowany, a także będziesz mieć możliwość skierowania potencjalnych graczy / testerów!

7. Dołącz do konkursów

Niemal cały czas odbywa się wiele konkursów dla twórców gier. Spróbowałbym dołączyć do jednej z tych gier, jeśli pozwalają na to reguły. Zwiększa to motywację i sprawia, że ​​wszystko jest jeszcze przyjemniejsze - kto nie lubi wygrywać!

(Jeśli rozwijasz się w ściśle określonym terminie, możesz przynajmniej pominąć ten punkt.)

Zdecydowanie sugeruję użycie systemu kontroli wersji, nawet jeśli pracujesz sam. Może Ci to zaoszczędzić dużo czasu, gdy przypadkowo skasujesz coś lub wprowadzisz większą zmianę, ale dopiero później zdasz sobie sprawę, że to zły pomysł i musisz cofnąć wszystkie zmiany.

Edycja : Istnieje wiele bezpłatnych rozwiązań kontroli źródła.

• Użyłem serwera VisualSVN , który można łatwo skonfigurować i używać w systemie Windows.

• Istnieją również internetowe alternatywy, takie jak Codeplex (z SVNlub Mercurial), SourceForge lub Google Code . Plusem jest to, że nie musisz konfigurować i utrzymywać repozytorium, a twoje dane są w chmurze; haczykiem jest to, że nie można swobodnie hostować projektów o zamkniętym źródle.

Jeśli chodzi o śledzenie błędów i funkcji: jeśli masz już większą grupę odbiorców, którzy mogą być zainteresowani testowaniem wersji beta Twojej gry, zgłaszaniem błędów i żądaniem funkcji, śmiało.
Jeśli jednak jest tylko garstka takich osób (lub wcale), nie jest to konieczne.

A jeśli chodzi o priorytety rozwoju - to ty decydujesz. Kto powinien wiedzieć lepiej, co robić w projekcie, niż jego jedyny programista?

Czy warto używać systemu kontroli wersji, ponieważ pracuję solo?

Chyba tak. Jego konfiguracja jest dość trywialna i wiele razy zwariowałem na punkcie refaktoryzacji lub zrobiłem coś głupiego, a możliwość cofnięcia moich zmian pozwoliła zaoszczędzić mnóstwo czasu. Dodatkowo, jeśli jest hostowany na serwerze, masz kopię zapasową naszego kodu na wypadek, gdyby coś poszło nie tak .

Czy powinienem użyć formalnej metody, aby zarejestrować planowane funkcje / błędy (po prostu pamiętam, co trzeba teraz zrobić)

Nie uważam tego za konieczne. Chciałbym zachować pisemną listę tego, co zamierzasz zrobić, aby upewnić się, że nie zapomnisz o drobnym błędzie, a ponadto uważam, że pomaga ci zacząć od nowa po przerwie w kodowaniu.

Najważniejsze pytanie: skąd mam wiedzieć, co najpierw opracować? Teraz, gdy podstawy są już gotowe, znam listę funkcji do kodowania, ale nie wiem, w jakiej kolejności powinienem to zrobić.

Weź tę listę powyżej, zamknij oczy i losowo ją szturchnij. Pracuj nad dowolną funkcją palca. O ile przedmioty nie są od siebie zależne, ważniejsze jest po prostu utrzymanie przepływu niż upewnienie się, że rzeczy dzieją się w określonej kolejności.

Zdecydowanie użyj kontroli wersji

Kontrola wersji jest jak siatka bezpieczeństwa dla linoskoczka: uwalnia cię do prób zwariowania. Duży refaktor usuwający ogromne fragmenty kodu nie stanowi problemu, jeśli można go łatwo przywrócić. Tym bardziej, jeśli jesteś w gałęzi eksperymentalnej w repozytorium i możesz zdecydować, aby nie scalać go ponownie.

Jeśli nie masz takiej swobody, prawdopodobnie zostawisz skomentowany kod, siedząc wszędzie, w obawie, że możesz go potrzebować.

Głosowałbym na Gita. Składnia jest nieco dziwna, ale są dwie świetne rzeczy:

• Niskie koszty ogólne . Przejdź do folderu i wpisz git initi możesz rozpocząć sprawdzanie zawartości. Jeśli zdecydujesz, że mimo wszystko nie chcesz kontrolować wersji, rm -rf .gitw tym folderze i nie będzie to już repozytorium Git.

• Rozpowszechniane przez SSH . Git jest rozpowszechniany, co oznacza, że ​​możesz mieć wiele pełnych kopii repozytorium (całą historię itp.) W różnych miejscach i utrzymywać je w synchronizacji. Możesz skonfigurować kolejne repozytorium Git na dowolnym komputerze, na którym masz dostęp SSH, a następnie dodać to drugie repozytorium jako zdalne. Następnie w dowolnym momencie chcesz wykonać kopię zapasową tylko git pushtego repozytorium.

  Jest to duża zaleta w porównaniu z, powiedzmy, Subversion, gdzie całe repo znajduje się na jednej maszynie i na tej maszynie musi być uruchomiony serwer Subversion.

Mercurial może mieć te same punkty na swoją korzyść, ale go nie użyłem.

1. Tak! Ponieważ pytasz, zgaduję, że jesteś dobrze adoptowany dzięki systemowi kontroli wersji. To musi!

2. Jeśli chodzi o twoje drugie pytanie, istnieje formalny sposób rejestrowania błędów i powinieneś go użyć. W przypadku funkcji planowania myślę, że wybranie mniej formalnej trasy nie zaszkodzi (gdy pracujesz sam)

3. Najpierw wykonaj te funkcje, które pozwolą ożywić grę. Zorientuj się, jaka będzie ostateczna rozgrywka.

1) Tak, oczywiście. Polecam Mercurial przez BitBucket i TortoiseHg. BitBucket jest bezpłatny dla maksymalnie 5 użytkowników, a ponieważ jest przechowywany w chmurze, dodaje Ci pewności (nie ma potrzeby tworzenia kopii zapasowych).

2) Błędy powinny zostać naprawione przed wdrożeniem nowych funkcji. Chciałbym użyć prostej dostępnej listy TODO do śledzenia rzeczy - oczekujących / wykonanych. Możesz po prostu użyć zwykłego pliku tekstowego, po prostu nie zapomnij dodać go do repozytorium kontroli źródła.

3) Rób to, co chcesz robić w danym dniu, pamiętając jednak, że dostarczenie czegoś, co może być odtwarzane przez użytkownika końcowego, jest podstawowym celem. Na przykład, jeśli masz dość poprawnej fizyki, pracuj nad renderowaniem lub dodaj trochę brakujących testów jednostkowych dla tej sztucznej inteligencji.

Kawałki pracy powinny być na tyle małe, że można je wykonać za kilka dni. Bardzo ważne jest utrzymanie motywacji i unikanie wypalenia zawodowego.

Jeśli architektura jest wykonana poprawnie, powinieneś mieć możliwość łatwego dodania zmodyfikowanych części silnika / gry bez wpływu na wiele innych (w przeciwnym razie zacznij od refaktoryzacji :).

1) Jak wszyscy mówią: TAK (powiedziałbym nawet, wynająć tani online)

2) Zachowaj prostą listę lub jeśli Twój projekt powiększy się i otrzymasz beta-testerów, zainstaluj Mantis Bug Tracker

3) Nie wiem, ale powiem ci, jak to robię: najpierw opracuj najmniej interesujące i / lub najtrudniejsze rzeczy. Powtarzaj, aż wszystko się skończy. W ten sposób rozwój staje się zabawniejszy i łatwiejszy (i nie napotkasz tego problemu, którego po prostu nie możesz rozwiązać zbyt późno, jeśli to się kiedykolwiek zdarzy).

Dzięki, że zadałeś to pytanie. Właśnie to robię obecnie.

1) Kontrola wersji: jest to konieczne. Obecnie utrzymuję ręczne tworzenie kopii zapasowych. Przydaje się przynajmniej wtedy, gdy coś, co działało świetnie, nagle generuje błędy (lub nie działa zgodnie z oczekiwaniami). Porównuję wersje i często znajduję głupie błędy (głównie coś komentując)

2) Stworzyłem dokument słowny i wyszczególniłem wszystkie funkcje, które moja gra będzie miała w kategorycznym porządku oraz z wielopoziomowymi wcięciami zawierającymi podfunkcje (i związane z klientem / serwerem lub cokolwiek, co ma zastosowanie).

3) Po otrzymaniu listy (która zwykle nie jest kompletna, ciągle coś do niej dodaje) myślę o mojej grze i podkreślam wszystkie punkty, które są potrzebne, aby uruchomić grę i zacząć ją robić. Zaznaczam na żółto, co oznacza prace w toku. zielony po zakończeniu. pomarańczowy oznacza, że ​​został poprawiony lub ma kilka znanych błędów

mam nadzieję że to pomoże

1.) Warto używać kontroli wersji w każdym projekcie. Nawet bardzo małe, jeśli już wiesz, jak z nich korzystać. Od lat korzystam z Subversion w systemie Linux i Windows z TortoiseSVN . Nawet podczas tworzenia małego (<500 linii) projektu utworzę dla niego repozytorium, aby móc cofnąć zmiany, śledzić, co robiłem, jeśli na jakiś czas porzucę projekt itp.

2.) Zależy od tego, jak duży będzie projekt. Jeśli planujesz przetestować grę z zespołem i rozprowadzać, prawdopodobnie warto mieć system śledzenia błędów. Obecnie pracuję solo (chociaż mam artystę) nad projektem, który ma ponad 20 tys. Linii i po prostu przechowuję moją listę rzeczy do zrobienia w pliku tekstowym, który również znajduje się w moim repozytorium SVN. Chociaż nie muszę jeszcze dzielić się nim z innymi, więc brak śledzenia błędów odpowiada mi na razie. Nie martwiłbym się tym, dopóki nie będzie takiej potrzeby. Najgorsze, co może się zdarzyć, to wprowadzić błędy, które już zapisałeś, i usunąć / poprawić te, które naprawiłeś. Kiedy zaczniesz tracić pamięć swoich notatek, zdobądź narzędzie do śledzenia błędów.

3.) Wykreśl to na papierze. Zacznij od tego, co chcesz, aby była ukończona gra, zapisz jej sedno. Następnie podziel go na następujące elementy: wykrywanie kolizji? kod sieci? rodzaje graczy i potwory? hierarchie klasowe? Pracuj wstecz od swojej wizji, aby uzyskać jasne pojęcie o tym, jak zbudować ją od podstaw. Zakładam, że używasz języka obiektowego. Najważniejszym krokiem na początku byłoby rozsądne skonfigurowanie hierarchii klas. Postaraj się, aby nie było absolutnie żadnego wielokrotnego dziedziczenia (chociaż czasami jest to nieuniknione), opracuj relacje klasowe w edytorze diagramów (używam Dia ) itp. Podstawowe zasady mają długą drogę do uniknięcia bólów głowy później.