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

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”?

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.

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.

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!

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.

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ść.

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.