Planowanie gier i projektowanie oprogramowania? Uważam, że UML nie jest wygodny

21

Na mojej uczelni zawsze kładą nacisk na projektowanie UML i inne rzeczy, w których, jak sądzę, nie będzie to dobrze działać przy projektowaniu struktury gry. Chcę tylko profesjonalnej porady, jak rozpocząć projektowanie gry? Historia polega na tym, że mam trochę umiejętności programowania i wykonałem wiele drobnych gier, takich jak praca nad platformówką 2D do pewnego stopnia. Problemy, które znajduję w moim programie, to niska jakość projektu. Po pewnym czasie kodowania sprawy zaczynają się psuć z powodu złego planowania (gdy dodam nową funkcję, zwykle zmuszam mnie do przekodowania całego programu). Jednak zaplanowanie wszystkiego bez jednej wady projektowej jest nieco zbyt idealne. Dlatego masz jakieś wskazówki, jak zaplanować grę? Jak powinienem umieścić go na widocznych zdjęciach, abyśmy ja i moi przyjaciele mogli przeglądać projekty?

Planowałem zacząć kodować grę z moim przyjacielem. To będzie moja pierwsza praca zespołowa, więc wszelkie profesjonalne porady byłyby przyjemnością. Czy istnieją inne alternatywy niż UML?

Kolejne pytanie brzmi: jak zwykle wygląda „prototypowanie”?

użytkownik1542
źródło
26
UML to bzdury. To źle zaprojektowany paradygmat, który sprawia, że ​​biznesmeni czują, że coś produkują i rozumieją, podczas gdy w rzeczywistości tworzą tylko bezużyteczne ograniczenia.
o0 ”.
Chociaż zdecydowanie uważam, że UML ma miejsce w oprogramowaniu biznesowym, nie jest przeznaczony do projektowania czegokolwiek zbyt interaktywnego. Spróbuj znaleźć dokumenty dotyczące projektowania gier dla istniejących gier, aby zobaczyć, jak radzą sobie z formalnymi sprawami, coś w tym rodzaju: delta3d.org/filemgmt_data/files /... staraj się też pamiętać o robieniu wielu prototypów i nie bój się „wyrzucić” rzeczy (tutaj wyrzucenie oznacza półkę w systemie kontroli źródła i nieużywanie jej aktywnie).
Roy T.
4
Używam xmind do planowania wszystkiego. Nie użyłbym technicznych rzeczy takich jak UML, chyba że jestem do tego zmuszony. Ważne jest, aby wizualizować rzeczy przed przejściem do kwestii technicznych. Mapowanie myśli jest twoim przyjacielem. Możesz go użyć do planowania rzeczy technicznych.
On Shing
Imho, dużym problemem związanym z UML jest brak narzędzi do konwertowania diagramów na np. Deklaracje klas i funkcji i vice versa. UML jest świetnym narzędziem do wizualizacji i komunikowania pomysłów między członkami zespołu, ale sposób, w jaki większość przepływów pracy w UML bez narzędzi wykonuje określone czynności dwa razy, powoduje nadmierne wykorzystanie UML w przypadku małych projektów i / lub projektów hobbystycznych. Osobiście używam pióra i papieru do wizualizacji relacji między klasami i bytami w pewnego rodzaju pseudo-UML. Miło jest uzyskać przegląd interakcji klasowych i hierarchii.
Exilyth,

Odpowiedzi:

18

Chcę tylko profesjonalnej porady, jak zacząć projektowanie gry?

Projekt gry jest specyfikacją rozgrywki, zasobów, systemów punktacji itp. - nie są one specyficzne dla oprogramowania. Jako taki, UML jest niewłaściwym narzędziem do tego zadania.

Jeśli chodzi o projektowanie kodu do implementacji tych systemów, UML jest dobrym narzędziem do tego zadania, zapewniając Twojemu zespołowi znać go i trzymać się bardziej powszechnych typów diagramów. Zwykle, próbując zaprojektować funkcję, będziesz wiedział, czy potrzebujesz użyć opisu, czy diagramu. Jeśli potrzebujesz użyć diagramu, UML daje standardowy sposób rysowania go, co jest dobrą rzeczą.

Po pewnym czasie kodowania sprawy zaczynają się psuć z powodu złego planowania (gdy dodam nową funkcję, zwykle zmuszam mnie do przekodowania całego programu).

Jest to generalnie problem związany ze sposobem programowania, a nie planowaniem. Dobre oprogramowanie zazwyczaj jest łatwe do rozszerzenia i ponownego użycia. Jeśli będziesz trzymać się dobrych praktyk programistycznych, problem ten zmniejszy się. Ale lepsze planowanie również pomoże i nie potrzebujesz do tego skomplikowanych diagramów. Posiadanie listy funkcji oznacza, że ​​kodując jedną rzecz, masz na uwadze inne funkcje i możesz brać je pod uwagę podczas kodowania.

Dlatego masz jakieś wskazówki, jak zaplanować grę? Jak powinienem umieścić go na widocznych zdjęciach, abyśmy ja i moi przyjaciele mogli przeglądać projekty?

Wygląda na to, że mieszasz tutaj 2 problemy, projekt gry i projekt kodu.

Proponuję najpierw napisać podstawowy projekt gry, określając potrzebne funkcje, potrzebną grafikę i dźwięki, sposób wygrywania i przegrywania gry itp. Wyszukaj „dokumenty projektowe”, jeśli potrzebujesz pomocy.

Stamtąd będziesz miał pojęcie o funkcjach, które musisz zakodować. Możesz po kolei patrzeć na każdą funkcję i zastanawiać się, jak je wdrożyć. Diagramy mogą pomóc pokazać relacje między różnymi klasami i przedmiotami w twojej grze, ale umiejętność rozpoznania, które przedmioty muszą istnieć, jest czymś, czego musisz się nauczyć poprzez praktykę i / lub dalsze czytanie.

Spróbuj także pracować nad mniejszymi, mniej ambitnymi projektami. Dzięki temu przyzwyczaisz się do pisania dobrego, działającego kodu, bez potrzeby obszernego planowania lub przepisywania.

Kylotan
źródło
Chyba zmiksowałem to. Myślę, że mógłbym powiedzieć, że naprawdę mam jakieś surowe pomysły na system gier. Chciałbym jednak wiedzieć, jak mogę skutecznie rozwiązać mój problem z projektowaniem „kodu”? Lub innymi słowy, skutecznie przetłumaczyć moją strukturę gry na kod? Zwykle muszę wybierać między poświęceniem dużo czasu na uogólnienie kodu a szybkim kodowaniem specyficznym. Zwykle pierwszy zabrał mi piekło, więc poszedłem na drugiego, a potem
wpadłem
2
Wygląda na to, że nadal nie masz doświadczenia w modelowaniu oprogramowania (modelowanie to proces tłumaczenia abstrakcyjnego projektu na konkretne wdrożenie). Obawiam się, że to naprawdę poprawi się tylko wraz z doświadczeniem. Dobrym sposobem na sprawdzenie, czy robisz postępy, jest od czasu do czasu sprawdzanie swojego kodu sprzed ponad 6 miesięcy. Jeśli nie znajdziesz niczego, co napisałbyś inaczej (lub po prostu lepiej), jeśli przepisałeś to, prawdopodobnie nie poprawiłeś tego w tym czasie.
TravisG
Zgadzam się z heishe - doświadczenie jest jedynym realnym rozwiązaniem tutaj, w połączeniu z nauką liczenia doświadczenia. Staraj się czytać i rozumieć podstawowe pojęcia, takie jak enkapsulacja i abstrakcja, bardziej złożone, takie jak Prawo Demetera i Zasada Jednej Odpowiedzialności, i zrozum wystarczająco Wzorce Projektowe, aby zobaczyć, gdzie niektóre mogą ci pomóc. Ta wiedza w połączeniu z praktyką daje narzędzia do tłumaczenia pomysłów na działający kod.
Kylotan,
2

Niezrozumienie czegoś ułatwia oddalenie. UML to narzędzie inżynieryjne służące do komunikowania pomysłów w uporządkowany sposób. Gra to system, który można zaprojektować jak każdy inny. Złożoność i dynamika gry sprawiają, że wizualna reprezentacja jej części i ich interakcji jest nieoceniona.

Diagramy UML to różne widoki modelu omawianego systemu. Zaczynam od przypadków użycia dla osoby siedzącej przed moim programem i rozpoczynającej go. W przypadku gry istnieją dwa rodzaje użytkowników: projektanci i gracze. Piszę przypadek użycia dla każdej rzeczy, którą widzę, jak to robią. Następnie robię karty CRC, aby dowiedzieć się, jakie usługi muszę świadczyć. Następnie tworzę diagram klas dla interfejsów, które zapewnią te usługi i ich relacje. Jest to oparte na kartach CRC. Następne są dynamiczne diagramy dla zdarzeń takich jak inicjalizacja, które wymagają planowania i aranżacji. Następnie bardziej szczegółowe schematy statyczne przedstawiające klasy implementujące interfejsy.

Cały czas piszę kod i prototypuję go i rozwijam w kierunku świadczenia usług wspierających spełnianie wymagań mojej gry. Nie powstaje nic, co nie obsługuje użytkownika poprzez przypadki użycia. Piszę kilka bezużytecznych elementów diagramu, ale między kodowaniem interfejsu a tworzeniem diagramów piszę bardzo mało niepotrzebnego kodu. Schematy dają mi pewność, że rozumiem, w jaki sposób klasa, którą piszę, pasuje do całego systemu.

Chodzi mi o to, że trywialny program można napisać bez planów, ale gra jest trywialna. Jakiś czas temu, kiedy OOP był nowy, przeprowadzono wiele eksperymentów i na pierwszy plan wysunęły się najlepsze praktyki. Społeczność programistów zgodziła się, że potrzebujemy języka do pisania i analizowania projektów oprogramowania. UML to język, który opracowaliśmy. Wszyscy to wiemy i rozumiemy, więc jeśli chcesz skorzystać z rozwiązań innych osób w swoich problemach (książki, dyskusje online, artykuły, katalogi wzorów itp.), A nie wymyślać koła, musisz nauczyć się czytać standardowy zapis. Jako bonus, gdy zmuszasz się do myślenia o swoim systemie w innym języku, uczysz się nieoczekiwanych rzeczy.

Istnieje wiele różnych metodologii, ale wszystkie one identyfikują problem i opisują jedno rozwiązanie w sposób systematyczny. To jest inżynieria. UML jest ogromny i złożony, ale żaden model nie używa każdej konstrukcji. To jest jak szwajcarski scyzoryk. Musisz go poznać i dowiedzieć się, jak go używać do wspierania procesu inżynieryjnego. Ważna jest nie to, który proces lub metodologia, ale to, że ją masz. W przeciwnym razie utopisz się w złożoności.

Sinthia V.
źródło
2

Pracuję również nad niektórymi niezależnymi projektami gier z przyjacielem (2-osobowy zespół). Jako osoba w podobnej sytuacji do twojej, mogę zaoferować kilka ciekawostek, które uważam za pomocne.

  1. Jeśli Twoje pomysły są surowe, spróbuj wdrożyć je pojedynczo w bardzo małych projektach prototypowych. Na przykład, teraz tworzę grę platformową 2D, a poprawne wykonanie skoku przez gracza jest dla mnie niezwykle ważne. Zrobiłem więc nowy projekt, w którym jedyne dwie rzeczy, które się zdarzają, to: a) Rysowanie odtwarzacza na ekranie oraz b) Wykrywanie danych wejściowych i przerysowywanie skoku [postać nie może nawet poruszać się w lewo ani w prawo]
  2. Niektórzy ludzie mogą krzywo patrzeć na tę radę, ale najpierw pomyśl o napisaniu instrukcji gry (aby wyjaśnić pojęcia, kontrole, cele). To może zrobić dla ciebie 2 rzeczy - wygenerować bardzo potrzebny dokument, ale także nakreślić podsystemy twojej gry i wszelkie niezbędne szczegóły dla gracza. Jeśli wiesz z góry, co gracz powinien wiedzieć, to wiesz z góry, co musisz zrobić.
  3. Napisz kod w wystarczająco małych (zwanych także modułowymi ) kawałkami, aby podzielone na części kawałki można było przesuwać lub lepiej zorganizować bez poczucia, że ​​próbujesz usunąć wszystkie średniej wielkości kawałki spaghetti z talerza makaronu.

Mam nadzieję, że znalazłeś tam przynajmniej jedną przydatną informację i powodzenia!

C. Griffin
źródło
1

Myślę, że jest kilka cennych rzeczy z UML, których nie można zaprzeczyć. z drugiej strony, pamiętaj, że UML został zbudowany dla procesów biznesowych , wiesz, modeluje systemy, w których wiele osób wchodzi w interakcję z nimi, a wszystkie mają różne potrzeby i potrzeby i pragnienia. UML stara się upewnić, że niczego nie pominiesz ani nie zostaniesz przytłoczony szczegółami.

UML to „standardowy sposób wizualizacji architektury systemu”

UML opisuje

  • zajęcia
  • aktorzy
  • procesy biznesowe
  • schematy bazy danych
  • (logiczne) komponenty
  • instrukcje języka programowania
  • elementy oprogramowania wielokrotnego użytku

Ale jeśli tworzysz prostą grę, czy naprawdę musisz to wszystko wymodelować?

  • Aktorzy: gracz.

Jak bardzo to pomaga?

Modelowanie niektórych innych rzeczy jest jednak bardzo pomocne. Na przykład, jeśli tworzysz małą grę MMO, zdecydowanie chcesz dobrze zaprojektowane schematy baz danych.

Tak więc chociaż odejścia od UML są doskonałe (wiedz, co robisz, zapisz wymagania i szkicuj diagramy schematów blokowych tam, gdzie jest to potrzebne), a jego elementy są bardzo przydatne, mam wrażenie, że pełny proces UML jest trochę kwadratowego okrągłego otworu do gier.

Bobobobo
źródło
1
Aktorzy: projektanci, artyści, gracze sieciowi (jeśli masz szczęście) finansowi, qa ludzie. Komunikacja między projektantami, programistami, klientami, użytkownikami końcowymi i programistami jest co najwyżej fatalna w każdej branży oprogramowania, jaką widziałem. UML to narzędzie zapewniające interesariuszowi wspólny język do omawiania projektu. W świecie programistów panuje pewna wrogość wobec takich rzeczy jak dokumentacja (programiści) i kontrola / współpraca ze źródłami (projektanci), co naprawdę obniża jakość ostatecznego projektu. Większość tych rzeczy są budowane przez zespoły, więc musimy się nimi dzielić.
Sinthia V
@SinthiaV Aktorzy nie mają być zespołem deweloperów . Aktorzy to ludzie, którzy wchodzą w interakcję z produktem końcowym .
bobobobo
Co z edytorami i silnikami poziomów / zasobów? To był przypadek użycia, o którym mówiłem.
Sinthia V
0

UML nie jest jedną rzeczą, jest zbiorem rzeczy, które niektóre z nich cenią inne tak bardzo. starsze style Przypadki użycia (przynajmniej tak zwane przypadki użycia), które określają

  • imię
  • wymagania
  • warunki wstępne
  • wyzwalacze
  • działania
  • alternatywne działania
  • wyjątki

może być całkiem przydatny. chociaż to, co znajdziesz w „Use Cases”, jeśli przeprowadzasz wyszukiwanie w sieci (zdjęcia), to raczej ogólne oprogramowanie.

Przydałbym się również pewnemu schematowi klasy. pokazuje to, że jesteś w stanie pokazać związek między wszystkimi swoimi obiektami i znasz układ swojej architektury.

sprowadza się to do tego, że cały zestaw funkcji powinien być dokładnie zaplanowany i zablokowany int (wynajęty w konfiguracji potrzebnej / potrzebnej) przed modelowaniem, a nawet należy rozpocząć tworzenie diagramów. wszystkie powinny znajdować się w skrócie / Traktowaniu / Skrypcie (czasami określane jako wysokość, dokument funkcji i historia). następnie stamtąd wykonasz swoje dokumenty techniczne, które mają twoje modele i diagramy.

są firmy, które używają UML, ale zwykle są to firmy, które mają oddzielne zespoły projektowe i wdrożeniowe. firmy, które utworzą całą swoją dokumentację, a następnie przekażą ją zespołowi małp kodowych w celu stworzenia prototypu / alfa. mówi się, że jeśli możesz dokładnie wymodelować swoją grę, powinieneś być w stanie przekazać ją zupełnie innemu zespołowi i pozwolić im ją zaprogramować, chociaż jest to bardziej fajny sen niż dokładność.

gardian06
źródło
0

Będą uczyć cię o UML na twoim uniwersytecie, aby pomóc ci przekazać swoje pomysły reszcie twojego zespołu i pokazać wykładowcom, że masz dobrą praktyczną wiedzę na temat podstawowych zasad inżynierii oprogramowania.

Jak każda dyskusja na temat języka, narzędzi lub projektu - zazwyczaj sprowadza się to do tego, w jaki sposób Z niego korzystasz. Wybierz najlepsze narzędzie / język / projekt do pracy i poprzyj swój wybór z mocnym uzasadnieniem. Przyznaję, że UML nie jest tak elastyczny w produkcji gier, chociaż mogę powiedzieć, że skutecznie go wykorzystaliśmy do modelowania funkcji silnika, takich jak komunikacja i synchronizacja sieci, równoległe zarządzanie zadaniami i przypadki użycia. Nie ma nic gorszego niż wyjaśnienie tej samej rzeczy 5 różnym członkom zespołu 10 razy, ponieważ nie do końca to rozumieją. Oto dokumentacja, przeczytaj ją.

W zależności od tego, jak solidne są twoje projekty i jak zdyscyplinowany jest twój zespół, może być dość produktywne, aby móc modelować własne konstrukcje wokół tych, które jeszcze nie zostały jeszcze uruchomione, a jednocześnie wiedzieć dokładnie, jak będą działać z powodu dokumentacja.

Mimo to prawdopodobnie usłyszysz (i uświadomisz sobie ostro), że są to ŻYWE DOKUMENTY, a jeśli nie będą regularnie sprawdzane i aktualizowane, szybko staną się przestarzałe i skutecznie bezużyteczne.

Esteta
źródło