EDYCJA (2): Ponieważ są dwie odpowiedzi i nie zaakceptowałem żadnej z nich, pomyślałem, że zmotywuję to, co rozważę tutaj: albo coś silnie sugerującego, że takie podejście byłoby niemożliwe / wcale nie przydatne lub , alternatywnie, odniesienie do badań (dziedziny) lub przykładów co najmniej nieco ogólnego takiego systemu poza tekstowymi grami przygodowymi / interaktywną fikcją.
Chociaż nie będę udawał, że przeprowadziłem głębsze dochodzenie, zauważyłem, że wszystkie silniki / frameworki, na które patrzyłem, wydawały się być niczym gloryfikowany silnik graficzny w tym sensie, że mówią o kształtach / bytach lub trójwymiarowa przestrzeń euklidesowa z, być może, „pewną formą modelu współbieżności” „założoną”, pozwalającą na określenie jakiejś formy logiki dołączonej do tych „bytów”.
„Zasady” i narracja gry są następnie pisane w sposób ad-hoc (w odniesieniu do silnika) na tych prymitywach.
Oczywiście powyższy opis jest raczej uproszczony (weź bardziej wyspecjalizowane silniki, takie jak silnik nieskończoności, który zawiera jakąś formę systemu poszukiwań / narracji) i zdaję sobie sprawę, że ten model może działać całkiem dobrze (wiele osób go używało) .
Zastanawiam się jednak, jakie podjęto próby stworzenia silników / ram, które przyjmują takie pojęcia, jak (wysoki poziom) opis reguł / logiki lub narracji gry (lub przynajmniej nieprzestrzenny aspekt gry) jako główny podstawa?
EDYCJA (4): Nie oznacza to, że gra nie zawierałaby żadnych aspektów przestrzennych / graficznych, tylko że zamiast obiektów przestrzennych, z którymi kojarzysz logikę, masz pojęcie fabuły (lub rozgrywki lub „zasad gry planszowej” ), który następnie opisuje interfejs graficzny do / realizacji.
Szczególnie zainteresowałbym się wszelkimi deklaratywnymi podejściami, które próbują uchwycić pewnego rodzaju (pół-) formalną semantykę jakiejś dość dużej klasy gier, w sposób przydatny do faktycznej implementacji (w przeciwieństwie do, na przykład, ramy wyłącznie dla analiza jakościowa gier / narracji).
Widziałem kilka badań nad modelowaniem / analizą narracji za pomocą modelu opartego na sieci Petriego i kilka interesujących podejść do langiug do pisania interaktywnej fikcji .
EDYCJA (1): Pomyślałem, że dodam zabawkowy przykład do zilustrowania.
Powiedzmy, że byliśmy zainteresowani tworzeniem przygód w stylu wskaż i kliknij (pomyśl o grach SCUMM). Można je przeanalizować jako oparte na pojęciu mniej więcej liniowym i dyskretnym przejścia od sytuacji początkowej do końca.
Koncentrując się na pojęciu dyskretnego postępu i dopuszczając pewną nieliniowość, można wybrać teorię (ograniczonego) DAG jako podstawową teorię. Określenie gry tego typu w jej (w stosunku do tej teorii) najbardziej abstrakcyjnej formie odpowiada zatem dodaniu dodatkowych aksjomatów do tej teorii (albo tak, że teoria określa konkretny wykres, albo po prostu wystarcza do uchwycenia tego, co uważa się za konieczne do uchwycenia tych "wątek").
Przekształcenie tego w rzeczywistą grę staje się teraz problemem projektowania interfejsu HCI / interfejsu polegającego na osadzeniu tej teorii w czymś grywalnym (tj. Zbudowaniu modelu teorii / znalezieniu homo (iso?) Morfizmu grafów ze zbioru stanów interfejsu użytkownika z przejściami do DAG „określającego grę”).
W powyższym hipotetycznym scenariuszu widzę co najmniej trzy rzeczy, które powinny być możliwe do uchwycenia w bibliotekach. Po pierwsze, potrzebne są narzędzia do przekształcania / wnioskowania na temat DAG lub ogólnie wykresów. Po drugie, biblioteka interfejsu użytkownika jest wystarczająco sprytna, aby pomóc w sprawdzeniu, czy nasza reprezentacja naszego wykresu jako grywalnej gry faktycznie modeluje wykres (a więc na przykład, przynajmniej częściowo / nieformalnie, udowodnienie, że gra nie ma stanów zablokowanych z powodu warunku ograniczenia) . Wreszcie można podać zbiór bibliotek wyższego poziomu do określania wykresu; takich jak biblioteka do wyrażania znaków i ich interakcji oraz generowania (części) wykresów w kategoriach takich.
Po co utrzymywać „środkową” teorię DAG, a nie tylko implementację niskiego poziomu z kilkoma bibliotekami pomocy na wierzchu? Odpowiedź to wszystkie typowe powody formalnej semantyki. Biorąc pod uwagę, że zdecydowaliśmy się na formalne podstawy, możemy zweryfikować pewne właściwości gry, umożliwiając uzasadnienie takich rzeczy, jak optymalizacje w bibliotece interfejsu niskiego poziomu (o ile model DAG możemy robić, co chcemy), bez konieczności martw się o nieporównywalność z opisem wysokiego poziomu (znaków / dialogu itp.), ponieważ opisy te same muszą opisywać takie struktury.
W żaden sposób nie sugeruję, że powyższe podejście działałoby konkretnie i nie chodzi o to, że DAG musi być tym, co faktycznie jest przechowywane w pamięci (raczej tworzy coś podobnego do formalizmu obliczeniowego, takiego jak rachunek lambda), ale mam nadzieję, że ilustruje to podejście, które mnie interesuje.
Krótko mówiąc, wydaje mi się, że alternatywnym tytułem mogłoby być: Jak Dijkstra pisałby gry komputerowe?