Jak uzyskać przydatne dane z testerów gier? [Zamknięte]

Istnieje kilka rodzajów informacji zwrotnych od testerów gier i zastanawiam się, jak najlepiej zebrać dane dla każdego z nich ...

1. Raporty o awariach. Kiedy moja gra C ++ ulega awarii, gdy ktoś w nią gra, to jak najlepiej się upewnić, że wiem o niej, a jeszcze lepiej ... co ją spowodowało? Nawet uzyskanie czegoś tak prostego jak plik i numer linii, który spowodował awarię, byłoby niezwykle pomocne.

2. Informacje zwrotne dotyczące projektu. Kiedy tester gier gra, jak mogę się dowiedzieć, czy dobrze się bawią, dlaczego się bawią, dlaczego się nie bawią i co powinniśmy poświęcić na dostosowanie się?

Zakładam, że mówisz o testerach na stronie, a nie o beta testerach internetowych.

Zasada nr 1: Nie pomagaj im . Frustracja powinna być najważniejszą rzeczą, którą powinieneś sprawdzić. Idealną sytuacją byłoby dwukierunkowe lustro z zespołem z jednej strony i playtesterem z drugiej z jedną kamerą wideo na twarzy, a drugą na ekranie. Oczywiście nie jest to możliwe dla większości ludzi, więc zrób co możesz. Samo siedzenie projektantów i obserwowanie, gdzie ludzie utkną, jest bardzo przydatną informacją. Kiedy zabiorą grę do domu, nie będziesz stać nad ich ramieniem, więc udzielanie porad dotyczących przejścia niektórych sekcji nie zapewni ci potrzebnych informacji. Edycja : inny sposób ujęcia tego jest następujący: nie myśl, że „źle się bawią”

Zasada 2: Nie dawaj im tego, czego chcą . Po sesji testowej masz jakiś kwestionariusz, który wypełniają. Konkretne sugestie, które mają, zwykle nie są rozsądne, aby przyjąć wartość nominalną. Zwykle istnieje jakaś pierwotna przyczyna, która wywołuje większość odpowiedzi i po prostu nie wiedzą, jak to wyrazić. Jeśli potrafisz to rozgryźć, lepiej to zrobisz. Chociaż w tej chwili mam problem z wymyśleniem konkretnych przykładów.

Zasada 3: Dane są królem . Jeśli możesz (i to jest naprawdę kolejny element listy życzeń, szczerze mówiąc), śledź wszystko, co możesz. Śledź, gdzie umierają gracze. Śledź, gdzie kończy się amunicja z określonego pistoletu. Śledź, jakie przetworniki brakuje. Śledź, jakie aktualizacje kupują. Śledź, jakie wrogowie wyrządzają im szkody. Oczywiście są to przykłady specyficzne dla FPS, ale jestem pewien, że istnieją pewne domeny dla każdej gry, którą robisz. Jeśli wszyscy coś robią lub czegoś nie robią, zwykle są to obszary, na które powinieneś poświęcić trochę więcej czasu.

Zasadniczo nie obchodzi Cię, co myśli gracz . Zależy Ci na otrzymywaniu surowych liczb za to, co robią gracze . Potrzebujesz dziewiczych oczu, aby zobaczyć swoją grę i powiedzieć, co sprawia, że ​​są sfrustrowani i do czego są zmuszani.

W przypadku awarii sprawdź minidumps . Nie są idealne, ale są bardzo przydatnym narzędziem do ustalenia, gdzie występują awarie.

Weź również pod uwagę wbudowane narzędzie do zgłaszania błędów. Coś, w którym użytkownik może zrobić zrzut ekranu, dodać opis i wysłać go automatycznie do kogoś z poziomu gry. Idealnie z migawką świata (np. Szybkie zapisywanie lub zrzut pamięci), jeśli Twoja gra to obsługuje.

Aby rozwinąć dane, należy nieco poczuć króla (+1 do Tetradu!):

Sprawdź nagrywanie i odtwarzanie :

• Jeśli gra jest deterministyczna i oparta na ramkach, może być konieczne zapisanie początkowego losowego początku i krotki w (key/button state, joystick/mouse coords, frame #)dowolnym momencie zmiany stanu wejściowego. Odtwarzanie jest tak proste, jak przekierowanie danych wejściowych do tego strumienia. (W przeszłości robiliśmy to dla wielu gier platformowych.)
• Jeśli gra ma dobrze zdefiniowane interfejsy API lub systemy komunikatów do wykonywania działań (turowa gra strategiczna, gra karciana, gra planszowa itp.), Możesz być w stanie zebrać wywołania API lub wiadomości w określonym punkcie szczypania . (Zrobiliśmy to w przypadku gry karcianej na platformę podręczną).
• W niektórych systemach jest trudniej (mniej deterministyczne, wątkowe lub arbitralne systemy pomiaru czasu mogą być uciążliwe), ale i tak warto rejestrować dane; możesz uzyskać wyniki „wystarczająco blisko” dla niektórych zastosowań.

System „powtarzania” oparty na tych metodach ma wiele zalet:

• używać go do odtwarzania awarii podczas debugowania lub kompilacji lub środowiska w inny sposób;
• wczytaj powtórki w kompilacji profilowania i uzyskaj dane dotyczące wydajności lub zużycia zasobów;
• podłącz go do gry, aby zapewnić funkcję „natychmiastowej powtórki”, być może z innym aparatem lub krokiem;
• skonfiguruj grę demonstracyjną w „trybie przyciągania”, jeśli użytkownik trzyma się nic w menu;
• umieść go w swoim systemie kompilacji jako test zadymienia: jeśli mogę odtworzyć tę powtórkę bez awarii, jest to bardziej dobra kompilacja;
• obserwuj przykłady ludzi grających, aby zobaczyć, co zrobili, a czego nie zrobili.

Podłącz losowo, a nie nagrany strumień, i masz świetny test małpy , który możesz zostawić moczenie na noc lub za każdym razem, gdy twoje maszyny programistyczne są bezczynne.

Następnie zrób nagranie zdarzenia . Aby uzyskać hipotetyczny FPS, zacznij od czegoś takiego jak „czas T: X zabił Y w punkcie Z bronią W”: umieść go w dzienniku.

Po zebraniu danych dowiedz się, jak zautomatyzować gromadzenie danych . Podczas projektowania nie musi być elegancki:

• połącz się z serwerem SQL i wstaw wiersze,
• odpalaj i zapomnij pakiety UDP na prostym serwerze syslog-ish,
• wyślij e-mail do dziennika przy następnym uruchomieniu gry,
• po prostu zawiń plik wykonywalny w skrypcie powłoki lub pliku wsadowym, który zmienia nazwę i kopiuje plik .log na wspólny wspólny dysk,
• (później, w przypadku kompilacji produkcyjnych) użyj Raportowania błędów systemu Windows lub podobnej usługi do zbierania danych o awariach ...

To naprawdę nie ma znaczenia, o ile można zbierać dane.

Teraz rozszerz go: zbieraj zrzuty awarii, ślady stosów oraz nagrania wejściowe lub zdarzeń. Dodaj więcej wydarzeń i więcej źródeł danych:

• próbuj pozycję gracza lub rękę co 10 sekund, wykreśl to na mapie - „hej, nikt nie korzysta z tego kąta, który spędziłem na modelowaniu przez tydzień, czas na ulepszenie”
• getFreeMemoryBytes() co pół minuty
• getFPS() cyklicznie
• zrób zdjęcie lub nagraj film wideo o tym, co użytkownik robi za pomocą kamery internetowej (idealne do automatycznego testowania użyteczności - oczywiście tylko za zgodą i zrozumieniem użytkownika)
• pobierz informacje o systemie (ponownie za zgodą użytkownika)

Sprawa „nakreśl na mapie” po pewnym czasie może stać się naprawdę niesamowita: wyobraź sobie widok z lotu ptaka mapy RTS lub FPS. Umieść na nim suwak reprezentujący czas od początku gry. Wybierz typ zdarzenia („dostał złoto”, „zabił kogoś”, cokolwiek). Wybierz zestaw danych: może jedna gra, może 500 gier w ciągu ostatnich kilku miesięcy. Zacznij pociągać suwak w prawo i obserwuj, jak aktywność pojawia się na mapie.

A jeśli nie możesz znaleźć dobrych bibliotek, które mogą ci w tym pomóc (jest ich jednak sporo!), Zastanów się nad stworzeniem własnego: jest to dobre doświadczenie edukacyjne i nie musi być szczególnie eleganckie być użytecznym.

Zdobądź dane, a dowiesz się, co z nimi zrobić. =)

Oczywiście zależy to w dużej mierze od: a) jakiego rodzaju testów chcesz przeprowadzić, oraz b) jakiej gry testujesz, oraz c) jakie testery i infrastrukturę masz do dyspozycji ...

Różni się również bardzo, jeśli testujesz pod kątem a) funkcjonalności, b) równoważenia c) projektowania gier

Ale ogólnie możesz rozważyć te aspekty ...

* a) Wybierz odpowiednią osobę do pracy Brzmi zbyt prosto, by o niej wspomnieć, ale widziałem ją wiele razy i po prostu widziałem ją na żywo. Jak zawsze istnieją znaczące różnice między ludźmi pod względem tego, jak dobrze sobie radzą w różnych zawodach. Niektórzy ludzie, którzy chcą lub mogą chcieć przeprowadzić testy, mogą nie grać wystarczająco dokładnie, aby znaleźć nietypowe (lub nawet proste) błędy. Niektóre nie są dobre w opisywaniu błędów. Niektóre są lepsze w testowaniu problemów z równoważeniem, niektóre bardziej zwracają uwagę na słabości wizualne, niektóre są bardziej kreatywne w grze w nietypowy sposób i znajdują ukryte / rzadkie błędy, niektóre bardziej zwracają uwagę na jakość techniczną lub wizualną, niektóre lepiej rozumieją aspekty mechaniki gry i może być nawet w stanie zasugerować znaczące zmiany (jeśli chcesz, aby testerzy to zrobili;).

* b) Używaj oprogramowania do śledzenia problemów / śledzenia błędów Narzędzia te mogą nie tylko pomóc w uporządkowaniu problemów, ale także w poprawie jakości wyników testerów, dając im ramę do pracy i ucząc się na podstawie otrzymanych opinii od programistów na temat ich problemów. Pomaga poprawić jakość wyników testerów o wiele szybciej niż w przypadku pracy bez nich. (Pomaga również wiele ze zdalnych testerów) Typowe oprogramowanie wykorzystywane przez Game Studios to znaczy Mantis, JIRA, (i oczywiście wiele innych ..) Patrz Wikipedii dla ogólnej listy, a także tego wątku na SO.

c) Dodaj narzędzia do testowania w grze Typowe są skróty do testowania określonych poziomów lub sekcji gry. Wyświetlanie dodatkowych informacji podczas gry testerom, aby mogli dodać je do raportów błędów. Może to być pozycja na poziomie, liczba aktywnych obiektów w scenie, ilość aktualnie używanego ramka tekstur lub palet, cokolwiek pomocnego dla programistów.

d) Połącz doświadczonych testerów ze świeżą krwią Zawsze dobrze jest mieć testerów, którzy są bardzo doświadczeni w twojej grze i nauczyli się, jakie są typowe problemy i jak je (ponownie) testować. Jednocześnie chcesz od czasu do czasu nowych „dziewiczych” graczy, szczególnie do balansowania.

e) Poproś Kierownika Testów Kogoś, kto koordynuje proces i dostosowuje go do danej gry, aktualnych priorytetów oraz dostępnych testerów i środowiska testowego.

f) Przygotuj dokument z planem testowania. Byłoby to warte dodatkowego wpisu.

Jak wspomniał Tetrad, uzyskaj jak najwięcej obiektywnych danych. Umieszczanie haków do przechowywania niektórych zdarzeń i zrzucanie ich wszystkich do pliku .csv nie jest bardzo trudne. A kiedy już masz to w Excelu, możesz uczyć się, rysować i kreślić, aż krowy wrócą do domu.

Miej też konkretne pytania, na które chcesz odpowiedzieć. Naukowcy nie tylko siadają, odpalają eksperymenty i „uprawiają naukę”. Mają konkretne, mierzalne pytania, na temat których chcą danych. Często skorzystasz z możliwości testowania, jeśli zastosujesz to samo podejście. Bardzo trudno jest ustalić, czy gra jest „dobra”. Ale zastanowienie się, czy prosta misja samouczka zajmuje tylko 5 minut, których się spodziewasz, czy też testerzy próbują rozwiązać pewną zagadkę, można faktycznie ocenić.

Czasami najskuteczniejszym sposobem testowania jest iteracja w krótkich seriach. Poproś kilku testerów, by poszli około godziny rano, wprowadź zmiany w zidentyfikowanych przez nich problemach, a następnego dnia ponownie skorzystaj z nowych testerów. Oczywiście musisz przyjrzeć się funkcji wystarczająco małej, aby poprawić ją po południu. Ale w przypadku problemu, który był szczególnie uparty, ta metoda może być bardzo skuteczna.

Zdecydowanie zgadzam się z regułą nr 1 Tetrad. Nie pomagaj im. Powiedziałbym, że zastrzeżeniem jest wyjaśnienie im, że nie pomożesz im, a jeśli potrzebują pomocy, zapytaj. W ten sposób gracz nie jest sfrustrowany.

Kwestionariusz powinien zadawać pytania otwarte, zamiast prostych tak / nie, w zależności od wieku i liczby testerów mogą to być formularze, które wypełniają, lub możesz zadawać pytania. Ważne jest również zadawanie pytań na temat ich historii i znajomości gatunku gier, w którym je testujesz; to doda kontekst do konkretnych odpowiedzi na temat twojej gry.

Na szczęście, gdy moja gra się zawiesza, daje mi zrzut informacji o błędzie, więc mogę zrobić zdjęcie i zanotować, co robił gracz. Zwykle testuję młodsze grupy wiekowe, więc kiedy mamy awarię, muszę pamiętać, aby wyjaśnić im, że wykonują świetną robotę - mogą się zdenerwować po zerwaniu gry. Playtesterzy naprawdę okazali się świetni w znajdowaniu niejasnych błędów, których zespół deweloperów nigdy nie spotkałby, grając we „właściwą” drogę.

Możliwe jest napisanie kodu, który wyłapuje awarie i rejestruje stos wywołań. To może bardzo pomóc w zgłaszaniu błędów. Pomaga również wygenerowanie przydatnego pliku dziennika. Możesz poprosić użytkownika o przesłanie tych plików przy następnym uruchomieniu lub mieć samodzielne narzędzie, które uruchomi się po zamknięciu gry lub ulegnie awarii, jeśli chcesz.

W przypadku raportów o awariach powinieneś polegać na płatnym personelu kontroli jakości, a nie na testerach gier. QA to osoba, którą zatrudniasz specjalnie ze względu na ich umiejętność znajdowania błędów i zgłaszania ich w znaczący sposób, a dobry tester jest wart swojej wagi w złocie (i kosztuje tylko jedną dziesiątą swojej wagi w złocie, w porównaniu do programistów!).

Jeśli martwisz się o „och, co jeśli przypadkowo odkryją awarię, nie chcielibyśmy przegapić tego tylko dlatego, że nie testują tego”… po to jest rejestrowanie. Wystarczająco dobry system rejestrowania powinien rejestrować wystarczającą liczbę elementów gry, aby móc dokładnie odtworzyć awarię.

Informacje zwrotne od projektantów nie mogą zastąpić oglądania ich przez projektantów gier (lub korzystania z magnetowidu, jeśli musisz itp.). Nie polegaj na pamięci lub opiniach z playtestera, z których oba są notorycznie słabe. Ale jeśli patrzysz, jak grają w czasie rzeczywistym, jest to oczywiste po prostu patrząc na ich twarz i postawę ciała, czy są zaangażowani, znudzeni, czy sfrustrowani.