Jak decydujesz, kiedy lista funkcji jest wystarczająco długa?

Wiem trochę o tym pytaniu, ale uważam, że istnieje wiele różnych opinii na ten temat?

Wiem z perspektywy graczy, że więcej opcji jest prawie zawsze dobrych. Ale z drugiej strony, jeśli ma więcej graczy, oznacza większą złożoność (meta grę) zarówno dla programistów, jak i graczy.

Złożoność i ograniczenia czasowe zawsze idą ze sobą w parze. Kolejnym byłyby ograniczenia zasobów i platformy. Możliwe są także ekonomiczne konsekwencje powstrzymywania się na później.

Więc od osób doświadczających tutaj oprócz powyższego, kiedy funkcje powinny zostać wycięte lub być przeznaczone do późniejszego wydania?

Powiedziałbym, że jest to dla nas dwuetapowy proces:

• Ustal cele gry.
• Określ, które funkcje pomogą nam osiągnąć te cele.

Lista funkcji jest wystarczająco długa, gdy te dwa punkty pokrywają się. Więc:

1. Ustal nasze cele - Dowiedz się, co chcemy, aby gra zrobiła dla gracza / recenzenta / kogokolwiek, a następnie określ je w sposób wymierny. Na przykład, dzięki naszemu najnowszemu ( patrz vid testu alfa tutaj ), chcemy to zrobić:

• Wizualizacje: Chcemy, aby każda recenzja wspominała, że ​​wizualizacje są niezwykłe i seksowne, szczególnie w przypadku indie. Jest to dla nas ważne, ponieważ gracze często używają swoich oczu jako szybkiego miernika jakości (choć oczywiście jest to tylko jeden z wielu!), A my chcemy, aby to przyciągnęło.
• Eksploracja: Chcemy również nagradzać ludzi za eksplorację gry. Mówiąc w wymierny sposób, chcemy, aby około jednej piątej czasu gracza spędzało na robieniu drobiazgów poza podstawową rozgrywką. Jest to dla nas ważne, ponieważ (IMO), wiele radości z gry wykracza poza oczekiwane, kluczowe obszary (myślimy o tym, jak bawi nas klikanie na elementy w Starcraft).
• Społeczność: Chcemy, aby każdy powiedział przynajmniej jednej osobie o grze.

2. Określ funkcje, które pomogą nam osiągnąć te cele - te prawie naturalnie wypadają z powyższych. Funkcje odpowiadające powyższym przykładom mogą wyglądać następująco:

• Wizualizacje: Jako małe studio, jeśli chcemy seksownych wizualizacji, nie możemy konkurować z EA ani Sony pod względem realizmu. Aby zbliżyć się do celu, jakim jest niezwykła grafika, jedną z cech gry jest surrealistyczna estetyka. (Na tej podstawie jesteśmy w stanie określić, jakich narzędzi potrzebujemy itd.)
• Eksploracja: wypadają z tego ciekawostki związane z grą. W naszym najnowszym tytule umieściliśmy krótkie odniesienie do wątpliwego poszukiwania marynarzy przez Ryo w Shenmue . To był głupi pomysł, ale ludzie lubili i rozmawiali o tym!
• Społeczność: Zadajemy sobie pytanie, jak stworzyć grę, o której warto wspomnieć znajomemu. Oczywiście, zapewnianie radości to numer 1. Ale moglibyśmy również nagrodzić graczy specjalnym przedmiotem lub poziomem, jeśli tweetują na ten temat. Pokemon sprawił, że warto było, aby znajomi podnieśli grę - jest kilka stworzeń, które można uzyskać tylko poprzez kontakt z innymi ludźmi.

Kiedy przechodzimy przez ten proces, pomaga nam ustalić:

• Ile musimy wdrożyć dla minimalnie opłacalnego produktu ( MVP ).
• Co najważniejsze, na co można czekać i co możemy w ogóle rzucić.
• Kiedy w końcu będziemy mieć wszystkie potrzebne funkcje.

Warto zauważyć, że nie przestrzegamy niewolniczo tych zasad! Częściej niż nie, powstają niektóre niezwykle interesujące rzeczy w wyniku prototypowania w połowie projektu i po prostu ogólnego wybiegania wokół. Szczególnie w przypadku małych gier, takich jak nasza.

Złożoność nie sprawia, że ​​gra jest przyjemna.

Odpowiednia kombinacja i równowaga elementów rozgrywki. Gracz musi zostać popchnięty do poziomu swoich umiejętności i poczuć się mistrzowskim w podbijaniu wyzwań.

Twoja lista funkcji powinna się zmieniać, ilekroć uważasz, że obecna rozgrywka nie jest fajna. Zmiany te należy wprowadzić w ramach ograniczeń budżetu / czasu. Upewnij się, że wszelkie zmiany, które wprowadzisz, dodają wartości do gry.

Ponadto, prototypuj wcześnie, nie pisz po prostu ogromnej listy funkcji i zakładaj, że wszystko to będzie zabawne, gdy zostaną połączone.

Doskonałość jest osiągana, nie wtedy, gdy nie ma już nic do dodania, ale kiedy nie ma już nic do zabrania.

-- Antoine de Saint-Exupéry

Gdy czas i wysiłek potrzebny do ich włączenia jest większy niż wartość, którą dodają do gry .

Na przykład, jeśli tworzysz grę sportową lub coś, w którym gracze prawdopodobnie będą chcieli pokazać swoje umiejętności, gra wieloosobowa jest koniecznością. Guitar Hero nie byłby taki sam bez niego. Jednak wyłącznie indywidualna gra, w której zaczynasz i kończysz na własną rękę, śledząc historię lub fabułę, nie potrzebujesz gry wieloosobowej. Tandetny system dla wielu graczy w Grand Theft Auto San Andreas jest tego dowodem (chociaż ta firma prawdopodobnie nie uważała gry dla wielu graczy za zbyt trudne).

Ponadto funkcje, które nie pasują do historii gry, są dostępne, ponieważ mogą być. Jeśli rozgrywka nie jest całkowicie niezbędna, prawdopodobnie jest to dobry znak, że mogą zostać przeniesione do późniejszej wersji, jeśli czas stanowi problem.

Chodzi o to, że dodatkowe funkcje nie są kwintesencją gry. Ekscytująca fabuła połączona z przyjemną rozgrywką.

Chociaż istnieje stopień, w jakim różnorodność funkcji jest świetna (możliwość robienia ton losowych rzeczy w grze GTA, posiadanie ton różnorodności broni i akcesoriów w grze RPG lub Call of Duty-ish itp.), Myślę, że bardziej minimalna rozgrywka skoncentrowana ściśle na kilku podstawowych funkcjach może być bardzo skuteczna.

Spójrz na portal, wykorzystał swoją jedną podstawową mechanikę i naprawdę skutecznie zbudował wokół niego zagadki, nie wymagając dużo dodatkowego bałaganu.

Myślę, że ścisłe przestrzeganie listy funkcji na minimalnym poziomie i dopracowanie kilku podstawowych funkcji pozwala na bardziej wykonalny projekt i często przyjemniejsze wrażenia (jeśli Portal dodał elementy RPG i sekwencje jazdy oraz slowmo i cokolwiek innego „fajne funkcje” „czy byłoby tak dobrze? Czy mechanika rdzenia byłaby tak dopracowana?).

Teraz, jako niezależny twórca, jestem z pewnością stronniczy, ale myślę, że zazwyczaj „mniej znaczy więcej” w funkcjach, a nawet jeśli coś może być w tej chwili fajne lub popularne, jeśli nie poprawi to ogólnie wrażenia powinien zostać wycięty.

Z własnego doświadczenia wynika, że ​​najlepiej jest unikać dodawania nowych nieplanowanych funkcji tak szybko, jak to możliwe.

Z punktu widzenia projektu funkcja, która została dodana pod wpływem chwili „czy nie byłoby miło mieć cechę x”, wydłuży czas programowania, może nie być dobrze zintegrowana z kodem i może nie pasuje całkowicie do reszty twojego projektu.

W najgorszym przypadku projekt, który miał wiele takich chwil, może wydawać się niechlujnym połączeniem funkcji, które naprawdę powinny były poświęcić im znacznie więcej czasu na etapie projektowania i wyglądać mniej profesjonalnie.

Jako ogólną wytyczną staram się przestrzegać następujących zasad:

• Jeśli nowa funkcja pojawi się na początku projektu, poświęć czas na powrót do fazy projektowania i zobacz, jak ta funkcja może działać z Twoim produktem, zachowując jednocześnie zgodność z resztą projektu.

• Jeśli projekt zbliża się do wydania, rozważ utworzenie listy funkcji, które można dodać do nowej wersji.

• Jeśli okaże się, że wciąż pojawia się wiele funkcji, które naprawdę chcesz wdrożyć, być może powinieneś powrócić do projektu i sprawdzić, dlaczego te nowe funkcje nie były rozważane wcześniej, być może z powodu braku wysiłku włożonego w faza projektowania.

Oczywiście pasuje to do niektórych projektów lepiej niż inne, ale tak naprawdę, jeśli masz funkcję, która pojawi się w późnej fazie projektu, prawdopodobnie bez niej poradzisz, przynajmniej do momentu rozpoczęcia pracy nad nową wersją.

Listy powinny być krótkie, zwinne

Nie twórz wcale list funkcji, a jeśli tak, to buduj je bardzo krótko, warte kilku tygodni rozwoju.

Rozwijaj się w zwinnym stylu - zacznij od kilku najważniejszych funkcji, przetestuj, w oparciu o to, co działa, a co nie, a następnie zastanów się, czy warto dodać więcej funkcji (będziesz mógł je ocenić znacznie lepiej, jeśli masz już pewne doświadczenie z podstawową rozgrywką).

Jak ocenić indywidualną cechę

Poza tym zgodziłbym się z kryterium bennybdbc: „Gdy czas i wysiłek potrzebny do ich włączenia jest większy niż wartość, którą dodają do gry”.

To powiedziawszy, musisz również wziąć pod uwagę świat „zewnętrzny”:

• czy zabrakło Ci pieniędzy lub czasu określonego w umowie?
• zabrakło Ci miejsca na media (pełne DVD)
• brakuje Ci miejsca na wydajność (nowe funkcje spowodowałyby, że gra działałaby zbyt wolno)?
• czy wkrótce pojawi się konkurencyjna gra?

Należy również wziąć pod uwagę proste takie problemy z życia codziennego, chyba że tworzysz grę tylko dla zabawy.

Kiedy zabraknie papieru, aby go zapisać.

Zdecydowanym ograniczeniem będzie rozmiar nośnika; na przykład nie można zmieścić 10 GB funkcji na dysku DVD o pojemności 4,7 GB.

Nie chcesz też zbyt wielu funkcji, które mogłyby nadmiernie skomplikować grę. Najlepszym sposobem jest zastanowienie się, czy to będzie dla gracza znacznie fajne? czy to zbytnio pochłonie nasz czas rozwoju? czy to w ogóle możliwe?