Esiste un motore di gioco che utilizza un linguaggio di programmazione funzionale? [chiuso]

10

Esiste un motore di gioco che utilizza un linguaggio di programmazione funzionale simile a Scheme, Common Lisp, Clojure o JavaScript?

Ho provato Unity3D ma il loro "JavaScript" non è in realtà JavaScript, è fortemente tipizzato e non è funzionale.

functional

— MaiaVictor
fonte

2

Sto usando ThreeJS, ma, sebbene sia pieno di meraviglia, è la mancanza di una comunità attiva e la documentazione è un problema serio.

— MaiaVictor,

5

Perché vorresti programmare in un linguaggio di programmazione funzionale? Qual è il problema che stai affrontando? Sii più specifico. Allo stato attuale, questa domanda è troppo generica per fornire una risposta corretta ed è incline a generare un elenco di risposte (tutte ugualmente "corrette") come questa: - Che ne dici di Clojure combinato con qualsiasi motore di gioco Java? - Che ne dici di adottare uno stile di programmazione funzionale in un linguaggio che non è di per sé funzionale? (Leggi Programmazione funzionale in C ++ di Carmack.) - ecc.

— Eric,

2

Il Javascript di Unity3D è funzionale come il normale Javascript, devi solo usare i tipi C # 4.0, qualcosa del tipo:var add : Func<int, int, int> = ...

— fableal,

2

Consulta le domande frequenti sulle domande "Quale tecnologia utilizzare". Questa domanda, come mostrano le risposte, sta solo generando un elenco. Non è costruttivo poiché non esiste un'unica risposta corretta (tranne "Sì, c'è"). Questo non è il posto giusto per compilare elenchi.

— MichaelHouse

2

Questo è una specie di problema "strumento giusto per il lavoro giusto". La programmazione funzionale è fortemente focalizzata sulla minimizzazione e l'eliminazione, ove possibile, dello stato mutabile. Ciò può funzionare bene per alcune classi di applicazioni, ma è completamente antitetico al modo in cui funziona qualsiasi gioco.

— Mason Wheeler,

7

C'è LambdaCube che è scritto in Haskell (non è esattamente il motore di gioco ma più simile al motore grafico).

— tumdum
fonte

2

Questo potrebbe anche essere di interesse per voi (comentary generale di Tim Sweeney di Epic)

— tumdum

Link interessante, c'è un ppt qui

— bobobobo,

2

Puoi sempre usare f # o iron python (sì, lo so, python non funziona) o qualsiasi altro linguaggio .netified con XNA su piattaforma .net.

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

modifica: un altro motore, scritto in Lisp: http://code.google.com/p/blackthorn-engine/

— Grzegorz Sławecki
fonte

2

Non ho una risposta alla domanda scritta, ma credo che tu stia probabilmente cercando di chiedere "perché non ci sono motori di gioco più funzionali" piuttosto che cercarne uno specifico da usare. Se è corretto, dovresti riformulare la domanda. Altrimenti ... ignorami. :)

Un approccio funzionale puro non è adatto ai giochi. Giochi (e grafica, fisica e intelligenza artificiale) e fondamentalmente tutto sui cambiamenti di stato. L'approccio funzionale corretto a questi problemi sarebbe quello di calcolare un intero nuovo stato una volta per ciclo, il che avrà una severa penalità prestazionale rispetto alla codifica più diretta su come funziona l'hardware reale.

È per questo motivo che non si vedono motori di gioco in stile funzionale in produzione. È semplicemente il paradigma di programmazione sbagliato per la maggior parte dei problemi che un motore di gioco deve risolvere. È il paradigma di programmazione sbagliato per la maggior parte dei problemi che deve essere risolto anche negli script di livello superiore e nel codice della logica di gioco. Mentre è quasi certamente possibile realizzare un motore di gioco funzionale, sarebbe lento, difficile e ingombrante da usare e non servirebbe a nessun altro scopo se non quello di essere una demo / un giocattolo da mostrare.

Questo non vuol dire che la programmazione funzionale non abbia un posto nei giochi. Uso uno stile di codifica molto funzionale (se del caso) in C #, Unity JavaScript e persino C ++ 11. Alcuni problemi molto specifici sono meglio o almeno più facilmente risolti con uno stile funzionale e la maggior parte dei linguaggi popolari oggi supporta tale forma di programmazione, sebbene in modo più ingombrante rispetto ai linguaggi funzionali "reali". Di solito questi problemi risolti con approcci funzionali non sono nel codice del motore principale, né nel codice che gira nel gioco stesso. La codifica funzionale può essere molto utile per gli strumenti e l'elaborazione dei dati offline (modelli di cottura e altre risorse, ad esempio). È anche discutibile che la programmazione GPU sia vagamente funzionale nel modo in cui gli algoritmi sono scritti,

Ovviamente può essere comunque meglio evitare approcci funzionali al di fuori di circostanze molto specifiche poiché si desidera che questi strumenti offline siano il più veloci possibile. I linguaggi funzionali eccellono nel parallelismo, il che è positivo per alcuni problemi, ma le astrazioni dall'hardware tendono a portare a prestazioni single-thread molto inefficienti. (Lingue come LISP funzionano bene qui perché non sono puramente funzionali, e in effetti LISP comune è multi-paradigma.) La cosa peggiore in assoluto per un motore di gioco o un toolkit correlato è quella di essere un collo di bottiglia per l'iterazione dei contenuti. Un motore fantasioso con molte funzionalità che impiega ore ad artisti o designer di livello per fare ciò che si potrebbe fare in 5 minuti (o idealmente, quasi istantaneamente) porterà solo a giochi di bassa qualità o cancellazione a causa dell'escalation del budget.

— Sean Middleditch
fonte

1

Vedi: Clean Game Library (Clean) e Nikki and the Robots (Haskell).

— Andres F.

1

Questa risposta è per lo più sbagliata e sembra essere basata su una comprensione molto scarsa dei linguaggi funzionali attuali.

— CA McCann,

1

Hai dei punti contatori effettivi?

— Sean Middleditch,

4

... Quanta esperienza hai nei giochi di qualità del settore marittimo in linguaggi funzionali? Se hai esperienza, condividila. Fai dichiarazioni con spiegazioni e giustificazioni, non ricorrere a perizia o autorità o accuse personali. La probabilità di questo tipo di discussioni indignate e battibecchi personali è esattamente il motivo per cui questa domanda è stata chiusa.

— Sean Middleditch,

4

Mi stai mettendo parole in bocca. Non sto dichiarando il mio livello di esperienza perché la tua opinione sulla mia esperienza è assolutamente irrilevante per l'argomento. Non pretendere di non avere tempo per dichiarare fatti mentre si ha il tempo di attaccare i livelli di abilità personali. Probabilmente hai correzioni reali, ma devi dichiararle. "Quel ragazzo ha torto" non è un prezioso feedback di risposta per nessuno. Posso solo affermare che hai torto, e quindi abbiamo un ciclo infinito e inutile di litigi. Si prega di dire perché una risposta è sbagliata.

— Sean Middleditch,

0

La compagnia Naugthy Dog usava List sui suoi motori di gioco e si chiamava Game Oriented Assembly Lisp.

Alcune informazioni sono disponibili qui: http://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

Alcuni esempi di codice: http://web.archive.org/web/20070127022728/http://lists.midnightryder.com/pipermail/sweng-gamedev-midnightryder.com/2005-August/003804.html

Non è disponibile per l'uso pubblico.

— bcsanches
fonte

Se guardi la descrizione di Wikipedia, diventa subito chiaro che GOAL era a malapena un linguaggio funzionale, nonostante gli antenati di LISP.

— Mason Wheeler,