Czy jest jakiś silnik gry korzystający z funkcjonalnego języka programowania? [Zamknięte]

10

Czy jest jakiś silnik gry korzystający z funkcjonalnego języka programowania podobnego do Scheme, Common Lisp, Clojure lub JavaScript?

Próbowałem Unity3D, ale ich „JavaScript” nie jest tak naprawdę JavaScript, jest mocno napisany i nie działa.

functional

— MaiaVictor
źródło

2

Korzystam z ThreeJS, ale chociaż jest pełen niesamowitości, brak aktywnej społeczności i dokumentacja stanowią poważny problem.

— MaiaVictor,

5

Dlaczego chcesz programować w funkcjonalnym języku programowania? Jaki masz problem? Proszę być bardziej precyzyjnym. W tej chwili pytanie to jest zbyt ogólne, aby dać jedną poprawną odpowiedź, i jest skłonne do wygenerowania listy (wszystkie równie „poprawne”) odpowiedzi w następujący sposób: - A co z Clojure w połączeniu z dowolnym silnikiem gry Java? - A może przyjąć funkcjonalny styl programowania w języku, który sam w sobie nie jest funkcjonalny? (Przeczytaj Programowanie funkcjonalne w C ++ autorstwa Carmacka.) - itd.

— Eric

2

JavaScript w Unity3D jest tak samo funkcjonalny jak zwykły Javascript, wystarczy użyć typów C # 4.0, coś w stylu:var add : Func<int, int, int> = ...

— fableal

2

Zobacz często zadawane pytania dotyczące pytań „Której technologii użyć”. To pytanie, jak pokazują odpowiedzi, po prostu generuje listę. To nie jest konstruktywne, ponieważ nie ma jednej poprawnej odpowiedzi (innej niż „Tak, istnieje”). To nie jest miejsce do kompilowania list.

— MichaelHouse

2

Jest to rodzaj problemu „odpowiedniego narzędzia do właściwej pracy”. Programowanie funkcjonalne jest silnie skoncentrowane na minimalizowaniu i eliminowaniu, tam gdzie to możliwe, stanu zmiennego. Może to działać dobrze w przypadku niektórych klas aplikacji, ale jest całkowicie przeciwstawne do sposobu działania dowolnej gry.

— Mason Wheeler,

7

Jest LambdaCube napisany w języku Haskell (nie jest to dokładnie silnik gry, ale bardziej silnik grafiki).

— brzuch
źródło

2

To może Cię również zainteresować (komentator Tim Sweeney z Epic)

— tumdum

Ciekawy link istnieje ppt tutaj

— bobobobo

2

Zawsze możesz użyć f # lub iron python (tak, wiem, python nie działa) lub innego języka .netified z XNA na platformie .net.

http://fsharpgamedev.codeplex.com/ http://www.ironpython.info/index.php/XNA_Example_with_a_Bouncing_Sprite

edycja: Jeszcze jeden silnik, napisany w Lisp: http://code.google.com/p/blackthorn-engine/

— Grzegorz Sławecki
źródło

2

Nie mam odpowiedzi na pytanie w formie pisemnej, ale wierzę, że prawdopodobnie próbujesz zapytać „dlaczego nie ma bardziej funkcjonalnych silników gier”, zamiast szukać konkretnego do użycia. Jeśli to prawda, należy ponownie sformułować pytanie. Jeśli nie ... zignoruj mnie. :)

Podejście czysto funkcjonalne nie nadaje się do gier. Gry (i grafika, fizyka i sztuczna inteligencja) i przede wszystkim zmiany stanu. Prawidłowe funkcjonalne podejście do tych problemów polegałoby na obliczeniu całego nowego stanu raz na pętlę, co będzie miało bardzo poważny spadek wydajności w porównaniu z kodowaniem bardziej bezpośrednio od tego, jak działa rzeczywisty sprzęt.

Z tego powodu nie widać żadnych funkcjonalnych silników gier w produkcji. Jest to po prostu zły paradygmat programowania dla większości problemów, które silnik gry ma rozwiązać. Jest to zły paradygmat programowania dla większości problemów, które należy rozwiązać również w skryptach wyższego poziomu i kodzie logiki gry. Chociaż prawie na pewno możliwe jest stworzenie funkcjonalnego silnika gry, byłby on powolny, trudny i uciążliwy w użyciu, i nie służyłby żadnemu prawdziwemu celowi poza schludnym pokazem / zabawką do popisania się.

Nie oznacza to, że programowanie funkcjonalne nie ma gdzieś miejsca w grach. Używam bardzo funkcjonalnego stylu kodowania (w stosownych przypadkach) w C #, Unity JavaScript, a nawet C ++ 11. Niektóre bardzo specyficzne problemy najlepiej lub przynajmniej najłatwiej rozwiązać za pomocą funkcjonalnego stylu, a większość popularnych obecnie języków obsługuje tę formę programowania, aczkolwiek w bardziej uciążliwy sposób niż „prawdziwe” języki funkcjonalne. Zazwyczaj problemy rozwiązywane za pomocą podejść funkcjonalnych nie są zawarte w kodzie podstawowego silnika ani w kodzie działającym w samej grze. Kodowanie funkcjonalne może być bardzo korzystne w przypadku narzędzi i przetwarzania danych offline (na przykład modele pieczenia i inne zasoby). Można również argumentować, że programowanie GPU ma niejasną funkcjonalność w sposobie pisania algorytmów,

Oczywiście nadal najlepiej jest unikać podejść funkcjonalnych poza ściśle określonymi okolicznościami, ponieważ chcesz, aby te narzędzia offline działały tak szybko, jak to możliwe. Języki funkcjonalne wyróżniają się równoległością, co jest dobre w przypadku niektórych problemów, ale abstrakcje sprzętowe zwykle prowadzą do bardzo nieefektywnej wydajności jednowątkowej. (Języki takie jak LISP mają się tu dobrze, ponieważ nie są czysto funkcjonalne, a w rzeczywistości wspólny LISP jest wieloparadygmatowy). Absolutnym najgorszym aspektem silnika gry lub powiązanego zestawu narzędzi jest wąskie gardło w iteracji treści. Fantazyjny silnik z wieloma funkcjami, który zajmuje artystom lub projektantom godziny na zrobienie tego, co można zrobić w 5 minut (lub idealnie, niemal natychmiast) doprowadzi do niskiej jakości gier lub anulowania z powodu eskalacji budżetu.

— Sean Middleditch
źródło

1

Zobacz: Clean Game Library (Clean) oraz Nikki and the Robots (Haskell).

— Andres F.

1

Ta odpowiedź jest w większości błędna i wydaje się opierać na bardzo słabym zrozumieniu rzeczywistych języków funkcjonalnych.

— CA McCann

1

Czy masz jakieś faktyczne kontrapunkty?

— Sean Middleditch

4

... Ile masz doświadczenia w wysyłaniu gier o jakości przemysłowej w funkcjonalnych językach? Jeśli masz doświadczenie, udostępnij je. Wypowiadaj się wraz z wyjaśnieniami i uzasadnieniami, nie odwołując się do ekspertyzy lub autorytetu, ani też oskarżeń osobistych. Prawdopodobieństwo tego rodzaju oburzonych kłótni i osobistych sprzeczek jest właśnie powodem, dla którego to pytanie zostało zamknięte.

— Sean Middleditch

4

Wkładasz mi słowa do ust. Nie podam mojego poziomu doświadczenia, ponieważ twoja opinia na temat mojej wiedzy specjalistycznej jest całkowicie nieistotna dla tematu. Nie twierdz, że nie masz czasu na opisywanie faktów, mając czas na atakowanie poziomów umiejętności osobistych. Prawdopodobnie masz prawdziwe poprawki, ale musisz je podać. „Ten facet jest w błędzie” nie jest cenną odpowiedzią dla nikogo. Mogę tylko twierdzić, że się mylisz, a potem mamy niekończący się i bezcelowy cykl sprzeczek. Powiedz, dlaczego odpowiedź jest zła.

— Sean Middleditch,

0

Firma Naugthy Dog używała Listu w swoich silnikach do gier i nosiła nazwę Game Oriented Assembly Lisp.

Niektóre informacje można znaleźć tutaj: http://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

Niektóre przykłady kodu: http://web.archive.org/web/20070127022728/http://lists.midnightryder.com/pipermail/sweng-gamedev-midnightryder.com/2005-August/003804.html

Nie jest dostępny do użytku publicznego.

— bcsanches
źródło

Jeśli spojrzysz na opis Wikipedii, szybko okaże się, że GOAL nie był językiem funkcjonalnym, pomimo przodków LISP.

— Mason Wheeler,