Silnik gry i projektowanie oparte na danych

Słyszałem o projekcie opartym na danych i od dłuższego czasu go badam. Przeczytałem kilka artykułów, aby uzyskać pojęcia.

Jednym z artykułów jest Data Driven Design autorstwa Kyle'a Wilsona. Jak opisał, wydaje mi się, że kod aplikacji (tj. Kod kontrolujący zasoby takie jak pamięć, sieć ...) i kod logiki gry powinny być oddzielone, a kod logiki gry powinien być sterowany przez zewnętrzne źródła danych. W tym momencie mogę sobie wyobrazić, że twórca napisałby jakiś edytor gier, który akceptuje zewnętrzne dane o obiektach w grze (takie jak informacje o postaci, informacje o broni, informacje na mapie ...). Scenariusz zostanie napisany za pomocą niestandardowego języka / narzędzia napisanego przez programistę, aby umożliwić projektantowi gry interakcję między obiektami gry. Projektant gry albo użyje istniejącego / niestandardowego języka skryptowego, aby napisać skrypt do gry, albo przeciągnij i upuść narzędzie, aby stworzyć świat gry. Przykładem narzędzia, które mogę wymyślić, jest World Editor, który zwykle jest pakowany wraz z grami Bliizarda.

Jednak inny artykuł jest przeciwny stosowaniu projektowania opartego na danych, The Case Against Data Driven Design . Autor sugeruje, aby nie pozwolić projektowi gry kierować się danymi, ponieważ opracowanie gry zajęłoby więcej czasu, ponieważ projektant gry ma ciężar programowania. Zamiast tego pojawi się programista gier, który programuje grę swobodnie na podstawie szkicu i jest weryfikowany przez projektanta gry po zakończeniu programowania gry. Nazywa to napędzanym przez programistę. To, co myślę o tej metodzie, jest podobne do tego, co kiedyś: Logika gry to sama aplikacja, podobnie jak w przypadku powyższego pomysłu, aplikacja jest edytorem gier, a rzeczywista gra została zaprojektowana na podstawie tego narzędzia.

Według mnie pierwsza metoda wydaje się bardziej rozsądna, ponieważ elementy gry mogą być ponownie wykorzystane w wielu projektach. W przypadku drugiej metody, która sprzeciwia się projektowi opartemu na danych, kod gry należy tylko do tej gry. Właśnie dlatego uważam, że Warcraft ma tak wiele gatunków gier, takich jak oryginalny Warcraft i różne niestandardowe mapy, i jedna z najbardziej znanych: DOTA, która tak naprawdę definiuje nowy gatunek. Z tego powodu słyszałem, że ludzie nazywają World Editor to silnik gry. Czy to prawda, jak powinien wyglądać silnik gry?

Więc po tym wszystkim chcę tylko zweryfikować, czy jest jakaś wada w moim rozumieniu tych pomysłów (napędzanych danymi, napędem programisty, skryptami itp.)?

Wykorzystywanie danych w grze (lub dowolnym oprogramowaniu) jest prawie zawsze zaletą. Jedyną wadą jest to, że możesz poświęcić nieco więcej czasu na budowanie odpowiednich systemów z góry; opłaci się jednak przez resztę kariery programisty (nawet jeśli nie użyjesz tych samych systemów przez cały ten czas, ponownie użyjesz technik zastosowanych do ich zbudowania).

Wyzwanie, w którym pojawia się rozłączenie w tych dwóch artykułach, które łączysz, to to , co zdecydujesz się umieścić w danych i kogo zdecydujesz się na dostęp do tych danych. Zasadniczo projektowanie i opracowywanie oparte na danych oznacza po prostu, że umieszczasz informacje w pamięci zewnętrznej, ładujesz je w czasie wykonywania i działasz na ich podstawie. Kod aplikacji robi to, co nakazują dane zewnętrzne, a nie piszesz kod aplikacji, który bezpośrednio robi to, co Twoim zdaniem powinien być końcowy rezultat. To nie jest złożony pomysł.

Nie musisz budować złożonych „architektur opartych na komponentach” (jak to jest obecnie w modzie). Umieszczanie stałych dla poprawiania fizyki (siła grawitacji, współczynniki restytucji) w pliku tekstowym zależy od danych. Skrypty (w Lua lub coś innego) są sterowane danymi. Opisywanie danych poziomu w XML. Nic podobnego.

Możesz prowadzić dowolne elementy oprogramowania z danymi, a także wybierać, z którymi chcesz to zrobić. Czas programisty jest drogi; szczególnie czas programisty. Jeśli możesz zaoszczędzić czas siebie lub innych programistów, umieszczając zachowanie i dane w pamięci zewnętrznej i nie wymagając ponownej kompilacji gry przy każdej drobnej zmianie, powinieneś. Zaoszczędzisz pieniądze i szybciej wykonasz zadania.

Ponadto podejmujesz ogromne ryzyko, próbując sprawić, że „projektanci projektują”, a programiści „sprawiają, że projekty te stają się rzeczywistością”, zmuszając programistę do istnienia w pętli iteracji dla pracy projektanta: ryzykujesz, że poczujesz się, jakby jest tylko małpą kodową, ciągle wprowadzając drobiazgowe poprawki do projektu. Może to być ogromnie demoralizujące dla większości programistów, którzy chcą pracować nad interesującymi wyzwaniami technicznymi, a nie być projektantem proxy.

W przypadku konkretnych pytań:

Czy to prawda, jak powinien wyglądać silnik gry?

„Silnik gry” tak naprawdę nie ma ustalonej definicji. Zasadniczo jest to zunifikowany zbiór podstawowych technologii wykorzystywanych do tworzenia gry, zwykle obsługiwany przez wiele powiązanych narzędzi (a tym samym sterowanych danymi). Ale różni się dość szeroko w zależności od kontekstu.

Więc po tym wszystkim chcę tylko zweryfikować, czy jest jakaś wada w moim rozumieniu tych pomysłów (napędzanych danymi, napędem programisty, skryptami itp.)?

Wydaje się, że jesteś mniej więcej na właściwym kursie, chociaż być może nadmiernie komplikujesz projektowanie i rozwój oparty na danych, łącząc go z systemami opartymi na komponentach.

Jako autor drugiego postu chciałbym wyjaśnić kilka kwestii.

1. Jak zasugerował Josh Petrie, ustrukturyzowanie kodu w taki sposób, aby korzystało z danych zamiast zwykłego kodowania, wszystko zawsze wygrywa. Nie sugerowałem inaczej. Wskazywałam, że narzucanie wszystkiego projektantowi nie jest dobrym pomysłem. Termin „projektowanie oparte na danych” oznacza różne rzeczy dla różnych ludzi, więc prawdopodobnie powinienem był być bardziej szczegółowy, kiedy pisałem oryginalny artykuł.
2. W każdym miejscu, w którym pracowałem, tworzymy struktury danych, które można modyfikować w silniku. Aby dokonać zmiany, nie musimy ponownie kompilować gry. Możemy dynamicznie zmieniać liczbę w czasie wykonywania. Struktury danych są często przechowywane w kodzie, ale w zależności od tego, kto je zmienia, można je łatwo załadować z „pliku danych”.
3. Większość środowisk programistycznych obsługuje pewną formę edycji i kontynuowania lub przeładowania modułu dla C / C ++.
4. Większość studiów tworzących gry ma programistów. Ich zadaniem jest często współpraca z projektantem w tworzeniu przyjemnej zabawy. Ich głównym zmartwieniem nie są wyzwania techniczne, a raczej tworzenie zabawy z kodu. Pracuję jako programista gier od wielu lat i uważam to za bardziej interesujące niż tylko rozwiązywanie problemów technicznych. Moje obowiązki są różne, ale moja praca jest najbardziej satysfakcjonująca, gdy jestem odpowiedzialny za wdrożenie i współpracuję z projektantami przy tworzeniu czegoś fajnego. Problem z projektowaniem lub pisaniem skryptów polega na tym, że programiści często muszą rozwiązywać błędy, co jest jedną z najmniej zabawnych rzeczy, które możesz zrobić jako programista.
5. To, co działa najlepiej w studiu, zależy od gry. Jeśli masz dużo czasu, aby stworzyć grę, i chcesz oddać swoje nogi społeczności modów i stworzyć coś o ogromnym zasięgu, to stworzenie gry całkowicie opartej na danych ma sens. Wiele gier nie ma tego celu. Muszą wypuścić nową grę za dwa lata i jeśli nie będą mieli hitu, prawdopodobnie jest to inny rodzaj gry niż ich poprzednia praca
6. To, co robi „projektant”, może różnić się w zależności od studia. Słyszałem o studiu deweloperskim, które zatrudnia programistów z innych studiów, nazywa ich projektantami i zleca im pisanie scenariuszy gry. To pomija problem posiadania ludzi, którzy nie są przeszkoleni w programowaniu kodowania / skryptów.
7. Zawsze powinno być rozróżnienie między kodem logiki gry a kodem silnika. Ponadto zwykle chcesz mieć edytor wizualny do umieszczania obiektów. Nigdy nie pracowałem w studiu, w którym lokalizacje wroga są mocno zakodowane. Są one umieszczane w edytorze. Pozwól mi zaproponować przykład tego, o czym mówię. Powiedzmy, że projektant wymyśla wroga. Czy projektant niż pisze scenariusz zachowania tego nowego typu wroga? To właśnie uważam za projektowanie oparte na danych (pod względem tego, co napisał o tym Tim Moss). W sposób, w jaki proponuję, programista współpracuje z projektantem, robią zabawnego wroga, być może z możliwymi do dostosowania parametrami, a następnie są umieszczani na poziomie.
8. Natywny kod napisany przez programistę będzie działał szybciej w czasie wykonywania niż skrypt napisany przez programistę, który wykona się szybciej niż skrypt napisany przez osobę o mniej technicznym doświadczeniu. Ta wydajność może, ale nie musi być ważna, w zależności od rodzaju tworzonej gry i tego, co robisz, ale warto o tym pomyśleć.
9. Możesz współdzielić kod gry między grami, niezależnie od wybranej metody. Nie jestem do końca pewien, o co ci chodzi z tym punktem. Nawet jeśli nie używasz języka skryptowego lub narzędzia wizualnego do definiowania niektórych zachowań, powinieneś tak bardzo, jak tylko możesz, budować swój kod rozgrywki w komponenty wielokrotnego użytku. Zawsze będą rzeczy, które nie będą miały zastosowania do twojej następnej gry, ale w każdym miejscu, w którym kiedykolwiek pracowałem, kiedy rozpoczynamy kolejną grę, zaczynamy od bazy kodu z poprzedniej - nawet jeśli nie jest to kontynuacja. Następnie zachowujemy sens i usuwamy elementy specyficzne dla gry.

Ostatecznie nie ma dobrej lub złej odpowiedzi. To pytanie, jak Ty i Twoi współpracownicy czujecie się komfortowo w pracy. Kiedy pisałem ten blog jakiś czas temu, dużo mówiło się o tym, jak cała praca powinna zostać przekazana projektantom, i chciałem napisać o tym, jak wiele udanych firm gier, o których wiedziałem, znalazło inną równowagę.

Na marginesie, mój wpis na blogu ma 5 lat. Wygląda na to, że o wiele więcej studiów zmierza w kierunku języków skryptowych i co więcej, ale tworzą dojrzałe narzędzia do debugowania ich, co było moją główną skargą. Kiedy to napisałem, nie sądzę, żeby istniał Unreal Kismet, z którego nie korzystałem, ale wygląda na to, że próbują uprościć skrypty i najwyraźniej ma debugger. (Nie mam pojęcia, jak dobrze to działa)

W przypadku gier na mniejszą skalę zdecydowanie nie sądzę, że chcesz wypróbować język skryptowy lub podobną funkcjonalność w swojej technologii, ale jeśli masz duży zespół i dużo czasu, aby poświęcić się technologii, możesz to zrobić dobrze, a inwestycja czasu może mieć sens w zależności od tego, w jaki sposób Twój zespół programistów lubi pracować. Osobiście prawdopodobnie będę się trzymał C ++ tak długo, jak to możliwe, ponieważ dla mnie jest to najłatwiejszy i najszybszy, ponieważ często muszę próbować obejść „funkcje”, takie jak wyrzucanie elementów bezużytecznych.

Powinieneś spojrzeć na BitSquid Tech Engine . Jest budowany przy użyciu koncepcji DOD. Blog Niklasa Frykholma jest bardzo interesujący. Istnieje wiele artykułów na temat projektowania tego silnika.

Na GDC 2011 Niklas przedstawił prezentację na temat renderowania opartego na danych .