Warto dodać do naszej gry „futurystyczne” funkcje, czy powinniśmy skupić się gdzie indziej?

Jestem głównym programistą w średniej wielkości studiu gier niezależnych. To nasza pierwsza gra zespołowa. Pracujemy nad futurystyczną grą FPS z planem podziału zysków.

W każdym razie mamy bardzo dobrych programistów, którzy mają możliwość tworzenia nigdy wcześniej nie widzianych funkcji (prawdziwe realistyczne płyny, proceduralne niszczenie siatki, proceduralne skyboksy itp.). Zastanawiam się, czy warto zaimplementować te rzeczy? Zajmują dużo czasu, ale wyglądają świetnie. Naszym celem jest 12-miesięczny cykl rozwoju. Więc powinniśmy to zrobić lub po prostu stworzyć standardową grę.

Nie próbuj tego robić, ponieważ wiesz, że możesz to zrobić.

Rozgrywka powinna być na pierwszym miejscu, wszystkie rzeczy (nawet grafika) są drugorzędne. Jeśli gra jest fajna i przyjemna, ale ma słabą (lub wcale nie tak nowej generacji) grafikę, nadal będzie przyjemna i przyjemna, a ludzie będą w nią grać, a także twój metacritic będzie dobry. W przeciwnym razie, jeśli gra ma niesamowitą grafikę i funkcje (realistyczne płyny, proceduralne niszczenie siatki itp.), Ale nie jest zabawna lub trudna do grania (zła kontrola itp.), Ludzie nie będą w nią grać. Brak graczy = brak pieniędzy, a także zły metacritic.

Więc najpierw zaplanuj grę, którą chcesz zrobić i zastanów się nad jej funkcjami, sytuacjami, w których można grać. Nie próbuj naciskać, aby dopasować tę funkcję X do gry tylko dlatego, że wygląda fajnie. Jeśli to naprawdę nie ma sensu lub jeśli nie będzie stanowić istotnej części gry, po prostu upuść.

Unikaj też budowania rozgrywki wokół jednej z tych niesamowitych funkcji, jeśli nie ma to sensu lub uważasz, że to nie będzie zabawne. Na przykład: możesz pomyśleć: „Mam proceduralne zniszczenie siatki, więc zmuśmy gracza do zniszczenia wszystkiego, zanim będzie mógł kontynuować postępy w grze (aby zobaczył, że siatki są proceduralnie niszczone)”.

Podsumowując: najpierw pomyśl o swojej grze i jej potrzebach. Na tej podstawie zaplanuj fazę rozwoju, a następnie zobaczysz, czy jest wystarczająco dużo miejsca, aby zmieścić jedną lub więcej z tych niesamowitych funkcji (i czy warto je dodać do konkretnej gry).

Pamiętając, że 12-miesięczny cykl nie oznacza, że ​​przestajesz kodować w 52 tygodniu i wypychasz go za drzwi, odpowiadam już na odpowiedzi, ponieważ gra musi być na pierwszym miejscu i dodawać fajne funkcje, tylko jeśli pomagają w grze grać.

Idealnie będziesz mieć czas na testy beta z kandydatami do wydania, więc większość działa, z wyjątkiem awaryjnych napraw błędów i przestrajania w 50. tygodniu.

Pełne funkcje powinny być dostępne na długo przed wersją beta, więc być może nie w tygodniu 46, abyś mógł przeprowadzić testy wewnętrzne, aby wszystko było solidne przed dopracowaniem wersji beta. To naprawdę tylko 46 tygodni pracy, zanim zaczniesz przygotowywać grę do wysyłki.

Kluczową kwestią jest podjęcie decyzji, czy Twój gorący inżynier pracujący nad systemem jest wart handlu tego inżyniera, który nie pracuje już nad kolejnym tytułem. „Co jeszcze mógłby robić” to ukryty koszt każdej decyzji.

BTW, symulowane objętości płynów, zniszczenia proceduralne, dynamiczne skrzynki na niebo itp. Zostały wykonane w grach komercyjnych, a powodem, dla którego nie słyszysz o nich tak bardzo, jest to, że sama gra była zawsze ważniejsza.

Powodzenia, wszystko, co robisz, będzie ekscytujące!

Jeśli twoi programiści są tak dobrzy, wykorzystaj te umiejętności, aby zapewnić terminowość i niepełny budżet. Pomiędzy teraz a początkiem kolejnego dużego projektu zastanów się, jak lepiej wykorzystać umiejętności, które ma Twój zespół, przy większym budżecie i dobrych osiągnięciach.

Ale jeśli musisz robić to w ten sposób, wybierz JEDEN fajny przedmiot. Nie wszystkie, nawet dwa - Nigdy nie wprowadzaj zbyt wielu czynników ryzyka na raz. I ta, którą wybierzesz MUSI być w jakiś sposób centralna w grze, ponieważ cała reszta to tylko puch. Kiedy jesteś Blizzardem, możesz sobie pozwolić na wygodne dodawanie ciekawych funkcji - chociaż ich decyzje są zawsze nastawione na biznes IMHO.

Ale próba zaimplementowania wszystkich lub nawet kilku rzeczy, które mogą zrobić twoi koderzy, ponieważ wydaje się to fajne i wydaje ci się, że możesz, doprowadzi cię do bardzo dużego upadku.

Ponownie, kluczem jest NIE dodawaj niczego, co z pewnością nie przyczyni się do dynamiki podstawowej gry - cokolwiek to jest (brzmi, jakby to miało jeszcze TBD).

„mamy bardzo dobrych programistów, którzy potrafią tworzyć funkcje, których wcześniej nie widziałem”

Nic osobistego, ale muszę powiedzieć, że w to wątpię. Valve (aby wybrać tylko jednego) ma jednych z najlepszych programistów w branży, jeśli nie na świecie. Havoc ma także całkiem sprytnych ludzi - istnieje wiele innych przykładów. Wszystkie mają więcej programistów niż Ty, więcej czasu i wyższe budżety.

Może udało ci się w jakiś sposób zgromadzić grupę absolutnych geniuszy. Byłbym jednak bardzo ostrożny w kwestii rozróżnienia między tym, co programiści sądzą, że mogą zrobić, a tym, co możemy zrobić w ograniczonym czasie i zgodnie z możliwymi do uwolnienia standardami. Jak powiedzieli inni ludzie, możesz (jeśli jesteś bardzo pewny siebie) wybrać jeden. Osobiście chciałbym przejść przez proces wprowadzania gry na rynek przynajmniej raz, zanim spróbowałem strzelić na księżyc.