Lubię myśleć, że wszystko wokół nas może być przedstawione, w taki czy inny sposób, za pomocą diagramu. Nawet jeśli jest to tylko liniowy schemat przedstawiający przejście między stanami określonego obiektu w czasie (jak żywa istota, przechodząca przez szereg stanów od narodzin do śmierci). Korzystam ze schematów, aby przedstawić swoje przemyślenia i pomysły dotyczące rzeczywistej implementacji. Dużo improwizuję.
Dlatego moje diagramy są przez większość czasu na bardzo wysokim poziomie i wyglądają jak mapy myśli .
Aby rzucić kilka przykładów, w rzeczywistości jest to mapa dziedziczenia klas (wycięta) w mojej grze, w której obiekt interaktywny jest typem podstawowym.

To jest schemat FSM ( maszyna o skończonym stanie ) dla pułapki na kolce (te niesamowite pułapki, na które nadepnąłeś, a kolce wyskoczyły z ziemi).

To jest schemat podręcznika (nazwany w ten sposób, ponieważ ma on być schematem często wracającym ), który ostatnio narysowałem. Przedstawia elementy gry, a także pomaga zebrać wymagane zasoby, ponieważ od razu widać, co jest potrzebne, a co nie. Polecam je przy małych projektach, ponieważ stają się dość duże przy dużych. Można je jednak poszerzyć, aby to naprawić.

Kiedy przechodzę na niższy poziom, zwykle dzieje się tak dlatego, że muszę zaplanować najbardziej skomplikowane aspekty mojej architektury i zwykle mam tam do czynienia z UML. Jednak nigdy nie koncentruję się na tworzeniu absolutnie czystego i poprawnego UML. Zaadaptowałem to, co najbardziej podobało mi się w konwencji UML, i zmieniłem ją w przyjemny UML do mapowania myśli. Jest to proste i działa dla mnie, ale nie poszedłbym z tym w środowisku, w którym oczekiwany jest rzeczywisty UML, z oczywistych powodów.
Inną sytuacją, w której muszę przejść na niższy poziom, jest opisanie faktycznych algorytmów. Używam tak zwanych diagramów przepływu . Jest to format inspirowany diagramami stosowanymi w testach białych skrzynek .
Próbka pułapki szczytowej, którą właśnie narysowałem, będzie wyglądać następująco:

Zwykle jest to ostatnia warstwa między diagramami a rzeczywistymi implementacjami algorytmów. Jeśli zajdzie taka potrzeba, szczegółowo opisuję schematy przepływu (z dodatkowymi wykonanymi instrukcjami), dedukuję lub oceniam złożoność i buduję dokładne przypadki testowe. Wolę też diagramy niż pseudokod.
Nie jest to związane z tworzeniem gier, ale mam też ładny format do opisywania ekranów w aplikacji na wiele ekranów, funkcje, które użytkownik może uruchomić na każdym ekranie, oraz relacje między ekranami. Zwykle buduję je przed rozpoczęciem rzeczywistego rozwoju i działają one jak mapa podczas całego procesu rozwoju. Jeśli jest to dla klienta, schemat ekranu jest jeszcze bardziej przydatny! Pomaga mi przejść przez cały projekt, od początku do początku, i wziąć pod uwagę wszystkie funkcje, które będą potrzebne. Dlatego nieocenione jest zapewnienie dokładnego oszacowania kosztów i czasu.
Więc tak, zdecydowanie rysuję wszystko i cokolwiek. Jeśli mam pomysł, mogę i na pewno narysuję dla niego schemat. Jeśli w jakiś sposób rozpocznę projekt bez przynajmniej bardzo obszernego schematu, który by mnie poparł, czuję się kaleką.