Jak przygotować się na pełzanie funkcji?

Jak mogę przygotować się na pełzanie funkcji podczas preprodukcji?

Pełzanie po funkcjach ma miejsce, gdy jesteś na etapie produkcji i decydujesz: „Byłoby fajnie, gdyby to była funkcja”. To dodaje n godzin do czasu programowania, które nie zostały uwzględnione, i jeśli nie jesteś Blizzardem, nie masz na to czasu. Nie można oczekiwać, że będzie to fajna funkcja podczas preprodukcji, ponieważ ta funkcja jest wykrywana tylko podczas produkcji.

Co mogę zrobić podczas preprodukcji, aby uwzględnić lub zapobiec pełzaniu funkcji?

Czy powinienem pozwolić na pełzanie funkcji i wycinanie mniej pożądanych funkcji? Czy może to stanowić problem, ponieważ architektura nie jest przeznaczona dla nowych funkcji? Czy nie powinienem mówić o żadnych funkcjach, chyba że pasują one do istniejącej architektury?

Wiem, że to szerokie pytanie, ale mam nadzieję, że nie zostanie ono zamknięte jako takie. Jest to poważny problem w rozwoju gier i należy go wziąć pod uwagę.

Chociaż oczywiście nie ma twardych zasad, jeśli chodzi o preprodukcję, istnieje wiele heurystyk, które mogą pomóc. Niektóre funkcje pełzania są naturalne i konieczne - żaden plan nie przetrwa pierwszego kontaktu z rzeczywistością i możesz nie wiedzieć, co byłoby „fajne”, dopóki go nie zobaczysz.

Najpierw przygotuj swój rozwój. Narysuj kontur na mapie obiektów, a następnie poszukaj sposobów, aby pogrupować obiekty w testowalne iteracje , z których każda będzie miała termin . Po rozpoczęciu iteracji nie dodawaj do niej nowych funkcji. Wszelkie nieprzewidziane potrzeby techniczne powinny oczywiście przejść do bieżącej iteracji, ale nowe pomysły dotyczące funkcji powinny znaleźć się na liście do rozważenia w przyszłości. Następnie możesz rozważyć, czy dodać ją do iteracji po zakończeniu bieżącej.

Wynika to z metody MoSCoW , w której kategoryzujesz takie funkcje:

• Musisz mieć - cechy, które są niezbędne, aby bieżąca iteracja była stabilna , to znaczy można ją przetestować . Jeśli iteracja nie zadziała bez niej, to musi to mieć.
• Powinien mieć - funkcje, które w pewnym momencie będą musiały zostać wykonane, ale jeśli iteracja minie, można ją przesunąć do następnej iteracji . Na przykład rzeczy wymagane przez wydawcę mogą się tutaj znaleźć.
• Może mieć - funkcje, które Twoim zdaniem mogą być ważne dla bieżącej iteracji, ale mogą zostać usunięte z projektu. Są to wszystkie ważne polskie cechy .
• Nie będzie - elementy potencjalnie zasilające zaległości , funkcje zidentyfikowane w tej iteracji, które należy wziąć pod uwagę w późniejszych iteracjach.

Idealnie, aby rozwój był postępowym udoskonalaniem, a nie wszystkim lub niczym. Pracując w ostatecznym terminie, najmniej ważne funkcje należy przesunąć do końca, więc wszystko, czego nie dostaniesz, będzie rzeczą, którą można wyciąć. Oszacuj, ile czasu zajmie opracowanie każdej funkcji, i dopracuj te szacunki w miarę upływu czasu. Nigdy nie kompresuj harmonogramu, aby zrobić miejsce na więcej funkcji. Oprzyj się przesunięciu terminów (iteracji lub ostatecznego) w przyszłość - zamiast tego przenieś lub wytnij funkcje, jeśli to możliwe. Jeśli zbliżasz się do ostatecznego terminu, a gra jest wciąż nieosiągalnym bałaganem, wiesz, że nadszedł czas, aby poważnie ponownie ocenić swoje decyzje i rozważyć kanibalizację projektu, zanim zmieni się on w pułapkę czasu / pieniędzy.

• Zaplanuj wykorzystanie ułamka dostępnego czasu przedprodukcyjnego na podstawowy zestaw funkcji.
• Featureset bazowa powinna być niskiego ryzyka, cechy wysokiej nagrody, więc nie trzeba pełzanie na tych
• Podstawowy zestaw funkcji jest minimalny i nie podlega negocjacjom - muszą być obecne - w przeciwnym razie nie ma solidnych podstaw do pracy, a ty będziesz pełen wątpliwości i / „powinienem zastąpić ten” syndrom
• Upewnij się, że najwcześniejsze wersje gry są na tyle atrakcyjne, że możesz sobie pozwolić na pełzanie funkcji. Zasadniczo nie imponująca gra nie zajdzie daleko, nie mówiąc już o pełzaniu.
• Wiedz wcześniej, na jaki margines pełzania możesz sobie pozwolić, abyś mógł z niego mądrze korzystać.
• Używaj gotowych, uogólnionych technologii, takich jak Unity, i używaj ich kanonicznie, aby poprawić elastyczność, aby pełzanie funkcji nie miało zbyt dużego wpływu na istniejącą architekturę
• Nie buduj skomplikowanych podsystemów - tutaj odpowiednie jest podejście eXtreme Programming
• Poproś innych (projektantów i programistów), których mózgi możesz okresowo stukać, aby pomóc ci ustalić, które funkcje pozwolisz na pełzanie, niech ktoś doświadczy twojego kodu jako głównego punktu wyjścia dla tych pytań.
• Nadal będziesz musiał ograniczyć pełzanie funkcji, więc stale ustalaj priorytety i wiedz, gdzie narysować linię

Ostatecznie nie jest to coś, co sugerowałbym początkującym, ponieważ musisz być w stanie podjąć właściwą decyzję na każdym etapie i nie jest to łatwe nawet dla najbardziej doświadczonych. Jeśli nie masz pewności, jakie są właściwe decyzje, stosuj surową zasadę „nie wkraczaj poza ten punkt”.

Można również zobaczyć, jak pierwszy punkt i jeden o użyciu technologii wiesz dobrze oznacza, że trzeba bogate doświadczenie zarówno w szybkiego prototypowania (dżemy gry) i wybranego zestawu narzędzi.