Mając ledwie wystarczającą ilość czasu na ukończenie tworzonych przez nas gier, w jaki sposób możesz osiągnąć równowagę między solidną architekturą oprogramowania a postępami, aby to wszystko zrobić?
Moje osobiste wyzwanie: co powiesz na bycie skutecznym dzisiaj i jednoczesne myślenie długoterminowe? Dodatkowo, robiąc to, możesz równie dobrze chcieć uczyć się nowych rzeczy po drodze, zamiast uciekać się do tych samych powtarzalnych wzorców, z których korzystałeś przez ostatnie 5 lat?
Odpowiedzi:
Im mniej masz doświadczenia, tym więcej czasu marnujesz na projektowanie z góry. Tworzenie dobrych projektów jest czymś, czego nauczysz się, robiąc to, a następnie oglądając / oceniając, jak to się potoczy. Niektóre decyzje mają daleko idące, ale niejasne implikacje. Po niektórych grach prawdopodobnie będziesz w stanie uczynić początkowy projekt całkiem solidnym i opłaci się zainwestować trochę czasu na ten etap.
Moje motto: załatwiaj sprawy przede wszystkim, ale kieruj się zdrowym rozsądkiem, aby wykryć, które elementy są bardziej krytyczne niż inne i zaprojektować je całkiem nieźle, w wyznaczonym terminie. Na przykład, jeśli sztuczna inteligencja ma krytyczne znaczenie dla twojej gry, upewnij się, że możesz łatwo ją później rozszerzyć / zmienić. Lub, jeśli masz zamiar napisać komponent, który będzie używany w każdej grze, zaprojektuj go do ponownego użycia. Śledź swój czas i nie szalej na projektowaniu. Ustaw ostateczny termin projektowania, a następnie zacznij hakować wszystko, aby uzyskać ostateczny termin wydania. Pamiętaj jednak, aby zanotować, które punkty wymagają później refaktoryzacji / przeprojektowania i obliczyć za jakiś czas przed rozpoczęciem następnej gry, aby poprawić te rzeczy, aby nie mogły cię odgryźć!
Dobra rada: jeśli musisz wybrać jedną z dwóch opcji, nie zastanawiaj się zbyt długo nad szczegółami. Najczęściej nie ma „dobrego” ani „złego”. W niektórych sytuacjach A będzie lepszy, w niektórych B będzie, i ogólnie różnica między oboma może nie zawsze być warta czasu.
Istnieje wiele doświadczenia w projektowaniu oprogramowania lub gier, więc pamiętaj, aby poświęcić trochę czasu na badania (np. Czytając książkę o projektowaniu, czytając o innych doświadczeniach, rozmawiając z innymi programistami o swoich projektach itp.) ).
Ludzie strasznie przewidują przyszłość. Jest to szczególnie prawdziwe w przypadku gier, w których wymagania mogą się zmieniać codziennie.
Istnieje zasada zwana YAGNI , czyli „Nie będziesz jej potrzebować”, która zasadniczo mówi, że nie powinieneś wdrażać czegoś, dopóki nie dowiesz się, że będziesz go potrzebować.
Widziałem tak wiele systemów, które utknęły w martwym punkcie ze względu na sztywność architektoniczną, która tak naprawdę nie wykorzystywała żadnego z nich, ponieważ cechy, o których ludzie myśleli, że będą potrzebować, nigdy nie zostaną wykorzystane.
Moją osobistą filozofią jest robienie najprostszych rzeczy, które mogłyby zadziałać . Biorąc to pod uwagę, istnieje różnica między Gotowe do zrobienia a Hacking Shit Together. Pisanie kodu w określonym celu nie powinno oznaczać robienia rzeczy, które generują „zapach kodu”, takich jak upublicznianie wszystkiego, posiadania klas obiektów blob, które robią wszystko, lub któregokolwiek z tych dziesiątek innych rzeczy, które oznaczają „zły” kod.
W mojej dzisiejszej opinii to prawda.
Jestem przyjacielem szybkiego prototypowania oprogramowania. Zwłaszcza podczas tworzenia gier. Jest dobry do szybkiego uczenia się, testowania i używania rzeczy. Dla mnie blisko programowania sprzętu lub skomplikowanych algorytmów jest dla mnie najlepsza metoda.
Theory();
RapidPrototype();
bool bOk = false;
while(!bOk)
{
Testing();
LotOfFixing();
PlayingWith();
bOk= AnalysingResults();
}
FinalFastAndNiceDataStructuresAndCode();Moja wersja Rapid Prototype musi mieć odpowiednią prototypową skórkę:
Zalety:
Jeśli zrobisz to dobrze, możesz mieć wersję debugowania / nauki swojego produktu na końcu.
Używamy go w naszym projekcie i jesteśmy z tego zadowoleni.
Zobacz zwinne tworzenie oprogramowania . Chociaż nie jest to srebrna kula, ma ona na celu zrobienie obu rzeczy (wykonanie i solidne projektowanie oprogramowania).