Czy warto skakać przed kodem?

Zawsze myślałem, że planowanie jest ważne dla gry. Ale nie wiem w którym momencie. Niektórzy mówią mi, żebym kodował zamiast planować, ale wydaje mi się, że to wciąż ważne, ponieważ kiedy będziesz w kodzie, będziesz wiedział, co robić dalej. Obecnie pracuję nad grą, która będzie zawierała wiele treści, więc postanowiłem rozpocząć dokument projektowy przedstawiający te treści, a na poziomie bocznym robię weryfikację koncepcji, aby sprawdzić, czy da się to zrobić. Części każdego dowodu koncepcji mogą być później wykorzystane w prawdziwej grze.

EDYCJA: Pracuję sam nad tym projektem.

Więc moje pytanie brzmi: czy warto skakać przed kodem? Nadal jestem zainteresowany tym, co inni mogą o tym powiedzieć. Ponieważ wciąż mam trochę ludzi mówiących, że powinienem kodować zamiast myśleć ... więc jaka jest twoja opinia na ten temat?

W swoim pytaniu powiedziałeś dwie mądre rzeczy:

1. „kod zamiast myślenia” - cała filozofia to opisuje: http://gettingreal.37signals.com/toc.php
2. „dowody koncepcji, aby sprawdzić, czy da się to zrobić” - widziałem i miałem wiele pomysłów, które okazały się niemożliwe lub niezwykle trudne do zrealizowania, gdy były już prawie gotowe. Czasami po prostu nie możesz tego przewidzieć, ponieważ ogranicza Cię twoje środowisko programistyczne (język, biblioteki, wydajność sprzętu).

Dlatego mówię:

• projektuj, ale nie rób wielkiego projektu-dokumentu, jeśli nie szukasz współpracowników lub inwestorów, chyba że jest to dla ciebie fajne i traktujesz to jako przerwę od programowania;
• zawsze miej na uwadze to, co chcesz osiągnąć; każdy moduł powinien mieć zaprojektowane wejście i wyjście; w ten sposób możesz łatwo przetestować moduł i nie mieć poczucia wędrówki we mgle;
• pamiętaj, że i tak projektujesz większość czasu, ponieważ pisanie kodu zajmuje tylko około 5% twojego czasu (przynajmniej wpisywanie końcowego kodu);
• programowanie nie jest nauką teoretyczną, zamiast sprawdzać, czy coś zadziała na kartce papieru, możesz po prostu to zakodować i spróbować; w produkcie końcowym chodzi przede wszystkim o to, by wkład użytkownika był niezawodny, GUI wyglądał ładnie i zajmował się specjalnymi przypadkami - od razu można wykonać brudny test pomysłu;
• utwórz listę rzeczy do zrobienia, jeśli boisz się zapomnieć o swoich pomysłach
• rozmawiaj z przyjaciółmi o swoich pomysłach, ponieważ będą mniej entuzjastyczni i mogą mieć więcej doświadczenia w danej dziedzinie; Kiedyś wpadłem na pomysł, aby zachować parametry jednostki (w grze strategicznej) w tajemnicy, ale mój przyjaciel powiedział mi, że to zły pomysł, ponieważ grał w taką grę i była to straszna frajda dla użytkownika.

Tak, ale tylko trochę .

Do programowania gier, szczególnie programowania gier, ważne jest, aby mieć dobry przypadek użycia przed napisaniem jakiegokolwiek kodu. Np. Co powinien zrobić gracz, dokąd ma iść i jak, jak wchodzi w interakcje ze światem itp. Może to być scenariusz naszkicowany na papierze lub wynik dyskusji z rówieśnikiem ... jest częścią projektowania gry i głupotą byłoby zacząć kodować, nawet nie mając pojęcia o tym, jak powinna być rozgrywana.

Ale gry muszą być tworzone iteracyjnie . Nie możesz stworzyć ogromnej specyfikacji dla swojej gry i mam nadzieję, że będzie fajnie się w nią grało. Potrzebujesz regularnego testowania, aby dowiedzieć się, co działa, a co nie, i powtarzać. Najszybsze uruchamianie działa, najszybszy projekt gry można przetestować, najlepiej gra na końcu. Dlatego zawsze lepiej jest zacząć kodować jak najszybciej, od bardzo nieformalnego projektu gry, zobaczyć, co się wydarza i kontynuować.

Jedno jest pewne, ponieważ kodujesz sam, nie potrzebujesz żadnego wymyślnego dokumentu projektowego ani metodologii, kod źródłowy to projekt.

Niektórzy twierdzą, że powinieneś kodować zamiast myśleć? Cóż, aby zakodować, musisz wiedzieć, co chcesz stworzyć, aby wiedzieć, co chcesz stworzyć, najpierw musisz pomyśleć, co chcesz mieć, to znaczy, musisz pomyśleć, zanim zaczniesz kodować;).

I na poważnie, prawdopodobnie nie potrzebujesz szczegółowego planu na samym początku, ale posiadanie konspektu i / lub kamieni milowych jest zawsze korzystne - również dla twojej postawy, gdy przekreślasz rzeczy jako zrobione, będziesz bardziej zachęcany do robienia więcej praca.

Potrzebne jest zarówno kodowanie, jak i planowanie. Najpierw plan, potem kod, ale nie planuj wszystkiego naraz. Zaplanuj rdzeń, zakoduj go, w razie potrzeby zaktualizuj swój plan, a następnie zaplanuj funkcje, które składają się na grywalność, grafikę, dźwięki, duszki itp., Dzięki temu tworzona gra będzie wyglądać lepiej i ogólnie lepiej. Oczywiście możesz uruchomić taki cykl więcej niż jeden raz i radzę podejmować decyzje, które będą wspierały skalowanie w razie potrzeby.

Musisz wiedzieć, dokąd zmierzasz, zanim napiszesz kod, a pisanie / rysowanie może być dobrym sposobem na zmaterializowanie tego, co chcesz osiągnąć. Mówię rysowanie, ponieważ rysowanie diagramów, szkiców itp. Również może ci bardzo pomóc. Nie musisz tworzyć wspaniałego dokumentu wykonanego za pomocą Worda lub czegokolwiek, po prostu weź ołówek i kawałek papieru (dużo kawałków papieru?) I narysuj, napisz wszystko, o czym możesz pomyśleć.

Dla mnie dobrą praktyką jest używanie ołówka i papieru, pomaga w urzeczywistnianiu pomysłów, a także pozwala ustalić, gdzie chcesz się udać, aby gdziekolwiek się nie udać, ustalić swój cel. Działa na wszystko, co wymaga refleksji. I w wielu domenach oczywiste jest zapisanie rzeczy przed wykonaniem rzeczywistej pracy.

Rób wszystko, co dla ciebie działa. Osobiście planuję rzeczy w niewielkim stopniu, ale nie mam dokumentów projektowych, które są bardzo szczegółowymi planami, zanim zacznę coś kodować. Rób wszystko, co jest dla ciebie najbardziej wydajne, zwłaszcza, że ​​pracujesz sam.

(Zakładam, że pytanie jest postawione z punktu widzenia projektowania kodu / architektury, a nie projektowania gier, chociaż odpowiedź przynajmniej w pewnym stopniu dotyczy obu).

Jak już powiedziano, potrzebujesz obu i musisz to zrównoważyć. Zarówno przeprojektowanie, jak i za mało zaprojektowanie przepływu / struktury kodu może powodować problemy. Trudno powiedzieć, jaka jest właściwa równowaga, ale ogólnie uważam, że muszę mieć co najmniej niejasne pojęcie, jak reszta kodu połączy się z tym, co programuję w tej chwili, i zastanowić się nad możliwymi problemami, w przeciwnym razie mam tendencję do „zakodowania się w ślepy zaułek” - dostaję się do sytuacji, w której zdaję sobie sprawę „dobrze, teraz dzięki temu, jak rozwiązałem ten problem, stworzyłem nowy problem, który sprawił, że całe moje poprzednie rozwiązanie (lub nawet więcej, w najgorszych przypadkach ) daremny ”.

Generalnie, moim zdaniem, możesz z grubsza ocenić, czy masz właściwą równowagę, myśląc o scenariuszach „co jeśli” jak w „co jeśli później (kiedy wszystko zostanie w pełni zaimplementowane w podobnym paradygmacie, którego używam teraz) dowiesz się ta część A musi działać nieco inaczej, co oznacza, że ​​muszę całkowicie przerobić część B, która się z nią łączy, aby uwzględnić zmiany? ”. Jeśli zmiana architektoniczna w jednej części nie wymaga zmiany więcej niż jednej lub dwóch innych części, a zmiany nie następują kaskadowo (co oznacza, że ​​z kolei trzeba zmienić również kolejne części łączące się z częścią B, a następnie części łączące się z im itp.), kod jest podzielony na przedziały w stosunkowo dobry sposób.

Ale tak naprawdę jest to coś, co można poczuć po zdobyciu doświadczenia. To po części dlatego wszyscy doradzają początkującym graczom, aby najpierw napisali kod czegoś znanego i łatwego (Breakout / Tetris / Snake) i zrobili to całkowicie, ze wszystkimi menu, dźwiękami, efektami, wszystkim, aby gra była w pełni skończona - lepiej zepsuć mniejszy projekt, a zrobienie go (w dobry lub zły sposób) dokładnie pomoże ci zrozumieć, jak daleko sięgają skutki różnych decyzji architektonicznych.