Główne wymagania dotyczące projektu

*Ta zawartość została przetłumaczona przy użyciu narzędzi AI (w wersji beta) i może zawierać błędy. Aby wyświetlić tę stronę w języku angielskim, kliknij tutaj.

Następująca lista przedstawia przegląd głównych wymagań dotyczących projektu technicznego, o których myśleliśmy, pracując nad Tajemnicą Duvall Drive.Aby uzyskać więcej informacji na temat wizualnego projektowania tych elementów, zobacz Tajemnicę pokazu Duvall Drive, który podkreśla różne funkcje i narzędzia Studio, których użyliśmy do tworzenia wciągającego środowisko.

Misje

Istnieje kilka rodzajów misji, które gracze muszą rozwiązać, aby postępować w doświadczeniu, w tym nawigowanie po serii obracających się platform, aż gracze będą w stanie odzyskać specjalny przedmiot lub znaleźć różne składniki w rozszerzającej się spiżarni i umieścić je w garnku gotującym.Aby zorganizować proces tworzenia i debugowania misji, stworzyliśmy ramę misji i wersję debugowania.

Rama misji

Aby zapewnić, że zjednoczymy każdy krok misji w trakcie doświadczenia, zaprojektowaliśmy prostą ramę misji puzzle dla każdej misji, która składała się z haków na start i koniec puzzle, miejsca do odczytu danych konfiguracyjnych oraz przycisku do ukończenia puzzle dla celów debugowania.Aby uzyskać bardziej szczegółowe informacje o tym procesie i jego parametrach, zobacz Logika misji.

Foki i stany gry

Kiedy gracze weszli do określonych pokoi, chcieliśmy, aby wchodzili w interakcję z specjalnymi małymi obiektami znanymi jako foki, aby uruchomić misje.Po rozwiązaniu misji chcieliśmy, aby zabrali pieczęć i umieścili ją w określonej lokalizacji w holu, aby kontynuować ogólną rozgrywka.Po umieszczeniu pieczęci we właściwym miejscu mogli następnie kontynuować w innym pokoju w domu i rozpocząć następną misję, klikając na specjalny obiekt w tym pokoju.

Rozwinęliśmy prosty system chwytania, aby trzymać obiekt, przymocowując obiekt do prawego ramienia postaci.
Przedpokój, w którym gracze muszą umieścić każdą pieczęć, aby postępować w doświadczeniu.

Aby to zrealizować, stworzyliśmy stan gry , który określałby okres czasu, w którym gracze mogliby rozpocząć proces tak:

  • Szukanie „uszkodzonego” pieczęcia w pokoju, aby uruchomić misję.
  • Podnieś pieczęć "przywróconą", gdy rozwiążą misję.
  • Umieść pieczęć w kręgu foyer.

Stany gry w dużej mierze kontrolują przepływ doświadczenia i sposób interakcji graczy z narracją doświadczenia .Aby uzyskać więcej informacji, zobacz GameStateManager.

Normalne i skorumpowane pokoje

Chcieliśmy mieć dwa stany sześciu pokoi w domu: normalny stan i skorumpowany stan.Kiedy gracz dotknie skażonego pieczęcia w pokoju, aby uruchomić skażony stan pokoju, środowisko zmieni się na ciemniejszą atmosferę z modyfikowanym oświetleniem, obiektami środowiskowymi i efektami specjalnymi.Gracze musieliby wówczas rozwiązać misję, aby powrócić do normalnego stanu pokoju.

Normalny stan badania
Korupcyjny stan badania

Aby to zrealizować, przygotowaliśmy specjalną przestrzeń w doświadczeniu, która była bardzo daleko od domu, około 6,500 metrów w kierunku X , który mógł pomieścić skorumpowany stan pokoju.Kiedy gracz uruchamia jakikolwiek skorumpowany stan, skorumpowany stan tego konkretnego pokoju klonuje się w tym obszarze od ServerStorage do katalogu TempStorage/Cloned , a następnie gracze teleportują się w to pokój.Małe Parts istnieją w każdym normalnym i zanieczyszczonym pokoju, które służą jako punkty spawn dla graczy przy wchodzeniu lub opuszczaniu pokoi.Po rozwiązaniu misji jednocześnie teleportujemy graczy z powrotem do normalnego stanu pokoju i niszczymy wszystkie obiekty w złym stanie pokoju.Aby uzyskać więcej informacji o stanie gry, który kontroluje ten proces teleportacji, zobacz GameStateManager.

Wersja debugowania

Aby pomóc nam w okresowym debugowaniu misji, stworzyliśmy wersję doświadczenia, w której nie musielibyśmy czekać w lobby lub na sceny cięcia.Ta wersja miała skróty klawiaturowe i przyciski, które umożliwiłyby nam automatyczne ukończenie misji, abyśmy mogli szybko przetestować aspekty doświadczenia.Okresowo kopiowalibyśmy i publikowalibyśmy tę wersję w wersji, którą planowaliśmy wydać, miała odpowiedni przepływ gry.Aby odróżnić te dwie wersje, stworzyliśmy skrypt DemoGlobalSettings , aby sprawdzić miejsceID, zobaczyć, czy jest uruchamiany w Studio, i włączyć/wyłączyć różne sztuczki i przyciski gry.Aby uzyskać więcej informacji, zobacz Logika misji i Skrypty konfiguracyjne.

Teleportacja

Istnieją trzy rodzaje teleportacji, które występują w doświadczeniu:

  1. Teleportowanie graczy z prostego lobby do głównej strefy rozgrywki w zarezerwowanej witrynie.
  2. Teleportowanie graczy z normalnego stanu pokoju do uszkodzonego stanu, a następnie z powrotem, gdy pokazujesz scenkę cięcia.
  3. Teleportowanie graczy w niektórych zagadkach lub po tym, jak odpadną z obszaru rozgrywki.

Zarezerwowane serwery

Postanowiliśmy grupować graczy w grupy pięciu w prostym lobby przed przeniesieniem ich na rezerwowany serwer przed główną strefą rozgrywki domu .Lobby zapewniło czas dla dodatkowych graczy, aby dołączyli i grali razem, a zarezerwowane serwery uniemożliwiły dodatkowym graczom pominięcie aspektów gry i narracji z dołączeniem do doświadczenia na późno.Ta teleportacja zdarza się tylko raz.

Sceny cięcia

Chcieliśmy być w stanie przetransportować graczy w trakcie gry za każdym razem, gdy wykonają pewne zadania, takie jak dotknięcie foki lub ukończenie misji.Aby to zrealizować, opracowaliśmy prostą wersję narzędzia opartego na skryptach o nazwie EventManager , które kontrolowało różne właściwości i atrybuty, uruchamiało skrypty i dźwiękoraz wykonywało wstrząsy kamery przez określony czas.Umożliwiło to nam jednoczesne przesuwanie graczy i przesyłanie strumieni do i z różnych pokoi, ukrywając ten proces przed graczem za pomocą specjalnych efektów.Aby uzyskać więcej informacji, zobacz Menadżer wydarzeń.

Odrodź graczy

Trzeci typ teleportacji, który chcieliśmy wdrożyć, to krótki teleport z jedyną zmianą koordynatów gracza CFrame w niektórych zagadkach i gdy gracze upadają i odrodzą się.W przeciwieństwie do poprzednich dwóch rodzajów teleportacji ten rodzaj nie prosi wyraźnie o asynową transmisję.

Skryptowanie rozgrywki

Skryptowanie pozwoliło nam wykonać na konkretnych elementach rozgrywki, takich jak znikające elementy interfejsu użytkownika, tworzenie sygnałów dźwiękowych dla kluczowych wydarzeń i podświetlanie obiektów, gdy były w focusie z kursoром gracza.Wiele z tych systemów polegało na oznaczaniu obiektów do wykonywania niestandardowego zachowania, a następnie na wykorzystaniu różnych skryptów klienta lub serwera, aby zawierać różne przepływy pracy w zależności od tego, jakie działanie musiało się wydarzyć w określonych punktach doświadczenia.Aby uzyskać więcej informacji o tym, jak wdrożyliśmy te systemy, zobacz podstawowe systemy rozgrywki i systemy wspierające.

Niestandardowe zachowanie z tagami

Chcieliśmy sposób na dodanie niestandardowego zachowania dla obiektów, takiego jak blokowanie drzwi, aby gracze musieli pozostać w pokoju, dopóki nie zakończą aktywnej misji.Aby to zrealizować, zdecydowaliśmy się używać tagów dla konkretnych obiektów, następnie użyliśmy CollectionService do znalezienia tych obiektów i połączenia dowolnego odpowiedniego Scripts do dodania niestandardowego zachowania.Mieliśmy jeden Script dla każdej kategorii tagów, które działały jako menedżer, aby obsługiwać wszystkie obiekty oznaczone w tej kategorii, więc mogliśmy przechowywać Script w jednym miejscu, a nie kopiować ich wiele razy w DataModel.Aby uzyskać więcej informacji, zobacz DoorManager , MasterAnimator , DrawerManager , KillVolumes , PlayerMissionRespawn i PianoManager.

Funkcja "menedżera" Script używa funkcji Init w celu znalezienia dowolnych obiektów oznaczonych, gdy rozpoczyna się doświadczenie, i połączenia z nimi niestandardowego zachowania.Na przykład, DoorManager znajduje każdy obiekt oznaczony tagiem Drzwi , następnie przypisuje poprawne zachowanie do obiektów drzwi (otwiera drzwi, gdy kliknięto, odtwarza dźwięk efektu kołysania drzwi itp.).Jednak wszelkie obiekty dodane lub usunięte podczas uruchamiania, takie jak każdy obiekt dodany do skorumpowanego pokoju po interakcji gracza z skorumpowaną uszczelką, przegapią ten początkowy wezwanie i nigdy nie uzyskają oczekiwanego zachowania.Aby to rozwiązać, używamy CollectionService.GetInstanceAddedSignal i CollectionService.GetInstanceRemovedSignal , aby przyznać to samo zachowanie nowym obiektom oznaczonym i nieoznakowanym odpowiednio.

Skrypty klienta i serwera

Chcieliśmy zmniejszyć przepustowość dla różnych aspektów rozgrywki, które byłyby drogie w wykonywanie.Zdecydowaliśmy, że gdy funkcjonalność obiektu może wpłynąć na symulację dla innych graczy, takich jak przemieszczanie obiektu przez kolizję, uruchomimy to na serwerze , ale jeśli coś jest bardziej związane z projektowaniem środowiska, takie jak światła, animacje środowiskowe, które nie wpływają na rozgrywka, efekty specjalne i dźwięk, uruchomimy je na klientach .Zmniejszyłoby to przepustowość i utrzymałoby płynniejsze zmiany ruchu i środowiska na urządzeniach użytkownika.