Godot: 스크립팅 언어로서의 C#

내 의견으로는 GDscript에 더 많은 기능을 추가하면 스크립팅에 접근하는 더 좋은 방법이 될 것입니다.

저에게 다른 게임 엔진보다 Godot를 선택하는 주된 이유는 단순화된 스크립팅 방식입니다. Godot는 새로운 프로그래밍 언어를 배우겠다고 제안하지 않습니다. Godot와 그 스크립팅 언어를 게임 개발을 위한 통합 도구로 배울 수 있는 제안입니다. 이것은 신규 사용자에게 C++ 또는 스크립팅을 위한 다른 프로그래밍 언어를 배우도록 제공하는 것보다 덜 위협적인 접근 방식입니다.

이 문제를 열어 주셔서 감사합니다. 이것은 합리적으로 최선의 선택과 대다수가 요구하는 것 사이에 큰 차이가 있는 주제라고 생각합니다.

하나 이상의 엔진이 존재하는 가장 중요한 이유는 범용 작업의 성능이나 인터페이스의 접근성과 같은 1차원적 요소 외에도 특정 상황에 대한 성능과 같은 다차원적 요소가 있기 때문입니다. 3d 게임에 최적화된 것과 2d 게임에 최적화된 것) 또는 특정 사용자 그룹에 대한 사용성(초보자에게 친숙한 인터페이스는 일반적으로 고급 기능을 숨겨야 함).
따라서 다른 엔진들 사이에서 자리를 찾기 위해 엔진은 "철학"을 선택해야 합니다.

이제 스크립팅 언어는 엔진의 필수적인 부분이므로 언어의 철학은 엔진의 철학과 맞아야 하거나 적어도 모순되어서는 안 됩니다.

그렇다면 Godot의 철학은 무엇입니까? 몇 가지 사실을 살펴보겠습니다.

• Godot에 비해 다른 모든 주요 엔진은 부풀려 있습니다.
  Godot의 다운로드는 20MB보다 작으며 전체 "설치"는 50MB 미만의 실행 파일입니다. 반면 Lumberyard의 초기 다운로드 크기는 약 5.5GB이며 현재 내 설치 폴더는 15.3GB입니다. 그 주된 이유는 의존성에 관한 Amazon의 철학입니다. 그 초기 다운로드에는 42개의 종속성으로 구성된 10.5GB의 빌드 이미지가 포함되어 있으며, AWS SDK가 그런 측면에서 다르지 않다는 것을 알기 전에 Amazon 웹 서비스를 사용해 본 적이 있다면 필요성이나 능력의 문제가 아니라 문제입니다. 선택의. 예를 들어 Lumberyard에는 boost 및 Lua가 포함되어 있지만 Godot에는 가장 중요한 STL 컨테이너의 자체 버전이 포함되어 있으며 크기를 줄이고 종속성을 제거하며 코드를 훨씬 더 읽기 쉽고 액세스 가능하게 만드는 lua 대신 GDScript를 사용합니다.
• Godot의 소스 코드는 매우 쉽게 접근할 수 있습니다.
  그것은 빌드 언어로 파이썬을 사용하는 빌드 시스템(SCons)의 선택으로 시작됩니다. 대부분의 다른 프로젝트는 독점 빌드 언어가 있는 기존 빌드 시스템을 사용하거나 자체 독점 빌드 시스템을 작성합니다. 둘 다 빌드 코드의 가독성에 부정적인 영향을 미칩니다.
  소스 코드 자체도 그런 면에서 평균 이상입니다. Godot에 대한 첫 풀 리퀘스트의 코드를 작성하는 데 걸린 것처럼 C++로 단일 Unreal Blueprint 노드를 작성하는 방법을 찾는 데도 거의 같은 시간이 걸렸습니다. Unreal의 C++ 코드를 읽을 수 없다는 것은 아닙니다. 더 많은 매크로를 사용하고 사용자가 Godot보다 Unreal의 기본 프로젝트 코드를 더 많이 이해해야 하기 때문에 Godot만큼 깨끗하지 않습니다.
• Godot는 KISS와 OO 원칙을 장려합니다.
  이를 설명하기 위해 Unity의 몇 가지 간단한 개체를 살펴보겠습니다. Unity에서 마주하는 첫 번째 개념은 컴포넌트가 연결된 게임 오브젝트의 개념입니다. "C++ for Game Developers"에서 Michael J. Dickheiser의 공식 "Containment vs Inheritance"를 선호하는 "상속보다 구성"은 성공적인 패턴입니다. 제공하는 유연성 때문입니다. 하지만 그 유연성에는 대가가 따릅니다. 게임의 모든 것이 게임 오브젝트라면 플레이어가 없기 때문에 "플레이어"에 대한 참조를 실제로 얻을 수 없습니다. 플레이어).
  Unity 개발자는 동일한 문제를 발견했습니다. 때로는 Button 구성 요소가 있는 GameObject가 아닌 Button을 만들고 싶을 때가 있습니다. 그래서 그들이 한 일은 다음과 같습니다. 그들은 Button 구성 요소가 연결된 게임 오브젝트를 실제로 생성하는 편집기 인터페이스를 통해 "버튼"을 생성할 수 있도록 했습니다. 그 외에도 모든 구성 요소를 통해 GameObject의 가장 중요한 구성원을 라우팅하므로 이제 GameObject에 대한 참조를 사용하는 것처럼 Button에 대한 참조를 사용할 수 있습니다. Button의 위치를 ​​물어볼 수 있고 해당 구성 요소 목록을 요청할 수 있습니다. Button이 실제로 구성 요소이고 연결된 개체가 아닌 경우에도 마찬가지입니다.
  이제 우리는 게임 세계를 설명하는 가장 인기 있는 두 가지 방법인 구성 기반 및 일반 개체를 혼합했습니다. 그러나 초보자의 프로젝트(및 일부 고급 프로젝트)를 살펴보면 Unity가 게임 세계를 해석하는 세 번째 방법인 절차적 프로그래밍도 용이하게 한다는 것을 알 수 있습니다.
  Unity에서 모든 개체는 항상 "장면"의 일부입니다. Godot에서와 달리 이 용어는 게임의 최상위 부분을 설명합니다(면책 조항: 이제 Unity에는 장면 상단에 있는 SceneManager가 있지만 제 요점은 여전히 ​​유효합니다). 플레이어의 현재 장면을 검색하고 상호 작용합니다. 이것이 절차적 프로그래밍의 핵심 아이디어입니다. 소유권을 고려하지 않고 환경의 상태를 변경하는 일련의 명령이 있습니다. 물론 기술적으로 여전히 객체 지향 프로그래밍이지만 모든 객체가 동일한 장면의 일부로 예상할 수 있으므로 전역 코드처럼 동작하는 코드를 작성할 수 있습니다. 예를 들어 개체를 인스턴스화하려는 경우 "Instantiate(templateObject)"를 호출하기만 하면 템플릿 개체의 복사본이 인스턴스화되어 장면에 추가됩니다. 모든 것이 현재 일부인 하나의 장면이 항상 있기 때문에 개체를 추가할 장면을 묻지 않아도 됩니다.
  따라서 Unity는 구성, 객체 지향 사고 및 절차적 프로그래밍의 혼합을 장려합니다.

반면 Godot는 예를 들어 게임의 모든 단일 개체가 자체 장면으로 구축될 수 있으므로 개체 지향적인 사고를 촉진합니다. 이러한 씬은 스스로 시작하여 테스트하고 스스로 변경하는 등의 작업을 수행할 수 있습니다. 따라서 환경에 액세스할 필요가 없는 방식으로 해당 씬을 빌드해야 합니다. 예를 들어 적이 플레이어와 상호 작용하기를 원하는 경우 신호를 사용하여 상호 작용이 요청되었음을 기본 장면에 알리거나 단순히 장면에서 적에게 플레이어에 대한 참조를 제공하도록 요구하는 것이 훨씬 더 실현 가능합니다. 여전히 플레이어의 게임 장면을 검색할 수 있지만 그렇게 하면 적의 장면이 자체적으로 실행될 수 없으므로 디자인이 도구에도 적합하지 않습니다.

그렇다면 이것이 스크립팅 언어 선택과 관련하여 어떤 차이를 만들까요?
C#은 Unity가 엔진에 대한 것과 같은 언어입니다. C#의 철학은 항상 어떤 기능이 있으면 언어에 추가되는 것이 좋습니다. 각 버전에 추가된 기능 목록을 확인하세요 .
이제 기능이 있는 것이 나쁜 것이 아니라고 주장할 수 있습니다. 그렇죠? 굳이 사용하지 않으셔도 되며, 마음에 들지 않으시면 그냥 놔두시면 됩니다. 불행히도 그것은 언어에 해당되지 않습니다. 오늘날 인터넷의 중요성으로 인해 언어는 더 이상 도구가 아니라 문화입니다. 조만간 구글에 도움을 요청해야 하고, 다른 사람들이 만든 모듈이나 개체를 사용해야 하고, 커뮤니티에서 구축한 새로운 기능을 엔진에 사용하게 되며, 조만간 의도하지 않은 언어 기능을 사용해야 하는 상황이 생길 것입니다. 쓰다.
또한 팀에서 일하고 있다면 일반적인 코딩 스타일을 장려하고 동일한 코드를 작성하는 수십 가지 방법을 제공하지 않는 언어를 사용하는 방법을 배우게 될 것입니다.

이제 더 적은 기능을 가진 언어가 더 많은 기능을 가진 언어보다 항상 더 낫다고 말하는 것인지 궁금할 것입니다. 물론 그렇지 않습니다. Java가 문제를 해결한 방법을 비교해 보겠습니다.
C#을 사용하면 관리되지 않는 코드를 작성할 수 있습니다. 적절한 키워드를 사용하기만 하면 동일한 파일에서 바로 사용할 수 있습니다. 또한 SQL 코드처럼 읽고 기능 코드처럼 동작하는 LINQ를 사용하여 기능 코드를 작성할 수 있습니다. 하나의 파일이 무엇인지 완전히 이해하려면 프로그래밍 패러다임에 대해 많이 알아야 할 수도 있습니다.
Java를 작성하는 경우 함수형 프로그래밍도 사용할 수 있습니다. 별도의 파일에 작성하고 다른 컴파일러를 사용하고 "프로그래밍 Clojure"라고 부르기만 하면 됩니다. 객체 지향 프로그래밍과 기능 프로그래밍을 결합하는 것을 선호한다면 "프로그래밍 스칼라"라고 부를 수 있습니다. 중요한 부분은 다른 JVM 언어의 코드와 쉽게 상호 작용할 수 있는 JVM용 코드를 계속 작성하고 있다는 것입니다.
.NET 언어에는 동일한 기능이 있으며 C# 철학에서는 사용되지 않습니다. 그들은 C#에서 한두 가지 프로그래밍 패러다임을 고수하고 새로운 패러다임을 추가하기 위해 새로운 언어를 만들기로 결정할 수도 있었지만 대신 "하나의 언어로 모든 것을 정복"하기로 결정했습니다. 그런 언어. 그 철학과 프로그래머로서의 선택을 알고 있어야 합니다.

간단히 말해서: 우리가 가진 모든 언어 중에서 C#이 Godot에 가장 적합하다고 생각합니다. Unity에 자연스럽게 적합하지만 이러한 모든 옵션이 있는 경우 다른 모든 부분에서 깨끗한 OO 원칙과 KISS 프로그래밍을 촉진하는 엔진에서 패러다임의 혼합 및 일치를 촉진하는 언어를 선택하는 이유는 무엇입니까?

따라서 C#이 Godot에 좋은 추가 기능이 될 것이라고 생각하신다면 저는 이에 동의하지 않습니다. 저는 단지 훨씬 더 나은 대안이 존재한다는 것을 말하려는 것입니다. 그것은 먼저 평가되어야 하고 C#이 구현되면 즉시 잊혀질 것입니다.

@허비스트

내 의견으로는 GDscript에 더 많은 기능을 추가하면 스크립팅에 접근하는 더 좋은 방법이 될 것입니다.

그것은 확실히 일어날 수 있습니다, 나는 그것이 다른 제안들과 양립할 수 없다고 생각하지 않습니다.

저에게 다른 게임 엔진보다 Godot를 선택하는 주된 이유는 단순화된 스크립팅 방식입니다. Godot는 새로운 프로그래밍 언어를 배우겠다고 제안하지 않습니다. Godot와 그 스크립팅 언어를 게임 개발을 위한 통합 도구로 배울 수 있는 제안입니다. 이것은 신규 사용자에게 C++ 또는 스크립팅을 위한 다른 프로그래밍 언어를 배우도록 제공하는 것보다 덜 위협적인 접근 방식입니다.

그러나 Godot는 이미 C++에서 사용할 수 있으므로 C++로 코딩하는 것이 원하는 사람들에게 더 쉬워질 것이라는 점을 제외하고는 실제로 변경되는 것은 없습니다(GDScript가 유지됨). 워크플로).

@Warlaan 좋은 분석입니다. 내 게시물을 읽으셨다면 저도 C#이 Godot에 좋은 선택이라는 데 동의하지 않습니다. 그래서 GDScript가 대부분의 사용자에게 기본 언어로 남아 있는 상태에서 스크립팅 언어로 사용할 수 있도록 이미 존재하는 C++ 기능을 확장하자고 제안한 것입니다.

사용자는 GDScript로 많은 것을 작성할 수 있어야 하지만, 큰 게임이 GDScript로 작성될 것이라고 생각하는 것은 무리입니다. 제 생각에는 GDScript 성능을 제외하고 Godot가 대규모 게임에 적합하지 못하게 막는 것은 없습니다. 엔진이 매우 잘 설계되었고 이미 꽤 좋은 성능을 가지고 있기 때문입니다(그리고 Vulkan은 아마도 더 좋게 만들 것입니다).

제 생각에 성능은 대부분의 Godot 사용자에게 어필하지 않지만 더 많은 전문가를 Godot에 데려올 수 있습니다. 이는 더 많은 기여를 통해 모두에게 더 나은 Godot를 의미합니다.

@paper-pauper 같은 편인줄 알았습니다. 내가 "C#이 좋은 추가 기능이 될 것이라고 생각한다면"이라고 썼을 때 나는 개인적으로 당신이 아니라 "익명의 독자인 당신"을 말하고 있었습니다. ;-)
그리고 예, 모든 새로운 스크립팅 언어는 GDScript의 관심을 끌 것입니다. 커뮤니티에서 둘 이상의 언어를 처리할 것인지 의심스럽습니다. 조만간 일부 기능을 사용할 수 없거나 둘 중 하나에서 중단될 수 있으며 심지어 언어 중 하나가 삭제되는 시점까지 갈 수도 있습니다.

또한 여기서 유일한 실제 문제는 C++의 컴파일 시간과 GDScript의 성능이라는 데 동의합니다.
사람들이 이미 C#을 알고 있다는 주장은 완전히 잘못된 것입니다. 저는 약 4년 동안 C#으로 전문적으로 일해 왔으며(주로 C++ 및 SQL로 작업) 그 시간에 배운 한 가지는 제가 그 언어를 정말로 안다고 말할 수 없을 것이라는 것입니다. 결국 C# 6과 7에 대한 제안으로 기능의 수는 여전히 증가하고 있습니다.
따라서 "C#을 안다"는 것에 대해 이야기할 때 실제로 언급할 수 있는 것은 최악의 초보자라도 며칠 만에 다시 배울 수 있는 가장 기본적인 구문을 아는 것입니다. 저는 최근에 이전에 Unity를 독점적으로 사용했던 게임 디자이너 클래스에게 다양한 게임 엔진에 대한 강의를 열었습니다. 그들 중 누구도 GDScript의 구문에 대해 나쁘게 언급하지 않았지만 실제로 프로그래밍을 포기했던 몇몇 사람들은 이제 다시 동기 부여를 받았습니다.

예, GDScript의 속도를 높이고 C++를 컴파일하고 사용하는 데 덜 번거롭게 만드는 솔루션도 제가 가장 좋아하는 것입니다.

C#을 "아는" 많은 사람들은 C#을 Java와 다르게 만드는 많은 기능을 사용하지 않습니다. 서브클래스와 크게 다르지 않은 수많은 Unity 스크립트를 살펴보십시오.

이러한 이유만으로도 저는 C#이 제공할 실질적인 이점에 대해 매우 회의적입니다. 그것들은 게임 개발이 아니라 많은 상황에서 훌륭합니다. 게다가 C++1x는 오버헤드 없이 이미 많은 것들을 제공합니다(유형 추론, 반복자 및 일부 기본 기능 도구 포함).

또한 CLR(또는 JVM)이 가져온 오버헤드로 인해 Godot가 _나쁜_ 성능을 발휘하도록 할 수 있습니다. JVM의 가비지 수집기를 사용하는 데 몇 가지 이점이 있음을 알 수 있습니다(Godot의 메모리 관리에 대해 더 알고 있는 사람이 있습니까?)?

나는 GDScript 때문에 Godot를 사용하지 않는 사람들에 대한 포럼을 읽었습니다. 내 생각에 그것은 긴밀한 생각이라고 생각합니다. 왜냐하면 오버헤드가 없고 크로스 플랫폼이 없는 솔루션을 제안하여 다른 티켓 #3943에서 다루려고 했던 라이브러리 선택이 좋지 않다는 사실을 제외하고는 아무 문제가 없기 때문입니다. 지원하다.

LLVM을 통해 C++ JIT를 구현하지 않고도 네이티브 코드에서 실행되고 Godot의 소스를 다룰 필요가 없는 솔루션이 있습니다: 동적 연결.

첫 번째는 Godot를 처음부터 다시 컴파일할 필요 없이 네이티브 코드를 허용합니다: 그냥 .so 파일로 컴파일한 다음 로드 경로에 추가한 다음 오버헤드 없이 GDScript에서 사용합니다(모든 함수 호출이기 때문에).

이것은 (libdl을 통해?) 수행하기가 매우 쉬워야 하지만 내가 이해하는 한 플랫폼 간 문제로 인해 수행되지 않았습니다.

또한 ENIGMA가 해당 언어로 수행하는 것처럼 GDScript 를 C++로 컴파일하는 아이디어가 있습니다. 이것은 쉽지는 않지만 분명히 최고의 성능을 제공합니다.

아무도 Godot의 메모리 관리에 대해 더 많이 알고 있습니까?

문서 에서 :

클래스가 Reference에서 상속하는 경우 더 이상 사용하지 않을 때 인스턴스가 해제됩니다. 가비지 수집기는 존재하지 않으며 단순한 참조 카운팅만 있습니다. 기본적으로 상속을 정의하지 않는 모든 클래스는 참조를 확장합니다. 이것이 원하지 않는 경우 클래스는 Object를 수동으로 상속해야 하고 instance.free()를 호출해야 합니다. 해제할 수 없는 참조 주기를 방지하기 위해 약한 참조를 생성하기 위한 weakref 함수가 제공됩니다.

참고로...

GDscript의 주요 장점은 Reduz와 다른 개발자들이 완전히 통제하는 언어라는 점입니다. Godot 개발자를 위해 작동하는 방식은 외부 팀에 의존하지 않고 고유한 방식으로 개발될 수 있습니다. 엔진의 디자인과 사용자가 요구하는 것을 가지고 있습니다.

또 다른 사실은 GDscript가 현재 실제 고성능 언어는 아니지만 단순성과 동적 타이핑 특성을 유지하면서 성능을 크게 향상시킬 수 있는 영역이 많이 있을 수 있다는 것입니다.

그리고 GDscript는 컴파일 지식이 전혀 필요하지 않으며 Godot의 내장 편집기 외에는 어떤 것도 필요하지 않습니다.

질문입니다. GDscript 인터프리터는 내부적으로 어떻게 작동합니까? 이전 기본 언어와 같이 런타임에 각 줄을 구문 분석하거나 전체 스크립트를 바이트 코드 테이블로 변환한 다음 바이트 코드를 실행합니까?

@RebelliousX

https://github.com/godotengine/godot/blob/master/modules/gdscript/gd_compiler.cpp
https://github.com/godotengine/godot/blob/master/modules/gdscript/gd_parser.cpp

더 이상 BASIC처럼 작동하는 진지한 언어는 없다고 생각합니다! :)

안녕!
GDScript의 역사는 다음과 같습니다.
////////////////////////////
역사
처음에 Godot는 여러 스크립팅 언어를 지원하도록 설계되었습니다(이 기능은 오늘날에도 여전히 존재합니다). 그러나 현재는 GDScript만 사용하고 있습니다. 여기에는 약간의 역사가 있습니다.

초기에 엔진은 Lua 스크립팅 언어를 사용했습니다. Lua는 빠르지만 (폴백을 사용하여) 객체 지향 시스템에 바인딩을 만드는 것은 복잡하고 느리며 엄청난 양의 코드가 필요했습니다. Python으로 몇 가지 실험을 한 후에도 포함하기가 어려웠습니다.

출시된 게임에 마지막으로 사용된 타사 스크립팅 언어는 Squirrel이었지만 역시 삭제되었습니다. 그 시점에서 Godot가 내장 스크립팅 언어를 사용하면 다음과 같은 장벽이 충족되어 더 최적으로 작동한다는 것이 분명해졌습니다.

• Godot는 노드에 스크립트를 삽입합니다. 대부분의 언어는 이를 염두에 두고 설계되지 않았습니다.
• Godot는 2D 및 3D 수학을 위해 여러 내장 데이터 유형을 사용합니다. 스크립트 언어는 이를 제공하지 않으며 바인딩하는 것은 비효율적입니다.
• Godot는 네트나 디스크에서 데이터를 들어올리고 초기화하기 위해 스레드를 많이 사용합니다. 공용 언어를 위한 스크립트 인터프리터는 이에 친숙하지 않습니다.
• Godot는 이미 리소스에 대한 메모리 관리 모델을 가지고 있으며, 대부분의 스크립트 언어는 자체적으로 제공하므로 중복 노력과 버그가 발생했습니다.
• 바인딩 코드는 항상 지저분하고 여러 실패 지점, 예기치 않은 버그 및 일반적인 유지 관리 불가능을 초래합니다.

마지막으로 GDScript는 맞춤형 솔루션으로 작성되었습니다. 이를 위한 언어와 인터프리터는 결국 Lua와 Squirrel에 대한 바인딩 코드 자체보다 작았고 기능적으로도 동등했습니다. 시간이 지남에 따라 내장 언어가 있다는 것이 큰 이점으로 입증되었습니다.
//////////////////////////

제 생각에는 C++가 최고일 수 있습니다. 다음과 같은 몇 가지 솔루션이 있습니다.
https://github.com/RuntimeCompiledCPlusPlus/RuntimeCompiledCPlusPlus
Angel 스크립트도 일반적으로 컴파일된 런타임과 같을 수 있습니다.
스크립팅에서 저는 항상 게임과 과학 시뮬레이션을 혼합한 솔루션을 사랑하기 때문에 파이썬을 사랑합니다(파이썬에는 많은 과학 라이브러리가 있습니다). 그래서 나는 불평한다! Godot에 자체 물리 라이브러리가 있는 또 다른 문제: https://github.com/godotengine/godot/issues/4217
C#과 같은 언어에 대한 몇 가지 문제가 있습니다: https://github.com/godotengine/godot/issues/2790

좋은 발견, @ alabd14313 - GDScript는 그대로 두면서 거의 대부분의 문제를 해결할 수 있습니다.

RCCPP에 대해서는 매우 좋은 생각입니다. Godot가 에디터 모드에서 지원한 다음 빌드에서 비활성화했다면 최대 성능과 반복 시간이 꽤 빠를 것이라고 생각합니다. Unreal Engine과 같은 다른 엔진이 C++와 유사한 작업을 수행한다고 들었고 Godot가 C++ 코딩과 같은 원활한 스크립팅을 허용한다면 꽤 깔끔할 것이라고 생각합니다.

저자는 이 페이지 에서 자신의 접근 방식에 대한 대부분의 대안을 나열했기 때문에 자신의 내용을 알고 있는 것 같습니다(내가 언급한 LLVM JIT 포함).

이 접근 방식이 가장 합리적이라고 생각합니다. Godot는 C++로 작성되었기 때문에(그리고 C++가 몇 년 안에 훨씬 더 좋아질 것이라는 점을 고려할 때 변경될 것이라고는 생각하지 않습니다.) 이미 작동하는 C++ API와 C++가 있습니다. 오버헤드가 전혀 없는 최대 바람직한 성능을 제공하며 추가 런타임이나 메모리 관리자가 없습니다. 개발자분들이 참고하시길 바랍니다.

스크립팅 언어로 C#을 추가하자는 제안에 대한 반응으로 시작된 이 스레드가 여섯 명이 의견을 밝혔음에도 아직 FOR C#에 대한 단일 인수를 포함하지 않는다는 사실에 약간 놀랐습니다.
아마도 C#을 추가하기로 한 결정은 내가 들은 소문에서 가정한 것만큼 미리 계획되지 않았을 것입니다.

@Warlaan 이 URL을 Facebook 그룹에 게시하면 어떻게 되나요? :)

제목을 "스크립팅 언어로서의 C++"와 같이 변경하십시오.
C++17에는 더 많은 기능이 있습니다.
http://blog.mattnewport.com/why-c17-is-the-new-programming-language-for-games-i-want/
나는 Godot 개발자들을 존경하고 그들의 작업에 감사드립니다. 그러나 나는 Box2D/LiquidFun/Bullet 라이브러리에 저항합니다. 이러한 방식으로 개발자는 물리학과 같은 구성 요소가 아닌 파이프라인에 집중할 수 있습니다. C++를 사용하면 gdscript를 유지 관리하고 업데이트하지 않고 성능에 집중할 수 있습니다. 이론적으로 RCCPP는 도구 모드와 같은 몇 가지 새로운 기능을 더 나은 방식으로 구현할 수 있습니다. 아마도...

@reduz 는 몇 달 전에 언리얼 청사진과 같은 시각적 스크립팅을 구현하고 싶다고 말했습니다. RCCPP를 사용하면 C++(프로그래머용)와 Visualscripting(레벨 디자이너 및 아티스트용) 간의 워크플로를 다음과 같이 구현할 수 있습니다.
UE4의 C++ 프로그래밍 소개
C++ 및 청사진
따라서 그룹에서 프로그래머는 아티스트를 위한 새로운 청사진 클래스를 개발할 수 있으며 아티스트는 직접 코딩하는 대신 이를 사용합니다.

@Warlaan IMHO 많은 C# 이야기가 Godot가 Unity ripoff가 되기를 바라는 사람들에 의해 연료가 공급되었기 때문입니다. 그러나 다행스럽게도 여기 많은 사람들은 Godot가 고유한 것이며 여러 면에서 이미 Unity보다 앞서 있고 공정하지 않다는 것을 깨닫습니다. 동일한 문제의 영향을 받도록 합니다.

@alabd14313 제목을 변경하고 싶지만 별도의 문제를 만들어 후세를 위해 보관하는 것이 더 나을 것입니다. 그래서 누군가가 C#을 제안할 때 연결할 수 있습니다(종종 그런 경우입니다).

솔직히 비주얼 스크립팅에 대해 주저하지만 모듈로 구현할 수 있다면 왜 안 될까요? 물론 비주얼 스크립팅(디자이너 및 초보자), GDScript(프로그래밍할 수 있거나 배우려는 사람) 및 C++(프로그래머)가 있으면 Godot가 모든 수준의 기술에 적합하지만 C++ 코딩을 덜 만드는 균형 잡힌 프로그램이 될 것이라고 생각합니다. 번거롭고 제3자 라이브러리와의 더 쉬운 인터페이스를 허용하는 것은 많은 전문 사용자(및 결과적으로 기여자)를 가져올 수 있기 때문에 더 높은 우선 순위인 IMHO를 가져야 합니다.

Imho 비주얼 스크립팅은 의미가 있을 만큼 세련되지 않습니다. 마케팅 및 프로그래밍 입문자에게 유용하지만 내 경험에 따르면 초보자가 흐름도를 선호하는 학습 단계는 매우 짧습니다.
내가 아는 시스템(Unreal, Cryengine, Fungus, Stingray)의 가장 기본적인 호출 시퀀스 외에는 도움이 되지 않습니다. 예를 들어 이 스크린샷 은 Stingray 엔진의 공식 광고 비디오에서 가져온 것입니다. 이제 그것이 내가 스파게티 코드라고 부르는 것입니다. 그리고 Cry 엔진의 공식 예제는 더 좋아 보이지 않습니다. 주석 요소의 양으로 그래프를 읽을 수 있도록 하기 위해 많은 노력을 기울였다는 것을 알 수 있습니다.
그것이 그렇게 나쁘지 않다고 생각한다면, 텍스트 기반 언어로 된 코드를 본다면 화면 밖에서 시작하는 모든 연결 라인이 (바라건대) 의미 있는 이름을 가진 변수가 될 것임을 상기시켜 드리겠습니다.

흐름 그래프는 중간 결과를 표시할 수 있기 때문에 쉐이더/머티리얼에 관해서는 다소 도움이 됩니다. 그러나 거기에서도 시스템은 다음과 같은 짧은 방정식이
float x = (ab)*(a+b)/(1-(a+b))
모든 곱셈, 합 또는 차이는 두 개의 입력과 출력이 있는 노드이기 때문에 그래프로 완료되면 전체 화면을 쉽게 채웁니다. 위 공식의 경우 최소 10개의 노드이며, 연결의 혼란을 야기하지 않으려면 a- 및 b-노드를 복제해야 합니다.

오늘날 우리가 가지고 있는 흐름 그래프 시스템(적어도 내가 아는 시스템)은 값에 의미 있는 이름을 부여하는 옵션을 없애고 있습니다. 결과를 중간 명명된 변수에 넣는 대신 단순히 다음 노드에 연결하기 때문입니다. 이는 자체 문서화 코드를 거의 불가능하게 만들고 문서화에 더 많은 노력을 기울여야 합니다.
이러한 시스템이 추가하는 것은 원하는 곳에 노드를 배치할 수 있는 옵션으로, 내 경험에 따르면 더 읽기 쉬운 코드보다는 덜 읽기 쉬운 코드가 더 자주 발생합니다.

그리고 흐름 그래프가 코딩이 아닌 것처럼 이야기하지 마십시오. 그들은 다른 프로그래밍 언어만큼 많은 코딩을 합니다. 그들은 타이핑을 하지 않고 있습니다. 그게 전부입니다.

비주얼 스크립팅은 디자이너와 아티스트가 코딩 방법을 배우지 않고도 변경할 수 있도록 하는 것입니다. 일부 아티스트는 간단한 인터랙티브 게임도 만들 수 있습니다. 그것은 분명히 유용한 곳에 목표를 가지고 있습니다. 그것은 단지 프로그래머를 위한 것이 아닙니다.

@Warlaan 글쎄, 그것은 "프로그래밍"을 정의하는 방법에 달려 있습니다. 확실히 시각적 스크립팅은 알고리즘을 정의하는 것과 유사하므로 프로그래밍과 멀지 않지만 프로그래밍은 다른 것들에 관한 것이기도 합니다.

그러나 시각적 프로그래밍의 좋은 구현이 있습니다. PureData가 하나이며 꽤 좋은 FLOSS 게임 제작 프로그램인 GDevelop 도 있습니다. 간단히 말해서, 비록 내가 개인적으로 그것을 좋아하지는 않지만(당신이 언급한 몇 가지 이유 때문에), 우리 둘 다 프로그래밍할 수 있다는 것도 사실입니다. 그래서 우리에게 시각적 프로그래밍은 비교적 좋지 않은 결과를 얻기에는 느리고 번거롭습니다.

그래도 일부 사람들이 매력을 느낀다 는

플로우 그래프가 셰이더 편집에 잘 작동하는 이유는 매우 시각적이기 때문입니다(파일 경로와 값을 수동으로 입력하지 않고도 이미지 로드, 색상 선택 등을 허용하는 노드가 있음). 또한 구문이 정확하고 기능의 철자가 올바른지 확인하는 것에 대한 두려움이 전혀 없습니다. 행렬로 작업하는 방법과 같은 복잡한 작업을 알아낼 필요도 없습니다(모두 계산됨).

셰이더 편집을 위한 Godot의 방법론은 정점, 조각, 조명 구성요소를 깔끔하게 분리하고 작업 중인 데이터 유형(일반 정보인지 카메라 정보인지)에 대한 명확한 지침을 제공하기 때문에 좋은 접근 방식이 됩니다.

이제 시각적 스크립팅을 사용하면 노드가 게임 메커니즘 측면에서 충분히 높은 수준에 있고(더 복잡한 작업을 수행하고 여러 입력이 있음) 중간 수준의 복잡한 작업에도 유용할 수 있다고 생각합니다. 스크립트를 실행하거나 표현식/방정식(복잡한 방식으로 값을 조작하는 데 사용할 수 있음)을 생성할 수 있습니다. 이 유형의 다른 시각적 노드 시스템에서 내가 본 문제는 가능한 한 문자 프로그래밍에 가깝도록 노력한다는 것입니다. 블렌더의 로직 브릭 또는 GameMaker의 드래그 앤 드롭).

물론, 순수 스크립팅으로 할 수 있는 것만큼 세밀하고 고급스러운 것은 허용하지 않지만 게임 내에서 (매우 복잡한 로직이 필요하지 않은 단순한 객체 유형에 여전히 사용됩니다. ) 또는 무언가를 빨리 쳐야 하는 경우.

나는 어떤 사람들은 그것에 매력을 느낀다는 것에 동의하고, 그것이 프로그래머를 위한 것이 아니라는 데에도 동의합니다(단지 "프로그래머"에 대한 정의가 다름 ;-) .

C++의 또 다른 유용한 기능은 정적 유형이라는 것입니다. "auto" 및 "decltype" 기능은 개체 유형을 감지할 수 있습니다. 편집기 및 코드 완성이 더 쉬울 수 있습니다. 내부 코드 편집기에 집중하는 대신 다른 외부 IDE를 사용할 수 있습니다. 현재로서는 codelite와 qtcreator가 코드 완성에서 더 나은 상태를 가지고 있다고 생각합니다. 코드 블록은 C++11 키워드와 관련하여 몇 가지 문제가 있습니다. 또한 eclipse-cdt는 좋은 코드 완성을 가지고 있습니다. qtcreator용 플러그인은 좋은 아이디어입니다(예: unreal-visual studio 및 Unity-Monodevelop). 외부 IDE는 godot 설정(예: /use/bin/qtcreator)에서 시스템 경로로 식별할 수 있으며, Godot로 컴파일 및 패킹할 필요가 없습니다(Unity 패키지에 내장된 monodevelop와 달리).
qtcreator에 플러그인이 있는 cppcheck 및 valgrind와 같은 다른 도구가 있습니다.
RCCPP가 무엇인지 미리 보려면:
데모

Godot용 C++ 기반 스크립팅 언어를 보고 싶지만 모든 C++ 기능을 구현하는 것은 템플릿 프로그래밍과 같이 번거로울 것입니다. 이러한 종류의 스크립트 언어(STL)에는 몇 가지 제한 사항이 있어야 하며 템플릿을 사용해서는 안 됩니다. 또한 RTTI는 성능 문제를 일으킬 수 있습니다.

나는 GDscript를 좋아합니다. 그것에 대한 유일한 불만은 변수 이름 공간의 오염입니다. 큰 스크립트를 처리할 때 ready() 이전의 변수 정의는 매우 지저분해질 수 있고 동일한 스크립트 파일의 함수 간에 변수를 공유하기 때문에 코드에서 버그가 발생하기 쉽습니다. .

내 3센트. (어... 20으로 끝났지만 그냥 놔둬...)

앞서 언급한 @alabd14313 처럼, Godot를 오늘날의 형태로 이끈 수년 간의 진화로 인해 "이것이 바로 그 지점에 있습니다".
자연이 하든 우리 인간이 하든 간에, 창조 당시의 일을 바로잡는 것이 발전의 가장 좋은 길인 것 같고, 덕분에 나는 고도를 있는 그대로, 그리고 진화가 가져다준 곳을 아주 좋아한다는 것을 인정해야 합니다.

필요한 모든 조각이 있습니다.

더 복잡한 개체로 결합될 수 있는 노드는 장면으로 저장한 다음 다른 장면에서 "단순한" 개체로 다시 재사용할 수 있습니다. 이 개체는 사용자 자신의 상상력과 창의성 경계에 의해서만 제한되는 굉장하고 유연한 기능입니다.

사용 및 학습이 간편한 GDScript, 코드 줄을 입력하여 우리 코더가 하던 방식으로 모든 노드를 제어할 수 있을 만큼 강력합니다.
또한 컴파일할 필요 없이 빠르고 쉬운 방법(코드 완성/빌드인 문서/유용한 툴팁)으로 수행하는 것 외에도 입력하고, 시도하고, 조정하고, 다시 완벽하게 연마합니다.

클릭 한 번으로 여러 플랫폼에 배포(Wi-Fi/adb, 생활 편집, 디버깅 등을 통해 Android에 배포하는 것은 말할 것도 없고 그냥 예술의 걸작입니다. 아니... 그 이상, 마술입니다!)

또한 블렌더 요법과 같이 일반적으로 사용되는 도구에 대한 이러한 모든 친숙함.
(물건을 가져오면 즉시 사용할 수 있습니다. 모든 것이 있어야 할 위치와 방식)

그리고 마지막으로, 루프에서 백만 번이고 1 프레임에 맞는 일을 하는 데 있어 초창기성조차도 충분하지 않을 수 있음을 인정합니다. 그것이 C 항목이 들어오는 곳입니다. C를 알고 필요하다면 원하는 것을 정확히 수행하는 플러그인, 자체 사용자 정의 노드 요법을 만드는 것을 막을 수는 없습니다.

거의 모든 것을 갖추고 있으며 시간이 지나면 모든 것을 갖게 될 것이라고 믿습니다.
(즉, 오늘날의 것들은 "아직 구현되지 않았으며" '어떻게든' 또는 '맨손으로' 해야 합니다(읽기: 외부 도구 사용). )

Godot는 놀랍고 마술적이며, 가는 길에 완벽하게 맞습니다.조정이 필요하고 여기 저기에 물건을 추가해야 하지만 그게 전부입니다.

비주얼 스크립팅?
음. 그것은 우리 코더들로 하여금 비정상적인 방식으로 "조금" 사고 방식을 바꾸도록 강요할 수 있으며, 게다가 나는 그것이 일반 코드만큼 유연하고 가독성이 있을 수 있다고 믿지 않습니다.
당신이 코딩하고 다음과 같은 간단한 한 줄을 가지고 있다고 상상해보십시오 ( abc / def ) * ghi
그런 다음 평소와 같이 빠른 방법(?) 입력을 저장하기 위해 무언가의 일부를 표시하고 여기에 붙여넣고 저기를 자르고 다시 붙여넣고 5초 안에 키를 몇 번 누르면 "단순"으로 끝납니다(당신이 하는 일을 알고 있기 때문입니다) ((((abc/def+((abc/def)_ghi^4))_ghi)+(abc/def_(100))_ghi)+abc)와 같은 하나의 라이너
일반적이고 아마도 우리 중 많은 사람들이 이 방식으로 매우 빠른 속도로 수행합니다.
이제 시각적인 방법으로 하는 것을 상상해 보세요...
전체 화면이 필요할 수 있고 많은 마우스 작업이 필요할 수 있으며 예상대로 읽을 수 있는 것처럼 보이지 않을 것입니다.
(물론 그런 라이너도 1년이 지나면 쉬워보이지는 않지만 댓글이 달린 이유는)

누군가가 100개의 그러한 라인을 다른 라인 아래에 가지고 있다면 어떻게 될까요?
시각적으로 그는 그것을 전시할 축구 경기장을 얻을 수 있었습니다. 그것을 분석하고 변경하는 것은 어떻습니까? 엉망이고 큰 골칫거리입니다.
물론 코더는 사용되는 언어가 아니라 누군가를 코더로 만들고, 알고리즘을 만들고, 데이터를 작은 부분과 전체로 조작하는 특정한 사고 방식을 만들기 때문에 이 작업을 수행할 수 있습니다.
C, Python, PHP, Java 또는 Visual 스크립팅이든 상관없이 언어는 생각을 기록하는 도구일 뿐입니다.
그리고 여기 임호, 키보드로 일반 타이핑하는 것이 가장 빠르고 읽기 쉬운 형식으로 적어 둡니다.
반면에 누군가가 코딩을 못한다면 우리가 게임을 생각할 때 두 개의 공을 두드리는 것보다 더 복잡한 것에 대해 이야기한다는 점을 고려할 때 자신의 아이디어와 시각적 표현에서 길을 잃지 않는 알고리즘의 천재성과 지각력을 갑자기 드러낼 것이라고 기대하십니까? 물리학으로 서로.

그렇다면 실제로 Visual Scripting은 누구를 위한 것입니까?
코더의 삶을 더 어렵게 만들거나 초보자를 위한 "간단한 게임"을 위한 엔진 수준으로 Godot를 제한하려면?

여러분, #1220에서 Visual Scripting에 대한 긴 토론이 있습니다. 여기에서 같은 주제를 다시 논의하지 맙시다.

여러분, #1220에서 Visual Scripting에 대한 긴 토론이 있습니다. 여기에서 같은 주제를 다시 논의하지 맙시다.

여기에 있는 대부분의 게시물은 너무 길어서 읽는 동안 길을 잃었습니다.
죄송합니다:편안함:

@RebelliousX RTTI를 사용하더라도 C++는 여전히 GDScript보다 훨씬 더 나은 성능을 보입니다. 템플릿이 문제가 될 수 있는 것은 사실이지만.

#3936에서 @reduz 가 제안한 솔루션은 이미 C++ 코딩을 상당히 간단하게 만들 것입니다. 선택한 편집기와 컴파일러를 사용하고 Godot의 API에 링크하기만 하면 됩니다. 이것이 구현된다면, C++로 스크립팅하는 것이 좋을지라도, 성능 면에서는 C++로 코드를 작성한 다음 GDScript에서 호출하는 것과 크게 다르지 않을 것입니다. 간단히 말해서, #3936(간단한 솔루션)에 초점을 맞추면 다음과 같이 크게 개선될 것입니다.

• 성능(C++로 부분을 작성하는 것은 매우 쉬울 것이기 때문에)
• 타사 라이브러리의 가용성(래퍼가 더 쉽게 배포될 수 있지만 #3943만큼 쉽지 않기 때문에)
• 사용자 기반 및 기여자(많은 C++ 프로그래머가 Godot를 채택할 것입니다)

그런 다음 GDScript의 정적 입력 및 인터프리터 최적화(JIT를 통해 또는 GDScript를 C++로 컴파일)에 초점을 맞출 수 있지만 모듈 작성이 더 쉬워지면 나중에 올 수 있습니다.

이 토론에 잠입했지만 아직 해결되지 않은 몇 가지 요점을 언급하고 싶습니다.

• 우리 중 일부는 C++ 개발을 촉진하고 GDScript 성능을 향상시켜 기존 시스템(스크립팅 언어로서의 GDScript, 백엔드 언어로서의 C++)을 개선하는 것에 대해 이야기하고 있습니다. 다른 사람들은 C++(또는 Java / C# / ...)를 스크립팅 언어로 사용하는 것에 대해 이야기하고 있습니다. 빠른 C++ 개발을 가능하게 하는 것과 그것을 스크립팅 언어로 만드는 것 사이에 실질적인 차이가 없는 것처럼 보일 수도 있지만, 게임 디자인 품질에 대한 강력한 스크립팅 언어의 부정적인 영향을 내가 어떻게 경험하고 관찰했는지 기꺼이 설명하겠습니다. 그리고 이것이 토론의 주제가 되지 않는 한 포럼이나 이 스레드를 가로채지 않는 다른 곳에서 기꺼이 그렇게 할 것입니다.
• @RebelliousX : "변수 이름 공간", "큰 스크립트" 및 "함수 간 변수 공유"에 대해 이야기할 때 GDScript의 객체 지향 특성을 완전히 이해하지 못한 것처럼 들립니다(공격 없음). 모든 GDScript 파일은 클래스이므로 (멤버) 변수 간의 이름 충돌은 다른 객체 지향 언어와 마찬가지로 자주 발생해야 합니다. 스크립트 간에 변수를 공유하지 않고 포함하는 개체의 상태에 액세스할 수 있는 여러 함수를 작성하고 있습니다.

@Warlaan 첫 번째 요점에 대해서는 주제와 관련이 있으므로 여기에 게시할 수 있다고 생각합니다.

@Warlaan 공격을 받지 않았습니다. GDscript가 자체 클래스이고 변수가 C++ 클래스의 일반 멤버 변수와 같다는 것을 알고 있지만 제 요점을 완전히 놓친 것 같습니다. 1000줄 이상의 코드가 있는 스크립트가 있으면 이해할 수 있습니다. 내가 원하는 것은 수많은 멤버 변수를 생성하는 대신 참조 또는 포인터를 멤버 함수 사이에 전달하는 것입니다. 그래야 더 안전합니다.

C#을 좋아하지만 장단점이 있습니다.

장점:

• 좋은 도구 지원(사실, Visual Studio 또는 MonoDevelop 없이 C#으로 코딩하시겠습니까?)
• 대규모 프로젝트에 적합
• 널리 사용되고 성숙한 인터넷에는 수많은 지원 스레드가 있습니다.
• 크로스 플랫폼이면서 우수한 성능, C++와 스크립팅 언어 간의 절충안
• C++에 비교적 쉽게 바인딩

단점:

• 수집된 쓰레기: 대규모 게임 프로젝트는 GC 킥이 너무 자주 발생하지 않도록 할당 전략을 구현해야 합니다. 이는 불쾌할 수 있습니다.
• GDScript만큼 통합되지 않음(노드 경로 완성? 노드의 스크립트 멤버 변수? 메모리 할당 모델?)
• 런타임은 무겁고 .NET 프레임워크는 훨씬 더 많습니다. Unity에서와 같이 표준 라이브러리는 Godot에 다시 매핑되어야 합니다.
• 빠르고 더러운 작업을 완료한다는 의미에서 실제 스크립팅에 가장 적합하지 않습니다. C#은 GDScript보다 더 장황하고 제한적입니다.
• Godot 개발에 관한 가이드라인은 아직 없습니다. 언어는 일반적이고 많은 일을 할 수 있으며 Warlaan이 말했듯이 개발자는 서로 다른 문화를 가지고 있습니다.

이 대부분은 Java에도 적용됩니다.
늦은 시간이라 다른 일을 잊고 있었을 수도 있습니다.

자, 이것은 기능이 풍부한 스크립팅 언어 resp에 대한 제 경험입니다. "스크립팅 언어"의 정의에 따라 스크립팅 언어가 완전히 부족합니다. 나는 그것을 짧게 유지하려고 노력할 것이다. ;-)

저는 독일 베를린에 있는 School4Games에서 엔지니어링 학장으로 몇 년 동안 일하고 있습니다. 그 학교에는 "순수한" 게임 디자인을 위한 교수진이 없지만 우리 게임 디자인 코스는 "게임 개발"이라고 하며 게임 디자이너에게 자신의 프로토타입을 개발하고 가능성과 한계를 이해하는 방법을 가르치는 충분한 프로그래밍 수업이 포함되어 있습니다. 하드웨어 및 공통 소프트웨어 아키텍처
그래서 제가 가르치는 학생들은 때때로 프로그래밍에 관심을 가지고 있지만 프로그래머가 되기 위해 지원한 사람은 아무도 없는 사람들입니다.
매 학기마다 팀을 구성하고 하나의 게임을 개발해야 합니다. 우리 학생들의 거의 모든 잠재적인 미래 고용주가 Unity를 사용하기 때문에 처음 두 학기 동안 해당 엔진으로 작업하는 것이 요구 사항이었습니다.

이제 스크립팅 언어의 효과에 관한 요점을 살펴보겠습니다.
이 학생들은 두 그룹으로 나뉩니다. 프로그래밍을 피하려고 하거나 희망을 잃은 사람(프로그래밍 수업에 참석하지만 문제가 발생하면 도움을 요청하지 않고 조용히 포기한다는 의미) 및 프로그래밍에 너무 깊이 빠져서 다음 주제로 바로 건너뛰는 사람 일반적으로 게임 프로토타입을 작성하는 동안에는 관심을 두지 않을 것입니다. 예를 들어 첫 학기의 제 학생 중 한 명이 제네릭을 사용하여 C#에서 싱글톤을 작성하는 방법에 대한 자습서를 최근에 게시하여 자습서의 일반 클래스에서 상속하여 Unity 구성 요소 클래스를 싱글톤으로 전환할 수 있습니다. 흥미로운 점은 그가 그 기사를 쓸 수 있을 만큼 많지 않다는 것입니다. 결국 그는 교사의 도움을 받았고 인터넷에 주제에 대한 많은 리소스가 있습니다. 흥미로운 점은 프로그래밍보다 게임 디자인에 중점을 둔 과정에 지원한 학생이 그러한 특정 프로그래밍 주제에 관심이 있다는 것입니다. 해당 튜토리얼의 코드는 게임 디자인의 변경으로 인해 절대 변경되지 않으며 순수한 프로그래밍 구성입니다.
한 게임 장면에서 다른 게임 장면으로 정보를 전송하기 위해 유사한 클래스를 사용한 다른 학생에게도 비슷한 일이 발생했습니다. 그는 public static 멤버로 동일한 작업을 수행할 수 있다는 것을 보여주었을 때 상당히 놀랐습니다. 이는 그가 모든 기본 요소를 완전히 이해하기 전에 완전하고 복잡한 솔루션을 찾고 있음을 보여줍니다.

따라서 건너뛰면 지금까지의 텍스트가 요약됩니다. 기능이 풍부한 언어로 간단한 코드를 작성할 수 있지만 복잡한 대안이 있는 경우 사람들이 간단한 솔루션을 무시할 가능성이 높다는 것을 여러 번 관찰했습니다.

이는 편견 때문만은 아니다. 물론, 그것은 아마도 한 가지 요인일 것입니다. 튜토리얼, 예제 또는 프로젝트의 다른 클래스에 있는 코드가 복잡해 보인다면 여러분의 코드도 복잡해 보여야 한다는 결론을 내릴 수 있습니다. 하지만 진짜 이유는 프로그래밍에서 오류가 없는 코드를 만드는 것이 합리적이기 때문이라고 생각합니다. 다른 장소에서 사용되자마자 또는 다른 입력을 받자마자 깨지지 않는 코드를 작성하는 것은 자연스러운 욕망입니다. 그리고 준비해야 할 옵션이 무엇인지 알아내야 합니다.
모든 상황에 대해 확인해야 한다는 이러한 느낌이 제 학생들을 C#의 방대한 기능에 빠져드는 학생들과 바로 뛰어들어 언어에 대한 집중을 잃는 학생들로 나누는 이유라고 생각합니다.

Zylann은 "빠르고 더러운"이라는 문구를 언급했습니다. 우리는 종종 이 두 용어를 구로 사용하지만, 생각해보면 실제로는 두 가지 다른 요소입니다. 빠르게 코딩할 수 있는지 여부는 상당히 측정 가능합니다. 반면에 결과 코드가 더러운지 여부는 많은 요인에 따라 달라지며, 가장 중요한 것은 사용된 언어의 기능 수입니다.
예를 들어 최상위 노드를 생성하고 Godot에서 싱글톤으로 사용하는 것은 GDScript가 C#과 같은 언어에서와 같은 방식으로 패턴을 구현하는 데 필요한 기능을 제공하지 않기 때문에 완전히 괜찮습니다. 물론 자동 로드 기능을 사용하는 것이 다른 개발자가 싱글톤을 찾는 첫 번째 장소이기 때문에 더 좋을 것입니다(그리고 구문을 조금 더 멋지게 만듭니다). 그러나 팀이 그런 방식으로 구현하기로 결정하면 논쟁. 반면에 누군가가 클래스에 public static 멤버를 추가하여 Unity에서 싱글톤을 구현했다고 상상해 보십시오. 그것은 똑같이 빠르지만(둘 다 가장 공개적인 장소에서 클래스 인스턴스임) C#은 생성자를 비공개로 만드는 옵션을 제공하기 때문에 지연 초기화 등의 속성을 통해 싱글톤에 액세스합니다. 그렇지 않으면 코드가 깨지지 않으면 매우 더러운 것으로 인식될 것입니다.

이제 게임 디자인 학생들이 이와 같은 주제에 뛰어 들었다는 사실이 내 요점에 대한 모호한 힌트 일 수 있지만 대형 F2P MMO 개발자에서 첫 직장의 상황에 대해 이야기하면 더 잘 설명 할 수 있다고 생각합니다. 제가 합류한 팀은 독일에서 가장 경험이 풍부한 게임 개발자 중 한 명입니다. 그들의 개발 책임자는 1995년부터 자체적으로 자체 엔진을 만들고 있으며 다른 회사에서 구입한 지 얼마 되지 않았지만 여전히 당시 가장 성공적인 개발자 중 한 명이었습니다.
내가 팀에 합류했을 때 그들은 스크립팅 언어가 없는 사내 엔진의 세 번째 버전을 사용하고 있었습니다. 그들은 이전에 하나를 구현했지만 해당 버전의 엔진에서는 게임 디자이너가 제공한 코드 품질에 문제가 있었기 때문에 스크립팅 언어가 없는 것으로 되돌아갔습니다. 다시 말해서, 스크립팅 언어가 너무 강력했기 때문에 프로그래머가 모든 프로그래밍을 하는 동안 게임 디자이너는 레벨을 편집하고 설정 시트의 설정만 변경하는 지점으로 프로그래머와 게임 디자이너 사이의 장벽을 옮기기로 결정했습니다. 이것은 제 학생들이 처한 상황과 거의 동일하다는 사실을 알게 되었습니다.
이제 내가 왜 신경을 쓰겠습니까? 이런 일이 반복해서 일어난다면 그것이 성공적인 업무 방식임을 증명하지 않습니까? 내 대답은 아니오입니다. 기술적 문제와 게임 디자인 모두에 문제가 있었기 때문에 프로그래머와 게임 디자이너 간의 의사 소통이 한 방향으로 작업을 작성하고 다른 방향에서 설정을 노출하는 것으로 축소되었다는 사실로 쉽게 설명될 수 있었습니다. 게임 디자이너의 관점에서 기능은 활성화 및 비활성화할 수 있는 블랙박스가 되었지만 팀 측에서는 대안을 논의하거나 프로토타입을 만들 수 있는 사람이 아무도 없었습니다.
반면에 프로그래머는 거의 자연스럽게 백엔드 사고방식으로 밀려났습니다. "빠르고 더러운" KISS 사고방식은 사라졌습니다. 우리가 구축한 기능이 어떻게 사용될지 아무도 예측할 수 없었기 때문입니다. 게임 디자이너가 부활절 달걀 찾기를 구현하여 인벤토리가 예전보다 훨씬 많이 늘어나 데이터베이스가 고장난 것을 생생하게 기억합니다. 기능의 요구 사항이 거의 동일하게 유지될 것이라고 가정한 것이 마지막이었습니다.

그렇기 때문에 저기능 스크립팅 언어를 게임 코드에 대한 정의된 영역으로 갖는 것이 매우 중요하고 이것이 없으면 게임 디자인에 나쁜 영향을 미친다고 생각하는 이유입니다.

• 빠른 코드를 작성한다는 것은 "빠르고 더러운" 코드로 전환하는 기능을 무시한다는 의미입니다.
• 깨끗한 코드를 작성하려는 열망은 개발자를 코딩하지 않는 개발자와 코딩에 대해 생각하는 데 더 많은 시간을 할애하고 게임에 대해 더 적은 시간을 보내는 개발자로 나눕니다.
• 그 결과 전체 팀을 코드 베이스를 모른 채 게임 디자인 작업을 하는 절반과 기능이 어떻게 사용될지 모르는 기능 작업을 하는 절반으로 나누어 게임을 기반으로 엔진 기능을 생각해낼 수 있는 사람이 아무도 남지 않게 됩니다. 쉽게 구현할 수 있는 기능을 기반으로 게임 디자인을 디자인하거나 제안합니다.

미리 빌드된 클래스 라이브러리를 사용하지 않고 오늘날 게임 개발을 상상하는 것은 불가능합니다. 결국 이것이 Godot, Unity, Unreal 등과 같은 도구 세트가 있는 엔진을 매우 성공적으로 만드는 이유입니다. 그러나 이러한 모든 엔진의 차이점은 프로그래밍과 게임 디자인 사이의 경계선이 어디인지와 양쪽 사이에 얼마나 많은 격차가 발생하는지입니다.
그리고 내 관찰에 따르면 스크립트 언어의 선택은 그러한 격차를 만들거나 좁힐 수 있는 가장 중요한 요소 중 하나라고 생각합니다.

그런데 제가 Godot에 이렇게 빠져들게 된 이유는 1학기에 필수 엔진으로 정착시키기 위해 노력하고 있기 때문입니다. 내가 말만 하는 것이 아니라 결과를 그리는 것도 알고 계시니까요. ;-)

@RebelliousX 나는 아직도 당신이 무엇을 하고 있는지 잘 이해하지 못한다는 것을 인정해야 합니다. 그러나 당신이 원하는 것은 참조나 포인터라고 말했기 때문에 새로운 기능 요청을 열고 거기에 문제에 대한 코드 예제를 게시할 수 있습니까? 솔직히 말해서 여전히 귀하의 문제가 누락된 언어 기능 중 하나가 아니라 코드 아키텍처 중 하나인 것처럼 들립니다.

나는 KISS가 주로 소규모 팀에 유리하다고 덧붙였어야 했다. Godot는 한 명의 개발자가 게임을 만들 수 있을 정도로 기능이 풍부합니다. 그러나 프로젝트에 더 많은 개발자가 있게 되면 "빠르고 더러운" 일의 가능성이 줄어들고 프로토타이핑이나 임시 수정을 위해 남겨진 다음 규칙/지침을 설정해야 합니다. 따라서 엔진을 누가, 무엇을 위해 사용하는지에 따라 다릅니다.

Godot는 일반적으로 우리가 생각하는 것보다 더 많은 제약이 있습니다. 메모리 누수와 쓰레드 친화성이라는 이유로 "c-static-style" 싱글톤이나 전역 변수를 만들 수 없습니다. GDScript는 다음과 같은 이유로 Python만큼 기능하지 않습니다. 게임 개발 작업 및 성능에 중점을 둡니다. 장면 시스템은 이유 때문에 객체 지향이기도 합니다. 테스트하고 재사용할 수 있는 독립적인 "상자"를 만들 수 있습니다. :)

이 항목은 C#(또는 Java) 모듈 지원을 추가하는 것에 관한 것이지만 예제 코드가 표시되지 않습니다. 즉석에서 뭔가를 시도하자 :)

using GodotEngine;

// Inherit a node type
public class Spikeball : RigidBody2D {

    // Exported variables
    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

    // Notice the naming convention. Should Godot API follow languages or should languages follow Godot?

    void _Ready() {
        SetProcess(true);
        // Should we use the generic system?
        Connect("BodyEnter", this, "_OnBodyEnter")
        // Or use C# features?
        this.bodyEnterEvent += _OnBodyEnter;
    }

    void _Process(delta) {
        var sprite = (Sprite)GetNode("Sprite");
        sprite.SetRot(sprite.GetRot() + delta*rotationSpeed);
        // Or we can have properties
        sprite.rot = sprite.rot + delta*rotationSpeed;
    }

    public void _OnBodyEnter(PhysicsBody2D body) {
        // We cannot invent C# members on the fly, so we can do this if the other script is in C# too.
        // ScriptInstance GetScript();
        var health = body.GetScriptInstance() as IHaveHealth;
        if(health != null) {
            health.TakeDamage(damage);
        }
        // But what if the other is GDScript?

        // A generic approach would look like this, a bit like SendMessage in Unity3D
        // object Call(string funcname, object arg1, ...); // where object can be seen as Variant
        body.GetScriptInstance().Call("TakeDamage", damage);

        // Same thing if we want to get a script variable
        var category = (string)body.GetScriptInstance().Get("category")
        Console.Print(category);
    }

}

어떻게 생각해?
그런 다음 이 파일을 DLL 자산으로 컴파일하거나 즉석에서 실행할 수 있습니다. 그러나 이것에 대해 말하면 Unity와 같은 csproj를 생성해야 합니까?

@Warlaan 경험을 공유해 주셔서 감사합니다. 제가 잘못 이해했다면 정정해 주세요(긴 글이었습니다). 하지만 프로그래머가 오버코딩보다 게임 개발에 집중할 수 있도록 기능이 적은 언어를 제공하는 것이 더 낫다는 말씀이신가요?

그렇다면 이것은 매우 미묘한 관찰입니다. Godot 개발자는 사용자 기반을 위해 최선을 다해야 한다고 생각합니다. 그들은 무엇이 최선인지 알고 있습니다.

그리고 저는 오늘 여기 있는 일부 사람들(저를 포함하여)이 Urho3D 를 미묘하게 요구하는 것이 아니라 다른 사람들이 GDevelop 을 요구하는지 궁금합니다. Godot는 분명히 그 둘 사이의 중간 도구입니다(하지만 Urho3D와 같은 전문가에게 완벽하게 적합). 저는 그렇게 유지되어야 한다고 생각하지만 Unity는 여기에 많은 사람들이 있기 때문에 항상 그림자를 드리울 것입니다. 그것에서 온다.

나는 Godot가 Unity ripoff가 될 것이라고 기대하는 것이 공평하지 않다고 생각합니다. Godot는 분명히 더 나은 디자인과 더 나은 성능을 가지고 있습니다. 그러나 어떤 사람들은 GDScript가 "심각한" 개발에 적합하지 않으며 Unity가 사용하는 이전 버전의 Mono가 어떤 면에서는 "사용자 정의" 런타임이라는 사실에도 불구하고 사용자 정의 런타임이기 때문에 결코 적합하지 않을 것이라고 생각합니다. 게다가 Unity에서 C#을 작성할 때 대부분 Unity에서만 작동하는 코드를 작성하고 디자인 패턴을 따르므로 다른 언어를 사용하는 것이 좋습니다.

나는 C#을 원하는 사람들이 틀렸다고 생각하지만, 내 생각에 좋은 타협은 다음을 제공하는 것입니다.

1) 더 나은 성능(정적 타이핑, 아마도 JIT)
2) 타사 라이브러리에 대한 더 나은 지원(FFI 및 더 쉬운 C++ 통합을 통해)

GDScript용. 나머지는 다른 스크립팅 언어를 구현하는 모듈 작성을 포함하여 C++에서 수행할 수 있습니다(자사일 필요는 없음 - 원하는 경우 누구나 C# 모듈을 작성할 수 있음).

@Zylann 솔직히 동등한 C++ 대신 해당 코드를 작성하는 데 이점이 없으며 C++ 코드의 성능이 더 좋습니다.

@paper-pauper 이 코드를 작성하는 이점은 GDScript와 동일합니다. 내보내려는 모든 플랫폼에 대해 엔진을 다시 컴파일할 필요가 없으며... 음, 언어를 선택할 수 있습니다(성능은 앞서 언급했듯이 유일한 한 지점이 아닙니다). 현재로서는 GDScript 경험이 더 뛰어나고 C++가 순수한 성능을 위한 최선의 선택이라는 데 동의합니다. 그러나 C++가 아무리 좋다 해도 하고 싶지 않은 사람들이 있습니다.
저는 개인적으로 Godot+C#에 관심이 없습니다. Godot에 추가하면 어떻게 되는지 평가하는 것뿐입니다. 그리고 그것은 그렇게 간단하지 않습니다 :p

Game Scripting Mastery라는 훌륭한 책을 읽은 후(컴파일러 Red Dragon에 대한 게임이 아닌 책을 제외하고 주제에 대한 책을 많이 찾을 수 없습니다). 내 결론은 GDscript가 적절하고 스크립팅 언어에 기능을 계속 추가하여 기능을 잃어버리게 만드는 것이 너무 쉽다는 것입니다. 가장 중요한 것은 부풀려지지 않은 스크립트 언어를 구현하고 가능한 한 일반적으로 다른 프로젝트에 적합하도록 만드는 것입니다. 같은 책에서 Unreal은 LLVM과 함께 C++를 사용하고 있다고 말합니다.

별도의 런타임을 구현하는 것보다 더 가벼울 수 있는 또 다른 아이디어: JavaScript 대신 GDScript를 내보내도록 TypeScript(런타임이 없는 C#과 매우 유사)와 같은 변환기를 적용하는 것은 어떻습니까? 이것은 Godot에 포함될 필요가 없습니다. 사실 이것은 타사 모듈일 수 있습니다. 최소한 정적 타이핑(컴파일 시)과 GDScript와 동일한 성능으로 여러 라이브러리를 제공합니다(GDScript이기 때문에).

나는 TypeScript를 좋아하지만 그런 복잡함을 추가할 요점이 보이지 않습니다. 누군가 그렇게 하면 최신 버전의 TS와 호환되도록 유지 관리해야 합니다. 또한 TS는 JS의 상위 집합이므로 JS를 GDScript로 변환할 수 있습니까? 그리고 나서 우리는 트랜스파일러에 버그가 있는 일부 사람들이 그것이 엔진의 버그라고 생각하게 만들 것입니다.

나는 여전히 더 나은 아이디어가 JIT에 더 쉽게 의존할 수 있고 여전히 엔진 및 현재 GDScript 자체와 밀접하게 관련될 수 있는 정적 버전 GDScript를 갖는 것이라고 생각합니다.

C#의 요점은 Godot 외부에서도 사용할 수 있는 확립된 언어를 사용하는 것입니다. TypeScript가 이에 적합할 수 있지만 Mono 런타임을 포함하는 것보다 TS 변환기를 만드는 것이 더 쉽다고 확신할 수 없습니다.

IRC에서 말했듯이 나에게 가장 좋은 옵션은 동적으로 연결된 모듈을 만드는 것입니다. 따라서 C++에서 더 쉽게 작업할 수 있으며 스크립팅 언어로 C#용 모듈과 C++용 모듈과 같이 다른 언어를 사용하는 타사 모듈도 있을 수 있습니다. 그것은 메인 엔진 바이너리를 부풀리지 않고 Godot의 자원을 성장시키는 능력을 증가시킬 것입니다.

@vnen

IRC에서 말했듯이 나에게 가장 좋은 옵션은 동적으로 연결된 모듈을 만드는 것입니다. 따라서 C++에서 더 쉽게 작업할 수 있으며 스크립팅 언어로 C#용 모듈과 C++용 모듈과 같이 다른 언어를 사용하는 타사 모듈도 있을 수 있습니다. 그것은 메인 엔진 바이너리를 부풀리지 않고 Godot의 자원을 성장시키는 능력을 증가시킬 것입니다.

아, 100% 동의합니다. 사실 저도 #3936에서 비슷한 견해를 밝혔습니다. 우리가 C#의 런타임을 단점으로 언급했기 때문에 그냥 버리고 있었습니다. :)

저에게 @Zylann 의 예제 C# 모듈은 훌륭합니다. 사용 가능한 경우 Unity에서 지금 전환하고 싶습니다. C++의 더 높은 성능이나 GDScript의 '쉬움'이 아니라 편안함에 관한 것입니다.

저는 여전히 Godot를 처음 접하고 테스트 게임을 만들 기회가 거의 없었기 때문에 여러분은 제 의견이 타당하지 않다고 생각할 수도 있지만 저에게는 GDScript가 노드와 작동하는 방식이 아니라 가장 큰 장애물입니다. 그리고 장면 - 나는 그것을 이해합니다 (그리고 그것은 꽤 깔끔합니다!).

그러나 나에게 있어 코드 편집기가 심각하게 부족하다는 것은 말할 것도 없고, 말할 것도 없이 말 그대로 GDScript의 구문입니다. 이미 모든 단축키를 알고 있기 때문에 VS를 사용하고 싶습니다.
나는 수년간 C#을 작성해왔고 솔직히 말해서 GDScript로 글을 쓰려고 하는 아이처럼 느껴집니다.

개발자가 편안하게 작성할 수 있도록 하면 무엇을 잃게 될까요? Mono 또는 Linq와 같은 화려함이 필요하지 않습니다. 코드를 작성하는 동안 편안하고 싶을 뿐입니다.
나는 GDScript를 위한 C#과 같은 구문, 최소한 중괄호, 세미콜론 및 명시적 유형을 사용하는 옵션으로 정착할 것입니다. 암시적 유형을 개인적으로 참을 수 없고, 그것들이 저를 미치게 만듭니다.
GameMaker는 다양한 인구 통계를 수용하기 위해 구문의 변형을 허용한다고 생각합니다.

이것은 물론 Godot와 몇 시간 동안 얻은 2센트에 불과합니다. 동의하지 않으셔도 됩니다.

또한, 나는 뭔가를 놓치고 있다고 생각합니다. 모두가 그토록 좋아하는 GDScript에 대해 정확히 무엇입니까?
화나게 하려는 게 아니라 아직 못 본 것뿐이에요.
저는 Perl에 매우 익숙하기 때문에 암시적 유형과 기타 등등의 힘을 알고 있지만 그 이상이 있어야 합니다. 그렇죠?

@Pikl :

또한, 나는 뭔가를 놓치고 있다고 생각합니다. 모두가 그토록 좋아하는 GDScript에 대해 정확히 무엇입니까?
화나게 하려는 게 아니라 아직 못 본 것뿐이에요.

GDScript에 대한 요점은 구문(Pythonesque)이 아니라 엔진과 얼마나 통합되었는지에 대한 것입니다. 현학적으로 들릴지 모르지만 구문은 다른 시스템으로 이동할 때 가장 덜 걱정되는 부분입니다. 가장 중요한 것은 API입니다. 우리가 지금 C#을 추가했더라도 Unity에서 하는 방식이 Godot에서 하는 방식과 같지 않기 때문에 새로운 패러다임에 불편함을 느끼실 것입니다.

죄송합니다. 모든 프로그래머가 편안하게 사용할 수 있는 언어를 추가한다면 우리는 영원히 그 일을 하며 보낼 것입니다. Unity 사용자에게 최소한의 스트레스를 주는 것이 합리적일 수 있지만(현재 Unity 사용자를 위한 Godot 가이드를 만들려고 노력 중입니다), Godot가 Unity처럼 작동하도록 스스로 적응해야 한다고 생각하지 않습니다. 그렇지 않으면 Unreal, Urho3D, GameMaker 등의 사용자에 대해서도 동일한 작업을 수행해야 합니다.

이것은 C#이 발생하지 않는다는 것을 의미하는 것이 아니라(가능하고 엔진의 이익 범위 내에 있는 경우일 수 있음) 이러한 주장이 다른 많은 언어 및 엔진에도 적용될 수 있다는 것입니다.

@Pikl 우선 C#에 대한 첫 번째 인수를 제공해주셔서 감사합니다. 이제 왜 당신의 의견이 타당하지 않다고 생각하는지 설명하겠습니다. ;-피

Zylann의 코드 예제 시작 부분을 자세히 살펴보겠습니다.

    using GodotEngine;

    public class Spikeball : RigidBody2D {

    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

경험상 모든 키워드와 키워드가 아닌 모든 문자에는 의미가 있습니다. 그렇지 않다면 거기에 있어서는 안 됩니다.
로 시작한다
using GodotEngine;
이는 이 코드가 "GodotEngine" 패키지에서 가져온 기능을 참조한다는 것을 의미합니다. Godot의 모든 스크립트는 해당 기능을 참조하고 가져올 다른 패키지가 없기 때문에 해당 줄을 추가하는 것은 무의미하므로 제거하겠습니다.

다음으로 우리는
public class Spikeball : RigidBody2D {
GDScript의 모든 것이 공개되어 있는데 왜 언급합니까?
class Spikeball : RigidBody2D {
모든 GDScript 파일에는 스크립트와 이름이 같은 클래스가 포함되어 있습니다. 그건 다른 언어처럼 그냥 코딩 규약이 아니라 그렇게 정의되어 있는데, 클래스 이름을 반복하는 게 무슨 의미가 있겠습니까?
: RigidBody2D {
이제 : 이 줄에서 유일하게 의미 있는 "키워드"이므로 조금 더 읽기 쉬운 것으로 교체해 보겠습니다.
extends RigidBody2D {
약간의 경험이 있는 코더는 들여쓰기를 사용하여 코드의 다른 영역을 표시합니다. 즉, 클래스 내부의 코드는 주변 중괄호와 들여쓰기로 식별할 수 있습니다. 이것이 Python 개발자가 들여쓰기를 필수로 만들고 이제 중복되는 중괄호를 제거하기로 결정한 이유입니다.
우리의 경우 모든 스크립트 파일이 하나의 클래스로 정의되기 때문에 클래스 수준에서는 들여쓰기가 필요하지 않습니다(들여쓰기로 표시된 하위 클래스를 사용하지 않는 한).
extends RigidBody2D

다음으로 수출 라인이 있습니다.

    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

[] 문자는 같은 이름의 클래스에 정의된 속성을 표시합니다. 이는 Godot에는 존재하지 않는 메커니즘이므로 대신 단순히 키워드를 사용합니다.

    export public float damage = 60f;
    export public float rotationSpeed = 2f;

다시 말하지만 모든 것이 공개됩니다.

    export float damage = 60f;
    export float rotationSpeed = 2f;

데이터 유형을 지정할 필요가 없습니다.

    export var damage = 60f;
    export var rotationSpeed = 2f;

인스펙터는 어떤 위젯을 보여줄지 알아야 하기 때문에 내보내기는 예외입니다. 따라서 유형은 실제로 내보내기 키워드에 대한 추가 정보일 뿐입니다.

    export(float) var damage = 60f;
    export(float) var rotationSpeed = 2f;

따라서 이 C# 코드의 차이점은

    using GodotEngine;

    public class Spikeball : RigidBody2D {

    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

그리고 이 GDScript 코드

extends RigidBody2D

export(float) var damage = 60f;
export(float) var rotationSpeed = 2f;

Godot에 있는 옵션을 설명하지 않는 모든 문자와 키워드가 제거되었다는 것입니다.
나는 이제 사람들이 GDScript에 대해 좋아하는 것이 매우 분명하다고 가정합니다. 의미가 없거나 중복되는 내용을 강제로 입력하지 않아도 되며 구문은 Godot에 없는 옵션이나 언어 기능을 암시하는 대신 사용자가 가진 옵션을 반영합니다.

C++/C#/TorqueScript 배경지식에서 Godot의 패러다임이 익숙해지려면 며칠이 걸리지만 단순함이 "클릭"하면 입력할 수 있는 만큼 빠르게 아이디어에서 실행으로 이동할 수 있습니다.

@vnen :

이러한 주장은 다른 많은 언어와 엔진에도 적용됩니다.

공평하게도, 나는 숨을 죽이고 있지도 않고 수용될 것이라고 기대하지도 않습니다. 이것은 내 영역이 아닙니다.

지금 Unity 사용자를 위한 Godot 가이드를 만들려고 합니다.

제가 도와드릴까요? 저는 Unity를 몇 년 동안 사용해 왔으며 다른 어떤 엔진과 비교해도 이 점을 아주 잘 알고 있습니다.

@Warlaan :

나는 이제 사람들이 GDScript에 대해 좋아하는 것이 매우 분명하다고 가정합니다. 의미가 없거나 중복되는 내용을 강제로 입력하지 않아도 되며 구문은 Godot에 없는 옵션이나 언어 기능을 암시하는 대신 사용자가 가진 옵션을 반영합니다.

이는 완벽하게 이해가 됩니다. 스크립트를 입력하는 데 필요한 키 입력의 양을 줄이는 Perl의 이념과도 일맥상통합니다. 그러나 실제로 해당 예제에서 실제로 입력할 키 입력의 양은 동일합니다. VS의 자동 완성을 최대로 사용하고 스페이스바를 누르거나 열기 전에 키워드, 유형 또는 변수 이름에 대해 3자 이상을 입력해야 하는 경우는 거의 없습니다. 브래킷을 완성합니다. 그리고 거기에 있는 실제 추가 '불필요한' 문자에 관해서는 거기에 있는 것을 선호합니다.
Godot에는 자동 완성 기능이 있지만 느리고 시간이 너무 오래 걸리기 때문에 대부분의 시간에 나타나기도 전에 전체 코드 라인을 입력하곤 했습니다.

따라서 사람들이 GDScript에 대해 좋아하는 것은 사용 가능한 정확한 기능을 제공하고 키 입력을 줄이는 것 외에는 가능한 한 최소화한다는 것입니다.

이해는 하지만 더 이상 사용하는 데 도움이 되지는 않습니다. GDScript를 입력하는 것이 불편할 뿐이지만 완벽하게 읽을 수는 있습니다. 배우려고 애쓰는 게 아니라 그냥 싫은 것 같아요.
Space Invaders 복제품을 만드는 데 몇 시간이 더 걸릴 수 있습니다. 저보다 GDScript를 더 좋아하고 싶습니다.

보적:
Godot에서 C++만 사용할 수 있나요? 솔직히 저는 C++를 배우고 GDScript보다 그것을 사용하는 것을 선호한다고 생각합니다.

제가 도와드릴까요? 저는 Unity를 몇 년 동안 사용해 왔으며 다른 어떤 엔진과 비교해도 이 점을 아주 잘 알고 있습니다.

@StraToN 이 페이스북 그룹에 이런 도움을 요청하는 글을 올렸습니다. 그에게 연락하십시오(다른 사람도 그 일을 하고 있는지 확실하지 않습니다).

@neikeq 감사합니다. 완료되었습니다!

@Warlaan 나는 당신의 코드 비교를 이해하지만 나에게 그것은 주로 C#에 더 많은 기능이 있고 따라서 더 장황하다는 것을 증명합니다.

많은 클래스와 이름 충돌을 피하기 위한 네임스페이스가 있기 때문에 using 가 필요합니다(내 게임 프로젝트에서 이미 발생했습니다).
시간이 지남에 따라 코더 오류를 방지하기 위한 캡슐화 개념이 있기 때문에 public 가 필요합니다.
다양한 프로젝트 요구 사항에 맞게 기본 제공 주석을 확장하고 도구를 개선할 수 있기 때문에 [SomeClass] 가 있습니다.
중괄호에 관해서는 ... 범위를 정의하는 것 외에는 이점이 없습니다.

이러한 기능은 이유가 있습니다. 그 중 확장성이라고 하겠습니다. GDScript의 모든 코드베이스로 거대한 크로스 플랫폼 3D 게임을 개발하시겠습니까? 글쎄, 당신은 할 수 있습니다. 그러나 내가 나열한 장점 때문에 많은 사용자가 C++, C# 또는 Java를 선호할 것입니다.

그러나 동시에 Godot와 함께 개발 중인 "거대한" 게임 프로젝트가 없으므로 예가 많지 않습니다.p
또한 C#에서 몇 가지 나쁜 기능을 볼 수 있습니다(경고: 개인적인 의견 미리 보기).

정적 변수를 가질 수 있습니다. 이것은 잘못된 것이므로 전역 상태/싱글톤에서 많은 오류가 발생합니다. 자동 로드와 달리 장면 범위에 구속되지 않습니다.
if() 문의 while() 끝에 세미콜론을 잘못 입력하여 쓸모없고 찾기 어렵게 만들 수 있습니다.
오버코딩할 수 있습니다. 잘못된 방식으로 사용하면 C# 코드가 매우 복잡해질 수 있고 다른 간단한 코드도 마찬가지라는 데 동의합니다. 그러나 그것은 사람/경험에 달려 있습니다.

오. preload() 언급하지 않았습니다. 컴파일러 트릭에 의존하지 않는 한 이것은 C#/Java로 만들 수 없습니다.

누군가 이미 Mono 모듈을 실험하기 시작했습니까?

C# 개발자로서 저의 가장 겸손한 의견을 여기에 덧붙이자면...

나는 Godot에 C#을 추가하는 것이 많은 가치가 있다고 생각하지 않습니다. 왜냐하면 당신은 여전히 ​​Godot의 클래스를 배워야만 할 수 있고 C#을 추가함으로써 얻을 수 있는 유일한 것은 더 친숙한 (많은 사람들에게) C 스타일이기 때문입니다 구문 및 정적 입력.
구문 문제는 논쟁의 여지가 있습니다. Python은 초보자가 배우기 쉽다는 평판이 있으며 GDScript는 Python과 매우 유사하기 때문에 마찬가지입니다.
어느 정도 숙련된 프로그래머는 어쨌든 해당 구문을 선택하는 데 문제가 없어야 합니다. 일관성이 있고 보다 자유로운 형식의 C 스타일 구문보다 함정이 상당히 적습니다.

이제 정적 타이핑은 성능에 도움이 되는 것 외에도 어떤 면에서 개발 속도에도 도움이 될 수 있습니다. 자동 완성 도구는 함수/메서드가 예상하고 반환하는 유형이 무엇인지 알려주는 것을 좋아하지만 유형 힌트만으로도 이를 달성할 수 있습니다.
이것은 GDScript에 추가할 수 있지만 추가 언어가 필요하지 않습니다.

또한 C#을 구현하는 것은 쉽지 않을 것이며 엔진을 현재 상태로 가져오는 데만도 GDScript 대신 C#이 맨 위에 있는 상태로 만드는 데 상당한 시간과 노력이 소요될 것입니다.

일부 사람들이 잘못된 길을 택할 것임을 알고 있는 마무리 논평으로 다음과 같이 말씀드리고 싶습니다.

내가 관찰한 바에 따르면 우리 기술에 있어야 할 만큼 확고하지 않은 일부 프로그래머는 가능한 모든 힘을 다해 알고 있는 내용에 집착하는 경향이 있습니다.
이 현상은 내 편견일 수도 있지만 C# 개발자 커뮤니티에서 특히 널리 퍼져 있는 것으로 보입니다.
이 글을 읽고 있는 사람들 중 자신이 그 설명에 적합할 것이라고 생각하는 사람이 있다면 이 익숙한 상자에서 벗어나 새로운 것을 배우기 시작하는 것이 좋습니다. 그 새로운 것을 이해하면 이미 알고 있던 것에 대한 이해도 높아졌을 것입니다. 그만한 가치가 있습니다.

정적 유형을 사랑하고 싶지만 그런 일이 발생한다면 제네릭을 어떻게 처리하시겠습니까? 해당 인스턴스에서 단순히 동적 유형을 사용하시겠습니까, 아니면 제약 조건을 사용할 수 있기를 원하십니까? - 예를 들어 int와 bool만 허용합니다.

네임스페이스는 매우 환영할 일입니다. GDScript에 네임스페이스가 이미 존재하지 않는다는 사실에 놀랐습니다.

메소드에 콜론 대신 중괄호를 사용하는 옵션도 멋질 것입니다. 필요하지 않다는 것을 알고 있지만 거기에 두는 것이 좋습니다. 마치 마침표 없이 책을 읽는 것과 같으며 거슬립니다.

유형 힌트는 코드 완성이 완전히 작동하지 못하게 하는 간격을 좁힐 수 있습니다. 예전에 Lua를 사용하여 프로젝트를 진행한 적이 있는데, Lua에서도 이것을 원했습니다. 연구는 나를 여기로 이끌었습니다. https://github.com/andremm/typedlua/blob/master/examples/http-digest/http-digest.tl#L48
타입 힌팅을 너무 깊이 파고들면 함수 매개변수가 될 수 있습니다. xD
하지만 절충안이 있어야 한다고 생각합니다. TypeScript 또는 Hax가 어떻게 작동하는지 확인하십시오(둘 다 변형 및 유형 혼합 허용). 또한 유형 힌트는 이미 Godot에 있습니다. export()에서만 사용됩니다 :)

누군가 이미 Mono 모듈을 실험하기 시작했습니까?
@Zylann

GodotSharp 를 확인하십시오. 저장소의 현재 상태는 아직 사용할 수 없습니다. 내 로컬 리포지토리에서는 참조가 아직 작동하지 않기 때문에 GDScript에서 수행되는 적과 총알 인스턴싱을 제외하고 2d/platformer 데모를 C#으로 변환하기에 충분한 항목(Vector2 및 Matrix32만 기본 유형으로 사용 가능)을 구현했습니다.
이것은 플레이어 클래스의 예입니다: https://github.com/neikeq/GodotSharp/blob/master/platformer_cs/Player.cs

@Pikl

보적:
Godot에서 C++만 사용할 수 있나요? 솔직히 저는 C++를 배우고 GDScript보다 그것을 사용하는 것을 선호한다고 생각합니다.

네, 가능합니다. 하지만 현재로서는 그렇게 쉽거나 편리하지 않으며 Godot를 처음부터 다시 컴파일해야 합니다. C++가 일류 시민이 되는 데 관심이 있다면 #3936에 대한 지원을 보여 주어 많은 작업 없이 GDScript와 함께(또는 독점적으로) 사용할 수 있도록 하십시오.

@Zylann Pikl은 Unity 개발자가 더 쉽게 읽을 수 있도록 GDScript의 구문을 C#과 유사하게 변경하는 것에 대해 질문했습니다. 그게 내가 댓글을 달았던 것입니다. 예, C#에는 더 많은 기능이 있습니다. 이것이 내가 제거한 키워드와 문자가 처음에 거기에 있었던 유일한 이유입니다. 그리고 그것이 바로 C# 코드처럼 보이는 GDScript 코드를 갖기 위해 추가하는 것이 단순히 불필요한 것이 아니라 잘못된 것입니다. GDScript에 없는 언어 기능을 암시하는 구문을 사용하기 때문입니다.

@Pikl 키 입력 의 양이 아니라 선택의 양과 추가 문자의 의미에 관한 것입니다. GDScript에는 추가 키워드를 정당화할 수 있는 일부 기능이 없습니다. 예를 들어 모든 변수, 클래스 및 함수는 C#의 기본 가시성 수정자가 public이 아니기 때문에 "public" 키워드가 앞에 와야 합니다(네임스페이스 제외 - 사용 사례에 따라 변경됨... Microsoft가 다음과 같이 결정한 또 다른 상황 KISS는 80년대의 밴드일 뿐이고 GDScript에서는 모든 것이 공개되어 있기 때문입니다.

그렇다면 모든 기능을 갖춘 C#을 추가하지 않으시겠습니까?
Zylann이 이미 언급했듯이 Godot에 C#을 추가하는 효과는 예측하기가 그렇게 간단하지 않습니다. 아직 하지 않았다면 이 스레드(https://github.com/godotengine/godot/issues/5081#issuecomment-225226235)에서 제 긴 게시물을 읽어주시면 감사하겠습니다. 개발자로서 나는 항상 더 강력한 언어를 요구했을 것입니다. 여가 시간에 나는 현재 첫 번째 게시물에서 paper-pauper가 언급했기 때문에 Kotlin을 보고 있습니다.
하지만 프로그래밍 언어가 게임 개발자의 결과와 행동에 미치는 영향을 살펴볼 기회를 갖게 되면서 강력한 언어보다 적절한 언어를 선택하는 것이 얼마나 중요한지 깨달았습니다.
링크된 게시물에서 설명했듯이 C#은 프로그래머를

• 에셋 스토어를 위한 자료 작성
• 튜토리얼 작성
• 버그를 수정합니다.

제 경험상 Unity에는 게임플레이 프로그래밍 문화가 많지 않습니다. 어떤 종류의 문제가 발생하면 이를 해결하기 위해 패턴이나 사전 구축된 자산을 찾기 시작합니다. 실제로 프로젝트에 대해 알기도 전에 패턴을 선택하는 사람들이 상당히 많으며, 그런 종류의 정신적 융통성은 게임 플레이 결과에 영향을 미칩니다.

그리고 그것은 제가 가장 좋아하는 반론입니다. 첫 번째 포스트에 다른 좋은 논거가 몇 개 더 있었습니다. ;-)

JVM의 문제점은 너무 무겁다는 것입니다. Avian 을 본 사람이 있습니까? Java 세계와 얼마나 호환됩니까?

@neikeq 그렇다고 해서 성능이 더 나쁜 것은 아닙니다. AFAIK JVM은 CLR보다 성능이 더 좋고 게임 개발에 훨씬 더 적합한 가비지 컬렉터(Garbage Collector)도 있습니다. 또한 Windows, Mac 또는 GNU/Linux에 관계없이 대부분의 컴퓨터에 설치됩니다.

또한 고품질 FLOSS 라이브러리가 더 풍부하고 일부 사람들이 말하는 것과 상관없이 더 나은 크로스 플랫폼 지원을 제공합니다.

나는 둘 사이에서 JVM이 게임 개발에 분명히 더 낫다고 말하고 싶습니다(그러나 나는 JVM과 CLR을 모두 동일하게 피하고 싶습니다).

Avian은 흥미롭게 보입니다. 경험이 없어서 질문에 답할 수 없고, 호환성 문제가 Unity의 Mono 버전만큼 문제가 될 수 있어 걱정됩니다. 제공된 .NET 버전 중 하나에 대한 것을 찾을 수 있습니다.

그러나 빠른 처리 시간이 필요하고 코드 품질(예: 게임 잼 또는 새로운 백엔드 아이디어의 신속한 프로토타이핑)을 희생할 수 있는 경우 GDScript 및 C++ 외에 추가 옵션으로 경량 Java 구현을 사용하는 것이 좋습니다.

@neikeq Avian은 C++ 프로젝트에 자바 스크립팅을 제공하기 위해 만들어졌기 때문에 정말 좋은 후보입니다. 매우 작을 수 있습니다(제 기억이 맞다면 100kb 정도). iOS 포트를 출시하기 위해 Avian을 사용하는 일부 libGDX 게임에 대해 들었습니다... jMonkey 엔진은 iOS에서도 Avian을 사용하고 있습니다. 일반적으로 Avian은 일반적으로 Sun/oracle 클래스와 같은 JVM과 함께 제공되는 전체 패키징 없이 제공됩니다. 그러나 '원래' 자바 클래스는 게임에 전혀 적합하지 않기 때문에 문제가 아니라고 생각합니다. 이것이 libGDX와 같은 라이브러리가 벡터 또는 데이터 구조에 대한 자체 구현을 제공하는 이유입니다. 해당 클래스도 다시 구현해야 합니다. (그러나 원래 Java 클래스의 다양한 부분을 포함하는 것은 쉽지만 포함할수록 Avian은 더 커질 것입니다)

@paper-pauper 나는 그것이 게임과 함께 번들로 제공될 것이라고 가정하고 크기가 무겁다는 것을 의미했습니다. 하지만 말씀하신 대로 대부분의 컴퓨터에 설치되어 있고 libGDX와 같은 프레임워크의 인기를 고려할 때 최상의 옵션이 될 수 있습니다.
GDScript의 대안으로 C++에 대한 내 문제는 구문이 끔찍하다는 것입니다. 생산성 킬러입니다. 엔진과 모듈 개발에는 괜찮지만, 나는 그것으로 전체 게임을 작성하지는 않을 것입니다. 그렇긴 하지만, 저는 #3936에 찬성하고 Unreal이 하는 것과 같은 것을 갖고 있지만 그것을 대안적인 "스크립팅" 언어로 보지는 않을 것입니다.

@kubecz3k 다른 JVM 언어를 지원합니까? 예: 코틀린

@neikeq 예, Java 바이트 코드와 완벽하게 호환되므로 모든 jvm 지원 언어(kotlin, scala, jpython 등)를 지원합니다.
나는 우리가 avian google 그룹에 몇 가지 질문을 할 수 있다고 생각합니다: https://groups.google.com/forum/#!forum/avian
꽤 활동적인 것 같다

+1은 C++를 대체 스크립팅 언어로 보지 않는 것입니다. 내가 전에 말했듯이 Godot는 두 영역에서 일종의 "meh"인 하나의 언어를 갖는 것과 대조적으로 스크립팅에 최적화된 하나의 언어와 백엔드 개발을 위한 하나의 언어를 갖고 있다는 것은 좋은 일입니다.

동적 lib 지원과 더 빠른 C++ 개발이 내가 보고 싶은 것이 아니라는 말은 아닙니다.

그러나 Avian에 대해 지나치게 열광하지 않기 위해 libGDX가 ios 포트에 Avian을 사용하지 않는 이유를 설명하는 libGDX의 주요 개발자의 블로그 게시물입니다. http://www.badlogicgames.com/wordpress/?p=3925 (조류 부분까지 아래로 스크롤)
저는 jvm 프로그래머/해커가 아닙니다(하지만 저자는 RoboVm(Microsoft에서 구매하고 폐쇄한 또 다른 jvm)에서도 작업하고 있었기 때문에). 그래서 이것이 얼마나 많은 것이 실제로 Avian이 스크립팅 언어로만 사용되는 상황(코어 엔진에 전원을 공급하지 않음)

여러분 대부분은 아마도 저보다 더 많은 경험을 가진 프로그래머일 것입니다. 그러나 제 2센트가 있습니다. 1년 전 저는 C#을 응원했습니다. 하지만 GDScript 구문을 매우 빨리 배웠습니다. 하루가 끝나면 여전히 API를 배워야 하고 아마도 배우는 데 가장 시간이 많이 걸리는 부분일 것입니다. 예, C#이 필요하지 않습니다. @Warlaan 은 C#에 대해 좋은 이유를 많이 제시했습니다. C#을 구현하는 데에도 많은 시간이 걸립니다. 그것은 또한 더 많은 버그를 의미합니다. 예, 코드 기반에 기여하는 훌륭한 커뮤니티가 있지만 여전히 @reduz 가 하나만 있습니다. C#을 구현하는 데 필요한 시간은 우리가 정말로 필요한 기능에 투자해야 한다고 생각합니다. 얼마나 많은 Godot 개발자들이 GDScript에 만족합니까? 예, 더 빠를 수 있지만 다른 문제는 없습니다. 나는 그다지 좋지 않은 두 개의 스크립트 언어보다 하나의 멋진 스크립팅 언어를 갖고 싶습니다. Unity조차도 오래된 Mono에 뒤쳐져 있습니다.

내가 갖고 싶은 것은 GDScript에서 정적 타이핑입니다. C#이 아닌 스크립팅 언어로서의 C++가 아닙니다. GDScript에 집중해서 지금보다 더 좋게 만들어 봅시다.

내가 14년 동안 개발을 주도한 엔진이 Visual Scripting 스레드에서 언급되었기 때문에 우리 고유의 C#과 같은 언어로 완전히 작성된 새 엔진을 개발할 때 여기에 2센트를 추가해야겠다고 생각했습니다.

우리는 우리가 지원하는 모든 플랫폼(XBox/PS/PC/Wii/ 등). 우리는 필요에 따라 성능을 조정할 수 있도록 세대별 가비지 수집기를 작성했습니다. 이 방법을 사용하면 엔진 전체에서 사용되므로 테스트 및 프로파일링이 잘 이루어집니다. 그리고 C++로 크로스 컴파일했기 때문에 필요에 따라 시스템 API를 호출하거나 SIMD(플랫폼 특정 작업)를 포함할 수 있는 '네이티브' 함수로 C++ 코드를 쉽게 작성할 수 있었습니다.

Unity가 많은 C++ 코드를 Mono와 병합해야 하는 것이 얼마나 실망스러웠을지 정말 상상이 되지 않습니다. 아마도 @GlaDOSik 이 지적한 것처럼 뒤처지는 이유를 설명할 것입니다. 그것은 확실히 우리 중 누구도 하는 데 관심이 있는 것이 아니었습니다.

우리의 주요 목표는 엔진, 편집기 및 도구 간에 사용되는 언어와 게임플레이 코드를 단일 언어로 통합하는 것이었습니다. 이전에는 엔진과 도구가 완전히 C++이었고 시각적인 스크립팅 언어(적어도 C 코드처럼 보임)가 레벨 디자이너가 선호하는 모든 게임 플레이에 사용되었지만 대다수를 작성하는 게임 플레이 프로그래머 대다수를 짜증나게 했습니다. 코드의. 또한 게임플레이 개발에 필요할 수 있는 것(예: 상태 머신 지원)에 맞게 언어를 조정할 수 있었습니다.

_모든 사람을 기쁘게 할 수는 없습니다._ 스파게티 청사진/기타 노드 기반 "코드"의 지저분한 엉망을 디버깅하는 작업을 하거나 누군가를 돕기 위해 노력해야 한다면 보복으로 제 눈을 도려내고 싶습니다. C++ 코드를 읽으려는 아티스트가 동일한 작업을 수행할 것으로 예상합니다. 당신이 할 수 있는 일은 _최고의_ 솔루션이 무엇인지 논쟁하고 모든 사람을 기쁘게 하기 위해 더 많은 시간을 _많은_ 낭비하는 것입니다. 어떤 시점에서는 적합한 사람들을 위해 할 수 있는 가장 생산적인 도구를 만드는 데 집중해야 하며 때로는 소수의 사람들이 새로운 것을 배워야 할 수도 있습니다.

"C++가 아니면 느리다"가 종종 만트라인 것 같지만, 요즘 _출시되는_ 게임의 대부분은 게임 플레이 코드를 위해 C++가 아닌 다른 것으로 작성된다고 말하고 싶습니다. 나는 실제로 GDScript에서 특별히 성능 문제를 게시한 사람을 본 적이 없지만 느린 것이 무엇인지 듣고 싶습니다.

GDScript에 대한 내 소개는 다음과 같습니다.

• 어머나 파이썬 같네!? 그건 말이지, 공백은 중요하지 않아야 합니다!
• 흠, "소문자" 스타일의 팬이 아닙니다(모든 사람을 만족시킬 수는 없습니다).
• 글쎄요, 이것은 실제로 좀 멋지고 잘 생각한 것입니다.
• 네, 이것은 에디터와 훌륭하게 통합되어 있습니다. 게임플레이 코드와 일부 에디터 플러그인에서 매우 생산적이라는 것을 확실히 알 수 있었습니다!

GDScript에 많은 노력과 시간을 들인 것 같고, 딱 맞는 도구인 것 같습니다. 그래서 정말 열심히 만든 사람들에게 박수를 보내고 싶었습니다!

@Ziflin 안녕하세요! 여기에서 만나서 반가워요. Vicious는 우리가 전문적으로 사용한 최초의 게임 엔진 중 하나였습니다(하지만 실제로 사용하는 것보다 해킹하고 문제를 해결하기 위해 @punto-에 고용되었지만).

비주얼 스크립팅 언어는 정말 악몽이었지만 소스 코드는 정말 잘 수행되고 깨끗하며 조직되었습니다. Torque와 작업한 후에는 행복했습니다. 나는 그것으로 일하면서 많은 것을 배웠다. Sony는 10년 전에 모두가 여기에서 그것을 사용했기 때문에 라틴 아메리카에서 그것을 판매하는 데 훌륭한 일을 했습니다.

작업하면서 가장 놀라운 순간은 실수로 언어가 나열된 코드 조각을 우연히 발견했는데 "포르투갈어가 지원되지 않습니다"라는 댓글이 있었던 것 같습니다.

우리는 그것에 대해 정말 열심히 웃고 농담을 하고 있었고, 게임 제작자(우리 뒤에 있었고 우리는 그를 눈치채지 못한)가 두려움에 떨며 말했습니다: "잠깐만요? 이제 남은 것은 게임을 포르투갈어로 번역하는 것뿐입니다. , 농담이지?"

그러나 우리는 포르투갈어로 중국어를 사용했고 모두 잘 작동했고 게임이 배송되었습니다. 아직 개발 중이라는 사실을 알게 되어 기쁩니다!

( @Ziflin에서 인용) GDScript 에서 특별히 성능 문제를 게시한 사람을 실제로 본 적이 없지만 느린 것이 무엇인지 듣고 싶습니다.

저는 개인적으로 이 프로젝트에서 CPU/Gdscript 병목 현상에 도달했습니다. http://godotdevelopers.org/index.php?topic=15519.0

GDscript에서 기본적인 AI와 기본적인 구식 의사 물리학을 작성하여 8대의 자동차 각각을 제어했습니다.
아직 최적화의 여지가 조금 있기 때문에 이 성능 문제에 대해 공개적으로 큰 소리로 울지 않았습니다.
그러나 자동차를 더 추가하고 싶다면 C++용 Gdscript 를 삭제해야 했을 것입니다.

또한 작년에 각 버그(동물)에 대한 기본 AI에 GDscript를 사용하던 다른 프로젝트에서 동일한 CPU/Gdscript 병목 현상이 발생했다고 생각합니다. http://ludumdare.com/compo/ludum-dare-32/? 작업=미리보기&uid=50893
버그(동물)를 추가할수록 성능이 떨어졌습니다.

누군가가 원한다면 내 경험을 공유 할 수 있습니다.

@SuperUserNameMan 계속 진행하십시오. 하지만 내가 열었던 #5049(GDScript 성능에 대해 구체적으로 설명하는) 티켓이 더 적합하다고 생각합니다.

@paper-pauper : 내가 #5049에 기여할 수 있을지 확신이 서지 않습니다. 내가 공유할 수 있는 경험은 내가 도달한 병목 현상의 종류, 특정 증상이 무엇인지, 해결 방법, 최적화 방법, 희생해야 했던 "godot의 디자인 이점"에 대한 것입니다.

@SuperUserNameMan 유형 유추를 통해 JIT를 구현하는 것에 대해서는 아직 많이 생각하지 않았지만 이를 위해 VM은 먼저 정적 입력을 지원해야 합니다.

어떤 AI 코드를 말씀하시는지 듣고 싶습니다.
내 선입견은 단 8개의 엔터티에서 실행할 때 성능 문제를 일으킬 수 있는 모든 코드는 아마도 실제 게임 코드가 아니므로 어쨌든 C++ 클래스에 넣어야 한다는 것이므로 질문하는 것입니다.

@reduz 하하, 확실히 작은 세상이군요! 그리고 예, 시각적 스크립팅 종류는 통제할 수 없게 되었습니다(실제로는 트리거 및 이벤트 논리의 작은 비트를 처리하기 위한 것이었습니다). Vicious는 실제로 올해 초 문을 닫았지만 그곳에서 일하는 것은 매우 즐거웠습니다.

@paper-pauper 말씀하신 다른 주제도 확인해 보겠습니다. 사람들이 이 스레드에 성능 문제를 게시하기 시작하려는 것은 아닙니다.

GDScript가 정적 타이핑을 추가하는 것이라면 IL->C++ 전환으로 인한 추가 오버헤드를 피하고 런타임을 작게 유지하는 C++로 직접 변환하는 옵션을 갖는 것이 더 쉬울 수 있습니다(JIT 컴파일러 등 없음). 그런 다음 GDScript에서 프로토타입을 만들거나 모드를 만들 수 있지만 최종 빌드에 필요할 때 추가 속도를 위해 C++로 자동 변환할 수도 있습니다.

그렇게 하면 사람들이 사용하던 기존 IDE(VC++ 등 & Godot 편집기)도 유지됩니다. 우리는 실제로 VC++를 사용하여 언어를 디버그했으며 컴파일러는 .cpp 파일에 #LINE 지시문을 생성하여 원본 코드를 쉽게 단계별로 실행하고 중단점을 설정할 수 있습니다. 따라서 이론상으로는 편집기에서 일반 GDScript를 사용하여 프로토타입을 만들고 디버그할 수 있지만 'GDScript->C++'가 활성화된 빌드 중에도 여전히 C++ IDE/디버거를 사용하고 gdscript 파일에서 중단점/디버그를 설정할 수 있습니다. 우리에게 생성된 C++ 파일은 일시적이었고 코드 생성 문제가 있는 경우에만 파일을 살펴보았습니다.

어쨌든, 그냥 생각. 이제 멋진 스크립팅 언어가 있다는 사실은 확실히 플러스이며 사용자 생성 모드, 빠른 프로토타이핑 및 언어에 새로운 기능 추가와 같은 작업을 가능하게 합니다.

사실 나는 내 성능 문제를 이 스레드에도 게시해야 한다는 사실을 이해하지 못했습니다. 여기에 더 적합했습니다 : https://github.com/SuperUserNameMan/kart-zero/issues/1

@Ziflin 실제로 우리가 다른 문제에서 논의한 것은 Godot의 전체 리플렉션 API를 노출하는 최소 API를 통해 일반 C를 사용하여 Godot 모듈/스크립트를 작성하기 위해 최소 C API를 추가하는 것입니다. 이것은 바인딩 배포와 관련하여 우리가 가지고 있는 일반적인 문제를 해결할 것입니다 Godot를 재컴파일할 필요 없이 다른 종류의 라이브러리로

예를 들어 Steam API, ODBC, SQLite, Kinect 등을 바인딩하려는 사람들이 있습니다. 모두 C++로 모듈을 작성해야 합니다. C API로 이것을 하면 C++에 대해 동적으로 링크하는 문제를 해결합니다(모든 컴파일러 또는 자체 ABI를 가진 컴파일러 버전과 Godot 버전 간에 발생할 수 있는 기호 크기 불일치 문제로 인해 매우 제한적임). C는 그런 문제가 없습니다.

일단 작동하면 GDScript를 C로 컴파일하고 게임이 실행되거나 내보낼 때 런타임에 로드하는 것이 정말 쉬울 것입니다.

@reduz 아 멋지다. 기본적으로 GDScript에 원하는 것을 노출할 수 있는 '플러그인' DLL을 작성할 수 있다는 말입니까? (아니면 제가 잘못 이해한건가요?)

일단 작동하면 GDScript를 C로 컴파일하고 게임이 실행되거나 내보낼 때 런타임에 로드하는 것이 정말 쉬울 것입니다.

몇 가지 새로운 C++ 노드 파생 유형이 포함된 dll을 작성하려는 사람에게 이것이 작동합니까?

그러나 새로운 C++ '모듈' 지원이 DLL과 관련된 일부 문제를 해결하기에 충분해 보인다는 것은 약간 슬픈 일입니다.

Lua나 Ruby와 같은 내장형 스크립팅 언어를 사용하지 않는 이유는 무엇입니까?

@jersten 은 문서를 읽기 때문에 - http://docs.godotengine.org/en/latest/reference/gdscript.html

@Ziflin 예, 하지만 리플렉션을 통해 C API를 사용해야 합니다(리플렉션을 통해 함수 포인터를 요청할 수 있으므로 충분히 빨라야 합니다..). 목표는 대부분 ABI 문제를 피하는 DLL을 로드하는 쉬운 방법과 GDScript를 C로 컴파일하고 .so로 로드하는 간단한 방법을 갖는 것입니다.

나는 가치있는 것을 위해 여기에 2 센트를 넣을 것입니다. 저는 C#으로 코딩한 적이 없고 Java로만 코딩했습니다. 개인적으로 Java를 사용하고 좋아했기 때문에 선호하지만 실제로 Java보다 C#을 지원합니다. C#은 Unity 게임 개발자가 사용하는 것이므로 Godot를 Unity가 만든 이 인디 개발 생태계의 일부로 만들 수 있습니다. 또한 JVM 언어를 원한다면 Java는 좋은 선택이 아닙니다. JVM으로 컴파일되는 다른 더 나은 언어가 있습니다.

나는 사람들이 어쨌든 요점을 놓치고 있다고 생각합니다. C#/Java != 스크립팅 언어. GDScript로 충분합니다. 배우기 쉬운 등

Java(어떤 목적을 위해 JVM을 구축합니까?! 구문?! 작동하려면 특정 버전의 JVM이 필요합니까?!?) 또는 C#(모노를 구현하고 엔진을 클러지하거나 직접 구축하시겠습니까?)과 같은 언어를 추가하면 엔진에 독이 됩니다. .

GDScript에 문제가 있으면 지적해야 합니다. 그런 다음 수정을 시도했습니다.

나는 동의하지 않는다. 나는 C#이 GDScript와 같은 파이썬에 대한 훌륭한 대안을 제공하는 언어와 같은 C에 익숙한 많은 Unity 개발자 또는 개발자를 끌어들일 것이라고 생각합니다. 퍼즐의 마지막 조각은 코딩에 익숙하지 않은 아티스트를 끌어들이는 시각적 스크립팅이 될 것입니다. 이것은 거의 모든 사람을 다루어야 합니다.
또한 당신이 무엇을 코딩하든 간에 여전히 어떤 언어에서나 동일할 Godot의 클래스와 기능을 배워야 합니다.

Unity 개발자가 C#을 알고 있기 때문에 C#을 주장하는 모든 사람들에게 다음을 고려하십시오. 많은 Unity 개발자가 C#으로 프로그래밍하는 방법에 대해 무지합니다. 그들이 아는 것은 C# 바인딩이 있는 Unity API를 사용하는 방법입니다. 그것들을 Godot로 가져오면, 그것이 C#이라 할지라도, 그들은 어쨌든 그들이 무엇을 하고 있는지 알지 못할 것이고 그들에게 다른 프로그래밍 언어를 제공하는 것만큼 길을 잃을 것입니다.

추가 언어를 포함하는 것은 오버헤드가 더 크며 프로젝트에서 유지해야 하는 유지 관리가 더 필요합니다.

나는 이것에 대해 많은 생각을 했고, C#과 같은 것을 지원하는 것에 대한 나의 주요 관심사는 그것을 사용할 대부분의 사람들이 Godot에 오는 Unity 사용자일 것이라는 점입니다. 분명히 우리는 공식 템플릿에 C#을 포함하지 않을 것이며 그들이 모듈을 직접 구축할 것인지 의심스럽습니다...
소수만이 사용할 수 있는 언어를 지원하는 것은 결국 큰 노력이 될 수 있습니다.

오해가 있는 것 같아요:

• 그들은 GDScript를 보고 GDScript가 C#과 동등하다고 생각합니다. C#이 스크립팅 언어가 아니라는 근본적인 요점을 놓치고 있습니다.
• 위의 사실 때문에 누군가가 "Java 또는 C#"이라고 말할 때; 그들이 정말로 요구하는 것은 엔진을 C#/Java로 재작성하거나 해당 언어를 지원하기 위해 일부 바인딩을 추가하는 것입니다(웃음).

나는 후자를 가정하기 때문에; C#/Java에서 디버깅하는 것은 여러 플랫폼에서 악몽입니다. 두 언어 모두 플랫폼에 독립적이지 않기 때문에(inb4는 거의 모든 OS에 런타임이 있습니다); "한 번 작성하고 모든 곳에서 디버그"로 바뀝니다(이것이 Monogame으로 작성된 게임이 Windows에서 먼저 나오고, 개발자가 해당 플랫폼에 대해 디버그해야 하기 때문에 결국 Linux/Mac에서 나오는 이유입니다). 이것이 JVM 업데이트가 애플리케이션을 중단시키는 이유입니다.

이러한 언어에 대한 지원을 추가해도 엔진에 가치가 추가되지 않습니다.

인수가 "moar Unity devs"인 경우; 그런 다음 Unity 개발자를 전환하는 데 도움이 되는 문서를 만들어야 합니다. 레이아웃 차이 등

그렇기 때문에 내가 마지막에 어떤 언어를 사용하든 상관없이 Godot API 클래스와 모든 것을 배우려면 여전히 필요하다고 말한 것입니다. Unity 개발자는 C#을 알고 있기 때문에 인스타 전문가가 될 것 같지 않습니다. 나는 그것이 C#을 지원한다면 Godot에 더 많은 "선함의 기운"이라고 생각합니다. 사람들은 자신이 더 많이 알고 있다고 느끼며 갑자기 Godot에 더 접근하기 쉬워지고 더 이상 무섭지 않게 되었습니다. Godot가 아닌 사용자로부터 Godot에 대한 가장 부정적인 점은 고유한 스크립팅 언어가 있다는 것입니다. Godot 사용자는 GDScript가 재미있고 간단한 언어이기 때문에 BS를 알고 있지만 외부인에게는 그것이 초대되지 않는 것처럼 보일 수 있습니다.
개발자의 관점에서 말할 수는 없지만 개발자가 C#을 구현하여 무언가를 얻을 수 없다면 가치가 있는 것보다 더 많은 노력이 필요할 것입니다. 결국 리드 개발자의 결정이고 그들이 결정한 것은 무엇이든 저는 그것을 따르겠습니다. 좋은 결정이 되리라 확신합니다.

나는 GDScript가 사실상 알려지지 않은 언어이기 때문에 약간 우스꽝스럽다는 점에 동의합니다. 그러나 Lua와 Python이 제거된 이유와 GDScript를 추가할 때의 이점을 읽은 후 나는 덜 걱정했습니다.

관련이 있을 수 있는 또 다른 사항: 이미 C#을 지원하고 Unity, Atomic Game Engine 과 더 유사한 또 다른 MIT 라이선스 엔진이 있습니다. 가능한 한 Unity에 가까운 것이 절실히 필요한 모든 사람들이 시도해 볼 것을 제안합니다.

여기에 2센트만 추가하겠습니다. 나에게 C#의 가장 큰 장점은 성능이며 C++보다 작업하기 쉽습니다. 동적으로 유형이 지정되는 GDScript는 작성이 매우 빠르지만 실행 속도가 매우 빠르지는 않습니다(비록 상당히 많이 최적화될 수 있음에도 불구하고). C++ 모듈은 매우 빠르지만 작업하기에는 다소 어색합니다. C++는 정확히 친숙한 언어가 아니며 이를 사용하기 위해 엔진을 다시 컴파일해야 하는 것은 실제로 최적이 아닙니다. 나에게 C#은 일종의 타협입니다. GDScript보다 훨씬 빠르고 적절한 지원이 있으면 C++ 모듈보다 훨씬 쉽게 작업할 수 있습니다.

즉, C#일 필요는 없습니다. 정적으로 유형이 지정된 컴파일/JIT GDScript 또는 Swift와 같은 다른 것이든 비슷한 효과를 가질 수 있는 다른 모든 것이 제 생각에는 괜찮을 것입니다. C#은 '마케팅 목적'에 가장 적합할 수 있습니다. 유사한 API가 없더라도 다른 엔진/프레임워크의 개발자는 이 API가 더 편할 것입니다. 수정된 GDScript는 구현하기 쉬울 수 있으며 아마도 훨씬 더 잘 통합될 것입니다.

지금은 쓰레드가 매우 길다는 것을 알고 있지만, 혼자서 무언가를 게시하기 전에 위의 모든 게시물을 읽으십시오. C#이 사람들을 끌어들이고 Unity 사용자에게 매우 편리했다는 주장은 수십 번 더 언급되면 더 이상 유효하지 않습니다.

imho C#이 Unity에 적합하고 Godot에 나쁜 이유는 여기 에서 확인 하세요 . imho가 C#을 추가하면 자신의 프로젝트뿐만 아니라 온라인 튜토리얼, 곧 출시될 에셋 스토어 등에서 더러운 코드가 발생하는 이유를 여기에서 확인하세요. 그리고 imho가 왜 여기에 있는지 확인하세요. 사람들이 C#에서 GDScript로 변경할 때 많은 새로운 것을 배워야 한다는 주장은 유효하지 않습니다.

C#이 새로운 사람들을 끌어들일 것이라는 주장에 대한 설명을 추가하겠습니다.
더 많은 사람들이 Godot를 사용하기를 바라는 이유는 무엇입니까? 나는 오픈 소스 프로젝트에 커뮤니티가 필요하다는 것을 완전히 이해합니다.

• 기능 추가
• 버그 수정
• 재사용 가능한 자산 생성
• 새로운 기능을 제안합니다
• 워크플로의 버그 또는 문제를 찾습니다.
• 튜토리얼을 씁니다

그러나 위의 모든 것은 엔진의 핵심 아이디어를 이해하고 감사하는 사람들이 필요합니다. 라이브러리에 불필요한 기능을 추가하는 사람들은 도움이 되지 않으며 이러한 기능으로 인해 어려움을 겪는 프로젝트가 하나 이상 있었고 때로는 프로젝트가 중단되거나 분할되는 지점까지 있었습니다.
Unity는 특히 튜토리얼을 작성하는 사람들이 자신이 하는 일을 제대로 이해하지 못하는데도 어려움을 겪습니다. 이는 대부분 C#의 잘못입니다.

사람들이 GDScript처럼 간단한 언어를 배우려는 의지나 능력조차 없다면, 그들이 커뮤니티에 적극적으로 기여하기 시작하기 전에 Godot의 디자인 철학을 완전히 이해하는 데 시간을 할애할지 여부는 매우 의심스럽습니다. ("적극적인 기여"란 풀 리퀘스트를 보내는 것부터 Facebook에 Godot에 대한 의견을 게시하는 것까지 모든 것을 의미합니다.)

Godot는 상용 엔진이 아닙니다. Unity는 모두 잠재 고객이자 엔진 광고이기 때문에 가능한 한 많은 사람을 끌어들이는 데 관심이 있습니다. Godot를 있는 그대로 인정하는 대규모 사용자 커뮤니티를 갖는 것은 분명 좋겠지만 더 큰 커뮤니티를 수용하기 위해 Godot의 특성 중 일부를 희생하는 것은 의미가 없습니다.

@Warlaan 사람들은 일반적으로 시간 낭비를 원하지 않으며 학습할 때 처음에 프로젝트를 빌드할 때 찾은 코드 조각을 사용합니다. 초보자의 경우 귀하의 요점은 그들이 사용하는 코드 스니펫이 작성되는 언어가 무엇이든 결국 배우게 될 것이기 때문에 약간 관련이 있습니다. 그것이 내가 예제를 보고 배운 방법이고 GD 스크립트를 몰랐지만 배웠기 때문에 이것을 압니다. 문제는 무엇이 최선인지 또는 이것이 튜토리얼 등에 어떻게 영향을 미치거나 복잡하게 할 것인지가 아닙니다. 문제(저에게)는 C#에 더 가깝습니다. 그래서 다른 어떤 언어보다 Godot가 Unity가 속한 이 인디 개발 생태계의 일부가 될 것입니다. 이것은 Unity에 관한 것이 아니라 Godot에 관한 것입니다.

편집: 불필요하게 거친 언어를 제거했습니다 ;-)

@trollworkout 실례는 아니지만 제 요점을 제대로 이해하지 못하셨고 말씀하신 내용을 깊이 생각하지 못한 것 같습니다.

1. 예, 사람들은 시간을 낭비하고 싶어하지 않습니다. GDScript의 전체 사양: 몇 개의 화면. C#을 설명하는 책: 일반적으로 최소 500페이지. 나는 GDScript를 배우는 데 며칠을 보냈고 내가 모르는 단일 기능이 없다는 것을 확신합니다. 저는 전문적으로 그리고 여가 시간에 C#으로 몇 년 동안(Windows Forms, WPF, XNA 및 Unity를 사용하여) 작업했으며 아직 완전히 이해하지 못한 기능을 사용하는 코드 조각을 찾습니다. 시간 낭비가 적기 때문에 C#을 요청하는 것은 실제로 의미가 없습니다.
2. "초보자는 사용하는 코드 조각이 어떤 언어로 작성되든 결국 배우게 될 것입니다." - 1번 항목 참조. 코드 조각에서 C#을 배울 수 있다는 개념은 사실과 거리가 멉니다. 그런 식으로 배울 수 있는 것들은 너무 기본적이어서 다른 언어를 "배우는" 데 며칠 이상 걸리지 않을 것입니다. 당신은 스스로 GDScript를 그렇게 배웠다고 말했습니다.
3. "C#은 Godot를 이 인디 개발 생태계의 일부로 만들 것입니다." 그리고 그것이 의미하는 바는 무엇입니까?
   C#-Godot에서 Unity 코드 스니펫을 사용할 수 있습니까? 아니.
   C#-Godot에서 Unity 자산을 재사용할 수 있습니까? 아니.
   Unity 튜토리얼을 읽고 C#-Godot에 그대로 적용할 수 있습니까? 아니.
   그렇다면 이 "인디 개발 생태계"는 무엇을 말하는 것입니까?

Paper-pauper가 말했듯이 선택할 수 있는 엔진과 라이브러리가 많이 있습니다.
Unity와 같은 구성 요소 시스템을 원하십니까? Atomic Game Engine을 보십시오.
엔진에서 C#을 계속 사용하고 싶지만 구성 요소 시스템을 버리고 싶습니까? CryEngine/Luberyard를 보십시오.
C#을 계속 사용하고 싶지만 엔진을 버리고 싶습니까? 모노게임을 보세요.

Godot에 C#을 추가하는 것이 초보자에게 도움이 된다는 생각은 잘못된 것입니다. 코드 조각을 보고 Godot에서 스크립팅을 배웠다고 스스로 말했기 때문입니다. 그것이 엔진으로 작업하는 방법을 배우는 방법이라면 수천 가지 사용 사례를 위해 설계된 언어보다 엔진이 어떻게 작동하는지 암시적으로 알려주는 언어를 원하지 않습니까?

여기에 2센트만 추가하겠습니다. 나에게 C#의 가장 큰 장점은 성능이며 C++보다 작업하기 쉽습니다. 동적으로 유형이 지정되는 GDScript는 작성이 매우 빠르지만 실행 속도가 매우 빠르지는 않습니다(비록 상당히 많이 최적화될 수 있음에도 불구하고). C++ 모듈은 매우 빠르지만 작업하기에는 다소 어색합니다. C++는 정확히 친숙한 언어가 아니며 이를 사용하기 위해 엔진을 다시 컴파일해야 하는 것은 실제로 최적이 아닙니다. 나에게 C#은 일종의 타협입니다. GDScript보다 훨씬 빠르고 적절한 지원이 있으면 C++ 모듈보다 훨씬 쉽게 작업할 수 있습니다.

언급한 C++에 대해 언급한 모든 문제는 유효하며 #3936을 통해 수정할 수 있습니다. 우리는 이미 이에 대해 여러 번 논의했지만 명확성을 위해 객관적으로 인식할 수 있는 GDScript의 문제는 다음과 같습니다.

1. 타사 라이브러리에 대한 지원 부족
2. 성능 저하

C++로 부분을 작성할 수 있으면 이 두 가지를 쉽게 고칠 수 있습니다. C#(또는 다른 언어)도 이러한 문제를 해결할 수 있지만 런타임이 추가되면 성능이 저하되고 플랫폼 간 지원이 저하되고 많은 추가 작업이 필요합니다(Godot은 이미 C++로 작성됨). 따라서 합리적인 선택은 이미 있는 것(C++)을 사용하여 더 나은 것으로 만들고 물론 GDScript로 이러한 문제를 수정하는 것입니다.

나는 이 스레드를 빨리 읽었고 GDScript to C가 구상되었다는 것을 알았습니다.

이 방법을 선택한 경우 생성된 C를 컴파일하기 위해 편집기에 tcc C 컴파일러 를 포함하는 것을 고려하는 것이 좋습니다. 컴파일 시간이 매우 빠르고 매우 작고 쉽게 포함할 수 있습니다. 아마도 이것이 속도를 높이는 가장 좋은 방법일 것입니다.

TCC는 GNU Lesser General Public License에 따라 배포됩니다.

(원천)

이것은 아마도 Godot에 포함하기에 적합하지 않을 수 있습니다. 또한 더 이상 유지되지 않는 것 같습니다.

@Warlaan 너무 생각할 필요 없어요. 이 시점에서 우리는 이미 10번 정도 같은 말을 했습니다. 내 2센트와 몇 가지 아이디어 외에는 내가 개발자가 아니며 엔진을 잘 알지 못하기 때문에 더 이상 기여할 것이 없습니다. 내가 더 잘 아는 사람들이 말하게 해줄게. 나는 단지 내 지지를 표명하고 싶었고 그게 다야.
주제를 벗어:
그러나 네, 2번 항목에 관해서는, 당신이 당신의 코멘트를 수정해야 한다는 것에 대해 많은 소란을 일으켰습니다. 예를 들어 언어를 배울 수 없다는 말입니까? 나는 당신이 그것을 거부하는 이유 1을 말하는 C#으로 알려진 500페이지 매뉴얼을 읽지 않는 한 사람들이 그것을 배울 수 없다고 가정한다고 생각합니다. 글쎄, 나는 당신이 틀렸다는 살아있는 증거입니다. 내가 어떻게 GDScript를 배웠다고 생각해? API 및 데모 예제와 함께 질문하기. 시작하기 전에 나는 파이썬 지식이 0개였으므로 그것에 관한 모든 것이 꽤 낯설었다는 것을 명심하십시오. 참고로 저는 얼마나 많은 사람들이 libGDX 매뉴얼을 구입하는지, 실제로 얼마나 많은 사람들이 "libGDX에서 X를 수행하는 방법"을 구글에서 검색하는지 궁금합니다. 아마도 Unity에서 에셋 저장소가 그렇게 나쁜 이유일 것입니다. 그리고 그것으로 나는 더 이상 할 말이 없기 때문에 당분간 끝났습니다.

( @Calinou : Bellard는 TCC의 포크가 BSD 또는 MIT가 되는 것을 허용했습니다. 하지만 지난번에 확인했을 때 포크의 개발자는 소스코드를 공개하지 않았습니다. 그래서 Bellard는 Godot 커뮤니티에서도 TCC를 다시 라이선스하도록 허용할 수 있을까요?)

TCC가 컴파일러만큼 GCC나 Clang만큼 좋은지는 잘 모르겠습니다. 그 크기는 많은 아키텍처를 지원하고 상당히 최적화된 코드 생성(더 나은 성능)을 지원합니다.

C를 컴파일하기 위해 GCC 또는 Clang에 선택적으로 의존하는 Godot는 어떻습니까? 그들은 어쨌든 게임을 만드는 대부분의 사람들의 컴퓨터에 설치되며(크기는 실제로 문제가 되지 않음) C로 컴파일하는 다른 언어(예: 치킨 )가 수행하는 방식입니다. 필요할 경우를 대비하여 C++도 지원합니다.

선택적 종속성으로 만들면 GCC나 Clang이 설치되지 않은 사람(배포용 게임을 빌드해야 하는 개발자에게는 이상하지만 어쨌든)은 지금 그대로 GDScript 인터프리터를 사용할 수 있습니다.

TCC를 GDScript용 JIT 로 사용하는 것이 좋습니다. 그래서 가장 중요한 기능은 컴파일 속도였습니다. 그리고 결과는 이미 현재 솔루션보다 훨씬 빠를 수 있다고 생각합니다.

대부분의 사람들은 성능을 위해 C/C++를 원하고 더 쉽고 빠르게 작성하기 위해 Lua/Javascript를 원합니다. 그렇다면 두 가지 장점을 모두 누리지 못하는 이유는 무엇입니까?

님 - http://nim-lang.org/

C처럼 효율적이고 Python처럼 표현력이 뛰어나며 Lisp처럼 유연합니다.

장점:

• C, C++, Obj-C 또는 JS로 컴파일( http://nim-lang.org/docs/backends.html )
• (파이썬/파스칼) ( https://learnxinyminutes.com/docs/nim/ )
• GC 또는 매뉴얼( http://nim-lang.org/docs/gc.html )
• Godot가 아닌 다른 곳에서 사용할 수 있습니다.
• 크로스 플랫폼(windows, linux, osx, mobile)
• C 코드를 Nim으로 변환하는 데 도움
• C 라이브러리 지원
• 조정 가능한 컴파일러
• MIT 라이선스
• 오픈 소스
• 유형 안전

단점:

• 개발자의 컴퓨터에 C/C++ 컴파일러 필요 -> gcc , vcc , llvm_gcc , icc , clang 또는 ucc _(실제로 사기가 아닙니다. 제 생각에는)_
• 작은 커뮤니티
• 아직 1.0이 아닙니다.

Nim의 TODO 목록은 1.0에 가깝습니다.
https://github.com/nim-lang/Nim/blob/devel/todo.txt

paper-pauper가 말했듯이 (개발자의 컴퓨터에 컴파일러가 있는 것에 대해):

그들은 어쨌든 게임을 만들 대부분의 사람들의 기계에 설치됩니다.
https://github.com/godotengine/godot/issues/5081#issuecomment -227706106

https://hookrace.net/blog/what-is-special-about-nim/
https://hookrace.net/blog/what-makes-nim-practical/

https://github.com/nim-lang/Nim/wiki/Nim-for-C-programmers
https://github.com/nim-lang/Nim/wiki/Nim-for-Python-Programmers

내가 가장 좋아하는 솔루션은 아니지만 그 길을 가야 한다면 Nim 대신 Haxe( haxe.org )를 사용하는 것이 좋습니다.

나는 Haxe의 라이선스에 대해 논평할 수 없지만(컴파일러 자체는 "GPLv2+"를 사용하고 있으며 표준 라이브러리는 MIT를 사용하고 있음) 다른 모든 요인으로 인해 탁월한 선택이 되었습니다.
Nim이 아직 버전 1.0이 아닌 것과는 대조적으로 테스트된 플랫폼(현재 버전 3.2.1)이지만, 나에게 훨씬 더 중요한 것은 구문이 잘 알려진 다른 언어에 훨씬 가깝다는 것입니다. Nim 예제를 읽으면 해당 언어 뒤에 있는 개발자가 비정상적이거나 추악한 솔루션을 찾으려고 노력한 것 같습니다.

그러나 내가 언급했듯이 이것은 내가 가장 좋아하는 솔루션이 아니며 그 이유는 다음과 같습니다.
Nim이나 Hax와 같은 중간 언어에는 많은 "의미론적 종속성"이 있습니다. 존재해야 하는 라이브러리나 실행 파일에 대한 종속성을 의미하는 것이 아니라 다른 언어와 관련되어 있다는 의미입니다. 언어는 더 이상 도구가 아니라 문화입니다. 그리고 그것들을 도구로만 볼지라도 그것들은 구축된 다른 핵심 영역을 가지고 있습니다. 예를 들어 "echo" 명령이 표준 입력에 입력될 때 표준 출력에 텍스트를 인쇄한다는 것은 완전히 의미가 있습니다. 배치 스크립트에서 동일한 명령을 사용하는 것은 결과적일 뿐입니다. 그 논리에 따르면 PHP가 동일한 명령을 사용한다는 것을 이해할 수 있습니다. 기본적으로 다른 모든 범용 언어에는 이름에 "write" 또는 "print"가 포함된 메서드가 있기 때문에 Nim과 같은 범용 언어에서 사용하는 것은 의미가 없습니다.
Nim이 여전히 해당 명령의 이름으로 "echo"를 사용하는 이유를 모르겠습니다. 그러나 이것은 Hax에서 많이 관찰할 수 있는 종류이며 첫 번째 릴리스에 아직 없다면 향후 Nim에서 기대할 수 있습니다. . 예를 들어 Haxe의 표준 라이브러리에는 substr(int, int) 메서드와 substring(int, int) 메서드가 모두 포함되어 있습니다. 둘 중 하나는 첫 번째 인덱스에서 두 번째 인덱스까지의 부분 문자열을 반환하고, 다른 하나는 두 번째 인수의 길이와 함께 첫 번째 인덱스의 부분 문자열을 반환합니다. 둘 다 존재하는 이유는 언어가 다른 종류의 언어를 대체하는 데 사용할 수 있기 때문에 다른 플랫폼에서 온 사용자가 있고 해당 오픈 소스 라이브러리에 들어갈 항목과 그렇지 않은 항목을 결정하는 데 매우 강한 사람이 없는 한 당신은 쉽게 코딩 스타일의 혼합으로 끝날 것입니다.

올바른 작업에 적합한 도구를 선택하는 것이 매우 중요합니다. Haxe(또는 C#)와 같은 언어는 모두에게 적합한 하나의 언어를 제공하려고 하므로 불행히도 이렇게 보이는 "단 하나의 도구"를 사용하게 되는 경우가 많습니다.

나는 잠시 Godot와 함께 일한 후에 내 2센트를 추가하고 싶습니다.
내가 보고 싶은 것(또한 제한된 성공과 함께...)을 보고 싶은 것은 Godot에서 일류 언어로서의 C++입니다.
C++로 계산량이 많은 로직(충돌 해결, 물리학, 변환 및 AI)을 작성하고 GDScript(트리거, 조건, 애니메이션 및 사운드)를 사용하여 노드를 스크립팅합니다.

GDScript는 배우기 매우 쉽기 때문에 Godot는 Unity보다 Gamemaker에 조금 더 가깝습니다.
그러나 3개의 작은 게임을 작성하고 많은 데모를 가지고 놀고 난 후에 GDScript는 아주 기본적인 게임 이외의 어떤 것에도 부족하다고 말해야 합니다.

코드 파일이 너무 길어지고 코드 편집기에는 범위 축소, 영역 축소, 현재 범위의 시작/끝으로 점프와 같은 다른 IDE에서 볼 수 있는 유용한 기능이 많이 부족합니다.

GDScript는 또한 다음과 같은 절차적 언어의 기본 기능이 많이 부족합니다. 적절한 _ for _ 루프, 적절한 _ do...while _ 루프(_ while _ 루프 지원), _ switch...case _, _ 삼항 연산자 _ , _ 열거 _.
_ 클래스 장면 관계 인식 기능이 없습니다. _ 미리 빌드되지 않은 경우 "외부" 클래스이므로 미리 로드해야 합니다.

또한 GDScript의 특성상 함수 참조와 템플릿이 없습니다.
눈에 띄는 것은 아니지만 매우 짜증납니다.

눈776; GDscript는 _get_overlapping_bodies()_와 같은 기능만 사용하는 대신 다른 기능(가능한 경우 노드 및 콜백 사용)을 무시하기로 결정한 경우 단순한 게임 이상의 경우에만 사용할 수 없습니다.

그 이유는 콜백과 노드 사용이 하나의 큰 스크립트와 아주 적은 수의 노드로 모든 작업을 수행하는 것보다 훨씬 빠르기 때문입니다. 나무는 더 커지지만 Godot의 씬 인스턴싱 시스템에서는 문제가 되지 않습니다.

예를 들어, 일정한 회전 속도가 필요한 객체는 GDscript를 사용하여 수동으로 회전을 설정하는 대신 애니메이션을 사용할 수 있습니다. 타이밍에 의존하는 항목은 타이머 노드 등을 사용할 수 있습니다. 더 빠른 게임을 가능하게 하는 즉각적이고 직접적인 방법은 선택할 수 있는 노드 유형이 더 많을 것이라고 생각합니다(각각 고유한 콜백 및 연결이 있음).

코드 파일이 너무 길어집니다.

이런 스크립트를 말씀하시는 건가요? https://github.com/Algorithmus/CastlevaniaClone/blob/master/game/players/player.gd
C#이 이것을 방지할 수 있다고 생각하십니까? 개인적으로 나는하지 않습니다. 실제로 게임이 실행될 때까지 노드 경로 오류를 감지할 수 없지만 도구 (예, 사람들이 C#을 의미할 때 종종 VS 암시적) 및 정적 유형으로 인해 이러한 긴 스크립트의 초기에 오류를 리팩토링하고 감지하는 것이 더 쉽습니다. 그러나 그와는 별개로 노드를 잘 설계하고 사용하면 스크립트를 많이 단순화할 수 있습니다.

코드 편집기에는 범위 축소, 영역 축소, 현재 범위의 시작/끝으로 점프와 같은 다른 IDE에서 볼 수 있는 유용한 기능이 많이 부족합니다.

나중에 요청하면 추가할 수 있지만 (https://atom.io/packages/lang-gdscript) 외부 편집기를 문제 없이 사용할 수 있지만 Godot에는 자동 완성 서비스도 있습니다.

실제로 거대한 게임을 만든다면 C++를 사용하여 Godot를 확장하고 싶을 것입니다.
사실, 엔진 재구축 프로세스 때문에 현재로서는 이것이 다소 벅차다고 생각하지만, 거기에는 이유가 있습니다 .

수업 현장 관계 인식이 없습니다.

무슨 뜻이에요? 장면의 루트에 스크립트를 넣을 수 있다는 것을 알고 있습니까? 또한 C# 편집기는 사용되는 장면에 무엇이 있는지 추측할 수 없지만 GDScript는 가능합니다.

또한 GDScript의 특성상 함수 참조와 템플릿이 없습니다.

람다 및 이벤트와 유사한 것을 찾으면 funcref 및 signal 가 있으며 언어가 동적이기 때문에 템플릿은 문제가 아닙니다. 동적 언어는 종종 인터페이스와 제네릭 대신 오리 타이핑을 사용하는 것을 선호합니다. 또한 재사용 가능한 것을 원할 경우 상속보다 합성이 매우 효과적입니다.

GDScript는 또한 절차적 언어의 기본 기능이 많이 부족합니다.

조금 동의합니다. 그들 중 일부는 요청되었지만 문제가 기억나지 않습니다. 검색해야 합니다. 예를 들어 정수 범위 및 컨테이너(float?) 이외의 다른 항목에서 반복할 수 있는 for 를 보고 싶으므로 while 를 사용합니다. 그것은 실제로 약간 성가시지만 너무 심각한 것은 아닙니다.

이런 스크립트를 말씀하시는 건가요? https://github.com/Algorithmus/CastlevaniaClone/blob/master/game/players/player.gd

파일이 길더라도 훨씬 더 나쁜 것을 보았고 코드가 상당히 절차적임에도 불구하고 여전히 꽤 읽을 수 있습니다. 이제 GDScript에 간단한 구문이 더 나은 이유를 드디어 알았습니다. 대부분 if 및 함수 호출인 평균 게임 논리에 가장 적합합니다.

C#으로 작성된 동일한 파일이 읽기 또는 쓰기가 더 쉽거나 성능(어쨌든 C++보다 나쁨) 이외의 실질적인 이점을 제공한다고 주장하는 사람을 보고 싶습니다. 나는 C#이 이런 종류의 스크립팅에 과도하다고 생각하는데, 이는 일부 전문 2D 게임에서 사용되는 스크립팅보다 더 복잡합니다.

조금 동의합니다. 그들 중 일부는 요청되었지만 문제가 기억나지 않습니다. 검색해야 합니다. 예를 들어 정수 범위와 컨테이너(float?) 이외의 다른 항목에서 반복할 수 있는 for를 보고 싶으므로 while을 사용합니다. 그것은 실제로 약간 성가시지만 너무 심각한 것은 아닙니다.

for 부분과 의사 GDScript에서 언급하는 내용의 몇 가지 예에 대해 좀 더 자세히 설명해 주시겠습니까?

@paper-pauper GDScript에 없는 것은 C#과 관련이 없지만, 예를 들어 for i in range(-PI, PI) 는 for i=0, i < size and stuff, ++i 뿐만 아니라 GDScript에서도 작동하지 않습니다. 또한 세 줄의 if를 작성하는 대신 삼항을 작성하고 싶습니다. 그러나 내가 말했듯이 추적기에는 이미 문제가 있으며 GDScript 사용을 중단하지 않을 것입니다 :p

그러나 모든 스크립트가 최대 200줄이고 비교적 잘 설계되어 있더라도 게임에 수천 개의 스크립트가 있는 경우 해당 코드 기반을 유지 관리하고 리팩토링하는 데 문제가 있을 것입니다. 도구 때문에 : C# 인기의 큰 부분은 Visual Studio가 훌륭한 IDE이기 때문입니다. Godot가 적합한 도구(goto 정의, 안정적인 클래스/함수/멤버 이름 변경, 모든 참조 찾기 등)를 통합한다면 거대한 GDScript 코드베이스 작업이 훨씬 쉬워질 것이라고 확신합니다. 더 일반적으로 말하자면, 이것은 내가 Godot에서 보고 싶은 것입니다. BIG 게임에서 어떻게 잘 확장될 수 있는지입니다. 왜냐하면 지금까지 (내 자신의 프로젝트를 포함하여) 어떤 것도 보지 못했기 때문입니다.

for i in range(-PI, PI)

그것은 0으로 나누기에 도달하고 엔트로피를 파괴하기 시작할 때까지 내 머리를 축을 중심으로 회전하게 만듭니다. 어떤 언어도 그런 예측할 수 없는 진술을 구현하지 않기를 바랍니다. 그것은 무엇을합니까? -PI와 PI(예: -3, -2, ..., 2, 3) 또는 PI의 배수(예: -PI와 0) 사이의 정수에 대해 반복하거나 다음과 같은 일부 부두 기본 단계가 있는 부동 소수점에 대해 반복합니까? 0.176 또는 ln(2) 일부 언어 프로그래머가 가장 적절하다고 생각한 것은?

@akien-mga 죄송합니다. 실제로 xD 단계 인수를 추가해야 했지만 여전히 작동하지 않습니다. 여기에 내가 만든 문제가 있습니다. https://github.com/godotengine/godot/issues/4164

나는 Godot가 그리워하는 것이 도구라는 데 동의합니다. 주요 문제는 GDScript의 덕 타이핑(duck-typing) 특성으로, 이것이 무엇인지 알기 어렵게 만들고 "참조 찾기" 또는 "정의로 이동"과 같은 일부 작업을 수행하기 어렵게 만듭니다.

GDScript에 유형 힌트를 추가할 계획이지만, 이는 선택 사항이기 때문에 얼마나 개선할 수 있을지 모르겠습니다. 확실히 코드 완성에 많은 도움이 될 것이며 더 나은 도구에 대한 작업을 쉽게 할 수 있습니다.

@vnen (M)ELPA의 GDScript용 EMACS 모드는 제 책에서 이미 올바른 방향으로 나아가는 단계일 것입니다. :)

오 예, 충분히 웃기게도 실제로 실제로 저를 느리게 만드는 이 두 가지 문제를 거의 잊었습니다.

• 인수는 함수 서명의 일부가 아닙니다. 즉, 함수를 재정의할 수 없습니다.
  실제로 같은 클래스에 function doFoo(a,b,c,d) 및 function doFoo(a,b) 가 있으면 컴파일에 실패합니다. 결국 doFoo4(a,b,c,d) 및 doFoo2(a,b) 로 이름을 바꾸고 스크립트 파일을 리팩토링했습니다.
• 열거형에 대한 지원이 없기 때문에 모든 플래그와 반환 코드는 필요에 따라 int이므로 추측해야 하며 많은 부분이 아직 문서화되지 않았습니다.

추신: 분명히 함수의 이름은 문자 그대로 doFoo 가 아닙니다. ;)

편집: @Ace-Dragon: 다른 엔진은 복잡한 내장 노드/구성 요소 등을 가르쳐주었습니다. 변화할 수 있고 변화할 것이며, 그 과정에서 게임을 깨뜨릴 것입니다. 그렇기 때문에 기본 트리거 콜백(충돌, 값, 타이머) 외에 너무 많이 의존하지 않는 것을 선호합니다.
나는 또한 신호 슬롯 패러다임의 열렬한 팬이 아니므로 가능하면 피하는 경향이 있습니다. 그런 다음 다시 나는 코루틴보다 스레드를 선호합니다. 저를 러다이트라고 부르세요 :)

@Zylann : ~1200 LOC?... pffft 아니요, 실제 거래에 대해 말하는 것입니다... 파일당 20k+ LOC. Unity를 사용하는 RPG 개발자는 이름이 지정되지 않은 상태로 유지되며(저는 그들을 위해 일하지 않습니다) 일상적으로 25k+ loc의 클래스가 있습니다. 그런 다음 다시 모든 기능을 정적으로 만들고 C#을 C인 것처럼 사용합니다.

주제넘어서 죄송합니다.

@eye776 재정의를 허용하는 동적 언어는 생각할 수 없지만(경우에 따라 기본 인수로 속일 수 있음) GDScript에 포함하는 것이 좋습니다.

그리고 엔진에 대한 획기적인 변경은 Godot와 같은 자유 프로그램에서 쉽게 감지되고 되돌릴 수 있으므로 걱정할 필요가 없습니다.

@eye776 또한 함수 재정의가 있는 동적 언어를 본 적이 없습니다. GDScript에는 기본 매개변수가 있으므로 대신 사용할 수 있습니다.

또한, 단일 파일에서 20K+ LOC를 수행하는 미친 사람은 누구입니까? 여기서 문제는 도구에 있지 않습니다... 전체 Godot 소스에서 10K LOC로 찾을 수 있는 단일 파일이 없습니다.

내가 동의하는 것은 C++에 조금 더 많은 사랑을 준다는 것입니다. 그러나 앞서 언급한 용도에 대해서는 AI에만 동의합니다. 그리고 하나 더 인용하자면 절차적 생성입니다. 이제 엔진 물리학, 렌더링 등을 다시 만들고 있다면 Godot를 더 이상 사용하지도 않고 포크만 한 것입니다. 내장 유형에 의존할 수 없다면 엔진이 필요한 이유는 무엇입니까?

물론 GDScript는 완벽하지 않습니다(어떤 언어도 완벽하지 않음). 또한 돌에 새겨져 있지도 않습니다. 열거형, 스위치/케이스 및 삼항 연산은 미래에 추가될 가능성이 있습니다(이에 대해 이미 미해결 문제가 있음). 지금 당장 가지고 있지 않다고 해서 절대 가질 수 없는 것은 아닙니다.

마지막으로 "의심"은 실제로 도움이 되지 않습니다. 우리에게 필요한 것은 벤치마크와 사용 사례입니다. 이미 GDScript로 작성된 상당히 복잡한 게임이 있으므로 실제로 누락된 것이 무엇인지 모르겠습니다.

@vnen 은 재미로: godot/drivers/gles2/rasterizer_gles2.cpp 는 11K LOC :p입니다(내가 찾은 것 중 가장 크지만 드문 예외임).

@vnen

내장 유형에 의존할 수 없다면 엔진이 필요한 이유는 무엇입니까?
음, 초보자를 위한 고품질 크로스 플랫폼 컨텍스트로. 그러나 이것이 내가 내 자신의 스프라이트 또는 모델 클래스를 작성한다는 것을 의미하지는 않습니다.

Godot는 지난 3월에 한 번 나를 태워버렸습니다(v 2.0.1). 저는 3인칭 카메라와 캐릭터를 가지고 장난을 치고 있었고 Godot의 자체 물리학을 움직임(끌기 및 힘)에 사용하려고 시도했고 작동하게 했습니다.
다음 마이너 버전(v 2.0.2) 업데이트는 정확히 동일한 값에 대해 기본적으로 캐릭터의 속도(2-3배 더 빠름)를 중단했습니다.
Kinematic을 유지하고 내 자신의 "물리"를 수행하는 것이 더 낫다고 생각했습니다.

또한 Godot와 관계없이 XCode의 스토리보드와 같은 자동화된 것들에 의존하여 여러 번 화상을 입었습니다.
나는 반짝거리는 것에 끌리는 것을 그만뒀고 내 뒤에서 IDE에 의해 자동 생성되는 코드가 무엇이든지 간에 내 코드가 엉망이 되지 않기를 기도했습니다.

어쨌든, 스레드를 탈선시켜 정말 정말 죄송합니다.

@eye776 2.0.1에서 2.0.2로 커밋 차이를 확인하여 게임이 망가졌는지 확인하셨나요? 버그일 수 있으며 이를 보고하면 전체 커뮤니티에 도움이 될 수 있습니다.

모노 또는 CoreCLR? 그리고 왜?

단 핵증:

• MIT 라이센스
• 안정적인
• 버려질 가능성
• 좋은 문서

코어CLR:

• MIT 라이센스
• 여전히 1.0이 아닙니다(현재 RC2임).
• 작은
• 부실한 문서

우리는 Mono가 모바일과 웹에 배포되기 때문에 사용하고 있습니다. 나는 여기라고 생각한다
휴대가 훨씬 간편하기 때문에 버려질 가능성이 0입니다. 내 직감
두 코드베이스가 결국 병합된다는 것입니다.

2016년 8월 4일 목요일 오후 1시 45분, Hubert Jarosz [email protected]
썼다:

모노 또는 CoreCLR? 그리고 왜?

단 핵증:

• MIT 라이센스
• 안정적인
• 버려질 가능성
• 좋은 문서

코어CLR:

• MIT 라이센스
• 여전히 1.0이 아닙니다(현재 RC2임).
• 작은
• 부실한 문서

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/godotengine/godot/issues/5081#issuecomment -237611905,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AF-Z2zRjC8u_owFzCCyeqIhF8W5XqCtLks5qchchgaJpZM4Ivn7R
.

위에서 언급한 @reduz 외에도 API가 캡슐화되어 나중에 필요한 경우 CoreCLR로 변경하는 것이 어렵지 않습니다.

CoreCLR: 아직 1.0이 아닙니다(현재는 RC2임).

6월 14일에 1.0 안정에 도달했습니다.

모노: 버려질 가능성

무엇을 기반으로?

모노: 좋은 문서

아 아 아

무엇을 기반으로?

Microsoft가 .NET의 세 가지 스택을 개발하는 이유는 무엇입니까? 자원적으로 좋지 않습니다. (.NET 프레임워크, 모노, .NET 코어)

아 아 아

나는 C++/C# interop(godot에 필요한 것)에 대한 두 문서를 모두 확인했으며 Mono로 문서화되어 있습니다. coreCLR에서 나는 그들의 코드 중 일부를 파헤치고 개발자들에게 내 앱을 작동시키는 데 도움을 요청해야 했습니다.

참조 가이드 에는 문서화되지 않은 기능이 너무 많고 끊어진 링크가 있습니다...

이론상 저는 여기에서 편견을 가지고 있습니다... 하지만 제 주장이 객관적이기를 바랍니다...

• Mono 개발에 어떤 감소도 보이지 않습니다: https://github.com/mono/mono/graphs/contributors
• Windows에서 Mono를 위한 개발은 오늘날만큼 강력하지 않았습니다(약간 증거(많은 커밋을 연결하지 않음) https://github.com/mono/mono/pull/3231 Miguel이 "이제 실제 관리자가 있기 때문에"라고 말합니다) 이전 요점이 더욱 명확해졌습니다.
• Mono의 Embedding API는 전투 테스트를 거쳤습니다(Unity뿐만 아니라 다른 많은 개인 사용자가 있음).
• Mono TODAY 는 PS4, Android, Windows, iOS BITCODE (수년간의 작업이 필요함), AppleTV 및 더 많은 플랫폼에서 실행됩니다...

그래서 임호, 가까운 미래에 대부분의 게임 플랫폼에서 이것을 제공하려면... Mono와 함께 가십시오.

안녕하세요,

일부 의견:

• David Karlas가 나열한 플랫폼 외에도 WebAssembly, XboxOne, UWP 및 Win64 기본 지원도 추가하고 있습니다.
• 공유 중인 샘플은 가상 메서드(빠른 디스패치)로 수행하거나 C# 이벤트로 수행할 수도 있습니다.
• C#은 역사적으로 많은 언어 혁신의 선두에 서서 어느 곳에서나 좋은 아이디어를 이끌어 냈습니다. 그것은 대중화되었고 언어 연구에서 많은 아이디어를 대중 시장에 가져왔으며 반복자, 지우지 않은 제네릭, 람다, 비동기 프로그래밍, 속성, 플랫폼 호출과 같은 것들을 이제 당연하게 여깁니다. 공개적으로 가장 활발하게 개발되었습니다 . 예를 들어, 다음 버전에는 내가 가장 좋아하는 패턴 매칭을 포함하여 많은 새로운 기능이 추가됩니다.
• 일반적으로 Unity는 이전 런타임을 사용하기 때문에 최신 C#을 선보이지 않습니다. 이것은 곧 바뀔 것입니다. 즉, 현재 Mono는 게임 코드에 이상적인 "비동기" 프로그래밍 중에서 모든 새로운 C# 기능을 지원합니다. 선형으로 작성할 수 있고 컴파일러가 자동으로 코드를 코루틴이나 고급 Unity에서 사용되는 "yield"의 버전입니다.
• 동기화 컨텍스트는 특정 컨텍스트 내에서 실행되는 비동기 코드를 작성할 수 있음을 의미합니다. 예를 들어, 게임 바운드 실행, IO 바운드 실행 또는 메인 대 백그라운드 스레드 바운드 실행이 있을 수 있으며 모두 시스템의 일부입니다.
• 배포하는 동안 LLVM이 있거나 없는 JIT 컴파일 또는 정적 컴파일(AOT)을 선택할 수 있으므로 C#이 배열 경계 검사를 수행한다는 사실을 모듈로 C++에서 최대한 빨리 얻을 수 있습니다. 버퍼를 사용하면 안전을 희생하면서 성능을 다시 얻을 수 있습니다.)
• 지난 몇 년 동안 Mono가 모바일에 중점을 두었기 때문에 Mono의 GC는 서버용이 아니라 대화형 워크로드용으로 조정되었습니다. 우리의 새로운 GC는 매우 빠르게 수집할 수 있고 전체 힙을 스캔할 필요가 없는 작은 보육원과 함께 세대에 걸쳐 있습니다.

Microsoft가 여러 CLR(JIT 워크로드용 CoreCLR, UWP의 정적 컴파일용 CoreRT 제품군, 모바일 워크로드용 Mono)을 개발하는 이유는 모두 서버의 용도가 약간 다르기 때문입니다. 내부는 가능한 한 수렴되고 있습니다. 예를 들어 Mono는 이제 핵심 코드의 약 60%를 나머지 .NET과 직접 공유되는 코드로 대체했습니다. 자신에게 더 적합한 워크로드를 찾는 것이 중요합니다.

오늘 하나의 VM으로 시작하여 나중에 다른 VM으로 전환할 수 있습니다. 현재 Mono는 더 큰 API 표면을 가지고 있고 모바일에서 작동하며 대화형 워크로드에 최적화되어 있으며 더 많은 아키텍처(예: ARM64)를 지원합니다.

좋은 소식은 한 VM을 다른 VM으로 바꾸거나 둘 다 지원하는 데 며칠이 소요되므로 특정 구현에 자신을 가둘 필요가 없다는 것입니다.

@migueldeicaza 환영합니다! 당신이 우리의 토론에 참여하기로 결정하고 Godot에 관심을 갖게 되어 기쁩니다 :+1: 당신이 잠시 동안 우리와 함께 있기를 바랍니다 :)

@migueldeicaza의 좋은 분석에 감사드립니다! 귀하 또는 다른 Mono 개발자에게 두 가지 간단한 질문이 있습니다.

1) Visual Studio를 사용하여 Windows에서 임베디드 Mono를 디버깅하기 위한 현재 설정은 무엇입니까? Unity에는 플러그인이 있지만 Linux/OSX 시스템에 연결하는 플러그인 외에는 아무 것도 찾을 수 없었습니다.

2) 런타임 재컴파일을 처리하는 데 권장되는 방법은 무엇입니까? 불행히도 C#은 Assembly.Unload() 메서드를 노출하지 않으며 AppDomain 및 교차 AppDomain 문제를 처리하는 것은 이 상황에서 지나치게 성가신 것 같습니다.

참고로 Unity는 Mono( https://github.com/xamarin/urho (Urho3D 엔진용 C#/Mono 바인딩))를 사용할 뿐만 아니라 MIT 라이선스를 사용하므로 솔루션을 쉽게 조회할 수 있습니다.

내 2센트:

C#은 사용자 정의 값 유형을 지원한다는 점에서 다른 유사한 수준의 언어보다 게임 프로그래밍에 훨씬 뛰어납니다. 이것은 성능에 있어 매우 중요한 기능이며 Java(및 일반적으로 JVM)에는 말 그대로 이에 대한 대안이 _no_ 있습니다.

당신은 얻을:

• 힙 할당 없이 수학 연산 및 임시 개체를 지원하는 스택 할당 수학 유형입니다.
• 최적화된 캐시 친화적인 연속 컬렉션.
• 값 유형을 사용하는 제네릭(기본 유형 포함)

그 외에도 C#에는 삶을 더 쉽게 만들어주는 다른 기능이 있습니다. C#이 _game_ 프로그래밍에서 중요한 거의 모든 면에서 단순히 Java를 능가할 때 C# 대신 Java를 사용할 가치가 없다고 봅니다.

안녕하세요 여러분,
나는 위의 모든 것을 읽지 않았습니다 (단순히 너무 많이 :))
그러나 나는 휴일이 있어서 msDotNetHost 역할을 하는 Godot용 프로토타입 모듈을 만들었습니다. 그래서 내가 겪은 몇 가지 발견 사항을 제공할 수 있습니다. 아마도 도움이 될 것입니다. 슬프게도 내 hollydays는 끝났고 돈을 위해 다시 코드를 작성했습니다 :) 그러나 재미있었습니다. :)

현재 상태:
o) 모듈은 노드 클래스를 확장하여 노드 이벤트를 netCode에 노출합니다.
(초기화, tree_entered, 준비, 프로세스, fixedprocess....)),
o) "net host/wrapper module" 완료(Microsoft dotNet 호스트 메커니즘 사용)
동적 라이브러리에 캡슐화되어 있으므로 나중에 Mono로 쉽게 전환할 수 있습니다.
o) dotNet 메서드가 바인딩되고 호출됩니다(init, tree_entered, ready, process, fixedprocess....).
o) 노드 클래스가 래핑되어 netAssembly(프로토타이핑을 위해 수동으로 작성된 코드)에 바인딩됩니다.
o) (netCode에서) godot에 대한 호출은 자체 작성 바인딩 메커니즘을 통해 작동합니다.
(dll에서 godot-exe로) exe는 기능을 내보낼 필요가 없습니다.
o) msDotNet의 사용으로 인해 가까운 장래에 Windows에 바인딩됩니다.

.Net을 포함하는 로드맵은 다음과 같습니다.

1. Microsoft .Net 호스팅 메커니즘을 사용하는 Godot용 모듈 (완료)
2. wrappin godotClasses
   (내 현재 상태: godot C++ 코드를 구문 분석하는 래퍼 생성기 작성,
   구문 분석 완료, 생성 진행 중)
3. 프로젝트를 프로토타입 상태에서 해제(가장자리 완성, 테스트...)
4. Windows 채권을 제거하기 위해 Mono 호스팅 메커니즘을 작성하십시오.
5. 어떻게 든 Visual Studio가 모노를 디버그하도록 활성화하여 xamarin/monodev를 제거합니다(예: unity vs-plugin).
6. 수백 명의 새로운 Godot .net 개발자와 함께 즐거운 시간 보내세요 :)

몇 가지 질문:

1. gdscript에 사용되는 바인딩 메커니즘을 재사용할 수 있는지 궁금합니다. 하지만 이 모든 것을 평가할 시간이 없습니다. 저에게 좋은 tut 또는 highlvl 힌트가 있습니까?

2.
현재 저는 모든 Godot 메서드를 함수로 래핑하는 래퍼를 생성하여 dll 경계 및 C++/netCode 경계를 통해 쉽게 호출할 수 있습니다. (netCode에 대한 자체 작성 바인딩 메커니즘)
호환성을 유지하기 위해 Godot 코드(내 모듈 코드 제외)를 변경하고 싶지 않습니다.
또한 정적, 비정적, 가상 비가상이 저를 울게 만들었습니다. 그래서 제가 이 방법을 선택했습니다.
이것에 대한 더 나은 솔루션이 있습니까?

몇 가지 추가 생각:

마이크로소프트 닷넷 대 모노:

대부분의 경우 dotNet 코드는 둘 다에서 변경되지 않고 실행되기 때문에 모노 또는 msDotNet을 사용하는 것은 중요하지 않다고 생각합니다. 둘 다 지원하기 위한 유일한 노력은 각각의 "호스트"를 작성하는 것입니다("GodotDotNet"의 가장 작은 부분). 프로토타이핑을 위해 msDotNet을 선택했습니다.
글쎄, 모노는 많은 플랫폼 msDotNet 전용 창을 지원하는데 왜 msDotNet을 지원/사용합니까?
답: 생산성, 디버깅

ms닷넷:
특히 DotNetModule을 작성/프로토타이핑할 때 FAST 컴파일 및 디버그를 필요로 하거나 원할 때 디버거가 C++에서 netCode로 점프해야 하며 그 반대도 마찬가지입니다.
VisualStudio를 선택합니다. 둘 다 디버그할 수 있기 때문입니다. 그러나 msDotNet을 사용하는 경우에만.
그렇게 하면 netCode의 일부를 변경하고 실행을 누르고 1초 안에! 컴파일 및 실행 중!!! Godot로 디버그할 수 있는 가능성을 포함합니다. (고도에서 변경하지 않은 경우 일반적으로 30초에서 1분을 기다려야 합니다. 젠장, 느린 scons! :) )

단 핵증:
Mono는 최종 대상이어야 하며 이에 대한 논의는 없지만(플랫폼 독립성):
모노를 사용하는 경우 디버깅과 관련하여 큰 문제가 발생합니다. 모노에는 자체 디버깅 메커니즘이 있습니다!
저에게는 생산성에 큰 영향을 미쳤습니다. 왜냐하면 Visualstudio용 monodebug-plugin을 작성하지 않는 한(unity가 이 작업을 수행했습니다) Visual Studio에서 모노 호스팅 넷코드를 디버그하고 C++ 코드로 디버그할 수 없기 때문입니다(해킹 솔루션이 있지만 ...).
Mono 기반 솔루션을 설정하려고 시도했지만 VisualStudio(C++용)와 xamarin/monodev(netcode)를 병렬로 사용하게 되었습니다.

결론:
프로토타입 상태: msDotNet
lateron: 모노, Godot/C++ 및 플랫폼 독립성으로 디버그하는 데 관심이 없는 사용자를 위한 것
그 후: 모노 디버그를 위한 vs-플러그인 생성

C# 대 자바:
대답은 분명합니다 C#! 자바는 scritpkids를 위한 것입니다! (오 C++ 코더는 C# 개발자에 대해 어떻게 생각하나요 :) )
아니 농담이었어 :)
나는 토론을 이해하지 못합니다... .net 시스템이 구현되면 두 언어와 그 이상을 포함하여 dotNet을 지원하는 모든 언어를 사용할 수 있습니다.
이것은 자바 시스템이 지원되는 경우가 아닙니다 ...

@지플린 :
질문 1:
그 검색도 했습니까 ... monoRemotedebugger 만 (아님) 솔루션입니다 atm :(
제가 추천하는 방법은 위에서 언급한 대로 프로토타이핑을 위해 microsofts dotNet 호스팅을 사용하는 것입니다.
그런 다음 나중에 모노로 전환하십시오.
대안:
해킹된 모드에서 xamarin을 시작하고 localhost를 수신하도록 하고 중단점을 설정한 다음 ur 프로젝트를 vs. ive에서 시작하여 테스트했지만 작동하지만...
나에게는 해결책이 없습니다! 나는 "1초 만에 실행 및 디버그"를 원합니다.
여가 시간이 많지 않기 때문에 생산성이 주요 목표입니다.

질문2:
모노는 아직 잘 모르지만 C++에서 모노 호스팅을 구현하고 C++에서 "외부"에서 관리해야 한다고 생각합니다.

@CharlesWoodhill 공식 C# 바인딩은 이미 WIP이며 https://github.com/neikeq/GodotSharp/ 에서 볼 수 있습니다.

멋진 tnx, 다음 휴가를 어떻게 보낼지 압니다 ;)

안녕하세요, 방금 GodotSharp를 찾았지만 이것은 떨어졌습니다.

이것은 떨어졌다.

IRC에서 들은 공식 버전은 다음과 같았습니다.

@neikeq 는 완료되지 않은 코드를 푸시하는 것을 좋아하지 않으므로 로컬 지점에서 작업합니다.

다행이군요, 저는 제 자신의 모듈을 만들려고 했으나 Godot 2.2나 3.0에서도 그렇게 할 수 있을 것 같습니다.

2.2 릴리스는 없을 것이며 Godot 개발자는 모든 2.2 기능을 3.0으로 옮겼습니다.

처음으로 댓글을 남깁니다. Unity에서 왔고 GDscript로의 이전은 꿈이었습니다. 나는 하루 만에 언어를 습득했습니다. 나는 언어가 엔진에 얼마나 잘 구현되어 있고 생산성이 상당히 높아진 것을 좋아합니다.

내 주요 관심사는 추가된 C# 지원으로 GDscript가 Unity 개발자의 홍수 이후에 뒤처지거나 덜 개발될 것이라는 점입니다. C#은 훌륭한 언어이지만 개인적으로 좋아하는 언어는 아닙니다.

또한 Godot가 단독으로 서 있는 것이 아니라 다른 엔진처럼 보이려고 하는 것이 걱정됩니다. Unity는 멋진 성공 사례이지만 내가 사용해 본 엔진 중 최고는 아닙니다. 부풀어 오르고 버그가 있습니다. 일단 확인 없이 전체 프로젝트를 삭제했습니다. 버그와 제대로 작동하지 않는 일을 처리하는 것은 끊임없는 투쟁이었습니다. 일이 제대로 작동하지 않아 작업하고 있던 장면을 완전히 다시 만들어야 했던 횟수를 셀 수 없습니다. 한 번은 이전 버그 장면의 모든 내용을 복사하여 새 장면에 붙여넣어 두 장면이 똑같음에도 불구하고 갑자기 작동하도록 한 적이 있습니다. 나는 마술처럼 나타났다가 사라지는 물리학 버그를 사냥하는 데 몇 주를 허비했습니다.

Godot는 간결하고 이해하기 쉽습니다. Godot와 작업하는 것은 잘 조율된 악기를 사용하는 것과 같았습니다. 거의 1년 동안 그곳에서 일한 후에는 이전에 해보지 않았더라도 내가 해야 할 일은 무엇이든 하는 방법을 알게 되었습니다. Unity 사용자의 유입으로 인해 엔진의 방향이 Unity로 향하지 않기를 바랍니다. Unity를 원했다면 Unity를 사용할 것입니다.

@zaywolfe 귀하의 우려는 다른 사용자에 의해 몇 번 표명되었습니다. 당신은 걱정할 필요가 없습니다. GDScript는 계속해서 Godot의 주요 언어가 될 것입니다.

나는 GDScript를 좋아하지 않는다 . 파이썬을 모델로 한 것은 이해하지만 매우 보잘 것 없습니다. C++ 또는 Java가 포함된(즉시 사용 가능) 제 생각에는 훌륭한 아이디어가 될 것입니다. 저는 개인적으로 개발 중에 GDScript를 사용하는 것에 혐오감을 느끼며, Godot를 떠나고 새로운(또는 대체) 언어가 구현되었을 때 다시 돌아올 것인지에 대해 의문을 가질 정도입니다. 죄송합니다. 하지만 프로그래머의 정확한 정보를 원하신다면 알 수 있습니다.

또한, 저는 가끔 간단한 소프트웨어 프로토타이핑을 위해 Godot를 사용하기도 합니다. 따라서 깊이 통합된 프로그래밍 언어는 엔진 내에서 소프트웨어 개발을 위한 문을 열 수 있습니다. 그것은 진정으로 Unity 킬러가 될 것입니다. (물론 Java 또는 C++를 선택한 경우)

열성적인 개발자 여러분의 노고에 감사드립니다. 여러분 모두를 기대하며 향후 업데이트된 릴리스를 기대합니다!

@VenHayz Godot 문서를 읽었는지 모르겠지만 Godot 의 첫 번째 버전 이후 로 이미 C++로 게임을 작성할 수 있습니다 - http://docs.godotengine.org/en/stable/reference/custom_modules_in_c++.html

Microsoft .net 코어를 사용하는 것은 어떻습니까? 크로스 플랫폼 및 성능 중심이며 오픈 소스이며 활발하게 개발되고 있습니다.

안녕하세요 그냥 지나가는 사나이

나는 당신이 사용하는 스크립트 언어가 마음에 들지 않기 때문에 내가 Godot를 사용하지 않는다는 것을 당신에게 알리고 싶었습니다

Java 또는 C#을 추가하면 공지 직후에 godot를 설치하여 사용하겠습니다. :)

@RUSshy 작별인사를 하세요. 당신의 손실입니다. Godot는 훌륭합니다. GDScript는 훌륭합니다. 당신이 실제 프로그래머라면 어떤 프로젝트를 시작하기에 충분한 것 이상을 아는 데 문자 그대로 2시간이 걸릴 것입니다. 실제 프로그래머는 많은 언어를 마스터해야 하며 Java/C#을 고수하고 영원히 취미 생활을 하는 "무작위" 사람이 될 수 있습니다. 무례하게 하려는 것이 아니라 사실만을 말하겠습니다. 이 엔진이 마음에 들지 않으면 일부 코드로 기여하십시오. 대부분의 다른 엔진과 달리 무료입니다.

마케팅의 신은 C#을 선호합니다. :웃음:

@RebelliousX Java 또는 C#을 선택하면 사용할 라이브러리를 손에 넣을 수 있습니다.

집에서 만든 스크립트 언어로 자신을 제한하는 것은 쓸모가 없으며 새로운 지식은 다른 곳에 적용할 수 없으며 수많은 라이브러리를 찾을 수 없거나 지식이나 기존 학습 리소스를 재사용할 수 없습니다.

요즘은 선택이 미쳤어

@RUSshy 농담하는거야? 저와 몇몇 다른 사람들은 C#에 비해 GDscript의 이점에 대해 문자 그대로 설명 페이지를 작성했는데 이전에 언급된 내용을 읽지 않고도 짧은 단락 하나로 토론을 해결할 수 있다고 생각하십니까?

"밀접하게 생각하지 마십시오" - 좋은 생각입니다. GDscript에 대해 열린 마음으로 시작하는 것은 어떻습니까?
"당신의 새로운 지식은 다른 곳에 적용되지 않을 것입니다." - 그것은 단순히 거짓입니다. 이해하지 못한 코드를 복사하여 붙여넣는 것으로 지식 부족을 보충할 수 없습니다.
"수많은 라이브러리를 찾을 수 없을 것입니다." - 스크립팅 언어와 백엔드 언어의 차이점을 배우십시오. 또는 - 미친 아이디어 - 내가 그것에 대해 쓴 것을 읽으십시오.

진심으로, 어떤 사람들의 대담함...

C# 통합 모듈이 작업 중이라고 여러 곳에서 여러 번 언급되었습니다. 사람들이 해야 하는 시간만큼 빠르게 진행됩니다. 더 빠르게 만드는 유일한 방법은 해당 통합에 기여하는 것입니다. :)

@Warlaan 두 번째 요점: 이전에 C#으로 많은 코드를 작성했다면 모두 이식하지 않는 한 재사용할 수 없습니다. 또한 라이브러리를 사용하기 위해 라이브러리 코드를 이해할 필요도 없습니다. 요점은 이전에 C#에 있던 것(단일 파일 또는 라이브러리 집합, 잠재적으로 폐쇄된 소스)이 필요한 경우 모든 것을 이식하거나 C# 런타임을 포함하거나 C 구현을 찾아야 한다는 것입니다. 불가능한 것은 아니지만 시간이 많이 걸립니다.
그렇다고 Godot가 기존 라이브러리를 많이 사용할 수 없다는 뜻은 아닙니다... C/C++에도 수많은 라이브러리가 있습니다.

이것은 화염 전쟁이 될 위험이 있습니다.
로그가 너무 길어서 사람들이 읽는 대신 동일한 질문이나 주제를 반복합니다.
논의할 기술적인 내용도 많지 않습니다.

스크립팅 측면에서 Godot의 미래는 이미 매우 명확합니다:

• GDScript는 기본 언어로 남을 것이며 이를 최적화할 계획이나 아이디어가 있습니다(그러나 여기에서 논의할 적절한 장소는 아닙니다).
• 3.0부터 C#은 스크립팅 대안으로 지원됩니다. 모노 런타임을 사용하지 않을 사람들에게 추가 크기를 강요하지 않도록 별도의 바이너리를 제공할 것입니다.
• DLScript도 작업 중입니다. 사람들이 스크립팅을 위해 공유 라이브러리를 사용할 수 있습니다. 이러한 라이브러리는 c 연결 및 공유 라이브러리를 지원하는 모든 언어로 작성할 수 있습니다(Rust 및 D와 같은 언어 예상). 3.0에 대한 준비가 될지 여부는 아직 명확하지 않습니다(내가 구식인 경우 제외).
• 3.0에도 Visual Scripting이 있다는 것을 잊지 마십시오!

누군가 다른 것을 기고할 계획이라면 여기도 그에 대해 논의할 적절한 장소가 아닙니다.

이 문제는 닫을 수 있고 닫아야 한다고 생각합니다.

동의.

C# 통합 소스 코드에 대한 링크를 제공해 주시겠습니까?

https://github.com/neikeq/GodotSharp

얼마나 기능적인 GodotSharp 통합? 테스트에 사용할 준비가 되었습니까?
Godot 마스터의 소스 빌드와 함께 사용할 수 있습니까?

@nictaylr 현재 마스터로 빌드하지 않습니다. 테스트하려면 2.2-레거시를 사용해야 합니다. 그것은 그 버전으로 아주 잘 작동합니다

4월에 3.0 알파를 준비하기 위해 노력하고 있습니다.

엉뚱한 생각이지만 Godot로 C++에 대해 깊이 생각한 후 더 나은 것을 생각해냈습니다. D 언어. C 및 (일부) C++ 지원에 대한 인터페이스 와 함께 틀림없이 "저수준" 언어 할당량에 속합니다. 수업이 있으며 매우 현대적입니다. 무섭게 들리지만 GDScript와 매우 흡사하며 매우 큰 프로젝트를 지원하는 데 사용되는 것을 볼 수 있습니다. GDC라는 컴파일러로 C 및 C++(gcc/g++)와 경쟁할 만큼 강력합니다. (DMC를 사용하여 컴파일할 수도 있지만 GDC는 gcc로 직접 컴파일합니다.) GDC에 대한 자세한 내용은 여기를 참조하세요.

어쨌든, 단지 빠른 제안이나 아이디어를 위한 것일 뿐입니다.

@VenHayz 저는 스크립트 에 공유 라이브러리를 사용할 수 있는 모듈을 개발 중입니다. 나는 이미 C++를 사용하기 쉽게 만들기 위해 약간의 노력을 기울였습니다. D를 사용하여 해당 라이브러리를 만들 수도 있습니다. D 바인딩을 만드는 데 관심이 있다면 IRC나 Discord에서 저를 찾아주세요.

@karroffel 정말 멋지네요. 나는 라이브러리와 API("바인딩"에 대한 언급 참조)를 작성한 경험이 없지만 아마도 하루 동안 연구하고 수행할 수 있을 것입니다. 나는 자랑스럽게도 빨리 배우는 사람입니다. 괜찮으시다면 Discord로 연락을 드리고 싶습니다. 내 불화: _hasCat#3941

@VenHayz 나는 당신을 추가할 수 없습니다, 당신은 다른 사람들이 당신을 추가하는 것을 허용하지 않습니다. Karroffel#8409 또는 Godot 서버에 가입하세요

@neikeq 귀하의 GodotSharp 저장소는 Godot 3.0에서 C# 지원에 사용되는 코드베이스입니까? 어떤 기능을 사용할 수 있는지 대략적인 아이디어를 얻으려고 하기 때문에 질문하는 것입니다. 그렇다면 해당 코드베이스를 둘러볼 것입니다. 감사 해요!

나는 Godotsharp를 본다, 구식인가? 새로운 특성 ? 또는 개발 빌드에서 사용할 준비가 되었습니까?

나를 위해 소스에서 Godosarp를 어떻게 컴파일할 수 있습니까?

@nictaylr 2.2 레거시 브랜치를 개발 빌드로 사용해야 합니다.

나는 다른 누군가가 이것을 언급했는지 알아낼 만큼 충분히 읽었다고 생각합니다.

저는 개인적으로 다른 곳에서 사용할 수 없는 다른 언어를 배우고 싶지 않습니다. 저는 3D 프로그래밍을 많이 할 계획이 아니라 여기저기서 몇 가지만 할 계획입니다.

예, 이에 대해 많은 반론이 있지만 ... 그것은 오픈 소스 프로젝트입니다. 새로운 프로그래밍 언어를 제공하는 누군가를 미워할 필요가 없습니다.

어린이 파티에 맥주를 가져오는 것을 상상해 보십시오. "누군가가 새로운 음료를 제공하는 것을 미워할 필요가 없다"라고 말할 수 있습니까? C#을 추가하면 GDscript의 개발에 해를 끼칠 가능성이 높습니다. 나는 모두가 Godot의 기본 언어인 GDscript를 유지하기로 결정했다는 것을 알고 있습니다. 그러나 왜 새로운 기능을 추가하는 것이 단점이 있고 사람들이 여전히 "무엇이 해로운가?"라고 묻는 이유를 여러 번 설명했을 때 여전히 짜증이 납니다.

또한 "배우고 싶지 않다"는 이유로 GDscript 대신 C#을 요구하는 것은 정말 어리석은 주장입니다. 내가 게임 개발에서 아는 모든 언어 중에서 GDscript는 가장 적은 기능을 가지고 있고 C#은 단연 가장 많이 가지고 있습니다. 배우고 싶지 않다면 GDscript에 감사해야 합니다.

저는 이 토론을 계속해서 예열하고 싶지 않습니다. 따라서 누군가 이 스레드에 대해 논평을 하고 싶다면 맨 위에서 읽어주세요.

또한 "배우고 싶지 않다"는 이유로 GDscript 대신 C#을 요구하는 것은 정말 어리석은 주장입니다.

나는 다른 곳에서 그것을 사용할 수 있기 때문에 C#을 배우는 것에 신경 쓰지 않을 것입니다.

스레드를 잠그십시오. 의미가 없습니다.

이 스레드가 목적을 달성한 것은 사실입니다. 잠그자.