Nexus Devlog: prototyp silnika

▶

Watch on YouTube

Półtora miesiąca temu wrzuciłem na stronę plany studia - o silniku Nexus: czym jest i jakie projekty będziemy na nim robić, aż po strategie i kontynuacje serii egipskiej. Była tam też mapa drogowa. Silnik jest skomplikowany i żeby zmniejszyć ryzyko, chciałem składać go stopniowo. Ale gracze w komentarzach powiedzieli wprost: czegoś takiego nie da się złożyć. Dlatego postanowiłem zacząć od prototypu - pokazać, że taki silnik jednak da się zbudować. I właśnie go pokażę.

Oto jak silnik wygląda teraz. Z wierzchu to dość prymitywna aplikacja konsolowa. Ale dobrze pokazuje najważniejsze - że różne mechaniki działają na jednym uniwersalnym silniku.

Teraz działają na nim cztery symulacje. Pierwsza to Stone Age, najwcześniejsza gra studia, z 2013 roku. Pozostałe trzy są zrobione na podstawie cudzych projektów. Nie zamierzam ich kopiować ani wydawać, są tu tylko po to, żeby pokazać, że na jednym silniku mogą działać zupełnie różne mechaniki gier.

Stone Age

Stone Age odtworzono na silniku w całości. Te same cechy, lata i tury, populacja, ziemie. Robotników wysyłasz do lasu, zdobywają jedzenie, populacja rośnie, pojawiają się technologie - badasz je, odblokowujesz budowle i drzewo ewolucji, od australopiteka do człowieka zręcznego i dalej. Wydarzenia, zakończenie - wszystko z oryginału jest na miejscu.

Slay the Spire

Dalej - Slay the Spire, świetny karciany roguelike, ktoś na pewno grał. Na silniku jest tylko walka: gracz ma karty, energię i zdrowie, a wróg swój zamiar. Strike (Cios) bije, Defend (Obrona) stawia blok. Wydajesz energię, kończysz turę, i tak na zmianę, aż ktoś wygra.

GURPS

Trzecia symulacja to GURPS, papierowy system RPG, dość skomplikowany. Wziąłem z niego tylko jeden moduł, generator układów gwiezdnych. Ciekawe jest to, że sam ten moduł to w ogóle nie gra, tylko skomplikowany generator. Złożył układ z jedną gwiazdą i masą właściwości: dziesięć orbit, a na nich różne światy. Pierwszy, mały i skalisty, przypomina Merkurego - z własną masą, ciśnieniem atmosfery i całą resztą. W sumie w tej symulacji jest ponad sześć tysięcy faktów. To dobry test obciążeniowy: widać, ile danych silnik udźwignie.

Oregon Trail

Czwarta - Oregon Trail, klasyka z 1971 roku i jedna z najwcześniejszych gier komputerowych. To droga osadników przez Amerykę wozami: przed wyruszeniem kupujesz zapasy - woły, jedzenie, naboje, odzież - a potem polujesz, rozdzielasz racje i radzisz sobie z wydarzeniami. Właśnie nas napadnięto. I tak aż do końca trasy.

Wszystkie cztery gry działają na jednym silniku i dla żadnej z nich nie trzeba było pisać kodu.

Zmiany na bieżąco

Ale silnik nie tylko uruchamia te gry - można je zmieniać na bieżąco, nie ruszając kodu. Weźmy Slay the Spire.

Zmienię obrażenia karty Strike (Cios), ustawię 100:

/set Strike.CalcDamage Value 100

Właściwość zmieniła się od razu u obu takich kart, bo mają wspólną klasę.

A można też dodać zupełnie nową kartę, Fireball (Kula ognia):

/add Fireball Is DirectDamage
/set Fireball.CostEnergy Value 2
/add Fireball Has CalcDamage
/set Fireball.CalcDamage Value 20
/add Fireball Has ApplyDamage
/add Fireball.ExecutionEffects Has CostEnergy
/add Fireball.ExecutionEffects Has CalcDamage
/add Fireball.ExecutionEffects Has ApplyDamage

Nie było jej, a teraz jest w grze - leży w ręce, daje się zagrać, zadaje 20 obrażeń i idzie na stos kart odrzuconych, jak każda inna:

Można zmienić i same reguły, jednym poleceniem. Usunę regułę, według której zagrane karty trafiają na stos kart odrzuconych.

/remove PlayCard Has MovePlayedCard

Teraz zostają w ręce. Zagrałem Defend (Obrona): blok się pojawił, energia się zużyła, a karta została.

W zwykłej grze, napisanej w języku programowania, trzeba by w tym celu grzebać w kodzie i przebudowywać projekt. Tutaj nie ma takiej potrzeby.

Tak samo do gry dodaje się i to, czego wcześniej w niej w ogóle nie było. Na przykład złoto - wprowadzę je i opiszę, jak się je wydaje:

/set Player.Gold Value 100
/add CostGold Output Owner.Gold
/add CostGold Math.Subtract.Apply true

Pojawia się cecha, której przed chwilą nie było - złoto, i od razu cała setka.

Na tym złocie można zrobić i nowe działanie - Bribe (Łapówka). Wydaje nie energię, tylko złoto:

/add Bribe Is DirectDamage
/set Bribe.CostEnergy Value 0
/set Bribe.CostGold Value 30
/add Bribe Has CalcDamage
/set Bribe.CalcDamage Value 15
/add Bribe Has ApplyDamage
/add Bribe Has CostGold
/add Bribe.ExecutionEffects Has CostGold
/add Bribe.ExecutionEffects Has CalcDamage
/add Bribe.ExecutionEffects Has ApplyDamage
/create Bribe Player.Hand

Bribe (Łapówka) kosztuje trzydzieści złota i zadaje piętnaście obrażeń - i od razu działa.

Może się wydawać, że to cheaty i że wpisywanie takich poleceń jest niewygodne. Ale to nie cheaty. To edycja faktów logicznych i danych, na których trzyma się cała gra - jej obiektów, właściwości i mechanik. W gruncie rzeczy to język, w którym gra jest napisana.

Uczyć się tego języka nie trzeba. Można poprosić AI, żeby przełożyło zwykłe zdanie na polecenia, które rozumie Nexus. Na przykład:

give 999 gold

W tłumaczeniu to po prostu „Dodaj 999 złota”.

AI myśli, znajduje odpowiednie polecenie i je wykonuje, i mamy 999 złota.

Można powiedzieć inaczej, „złoto 100” - też zadziała. „Uczyń mnie bogiem” - AI daje niewrażliwość. Zakończyć turę, uderzyć, uleczyć się - wszystko to można zrobić słowami, silnik rozumie. I nic z tego nie jest zaskryptowane, wszystko działa naprawdę.

Plany

Polecenia chcę uprościć. Teraz, żeby stworzyć tego samego Fireballa (Kula ognia), trzeba około ośmiu poleceń, a myślę, żeby zejść do trzech-czterech. A w następnym filmie postaram się pokazać coś bardziej obrazowego - render 2D.

Więcej o silniku i planach - w sekcji Nexus.

Zastrzeżenie: Stone Age to gra studia. Slay the Spire, GURPS i Oregon Trail należą do swoich właścicieli i są pokazane wyłącznie jako demonstracja silnika - te wersje nie są nigdzie rozpowszechniane.