Czy faktycznie używasz diagramów do modelowania gier? [Zamknięte]

Mam na myśli głównie UML, ale każda metoda, która działa, jest opłacalna. Więc - czy faktycznie modelujesz swoje gry za pomocą UML / innych diagramów lub innych metod? Na uniwersytecie miałem temat dotyczący modelowania w języku UML i wydawało mi się, że to więcej wysiłku niż rzeczywistej korzyści, ale zdaję sobie sprawę, że może tak być tylko dlatego, że nigdy nie stworzyłem bardzo złożonego systemu informatycznego. Czy warto więc poświęcić trochę czasu i jakie typy diagramów / metod są zwykle * najlepsze?

* Oczywiście, wiele razy trzeba wybierać konkretne narzędzia do konkretnych problemów, ale może istnieją pewne wzorce.

Edycja: Zapomniałem o jednej ważnej rzeczy - czy tworzysz diagramy przed czy po wdrożeniu rzeczy? Chodzi mi o to - kiedy ktoś projektuje i wdraża coś, co zwykle zmienia zdanie lub pojawia się coś nieoczekiwanego i trzeba wprowadzić zmiany, czasem poważne - i wykonanie ich na skomplikowanych diagramach wydaje się równie beznadziejne, jak w samym kodzie.

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

Z pewnością tak robię - zarówno strukturalnie, jak i behawioralnie - podstawową zasadą jest to, że robię diagramy, gdy koszt zrobienia diagramu jest mniejszy niż próba przypomnienia sobie, o czym myślałam miesiąc później - lub gdy muszę jasno wyjaśnić jakiś inny programista

Diagramy klas, gdy hierarchia dziedziczenia staje się wystarczająco złożona

Diagramy obiektów, gdy tworzenie instancji obiektów staje się czymś granicznym z tworzeniem potwora Frankensteina z różnych części - szczególnie przydatne w przypadku użytkowników zlewów kuchennych i modułów cieniujących piksele, aby upewnić się, że wszystkie wymagane bity są przepchnięte przez rurę

Diagramy sekwencji, gdy szczegółowe interakcje między zestawem obiektów stają się złożone - jest to niezwykle przydatne w modelowaniu złożonych przepływów renderowania, w których wcześniej obliczone informacje są potrzebne w ledwo powiązanych lokalizacjach

Diagramy to świetny sposób na komunikację, dokumentację i pomoc w projektowaniu , a projekt jest najważniejszą częścią rozwoju oprogramowania. UML ma wiele funkcji, ale nie należy ich używać jednocześnie, tylko te, które są przydatne.

Czy podczas nawigacji w nowym mieście rzeczywiście zatrzymujesz się i patrzysz na mapę, a nie tylko kontynuujesz i podążasz za znakami? Na tym właśnie polega projektowanie kontra kodowanie. Kiedy rzeczy są nieznane, kiedy problem jest złożony, kiedy czujesz się zagubiony, wtedy myślenie o projektowaniu jest najbardziej pomocne i lepiej to zrobić wcześniej niż później. O wiele łatwiej jest zmienić projekt, zanim cokolwiek zaimplementujesz .

Diagramy to świetny sposób na zwizualizowanie problemu i pomoc w projektowaniu, szczególnie dla myślicieli wizualnych ( wyobrażam sobie większość z nas na gamedev). Wiele problemów staje się trywialnych, wady stają się oczywiste, gdy są wyraźnie odwzorowane na schemacie. Niektóre problemy, które możesz znaleźć na schemacie:

• Zbyt wiele połączeń z jednym komponentem? Możesz mieć obiekt boga, który jest trudny do utrzymania
• Za dużo połączeń wzajemnych? Być może modułowość można poprawić, aby architektura była mniej krucha
• Zbyt wiele ścieżek między dwoma komponentami? Być może masz ciasne połączenie
• Czy w przypadku aplikacji o wysokiej wydajności, takich jak gry, zbyt wiele elementów jest zaangażowanych w gorącą ścieżkę lub wewnętrzną pętlę? Może to wpłynąć na Twoją wydajność
• Jednak przez większość czasu diagram pokaże niespójności między przewidywanym projektem a faktyczną implementacją

Co więcej, diagramy doskonale nadają się do komunikowania i dokumentowania projektu, zarówno osobom nietechnicznym, jak i nowym w projekcie - i pamiętajcie, że za 6 miesięcy jesteście praktycznie nowi w projekcie!

Sposób korzystania z UML powinien wynikać z tych rozważań. Tworzenie diagramów dla własnego dobra? Używaj dowolnego zapisu, z którym czujesz się najlepiej. Współpracujesz z innymi programistami? Spróbuj podać szczegóły wywołań interfejsu API, typy wiadomości, kierunki zależności. Omawiasz architekturę? Wystarczą czarne skrzynki i proste połączenia. Nikt i tak nie używa pełnego zestawu funkcji UML , a ponadto jest bardzo przydatny jako zestaw znormalizowanej notacji, którą wiele osób rozumie - podczas gdy moje gryzmoły na serwetki mogą być dla ciebie niezrozumiałe i odwrotnie.

Jeśli chodzi o mnie, cały czas korzystam ze schematów - proste rysunki do notatników do osobistych projektów, proste diagramy UML w pracy. Ten diagram UML jest tym, co uważam za zbyt skomplikowane, i którego nigdy nie stworzę, ponieważ koszt jego wytworzenia i utrzymania przewyższa jego zalety, ale oczywiście YMMV.

Powiedziałbym, że istnieją dwa rodzaje diagramów. Formalne diagramy i bazgroły.

Jeśli chodzi o formalne diagramy, robię je, gdy pracuję z innymi programistami, ale rzadko robię to, gdy programuję sam.

Nie oznacza to jednak, że siedzę i koduję wszystko, co przychodzi mi do głowy. Moim zdaniem najważniejszą rzeczą przy programowaniu (a właściwie czymkolwiek w życiu) jest myślenie najpierw, a później robienie tego .

Kodowanie to bardzo mechaniczne zadanie. Wpisujesz, a słowa pojawiają się na ekranie. Chodzi o to, że zanim zaczniesz kodować, powinieneś już rozwiązać problem. Robienie bazgrołów to świetny sposób na uporządkowanie myśli, a nawet zmuszenie się do myślenia, że ​​musisz poprawnie wykonać część kodującą. Nie należy zapisywać bazgrołów do wykorzystania w przyszłości, abyś mógł łatwo zrozumieć swoje procesy myślowe.

Nie martw się, jeśli poświęcisz zbyt dużo czasu na myślenie. Myślę, że równowaga zachodzi, gdy poświęcisz 90% swojego czasu na myślenie i 10% na kodowanie. Spotkałem kilku „starszych” programistów, którzy żyją według „nie mamy czasu na myślenie, tylko na to”. Ale nawet jeśli nazywają swój kod „wykonanym” wcześniej niż ci, którzy poświęcają czas na zastanowienie się nad tym, co robią, to (lub pechowe dusze, które potem pozostały) spędzają niezliczone godziny na naprawianiu i łataniu czegoś, co powinno być poprawnie zbudowane od początku.

Najlepsze jest to, że myślenie jest bezpłatne! nie musisz siedzieć na komputerze, żeby myśleć. Możesz pomyśleć o kodzie podczas jedzenia, dojazdów do pracy, ćwiczeń ... W rzeczywistości najlepsze pomysły przychodzą, kiedy najmniej się ich spodziewasz, więc miej otwarty umysł przez cały czas i zacznij pisać tylko wtedy, gdy naprawdę wiesz, co idę do kodu.

Oto powiązany artykuł, z którym się zgadzam.

Edycja : Jeśli chodzi o rzeczywisty format i typ diagramów, polecam wybrać styl dowolny, a właściwie odręcznie zamiast korzystać z gotowych narzędzi. Pamiętaj, że chodzi o to, aby pomóc ci w procesie myślowym, więc nie krępuj się rysować, co chcesz. Semantyka jest tym, czym ci się podoba, i mogą być różne między diagramami, a nawet między różnymi częściami diagramu.

Istnieją trzy główne zalety schematów freestyle / odręcznych w porównaniu z narzędziami paczkowanymi:

1. Nie musisz przestrzegać schematu obsługiwanego przez dowolne wybrane narzędzie. Czasami mapmindy będą działać, czasem coś bardziej podobnego do UML będzie w porządku, a innym razem zadziała schemat logiczny. Innym razem działa schemat niestandardowy, a żadne narzędzie nie zapewnia pełnej elastyczności diagramów freestyle (spróbuj przebić dziurę w papierze i kontynuować na odwrotnej stronie papieru, w ulubionej paczce i zobacz, co się stanie)

2. Spędzisz więcej czasu na tworzeniu diagramów zamiast na narzędziu. Niezależnie od narzędzia pisanie i pisanie zawsze jest szybsze w tworzeniu diagramów niż wprowadzanie klawiatury i myszy w menu, aby znaleźć określone elementy, których szukasz.

3. Do pisania odręcznego nie potrzebujesz komputera. Przez większość czasu wykonuję skomplikowane projekty, robię je w bibliotece, kawiarni, a nawet w samolocie. Ponadto dobre pomysły zawsze pojawiają się w najmniej odpowiednim momencie, więc pamiętaj, aby zawsze mieć przy sobie coś do pisania i coś do pisania.

Warto wspomnieć o kilku rozmowach dotyczących schematów projektowych z Game Developers Conference 2013. Są to bardzo praktyczne i przetestowane na drodze przykłady - i wydaje się, że były prezentowane na wielu konferencjach na przestrzeni lat.

(Inne odpowiedzi wykonały godną podziwu pracę polegającą na pokazaniu, dlaczego i w jaki sposób diagramy projektowe mogą być niezwykle pomocne w planowaniu, budowaniu, rozwijaniu i utrzymywaniu bazy kodu, więc zostawię ten aspekt w spokoju i ufam, że te zasoby mogą być przydatne każdemu odwiedzającemu pytanie).

Joris Dormans i Ernest Adams omawiali system projektowania gier Machination / diagramów równowagi. (Oto płatne wideo GDC Vault z GDC EU 2012; próbki z GDC 2013 na wiki Dormans.) Zamiast próbować sparafrazować, oto jak wiki opisuje system:

Machination to teoretyczna struktura i interaktywna, dynamiczna, graficzna reprezentacja, która opisuje gry jako systemy dynamiczne i skupia się na zamkniętych pętlach sprzężenia zwrotnego w nich zawartych. Chodzi o to, aby znaleźć sposób na metodologiczną ekspresję i badanie (powtarzających się) struktur gry. Machination oferuje nowe podejście do intuicyjnej i delikatnej praktyki projektowania i równoważenia gier.

Noah Falstein wygłosił przemówienie zatytułowane „Tajemna sztuka łamigłówkowych diagramów zależności” (wideo GDC Vault z zapłatą ). Nie mogę tu znaleźć żadnego linku, który nie jest płatny, ale różni ludzie dyskutowali lub zamieszczali swoje notatki w Internecie.

Obie rozmowy omówiły, kiedy powstały i jak utrzymały te diagramy, w takim czy innym stopniu.

Prawdopodobnie powinieneś sprawdzić ten artykuł na temat używania prostej abstrakcyjnej gramatyki do opisywania swojej pętli rozgrywki, jak może pomóc ci zidentyfikować problemy projektowe i jak łatwo jest iterować na tym poziomie.

http://www.gamasutra.com/blogs/JoshuaStarner/20130205/186060/Applying_Abstract_Models_to_Game_Design.php

Mogę również skierować Cię w kierunku mojej własnej pracy na ten temat, bardziej opartej na ekonomice pętli rozgrywki, wykorzystującej abstrakcyjne zasoby do śledzenia takich rzeczy, jak szanse, szczęście lub przygotowanie:

http://www.stephanebura.com/diagrams/

Jeśli uznasz to za przydatne, powinieneś rzucić okiem na Machynacje Jorisa Dormansa, narzędzie do tworzenia takich diagramów i przeprowadzania ich symulacji:

http://www.jorisdormans.nl/machinations/

Cały jego proces wyjaśniono w jego książce:

http://www.amazon.com/Game-Mechanics-Advanced-Design-Voices/dp/0321820274/