기능적 언어가 게임 작성에 가장 일반적으로 사용되는 것은 아니라는 것을 알고 있지만, 프로그래밍 환경에서 흥미로울 것 같은 많은 이점이 있습니다. 특히 병렬화의 용이성은 포커스가 점점 더 많은 프로세서로 이동함에 따라 매우 유용 할 수 있다고 생각합니다.

또한 .NET 제품군의 새 멤버 인 F #을 사용하면 XNA에서 직접 사용할 수 있습니다. 예를 들어 LISP, Haskell, Erlang 등과 달리 임계 값을 약간 낮출 수 있습니다.

기능 코드로 게임을 작성해 본 경험이 있다면, 긍정적 인면과 부정적인면은 무엇입니까? 무엇에 적합합니까?

편집 : 이것에 대한 좋은 대답이 있다고 결정하기가 어려워서 커뮤니티 위키 게시물로 더 적합 할 것입니다.

저는 현재 Haskell에서 게임을하고 있습니다. 나는 일반적으로 함수형 프로그래밍에 대해서는 말할 수 없지만 Haskell에 대해서는 구체적으로 말할 수 있습니다

좋은

이것들은 하스켈을 정말 돋보이게하는 멋진 것들입니다.

• 순도는 코드에 대한 추론이 훨씬 쉽다는 것을 의미합니다. 변수의 "현재"값에 대해 또는 주어진 함수를 사용하여 어떤 식 으로든 전역 상태와 충돌하는지 걱정할 필요가 없습니다. 또한 병렬 처리와 동시성이 훨씬 쉽게 작업 할 수 있음을 의미합니다 (많은 경우에는 사소한). 이것들은 게임 개발자에게 신의 선물이 될 수 있습니다.
• Haskell을 사용하면 자신이 만든 추상화를 사용하여 매우 높은 수준에서 쉽게 작성할 수 있습니다. Haskell의 특수 코드보다 매우 일반적인 코드를 작성하는 것이 더 쉬운 경우가 많으며, 개발 시간이 단축되고 코드 이해가 쉬워 지므로이 매니페스트의 이점 자체가 나타납니다. 인터페이스를 사용하는 것이 완전히 새로운 언어를 사용하는 것과 같다는 것을 알고있는 다른 언어보다 하스켈에서 더 사실입니다 (여전히 하스켈 생태계의 나머지 이점을 유지함). 대부분의 언어가 언어 기능을 호출하는 것으로 Haskell은 라이브러리를 호출하지만 강요되지 않습니다. psuedocode에서 게임에 대한 추론을 발견하면 간단한 인터페이스를 작성하여 실제 코드로 만들 수 있으며 일반적으로 그렇게 할 가치가 있습니다.
• 이것은 다른 답변과 충돌 할 수 있지만 Haskell은 내가 알고있는 다른 언어보다 명령 코드를 처리하는 것이 좋습니다. 순도의 제약 조건은 Haskell이 "평가"(표현 축소)와 "실행"(부작용 수행)의 개념을 분리한다는 것을 의미합니다. 소위 "제 국적"언어로 쉽게 비교할 수없는 부작용을 언제 어떻게 수행 할 것인지를 제어 할 수 있습니다. 이전에 순도에 대해 말한 것에도 불구하고 일부 C 바인딩은 여전히 ​​매우 중요합니다 (OpenGL, 당신을보고 있습니다). 따라서 명령형 코드에 대한 세밀한 제어는 매우 환영합니다. 가장 노련한 C 프로그래머조차도 익숙해지면 감사 할 것입니다.
• GHC는 매우 빠른 바이너리를 생성합니다. 그것들은 일반적인 C 컴파일러에서 생성 된 바이너리만큼 빠르지는 않지만, 규모가 크며, 해석 된 언어로 달성 할 수있는 것보다 훨씬 빠릅니다. 너무 느려서 파이썬과 같은 다른 고급 언어로 게임을 작성할 수 없더라도 Haskell에서 게임을 할 수있는 좋은 기회가 있습니다.
• Haskell에는 게임 관련 라이브러리가 많지 않지만 아래 "나쁜"에서 언급했듯이 Haskell 외부 함수 인터페이스는 내가 사용했던 것 중 가장 쉬운 방법입니다. Haskell에서 거의 독점적으로 작성하여 C에 바인딩 할 수 있습니다.

나쁜

이것들은 좋지는 않지만 너무 많은 노력 없이 해결할 수 있습니다 .

• 비 기능 언어를 다루는 데 익숙하다면 Haskell을 배우는 데 필요한 시간과 노력이 상당히 높아질 수 있습니다. 언어 자체는 그리 어렵지 않지만 일반적인 언어 확장과 방대한 양의 라이브러리를 고려할 때 (다른 언어의 언어 기능을 Haskell의 라이브러리라고 생각할 수있는 많은 것들이 있다는 것을 기억하십시오) 훨씬 불길 해 보입니다. 제 생각에는 그만한 가치가 있지만 다른 사람들은 동의하지 않을 수 있습니다.
• 어떤 사람들은 게으름에 대해 많이 불평합니다. 당신이하고있는 일을 안다면, 추적하기 어려운 공간 누출을 일으키지 않을 것입니다 (지금 몇 년 동안 공간 누출을 만들지 않았습니다). 초보자는 이것에 더 많은 어려움을 겪습니다. 이 사람들을 쓰러 뜨리고 이것이 문제가 아니라고 주장하는 것은 어리석은 일이지만, 경험으로 쉽게 해결되는 문제라고 주장 할 것입니다.
• Haskell에는 게임을 만들기위한 훌륭한 라이브러리가 많지 않으며, 많은 Haskeller가 게임을 작성하지 않기 때문에 리소스를 찾고이 문제에 도움을주기가 어렵습니다.

못난이

이것들은 극복하기 위해 상당한 노력을 기울여야 할 것들입니다.

• 리소스 집약적 인 게임을 작성하는 경우 GHC의 가비지 수집기가 꽤 어려울 수 있습니다. 세대를 초월한 세계 최고 수준의 GC이므로 가끔씩 몇 프레임을 떨어 뜨릴 수 있습니다. 일부 게임의 경우 문제가 없지만 다른 게임의 경우 큰 문제입니다. 나와 Haskell을 사용하는 다른 게임 개발자들은 GHC를 위해 구현 된 소프트-실시간 GC를보고 싶어하지만 아직까지는 아는 바가 없습니다. 현재, 나는이 문제를 해결하는 것에 대해 걱정하지 않고 (그리고 아직 프레임에서 떨어진 것을 보지 못했지만) 적어도 다른 팀은 기본 렌더링 루프를 C에 넣었습니다.

작년에 Haskell에서 상업용 게임 엔진을 개발하는 데 보냈으며 우리에게는 경험이 압도적으로 긍정적이었습니다. 우리의 게임 세계는 복잡하며, Haskell은 편집기 형식에서 게임 엔진 형식으로의 변환 과정을 쉽게 모델링 할 수있게했습니다. 나는 그 코드가 명령형 언어로 보일 것이라고 생각하는 것을 싫어합니다.

경우에 따라 공간 누출이 발생하고 약간의 문제가 발생했지만 일반적으로 비슷한 크기의 Java 프로젝트에서 교착 상태를 찾는 것과 비교할 때 소량의 문제가 발생했습니다. 그들은 고정 된 상태를 유지했다.

우리는 Yampa와 유사한 FRP를 사용하고 있으며, 관련 학습 곡선이 있지만, 일단 끝나면 경험은 매우 긍정적입니다. 라이브러리는 우리에게 문제가되지 않았습니다. 필요한 모든 것이 가능합니다. 가비지 수집 지연은 임베디드 플랫폼을위한 것이기 때문에 특별한 문제였습니다. 우리는 애니메이션을 관리하기 위해 C ++을 사용했습니다. 임베디드 플랫폼 (= 느린 프로세서) 인 경우에도 성능이 문제였습니다. 우리는 일부 C를 수행했으며 가속과 같은 새로운 Haskell 기술도보고 있습니다. C ++ 애니메이터는 초기에 디자인 결정이었으며 코드가 너무 느린 곳은 매우 작은 영역입니다. 장기적으로, 우리는 모든 C를 하스켈로 변환하려고합니다.

Haskell은 어려운 작업을 쉽게 해주 었으며 방금 언급 한 모든 어려움은 깨끗하고 유지 보수가 가능하며 거의 깨지지 않는 대량의 복잡한 코드에 비해 작습니다. 게임 개발에서 병렬화는 곧 문제가 될 것이며,이를 처리 할 수있는 좋은 위치에 있습니다. 제가 말한 것 중 일부는 소규모 프로젝트에는 적용되지 않을 수 있습니다. 우리가 장기적으로이 프로젝트를 진행하고 있기 때문에 학습 곡선, 라이브러리 지원 등과 같은 시작 비용은 문제가되지 않습니다.

Dave는 Haskell이 그의 두 가지 문제를 모두 해결했음을 지적해야하지만 몇 가지 훌륭한 점을 언급합니다. Stateless는 State monad를 사용하여 우회 할 수 있으며 (편집 : 실제로는 아닙니다-자세한 내용은 아래 참조) IO monad를 사용하여 시퀀싱을 처리 할 수 ​​있습니다 (EDIT : 또는 다른 모나드, 그 문제에 대해서는 ...) .

당신이 겪게 될 도전들 (그리고 게임 프로그래밍과 Haskell을 배우려고 노력했던 것)은이 라인들에 더 가깝습니다. (이것은 아직 다른 FP 언어에 깊이 들어 가지 않았기 때문에 모든 Haskell에만 해당됩니다.)

• FP 학습 곡선 : FP는 반복 프로그래밍에서 완전히 사고 방식을 전환해야합니다. 루프보다는 맵과 폴드로 생각하는 법을 배우려면 익숙하지 않은 경우 정신 운동이 필요합니다.
• Mathy 학습 곡선 : Haskell은 디자이너의 수학적 정교함으로 인해 축복과 저주를 받았습니다. FP의 기본 사항을 배우고 나면 모나드, 형태, 화살표 및 기타 여러 고려 사항에 빠지기 때문입니다. 그 자체로 매우 추상적입니다.
• 모나드 (Monads) : 이 강아지들은 특별히 당신의 마음을 감싸기 어렵지 않습니다. 특히 에릭 레이몬드 (Eric Raymond)의 말에 따르면, "함수 구성을 함수 호출 시퀀싱을 강요하는 방법으로 바꾸는 핵"이라는 말 을 받아들이면 더욱 그렇습니다 . 불행히도 (이것이 하스켈이 인기를 얻음에 따라 나아지고 있지만), 모나드에 대한 많은 설명은 대부분의 프로그래머의 머리를 넘어서거나 ( "그들은 endofunctors 범주의 monoid입니다!") 또는 완전히 도움이되지 않는 유추입니다 (예 : , 브렌트 Yorgey의 참혹 정확한 예 " 모나드는 부리처럼 !"당신은 그가 농담 같아? 아무도 튜토리얼에서 그런 바보 같은 비유로 올 수 없다고? 다시 생각해 .)
• 생태계 : 만약 당신이 도로의 다른 모든 충돌을 극복했다면, 여전히 실험적인 언어로 작업하는 실제적인 현실에 대해 뺨을 맞이할 것입니다. 당신이 여기 도착하면 신이 당신을 도와주세요. 내가 스칼라, 또는 F #, 또는 적어도이 다른 언어에 집착하는 진지하게 시작했던 곳 여기 몇 가지 다른 도서관과의 상호 운용성 보장. 옛날 옛적에, Haskell이 Windows에서 OpenGL 라이브러리를 링크하고로드하도록했습니다. 기분이 좋았습니다. 그런 다음 OpenGL 바인딩이 다시 릴리스되고 내가 한 모든 것을 깨뜨 렸습니다. 그것은 하스켈 랜드의 삶입니다. 솔직히, 그것은 고통이 될 수 있습니다. 불릿 엔진 용 래퍼를 원하십니까? 그것은 Hackage에있어 -로 밴던작년 11 월부터 당신은 Ogre3d를 좋아합니까? 해커 지는 라이브러리의 하위 집합에만 바인딩됩니다 . 결론은 게임 개발을 위해 구타를 벗어난 언어를 고수한다면 방금 무리를 따라 C ++에 집착했을 때보 다 기본 배관 작업에 더 많은 시간을 할애한다는 것입니다.

이것의 단점은 상황이 빠르게 개선되고 있다는 것입니다. 그리고 그것은 실제로 당신이 경험에서 원하는 것에 달려 있습니다. 당신은 게임을 구축하고 명성과 재산을 찾기 위해 귀하의 웹 사이트에 넣어? C ++ 또는 Python을 사용하십시오. 그러나 프로세스를 혁신해야하는 새로운 것을 배우고 싶다면 기능적 언어를 사용해보십시오. 배우는 동안 많은 인내심을 가지십시오.

Antti Salonen은 Haskell 게임 프로그래밍 에 대한 그의 또 다른 일 을 자세히 설명하는 흥미로운 블로그를 가지고 있습니다. 읽을 가치가 있습니다.

편집 (1 년 후) : 이제 State 모나드를 더 많이 연구 했으므로 특정 기능 외부에서 지속되도록 의도 된 상태에 대해서는 특히 좋은 해결책이 아니라는 것을 알고 있습니다. 상태 비 저장에 대한 실제 솔루션은 스레드 안전을 위해 IOVar, ST, MVar의 Haskell 또는 Arrows와 FRP를 사용하여 개발자에게 숨겨져있는 내부 상태를 관리하는 Yampa와 같은 방법을 통해 찾을 수 있습니다. (모나드를 이해하면 처음 3 개는 특별히 어렵지는 않지만이 목록은 난이도 순서입니다.)

목표 카멜!

기능 언어를 사용하면 대부분의 소프트웨어 개발에서 큰 이점이 될 수 있습니다. 대부분 개발 시간이 상당히 단축 되었기 때문입니다. 기능적인 언어로 서버 백엔드를 게임이나 클라이언트의 AI 및 논리 계층에 쓸 가능성이 크다는 것을 알 수 있습니다. 그리고 누구나 알고 있듯이 LISP는 NPC 스크립팅에 사용되었습니다.

기능적인 언어로 게임의 프론트 엔드를 작성하려고한다면 분명히 하이브리드 언어 인 Objective Caml을 선택해야 합니다. ML 자손이며 반복적이고 기능적인 스타일을 혼합 할 수 있으며 상태 저장 객체와 객관적인 시스템을 갖추고 있습니다. (Caml은 F #이 모델링 된 언어입니다.)

OpenGL 바인딩은 완벽하게 작동하는 것으로 보이며 사람들은 OCaml에서 오랫동안 게임을 해왔습니다. 언어는 컴파일 될 수 있고 잠재적으로 매우 빠릅니다 (오래 전에 일부 벤치 마크에서 C를 능가했습니다. 지금 상황이 아닙니다).

수많은 도서관도 있습니다. 컴퓨터 과학부터 모든 종류의 라이브러리에 이르기까지 모든 것이 있습니다.

- 아니 정말 아무것도 대답,하지만 기능적인 언어 게임 프로그래밍에 대한 논의 기분이 기능 반응성 프로그래밍 (FRP)의 언급없이 불완전 http://www.haskell.org/frp/ - 그리고 가장 일반적인 구현 ( 내 생각), YAMPA - http://www.haskell.org/yampa/을 .

이점은 Clean Game Library (http://cleangl.sourceforge.net/)를 확인하고 플랫 포머 게임을 확인하십시오. 구문에 대해 이해하고 나면 (시도해보십시오) 구성의 깎아 지른 우아함과 소스가 표현하는 개념에 얼마나 가깝게 매핑되는지 확인할 수 있습니다. 추가 보너스로, 상태의 추상화 및 상태를 명시 적으로 전달해야 할 필요성으로 인해 코드가 훨씬 더 친숙해집니다.

반면에 주요 패러다임 전환이 필요합니다. 당신이 그것에 대해 생각하지 않고했던 일이 갑자기 더 이상 존재하지 않으며 단순히 잘못된 패턴으로 생각하고 있기 때문에 그것을 해결하는 방법을 혼란스럽게 할 것입니다.

내 관점에서 볼 때 가장 큰 과제는 다음과 같습니다.

• 기능적 언어의 상태 비 저장 : 게임의 아이디어는 각 엔티티가 상태를 가지며이 상태가 프레임마다 수정된다는 것입니다. 일부 언어 (예 : plt 체계에 "!"가있는 함수)에서 해당 동작을 모방하는 기법이 있지만 부 자연스럽게 느껴집니다.
• 실행 순서 : 게임에서 일부 코드 부분은 실행하기 전에 완료해야하는 다른 코드 부분에 의존합니다. 함수형 언어는 일반적으로 함수의 인수 실행 순서를 보장하지 않습니다. 이 동작을 모방하는 방법이 있습니다 (예 : (begin...plt 체계에서 " ").

이 목록을 자유롭게 확장하십시오.

C / C ++로 코드를 작성하고 스크립팅에 Embedded Common Lisp와 같은 내장 언어를 사용할 수 있습니다. 다른 플랫폼에서 컴파일하는 것은 어려울 수 있습니다. 자신 만의 스크립팅 언어를 작성하는 방법을 배우기 위해 Lisp In Small Pieces를 볼 수 있습니다. 시간이 있다면 정말 어렵지 않습니다.

나는 LISP로 간단한 게임을 만들었고 재미 있었지만 추천 할만한 것은 아니었다. 함수형 프로그래밍은 최종 결과에 관한 것입니다. 따라서 데이터를 처리하고 결정을 내리는 데 매우 편리하지만 기본 제어 루프처럼 간단한 깨끗한 코드를 작성하는 것이 어려워졌습니다.

F #을 배우지 않았으므로 작업하기가 훨씬 쉬울 수 있습니다.

긍정적이 될 것이다 성능 과 휴대 성 네거티브가 될 것이다 복잡성을 관리 , 게임 오늘 심각하게 복잡하고 기능성 프로그래밍을 구현하기 어렵다 객체 지향 방법론 또는 일반 프로그래밍과 같은 복잡한 더 잘 관리 할 수있는 도구 나 프로그래밍 언어가 필요 언어.