Jakie są największe pułapki, które należy wziąć pod uwagę przy opracowywaniu nowej gry?

Właśnie zacząłem śledzić (dzięki Davidowi Youngowi za korektę nazewnictwa) kilka nowych gier internetowych na Facebooku kilka tygodni temu i właśnie byłem zalany blokami umysłowymi i czasem do ponownego kodowania. Pracuję nad czymś podobnym do turowej gry RPG. Mam umiejętności kodowania gry, ale prześlizguję się przez próby poprawienia wzorców projektowych i dopasowania produktu do tego, co widzę w moich oczach.

Zwykle podczas tworzenia strony internetowej lubię „myśleć w kodzie” i uważam, że szybsze jest po prostu zmienianie kodu / HTML, aby go ulepszyć. Jest tak prawdopodobnie dlatego, że jestem BARDZO komfortowy w tym, co robię i wiem, czego się spodziewać tak jak robiłem to w kółko. W tym momencie przy tworzeniu gier zaczynam od nowa na papierze (tak jak kiedyś ze stronami internetowymi) i zastanawiam się, czy to tylko mój brak koncentracji i intuicji w logice gry, czy też jest to odpowiedni sposób na rozwinięcie moich myśli postęp kodowania.

Byłbym wdzięczny za porady, jak prawidłowo zaatakować ten problem i utrzymać się na zadaniu. Szybko uczę się, jak bardzo różni się silnik gry od standardowej strony biznesowej! Za każdym razem, gdy coś robię na swoim miejscu, wydaje mi się, że jest to coś złego i niekompletnego, i staje się cholernie frustrujące.

Rozszerzony

Jako przykład, silnik bitewny, który dawał mi tak duży problem, ostatnio bierze prostą umiejętność ataku, a następnie wykonuje losowy rzut między -50% a + 50%, a następnie zwielokrotnia pierwotną umiejętność ataku przez ten procent. To samo dzieje się z obroną, a następnie zestawiam je w siatkę, aby ustalić, czy jakiekolwiek szkody zostaną wyrządzone przeciw zdrowiu wroga. Wydaje mi się, że powinienem zdać sobie sprawę, że jestem nad głową, kiedy zacząłem zadawać sobie pytanie, czy jest to nawet właściwy sposób, aby to zrobić, czy też istnieje JEST „właściwy” sposób. Jedną z głównych wad, które znalazłem przy tym, są dwie postacie na tym samym poziomie, które mogą mieć kilka rzutów, w których atak wynosi -50%, a obrona wynosi + 50%, więc kończę z NIEZWYKLE długimi sekwencjami bitew, w których nikt nic nie robi. ZAWIEŚĆ

Może mój post powinien zawierać prośby o sugerowane linki opisujące prostą logikę gry.

End Extension

Z góry dziękuję wszystkim!

dodając zbyt wiele funkcji. Skoncentruj się na rdzeniu gry, zbuduj go, a jeśli wszystko działa dobrze, dodaj funkcje. Ludzie zbyt skupiają się na dodawaniu fajnych rzeczy i nigdy nie robią nic.

To świetny artykuł na temat tworzenia prototypów gry. Z twojego pytania wynika, że ​​nie rozumiesz, czym powinien być prototyp.

Prototypowanie: (prawdopodobnie) robisz to źle

Nota wydawnicza:

Błąd nr 4: Budowanie systemu, a nie gry
Kiedy tworzysz prototyp, jeśli kiedykolwiek pracujesz nad czymś, co nie jest bezpośrednim posunięciem naprzód, zatrzymaj się właśnie tam. Jako programiści staramy się uogólniać nasz kod, nadawać mu elegancji i być w stanie poradzić sobie w każdej sytuacji. Stwierdzamy, że swędzenie jest wyjątkowo trudne, a nie zadrapanie, ale musimy się nauczyć. Wiele lat zajęło mi uświadomienie sobie, że nie chodzi o kod, ale o grę, którą ostatecznie dostarczasz.

Nie pisz eleganckiego systemu elementów gry, całkowicie pomiń edytor i podłącz kod do stanu, unikaj opartego na danych, parsowania, szaleństwa XML i po prostu koduj to cholerstwo.

Edytować:

Dodam to tylko w celu wyjaśnienia różnicy między Prototypem a Kodem śledzenia.

Zawsze pamiętaj: Prototyp został zaprojektowany do wyrzucenia! Kod śledzenia nie jest.

Prototypowa pułapka

... Podejście do kodu śledzenia rozwiązuje inny problem. Musisz wiedzieć, jak aplikacja jako całość zawiesza się razem. Chcesz pokazać użytkownikom, jak interakcje będą działać w praktyce, i chcesz dać swoim programistom szkielet architektoniczny, na którym można zawiesić kod. W takim przypadku możesz skonstruować moduł śledzący składający się z trywialnej implementacji algorytmu pakowania kontenerów (może coś w rodzaju „kto pierwszy, ten lepszy”) i prosty, ale działający interfejs użytkownika. Po połączeniu wszystkich komponentów w aplikacji masz strukturę do pokazania użytkownikom i programistom. Z biegiem czasu dodajesz do tego frameworka z nową funkcjonalnością, wypełniając rutynowe procedury. Ale struktura pozostaje nienaruszona i wiesz, że system będzie nadal zachowywał się tak, jak po ukończeniu pierwszego kodu śledzenia.

Rozróżnienie jest na tyle ważne, że uzasadnia powtórzenie. Prototypowanie generuje kod jednorazowy. Kod śledzenia jest ubogi, ale kompletny i stanowi część szkieletu końcowego systemu. Pomyśl o prototypowaniu jako o zebraniu rozpoznawczym i wywiadowczym, które ma miejsce przed wystrzeleniem jednego pocisku znacznika.

Więcej informacji o projekcie Tracer Code, od The Pragmatic Programmer

Kule i prototypy

Pułapki: brak oddzielenia logiki od danych. Nie testowanie, czy Twoje dane dają pożądane wyniki.

Z Twojego komentarza do posta Joe:

Chcesz, żebym napisał kod silnika bitewnego na potwory, BOOM! W tym tygodniu napisałem silnik przynajmniej trzy razy i nigdy nie czuję się z tym dobrze. Mam na myśli, że matematyka działa, ale kiedy ją wypróbowuję, po prostu czuję się niepewnie. Czy to ma sens?

Wygląda na to, że łączysz silnik z danymi tutaj. Silnik twojego potwora powinien być napędzany danymi. Jeśli dane wpływające na równowagę / zabawę w grze są nieprawidłowe, nie powinno być potrzeby całkowicie przepisywać silnika - po prostu modyfikuj zmienne balansu, aż poczujesz się dobrze.

Ponieważ jednak zmienne bilansowe są czasami współzależne, zmiana jednej zmiennej na lepszą w jednym scenariuszu może mieć ogromny (negatywny) wpływ na inne scenariusze.

Aby przetestować, czy twoje nowo poprawione dane nie psują całej gamy innych przypadków, warto zachować kilka przypadków testowych i upewnić się, że nie są uszkodzone po poprawieniu. Oto wymyślony przykład tego, jak byś to przetestował.

TestResult TestPlayerKillsMonsterDuringAttack(PlayerStats, MonsterStats, seed)
{
   Player player(PlayerStats);
   Monster monster(MonsterStats);


EncounterEngine.SeedRNG(seed);

   while(1)
   {
     result = EncounterEngine.Attack(player, monster);
     if (result == PLAYER_DEAD)
       return TEST_FAIL;
     if (result == MONSTER_DEAD)
       return TEST_PASS;
     // result == MONSTER_DAMAGED, PLAYER_DAMAGED is expected. 
   }
}

Na przykład. Jeśli nazwiesz to za pomocą PlayerStats.Level == 5 i MonsterStats.Level == 3, możesz oczekiwać, że gracz zawsze ostatecznie pokona tego potwora.

Pułapka tutaj, o ile widzę, polega na tym, że traktujesz programowanie i projektowanie gier jako to samo zadanie, podczas gdy tak naprawdę są to oddzielne zadania. Jak sugerujesz, nie jest to problem programistyczny ani algorytmiczny (możesz kodować system bitwy w dowolny sposób), chodzi o to, co jest zabawne i interesujące dla gracza.

Odpowiedź brzmi: poszukaj zasobów na temat projektowania gier i równowagi gry. W rzeczywistości istnieją uniwersytety, które poświęcają cały czteroletni program studiów na poruszane tematy, więc udzielenie szybkiej i nieczystej odpowiedzi jest niemożliwe (w ten sam sposób, w jaki prawdopodobnie wpadłbyś w zakłopotanie, gdyby ktoś powiedział „ tak, mam pomysł na grę, ale nie wiem jak ją zaprogramować, na co mam uważać? ”). Istnieją książki, kursy i teksty online dotyczące projektowania gier; odszukaj ich.

Największą pułapką przy pisaniu gier jest martwienie się o to, czy używasz odpowiednich wzorców projektowych, a nie po prostu pisanie kodu, w którym czujesz się dobrze.

Polecam Steve Pavlina artykuły „s o zarządzaniu czasem i motywacji: http://stevepavlina.narod.ru/

On też jest programistą. Jego eksperymenty związane ze stylem życia wywołały zainteresowanie mediów głównego nurtu.