Jak to zrobić vs Solidne projektowanie oprogramowania?

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?

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.

• Pragmatyzm nad ideologią
• (1) Spraw, by działało (2), a następnie popraw - gra się kończy, jeśli zapomnisz kroku 2
• Puść to!
• Zbyt dużo wstępnego projektu będzie stratą czasu
• TDD i Clean Code prowadzą do prostszych, bardziej stabilnych projektów oprogramowania

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ę:

• Maksymalnie przyjazny interfejs wejściowy do konfigurowania dyrektyw i ustawiania zmiennych lub danych.
• Stabilne wyjątki i obsługa błędów.
• Online jak funkcja debugowania, ale na poziomie, czego potrzebujesz.
• Maksymalnie przyjazny interfejs wyjściowy do wyświetlania lub rejestrowania wyników na wszystkie możliwe i niezbędne sposoby.

Zalety:

• Możesz poprawić skorupę RapidPrototype podczas całego rozwoju.
• Możesz zobaczyć i skonfigurować swój kod na wiele sposobów.
• Możesz skupić się tylko na teorii i problemach, które musisz rozwiązać.
• Możesz szybko opracować dowolne nowe części projektu i wypróbować je z resztą ostatecznych rzeczy.
• Możesz szybciej dostarczać nowe rzeczy do wykorzystania w wypełnianiu treści i finalizować je później (szczególnie w przypadku piaskownicy)
• Możesz łatwo opisywać i pokazywać prognozy lub rozwiązania innym osobom. Online.
• Funkcjonalny i przejrzysty prototyp jest najlepszym źródłem informacji dla końcowego kodu (każdy może to zrobić).

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).