질문이 단순히 "Godot에서 동일한 결과를 얻을 수 있는 여러 가지 방법이 있습니까?"라면 대답은 예입니다. 그리고 게임의 시스템마다 요구 사항이 다를 수 있으므로 단일 워크플로를 강요하는 것은 터무니없는 일입니다. 많은 성능이 필요한 시스템과 게임 디자이너가 자주 업데이트해야 하는 시스템을 같은 방식으로 코딩하지 않습니다. 모든 솔루션에는 장단점이 있으므로 "공식" 워크플로를 만드는 것은 의미가 없습니다.

다중 구성 요소가 있는 MeshInstance만큼 복잡한 클래스를 만들 수 있습니다.

정확히 어떤 구성 요소로?

편집: 그리고 아시다시피, 귀하가 인용한 문제 중 하나는 "이 아이디어는 진정으로 완전히 형편없고 완전히 무의미합니다"라는 작성자와 함께 종료되었습니다.

이것을 보여주기 위해 저는 MeshInstance가 Godot에서 만들어진다면 어떤 모습일지 모의 클래스를 사용할 것입니다.
자식 노드라고도 하는 의사 Unity가 있습니다.
Godot 사용자는 자식 노드를 사용하여 MultiScript와 동등한 것을 만듭니다.
Pseudo Unreal, 일명 컨트롤러 및 중간:
Pseudo Panda3D, 일명 Preload(스크립트):
WTF 스크립트:
예, Godot에 MeshInstance 클래스가 있다는 것을 압니다.
이것이 보여주는 요점은 현재 개발자가 사용하는 대부분의 워크플로가 다중 구성 요소가 있는 MeshInstance만큼 복잡한 클래스를 만들 수 있다는 것입니다. 각 워크플로에 심각한 결함이 있다는 점을 제외하고.

나는 당신이 여기서 말하려는 것을 잘 이해하지 못합니다. MeshInstance 클래스가 이미 있는 경우 왜 누군가가 이를 생성합니까? 그리고 Godot가 다른 엔진과 비슷한 기능을 가지고 있는 것이 왜 문제일까요? 또한, 하나의 노드에 여러 스크립트를 연결하려는 경우 OOP를 사용하지 않거나 두 개의 개별 기능을 하나의 노드에 넣습니다. 이는 Godot의 노드 시스템을 사용하여 쉽게 수정됩니다.

질문이 단순히 "Godot에서 동일한 결과를 얻을 수 있는 여러 가지 방법이 있습니까?"라면 대답은 예입니다...

망치를 만들면 그 용도를 알 수 있고, 쓸 수 있는 모든 것을 다 알지는 못해도 어떤 용도로 쓰면 안 되는 것인지 알 수 있습니다.
망치가 뭔지도 모르는 사람에게 망치를 주고 사용법을 설명하지 않은 경우 그들이 격렬하게 스윙하기 시작하면 놀라지 않을 수 없습니다.

이것이 Godot가 있는 곳입니다. 개발자들은 어떻게든 이것을 통해 무언가를 만들 수 있기를 희망하면서 어둠 속에서 흔들리고 있습니다.

정확히 어떤 구성 요소로?

머티리얼과 트랜스폼 같은 것들은 원래 인스턴스의 일부로 간주됩니까?
유사한 구성 요소를 생성하면 노드에 어떻게 연결합니까?

"목표물 추적" 또는 "목표물 발사"와 같은 다른 작업은 이러한 작업을 클래스에 추가하거나 어떻게든 첨부해야 합니까?
Godot는 결코 Godot에 대한 적절한 Include 또는 Import 기능을 만들지 않았기 때문에 그것이 결코 그런 식으로 사용되도록 의도되지 않았음을 의미합니까?

우리는 우리가 모든 것을 가질 수 없다는 것을 알고 있습니다. 그래서 질문은 우리가 무엇을 가지고 있습니까? 작동하는 디자인은 어땠나요?

@MysteryGM 느슨하고 연결이 끊긴 비유는 도움이 되지 않습니다.

재료 및 변형과 같은 것

Transform은 Spatial 속성이고 Materials는 Mesh 속성입니다. MeshInstance는 Spatial 위에 구축되어 Spatial의 모든 속성을 상속합니다. 그것은 나에게 의미가 있는 간단한 계층 구조입니다.

유사한 구성 요소를 생성하면 노드에 어떻게 연결합니까?

Godot가 이미 메시 시스템을 가지고 있는데 왜 당신만의 메시 시스템을 만드시겠습니까?

"목표물 추적" 또는 "목표물 사격"과 같은 다른 작업은 어떻습니까?

코드는 스크립트에 들어갑니다. 노드의 기본 스크립트에 넣거나 그렇게 하는 것이 더 유용하다고 생각되면 스크립트와 함께 자식을 줄 수 있습니다.

Godot가 이미 메시 시스템을 가지고 있는데 왜 당신만의 메시 시스템을 만드시겠습니까?

게임 개체는 메시만큼 복잡하기 때문입니다. 게임의 일부가 원래의 엔진인 엔진은 재사용된 부분일 뿐이라는 것을 기억하십시오.

Godot가 엔진 내부에 Mesh 클래스를 효과적으로 생성할 수 없다면, 복잡한 게임을 만드는 데 사용할 수 없습니다. 모든 게임은 엔진보다 덜 복잡해야 합니다.
이것은 차례로 전문 개발자 팀에게 아무 소용이 없음을 의미합니다. 그런 팀이 소스 코드와 함께 C++만 사용하지 않는 한.

코드는 스크립트에 들어갑니다.

하지만 어떤 면에서?
저는 이미 모든 스크립트에 대해 자식을 만들 수 없다는 것을 알고 있습니다. 왜냐하면 저는 백만 개 이상의 함수가 필요하고 백만 개의 빈 노드라도 Godot에게는 너무 많기 때문입니다.
그게 무슨 뜻인가요? 얼마나 많은 기능을 함께 그룹화해야 합니까? 아니면 종이에 개체 상속을 계획하는 데 2-4개월을 소비해야 합니까?

내가 알고 싶은 것은 Godot가 날씨 효과, 체적 안개 및 넓은 지형과 같은 복잡한 시스템을 가진 대규모 게임을 어떻게 처리하는지입니다.

다음은 저, 제 의견 및 경험, _YMMV_에 관한 것입니다.

모든 엔진에는 고유한 특성이 있으며 Godot도 다르지 않습니다. 솔직히 말해서 첫 번째 안정적인 릴리스 이후로 얼마나 오래되었는지 감안할 때 얼마나 좋은지, 얼마나 빨리 발전했는지에 대해 확실히 압도됩니다. 그것이 우리가 가지고 있는 몇 가지 문제에 대한 이유일 수 있습니다. 씬/노드 시스템은 제가 가장 좋아하는 부분이고, 스크립팅된 노드의 단순함이 저를 빛나게 하는 부분입니다. 나에게는 단점이 있지만 파이썬과 같은 구문을 싫어하고... 미리 로드하는 시스템은... C#을 작동시키는 방법을 알아낼 수 없었습니다.

Unity 4/5를 예로 들면(몇 년 동안 연결되어 있음) _구성 요소가 너무 부풀려서 내가 사용한 다른 ECS와 비교할 수 없습니다. 그리고 오, 당신은 http 요청을 하시겠습니까? 물론, 장면 구조의 새 개체에 새 구성 요소를 추가합니다. 장면 내 개체 및 해당 구성 요소와 http 요청을 연결하는 것이 매우 합리적이기 때문입니다. "변경 사항 없이 장면을 저장하면 모든 UUID가 중단됩니다" 기능은 비기술적인 디자이너가 버전 제어를 사용하기 어렵게 만들기 위해 만들어졌습니다. "Don't Destroy On Load"와 조립식을 시작하고 싶지도 않습니다.

어쨌든 그 대부분의 것들 사이에 근거가 무엇이었습니까? 나는 그것이 아마도 유기적이고 반복적인 개발과 여기저기서 해킹된 해결 방법이라고 말하고 싶습니다(Godot 및 아마도 다른 모든 게임 엔진에서도 발견됨). 내 말은, "_With_"를 입력할 때마다 내 Swift 키보드가 "_Unity crashing_"라는 단어를 예측하기 시작했을 정도로 충돌이 심했습니다. 그것은 내 작업 흐름의 주요 부분이었습니다. 충돌 -> 1분 동안 모든 자산을 다시 가져오고 30분 동안 작업을 반복합니다.

신성모독적인 행동을 너무 많이 보았지만 누구를 탓할 수 있겠습니까? 엔진은 사람들이 pointlight 개체 안에 _GameState_ "_component_"를 넣을 수 있도록 합니다. 우리는 그것을 금지해야합니까? http 통신(또는 거의 모든 비동기 작업)이 필요할 때 게임 상태 데이터가 장면 개체의 구성 요소 내부에 있어서는 안 된다고 어떻게 주장합니까?

다른 개발 단계에서 엔진을 비교하는 것은 어려운 일이며 실제로 Godot는 빠르게 발전하고 기능을 추가/제거하고 있습니다. 즉, 워크플로가 그에 따라 변경되고 적응해야 합니다. 나는 Godot와 함께 괜찮은 2D 워크플로를 가지고 있습니다. Unity로 했던 것보다 확실히 낫습니다. 예, 모범 사례는 흐립니다. 예, 세 명의 개발자에게 물어보면 세 가지 다른 워크플로가 있습니다. 그러나 그것이 나에게 새로운 문제라고 말할 수는 없으며 최소한 비교된 두 엔진 모두에 하나의 문제가 있다고 말할 수 없습니다.

저는 프로토타입 및 테스트 프로젝트 이상으로 Unreal(또는 기타 관련 게임 엔진)을 사용해 본 적이 없으므로 합리적인 깊이와 비교할 수 없습니다.

하지만 어떤 면에서?
저는 이미 모든 스크립트에 대해 자식을 만들 수 없다는 것을 알고 있습니다. 왜냐하면 저는 백만 개 이상의 함수가 필요하고 백만 개의 빈 노드라도 Godot에게는 너무 많기 때문입니다.
그게 무슨 뜻인가요? 얼마나 많은 기능을 함께 그룹화해야 합니까? 아니면 종이에 개체 상속을 계획하는 데 2-4개월을 소비해야 합니까?

모든 기능을 하나의 스크립트에 넣을 수 있습니까? Godot는 객체 지향적으로 매우 잘 사용될 수 있으므로 OOP를 사용한 적이 있다면 스크립트나 장면 상속을 사용하고 클래스를 만드는 등의 작업을 할 수 있습니다.

내가 알고 싶은 것은 Godot가 날씨 효과, 체적 안개 및 넓은 지형과 같은 복잡한 시스템을 가진 대규모 게임을 어떻게 처리하는지입니다.

날씨 영향? 파티클 노드, 태양 및 세계 환경을 포함하는 장면을 만들고 스크립트를 루트에 첨부합니다. 이 스크립트는 날씨를 제어할 수 있습니다. 또한 빈 노드를 만들어 상태 머신으로 사용할 수 있습니다. 각 상태(예: 비, 햇빛 등)에 대해 빈 노드를 연결합니다. 이제 노드에 각 상태에 대한 코드를 넣으면 됩니다. 이 상태 머신은 루트 스크립트로 제어할 수 있습니다. 이것은 매우 읽기 쉬운 일을 하는 방법입니다.

체적 안개? 나는 이것을 새로운 FPS 데모에서 본 것 같다.

넓은 지형? 한 번 절차적 지형 메쉬를 사용한 프로젝트가 있었고 몇 년 된 노트북에서 꽤 원활하게 실행되고 있었습니다.

이것들은 OP에서 말하는 '큰 문제'가 아닌 일부 기능일 뿐입니다.

날씨 영향? 파티클 노드가 포함된 장면 만들기...

글쎄, 우리는 그보다 조금 더 야심 찬 계획을 가지고 있습니다 :) AI에게 어디로 걸어야 하는지 알려주는 지역 지도를 사용하고 시간이 지남에 따라 눈이 쌓일 수 있도록 깊이에 대한 마지막 채널을 유지하면서 다른 채널을 비 제외 구역으로 사용합니다.

넓은 지형?

공간이 큽니다. 너무 많은 노드를 제거해야 하기 때문에 정지 없이 장면을 Vector3(0,0,0)으로 재설정하는 방법이 필요합니다. 물리학과 모든 것이 큰 수레와 함께 흔들립니다.

그것은 내가 사용한 다른 ECS와 비교할 수 없을 정도로 부풀려진 구성 요소를 가지고 있습니다.

동의합니다. 구성 요소가 끔찍할 수 있으므로 Godot가 다른 전략을 염두에 두고 있다고 해도 놀라지 않을 것입니다. 그러나 Godot가 어떤 전략을 세웠는지, 실제로 그렇게 했는지는 알 수 없습니다.

Godot를 배운지 2개월 동안 우리는 작은 게임을 만드는 방법만 생각했습니다.
Godot를 사용할지 결정할 날이 14일 남았는데, 엔진 개발자가 대규모 프로젝트에서 어떻게 작동하는지 설명할 수 있기를 바랍니다.

우리가 마지막으로 하고 싶은 것은 게임을 개발하는 동안 엔진 디자인에 맞서 싸우는 것입니다.

@MysteryGM 왜 Godot를 큰 프로젝트에 사용할 수 없다고 생각하시는지 정말 이해가 안됩니다. 이 디자인은 모든 것을 별도의 장면으로 분할하고 OOP를 사용하여 작업을 재사용할 수 있기 때문에 큰 프로젝트에 적합합니다. 큰 프로젝트에 Godot를 사용할 때 문제가 목표를 달성하는 방법을 모른다는 것이라면 Godot Discord 도움말 채널에 질문하면 매우 즉각적인 응답을 받을 수 있습니다.

물리학과 모든 것이 큰 수레와 함께 흔들립니다.

#288 참조

그러나 Godot가 어떤 전략을 세웠는지, 실제로 그렇게 했는지는 알 수 없습니다.

나는 그것이 처음에는 일종의 외계인이라는 것을 이해하지만 나에게 노드 + 스크립트 사용법은 매우 간단합니다. https://gumroad.com/gdquest 에서 이 과정의 취미 버전을 (적어도) 살펴보는 것이 좋습니다.
그것은 나와 매우 유사한 노드 스크립트 구조를 사용하며, 실제로 엔진과 관련된 사람들이 그것을 사용하는 방법에 대한 더 나은 통찰력을 확실히 제공할 수 있습니다. 저자는 Godot 문서의 주요 기여자입니다.

편집: 실제로 https://github.com/GDquest/make-pro-2d-games-with-godot 과정을 원하지 않는 경우 저장소의 소스를 살펴볼 수 있습니다.

Godot를 사용할지 결정할 날이 14일 남았는데, 엔진 개발자가 대규모 프로젝트에서 어떻게 작동하는지 설명할 수 있기를 바랍니다.

나는 이것이 정확히 무엇을 의미하는지에 대해 약간 혼란 스럽다고 생각합니다. 이전에 망치 비유를 예로 사용했지만 망치는 일반적으로 일회용 기본 실용 도구이고 어포던스로 인해 도구의 용도에 대한 본질적인 이해가 있기 때문에 결함이 있는 비유입니다.

또한, 위의 모든 시스템의 모든 문제를 나열했지만, 큰 소프트웨어 프로젝트의 현실은 각 아키텍처 '선택'이 향후 몇 가지 단점을 초래한다는 것입니다. 함께 더 많은 작업을 수행합니다. 은색 총알 제안을 찾고 계십니까? 솔직히 말해서, 저는 대부분의 Unity 또는 Unreal 프로젝트가 정확한 '권장' 구조를 따르고 있다고 생각하지 않으며 종종 가장 적합한 워크플로에 맞게 엔진을 포크합니다. 모든 게임에는 노드 아키텍처에 대한 고유한 아이디어가 있어야 한다고 주장하기까지 했습니다. (예를 들어 시뮬레이션 게임은 3인칭 슈팅 게임과 구조가 매우 다릅니다.)

프로젝트 구조의 예에 대한 더 많은 문서화에 대한 논쟁이 있을 수 있다고 생각합니다. 하지만 그건 문서화에 대한 더 많은 기여의 문제일 뿐입니다.

장면을 분리하고 OOP를 사용하여 작업을 재사용합니다.

앞서 언급했듯이 신호가 연결된 후 물체를 움직이는 것은 고통스럽습니다. 특히 예외나 경고 없이 작업을 중지할 때.
다른 개발자가 언급한 후 타사 리팩토링 도구를 사용하기로 결정했습니다. 하지만 그렇다고 해도 Godot의 고유한 문제를 해결할 수는 없습니다.
물건을 움직이지 않으면 이 문제가 발생합니다("문제 게시판"의 이미지).

그래서 이것을 수정하기 위해 우리는 자식 노드를 만들었습니다. 약 50,000개를 제외하고는 노드일지라도 문제를 일으키기 시작합니다.

우리가 알고 싶은 것은 이러한 문제를 해결하는 방법, Godot는 이러한 문제를 어떻게 처리할 계획이었는지입니다. 위에서 언급한 모든 워크플로를 테스트했습니다.

#288 참조

덕분에 우리는 세계 좌표를 쉬는 데 너무 익숙해서 이것을 확인하지 않았습니다.

나는 그것이 처음에는 일종의 외계인이라는 것을 이해하지만 나에게 노드 + 스크립트 사용법은 매우 간단합니다.

문제는 그것이 외계인이라는 것이 아니라 다른 문제를 일으킨다는 것입니다. 주로 더 많은 자식을 추가하면 결국 게임이 지연되거나 언로드하려고 할 때 멈춥니다.
노드일 때도 마찬가지입니다.

게임에 50,000개의 개체가 필요한 이유는 무엇입니까? 확실히 이것은 모든 엔진을 지연시킬 것입니다.

게임에 50,000개의 개체가 필요한 이유는 무엇입니까?

노드를 사용하여 개체에 추가 스크립트를 추가하기 때문입니다. Godot의 UI 도구는 컨테이너 안의 컨테이너를 컨테이너 안의 컨테이너를 사용하기 때문에... 실시간으로 규모를 조정합니다.
가장 작은 UI는 800개가 넘는 개체입니다. 이 컨테이너의 대부분.

단일 적 AI는 목적이 있는 +/- 8개 노드와 거기에만 있는 +/- 64개 노드이기 때문에 50,000개 개체가 있습니다.
각 작업을 자체 코드로 분할하여 문제가 있는 위치를 볼 수 있기 때문입니다. 게임의 특정 부분을 빠르게 찾을 수 있는 다른 방법이 없기 때문입니다.

이 경우 사용자 지정 모듈이 좋은 옵션인 영역에 침입한 것 같습니다.
http://docs.godotengine.org/en/3.0/development/cpp/custom_modules_in_cpp.html
거기에서 사용자 정의 노드를 만들고 많은 중첩을 피할 수 있습니다.

편집: 하나의 (가장 작은?) UI에 대해 800개의 개체가 나쁜 디자인/아키텍처를 가리킨다고 주장하고 싶습니다.

단일 개체에 대해 64개에 가까운 스크립트를 가질 수 있는 방법을 심각하게 이해하지 못합니다. 이것은 Godot 문제보다 프로젝트의 디자인 문제에 더 가깝습니다. 코드를 더 적은 수의 스크립트로 통합합니다. 기능의 각 부분에 대한 스크립트를 만들지 말고 대신 각 유형의 개체에 대해 ("적" 노드가 XYZ를 수행할 수 있는 경우 X 및 Y 및 Z 기능에 대한 자식 노드를 추가하는 대신 해당 부분을 Enemy 스크립트에 추가하십시오) . 이를 위해 더 많은 고급 기능이 필요한 경우 사용자 지정 상속 및/또는 C# 인터페이스를 사용할 수 있습니다.

이 경우 사용자 지정 모듈이 좋은 옵션인 영역에 침입한 것 같습니다.

이것이 우리가 궁금해하는 것 중 하나였습니다. 왜냐하면 Custom Modulse가 필요한 경우 우리 모두가 C++를 알고 있기 때문에 대신 Godot 엔진을 편집할 것입니다.
우리는 Godot preload()가 의심되는 곳에서 #include를 안전하게 사용할 수 있다는 것을 압니다. 그것이 얼마나 안정적인지 또는 어떤 단점이 있는지 아무도 우리에게 말할 수 없습니다.

단일 개체에 대해 64개에 가까운 스크립트를 가질 수 있는 방법을 심각하게 이해하지 못합니다.

간단합니다. 모든 AI는 사소한 작업이 아니라 64개 정도의 작업을 수행할 수 있습니다.
예를 들어 스크립트는 SquadFlightPatters이고 여기에는 20개의 모든 비행 대형이 있으며 비행 패턴과 관련된 애니메이션, 사운드 및 입자만 해결하는 SquadFlightPattersCosmetic이 있습니다.

현재 우리의 규칙은 사용자 피드백을 정비사로부터 나누는 것입니다.

"Enemy" 노드가 XYZ를 수행할 수 있는 경우 X 및 Y 및 Z 기능에 대한 자식 노드를 추가하는 대신 해당 부분을 Enemy 스크립트에 추가합니다.

이미지와 Pseudo Unreal, 일명 컨트롤러 및 중개자를 보면.

Custom Modulse가 필요한 경우 우리 모두는 C++를 알고 있기 때문에 대신 Godot 엔진을 편집할 것입니다.

모듈을 만드는 것이 엔진 자체를 변경하는 것보다 훨씬 간단합니다. 엔진 자체가 아니라 그 위에 구축되기 때문입니다.

그러나 위젯당 수백 또는 수천 개의 노드가 있는 UI, 특히 이러한 높은 숫자로 확장하는 것은 여전히 ​​상상할 수 없습니다.

OP의 참조된 문제에 대한 응답:

• 19486 :

  • 자산의 시스템 전체 설치로 적절한 종속성 관리를 추가합니다. 수정을 위해 다시 가져올 수 있는 방법으로 애드온을 프로젝트 자체 밖으로 이동
  • 사용자 정의 노드를 더 쉽게 확장하고 언어 간 스크립트 상속을 허용합니다.
  • 자산의 경우 매우 긴 경로를 피하기 위해 클래스 이름과 네임스페이스로 스크립트를 참조할 수 있습니다.

  스크립트 클래스는 마지막 문제를 해결합니다. 다른 스크립트의 별칭 역할을 하는 상수를 사용하여 최상위 스크립트 클래스를 만들어 네임스페이스를 만들 수 있습니다. 3.1에서 에디터의 씬 독에 대한 변경 사항으로 인해 이제 사용자 정의 스크립트를 훨씬 쉽게 확장할 수 있습니다. 교차 언어 상속에 관해서는 공식적으로 구현되지는 않겠지만 MultiScript가 다시 도입되면 합리적으로 잘 속일 수 있습니다.

• 7402 : 다시 말하지만, 스크립트 클래스는 이 문제에 대한 솔루션입니다(이 문제의 최종 설명을 보면 reduz가 생각한 "간단한 솔루션").

• 15996 : 이것은 내가 원했던 것이 특성 시스템이라는 것을 깨닫고 (특성이 무엇인지 이해하기 전에) 결과적으로 장면과 노드의 대상 디자인을 완전히 왜곡하고 전체를 변환하기 때문에 초기 제안이 얼마나 완전히 끔찍했는지 깨달았습니다. 컴포지션 기반 상속 시스템에 대한 것 - Unity가 실제로 하는 것과 유사한 것, 역겹습니다(Unity에서는 모든 COMPONENT에서 getComponent를 사용할 수 있으며 소유하는 GameObject의 형제 구성 요소를 가져옵니다. GameObject의 확장, 종속성을 서로 푸시함).

• 8502 : MultiScript는 UE4의 블루프린트가 C++ 스크립트에서 직접 상속할 수 있는 방식과 유사하게 서로 다른 스크립팅 언어가 서로 상속되도록 하기 위한 도구일 뿐입니다. VisualScript는 애초에 상속을 지원하지도 않습니다. 그래서 GDScript가 여기에서 더 적절한 비교입니다).

  이제 MultiScript는 기본 엔진 유형을 확장하는 모든 스크립트를 기본적으로 지원하므로(따라서 모두 다른 작업을 수행하지만 서로 관련이 없는 다른 언어의 여러 노드 확장 스크립트를 가질 수 있음) 실제로 거의 다음과 같이 작동합니다. 교차 언어 특성 시스템... 일종의. 나는 MultiScript를 다시 추가하는 것이 꽤 멋지다고 생각합니다.

OP에서 제기된 많은 문제는 문제를 해결할 수 있는 여러 가지 잠재적인 방법이 있으며 각 방법에는 다양한 비효율성이 있을 수 있습니다. 일반적으로 가장 최적의 작업을 수행하는 특정 방법이 있는 경우 엔진은 기본 C++ 엔진에서 자체 구현을 제공하며(스크립트나 플러그인이 필요 없음) 이것이 제안된 사용법입니다.

그러한 클래스가 존재하고 사람들이 그것을 사용하지 않는다면, 그것은 1) 그들이 그들의 요구가 이미 엔진에 의해 충족되었는지 확인하기 위해 문서를 적절하게 확인하지 않고 있다는 신호입니다/엔진이 그것을 사용하도록 제안하는 방법 또는 2) 엔진/조직은 사용자가 문서를 잘 볼 수 있도록 하거나 사용자가 액세스할 수 있도록 하는 데 충분한 작업을 수행하지 않습니다(존재하는 리소스를 찾지 못하기 때문에).

문제 1을 해결하기 위해 할 수 있는 유일한 일은 해당 사람들이 자신의 문제를 목소리로 표현하고 다른 사람이 문서 또는 Q&A 사이트로 리디렉션하여 솔루션을 찾는 데 도움을 주는 것입니다. 나는 사람들이 문제 2에 많은 도움이 될 편집자에서 직접 Q&A 사이트를 탐색하고 사용할 수 있도록 제안하는 문제(#23043)를 만들었습니다. 이유는 링크에 설명되어 있습니다.

(편집: 문제를 해결하는 방법은 여러 가지가 있고 그 방법 중 하나가 다른 방법보다 훨씬 낫고 Godot가 아직 고유한 솔루션을 구현하지 않은 경우 새로운 기능으로 제안 할 수 있습니다. 이것은 사람들이 GDScript / 셰이더 코드 등에서 자신의 SimplexNoise 알고리즘을 작성했기 때문에 SimplexNoise 항목을 추가한 방법입니다.

당신이 묘사한 "문제 게시판"에 따르면, 당신이 겪고 있는 문제는 다중 상속이 지원되지 않는다는 것입니다(좋은 생각도 아닙니다). 그래서 당신은 부모에게 기능을 부여하는 구성 요소 노드를 사용했습니다. 단순히 너무 많은 노드를 생성하기 때문에 게임 지연 문제가 발생하는 경우 일반적인 접근 방식에 문제가 있을 가능성이 더 높은 것 같습니다. 여기에서 식별하기 위해).

OP의 워크플로 예는 ...

• Unity 접근 방식, 자식 노드:

  페어링 논리를 작성한다고 가정하면 자식 노드를 사용하는 것이 합리적입니다. 이것은 특성 시스템이 유용할 이상적으로는 짝짓기 로직을 ​​한 번 작성하고 필요에 따라 어디에서나 복제할 수 있도록 하는 것입니다. 나는 종종 부모가 부모/양부모가 아닐 때 자동으로 부모에 대한 "대상"으로 설정되고 관련 신호를 자동 연결/연결 해제하는 방식으로 구성 요소를 작성합니다. 이를 위해 _notification(what) 의 NOTIFICATION_(UN)PARENTED 알림을 사용할 수 있습니다.

• 컨트롤러를 사용한 UE4 접근 방식:

  Godot 3.1을 사용하면 스크립트에 스크립트 클래스를 할당할 수 있으므로 더 이상 미리 로드할 필요가 없습니다. 이 경우 Godot는 노드에 유형 이름을 할당하는 것을 허용하지만 스크립트에 따라 다르므로 주의해야 합니다. 장면은 동일한 처리를 받지 않으며 아마도 엔진 코어에 많은 항목을 추가해야 하기 때문에 그렇지 않을 것입니다.

  나는 또한 어떻게 그렇게 많은 중복 코드를 얻고 있는지 잘 모르겠습니다. 여러 클래스에 동일한 로직이 필요한 경우, 해당 로직을 단일 노드로 묶은 다음, Unreal(구성 요소, 자식 액터), Unity(MonoBehaviours 또는 자식 GameObjects)에서와 동일한 방식으로 해당 로직을 필요로 하는 클래스 아래에 해당 노드를 재생산합니다. , 또는 코드 재사용을 줄이기 위해 종속성을 소유 개체로 이동하는 거의 모든 다른 엔진.

• 사전 로드가 있는 Panda3D 접근 방식:

  NodeRef 가 아직 존재하지 않기 때문에 이 접근 방식에 많은 문제가 있다는 것을 이해할 수 있었고 현재 3.2에서 수정 하기를 바라는 리소스 스크립트를 내보내는 데 문제가 있음을 이해할 수 있습니다(비록 직접 수정할 수도 있지만 충분히 쉽게, 그것은 꽤 작습니다).

• WTF 스크립트 접근 방식:

  나는 당신이 여기서 겪고 있는 모든 문제를 정말로 이해하지 못합니다. 아마도 우리에게 많은 맥락이 없기 때문일 것입니다.

  인스턴스 시스템과 충돌합니다. 신호가 가장 위쪽으로 연결되는 동안 인스턴스가 아래로 흐르기 때문입니다.

  자손에서 부모의 신호 트리거 동작을 원할 때는 언제입니까? 부모가 직접 자손과 그 메서드를 가져와 호출하도록 하지 않는 이유는 무엇입니까? 부모가 아이를 볼 위험이 없습니다. C++ 객체가 구조체 또는 클래스 멤버 변수(?)에 액세스할 수 없어야 한다고 말하는 것과 같습니다.

  작은 무의미한 스크립트가 주위를 배회합니다. 그들이 하는 모든 일은 신호를 보내고 단일 값을 추적하는 것입니다.

  이것은 이미 프로젝트의 디자인이 좋지 않다는 신호입니다. 게임의 모든 단일 상호 작용을 고유한 개인 개체로 추적하는 것이 문제입니다. 이것은 어떤 관점에서 보아도 이상적이지 않습니다.

  너무 많은 신호가 첨부된 개체를 이동하는 것은 최소한 실망스럽습니다.

  어떤 방법으로? 나는 일반적으로 장면 파일의 연결을 하드코딩하거나 노드가 이동하려는 경우 신호를 알고리즘 방식으로 연결 및 연결 해제한다는 것을 발견했습니다. 그것으로 제 목적을 충분히 달성했지만, 특정한 문제가 있는 경우 이를 공유하면 다른 사람들이 도움을 받을 수 있습니다.

  신호 및 그룹을 사용하면 경고 없이 게임의 전체 부분이 실패할 수 있습니다.

  따라서 존재 설계를 통한 모든 부울의 문제입니다. 대안은 ALL 개체를 반복하여 기준과 일치하는지 확인한 다음 일치하는 경우 논리를 수행하고 일치하지만 적절하지 않은 경우 오류를 throw하는 것입니다. 신호 및 그룹의 경우 집합 내의 모든 항목에 대해 동작이 자동으로 트리거되므로 집합을 벗어나는 경우 실행 시간 동안 문제가 발생했음을 감지할 방법이 없습니다. 이러한 종류의 문제를 찾는 유일한 방법은 그룹/신호가 처음에 배열되는 설정 프로세스 동안입니다.

어쨌든, 그것은 물건에 대한 나의 모든 경험이었습니다. 특정 사용 사례에 대한 제안을 제공할 수 있도록 귀하의 프로젝트와 프로젝트가 실제로 하는 일 에 대해 더 많이 아는 것이 훨씬 더 도움이 될 것입니다.

어느 쪽이든, 여기에서 제기한 문제는 Godot 엔진의 설계 또는 구현 자체에서 "새로운" 문제로 보이지 않습니다. Godot는 사람들에게 API를 제공하고 사람들이 그 API를 사용하는 방법은 그들에게 달려 있습니다. Godot에서 특정 기능을 어떻게 더 통합/사용 가능하게 만들어야 하는지에 대한 아이디어가 있다면(예: MultiScript 다시 활성화), 그것은 좋은 제안이 될 것입니다.

그러나 여기서 질문은 "X와 같은 시스템을 설계하는 가장 좋은 방법은 무엇입니까?"에 더 가깝습니다. 이는 실제로 GitHub 문제가 아닙니다. "모범 사례" 종류의 질문에 대한 Q&A 사이트에서 더 적절해 보입니다. 또는 이러한 종류의 사용 사례별 정보를 보다 명확하고 공개적으로 사용할 수 있는 방법을 제공해야 한다는 제안입니다. 이것이 바로 제 Q&A 문제에 관한 것입니다.

스크립트 클래스는 마지막 문제를 해결합니다.

먼저 긴 답변에 감사드립니다. 글을 쓰는 데 시간이 많이 걸렸습니다.
스크립트 클래스에 대해 듣게 되어 기쁩니다. 우리는 3.1을 사용하지 않았습니다. FPS 데모를 실행하기 위해서만.

그러나 MultiScript가 다시 도입되면 합리적으로 잘 속일 수 있습니다.
Godot가 멀티스크립트를 구현하지 않는다면 완전히 이해할 수 있습니다. 사실 나는 GitHub의 많은 사용자들이 우리가 시도한 것과 유사한 워크플로 솔루션을 찾고 있다는 점을 지적하고 있었습니다.

자손에서 부모의 신호 트리거 동작을 원할 때는 언제입니까? 부모가 직접 자손과 그 메서드를 가져와 호출하도록 하지 않는 이유는 무엇입니까?

이것을 설명해야 할 것 같습니다. 당시 우리는 각각 대략 +/- 30개의 기능을 가진 매우 큰 스크립트를 가지고 있었습니다. 그런 이유로 우리는 이미 큰 스크립트에 추가 신호 기능을 추가하는 것을 피하고 싶었습니다.
그 결과 큰 스크립트에서 작업을 오프로드하기 위해 느슨한 스크립트를 만들었습니다.

이것은 이미 프로젝트의 디자인이 좋지 않다는 신호입니다.

그것이 바로 문제의 근원입니다. 주로 Godot 커뮤니티와 튜토리얼에서 추천하는 많은 디자인을 시도했습니다.
1.) 처음에 우리는 미친 유산을 가지고 있었는데, Save Branch Scene 이나 객체를 다른 Scene으로 이동하는 것이 신호를 끊었다는 것이 분명해졌을 때 빨리 포기했습니다.
2.) 우리는 이것을 큰 스크립트로 따랐습니다. 이러한 스크립트의 추상적인 이름을 제외하고 각각이 수행하는 작업을 설명하고 문제를 찾기가 어려웠습니다.
우리는 문제를 일으키는 함수의 이름이 어디에 있는지 알고 있었지만 정확히 어디에 있는지는 알지 못했습니다.
3.) 그런 다음 매뉴얼을 읽고 자식 노드 접근 방식을 찾았습니다. 직접 노드를 허용하고 편집기에서 구조를 볼 수 있기 때문에 너무 유혹적이었을 수 있습니다. 또한 우리가 원하는 정확한 스크립트를 찾기 위해 그것을 필터링합니다.

여기에서 나와 함께 끝내고 마지막 답변은 내가 궁금했던 많은 부분을 해결했다고 생각합니다. 여기가 새벽 2시이므로 내일 다시 확인해야 합니다.

"X와 같은 시스템을 설계하는 가장 좋은 방법은 무엇입니까?"... 실제로 GitHub 문제가 아닙니다.

나는 우리가 우리의 다른 선택의 대부분을 소진했다는 것을 지적하고 싶습니다. 우리 각자는 Q&A 포럼에서 질문하고 커뮤니티에서 친구를 사귀고 그들로부터 사례를 수집했습니다. 설명을 찾기 위해 문서를 스캔했습니다.
내가 설명한 모든 워크플로는 이러한 워크플로를 사용하는 Godot 사용자가 설명하려고 시도한 것입니다. 각각은 언급된 엔진에서 작동하지만 Godot에서는 잘 작동하지 않았습니다.

메인 프로그래머가 테이블에 머리를 부딪치고 흉내를 내서 누군가를 목 졸라 죽이는 것을 제외하고는 마지막 워크플로 종류만 작동했습니다.

문제에 대한 해결책을 찾는 데 문제가 있다는 소식을 접하게 되어 유감입니다. Will은 이미 긴 답변을 제공했으므로 대화를 너무 복잡하게 만들지 않으려고 노력할 것입니다. 그러나 이 시점에서 귀하의 요구에서 발생한 특정 문제를 해결하는 데 도움이 되는 컨설턴트가 더 필요할 것 같습니다.

주로 Godot 커뮤니티에서 추천하는 많은 디자인과 튜토리얼에서 나온 디자인을 시도했습니다.

지역 사회의 우리 대부분은 비교적 작은 규모의 프로젝트에서 일합니다. 튜토리얼에서 주어진 시스템의 요점과 구조를 파악하는 데 도움이 되도록 많은 노드를 사용합니다. 이것은 대부분의 사람들에게 잘 확장될 것입니다. 그러나 중소 규모 게임에 적용되는 것이 더 큰 게임에는 적용되지 않습니다.

@willnationsdev 가 앞서 말한 대로 성능 면에서와 편집기 자체에서 관리할 코드를 줄이기 위해 게임 확장에 도움이 되는 백엔드 코드를 고려하는 것이 좋습니다. 여기 많은 사람들과 마찬가지로 저는 더 큰 프로젝트에 대한 경험이 없기 때문에 그 외에 많은 도움을 드릴 수 없습니다. 행운을 빕니다!

안녕하세요, 질문이 하나 더 있습니다.

건물과 물과 같은 두 개의 관련 없는 개체가 있지만 이러한 개체의 스크립트가 상호 작용하기를 원하는 경우 노드나 사전 로드 없이 어떻게 이를 수행합니까?
물은 질감이라 건물에도 부딪히지 않는다.

@MysteryGM 건물과 물을 나타내는 노드를 원하지 않거나 스크립트가 첨부되는 것을 원하지 않는다는 말씀이신가요? 노드를 포함하는 단일 데이터를 제외하고는 장면 트리 내에 어떤 식으로든 존재하지 않는 처리용 데이터를 갖는 데에는 아무런 문제가 없습니다.

ECS 접근 방식을 사용하려는 경우 유형의 모든 인스턴스에 스크립트를 첨부하고 개별적으로 처리하는 대신 유형/유형에 따라 노드를 반복하고 처리를 수행하는 단일 "시스템" 노드를 가질 수 있습니다. 할당한 그룹입니다. 개별 세부 정보를 위해 노드에 스크립트를 첨부하지 않으려면 시간에 따라 해당 정보를 시스템에 저장할 수도 있습니다. 이렇게 하면 노드의 무게가 가벼워지고 동일한 유형의 수천 개의 엔터티에서 작업할 때 더 효율적일 수 있습니다.

50.000 개의 항목을 가지고 있으면 Godot의 SceneTree -and-nodes 객체 기반 은유가 유용한 지점을 오랫동안 초과했습니다.

이는 다른 엔진과 크게 다르지 않습니다. Unity를 사용하면 게임 개체, GC에서 비슷한 한계에 도달하거나 UE4를 사용하여 블루프린트를 확장 하는 데 문제가 있음을 발견할 수 있습니다. 시각적 편집기는 더 이상 유용하지 않으며 제공된 도구가 중단되거나 최소한 성능이 저하되기 시작합니다.

모든 엔진에서 솔루션은 거의 동일합니다. 자신만의 솔루션을 구축하는 것입니다. 그것들이 무엇인지는 엔진보다 게임, 아키텍처 및 세부 사항에 따라 다릅니다.

관리자 클래스, pub-sub 통신 버스, 메시지 브로커, 파티클에 대해 수행되는 것과 유사한 인스턴스 관리자, 개체 풀, GPU로 작업을 오프로드하기 위한 사용자 정의 셰이더, 셰이더 계산, 스레드 또는 기타 프로세스/서버로 처리 이동 - 다음이 있습니다. 가능한 솔루션을 위한 수많은 빌딩 블록과 결합해야 하는 빌딩 블록은 특정 문제 세트에 따라 다릅니다.

Unity는 새로운 ECS 인프라를 통해 이 중 일부를 더 쉽게 만듭니다. UE4는 확실하지 않습니다. 결국, 이 고급 수준에서는 대부분의 힘든 일을 스스로 해야 합니다(또는 경험이 풍부한 사람을 고용하여 수행해야 함).

UE4와 Unity는 더 오래되고 더 확립되어 있다는 점에서 더 쉽습니다. 따라서 이러한 확장 문제에 직면하는 사람들이 더 많습니다. 이는 해결에 더 많은 지식(및 고용 가능한 인재)을 사용할 수 있음을 의미합니다.

그러나 실제로, 결국에는 어떤 엔진도 당신 을 그렇게 멀리 데려다주지 못할 것입니다. 모든 야심 찬 게임은 모든 엔진에서 한계에 부딪힐 것입니다. 비슷한 문제를 해결하는 데 필요한 UE 또는 Unity의 중대형 게임에 대한 수십 개의 예제를 알고 있습니다. 문제를 해결하거나 범위를 축소하십시오.

Godot 게임 개발자가 엔진 개발자에게 필요한 것은 복잡한 개체와 시스템을 만들기 위한 공식 워크플로의 명확한 감속입니다.

이는 주로 게임에 따라 다릅니다. 대형 엔진에는 이에 대한 정답이 없습니다.
Unity에서 gameobjects-scene 기반 접근 방식을 사용해야 합니까? 아니면 하이브리드 ECS? 완전히 새로운 ECS? 어떤 렌더 파이프라인을 사용합니까?
UE4 프로젝트에서 Blueprint 또는 C++를 사용하시겠습니까?

모든 엔진에 맞는 솔루션이 없기 때문에 모든 엔진은 수많은 선택, 수많은 워크플로 및 많은 자유를 제공합니다.

따라서 Godot에서 특정 게임에 접근하는 방법 , 게임을 구성하는 방법, 사용할 아키텍처에 대한 구체적인 조언 이 필요한 경우 더 많은 컨텍스트와 정보를 제공해야 합니다.

당신이 성취하고 싶은 것이 무엇인지 알려주십시오. 그러면 누군가가 조언을 해줄 수 있습니다. 그렇지 않다면 유일한 방법은 경험 많은 Godot 개발자를 컨설턴트로 고용하는 것입니다.

나는 Groud에만 동의할 수 있습니다.

모든 솔루션에는 장단점이 있으므로 "공식" 워크플로를 만드는 것은 의미가 없습니다.

@mhilbrunner 여기에서 악마의 옹호자 역할을 하는 것만으로도 성능이 중요한 대부분의 통에서 적절한 ECS와 같은 더 나은 엔진 설계로 인해 거의 모든 게임에서 실제로 경험할 수 있는 것보다 많은 한계가 훨씬 더 높아집니다(이것이 새로운 Rust Amethyst 방식입니다. 게임 엔진은 예를 들어 집중하기 위해 구축 중입니다.

하지만 예, Godot(2)에서 ECS와 같은 작업을 수행했으며 효율성과 기능 분배 측면에서 씬트리 인스턴싱 스타일보다 훨씬 더 잘 작동했습니다. Godot에는 유용한 프리미티브가 없기 때문에 할 수 있습니다. 약간 고통스럽습니다.

@OvermindDL1

나는 다른 Godot 개발자가 아니라 나 자신에 대해서만 말할 수 있고 UE, Unity 및 Godot에 대한 경험만 있기 때문에 Rust Amethyst에 대해서는 모릅니다.

Godot에는 유용한 프리미티브가 없기 때문에 할 수 있습니다. 약간 고통스럽습니다.

그러한 프리미티브를 어디에 추가하는 것이 의미가 있는지 / Godot가 그러한 사용 사례를 더 잘 수용할 수 있는 방법에 대해 토론하는 것은 매우 가치 있다고 생각합니다. 이 문제에는 없을 수도 있습니다 :)

그러나 우리는 이 피드백을 어떤 식으로든 수집해야 합니다.

그리고 엔진에 따라 한계가 다르다는 점에는 동의하지만, Unity와 UE4에서도 비슷한 장벽에 부딪히는 사람들을 보았습니다. 나중에 는 더 높을 수도 있지만 결국에는 모든 엔진에서 발생하는 문제를 해결할 수 있어야 합니다. :)

@MysteryGM 건물과 물을 나타내는 노드를 원하지 않거나 스크립트가 첨부되는 것을 원하지 않는다는 말씀이신가요?

나는 이미 물 셰이더에 공급하는 물 개체에 연결된 스크립트를 가지고 있습니다. 그래서 더 이상 워터 노드에 스크립트를 첨부할 수 없습니다.
자원 생산을 제어하고 문과 같은 것을 건물에 연결하는 스크립트가 건물에 첨부되어 있습니다. 따라서 더 이상 코드를 추가하고 싶지 않은 스크립트도 있습니다.

두 개체에 이미 코드가 있는 경우 이제 어떻게 해야 합니까? 노드를 더 추가할 수 없으며 사전 로드가 가능한 솔루션인지 여부는 여전히 불분명합니다.

OOP 디자인으로 표현하면 내 질문은 다음과 같습니다. 두 스크립트가 서로 인터페이스에 어떻게 액세스합니까?

문제는 GDscript가 다른 스크립트에 직접 액세스할 수 있는 방법이 없는 것처럼 보입니다.
불로 나무를 태우려면 나무->확장->불 또는 불->확장->나무가 있어야 합니다.

@MysteryGM : 한 가지 팁: 신호. 화재는 대상이 나무인 경우 신호 화상(대상)을 가질 수 있습니다.

두 스크립트가 서로의 인터페이스에 어떻게 액세스합니까?

$NodeWithScript.do_function() ?

_/저는 여전히 악마의 옹호자 역할을 하고 있습니다. 이것을 Godot에서 '해야 할' 일의 척도로 생각하지 마세요. 기껏해야 자전거 탈취입니다_

나는 다른 Godot 개발자가 아니라 나 자신에 대해서만 말할 수 있고 UE, Unity 및 Godot에 대한 경험만 있기 때문에 Rust Amethyst에 대해서는 모릅니다.

UE는 Actor SceneTree 모델을 사용합니다. Unity는 EC 모델을 사용했습니다(최근 ECS를 구축하고 이전 EC 모델을 더 이상 사용하지 않지만 아직 완전하지는 않지만 유망해 보입니다). 그리고 Godot는 Component SceneTree 모델을 사용합니다. ECS는 데이터 흐름 패턴의 하위 집합입니다(특히 이를 일반화한 것임).

ECS에 대한 간략한 요약:

• 대부분의 엔진은 생성 및 엔터티 인덱스를 단일 int32(8비트 생성 및 24비트 인덱스) 또는 int64 (각각 32비트, int64가 훨씬 더 일반적입니다. ECS가 실제로 허용하므로 '엔티티'는 정수 ID입니다. 그러한 상당한 양의 엔티티로 확장).

• ' C 구성 요소'는 C/C++ 용어의 POD 구조이며 기능을 포함해서는 절대 안됩니다. 일반적으로 간단하게 memcpy' 가능해야 합니다.

• 구성 요소 '테이블'은 구성 요소를 위한 저장소입니다. 가장 기본적으로 크기를 조정할 수 있는 배열일 수 있지만 일반적으로 몇 가지 유형이 사용되는 경향이 있습니다.

  • 크기 조정 가능한 배열: 위치와 같이 구성 요소가 매우 일반적일 때 자주 사용됩니다.
  • 희소 배열: 구성 요소가 한 번에 엔터티 그룹에서 사용되는 경향이 있을 때 자주 사용됩니다.
  • 매핑: 예상하는 성능 특성에 따라 해시 맵 또는 트리 맵 등일 수 있지만 일반적으로 덜 일반적인 구성 요소에 사용됩니다.
  • Bitsets: 구성 요소가 엔티티에 전혀 존재하지만 아무것도 저장하지 않는 경우에 대한 정의로 순수하게 사용되며 일반적으로 플래그 구성 요소라고 합니다.
  • Octree 또는 다른 SceneGraph(Godot의 렌더러가 여기에 적합할 수 있음): 구성 요소인 것처럼 가장하는 장면 트리 매핑.
  • Etc...: 구성 요소에 대해 예상되는 액세스 및 성능 특성에 따라 다른 많은 유형이 있습니다.

• ' 시스템'은 가장 기본적인 구성 요소 집합을 취하는 기능이지만 대부분의 라이브러리에는 가상이 아닌 클래스 또는 모듈 정도가 있지만 결합된 구성 요소 집합에 대해 작동하여 무언가를 '수행'합니다. 여기에는 구성 요소의 값 변경, 구성 요소 추가 또는 제거 등이 포함될 수 있습니다. 몇 가지 예:

  • 위치 및 변환 구성 요소가 있는 모든 엔터티를 사용하고 효율적이고 캐시 친화적인 방식으로 주어진 틱/시간에 필요한 변환으로 모든 위치 행렬을 변환하는 시스템입니다. 더 이상 수행할 변환이 없으면(엔티티가 정적이 됨) 변환 구성 요소가 엔터티에서 제거되고 더 이상 처리되지 않습니다.
  • 입력 시스템은 입력(마우스/키보드/게임패드 등...)의 이벤트를 수신하고 관련 엔터티에 추가되거나 다른 작업을 수행하는 구성 요소로 변환합니다.
  • Furnace 시스템(Minecraft 은유)은 Inventory, Fuel, RecipeMapping, BlockPos, Cooking 및 기타 구성 요소가 있는 엔터티를 사용하여 해당 엔터티를 반복하고 필요에 따라 관련 상태를 업데이트합니다. 어떤 플래그 구성 요소를 설정하기 위해 인벤토리가 다시 변경될 때까지 Cooking Flag 구성 요소가 더 이상 처리되지 않습니다.

내부적으로는 ECS를 데이터 매핑 설정을 구독할 수 있는 데이터베이스로 생각할 수 있지만 잘 만들어진 경우 매우 최적화되어 있습니다. 어떤 시스템이 다른 시스템보다 먼저 실행되어야 하고 어떤 시스템이 비중첩(읽기 또는 읽기/쓰기에 따라 다름)을 통해 작동하는지 알고 있으면 간단하게 다중 스레드 호출도 수행할 수 있습니다. (저는 Amethyst를 계속 사용하고 있으며 예를 들어 specs 라고 하는 ECS 특정 라이브러리 부분입니다. 제 오래된 C++ ECS 라이브러리를 이식하여 생성했기 때문입니다.) spec Book 은 'Why' ECS, ' How', 효율성, 용도 등... Amethyst는 특히 ECS가 일반 게임 시스템, 렌더링 등에 어떻게 사용되어야 하는지에 대해 더 자세히 설명합니다.

잘 작성된 C++ ECS 라이브러리를 보고 싶다면 https://github.com/skypjack/entt 를 살펴보십시오. 전반적으로(비교한 모든 항목에 대해 사양이 훨씬 더 우수하다는 점을 고려하면 인상적입니다).

ECS의 일반적인 '사용'은 '엔티티'(데이터가 없는 정수만 있음)가 있고 구성 요소를 엔터티에 매핑하는 테이블 집합과 실제로 작업을 수행하는 시스템이 있다는 것입니다. GDScript 의사 코드에서는 간단한 API라고 생각하지만, Scenetree가 염두에 두고 설계되지 않았기 때문에 Godot 장면 트리에 '통합'하는 약간 이상한 관례가 있습니다.

# All of this would generally be wrapped up in one or more function calls for easy
# building.

# Create a new entity
var e = createEntity()

# Map it to some Components, starting with a godot scenetree component
# I'm using long names to be descriptive, but eh...
var eNode = scenetreeComponentTable.set(e, SomeNodeType())
# Generally things like the transformation matrix and so forth would be their own
# components, but since the godot scenetree already bakes all that in then just
# deal with it all via the node type, you definitely lose a little efficiency doing
# it this way though since nodes involve multiple virtual calls to access and
# the usual ECS patterns entirely get rid of virtual calls with potentially only
# the occasional indirect calls inside a table (maps, etc...)

# 8x4 inventory slots
inventoryComponentTable.set(e, 8, 4)
# 1 fuel slot, accepts items that have the "burn" tag
fuelStorageComponentTable.set(e, 1, "burn")
# Give this entity the furnace component that uses the "basicFurnaceRecipes" recipes
furnaceComponentTable(e, "basicFurnaceRecipes")
# Add other components

# All of the above component mappings could also be in, say, a JSON file, and
# loaded something as such:
componentTables.map(e, "res://entity_types/basicFurnace.json")
# Or maybe via a preloaded JSON object or so

# Once at startup:

# And you could make a system something like, I'll use a GDScript class for this:
val furnaceCookSystemHandler = systems.register(FurnaceCookSystem.new())
furnaceCookSystemHandler.staticTickRate(0.05) # 20 times a second exactly

# Where the `FurnaceCookSystem` could be something like:
class FurnaceCookSystem:
  def _entity_matchers():
    furnaceBurnMatcher =
      componentTables.matcher().
      write(inventoryComponentTable).
      write(fuelStorageComponentTable).
      writeEither(inventoryChangedComponentTable, furnaceCookingComponentTable)
      read(furnaceComponentTable)
    return [furnaceBurnMatcher]

  # Assume we have matching semantics here to destructure a list, I'm lazy...
  def _entities_process([furnaceBurnEntities], delta):
    # This function takes a list of entity sets in the same order as the matchers
    # returned above.
    while entity in furnaceBurnEntities:
      val furnace = furnaceComponentTable[entity] # or .get(entity) or whatever API
      val cooking = furnaceCookingComponentTable[entity]
      if cooking == null or cooking.cookTimeRemaining <= 0:
        if cooking != null:
          if inventoryComponentTable.put(item) == False: # No space, try later
            continue
        # Get next item that has a "burnable" tag, if any
        val item = inventoryComponentTable[entity].getAndRemoveFirstOf("burnable")
        if item == null:
          furnaceCookingComponentTable.remove(entity)
        else:
          cooking = furnaceCookingComponentTable.set(entity, item, furnace.cookTime * getCookTimeModifierOfItem(item))
      else:
        cooking.cookTimeRemaining -= delta

 # ... whatever other functions are useful to the system

# Then of course just with the right components on any entity it will just work
# 'as' a furnace.  You can have a whole variety of 'generic' systems that can be
# mixed and match with impunity.  If you want a random rock that can be a furnace
# then just add the proper components, or if you want an Ent that can both be
# chopped down like a tree for wood but will also attack the player then just add
# the proper components, etc.... etc....

@MysteryGM : 한 가지 팁: 신호. 화재는 대상이 나무인 경우 신호 화상(대상)을 가질 수 있습니다.

죄송합니다. 인스턴스가 아닌 스크립트를 의미했습니다. 나는 Godot 트리에 노드가 필요 없이 스크립트가 상호작용하기를 원합니다.

죄송합니다. 인스턴스가 아닌 스크립트를 의미했습니다. 나는 Godot 트리에 노드가 필요 없이 스크립트가 상호작용하기를 원합니다.

제가 귀하의 문제를 오해하고 있는 것일 수도 있지만, GDScript에서 클래스를 생성하여 이미 이 작업을 수행할 수 있다고 확신합니다. 진입점 역할을 하려면 노드에 자동 로드 또는 하나 이상의 스크립트가 여전히 필요합니다.

또한 C#을 사용해 보셨습니까? 노드에 스크립트를 연결하는 것 외에 다른 것을 통해 노드와 상호 작용하고 제어하는 ​​스크립트가 있는 복잡한 시스템을 만들려는 경우 이러한 시스템에 대해 GDScript를 사용하는 것보다 C#을 사용하는 것이 훨씬 더 나을 것입니다.

@MysteryGM 장면에서 노드를 사용하지 않고 스크립트가 서로 상호 작용하도록 하려면 최소한 로드된 버전의 스크립트 리소스를 가져와야 합니다. 3.0에서 이 작업을 수행하는 유일한 방법은 preload / load 스크립트를 파일 경로로 지정하는 것입니다. 3.1은 스크립트에 부여된 이름이 전역적으로 등록되는 GDScript 및 NativeScript에 대한 "스크립트 클래스" 기능을 추가합니다. GDScript는 엔진의 전역 등록을 언어의 전역 변수로 수동으로 변환합니다.

그런 다음 Script 리소스가 있는 경우 스크립트에서 정적 메서드를 호출하거나 .new() 를 호출하여 ScriptInstance $를 얻은 다음 멤버 함수를 호출하거나 멤버 변수에 액세스할 수 있습니다. Script 가 Object, Reference, Resource 또는 다른 비노드 유형을 파생하는 경우 Script / ScriptInstance 의 인스턴스를 생성하기만 하면 됩니다. 정적/비정적 콘텐츠. 노드인 경우 SceneTree 액세스가 필요한 항목(예 get_node )을 제외하고 동일하게 적용됩니다. 이 경우 add_child 를 사용하여 먼저 SceneTree에 추가해야 합니다.

위의 모든 것은 Godot와 함께 사용되는 모든 스크립팅 언어에 적용됩니다(비록 사전 로드는 내가 믿는 특정 언어에 특정한 작업입니다...).

파일 경로별 스크립트. 3.1은 GDScript를 위한 "스크립트 클래스" 기능을 추가합니다.

3.1은 언제 정식 출시되나요?

@MysteryGM 이정표 완료율이 충분히 높을 때 / 핵심 개발자가 빌드가 "안정적"이라고 생각할 만큼 충분히 진행 상황을 판단했을 때.

마일스톤: https://github.com/godotengine/godot/milestone/7

비교를 위해 2.1과 3.0은 현재 99% 완료 상태에 있습니다. 그것이 그들이 라이브했을 때의 상태인지 확실하지 않습니다.

기본적으로 대답은 "준비가 되었을 때"입니다.

답변에 감사드리며 시간을 내어 죄송합니다.
Godot는 당시 우리의 요구에 맞지 않는 것 같습니다. 아마도 미래에 우리는 엔진을 다시 사용할 기회가 있을 것입니다.

불로 나무를 태우려면 나무->확장->불 또는 불->확장->나무가 있어야 합니다.

@MysteryGM
여기를 참조하십시오.
엔진이나 언어에 관계없이 해결책은 화재와 숲 사이의 상호 작용을 제어하는 ​​"시스템" 스크립트를 사용하는 것일 수 있습니다. 그 프레젠테이션은 구성 요소에 초점을 맞추고 있지만 객체와 함께 작동하는 시스템도 만들 수 있습니다.

C#에서 Wood 는 Fire IBurnable 를 구현한다고 말할 수 있습니다.

안녕하세요, 지속적인 관심에 감사드리며 @willnationsdev 지원에 정말 감사드립니다. 우리는 수출 자원 솔루션으로서의 스크립트가 많은 잠재력을 가지고 있다고 믿습니다. #22660에서 언급했듯이.

어떤 엔진을 사용할지 아직 10일 남았기 때문에 Godot와 함께 더 많은 시도를 했습니다.
우리는 워크플로 문제를 살펴보았고 우리 프로그래머가 가장 잘 말했다고 생각합니다.

"Godot 개발자는 Github의 모든 문제를 자체 게시물에 보관하고, 항상 하나의 버그에 대해 하나의 문제를 엽니다 . 하지만 엔진에 대해 동일한 워크플로를 허용하지 않습니다."
스크립트를 만들어야 하고 계층에 추가해야 한다는 사실입니다.

불과 숲 사이의 상호 작용을 제어하는 ​​"시스템" 스크립트. 해당 프레젠테이션은 구성 요소에 중점을 둡니다.

예, 그것이 우리가 원하는 것입니다. GDscript에서 어떻게 합니까?

C#에서는 Wood가 Fire가 사용하는 IBurnable을 구현한다고 말할 수 있습니다.

Godot는 인터페이스와 같은 일을 하는 Duck 타이핑을 가지고 있습니다. 우리가 원하는 것은 Burning이 별도의 클래스가 되어 계층에 노드를 추가하지 않고도 재사용할 수 있게 하는 것입니다.

우리가 원하는 것은 Fire, Burning, Wood입니다. 우리는 불(나무+타기)을 원하지 않습니다.
이 워크플로의 장점은 모든 개체를 구울 수 있는 문제를 수정할 필요 없이 자체적으로 굽기를 디버그할 수 있다는 것입니다.

C#에서는 Burning을 자체 클래스로 선언합니다. Public 클래스 Burning과 우리의 문제가 해결되었습니다.
C++에서는 굽기 및 문제 해결을 포함합니다.

예, 그것이 우리가 원하는 것입니다. GDscript에서 어떻게 합니까?

@MysteryGM

성능 최적화에 대해 자세히 알아보지 않고 내가 제안하는 것은 상호 작용 해결을 별도의 시스템 스크립트(불이 아닌 나무가 아님)로 옮기는 것뿐입니다. 가장 단순한 경우 시스템은 세계의 모든 객체 배열을 보유하고 상호 작용을 처리할 수 있습니다. 이 경우 객체는 유형에 신경 쓸 필요가 없고 시스템만 신경을 쓸 것입니다.

작업을 더 빠르게 하기 위해 실제로 충돌한 개체에 대해서만 검사를 수행할 수 있습니다(예: 충돌이 발생할 때 개체에서 시스템으로 signal 전송).

스크립트 상호 참조에 대한 몇 가지 GDScript 특정 예(버전 3.0용):

여기서 Enemy 는 유형/인터페이스로 작동하며 is 연산자로 확인할 수 있습니다.

# Cache the enemy class.
const Enemy = preload("enemy.gd")

# Use 'is' to check inheritance.
if (entity is Enemy):
    entity.apply_damage()

여기서 runnerGame 는 경로가 /root/runner인 _autoload_ 장면(일명 싱글톤)을 가리킵니다.

onready var runnerGame = get_node("/root/runner")
onready var runnerScript = preload("res://runner/runner.gd")

func _ready():
    runnerGame.setMode(runnerScript.SPAWN_TITLE)

여기에서 버튼의 signal "눌림"을 핸들러에 연결합니다(다른 개체 및 스크립트에 있을 수 있으며 self 를 사용하여 동일한 것을 참조함).

func _button_pressed(which):
    print("Button was pressed: ", which.get_name())

func _ready():
    for b in get_node("buttons").get_children():
        b.connect("pressed", self, "_button_pressed",[b])

여기에서 문서를 참조하십시오. 사용 가능한 몇 가지 기능이 더 있습니다. http://docs.godotengine.org/en/3.0/getting_started/scripting/gdscript/gdscript_basics.html#inheritance

여기에서 문서를 참조하십시오. 사용 가능한 몇 가지 기능이 더 있습니다.

주제에 대한 의견을 보내주셔서 감사합니다. 상속의 문제는 클래스를 구현할 때 클래스의 모든 관계를 알고 있는 경우에만 작동한다는 것입니다.

다음은 예입니다.

단계 A.
MeshInstance+ HomingScript = HomingMissile .
하지만 이제 유도 지뢰를 원하면 문제가 있습니다.
(MeshInstance+ ProximityScript) = Landmine .
(MeshInstance+ ProximityScript) + HomingScript = 하나 이상의 스크립트 오류
(MeshInstance+ ProximityScript) + (childNode + HomingScript ) = 보이지 않는 노드만 이동하므로 FAILED.
(MeshInstance+ ProximityScript) + (childNode + ExtendedHomingScript) = 이제 Homing 클래스를 확장하므로 성공하여 자식 노드에서 노드를 소유할 수 있습니다. HomingLandmine 을 얻습니다.

지금을 제외하고는 Homing Missile과 Landmine이 모두 HomingClass에서 확장되어야 한다고 주장할 수 있습니다.

B단계.
호밍 미사일[호밍에서]
HomingLandmine[from Homing] [+ ProximityScript] 이제 스크립트를 복사하여 지뢰에 붙여넣습니다.

나중에 프로덕션 단계에서 우리가 가지고 있는 다른 스크립트에서도 동일한 일이 발생합니다.
단계C.
지뢰[근접에서]
ProximityAlarm[Proximity에서] [+ AlarmScript]
// HomingLandmine[from Proximity] [+ HommingScript] // 이제 우리의 지뢰도 여기에 맞을 수 있습니다.

따라서 우리는 StepB에 대한 적절한 상속을 찾기 위해 StepA를 계속 거쳐야 합니다. StepF 등을 넘어 이 패턴을 계속 반복합니다.

우리는 StepA를 연장하는 방법을 찾았습니다. 최상위 노드에 스크립트를 추가하는 것을 피하고 항상 그것을 Spatial 또는 일부 기본 노드로 만듭니다.
(Spatial + MeshInstance+ ProximityScript) + HomingScript = HomingLandmine
이것은 동일한 문제지만 더 비싼 ParentSpatial을 사용한다는 점을 제외하고는; childNode 대신.

이 기간 동안 죄송합니다.

@MysteryGM

"Godot 개발자는 Github의 모든 문제를 자체 게시물에 보관하고, 항상 하나의 버그에 대해 하나의 문제를 엽니다 . 하지만 엔진에 대해 동일한 워크플로를 허용하지 않습니다."
스크립트를 만들어야 하고 계층에 추가해야 한다는 사실입니다.
...
우리가 원하는 것은 Fire, Burning, Wood입니다. 우리는 불(나무+타기)을 원하지 않습니다.
이 워크플로의 장점은 모든 개체를 구울 수 있는 문제를 수정할 필요 없이 자체적으로 굽기를 디버그할 수 있다는 것입니다.
...
C#에서는 Burning을 자체 클래스로 선언합니다. Public 클래스 Burning과 우리의 문제가 해결되었습니다.
C++에서는 굽기 및 문제 해결을 포함합니다.

당신이 이해해야 할 것은 Godot가 이 경우에 다르게 작동하지 않는다는 것입니다. 최고의 솔루션은 자체 스크립트(이 경우 "굽기"용)로 하위 노드를 만드는 것이지만 Burning을 자체 클래스로 정의하고 정적 함수를 통해 포함/사용할 수 있습니다(또는 인스턴스화한 다음 속성/메서드 사용)

• C++
  
  
  
  • 클래스 굽기 {};
  
  
  • "burning.h"를 포함합니다.
  
  
  • 굽기::적용(나무, 불);
  
  
  • 굽기 *b = 굽기::get_singleton(); b->적용(나무, 불);
  
  
• C#(스타일 변경을 위해 편집됨)
  
  
  
  • 공개 클래스 굽기 {}
  
  
  • Game.Burning 사용;
  
  
  • Burning.apply(나무, 불);
  
  
  • 굽기 b = Burning.Instance; b.apply(나무, 불);
  
  
• GD스크립트(3.1)
  
  
  
  • 리소스 #burning.gd를 확장합니다.
  
  
  • const 굽기 = 미리 로드("res://burning.gd")
    
    
    
    
    
    • 3.0에서는 공통 스크립트를 사용하여 일반적으로 사용되는 모든 자극에 대한 상수를 로드할 수 있습니다.
      
      
      참조 확장
      
      
      const 굽기 = 미리 로드("res://burning.gd")
      
      
      const 습윤 = preload("res://wetting.gd")
      
      
      참조 확장
      
      
      const 자극 = preload("res://stimuli.gd")
      
      
      # Stimuli.Burning 또는 Stimuli.Wetting 사용
    
    
    
    • 3.1에서는 스크립트 클래스만 사용할 수 있습니다. Burning 및 Wetting은 전역적이므로 "포함"이 필요하지 않습니다.
      
      
      또한 전역 사용을 반대하는 경우 "Stimuli"를 동일한 상수 선언을 가진 스크립트 클래스로 만들 수 있으므로 항상 유사 네임스페이스로 사용할 수 있습니다.
    
    
    
  
  
  • Burning.app(나무, 불)
  
  
  • var b = Burning.new()
    
    b.apply(나무, 불)
  
  

Unity/ScriptableObject 접근 방식의 경우 동일한 목적으로 Godot의 리소스 스크립트를 사용할 수 있습니다.

• 설정은 Inspector에서 구성할 수 있습니다.
• 기능의 "빌드"를 파일에 저장할 수 있으므로 런타임 시에도 필요에 따라 특정 설정을 쉽게 바꿀 수 있습니다.
• 편집기는 장면 선언을 사용하여 노드에 리소스 인스턴스를 자동으로 생성하므로 수동 업데이트가 필요하지 않습니다. 이러한 리소스의 배열은 합리적으로 잘 작동할 수 있지만 3.1에서 중단된 배열 유형 힌트 시스템(3.2까지)으로 Inspector 콘텐츠를 올바르게 생성하려면 EditorInspectorPlugin을 작성해야 합니다. 내 godot-next 저장소의 FileSystemItemList (경고, 초기 WIP)에서 파일/디렉토리 배열을 위한 Godot-Builder 저장소에서 사용됩니다.

불과 숲 사이의 상호 작용을 제어하는 ​​"시스템" 스크립트. 해당 프레젠테이션은 구성 요소에 중점을 둡니다.

예, 그것이 우리가 원하는 것입니다. GDscript에서 어떻게 합니까?

이를 수행하는 가장 쉬운 방법은 일종의 자동 로드 노드/장면을 사용하는 것입니다. 그 이유는 (사용 중인 노드 수를 최소화하기 위해) 모든 다른 시스템에 대해 수많은 리소스가 있는 하나의 노드만 사용 하더라도 여전히 트리에 있는 노드에 액세스하기를 원할 것이므로 델타 시간, 입력 데이터, 양보 작업(특히 신호 사용과 결합), 애니메이션/트윈/타이머 노드에 대한 액세스 권한을 얻으면 목록이 계속됩니다. 또한 자동 로드로 GDScript는 노드에 대한 전역 변수를 다시 생성하여 코드베이스의 어디에서나 이름으로 "시스템"에 액세스할 수 있습니다(이 경우 스크립트 클래스 사용에 대한 또 다른 적절한 대체).

실제로 이전 WIP 플러그인인 godot-skills 에 대한 대규모 리팩토링이 있습니다. 이 플러그인은 이것과 그 이상을 포함한다고 생각합니다. 주제에 대한 (죄송합니다, 긴) reddit 스레드 를 읽으십시오. 이것은 유사하게 일반적이고 재사용 가능한 상호작용 시스템을 구현하기 위해 서버 아키텍처(Godot의 기본 아키텍처와 유사)에서 조정된 멀티스레딩을 사용하는 실행 가능성을 검사하는 것을 포함합니다.

btw, 이 주제에 대해 실시간으로 채팅하고 싶으시다면 언제든지 같은 사용자 이름을 사용하는 Reddit/Discord/Twitter에 저를 보내주세요.

@MysteryGM

MeshInstance+ HomingScript = _HomingMissile_.
하지만 이제 유도 지뢰를 원하면 문제가 있습니다.
(MeshInstance+ ProximityScript) = _Landmine_.
(MeshInstance+ ProximityScript) + HomingScript = 하나 이상의 스크립트 오류
(MeshInstance+ ProximityScript) + (childNode + HomingScript ) = 보이지 않는 노드만 이동하므로 FAILED.
(MeshInstance+ ProximityScript) + (childNode + ExtendedHomingScript) = 이제 Homing 클래스를 확장하므로 성공하여 자식 노드에서 노드를 소유할 수 있습니다. _HomingLandmine_을 얻습니다.

지금을 제외하고는 Homing Missile과 Landmine이 모두 HomingClass에서 확장되어야 한다고 주장할 수 있습니다.

나는 여기서 뭔가를 놓치고 있다고 생각합니다. Afaik, "구성 요소 동작" 노드를 만드는 적절한 방법은 자체를 변경하지 않고 기본 대상이 부모인 "대상" 노드를 직접 수정하는 것입니다. 이것은 내가 실수하지 않은 경우 발생하는 문제를 완전히 우회합니다.

extends Node
var src_target
export(NodePath) onready var dst_target = get_node(dst_target) if dst_target else null
func _notification(p_what):
    match p_what:
        NOTIFICATION_PARENTED:
           src_target = get_parent()
        NOTIFICATION_UNPARENTED:
           src_target = null
func _physics_process():
    # if necessary, can manually assign src_target elsewhere to be NOT a parent
    if src_target and src_target is KinematicBody2D:
        src_target.move_and_slide(...) # do logic to get parameters that move towards dst_target

이와 같은 것은 스크립트가 있는 노드를 "호밍" 기능을 갖기를 원하는 항목의 자식으로 만들기만 하면 아무 것도 변경할 필요가 없다는 것을 의미합니다. 내보낸 속성 값(씬에서 또는 런타임에)을 할당하여 집으로 보낼 대상을 지정하기만 하면 됩니다. 다른 내보낸 속성을 사용하여 이동 유형을 수정할 수 있으며 다른 "빌드"를 원할 경우 해당 항목을 리소스에 아웃소싱할 수도 있습니다. 다시 말씀드리지만, Godot는 게임 프레임워크의 디자인을 매우 유연하게 만들 수 있습니다.

일부 수정 사항:

 - C#
-   - public class Burning {};
+   - public class Burning {}
    - using Game.Burning;
    - Burning.apply(wood, fire); // is it :: here? I forget...
-   - Burning b = Burning::GetSingleton(); b.apply(wood, fire);
+   - Burning b = Burning.GetSingleton(); b.apply(wood, fire);

클래스의 닫는 중괄호 뒤에 세미콜론이 필요하지 않습니다. :: 대신 정적 멤버에 점을 사용합니다.
참고로 싱글톤에 액세스하는 규칙은 메서드 대신 속성(일반적으로 Instance 이라고 함)을 사용하는 것입니다.

@neikeq 감사합니다. 나는 C# 으로 너무 연습이 부족합니다.

"Global Scripts" 접근 방식에 관해서는 저는 이에 대해 매우 반대합니다. 그것은 개발자들이 그들의 게임을 나쁜 방식으로 코딩하도록 부추길 것입니다. Unity/Unreal/Godot/etc를 시도할 때 이전의 베어 C++ 및 Java 게임 개발자의 일반적인 질문은 "내 코드를 작성할 수 있는 메인 게임 루프는 어디에 있습니까?"입니다. 이러한 시스템을 추가하면 해당 개발자가 이 작업을 수행할 수 있으므로 개체에 대한 스크립트를 사용하는 대신 수정하려는 개체를 참조하는 전역 스크립트에 코드를 작성할 수 있습니다.

아마도 대신 순수하게 스크립트를 보유하는 개체 "구성 요소"에 대한 오버헤드가 발생하지 않도록 베어본 Node 노드의 성능을 향상시킬 수 있습니다. 또는 별도의 간단한 "only-holds-scripts" 노드일 수도 있습니다.

@aaronfranke

"Global Scripts" 접근 방식에 관해서는 저는 이에 대해 매우 반대합니다. 그것은 개발자들이 그들의 게임을 나쁜 방식으로 코딩하도록 부추길 것입니다. Unity/Unreal/Godot/etc를 시도할 때 이전의 베어 C++ 및 Java 게임 개발자의 일반적인 질문은 "내 코드를 작성할 수 있는 메인 게임 루프는 어디에 있습니까?"입니다.

내가 언급했듯이 누군가가 이 작업을 수행하는 것을 반대한다면(대규모 프로젝트에서 합리적으로) API 계층을 더 아래로 이동하기 위해 다른 스크립트의 상수를 유지하는 "네임스페이스" 전역 스크립트 클래스를 만드는 데 문제가 없습니다. 여기서 말하는 스크립트는 실제 노드 참조가 아닙니다.

이러한 시스템을 추가하면 해당 개발자가 이 작업을 수행할 수 있으므로 개체에 대한 스크립트를 사용하는 대신 수정하려는 개체를 참조하는 전역 스크립트에 코드를 작성할 수 있습니다.

이 시스템은 이미 자동 로드를 통해 Godot의 모든 사람이 구현할 수 있습니다(제안되는 기능의 "추가"가 없습니다). 게다가, 그들이 처음에 직면한 문제는 그들이 시스템 자체를 세계의 하위 노드로 추가하기를 원하지 않는다는 것입니다. 거기에 노드와 해당 노드에 스크립트를 모두 갖고 나중에 모든 것이 움직여야 한다는 것을 깨달을 때 모든 노드와 스크립트 사이의 관계를 잠재적으로 리팩토링합니다.

아마도 대신 순수하게 스크립트를 보유하는 개체 "구성 요소"에 대한 오버헤드가 발생하지 않도록 베어본 노드 노드의 성능을 향상시킬 수 있습니다.

어떤 방법으로? 이를 투명하게 수행할 수 있는 유일한 방법은 MultiScript 시스템을 구현하는 것이며 그 패러다임에는 수많은 문제가 있습니다. 그 문제를 해결하려고 할 때 내가 생각해낼 수 있는 유일한 다른 대안은 #23101에서 제안한 GDScript 특성 시스템이었습니다. 이 시스템은 MultiScript 문제를 하나의 언어로 제한하지만 자체 호스트에는 훨씬 더 심각한 문제가 있습니다.

또는 별도의 간단한 "only-holds-scripts" 노드일 수도 있습니다.

3.2에서 배열 유형 힌트 시스템을 수정하면 다음과 같이 할 수 있습니다.

extends Node
export(Array, Script) behaviors = []

이제 사전(이름으로 스크립트에 액세스하기 위해)과 3.1의 EditorInspectorPlugin을 사용하여 해당 노드가 Inspector에서 열릴 때 사용자 정의 UI를 정의하기 위해 기능을 구현할 수도 있습니다(내보낸 스크립트 UI 생성, 하지만 파일 이름과 일치하는 키가 있는 스크립트를 추가합니다).

리소스 #burning.gd를 확장합니다.

아, 우리 문제를 찾은 것 같아요. 사전 로드 시도가 리소스에서 확장되지 않았습니다. 나는 우리 중 누구도 우리가 맞춤형 리소스를 만들 수 있다는 것을 알지 못했다고 생각합니다.

또한 우리와 게임을 공유하거나 워크플로를 설명한 사람이 리소스에서 확장되지 않았다는 점을 지적하고 싶습니다.
거의 모든 사람들이 Node.js를 확장하고 있었습니다. 이것이 얼마나 큰 차이를 만드는지 알 수 없으므로 테스트를 실행해야 합니다.

FileSystemItemList(경고, 초기 WIP임)

확실히 이것을 살펴보아야 할 것입니다.

@MysteryGM

나는 우리 중 누구도 우리가 맞춤형 리소스를 만들 수 있다는 것을 알지 못했다고 생각합니다.

네! 나는 최근 에 문서에 프로세스를 설명하는 섹션을 추가했습니다 . :-디

Object, Reference, Resource, 그리고 물론 Node(또는 이러한 클래스의 파생물)를 포함한 모든 엔진 유형을 스크립트로 확장할 수 있습니다. 확장할 수 없는 유일한 것은 엔진 및 편집기 싱글톤(예: OS, Engine 또는 EditorFileSystem)입니다.

주제에 대한 의견을 보내주셔서 감사합니다. 상속의 문제는 클래스를 구현할 때 클래스의 모든 관계를 알고 있는 경우에만 작동한다는 것입니다.

천만에요. 장작 시스템을 구현하는 데 필요하지 않기 때문에 주석 끝에 상속을 넣었습니다.
이미 익숙한 패러다임을 사용하여 솔루션을 염두에 두고 있는 것 같고, 문제는 장작 시스템을 만드는 방법이 아니라 선호하는 패러다임을 사용하는 방법입니다.
그럼 사과드립니다. 나는 GDScript 상속에 익숙하지 않지만 다른 사람들이 이미 귀하의 질문에 답변했다고 생각합니다.

좋아, 우리는 새로운 방법을 테스트할 시간이 있었고 완벽하게 작동하는 것을 발견했습니다. 수백 개의 노드를 이미 스크립트로 대체할 수 있습니다. 성능을 크게 향상시킵니다.

리소스 사전 로드가 스크립트 포함 문제를 해결한다는 점을 고려하십시오. 또한 GDscript에서 리소스 변수를 내보내 Unity의 MultiScript 및 ScriptableObject 의 대안으로 사용할 수 있습니다.
리소스를 더 자세히 설명하기 위해 문서가 업데이트되었다는 사실과 결합됩니다.
Godot 3.1에는 더 많은 작업 흐름을 허용해야 하는 스크립트 클래스도 있다는 것은 말할 것도 없습니다.

이 문제의 원래 목표가 해결된 것 같은데 이제 이 문제를 닫을 수 있습니까?

다시 한 번 토론에 참여해 주신 모든 분들께 감사의 말씀을 전하고 싶습니다. 특히 Godot 엔진에 대해 엄청난 양의 통찰력을 제공한 @willnationsdev 에게 감사드립니다.

@MysteryGM 이 스레드의 시작 부분과 이 스레드의 끝 부분에 대한 생각은 블로그나 Godot-docs 초안으로 작성하는 것이 좋습니다. 나는 대부분의 초기 사용자가 복잡한 스크립팅 구성을 달성하려고 할 때 종종 성능 실수를 한다고 생각합니다. 우리는 학습 측면에서 "전" 대 "후"에 대한 좋은 기록이 필요합니다. 우리가 초기 튜토리얼에서 배운 교훈과 패턴은 대규모 게임으로 잘 번역되지 않을 것입니다. 이는 나에게 대규모 수업에 대한 더 많은 블로그/조언이 필요하다는 것을 의미합니다.

@pgruenbacher , 좋은 생각입니다. 우리 팀에는 두 가지 문제가 있습니다. 하나는 우리 중 단 두 명만이 영어를 유용한 수준으로 알고 있고, 두 번째는 시간이 많이 걸린다는 것입니다.

그럼에도 불구하고 개발 블로그를 만들고 발견한 모든 것을 기록해 두는 좋은 변화가 있습니다. "Godot으로의 전환" 블로그 항목을 만들 가능성이 있습니다.

지금 저는 "예술가를 위한 Godot 단기 과정" PDF 튜토리얼을 작성하고 있습니다. 왜냐하면 우리는 팀을 위해 프리랜서를 고용하고 싶지만 Godot는 아직 잘 알려지지 않았기 때문입니다.
이 튜토리얼은 Godot를 전문 게임 아티스트에게 소개하기 위한 것입니다.
이 작업을 완료하면 다른 Godot 사용자와 공유할 것이며, 내가 아직 배우는 동안 실수를 수정하는 것이 더 쉽기 때문에 시작하기 위해 PDF로 보관할 것입니다.

@pgruenbacher @MysteryGM Godot에 대한 전후 경험과 같은 맥락은 아니지만, 이 문제와 몇 가지 관련 되풀이되는 질문으로 인해 저는 Godot-docs에 대한 장면/스크립트 디자인 모범 사례 문서 작업을 시작하게 되었습니다. 내 포크에 지점이 있지만 매우 초기 WIP ATM입니다.

이와 같은 주제를 읽는 것은 매우 낙담합니다. 우리 프로젝트는 15,000 LoC가 훨씬 넘고 완벽하게 조직되었으며 훌륭하게 실행됩니다. (여기에 있는 다른 사람들이 나보다 훨씬 똑똑하기 때문에 특정 요점에 대한 세부 사항은 다루지 않겠습니다.)
당신이 Godot와 함께 하게 되어 기쁩니다, MysteryGM! Def는 개발자 블로그를 읽기를 고대하고 있습니다.

내 생각에 중요한 논리가 있는 게임은 코드를 사용하는 것이 더 좋습니다.
어쨌든 게임 엔진과 분리되어 있으므로
엔진이 작동합니다. 내 노드 스크립팅은 주로 인터페이스 렌더링에 사용됩니다.
물리학 논리. 게임 로직은 별도로 컴파일된 공유 라이브러리입니다.

2018년 11월 14일 수요일, Aaron-Fleisher [email protected]
썼다:

이와 같은 주제를 읽는 것은 매우 낙담합니다(어떤 의미에서
우리가 올바른 엔진을 선택하는지 다시 확인하게 함). 우리 프로젝트는 잘
15,000개 이상의 LoC를 완벽하게 구성하고 훌륭하게 실행합니다. (나는 가지 않을거야
여기 다른 사람들이 훨씬 더 똑똑하기 때문에 특정 요점의 세부 사항으로
나보다).
당신이 Godot와 함께 하게 되어 기쁩니다, MysteryGM! 데프 찾고
개발자 블로그를 읽기 전에

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

@Aaron-Fleisher

... 우리가 올바른 엔진을 선택했는지 다시 추측하게 만듭니다.

지금 사용하고 있는 엔진이 잘 작동하고 있다면 약간의 해결 방법이 필요하더라도 걱정할 필요가 없습니다. 일부 플레이어(또는 다른 개발자)가 귀하의 능력/제정신에 의문을 제기할 수 있지만 이는 게임 개발의 현실일 뿐입니다. 많은 열정적인 사람들이 명백한 권위를 가지고 이야기합니다(종종 실제 기술 수준보다 훨씬 높음).

당신은 당신의 문제를 알고 있는 사람이며, 당신은 그 일을 해야 할 사람입니다. 10~20%의 생산성을 추가로 얻을 수 있었던 것에 의해 마비되는 것을 피하십시오. 다음 게임을 위해 저장합니다. 아니면 이미 알고 있는 도구를 배우는 데 이미 엄청난 투자를 했기 때문에 하지 마십시오. 당신의 선택 :)

잘 모르겠습니다. Godot 개발자들이 자신들이 하는 일을 모른다는 느낌이 듭니다.

Godot 3.0.6 안정판을 처음 사용했을 때, 저는 못생기고 기능 장애가 있는 "프로젝트 관리자"가 나타납니다. 어떻게 작동하는지 알 수 있을 때(그리고 전혀 직관적이지 않음), 애셋 라이브러리에서 예제 프로그램을 다운로드하려고 할 때마다 앱이 충돌합니다. 때때로 앱이 응답을 멈춥니다. 때때로 앱에서 신비한 "상태 !연결됨" 오류가 발생합니다. 때때로 다운로드가 중단됩니다. 그리고 매번 100MB 파일은 대부분 다운로드하는 데 약 10분이 걸리는 반면, 같은 시간에 다른 곳에서는 10GB를 다운로드할 수 있습니다. "다시 시도"는 전체 다운로드를 처음부터 시작합니다.

여기서 "안정적"이라는 말은 "매번 안정적으로 망할 것"이라는 의미라고 생각합니다.

압도적인 첫인상을 이야기합니다.

@dejayc 이상하네요. Windows 10 또는 Linux Mint 장치에서 직접 프로젝트 관리자(3.0.6 안정 또는 마스터 분기 포함)에 문제가 발생한 적이 없습니다. 여기에서 문제에 대한 새 문제를 만드는 것이 좋습니다(이는 그러한 주제에 대한 올바른 문제가 아니므로). 누군가가 더 나은 지원을 제공할 수 있기를 바랍니다.

@dejayc
우리 모두가 Patreon에 기부한다면 Godot 프로젝트는 정규직 사용성 직원을 고용할 수 있을 것입니다.

사소한 점에 동의하지만 소셜 미디어의 마케팅 게시물을 기반으로 엔진을 선택해야 하며 특정 프로젝트에서 엔진의 단점이 얼마나 중요한지 확인해야 합니다. 그리고 슬프게도 그들 모두는 _많은_ 단점을 가지고 있는데, 이는 UI의 표면 수준보다 더 깊습니다...

즉, 프로젝트 관리자에 대한 제안 문제 를 열었습니다. 자유 시간이 주어지면 해당 영역에서 몇 가지 개선 작업을 수행할 것입니다.

저는 Unity와 Godot를 모두 사용해 보았고 Godot에서 일반 워크플로와 구조가 훨씬 더 우수하고 직관적임을 알게 되었습니다(특히 Unity의 장면/프리팹 대신 장면 모델, 다중 구성 요소 대신 "단일 스크립트" 모델, 속도 엔진 다운로드/시작 및 내보내기 및 오프라인에서 완전히 작동하는 기능).

둘 다 가능한 워크플로와 모델이 많이 있으며 어느 것이 더 나은지 알기가 결코 쉽지 않습니다.