Godot: 이벤트 시트 스타일 비주얼 스크립팅

현재의 Visual Scripting에 점점 더 많은 기능을 추가함으로써 이 문제를 많이 완화할 수 없었습니까?

UE4의 청사진에서는 많은 예가 사소합니다. "W 키를 누르면 이 액터를 앞으로 이동합니다."
청사진에서 매우 유사한 방식으로 이들 대부분을 구축할 수 있으며 시각적 차이(유일한 것)도 최소화됩니다.

우리는 우리가 사용할 수 있는 Visual Script를 만드는 데 집중해야 하며 직관적이고 부드러운 방식으로 IMO를 작동해야 합니다. 그대로 우리가 이미 가지고 있는 Visual Script 두 개의 Visual Scripting 시스템이 있으면 이 상황이 어떻게 개선될까요?

플러그인에 대한 좋은 아이디어입니다. 그러나 두 개의 시각적 스크립팅 시스템을 공식적으로 유지 관리하는 것은 고통스럽고 거의 이득이 없습니다.

@mhilbrunner 불행히도 아니오, 블루프린트는 비주얼 스크립팅에 대한 완전히 다른 접근 방식입니다. 당신에게 그것들은 사소하지만 clickteam의 포럼이나 construct의 포럼에서 감히 말할 수 있습니다. 그 사람들은 이 접근 방식을 얼마나 좋아하고 저를 믿기 때문에 사용하는 엔진에 집착하고 있습니다. 그들 중 많은 사람들이 Unity, 언리얼 및 Godot를 포함한 기타 엔진에서 청사진을 시도했습니다. 그들은 Blueprints보다 이벤트 시트를 선호하기 때문에 여전히 construct2 또는 clickteam fusion에 갇혀 있습니다. 그들은 여전히 ​​Unity 포럼에서 이벤트 시트 접근 방식을 요청합니다.
Godot의 비주얼 스크립팅은 포럼에서 언급되었으며 사용자는 여전히 이벤트 시트를 선호합니다. 저는 개인적으로 gdscript로 전환했고 청사진 대신 gdscript를 사용하는 것을 선호합니다. 왜냐하면 gdscript가 청사진보다 이벤트 시트에 더 가깝기 때문입니다.

바나나를 좋아하는 사람에게 토마토 대신 토마토를 먹으라고 말하는 것과 같습니다. 맛의 문제입니다 :)

@groud 나도 잠시 동안 같은 생각을 했지만 어디서부터 시작해야 할지, 그리고 플러그인으로서라도 누군가 플러그인을 유지 관리해야

@reduz 는 facebook의 아이디어에 대해 더 따뜻하게 느끼는 것 같았지만 그의 손에는 더 중요한 일이 가득했습니다.

어쨌든, 나는 이것을 문서화를 위해 여기에 게시하고 있습니다 - 이벤트 시트 시스템의 개요 - 그것이 하는 일과 청사진과의 차이점. 다른 사람이 이것을 Godot 또는 애드온으로 구현하는 데 관심이 있다면 저희에게 알려주십시오. 나는 확실히 소매를 걷어붙이고 돕고, 뉴스를 퍼뜨리고 clickteam/construct 사용자로부터 피드백을 얻을 것입니다.

지금까지 나는 Godot의 GUI 클래스와 인터페이스를 제대로 구현하는 방법조차 모릅니다. 같은 열의 셀 사이에서 논리 블록을 끌 수 있어야 합니다. 블록/행도 복사/붙여넣기 - 행 중첩 및
다른 독특한 것들. 작은 일이 아닌 것 같아요

@blurymind 네, 그리고 이 점을 지적

devs: 최소한의 복잡성으로 이것을 추가하는 가장 좋은 방법은 무엇입니까? 아마도 현재의 비주얼 스크립팅이 어떻게 작동하는지 살펴보는 시간을 가질 것입니다. 대부분 Visual Scripting UI를 대체하거나 GDScript 또는 이를 동적으로 수행하는 다른 방법을 생성하는 것이 가능한지 궁금합니다.

아직 이것에 대해 조사한 적이 없으므로 포인터를 환영합니다. :) nil 포인터가 없습니다, 제발!

@mhilbrunner 우리는 아마도

여기 내 게시물은 현재 구현된 방법의 변경이 아닌 대체 접근 방식에 대한 제안입니다. 어쨌든 이벤트 시트는 너무 다릅니다.

나는 그러한 이벤트 시트가 Nativescript를 통해 구현될 수 있다고 생각하지만, 비주얼 스크립팅과 동일한 코드베이스에 의존해야 할 이유가 없습니다.

@groud 실제로 좋은 지적입니다. 현재 Visualscripting 코드베이스를 얼마나 재사용할 수 있습니까? 노드 그래프 인터페이스에 대해 얼마나 구체적입니까?

@blurymind 예, VS에 대한 그러한 목록을 작업하고 있고 할 것입니다. 하지만 시간이 좀 걸릴 것입니다.

NativeScript를 조사해야 합니다. :)

이제 스크립팅 언어(C++, C#, 심지어 python)에 대해 여러 가지를 선택할 수 있습니다. 비주얼 스크립팅을 위해 하나 이상의 선택을 하지 않는 이유는 무엇입니까? :)

이것은 또한 시각적 스크립팅 인터페이스를 구축하기 위해 Godot의 API가 얼마나 유연한지에 달려 있다고 생각합니다.
비주얼 스크립팅 코드베이스를 재사용해야 합니까? 아니면 완전히 대안적인 코드베이스를 Nativescript(c++)로 작성해야 합니까?
이것을 gdscript 애드온으로 구현할 수 있습니까?

비주얼 스크립팅을 위해 하나 이상의 선택을 하지 않는 이유는 무엇입니까? :)

이미 너무 많은 언어를 기본 제공으로 지원하기 때문입니다. 대부분의 사용 사례는 이미 다루었으므로 유지 관리하기 위해 새 언어를 추가할 이유가 많지 않습니다. 기본 프로그래밍 언어(GDscript), 공연(C# 및 C/C++)용 언어 2개, 아티스트/게임 디자이너용 언어(비주얼 스크립트)가 있습니다. 일부 사람들이 새로운 언어를 배우는 것을 감당할 수 없다고 해서 다른 언어를 기본 제공으로 추가할 이유가 없습니다.

솔직히, 나는 이것이 핵심에 추가되어야 한다고 생각하지 않습니다. 다른 언어 바인딩과 마찬가지로 플러그인을 통해 추가하는 것이 좋습니다. 현재 언어를 유지 관리하기 위한 작업은 이미 충분합니다.

그리고 아니요, 저는 우리가 비주얼 스크립팅의 코드를 재사용할 수 있다고 생각하지 않습니다.

@groud 좋은 지적이지만 gamedev에서 프로그래머와 아티스트의 비율을 고려하십시오. 자신의 사고 방식에 맞는 직관적인 방식으로 게임을 만들고자 했던 아티스트들이 퓨전 2로 가장 훌륭하고 아름다운 복고풍 2D 게임을 만들었습니다. 다음은 Fusion에서 만든 게임의 약간 오래된 쇼릴입니다.
https://www.youtube.com/watch?v=3Zq1yo0lxOU

그들은 많은 성공적인 킥스타터 프로젝트와 스팀 게임을 보유하고 있습니다. 다양한 플랫폼의 게임이 있습니다. 사람들은 비주얼 프로그래밍, 심지어 전문 팀에서도 이 접근 방식을 사용하기를 좋아합니다. 사용자 기반을 확장할 가능성이 없었다면 여기에 제시하지 않았을 것입니다.

글쎄요. 하지만 그들 중 얼마나 많은 사람들이 이벤트 시트를 이해할 수 있지만 VisualScripting은 이해하지 못합니까? 당신은 "그 사람들은 이 접근 방식을 얼마나 좋아하고 저를 믿기 때문에 그들이 사용하는 엔진을 고수하고 있습니다. 그들 중 많은 사람들이 Unity, 언리얼 및 Godot를 포함한 다른 엔진에서 청사진을 시도했습니다"라고 말하고 있지만 실제로는 그것을 묻는 첫 번째 사람.

이것이 대중적인 요구라면, 우리는 그것을 핵심에 추가할 수 있습니다. 그러나 지금까지는 그렇지 않습니다.

저에게는 이미 모든 사용 사례를 다루고 있습니다. 최소한 최첨단 전문 게임 엔진의 경우. 그리고 우리는 어린이나 취미를 즐기는 사람이 아니라 회사를 대상으로 하기 때문에 시간을 할애할 가치가 없습니다. Fusion 2, Construct 또는 심지어 RPGMaker는 다른 청중에게 초점을 맞춥니다. 아름다운 게임이 그들과 함께 만들어졌다 하더라도 그들 중 극히 일부만이 전문적인 프로젝트입니다.

@groud 이 통계는

또한 이벤트 시트 접근 방식이 작업을 수행하는 데 필요한 클릭 수 감소, 더 명확한 프레젠테이션 및 gdscript로의 더 나은 학습 전환과 같은 청사진에 비해 이점이 있는 이유에 대해서도 설명합니다.

rpg 메이커 엔진은 당신이 나에게 묻는다면 정말 레벨 편집기입니다. Fusion 및construct2와 같은 수준의 유연성이 없습니다.

동일한 예를 청사진으로 설명하는 것보다 이벤트 시트의 작동 방식을 누군가에게 설명하는 것이 더 쉽습니다. 훨씬 적은 개념을 배워야 합니다. 노드 간의 연결 유형, 입력 및 출력 유형을 가르칠 필요가 없습니다. - 흐름을 설정하는 방법.
대신 이벤트는 위에서 아래로 흐릅니다. 왼쪽은 조건이고 오른쪽은 작업입니다. 아무것도 연결하지 않아도 됩니다.

이 작업을 수행합니까?

이렇게 이해하기 어려워 보이나요?

물론, Godot는 달성하기 위해 더 많은 이벤트 블록을 사용하지만 여전히 노드 그래프보다 명확합니다.
gdscript조차도 그보다 더 명확해 보입니다. 우리의 현재 비주얼 스크립트 시스템은 언뜻 보기에 복잡해 보입니다.

저는 두 시스템을 모두 사용해 본 사람으로서 지금 두 시스템을 비교하고 있습니다. 둘 다 동등하게 강력하고 하나는 배우고 시작하기가 훨씬 더 쉽습니다.
시도해 주세요. 여기에서 웹 브라우저에서 무료로 construct3을 사용해 볼 수 있습니다.
https://www.scirra.com/
아들이나 동생이 있다면 시도해 보라고 요청한 다음 Godot를 사용해 보세요. 그들이 할 수 있는 일과 지시 없이 그것을 하는 데 얼마나 걸리는지 확인하십시오. 더 많은 학교가 여기에서 Godot를 채택할 수 있는 잠재적 시장이 있습니다. - 프로그래밍 개념을 배우기 위해 시각적 스크립팅을 개선하고 엔진을 사용하여 더 젊은 인구 통계를 얻습니다.

얼마나 많은 사람들이 현재 비주얼 스크립트를 사용하고 있습니까?

나는 단서가 없지만 지금은 많이 믿지 않습니다. 현재로서는 대부분의 사람들이 GDScript를 사용하는 것 같습니다. Facebook이나 Youtube에서 VisualScripting에 관한 질문/컨텐츠를 많이 보지 못하기 때문입니다. VisualScripting이 모든 사용 사례에 응답하지 않는지 확인하기 전에 이벤트 시트를 추가하는 것은 과감한 베팅이 될 것입니다. 지금은 VisualScripting으로 충분한지 확인하고 사람들이 다른 시스템을 대량으로 요청하면 나중에 추가할 수 있습니다.

@groud 는 아이들이 기본적인 코딩 개념을 배우는 학교 환경에서 Godot의 시각적 스크립트를 테스트할 수 있다면
구성2의 가장 큰 판매 포인트 중 하나는 아이들에게 코딩을 가르치는 것이었고 수년간 특수 교육용 라이센스를 판매해 왔습니다.

내 주장은 현재 godot의 시각적 스크립트가 비 코더에게 그다지 매력적이지 않고 사람들이 코딩 방법을 배우는 데 실제로 도움이 되지 않는다는 것입니다. 그 접근 방식은 순전히 상태 머신 중심이고 기본 프로그래밍 개념은 추가 노드 그래프로 인해 훨씬 ​​더 복잡해지기 때문입니다. 위의 중심 규칙.

숙련된 프로그래머는 실제로 이것을 판매하기에 가장 좋은 청중이 아닙니다. 왜냐하면 그들은 이벤트 시트를 우리가 이미 가지고 있는 gdscript의 단순화로 보고 설계자가 상태 머신으로 사용할 수 있는 새로운 도구로 청사진을 볼 것이기 때문입니다.

나는 gdscript에서 기본 이벤트 시트 애드온을 작성하려고 노력하고 싶습니다. 저는 실제로 네이티브 스크립트 애드온을 만들 만큼 충분히 경험이 없습니다. 그것이 가능하고 시작해야 할 몇 가지 지침이 있는 경우 - 그 의견을 듣고 싶습니다.
아마도 관심이 충분하다면 누군가가 네이티브 스크립트로 만들 수 있습니다.

접근 방식이 순전히 상태 머신 중심이기 때문에

뭐 ? 왜 그렇게 생각하는지 모르겠습니다. VisualScripting은 상태 머신과 아무 관련이 없습니다.

현재 Blueprint와 Gdscript 중 어느 것이 사용하기 더 간단합니까? 비주얼 스크립팅의 목표는 무엇이며 대상 사용자는 누구입니까?

VisualScripting은 아티스트/게임 개발자를 위한 GDscript보다 간단해야 합니다. 나는 그것이 지금 당장은 아니라는 것을 인정해야 합니다. 아마도 많은 노드가 단순화되거나 더 매력적으로 만들어질 것입니다. 하지만 솔직히 말하면, 이벤트 시트가 VisualScript보다 이해하기 쉽다고 생각하는 것은 잘못된 생각입니다. 제 생각에는 그렇지 않습니다.

당신이 보여주는 예에서 실제로 차이를 만드는 유일한 것은 상황을 훨씬 더 이해하기 쉽게 만드는 텍스트와 아이콘입니다. 수직적 조직이 아닌, 보다 명확하고 직관적인 것은 텍스트와 아이콘입니다. VisualScripting은 이러한 아이콘을 추가하고 가장 일반적인 작업에 대해 더 나은 GUI를 만들고 기능을 적절한 범주로 그룹화하면 이해할 수 있을 것입니다.

@groud 는 실행 순서와 연결 유형이기도 합니다. 이벤트 시트보다 노드 그래프에서 주의해야 할 개념이 훨씬 더 많습니다. 노드에 아이콘을 추가하더라도 이벤트의 순서가 흰색 선에 의해 결정된다는 점을 설명해야 하며 다른 색상도 의미합니다. 여전히 읽기 어려운 스파게티 그래프가 표시됩니다. 다른 사람의 그래프에서 무슨 일이 일어나고 있는지 알아내기 위해 눈이 여기저기를 돌아다녀야 합니다.

당신은 올바른 대상이 아닙니다. 당신은 경험 많은 C++ 프로그래머입니다. 프로그래머가 아닌 사람들과 함께 이것을 테스트하면 내가 의미하는 바를 알게 될 것입니다.

이해하기 어렵지 않습니다. 다시 한 번 우리는 어린이를 대상으로 하지 않습니다.
그리고 코드 구성과 관련하여 문제는 이벤트 시트에서도 동일합니다. 노드를 그룹화하고 코드를 구성하는 데 신경을 쓰지 않으면 긴 이벤트 시트나 거대한 노드 그래프로 인해 읽을 수 없는 코드가 됩니다.

@groud 블렌더에서와 같이 Visualscript 노드를 그룹화할 수도 있습니까? 나는 그것을 본 기억이 없습니다. 아마도 @mhilbrunner 가 그것을 그의 목록에 추가해야 할 것입니다
https://github.com/godotengine/godot/issues/12418
또 다른 중요한 점은 gdscript를 통해 재사용 가능한 더 높은 수준의 동작/조건 논리 블록을 생성하는 기능이 이벤트 시트 시스템이나 청사진 시스템에 매우 유용할 것이라는 점입니다. 청사진 시스템에는 이미 있습니다 - 그러나 나는 그것을 위해 만들어진 어떤 플러그인도 볼 수 없습니다..

다시 한 번 -construct2는 우리보다 앞서 있습니다. 그들의 커뮤니티는 사용자 정의 조건 및 작업을 추가하는 설치하기 쉬운 플러그인을 많이 만들었습니다. 작업 및 조건을 등록하는 API는 매우 간단합니다.
https://www.scirra.com/forum/completed-addons_f153
https://www.scirra.com/manual/19/actions-conditions-and-expressions

Blurymind와 완전히 일치합니다.
저에게는 Construct 및 Fusion 이벤트 시스템을 이해하는 것이 훨씬 쉽고 라인으로 가득 찬 시스템보다 모든 게임을 훨씬 빠르게 개발할 수 있습니다.

lol 이것은 gdscript보다 어떻게 더 읽기 쉽습니다.

@groud 블렌더에서와 같이 Visualscript 노드를 그룹화할 수도 있습니까? 나는 그것을 본 기억이 없다

모르겠어요. 하지만 실행되지 않는다면 그래야 한다고 생각합니다.

lol 이것은 gdscript보다 어떻게 더 읽기 쉽습니다.

여기가 요점이 아닙니다.

@groud 그렇습니다 . 단순한 gdscript 코드보다 읽기에 훨씬 더 혼란스럽고 혼란스러울 때 게임 개발자가 이벤트 시트를 사용하려는 이유는 무엇입니까? 이것이 이 기능 제안의 전체 요점입니다.

@groud 그렇습니다 . 단순한 gdscript 코드보다 훨씬 더 무질서한 게임 개발자가 이벤트 시트를 사용하려는 이유는 무엇입니까?

아닙니다. VisualScripting(또는 Event Sheets)과 GDscript는 같은 사람들을 대상으로 하지 않습니다. VisualScripting(또는 이벤트 시트)은 아티스트 또는 게임/레벨 디자이너를 위한 반면 gdscript는 프로그래밍 경험이 필요합니다.

이벤트 시트와 GDscript를 비교하는 것은 의미가 없습니다.

이벤트 시트와 GDscript를 비교하는 것은 의미가 없습니다.

글쎄, 그것이 우리가 다른 곳입니다 : P 그들을 비교하는 것이 합리적이라고 생각하기 때문입니다. 특히 gdscript는 훨씬 더 간단한 수준에서 모든 작업을 수행합니다.

또한 "프로그래밍 경험 필요"에 대해 동의하지 않습니다. 레벨 디자이너가 _이벤트 시트나 비주얼 스크립팅에서 이미 액션 블록을 만들고 있다면, 그들은 gdscript를 사용하기 위한 _이미 기본적인 빌딩 블록을 가지고 있습니다_.

즉, JIT로 컴파일된 gdscript는 로드맵에 있으며 이벤트 시트 또는 시각적 스크립팅 추가보다 훨씬 더 유익할 것입니다(대다수의 Godot 개발자가 이미 큰 이점을 얻을 수 있기 때문입니다). VS/Event Sheets의 잠재적 사용 사례는 현재 매우 낮습니다. 최근 게시물 에서 이미 언급했듯이 리드 개발 시간에 대해 주의를 기울이십시오.

@girng 로드맵에서 다른 중요한 기능의 우선 순위를 훔치려 한다고 결정한 시점은? 이 포스트는 현재 우리가 가지고 있는 방법에 대한 대안적인 방법을 통해 시각적 스크립팅의 이점을 탐구하고 있습니다.
로드맵에도 나와있지 않은데 아침을 먹으러 온 것처럼 덤벼듭니다. :피
아이디어를 탐색하는 것은 시간을 요구하는 것과는 다릅니다.

컨스트럭트나 clickteam fusion에 대해 논의하고 싶다면 - 적어도 잠시 동안 이벤트 시트를 사용 - 플랫포머를 만드십시오.
나는 당신이 계정을 등록하거나 로그인할 필요가 없는construct3의 온라인 데모에 연결했습니다.
https://www.scirra.com/
말 그대로 세 번의 클릭으로

이벤트 시트를 사용해 보고 이것으로 무언가를 만드십시오. 그런 다음 Godot가 가지고 있는 Visualscript 청사진을 사용하십시오

Gdscript는 간단합니다. 예 저도 동의하고 좋아합니다. jit 컴파일된 gdscript는 굉장할 것입니다! 더 중요하다는 데도 동의했습니다.
하지만 이 논의는 전혀 그런 것들에 관한 것이 아니다

글쎄, 그것이 우리가 다른 곳입니다 : P 그들을 비교하는 것이 합리적이라고 생각하기 때문입니다. 특히 gdscript는 훨씬 더 간단한 수준에서 모든 작업을 수행합니다.

당신이 이해하지 못하는 것은 많은 사람들에게 코딩과 코딩하지 않는 것 사이에 마음의 장벽이 있다는 것입니다. VS가 지금은 들어가기가 조금 어렵다는 것을 인정해야 하지만, 많은 학습 자료가 생성되었을 수 있고 몇 가지 VS 개선이 수행되어야 하기 때문에 미래에는 GDScript보다 쉬울 것입니다.

또한 "프로그래밍 경험 필요"에 대해 동의하지 않습니다. 레벨 디자이너가 이미 이벤트 시트나 비주얼 스크립팅에서 액션 블록을 만들고 있다면, 그들은 이미 gdscript를 사용하기 위한 기본 빌딩 블록을 가지고 있습니다.

네, 저도 프로그래머로서 상당히 동의하지만 경험이 보여주는 것은 아닙니다.
Unreal이 완벽한 예입니다. 많은 사람들이 Unreal과 함께 청사진을 사용합니다. 특히 전문 분야에서 비프로그래머가 코드를 보다 환영하는 방식으로 작성할 수 있기 때문입니다. 실제 코드와 크게 다르지 않더라도(제 생각에는) 사람 마음의 차이를 만듭니다. 전문가가 사용하는 경우 동일한 장치라고 생각하기 때문에 폐기해야 하는 장치가 아니라 실제 필요하다는 의미입니다. 그렇기 때문에 두 제품을 비교하는 것은 의미가 없으며 둘 다 사용 가능하고 올바르게 작동해야 합니다.

어쨌든 이 논의는 여기서 마치겠습니다. VS 여부에 대한 자전거 이동은 이미 처리되었습니다.

@blurymind 나는 당신의 에너지에 감탄하고 당신은 좋은 포인트를 만듭니다. 나는 이전에 구성에서 이벤트 시트를 시도했고 처음에는 멋지지만 내 게임이 더 발전할수록 즉시 코드로 돌아가고 싶었습니다. 그래서 예, 나는 과거에 그들을 시도했습니다.

@groud 는 Marvel Heroes가 AAA aRPG이고 청사진 w/ Unreal 을 사용 했기 때문에 이에 대해 좋은 주장을 합니다.

나는 그들이 사용 사례를 가지고 있다는 데 동의하지 않습니다. 다음 기준에 따라 정당화하기 어려울 것이라고 생각합니다.

• 제한된 개발 인력
• 이미 현재 문제의 양
• 혼란 / 읽기 어려움 ( 여기 참조 )
• 나는 대부분의 Godot 개발자들이 차라리 gdscript를 사용할 것이라고 생각합니다
• gdscript는 이미 Godot와 아주 잘 연결되어 있습니다.
• core 에 추가 되면 이벤트 시트를 둘러싼 새로운 문제가 발생할 수 있으며 이는 gdscript 문제를 해결할 수 있습니다.
• 이미 gdscript를 사용하는 Godot 개발자의 현재 90%에게 공정하지 않습니다(개발 시간이 활성 사용 사례를 충족하는 jit 컴파일된 gdscript에 사용될 수 있는 경우)

플러그인으로 완벽하게 지원할 수는 있지만 공식적으로 지원된다면 좋은 생각이 아닐 수도 있다고 마음이 아픕니다.

@girlng 감사합니다. 다시 한 번 - 이것은 gdscript 또는 시각적 스크립트를 교체하라는 요청이 아닙니다.
일반적으로 시각적 스크립팅에 대한 관찰과 현재 Godot의 시각적 스크립팅이 비코더에게 사용자 친화적이지 않은 방법에 대한 것입니다.

Gdscript는 이벤트 시트 또는 청사진과 같은 시각적 스크립팅 시스템과 아름답게 결합될 수 있습니다.
내 첫 번째 게시물에서 언급했듯이 이벤트 시트 접근 방식은 gdscript를 이미 사용할 수 있는 표현식도 사용합니다. 더 높은 수준의 논리 블록은 gdscript와 Godot의 플러그인 시스템을 통해 생성될 수 있습니다. 시각적 스크립트 시스템과 아름답게 연결됩니다.

사실 이벤트 시트 시스템은 현재의 청사진 시스템보다 gdscript와 훨씬 더 잘 결합될 수 있습니다. 여기서 표현식은 단순한 텍스트 필드 입력보다 10억 노드 그래프로 수행됩니다. 1+1을 수행하려면 노드를 사용하십시오. 표현식에서 간단한 변수를 처리하려면 다른 노드를 사용하십시오. 훨씬 적은 노력과 장황함으로 작은 텍스트 필드에 쉽고 훨씬 더 명확하게 작성할 수 있는 간단한 표현을 위한 10억 개의 기본 노드의 스파게티 엉망으로 끝납니다.

현재 우리가 가지고 있는 시각적 스크립트는 가장 단순한 작업을 수행하기 위해 너무 많은 클릭, 노드 및 자세한 정보를 필요로 합니다. 이것이 gdscript가 10개의 노드와 100개의 연결 대신 한 줄의 코드인 imo보다 직관적인 또 다른 이유입니다.

그것은 기본적으로 이벤트 시트 시스템의 또 다른 장점입니다. 코드 블록 입력 필드 안에 표현식을 작성할 수 있습니다. 구성2와 융합 모두 시트가 범위 내에서 액세스할 수 있는 모든 노드 목록과 함께 노드가 가진 모든 메소드에 쉽게 액세스할 수 있는 자동 완성 및 표현식 편집기도 있습니다.

Godot는 같은 일을 할 때 표현식에 gdscript를 아주 쉽게 사용할 수 있습니다 - 하지만 그 표현식은 간단한 스프레드시트 구조로 되어 있습니다.

godot의 메소드를 논리 블록으로 상상해보십시오. 방법과 마찬가지로 해당 블록은 동일한 매개변수를 사용하지만 노드에 연결할 필요는 없습니다. 입력 필드에 일부 gdscript를 입력하기만 하면 됩니다.
Godot의 노드는 구성2의 동작으로 작동할 수 있으며 Godot의 이벤트 시트는 구성2보다 훨씬 유연하고 강력합니다. 그것은 그들의 엔진이 가지고 있는 어떤 단점도 가지지 않을 것입니다

객체를 페어링하는 Construct의 접근 방식은 무엇보다도 끔찍하지만 이벤트 시트 디자인과 관련이 없습니다.

현재 우리가 가지고 있는 시각적 스크립트는 가장 단순한 작업을 수행하기 위해 너무 많은 클릭, 노드 및 자세한 정보를 필요로 합니다.

이는 VS의 고유한 결함이 아니라 현재 제한된 구현의 결함입니다. 이것은 수정되어야 하며 그 옆에 다른 시각적 스크립팅 방법을 구현하기 위한 인수로 사용되어서는 안 됩니다. 그렇지 않으면 현재 VS를 폐기해야 합니다.

또한 GDscript용 JIT에 대해 논의하는 것은 주제가 아닙니다. 기능의 장점은 다음을 통해서만 측정할 수 있습니다.

• 동일한 사용 사례에 유용할 수 있는 다른 유사한 기능과 비교하여 유용합니다.
• 테이블에 가져오는 복잡성 대 유용성, Godot에 대한 추가 기술 부채 및 유지 관리 부담

따라서 이 작업을 수행해야 하는지 여부는 GDScript용 JIT를 구현하는지 여부와 관련이 없습니다. 그렇지 않으면 모든 주요 버그가 수정될 때까지(즉, 영원히) 모든 기능 요청의 99%를 닫아야 합니다. 이는 GDScript용 JIT보다 훨씬 더 중요합니다.

@mhilbrunner GDScript용 JIT는 실제로 발생할 예정이지만 이미 공식 로드맵에 있습니다. P. 나는 이것이 개발 시간을 빼앗을 수 있다고 말한 것뿐입니다. 그리고 Godot 개발자의 90%가 이미 gdscript를 사용하고 있기 때문에 정당화하기 어렵습니다(많은 사람들이 이벤트 시트보다 낫다고 생각하고 자신의 감정을 가지고 있습니다). 제대로 전달하지 못했다면 죄송합니다. 예, 이것이 그것을 대체하지 않는다는 것을 알고 있지만 개발 시간에 대해 더 많이 말하고 있습니다.

그건 그렇고 ,

이전에 Action Game Maker 및 Game Maker 이벤트 시트를 사용한 적이 있으므로 VisualScript(줄을 따르지 않고 위에서 아래로 읽음)보다 사용 및 이해가 더 쉽고 화면 공간을 많이 차지하지 않으며 유한 요소를 구현할 수 있다는 데 동의합니다. 상태 시스템을 보다 쉽게(이벤트가 완료된 후 트리거될 수 있는 이벤트를 필터링하여).

아주 좋은 추가 사항이 될 것입니다. GDScript로 충분하기 때문에 스스로 사용하지 않을 것입니다. 그러나 GDScript가 옵션이 아닌 경우(초보자와 프로그래머가 아닌 사람들이 경험할 수 있는) 잘 사용하고 있다고 상상할 수 있습니다.

글쎄, 나는 약 1 년 동안 Godot 사용자입니다. 저는 GDScript를 좋아하고 간단한 구문입니다.
하지만 저는 Construct를 8년 이상 사용해 왔으며 Event Sheets보다 더 쉬운 Visual Script를 본 적이 없다고 말할 수 있습니다. 저는 Blueprint를 좋아하지 않고 블렌더 및 Unity와 같은 다른 VS Blue Prints 스타일을 사용했습니다. 사람들이 Blue Print가 Event Sheets보다 쉽다고 말할 수 있다는 것을 이해하지 못합니다. 아티스트가 노드를 사용하여 셰이더와 그래픽을 설정하는 데 익숙하기 때문에 이러한 미학에 익숙합니다. 하지만 Unreal과 같은 엔진에 이벤트 시트 시스템을 넣으면 사람들이 블루프린트를 떨어뜨릴 것입니다.

저는 아이들과 십대들에게 프로그래밍 논리를 가르치는 학교에서 일하고 있습니다. 아이들을 위해 우리는 Construct 2를 사용합니다. 왜냐하면 그들이 Event Sheet로 무언가를 만드는 것이 고통스러울 정도로 쉽기 때문입니다. 십대의 경우 GDScript를 사용하여 좋은 결과를 얻었습니다. Godot 3.0이 나왔을 때 우리는 Godot VS를 사용하기 위해 Construct 2를 삭제하는 아이디어를 연구했지만 현재 VS가 GDScript보다 어렵고 이해하고 사용하기가 매우 복잡하기 때문에 아이디어를 포기했습니다. Godot에 이벤트 시트와 같은 것이 있다면 우리는 학교에서 오픈 소스 솔루션을 선호하는 경향이 있기 때문에 우리 과정을 Godot에 완전히 기반으로 만들 것입니다.

Event Sheets가 가져올 다른 이점은 Godot 사용자 기반을 증가시킬 것입니다. GDC에서 중대형 스튜디오는 Godot를 선호하지만 소규모 스튜디오는 Unity 및 기타 솔루션을 선호하는 것을 보았기 때문입니다. Construct, Fusion 및 Game Maker의 사용자가 Godot로 마이그레이션하기 시작할 것이라고 생각합니다.

글쎄요, 교사로서 저는 Event Sheets가 매우 이해하기 쉽고 학생들이 GDscript로 이동할 때 이미 논리적 사고를 개발했으며 이벤트 Sheets 구조는 Blue Prints보다 코드와 더 비슷하기 때문에 큰 가치를 봅니다.

어쨌든, 저는 Godot가 하는 일을 사랑하고 GDscript를 사랑합니다. 저는 이벤트 시트와 GDscript를 모두 사용하여 가르치기 때문에 제 경험을 던지고 싶었습니다. 위대한 일을 유지하십시오!

Godot 3.0이 나왔을 때 우리는 Godot VS를 사용하기 위해 Construct 2를 삭제하는 아이디어를 연구했지만 지금은 VS가 GDScript보다 어렵고 이해하고 사용하기가 매우 복잡하기 때문에 아이디어를 포기했습니다.

상당히 흥미로운 피드백입니다. :)
사실 Construct2 형식의 이벤트 시트는 VS 또는 GDscript보다 훨씬 낮은 수준입니다. 실제로 그들은 아이들이 게임 프로그래밍을 하도록 도울 수 있지만 Godot의 목표는 아닙니다. 나는 그러한 시스템이 내장된 상태로 배송되어서는 안 된다고 생각하지만 플러그인을 통해 사용할 수 있습니다. reduz의 이 댓글도 이를 표현한 것 같습니다.

@DrZanuff 이 중요한 요점을 지적해 주셔서 감사합니다. 동일한 내용은 kidscancode youtube 채널 및 @NinkuX 에서도 언급되었습니다. 이벤트 시트는 학교 환경에 적합하고 gdscript와 같은 것으로 전환하기에 좋습니다. 청사진은 불행히도

아마도 Godot는 게임 제작자가 하는 방식으로 이 문제에 접근할 수 있습니다. 드래그 앤 드롭 비주얼 코드는 실시간으로 미리 볼 수 있는 gml 코드로 직접 변환됩니다. 그렇게 하면 비코더가 엔진의 시각적 스크립팅 시스템을 사용하는 동안 gml을 배울 수 있습니다. 이는 yoyo 게임이 비코더를 gml에 점진적으로 도입하기 위해 사용하는 정확한 전략입니다.
https://docs2.yoyogames.com/source/_build/3_scripting/1_drag_and_drop_overview/change_dnd.html

표현식에 일부 gml을 사용할 때와 시각적 프로그래밍이 수행하는 작업을 미리 볼 때 모두

애드온으로도 - 나는 Godot의 이벤트 시트 객체가 결국 gdscript로 번역되어야 한다고 계속 생각합니다. 이벤트 시트는 비코더에게 gdscript 사용법을 가르치는 도구가 될 수 있습니다. 쉬운 인터페이스를 제공하여 표현식에 gdscript를 사용할 수 있고 결국 gdscript를 생성하고 미리 볼 수 있습니다.

Godot의 API에는 gdscript 파일을 생성하고 노드에 첨부하는 방법이 있습니다. 따라서 이벤트 시트는 게임을 실행할 때 또는 이벤트 시트를 편집하는 동안에도 gdscript로 변환될 수 있습니다.

clickteam fusion과 construct2가 사용하는 추가 학습 보조 도구는 기본 제공 노드 메서드/멤버의 클릭 기반 메뉴 목록입니다.

학생이 목록의 항목을 클릭하면 해당 구문이 입력 필드에 추가됩니다. 배우기 시작하면 클릭하지만 클릭하면 구문과 방법을 배우고 암기합니다. 나중에 클릭하는 대신 자동 완성으로 입력하고 깨닫지 못한 채 API를 배웠습니다.

그런 의미에서 Godot의 이벤트 시트 시스템 구현은 비코더를 gdscript와 기본 프로그래밍 개념에 문법으로 혼동하지 않고 소개하는 것을 주요 목표로 할 수 있습니다. 그러면 Godot가 십대 초반에 프로그래밍을 가르치는 더 많은 학교에 배치될 것입니다. 그들이 발전함에 따라 그들은 건설2나 게임 메이커 대신에 gdscript와 Godot의 API를 배우게 될 것입니다.

제가 설명을 잘 못드린듯... :(

내가 라인이라고 말할 때 노드를 연결하는 라인에 대한 시각적 스크립팅을 참조합니다.

구성 및 융합 이벤트 시스템은 Godot 비주얼 스크립팅보다 훨씬 직관적이고 쉽고 빠르게 게임을 생성할 수 있습니다.

이 유형의 대안을 찾는 것이 좋을 것입니다.

godot 의 시각적 스크립트 청사진의 @groud 고급 기능은 플러그인으로 작성할 수도 있습니다. 그러나 청사진에는 여전히 우리가 논의한 추가 설계 복잡성이 있을 것입니다.
더 높은 수준의 기능 이벤트 시트 기능과 완전히 새로운 이벤트 시트 기본 시스템을 플러그인으로 처음부터 작성하는 것보다 현재 청사진 시스템에 대한 더 높은 수준의 기능을 만들고 유지 관리하는 데 훨씬 적은 작업이 소요됩니다.

이벤트 시트 시스템의 낮은 수준 구현이 있는 경우 높은 수준의 작업/조건을 만들고 유지 관리하는 것이 훨씬 쉬울 것입니다.
애드온으로도 생각합니다. 먼저 낮은 수준의 액세스와 인터페이스로 기본 이벤트 시트 애드온을 만들 것입니다. 이 애드온은 새로운 방법으로 부풀리지 않고 Godot의 아키텍처를 따릅니다. 그런 다음 더 높은 수준의 항목을 위한 별도의 선택적 애드온을 다른 플러그인의 맨 위에 작성할 수 있습니다.

자산 저장소에는 시각적 스크립트 애드온을 위한 특수 섹션이 있을 수 있습니다.

저는 7세에서 17세 사이의 아이들을 위한 프로그래밍을 가르칩니다. 현재 어린 학생들은 Cosntruct를 사용하고, 큰 학생들은 Godot를 사용하고 있지만, 제 모든 학생들이 Godot를 사용할 수 있다면 아이들이 게임 개발자의 세계로 여행을 시작할 때부터 Godot를 사용하게 되어 정말 감사할 것입니다.

이벤트 시트 시스템뿐만이 아닙니다. 또한 plugins/behaviours/families , UID 및 개체 속성이 작동하는 방식입니다.

예를 들어 하나의 개체 스프라이트의 C2에서 장식, 플레이어, 적 등의 정적/애니메이션을 포함한 모든 게임 아트와 충돌 등을 모두 가질 수 있고 시작할 때 프레임을 선택하는 레이아웃에 배치할 수 있습니다. 그리고 이벤트에서 그의 행동을 설정하기 위해 "type="이라는 객체의 인스턴스 변수를 사용하여 적인지, 플레이어인지, 객체인지, 깨지기 쉬운지 등을 알 수 있습니다. 또한 각 스프라이트에는 몇 가지 기본 페인트 프로그램, 애니메이터 속성 등이 있습니다.

Godot에서 비주얼 스크립팅에서 Pong 예제를 시도했는데 플레이어에 하나의 스프라이트를 사용하고 충돌에 대해 다른 스프라이트 개체를 사용하는 것을 보았을 때 저는 '뭐!? . 또한 C2에는 한 번의 클릭으로 8개의 점을 사용하여 스프라이트가 충돌하는 "다각형 모양 추측"이 있습니다. 그 후에 더 많은 포인트를 추가하고 더 정밀하게 조정하거나 일부 플러그인이나 트릭을 사용하여 픽셀 정밀도를 얻을 수 있습니다.

내 말은, Godot가 C2에서와 같은 이벤트 시트 시스템을 적용하지만 모두 사용하기 쉽도록 동일한 철학을 따르지 않는다면 작동하지 않기 때문에 시간 낭비가 될 것입니다. 그리고 이 모든 것을 실제 Godot 엔진에서 하는 것은 정말 미친 일이 될 수 있습니다.

계속 진행하려면 RexRainbow, R0j0hound 등과 같은 C2의 큰 사람들에게 요청/고용해야 할 것입니다. . 하지만 내가 말했듯이, 그것은 많은 일과 돈을 의미합니다.

@matriax 나는 당신이 여기에서 옳지 않다고 생각합니다.
Godot는 Construct2보다 훨씬 더 유연하고 직관적인 아키텍처를 가지고 있습니다.
언급한 바와 같이 객체 짝짓기는 무엇보다도 구성에 있어 골치 아픈 일입니다. 예를 들어 구성보다 더 명확한 이벤트 순서를 가질 수 있습니다. 모든 노드에 이벤트 시트를 첨부할 수 있어 구성보다 더 나은 구성이 가능합니다.'2.
유형/패밀리의 경우 Godot에는 "그룹"이 있습니다. Godot의 그룹 구현은 실제로 구성의 것보다 낫습니다.
개체에 동작 연결 - 자식 노드를 연결하고 연결된 이벤트 시트를 포함하는 루트 부모 노드의 동작으로 사용할 수 있습니다. 이것은 실제로 다시 구성보다 낫습니다.
Godot에서는 충돌 모양 노드를 충돌이 있는 노드의 자식으로 만들어야 합니다. 그것은 로켓 과학이 아니며 실제로 프로그래밍에 대해 아이들을 가르치는 데 더 좋습니다.

요청하신 사항 중 일부는 애드온으로 수행되어야 하며 이미 애드온으로 만들어졌습니다(예: 다각형 모양 추측).

Godot의 현재 아키텍처에 맞는 이벤트 시트 시스템을 Godot에서 구현하면 구성보다 더 나은 이벤트 시트 시스템/학습 플랫폼이 될 것입니다. 왜냐하면 Godot는 코딩 스타일에서 훨씬 더 많은 유연성을 허용하고 더 나은 아키텍처를 가지고 있기 때문입니다. 플러그인을 통해 더 높은 수준의 기능으로 해당 시스템을 확장하면 구성 2만큼 사용자 친화적입니다.

Godot를 Construct 2처럼 사용자 친화적으로 만드는 것은 Godot의 핵심 개발자와 커뮤니티 모두의 공동 노력이 필요합니다. 커뮤니티는 이벤트 시트 애드온을 통해 더 높은 수준의 기능을 만들어야 합니다. 그래도 Godot를 construct2와 정확히 동일하게 만들려고 하지 마세요. 여러 면에서 더 좋습니다.

@blurymind C2에서와 동일한 아키텍처를 적용하는 것에 대해 말하는 것이 아니라 의미가 없습니다. 또한 Godot가 그룹, 자식 노드 등과 같이 이미 가지고 있는 모든 것을 알지 못합니다. 당신이 말했습니다.

내 말은 C2/C3에서와 같은 쉬운 방법으로 모든 작업을 달성하기 위해 동일한 철학을 따르지 않고 Godot에 이벤트 시트 시스템을 추가하는 것은 시간 낭비라는 것입니다. 내가 말했듯이 스프라이트/충돌 또는 모든 게임 아트에 대해 하나의 개체를 갖는 대신 각 개체에 대해 하나의 개체를 사용합니다.

얼마나 많은 사람들이 실제 비주얼 스크립팅을 사용하고 있는지, 그리고 얼마나 많은 사람들이 이벤트 시트 시스템을 선호할 것인지 커뮤니티에 물어보고 결정을 내려야 할 수도 있습니다.

@matrix 당신은 그러한 주장을 하기 전에 Godot를 배워야 합니다 :)

여기에서 제안하는 것은construct2의 전체 엔진 사본이 아니라 이벤트 시트에 대한 것입니다.

두 엔진을 모두 알고 있음 - 저는 이벤트 시트가 Godot 중심적인 방식으로 수행될 수 있으며 더 어린 아이들에게 프로그래밍에 대해 가르치는 데 더 나은 도구는 아니더라도 Godot가 될 것이라고 굳게 믿습니다.

그런 의미에서 이벤트 시트 엔터티는 스크립트 파일과 같습니다. 게임 제작자의 DND가 하는 것과 유사하며 엔진이나 작동 방식을 변경할 필요가 없습니다. 다른 구성2 기능을 원하면 몇 가지 애드온을 만들 수 있습니다.

애드온 구현이라고 해도 godot의 이벤트 시트는 gdscript 파일 생성을 위한 다른 인터페이스를 만드는 것 외에는 아무 것도 하지 않아야 합니다.

@blurymind 그리고 다시 같은 일로, 알았어, 잊어

@matrix 피드백은 좋은 생각입니다. 당신은 그 점에 옳습니다.
인터넷상의 누구라도 아닌 대상 그룹에게 물어보는 것이 좋습니다. 대상 그룹은 어린 학생과 교사일 수 있습니다. 이는 실제로 이벤트 시트 시스템의 완벽한 대상이 될 것입니다.
교사들은 학생들이 무엇을 어려워하는지 잘 알고 있을 것이며 동시에 Godot와 Construct도 알게 될 것입니다. 학생과 비코더가 좋은 피드백을 줄 수 있음

여기에서 Godot 트래커에 대해 물어보면 대부분 중급 프로그래머가 될 것입니다. 이미 gdscript, 엔진의 API 및 C++를 알고 사랑하는 사람들입니다.
그들은 보호적으로 반응할 것입니다. 포스트 시작 부분에서 당신이 제안하는 것이 그들이 필요로 하고 엔진이 필요로 하는 것이 아니라고 생각하는 것처럼 자연스럽게 우리가 gdscript에서 코드를 작성하는 방법과 더 중요한 목표를 보는 방법을 이미 알고 있기 때문입니다. 이것보다 엔진. 더 중요한 목표가 있는 것이 사실입니다.
운이 좋다면 그들 중 일부는 godot에 오기 전에 구성/게임 메이커/클릭팀 퓨전으로 시작했을 것이고 아직 프로그래밍 언어를 모르는 사람들을 위해 그 가치가 어디에 있는지 알게 될 것입니다.

누군가 3D 아티스트가 셰이더를 만드는 방법을 이미 알고 있기 때문에 청사진을 좋아한다는 좋은 지적을 했습니다. 3d 아티스트는 프로그래머가 아니지만 노드 그래프 시스템의 개념을 배운 기술적인 개인이라는 점은 매우 좋은 점입니다.

이 가치로 돌아가서 Godot, 아마도 미래의 언젠가는 더 많은 아이들의 첫 번째 엔진이 된다면 멋지지 않을까요?
학교에서 Construct를 대체하려고 시도하지 않는 이유는 무엇입니까? Scirra 개발자는 지금 너무 쉽게 사용하고 있습니다. 그들이 학교와 협력하는 것에 대해 어떻게 자랑하는지 보세요.
https://www.construct.net/gb/blogs/construct-official-blog-1/construct-3-a-year-in-review-947?utm_campaign=blog1postemailsub&utm_medium=email&utm_source=947&utm_term=txt4-read-laura_d% 2527s-post&utm_campaign=marketing&utm_source=sendgrid&utm_medium=이메일

애드온으로 아이디어를 시도하는 측면에서 WIP 개념 증명 GUI를 만들었습니다. 현재로서는 아무 것도 하지 않습니다 - 인터페이스가 어떻게 작동하고 Godot의 아키텍처와 연결될 수 있는지 알아내기 위한 것입니다. 드래그하여 셀 내부의 요소를 섞고 들여쓰기하는 방법을 아직 모릅니다.

Godot의 richtextlabel 노드가 내부 Godot 편집기 아이콘을 사용할 수 있다면 멋질 것입니다.

시간이 나면 조건/액션 편집기에 대한 또 다른 모형을 만들 것입니다 :)
작업/조건 편집기는 셀/논리 블록을 편집하는 도구입니다. 나는 Godot의 내부 코드 편집기를 표현식 편집기로 사용하는 Construct2의 접근 방식과 유사한 것을 생각하고 있습니다.
아마도 일부 도우미 지원은 나중에 추가될 수 있습니다. 예를 들어 구성 2 또는 퓨전에서와 같이

인터페이스가 만들어지면 나머지는 장면 내부에 데이터를 저장/저장하고 깨끗한 gdscript를 생성할 수 있도록 하는 것입니다. 하지만 제가 놓친 부분이 있을 수 있습니다.

@blurymind 니스, 컨셉이 마음에 들었습니다.
작업 및 조건을 추가하는 버튼에는 구성 2와 같이 배경 버튼이 없어야 합니다.

그리고 조건과 행동을 구분하는 라인이 좋을 것 같아요

나는 이것이 밝혀지는 방식을 좋아합니다.

정말 깔끔한 조형물입니다. 처음에 나는 당신이 무엇을 얻고 있는지 잘 이해하지 못했습니다. 이제 정말 명확해졌습니다... 프로그래밍과 우리가 이미 가지고 있는 일종의 시각적 스크립팅 사이의 일종의 중간 단계입니까?

@DrZanuff 피드백 감사합니다
@Zireael07 감사합니다 :)
그렇습니다. 두 엔진을 모두 사용하여 프로그래밍을 가르치는 Godot in Schools로 Construct2를 완전히 대체하는 데 도움이 되는 도구입니다.
그 아래에는 Gdscript 파일을 생성하기 위한 시각적 인터페이스가 있습니다. - Game maker 2에서 DnD가 사용되는 방식과 유사합니다. 저는 Godot의 뛰어난 아키텍처에 대한 변경을 요청하지 않습니다.
이벤트 시트는 코더가 아닌(청사진은 그렇지 않음) 프로그래밍 개념을 배우는 어린 아이들에게 사용자 친화적인 Godot의 시각적 스크립팅 옵션이 될 수 있습니다.

Godot는 이미 이 작업을 수행할 수 있는 많은 요소를 가지고 있지만, Construct2에서와 정확히 같을 수는 없습니다. Godot의 방식으로 그런 일이 발생하면 여러 면에서 더 좋을 것입니다. Construct2의 이벤트 시트는 몇 가지 정말 나쁜 코드 구성 관행을 허용하고 몇 가지 끔찍한 제한/특이점을 가지고 있습니다. 우리는 실제로 사용자 친화적이며 단점 없이 프로그래밍을 더 잘 가르치는 그들의 것보다 더 나은 이벤트 시트를 만들 수 있습니다.

내가 보기에 - 많은 작업이 이벤트 시트를 편집하기 위한 인터페이스를 만드는 데 있습니다 - 나는 Godot의 특전을 활용하여 이것을 더 잘 만들 수 있는 몇 가지 아이디어가 더 있지만 개념 증명을 개발하는 데 시간이 좀 걸릴 것입니다 그것은 그것을 설명합니다. 때로는 말보다 사진이 더 가치가 있습니다. 애드온 - 사진 그 이상

이것에 대한 당신의 작업을 사랑합니다. 작업하는 동안 저장소에서 사용할 수 있도록 하시겠습니까(그렇다면)? 구경하고 찔러보고 놀고 싶습니다.

@mhilbrunner 물론 당신이 할 수 있습니다. 그리고 여러분이 이것으로 찔러본다면 저는 실제로 그것을 사랑할 것입니다. 좀 더 보기 좋게 만들려면 시간이 필요합니다. :)

저는 GUI를 gdscript 플러그인으로 Godot의 편집기에 통합하는 과정에 있습니다 - 아직 충분히 대화형이 아닙니다 :)

기본 GUI가 대화식으로 작동하여 디자인 아이디어를 전달하면 github에 게시할 예정입니다. :) 오늘은 이벤트 시트 GUI가 탭으로 로드되도록 했습니다. - Sketchfab 플러그인에서 영감을 얻었습니다.

이벤트 시트는 다른 곳에서 액세스해야 합니까?

더 많은 업데이트 스크린샷을 게시하고 결국에는 github에 대한 링크를 게시할 예정입니다. 일부 계획 노트와 다른 이벤트 시트 엔진의 온라인 데모 링크가 포함된 첫 번째 게시물을 업데이트했습니다.

• bbcode를 통해 리치 텍스트 레이블 노드 안에 Godot 노드 아이콘을 표시하는 쉬운 방법을 알고 있습니까?
  이전 목업에서 [img] 태그를 사용했습니다 - 그러나 그것은 고도 편집기가 사용하는 모든 노드 아이콘을 다운로드하고 애드온과 함께 저장해야 하기 때문에 꽤 형편없는 접근 방식입니다.

• 나는 또한 애드온 API를 통해 새로운 이벤트 시트 스크립트 유형 리소스를 등록하는 방법을 알아내기 위해 고군분투하고 있습니다.

@blurymind 아주 좋아! 이제 더 읽기 쉽습니다. 작업 목록이 사용자에게 어떻게 표시될지 생각해야 합니다.

이전 Construct Classic에서 내가 좋아했던 것 중 하나는 작업이나 조건을 열지 않고도 이벤트 시트에서 값을 편집할 수 있는 옵션이었습니다. 그러나 편집하려면 값을 두 번 클릭했습니다.

누군가가 이것을 추가하고 싶다면(플러그인, 애드온, gdnative 등을 통해 스스로) 해가 없고 파울이 없습니다. 그렇지 않으면 시각적 스크립팅을 개선하여 이를 불필요하게 만들 수 있다는 데 동의합니다. GDscript는 쉽고, 정말 쉽습니다. 그리고 아마도 버벅거리는 시각적 스크립팅(심지어 청사진 기반)보다 아이들을 가르치는 데 더 유용할 것입니다. 누군가가 구성을 필요로 한다면, 저는 그들이 구성을 계속 사용하도록 권장합니다. Godot는 핵심에 있는 다른 모든 시스템을 에뮬레이트할 필요가 없습니다. 소프트웨어가 초점을 유지하고 분산된 초점으로 인해 "모든 거래의 대가, 누구의 것도 마스터"가 되지 않도록 하십시오.

@spyres 는 @reduz 와 godot 팀이 학교의 어린 학생들을 대상으로 삼고 싶은지 여부에 따라 다릅니다.
나는 개인적으로 우리가 학교의 구성을 고도로 완전히 대체할 수 있다고 생각합니다.
현재의 청사진 시스템은 그것을 위해 작동하지 않을 것입니다. gdscript보다 사용하기가 더 복잡하고 앞서 언급했듯이 프로그래밍 패러다임에 누군가를 소개하는 가장 좋은 방법은 아닙니다. 고유한 규칙 집합이 있기 때문입니다.
이것의 목표는 gdscript나 현재의 청사진 시스템을 대체하는 것이 아니라 오히려 아이들에게 도움을 주어 gdscript를 배울 수 있는 방법을 제공하는 것입니다. 이것이 yoyo 게임이 DnD 비주얼 스크립팅 시스템을 사용하여 프로그래머가 아닌 사람들에게 점진적으로 Gml btw를 소개하는 방법입니다.
프로그래머가 아닌 사람들이 더 쉽게 접근할 수 있고 gdscript로 전환하도록 더 잘 설계된 시각적 스크립팅 시스템을 갖는 것이 해가 될 것이라고 생각하지 않습니다. 왜 당신을?

애드온으로 만들려고 하는데, 문서나 API가 부족하다는 점에서 한계가 있습니다. 새 스크립팅 리소스 유형을 등록하고 myscript.es 파일을 편집하기 위해 스크립트 탭 안에 이벤트 시트 편집기를 삽입하고 싶습니다.
누구든지 이것이 어떻게 수행되는지 알고 있습니까? 또는 수행되는 예가 있습니까?
자체 탭이 있는 것은 보기 흉하고 에디터의 원래 디자인을 따르지 않습니다. 나는 내 애드온이 Godot의 디자인과 매끄럽게 통합되기를 바랍니다.

@DrZanuff Godot는 노드에 존재하는 모든 메소드를 나열하는 방법이 있지만 아직 액션이나 조건으로 필터링하는 방법을 잘 모르겠습니다. 그렇게 하려면 좀 더 고도 중심적인 방법을 찾아야 할 수도 있습니다. 여전히 그것을 탐구하고 아이디어를 위해 열려 있습니다 :)

어쨌든 우리는 완전한 기능을 갖춘 애드온을 결코 가질 수 없습니다. 이것은 여기에서 고도 중심적인 방식으로 수행할 수 있는 방법에 대한 아이디어를 탐색하기 위한 것입니다. 적어도 지금은

시각적 스크립트가 크게 향상될 수 없거나(또는 개선되지 않을 것이라는) 가정 또는 어린 아이들이 그것을 사용할 수 없거나 구성에서 gdscript로 성장할 것이라는 가정은 정말 바보처럼 보입니다. 특히 비주얼 스크립트가 꽤 새롭기 때문입니다.

아주 어린 아이들을 위한 솔루션 (개발자가 Godot의 주요 인구 통계로 언급한 것을 본 적이 없습니다) 이 그렇게 큰 경우 , 그들이 구성 또는 다른 초점을 맞춘 아동 솔루션 을 사용하도록 한 다음 GDscript를 통해 실제 프로그래밍으로 넘어갈 때 준비됐어.

추가 기능으로 만들고 해당 추가 기능을 지원하려면 괴롭히십시오. 그러나 중복되는 것으로, 코어가 부풀려지고 향후 지원, 통합 등으로 제한된 공식 개발 시간을 (아마도) 낭비하게 될 것 입니다. _

@spyres 본인이 개발자입니까? 아니면 선생님? 자신의 프로젝트에서 실제로 Godot의 비주얼 스크립트를 사용한 적이 있습니까? 그렇다면 사람들에게 프로그래밍에 대해 가르치는 더 나은 도구로 어떻게 개선할 수 있습니까?

@blurymind 아이디어가 좋은 것 같아요. 게다가, 당신은 이미 그것에 대한 확고한 비전을 가지고 있는 것 같습니다.

그러나 나는 "학교의 구조를 Godot로 대체"하는 것이 이 기능을 갖는 타당한 이유가 아니라고 생각합니다. Godot가 Unity, Unreal 등과 같은 다른 엔진을 대체할 비전이 있는지 기억나지 않습니다. Godot는 다른 도구를 부수려고 하지 않습니다. 그 이유가 생산성을 높이는 것이라면 동의합니다.

나는 또한 Godot가 교육 부문을 목표로 삼을 필요가 없다는 @spyres에 동의합니다. Godot가 프로그래밍(게임 개발자도 아님) 교육 도구로 적합하지 않다면 그렇게 하십시오. 그것은 처음부터 의미가 없었습니다. 그러나 누군가 Godot를 프로그래밍 교육 도구로 어떻게든 사용/변환할 수 있다면 나는 그것에 문제가 없습니다.

그래도 이 이벤트 시트는 볼만한 흥미로운 아이디어라고 생각합니다.

@blurymind 나는 당신이 Godot가 교육 도구가 아니라 Godot가 게임 엔진이라는 것을 잊은 것 같아요. 구성과 같은 것을 외부 모듈로 구현하고 싶지만, 게임 개발자를 위한 것을 어린이용 장난감으로 변형하지 마십시오. 당신이 정말로 원하는 것이 구성이라면 왜 Godot를 구성으로 변환하려고 합니까? 왜 Godot 대신 사용하지 않습니까?

@zaniar @ni-code 맞습니다. 개인적으로 현재의 청사진 접근 방식보다 더 효율적이고 명확한 시각적 스크립팅 도구를 만드는 데 더 관심이 있는 것은 사실입니다. 나는 Construct2를 좋아하지 않기 때문에 사실이 아닙니다. 나는 Godot를 그것으로 바꾸고 싶습니다. 앞서 언급했듯이 디자인과 단점이 상당히 나쁩니다. 그래서 이벤트 시트를 찾을 수 있는 유일한 장소가 Godot만큼 좋지 않다는 것이 저에게 너무 실망스러운 이유입니다.

저는 솔직히 청사진이 개선되더라도 이벤트 시트만큼 명확하고 빠르게 구축할 수는 없다고 생각합니다. 그런 점에서 이벤트 시트는 종종 과소 평가되는 신속한 프로토타이핑을 위한 훌륭한 도구입니다. 그러나 Clickteam 퓨전으로 만든 타이틀은 스스로 이야기해야 합니다. 어떤 사람들은 그것을 장난감으로 볼 수도 있지만 저에게는 이런 방식으로 게임 로직을 구축하는 것이 재미있습니다. :)

configure2와 Fusion을 모두 사용해 본 사람으로서 저는 이벤트 시트 접근 방식을 사랑하고 Godot의 API에서 영감을 주는 엔진의 결함 없이 이벤트 시트 시스템에 대한 아름다운 후보를 봅니다.
Godot의 노드 네스팅 디자인은 표현에 대한 gdscript의 명확성과 결합하여 정말 잘 작동합니다.
나는 그것이 Godot에서 구현될 것이라고 기대하지 않지만, 유용한 피드백을 얻고 API에 도움이 되기를 희망하면서 플러그인의 진행 상황을 여기에서 계속 공유할 것입니다. 여기에 있는 개발자 중 일부는 Construct2를 사용했고 Godot를 정말 잘 알고 있으므로 토론에서 좋은 아이디어가 나올 수 있습니다.

저는 실제로 경험 많은 사용자에게도 gdscript를 사용하는 것보다 약간 유리한 이벤트 시트 시스템에 대한 아이디어가 있습니다. gdscript 대신 gdscript와 함께 사용해야 합니다. 잊지 마세요.

나는 (완전히 통합/지원되기 때문에) 버벅거리는 "construct-lite" 아동 중심 플러그인보다 더 유용하고 아마도 더 인기 있는 불가피한 Visual Scripting 개선을 기대합니다.

@spyres 어조를 멍청하다 "거나 그들이 투자하고 있는(무료!) 잠재적인 플러그인이 " 버릇없는 구성 라이트 아동 중심 "이 될 것이라고 말할 필요가 없습니다.

물론, 사람들은 원하는 대로 시간을 자유롭게 보낼 수 있지만(궁극적으로는 쓸모없게 될 수도 있습니다), 그것이 Godot의 핵심 디자인에 도움이 되지 않을 수도 있습니다.

문명의 관심에서 ( "아동 중심"이 영업 이익은 여기를 요청하는 것을 _exactly_ 비록!)의 어색한으로 구조 스타일 디자인 시트를 설명과 함께 가자,하지의 핵심 개발자 시간을 낭비하지 않습니다 희망 고도 (Godot)의 핵심 인구 통계 학적, 뭔가에 집중 , 등.

실제 구성 엔진이 이미 강력한 방식으로 해당 기능을 제공할 때 Godot 내에서 구성을 다시 만드는 것을 귀찮게 하는 이유는 무엇

7세 아동 인구 통계가 정말 그런 종류의 복제에 대해 비명을 지르고 있습니까?

@mhilbrunner님의 글에 답글을 다는 느낌입니다 :D
그는 여기에서 대부분의 내 게시물을 거절했습니다.
그는 실제로 질문에 대답하지 않기 때문에 그와 논쟁하는 것은 의미가 없는 것 같습니다. 나는 그에게 피드백을 받는 데 도움이 될 수 있는 몇 가지 유효한 질문을 했습니다. 내가 대가로 얻은 것은 더 비슷합니다

github에 욕설을 하는 사람들이 게시하는 것을 차단하는 방법이 있습니까?

와우, 확실히 몇 가지 아이디어에 의문을 제기 했지만 실제로 누군가의 이름을 부른 적은 _그_ 는 꽤 모욕적입니다.

Godot 내에서 구성의 기능을 복제하는 것은 어... 구성에 의해 이미 잘 제공되지 않는 것을 제공합니다.

Construct의 기능 세트(아마도 덜한 방식으로)를 7세 어린이의 관심을 끌기 위해 Godot에 복제하는 데 합법적인 반전이 있습니까?

왜 그냥 구성을 사용하지 않습니까? 그들의 설정(일부는 복제하고 싶어하는 것처럼 보임)이 실제로 그렇게 부족합니까?

아이들이 구성 요소를 벗어나면 gdscript 또는 시각적 스크립팅으로 이동할 수 없다고 가정할 정당한 이유가 있습니까?

@spyres 이벤트 시트와 이벤트 시트를 사용하는 사람들을 설명하기 위해 일반적으로 공격적인 용어를 사용하고 있습니다.
그들은 "꼬마"가 아니며 시스템은 "잔키"하지 않습니다. 신을 위해 그 공동체에 대해 약간의 존경심을 가져라. 이 엘리트주의적 태도는 어디에서 오는가?

Construct2에는 경험이 풍부한 자바스크립트 프로그래머가 많이 있습니다. 실제로 내가 작성한 내용을 읽고 내가 제공한 링크를 따라가는 데 어려움을 겪었다면 분명히 알았을 것입니다. 그들이 만든 애드온 중 일부는 이를 babylon 및 three.js와 같은 3d 엔진과 통합합니다. 심지어 경험이 많은 개발자도 이벤트 시트를 사용하여 게임을 만드는 것을 즐깁니다.

Clickteam 퓨전 제작 게임은 Steam, kickstarter 및 앱 스토어에서 Godot 제작 게임의 수와 수익 측면에서 훨씬 더 많습니다. 그것은 10-80세의 사람들이 사용하는 완전히 이벤트 시트 기반 엔진입니다. 모든 연령대가 혼합되어 있습니다. 사용자 중 일부는 영화 제작자이고 다른 사용자는 예술가입니다. 라이센스, 수출업자 등에 돈을 쓰는 직업을 가진 사람들입니다. 젠장, 나는 지금까지 Godot와 함께 하는 어떤 것보다 그들의 자산 상점에서 물건을 팔아서 더 많은 돈을 벌었습니다.
다음은 몇 가지 예입니다. 영화 제작자인 Alonso Martin은 게임을 만들기로 결정했습니다.
https://www.kickstarter.com/projects/alonsomartin/heart-forth-alicia
7살짜리 무리가 게임을 만든다
https://www.kickstarter.com/projects/galaxytrail/freedom-planet-high-speed-platform-game

여기 좀 봐
http://indiegames.clickteam.com/
7살짜리 애들은 게임도 하고 돈도 벌 줄 안다 eh
https://thinkgaming.com/app-sales-data/publisher/3107/scott-cawthon/

프로그래밍 교육을 위한 더 나은 도구로 이것을 판매하는 나의 관점이 그렇게 잘못 분류되는 이유가 되어서는 안 됩니다. 사용자의 인구 통계가 넓어짐에 따라 엔진으로 게임을 만드는 사람들이 더 많아집니다. 뻔하지 않나요? 이것이 왜 뻔하지 않습니까 :D

내가 Construct2의 사본을 요구하지 않는다는 것을 몇 번이나 반복해야 합니까? 실제로 아무 것도 읽지 않고 같은 메시지를 반복하는 것과 같습니다. 내가 제안하는 것은 build2의 사본이 아니라 Godot 중심 이벤트 시트입니다.

이제 시스템이 "버벅거린다"는 귀하의 게시물을 읽는 것이 내가 Godot용 무료 애드온을 만들도록 동기를 부여하는 방법은 무엇입니까? 이거 좀 생각해봐

와! 그럼에도 불구하고 골대를 옮기고...

내가 명확히 하자.

Construct는 그것이 하는 일에서 꽤 성공적입니다. 따라서 완전히 다른 엔진에서 기능 세트(전체 또는 부분적으로)를 접목/복제해야 하는 필요성(?!)(눈에 띄는 이점이 없음)은 저를 탈출합니다.

실제 혜택에 관한 질문은 동일하게 유지되지만 일부는 (설명할 수 없이) "공격적"이라고 생각할 수 있습니다.

애드온을 완전히 다른 엔진에 접목하는 것이 구성을 사용하는 것보다 더 나을 것이라는 제안이 있습니까? 그 중 (추가 기능을 통해서라도) 통합된 것이 많은 사람들이 강력한 솔루션(즉, 구성)을 통해 사용하기를 기대하는 것입니까? 의심 스럽다.

근데 왜 거기서 멈춰? (구조 이상) 우수한 도구 (예 : 프로그래밍 가르치는 아이에 존재하는 스크래치 , Styncl을 , code.org 등) 또한 고도 (Godot)에 통합하지 왜!

아니면 아닐지도... ;-)

Godot 비주얼 스크립팅 써본 사람 있는데 너무 좋아서 Godot 비주얼 스크립팅만 쓰는 사람 있어?

@Zonacas 나는 Godot의 비주얼 스크립팅이 아직 충분히 성숙하지 않다고 생각하지만, 내가 틀릴 수도 있습니다. 이 시점에서 VS가 출시된 지 두 달밖에 되지 않았다는 점을 염두에 두십시오. :)

@Zonacas는 discord 서버의 VS 채널을 살펴보고 그것을 좋아하는 비프로그래머라고 자칭하는

안녕하세요 여러분, 개념 증명 애드온에 대한 진행 상황 업데이트가 있습니다.

여기 당신을 위한 신선한 gif가 있습니다:

하는 일에 대한 몇 가지 배경 - 기본적으로 이벤트 시트는 셀로 구성됩니다. 셀은 조건(게터/표현식) 또는 작업(게터/표현식과 함께 제공될 수 있는 설정기)에 대한 것일 수 있습니다.
GUI 측에서 이벤트 셀은 gdscript에서 생성된 richtextlabel 노드와 bbcode를 통해 생성됩니다. 더블 클릭하면 richtextlabel이 실제 gdscript 표현식을 포함하는 편집 상자 노드로 바뀝니다.

따라서 이벤트 시트 셀에는 2가지 모드가 있습니다.

• 편집 모드 - gdscript로 입력할 수 있는 textEdit 노드입니다.
  유일한 차이점은 사용자가 If/else/while을 입력할 필요가 없다는 것입니다. 이는 스크린샷에서 볼 수 있듯이 상위 컨테이너에 대해 컨텍스트에 따라 다릅니다. 모든 행은 새로운 조건이므로 사용자가 "또는" 또는 다른 것으로 행을 시작하지 않은 경우 파서는 새 행에 "and" 구실이 있음을 자동으로 압니다.

멀리 클릭하면 보기 모드로 전환됩니다.

• 보기 모드 - 서식 있는 텍스트 레이블 - 보기 모드로 전환하면 편집 모드에 있는 gdscript에서 bbCode가 구문 분석되고 대화형 서식 있는 텍스트 레이블을 통해 표시됩니다. 대화형이고 변경하기 쉬운 것 외에도 목표는 gdscript 코드를 보다 명확한 방식으로 표시하는 것입니다. 이는 노드의 이름과 아이콘만 표시하고(전체 경로가 아님) 일부 단어가 명확할 때(예: get_ 및 set_) 제거하는 것을 의미합니다. 클릭 가능한 모든 부분은 실제로 url 태그이기 때문에 예를 들어 노드 이름 위로 마우스를 가져갈 때 사용자는 노드의 전체 경로와 같은 일부 정보를 얻을 수 있습니다.

새 조건 추가/작업 메뉴 정보:
이것은 조건 또는 작업에 대한 새로운 gdscript 코드 줄을 만드는 것입니다. 좋은 점은 장면 내부의 모든 노드와 해당 메서드를 쉽게 탐색할 수 있다는 것입니다. gdscript 편집기에서 자동 완성이 작동하는 방식과 반대로 작동합니다. 모든 노드와 모든 setter, getter 또는 두 가지 방법을 모두 보여줍니다. 그런 다음 필터를 통해 원하는 범위로 좁힐 수 있습니다.
조건 셀에서 호출한 경우 이 메뉴에는 getter만 표시되고, 작업 셀에서 호출된 경우에는 setter와 getter 메서드가 모두 표시됩니다.

이 작업을 수행하기 위해 다음에 해야 할 일은 다음과 같습니다.

• 이벤트 순서를 쉽게 변경할 수 있도록 셀을 드래그하는 방법을 찾아야 합니다.
• 또한 미리보기 모드에서 복사 및 붙여넣기.
• 다음으로 특정 유형의 미리보기 모드 셀 URL을 클릭할 때 팝업되는 표현식 편집기를 만들어야 합니다.
• 자리 표시자 항목을 처리하는 방법을 알아보세요. 나는 의견을 퍼팅에 대해 생각했지만, unfortunatelly 고도 (Godot) 나던 지원 인라인 코멘트 : https://github.com/godotengine/godot/pull/18258 나는 하나의 드로잉 보드로 돌아가해야 할 수도 있으므로

아이디어는 단순한 교육 도구 이상의 것으로 진화하고 있습니다. 나는 이미 gdscript를 알고 사랑하는 사람들에게 실제로 시간을 절약하는 유용한 기능을 제공할 수 있다고 생각합니다.

지원해주신 모든 분들께 감사드립니다

플러그인에 대한 좋은 아이디어입니다. 그러나 두 개의 시각적 스크립팅 시스템을 공식적으로 유지 관리하는 것은 고통스럽고 거의 이득이 없습니다.

XKCD:표준

이것이 개념 증명이 아닌 실제 애드온/플러그인이 될 수 없는 이유를 모르겠습니다. 모든 것이 기본적으로 엔진과 함께 번들로 제공되어야 하는 것은 아닙니다. 그게 GDNative가 개발된 이유가 아닙니까?

@Megalomaniak 그건 사실이고 내가 Godot의 API에 대한 충분한 지식이 있다면 이것을 gdnative 애드온으로 다시 작성할 것이라고 말할 때 저를 믿으십시오. 그러나 여기까지 오기까지 나는 고군분투했고 실제로 이것을 실제 사용 가능한 도구로 바꾸는 몇 가지 핵심 요소를 놓치고 있습니다. 나는 여기에 질문을 제기했지만, 지금까지 아무도 나에게 어떤 대답이나 예를 보여주지 않았습니다.

• 어떻게 Godot 편집기에 새로운 스크립트 리소스 유형을 등록하고 사용자가 그것을 모든 노드에 연결할 수 있게 합니까? 현재 애드온은 장면과 그 해키의 루트에서 작동하고 있습니다.
• 그러면 Godot가 현재 청사진 시스템처럼 통합된 내 이벤트 시트 GUI를 열도록 어떻게 만들 수 있습니까?
• 어떻게 editText 노드가 godot의 gdscript 편집기처럼 작동하도록 만들 수 있습니까? 구문 색상 지정 및 자동 완성을 활성화합니다. 또한 사용자 정의 컨텍스트를 어떻게 제공합니까?

API에 대한 매우 낮은 수준의 지식을 가진 사람이 이 작업을 수행할 수 있습니다. 그런 종류의 내용은 문서에 없습니다. 기존 예제도 없습니다.
디자인 아이디어는 있지만 아직 완성할 수 있는 완전한 그림은 아닙니다.

지금까지는 계속해서 디자인 개념을 추진하고 API에 대해 더 많이 배울 수 있지만 이것이 실제로 완전히 작동하는 애드온으로 바뀔 수 있다고 확고하게 보장할 수는 없습니다. 사람들은 지금까지 그것을 많이 좋아하는 것 같다.

이와 같은 경우 개발자의 소원을 존중하는 것을 선호합니다.

https://godot.readthedocs.io/en/3.0/about/faq.html

나는 Godot를 더 좋게 만들 좋은 아이디어가 있습니다.

당신의 아이디어는 확실히 무시될 것입니다.

Godot를 더 좋게 만들 것이기 ​​때문에 이것을 합시다.
다른 게임 엔진이 하기 때문에 Godot에서 해보자
필요없다고 생각해서 삭제하자
어수선함과 팽창을 제거하고 Godot를 더 멋지게 보이도록 합시다
선호하는 사람들을 위해 대체 워크플로를 추가해 보겠습니다.

@spyres 저는 실제로 이것을 만들고 있으며 문서에서 찾을 수 없는 것들에 대해 API에 대한 다른 Godot 사용자의 지원을 구하고 있습니다 - Godot에 기여하려고 합니다.
여기서 뭐해?

당신은 모든 것을 무시하고 모든 게시물에서 같은 내용을 반복하는 유일한 사람입니다. 그것은 트롤이 하는 일과 매우 흡사합니다. 동의하지 않습니까? 당신은 디자인 아이디어를 논의하는 것에서 멀어지고 대화를 추적하고 있습니다.

@blurymind 한 사람의 "기여"는 다른 사람(또는 엔진)의 주의를 산만하게 합니다. 서로 다른 의견(공식 문서의 일부로 게시할 만큼 중요하다고 느끼는 개발자의 의견까지 포함)의 개념이 귀하에게 너무 불쾌하게 여겨져서 죄송합니다.

추가 기능에 행운을 빕니다. :이를 드러내고 웃다:

@spyres 하지만 실제로 만든 것이 있습니까? Godot용 애드온을 만든 적이 있습니까? 고도쓰세요?

왜 여기 있어? 당신은 토론에 기여하려고하지 않습니다

@blurymind 와 , 서로 다른 의견이 그렇게 신경

@spyres 여기 있는 모든 사람이 귀하의 의견을 볼 수 있습니다. 귀하는 스레드에 스팸 메일을

분명히 말해서, 나는 시간을 사용하는 모든 사람을 전적으로 지지하지만 그들은 가치를 찾지 못하는 나와 같은 사람들이 평화롭게 무시할 수 있는 추가 기능으로 이와 같은 것을 만들고 싶어합니다.

대체 워크플로가 실제로 Godot 코어에 통합되었습니까? 어, 제발, 안돼. 나는 그런 종류의 개발자 의견에 동의합니다.

@spyres 예, 이미 말씀하셨습니다. 위로 스크롤하여 5번 더 읽으십시오. 너 중 하나가 ..하지만 너무 많은 시간

@blurymind 그리고 왠지 귀찮은 것

_당신은_ 아무 것도 반복하지 않은 것 같습니까? (당신은 누구입니까, 왜 여기 있습니까, 자신을 정당화하십시오!). :웃음이 넘치는:

개발자가 작성한 공식 문서 주석이 약간의 소화 불량을 일으킨 것 같은데요?

예, 정말 훈훈합니다

@blurymind 감사합니다. 그럼 모두 안아주세요!

gdnative를 통해 이것을 구현하는 행운을 빕니다. 그런 비공식적인 것을 원하는 사람들(내가 의심하는 사람이 거의 없음)을 위해 있을 것입니다.

그러나 정보나 도움을 받을 수 없다면 이를 실현하기 위해 필요한 지원을 받을 수 있습니다. 아마도 이 대체 언어의 가용성이 귀하에게 실제로 얼마나 의미가 있는지 재평가해야 할 때일 것입니다.

@spyres 스팸을 중지하십시오. 나는 이러한 이메일과 알림이 필요하지 않습니다. 당신은 당신의 의견을 표명했지만, 그것을 계속 반복할 필요는 없습니다.

@mhilbrunner 제 의견이 너무 다르다면 제 아바타를 클릭한 다음 "사용자 차단"을 선택하십시오. 내 댓글을 읽으면서 발생하는 모든 고통은 즉시 중단됩니다. : 스마일 :

@spyres 이전 게시물에서 이 애드온이 대체 언어 역할을 하지 않고 gdscript를 사용하는 것을 목표로 한다고 언급했습니다. 예, 아무도 이 트래커를 조정하지 않는 것 같습니다.

빨리 끝내면 우리 모두가 더 행복해지지 않을까요? 다른 많은 추가 기능과 마찬가지로 실제로 그것을 원하는 소수의 사람들에게 아주 좋을 것이라고 확신합니다. 이로 인해 너무 많은 고통을 겪는다고 보기는 어려우니 자신을 돌보고 정보/진행 상황이 부족하여 낙담하지 않도록 하십시오. 대중의 지지가 압도적으로 많다면 곧 필요한 모든 정보/도움을 얻게 될 것이라고 확신합니다.

현명한 사람의 말처럼 "걱정하지 말고 행복하십시오". :웃음이 넘치는:

또는 "누군가가 그들의 눈을 쏠 때까지 그것은 모두 재미 있고 게임입니다!" (음, 잠깐, 내가 찾던 인용문이 아닌 것 같은데...)

와. 솔직히 말해서, 이것은 놀랍습니다!

처음에 귀하의 게시물을 읽었을 때 동의했지만 큰 논쟁이 있을까봐 조금 걱정했습니다. 그러나 귀하가 와서 전혀 짖지 않고 물지 않는 모습을 보여주고 실제로 애드온을 개발하기 시작했을 때 저는 깊은 인상을 받았습니다.

나는 GDScript와의 상호작용을 좋아합니다. 그것은 게임메이커 스튜디오(시각적 및 적절한 스크립팅의 상호 변경 가능성)에서 노드 기반 시스템으로 실제로 실행 가능하지 않은 큰 기능이었기 때문입니다.

이 작업이 완료되면 TON의 사람들에게 도움이 될 것입니다.

저는 지난 6년 동안 Construct 사용자였으며 가장 빠르고 간단한 시각적 스크립팅에 접근하는 가장 좋은 방법이라고 자신 있게 말할 수 있습니다.

훌륭한 아이디어!

이것은 매우 유용할 것입니다. 출시 될 때까지 기다릴 수 없습니다!

기발한 아이디어, SnailOn과의 협업.

1. 그는 천재다.
2. 그는 약 3년 동안 Godot를 사용하고 있습니다.
3. 그는 TGF 이후로 Clickteam 엔진을 사용했습니다.
4. 이상적인 후보.

@boruok 저는 초창기부터 snailon의 yt 채널 팬이었습니다. 😄 그의 튜토리얼은 오래전에 제가 퓨전을 배우는 데 도움이 되었습니다. 그는 github 계정을 가지고 있습니까? 나는 몇 가지에 대해 그의 마음을 이해하고 싶습니다.

Btw 나는 Construct2가 셀을 채우는 방법을 결정하는 데 사용하는 것보다 클릭 메뉴와 같은 퓨전 쪽으로 기울고 있음을 인정해야 합니다. 업데이트 1에서 제공되는 도우미 메뉴는 확실히 Clickteam 디자인의 영향을 받았습니다. 이 애드온에서 당신은 내가 어떤 엔진의 카본 카피를 만드는 것이 아니라 오히려 이벤트 시트의 신랄한 접근을 위해 더 잘 작동할 아이디어를 차용한다는 것을 알게 될 것입니다. 약간의 게임 메이커도 있습니다. 시각적 스크립트가 실제 스크립트로 매끄럽게 전환할 수 있다는 점에서 고급 사용자가 높이 평가할 수 있는 것입니다.

이 애드온의 진행 상황을 지켜봐주신 모든 분들께 감사드립니다. 초기 반응은 압도적으로 긍정적
이것은 내가 아이디어를 계속 발전시키면서 단순하고 우아하게 유지하려고 노력하는 데 큰 동기를 줍니다.

인라인 주석이 없으면 gdscript와 visualscript 사이를 쉽게 전환하기가 어렵지만 이를 극복하고 실험하는 방법에 대한 몇 가지 아이디어가 있으므로 ATM에서 작업하고 있습니다.
표현식이 예상되는 빈 자리 표시자를 gdscript에서 정의하는 방법이 필요합니다.
표현식은 값의 유형을 반환하기 때문에 자리 표시자를 표시하기 위해 godot에서 값 변환 방법을 사용하는 것으로 생각했습니다.
float() ## this will turn into a bbcode item that expects an expression resulting in a float
그러나 최종 생성된 gdscript 내부에 많은 불필요한 변수 유형 변환 메소드를 생성하므로 다소 추악할 수 있습니다.

Godot가 인라인 주석을 수행할 수 있다면 대신 gdscript에서 bbcode를 생성하는 메소드로 구문 분석할 수 있습니다. 이렇게 하면 추가 정보를 제공할 수 있습니다.

가장 좋은 방법은 실제로 bbcode 파서 메서드에 대한 빌어먹을 gdscript를 더 똑똑하게 만드는 것입니다. 이것이 제가 지금 하려고 하는 것입니다.

@blurymind 나는 git-account에 대해

@blurymind 100% 지지합니다!
(영어로 미리 죄송합니다)

사람들을 트롤링하는 데 사용할 수 있는 것 이상으로 about 페이지를 적절하게 살펴보면 다음과 같은

개발자는 (예를 들어) 다음 항목에 관심이 있습니다.

소프트웨어 사용 경험 및 문제(우리는 개선 방법에 대한 아이디어보다 이 문제에 더 관심을 가짐).
프로젝트에 필요하기 때문에 구현되었으면 하는 기능입니다.
소프트웨어를 배우기 위해 이해하기 어려웠던 개념.
최적화되었으면 하는 워크플로 부분.
명확한 튜토리얼을 놓쳤거나 문서가 수준에 미치지 못한 부분.

이 점을 염두에 두십시오.

• 현재의 시각적 스크립팅은 실제로 코딩하는 방법을 알고 있는 경우에만 사용할 수 있습니다. 그리고 하드 코드보다 훨씬 빨리 지저분해집니다. 그 도움이 누구에게 있습니까? 그리고 매우 구체적인 기술 배경이 없는 한 청사진도 그다지 도움이 되지 않습니다.

• 높은 수준의 이벤트 시트가 잘 작동합니다. 위에서 언급한 모든 앱의 성공에서 볼 수 있듯이. 잘 하면 비코더가 이해하고 사용하기가 더 쉽습니다.

• Godot가 비코더를 위한 이유는 무엇입니까?
  전문 프로젝트에서 작업하는 많은 사람들에게 이것을 많이 사용하는 것을 봅니다.
  소규모, 중간 규모 및 대규모 프로젝트의 많은 부분에서 팀의 일부는 코딩을 수행하고 다른 일부는 자체 작업을 수행합니다. 음악 및 사운드, 영상/애니메이션/SFX/UI, 게임 디자인, 작가 등...
  때로는 1인 팀이거나 이 영화 제작자와 같은 업계 외부의 사람들이 꽤 성공적인 게임을 하고 있습니다.
  어떤 사람들은 프로그래밍을 하고 싶어도 여러 가지 이유로 코딩을 하지 않습니다.
  예를 들어 난독증과 같은 문제는 코드를 악몽으로 만들지만 이벤트 시트와 같은 보다 시각적인 접근 방식을 통해 프로그래밍은 여전히 ​​가능합니다.
  대부분의 경우 이 사람들은 게임에서 필요한 것을 생산하는 동안 코딩 이외의 다른 일을 합니다.
  이벤트 시트를 사용하면 그래피스트, 사운드 또는 게임 디자이너가 원시 코드에 뛰어들지 않고도 매우 쉽게 자신의 작업을 테스트하거나 구현할 수 있습니다.
  또한 개념 증명을 테스트하기 위해 매우 빠른 프로토타이핑이 가능합니다. 스톡 이미지를 잔뜩 던지고 여기 저기를 클릭하면 아이디어가 지금 재미있는지 확인할 수 있습니다. 훌륭한 코더와 유명인/스튜디오라도 프로젝트 시작 시 반복할 수 있는 가장 간단한 것을 사용합니다.
  여기 에 모든 것에 대한 더 많은 피드백과 토론이 있으며 OP에 강력히 동의합니다.
  (Github은 이에 대한 피드백을 위한 최적의 장소가 아닙니다. 여기에 오는 사람들은 일반적으로 코딩에 깊이 빠져 있고 실제로 소수임에도 불구하고 필요성을 보지 못합니다.)

• 결론: 사람들에게 Godot와 상호 작용할 수 있는 간단하면서도 효율적인 도구를 제공하는 것은 전문 프로젝트에 참여하는 많은 진지한 어른들에게 다양한 수준에서 신의 선물이 될 것입니다.
  (아이들과 학교뿐만 아니라 실제로 도움이 될지라도.)

• 그건 그렇고, 더 많은 예를보고 싶다면 이벤트 시트를 사용하는 GDevelop 이라는 또 다른 도구가 있습니다. 이전 인터페이스(버전 4)는 꽤 좋았지만 현재 인터페이스(v 5)는 다소 나쁩니다. 앱에는 좋은 아이디어가 있지만 몇 가지 단점이 있으며 방향이 아직 명확하지 않지만 다음을 제공할 수 있습니다. 몇 가지 아이디어, 또는 적어도 다른 비교 지점.

이미 완료된 작업, 특정 반응에도 불구하고 긍정적이고 동기 부여를 유지하고 귀하의 아이디어를 믿는 것에 대해 축하합니다. 나도 그것이 정말로 결정적으로 유용할 것이며 나를 위해 주요 문제를 해결할 것임을 확인합니다.

@Goklayeh 좋은 격려의 말씀 감사합니다. 무슨 말씀인지 정확히 압니다. 이전에 여기에서 언급했듯이 성공적인 인디 Clickteam 퓨전 제작 게임은 성공한 인디 Godot 제작 게임보다 훨씬 많습니다.
게시 중인 게임, Steam 및 모바일에서의 판매량 및 목표를 달성한 킥스타터 타이틀.
그것은 전문 예술가와 디자이너가 "어린이"뿐만 아니라 그것을 사용한다는 충분한 증거가 될 것입니다.

Gdevelop의 새로운 IDE라는 주제에 대해서는 훌륭하지만 완전한 기능은 아니라고 생각합니다. 주 개발자가 한 현명한 조치 중 하나는 ide를 javascript로 이식하는 것이었습니다. 이는 C++ 개발자가 아닌 개발자가 기여할 수 있도록 매우 쉽게 액세스할 수 있도록 하는 것입니다. 나는 실제로 플레이하고 배우기 위해 지금까지 작은 수정으로 기여했습니다. 이번 주말에 저는 piskel을 통합하기 위한 몇 가지 단계를 수행하려고 합니다.
메인 개발자는 최근에 다른 개발자의 기여를 병합하여 기본적으로 드래곤본 지원을 추가했습니다. 원한다면 온라인 데모가 아닌 github의 최신 릴리스를 사용해 보십시오. 상품이 있습니다
https://github.com/4ian/GD/releases

나는 또한 이 애드온에서 여전히 느린 진행을 하고 있습니다. 더 나아가기 전에 몇 가지 사항을 리팩토링해야 합니다.

아마도 여기에서 Godot를 사용하는 모든 퓨전 사용자와 구성 2 사용자를 얻는 것이 좋습니다. 이 스레드를 보여주고 디자인에 대한 피드백을 받으십시오.
Snailon은 아직 저에게 연락하지 않았습니다. 하지만 그렇습니다. 그는 이벤트 시트와 관련하여 매우 경험 많은 프로그래머입니다. 나는 그가 Godot 사용자이기도 하다는 것을 몰랐습니다.

이것은 놀라운 것 같습니다! 이것을 개발/푸시해주셔서 감사합니다, blurymind.
저는 23년 정도 gamedev를 해왔고 기본적으로 모든 인기 있는 gamedev 도구/엔진, 프로그램 언어 등을 시도했습니다. 그리고 게임을 마칠 수 있기 때문에 하루가 끝날 때 이벤트 시트를 선호합니다. :)
조건과 작업을 분리하는 하향식 목록 접근 방식을 사용하면 다른 시스템보다 더 질서 있고 간결합니다. 제가 시각적인 면이 더 강하기 때문에 수직/수평의 단단한 구조를 가지면 프로그램/행사를 쉽게 진행할 수 있습니다.
스파게티 연결을 필요로 하는 다른 시각적 스크립팅은 매우 지저분하고 산만합니다. 시각적 세부 사항이 시끄러운 미학에 흩어져 시각적 지향적인 사람들(비주얼 스크립팅이 목표로 하는 동일한 사람들)의 집중력을 흐트러뜨립니다.
이벤트 시트는 나에게 최고입니다. 저는 blitzbasic, gamesfactory, unity, C++, javascript 등 모든 것을 사용하면서 23년을 보냈습니다. 그리고 저는 이것을 확신합니다. 저는 이벤트 시트를 좋아합니다!!

그냥 차임벨이 울리고 싶었습니다. 블루프린트/노드 스타일 편집은 "스파게티 코드"를 구성/피하는 것이 극히 어렵습니다. Clickteam/Construct/GDevelop 스타일 이벤트와 동일하다고 생각하시는 분들께 죄송하지만 근본적으로 다르며 이벤트 시트가 객관적으로 더 좋습니다(게임은 본질적으로 규칙 기반 IF/THEN이며 훨씬 더 쉽게 전환할 수 있습니다. 이벤트에서 코드로, 그러나 일반적으로 이벤트는 어쨌든 게임 로직을 코딩하는 것보다 빠릅니다).

노드 기반 편집이 편리한 순간이 있다고 확신하지만, 이벤트 기반 편집이 기본 Godot Visual Scripting에 포함된다면 빠르게 선호되는 옵션이 될 것입니다.

@bigelod @prominentdetail 코딩을 배우는 사람들뿐만 아니라 경험 많은 프로그래머들에게도 이벤트 시트가 좋은 이유에 대해 더 많은 피드백을 제공해 주셔서 감사합니다.

나는 당신이 절대적으로 옳다고 생각합니다. @prominentdetail 과

나는 또한 이벤트 시트 게임 엔진 커뮤니티 atm의 추세를 보고 있는데, Godot는 사용자 기반을 확장하는 데 실제로 활용할 수 있습니다.

• 이벤트 시트를 사용하는 개발자 커뮤니티는 이벤트 시트를 사용하는 3D 엔진을 갈망하고 있습니다. clickteam 퓨전 커뮤니티 모두 이를 애드온(반딧불)과 Construct(많은 플러그인 시도)로 통합하려고 시도했지만 해당 애드온은 3D 장면 편집 기능을 제공하지 않았습니다. 이벤트 시트가 3D 엔진과 함께 작동하도록 하는 해킹이었습니다. 엔진 편집기는 3D 게임용으로 설계되지 않았습니다. 이벤트 로직이 있는 3D 장면만 구성할 수 있습니다. 따라서 개체를 넣고 재료를 설정하는 등의 작업을 수행하는 데 어려움이 있습니다.
• 학습하는 프로그래머와 숙련된 프로그래머 모두 여전히 이벤트 시트를 좋아하고 교육뿐만 아니라 프로토타이핑에도 사용합니다.
• 많은 인디 팀이 성공적으로 이벤트 시트를 사용하여(여전히 사용하고 있음) 성공적인 타이틀(kicktarter, Steam 및 기타 플랫폼)을 만들지만 첫 번째 요점 때문에 3D 프로젝트는 거의 없습니다.

이제 이것을 Godot에서 애드온으로 작동시키는 것은 까다롭습니다. 액세스 방법을 잘 모르는 엔진의 몇 가지 사항 때문입니다. 내가 가지고 있는 현재 구현은 빠르고 지저분하며 GUI를 수행할 수 있는 방법의 일부를 시연하는 것 외에는 아무 것도 하지 않습니다. 나는 그것을 더 표현 가능한 상태로 만들기 위해 노력할 것이고 그것을 여기에 게시 할 것입니다.

참고로 저는 Piskel을 번들로 제공하고 Gdevelop과 통합했습니다. 이것은 지난 몇 주 동안 나를 바쁘게 만들었다. 하고 싶다면 시도해 볼 수 있습니다. :)
gdevelop에서도 이벤트 시트가 어떻게 수행되는지 살펴보았습니다.

@blurymind 좋아, 여기에서 이 게시물을 무시하려고 했다고 가정해 봅시다. 왜냐하면 저는 두 개의 Visual Script에 대한 아이디어가 마음에 들지 않았기 때문입니다.

그러나 마침내 충분했습니다. 마침내 토론을 시작할 때라고 생각합니다. 나는 당신이 GUI를 구축하기 위해 문서를 사용했음에 틀림없다고 믿습니다. 목업은 꽤 좋은 작업입니다. 코드를 조금 볼 수 있는 저장소가 있는지 묻고 싶었습니다. 아마도 EventSystem과 더 비슷하고 실행 가능하게 만드는 것에 대해 뭔가를 할 수 있을 것입니다.

현재 Visual Scripting 시스템에 대한 작업을 계획하고 있었습니다. 그리고 GDevelop을 만나서 마음에 들어서 여기까지 오게 되었습니다. 한 시간 동안 읽은 후에 결론이 명확해지면 중간 지점을 찾아야 합니다.

두 개의 서로 다른 Visual Scripting 시스템을 유지 관리하는 것은 불가능하며 그 중 하나는 죽어야 합니다. 하지만 저를 포함한 그 누구도 Blueprints 노드 구조와 헤어지는 것을 원하지 않습니다.
그러나 이 EventSystem은 먹지 않기에는 너무 맛있습니다(최소한 기본 프로토타이핑에 대해서는).

저는 VisualScripting이 프로토타이핑 도구에 가깝기를 원했습니다. 제한된 기능이 실제로 사용자 기반을 늘릴 수 있다면 문제가 되지 않습니다.
더 많은 사용자는 더 많은 기부와 동일합니다.

그러나 Blueprints는 산업 수준 도구이므로 용도가 있으며 Godot에게도 중요한 더 큰 물고기를 가져올 수 있습니다. 그리고 나는 그것에 대해 잘 알지 못할 수도 있다고 말했습니다.

질문은 간단합니다. 어떻게 해야 할까요? - 둘 다 선택하는 것은 불가능합니다.
그러나 하이브리드는 Godot를 더 유명하게 만들 수 있습니다.
적어도 나보다 두 가지 Visual Scripting 스타일에 더 많은 경험이 있기 때문입니다.(저는 아티스트라기보다 코더에 가깝기 때문에 제 방식대로 코딩하는 것을 좋아합니다.) 해결책을 생각해 보는 것은 어떨까요?

이것은 EventSystem 단독으로 할 수 있는 것보다 더 많은 사람들을 가져올 것입니다. 그리고 노드 시스템을 유지하는 것도 좋은 조치가 될 것입니다.

그렇다면 중도를 달성할 수 없다면 어떻게 될까요? 뭔가 죽을 것입니다. 그것이 무엇이든 상관 없습니다.

개인적으로 저는 Blueprints에 대한 이전 경험이 있기 때문에 Blueprints에 투표할 수 있으며 Unreal보다 더 큰 물고기를 비교하고 싶습니다.
하지만 비교를 위해 저는 15분 이내에 GDevelop을 선택했습니다. GDScript는 별도의 날에 몇 시간 미만이고 Blueprint는 GDScript의 두 배입니다.
그것은 또한 프로그래머로서의 나의 경험 수준을 보여주기도 합니다.

결정할 수 없습니다. 여기 참조하십시오.

1. 유니티: 4011
2. 언리얼: 316
3. 게임메이커: 274
4. 구성: 223
5. 고도: 75
   _Global Jam의 엔진당 게임 수 Reduz의 트윗 목록._

나는 Godot를 최고로 원합니다. 따라서 일부 VS 사랑이 이를 달성하는 데 도움이 되길 바랍니다.
그러나 Unreal + Godot + GameMaker + Construct는 여전히 그것을 자르지 않습니다. 하지만 최소한 2위를 차지합니다.

나는 Godot의 비주얼 스크립팅의 미래를 위해 무엇을 계획해야 할지 정말 혼란스럽습니다. 현재 시스템을 기다리거나 아무 생각 없이 고장난 것을 개선하려고 노력하는 것은 도움이 되지 않습니다.

"EventSystem은 어느 정도 Scratch로 프로그래밍하는 것과 같습니다. Blueprint는 완전히 고유하지만 EventSystem보다 강력하기 때문에 EventSystem은 깊이에 대해 더 혼란스러워지고 가독성이 떨어집니다."

뭐?? 특히 다른 이벤트 시트를 포함하고 그룹을 사용하여 Construct의 이벤트 시스템을 시도하면 정반대입니다.

최고의 노드 시스템은 항상 평균적인 EventSystem에 비해 코드 스파게티가 될 것입니다.

@bigelod 사실 그렇게

예, 저는 가장 좋은 것이 청사진이라는 것을 알고 있고 그런 것이 있다는 것은 정말 멋진 일이지만 이벤트 시스템은 초보자에게 더 친숙한 것들을 추가합니다. 또한 프로그래밍 학습에 도움이 됩니다.

@swarnimarun 몇 년 전 나는 이 동일한 트래커에서 Godot 개발자들에게 이벤트 시트를 제출했습니다. 하지만 당시에는 잘 하지 못했고 이미 많은 Godot 사용자가 Unity/Unreal 사용자였기 때문에 블루프린트에 대한 지원이 더 많았습니다. 청사진은 이미 승리했으며 현재 Godot에 있습니다.

이제 clickteam fusion, game maker, construct와 같은 엔진에서 실제로 온 많은 사용자가 이벤트 시트를 지원하고 청사진 사용을 매우 싫어합니다. 그들은 당신이 말하는 것과 반대되는 것을 말하고 이미 설명된 것을 설명할 것입니다. 청사진이 이벤트 시트 및 스크립트와 비교할 때 혼란스러운 이유를 설명합니다. 나도 이미 했다.

지옥 같은 다른 시각적 프로그래밍 엔진 포럼을 볼 때도 새로운 청사진 시스템 엔진에 대한 부정적인 반응을 볼 수 있습니다.
https://rpgmaker.net/forums/topics/23922/?post=857285#post857285

이제 하루가 끝나면 두 시스템이 모두 존재할 수 없는 이유를 알 수 없습니다. 그들은 함께 작동할 수 있습니다 - 청사진이 gdscript 노드와 함께 작동하는 방식입니다.

사실 이상적인 세계에서는 이벤트 시트가 상태 머신에서 구성하기 위해 세분화된 논리와 청사진으로 신속하게 프로토타입을 만들고 구축하기를 원할 것입니다.
왜요? 두 시스템 모두 장단점이 있기 때문입니다.

노드로 간단한 표현을 시작할 때 Godot의 청사진은 매우 빠르게 엉망이 될 수 있습니다. 이 동일한 표현은 이벤트 시트나 스크립트에서 훨씬 더 명확할 수 있습니다.

오픈 소스 프로젝트는 민주적입니다. 커뮤니티가 아이디어를 더 많이 지원할수록 그것이 현실화될 가능성이 높아집니다. 하지만 그렇다고 해서 다른 아이디어가 죽여야 한다는 의미는 아닙니다. 두 아이디어 모두 널리 좋거나 싫습니다.

여기 있는 모든 사람은 이벤트 시트와 청사진을 모두 사용하여 처음부터 프로그래밍하게 된다는 점을 인식해야 합니다. 가장 중요한 것은 시스템이 얼마나 명확하게 논리를 구성할 수 있는지입니다. 청사진을 사용하면 실행 순서가 엉망이 되는 디버깅이 될 수 있습니다. 또한 이벤트 시트와 비교할 때 설정하는 데 훨씬 더 많은 클릭과 단계가 필요합니다. 이것은 프로 개발자와 비주얼 프로그래밍 팬 모두를 위한 저의 주요 프레젠테이션입니다. 하지만 개인 취향의 문제라는 것도 잊지 말자. 나는 이것을 청사진 개발자의 팬으로 만들려고 하지 않을 것입니다. 대신 많은 시각적 프로그래밍 개발자가 청사진을 좋아하지 않고 이벤트 시트를 선호한다는 점을 지적하겠습니다.

이벤트 시트는 표현에 gdscript를 사용할 수 있으며 실제로 이벤트 시트 유형 엔진에서 온 사람들이 매우 빠르게 배울 수 있습니다.

아마도 이벤트 시스템은 사용자 정의 노드 생성 도구로 사용될 수 있습니다.

단지 뭔가에 대해 요점을 제기하고 싶습니다. 솔직히 말해서, 이벤트 시트가 프로토타입만을 위한 것이라고 생각하지 않습니다. 저는 이븐시트가 프로토타이핑만을 위한 것이라는 사고방식의 문제 중 일부는 그것을 사용하는 많은 도구가 프로그래밍 방법을 몰라도 물건을 더 쉽게 만들 수 있다는 개념을 밀어붙이기 때문이라고 생각합니다. 실제로 상당한 시간 동안 이벤트 시트를 사용하는 사람은 기본 프로그래밍 개념을 이해해야 하는 실제 프로그래밍 방법이며 이를 사용하여 완전히 완전하고 기능이 풍부한 게임을 만들 수 있다는 것을 알고 있습니다.
문제의 일부는 이벤트 시트를 사용하는 도구가 게임 개발 경험이 많지 않은 아마추어와 사람들을 끌어들이기 위해 이벤트 시트의 기술적 특성을 얕잡아보고 있다는 것입니다. 이것은 사실상 이벤트 시트의 이미지를 손상시키고 다른 도구를 사용한 경험이 더 많은 다른 사람들에게 능력이 없는 것처럼 보이게 합니다. 또한 많은 사람들이 프로그래밍에 대한 이해가 필요하지 않다고 들었기 때문에 자신이 무엇을 하고 있는지 잘 모르는 이벤트 시트를 사용하고 있습니다. 그렇다고 해서 좋은 예가 없는 것은 아닙니다. 다만 어떤 선입견이 생겼을 뿐입니다.

..하이브리드는 사람들이 더 진지한 어조를 가진 새로운 방식으로 해석할 수 있도록 하는 선입견을 깨는 방법일 수 있습니다. 이전 시스템의 문제를 해결하고 하이브리드가 영감을 받은 시스템보다 더 나은 것처럼 보이게 할 수 있는 기회가 있을 수 있습니다.

@prominentdetail 은 아주 좋은 지적을 합니다.
그것에 추가하기 위해 나는 이것을 말할 것입니다 :
Godot는 이벤트 시트를 지원하는 최초의 적절한 3D 게임 엔진이 될 기회를 얻었습니다. 이것은 정의상 현재 다른 모든 이벤트 시트 엔진보다 향상됩니다.
앞서 언급했듯이 이것은 Clickteam 퓨전과 Construct 모두에서 이전에 플러그인으로, 심지어 게임 메이커에서도 시도된 적이 있습니다. 그리고 그 엔진의 편집자는 3D 기능이 없기 때문에 어설픈 엉망입니다.

Clickteam 퓨전 - Firefly 엔진:
http://clickstore.clickteam.com/firefly
https://store.steampowered.com/app/267655/Firefly/
그것은 끔찍한 버그 애드온이기 때문에 Steam에서 패닝되고 있습니다.

구성2 - q3d
https://www.scirra.com/tutorials/9456/building-your-first-3d-game-with-the-q3d-plugin

3d 장면 편집기 없이 간단한 3d 장면을 설정하는 것이 얼마나 번거로운지 보세요.
https://youtu.be/VUGsTdBpRCQ?t=6m17s

IMHO 하이브리드는 두 가지의 단점을 모두 얻을 수 있는 좋은 방법처럼 들립니다.

접근 방식은 이벤트 시트 프로토타입을 만들어 가치를 보여주고 피드백을 받는 것이어야 합니다.

약 1시간 이상 동안 시스템을 테스트한 후에는 상당히 유능해 보입니다. 그리고 흥미로운 부분은 아마도 도우미 기능이 추가된 움직임이나 가장 기본적인 것 외에 대부분의 것을 만드는 데 GDscript만큼 많은 프로그래밍 지식이 있다는 것입니다.

프로그래밍을 시도하는 것을 두려워하는 사람들은 아마도 GDScript가 있는 곳에서 프로그래밍이 필요할 수 있는 유일한 사람들일 것이라고 믿습니다.

Eventsheet는 특히 Godot API와 함께 프로그래밍 학습을 위한 도구가 될 수 있습니다. Godot는 이미 동일한 도우미 기능을 많이 가지고 있습니다. 따라서 EventSheet를 구현하면 실제로 GDScript를 사용할 수 있습니다.
본질적으로 EventSheet를 GDScript로 변환하고 컴파일 시간에 업데이트되고 엔진에서 사용할 수 있는 별도의 숨겨진 폴더에 저장하는 시스템을 만들 수 있기 때문입니다. 적어도 그것이 내가 알아 낸 것입니다. 이것은 가장 간단한 해결책이 될 수 있습니다.

Visual Scripting/Blueprints 원인을 대신할 수는 없다는 것을 알 수 있지만 대부분 열에 코드를 삽입하여 이해하기 쉽게 만드는 시각적인 코드가 아닙니다.

EventSheet를 사용한 프로그래밍에 대한 기본 지식이 있는 사람이 더 번거로운 것으로 판명될 수 있는 경우가 아니라면 왜 그대로 공개되는지 이해할 수 없습니다.

현재 Visual Scripting 쪽이 수정되기를 기다리는 동안 시간을 ​​찾으면 이것으로 무언가를 만들려고 할 수 있습니다. EventSheet의 기본 버전을 구현하는 것은 재미있을 것입니다(Godot API를 배우는 데 도움이 될 것입니다). 진전이 있다면 여기에서 업데이트할 것입니다.

이벤트 시트는 gdscript/스크립팅 언어와 어떻게 다릅니까?

초보자를 위해(코딩보다 더 매력적으로 만드는 것들):

• 아이콘, 색상 및 가능한 한 적은 텍스트를 사용하여 논리를 시각적으로 표현합니다.
• 조건은 왼쪽 열에, 작업은 오른쪽에 표시됩니다. - 코딩에서 조건과 작업은 모두 한 열에 있으므로 다른 사람의 논리를 읽을 때 두 가지를 구별하기가 더 어렵습니다.
• 긴 텍스트 문자열 대신 메서드가 간단한 단어로 표시됩니다. 영어에서는 가능하면 구문 기호를 제거하고 구문의 노이즈를 제거하면 읽기가 훨씬 더 명확해집니다.
• Intelisense/자동 완성은 사용자에게 전체 API를 제공하므로 사용 가능한 모든 setter 또는 getter를 보고 원하는 것을 필터링할 수 있습니다. 여전히 엔진 문서에 숨겨져 있습니다. 또한 물건( 아이콘 )을 찾을 수 있는 시각적 단서가 있습니다. 반환되거나 예상되는 변수의 유형을 직접 보여줍니다.
• 그룹화 논리를 사용하면 접거나 접고 이동할 수 있는 고유한 폴더를 만들 수 있습니다. 축소 가능해야 한다고 결정한 논리 블록을 축소하는 기능은 코드를 구성하고 작업하지 않는 부분을 숨기고 싶을 때 매우 유용합니다.

숙련된 사용자의 경우:

• 채워진 셀을 끌어다 놓아 이벤트 실행 순서를 매우 쉽게 변경할 수 있습니다. 이것은 무엇을 의미 하는가? ide-로 코딩하는 동안 ctrl+x 및 ctrl+v로 이를 수행할 수 있습니다. 이벤트 시트 시스템에서 논리 행 또는 셀을 한 행에서 다른 행으로 끌어다 놓는 방식으로 간단히 재정렬할 수 있습니다.
• 이미 설정된 논리는 시각적 단서와 왼쪽 및 오른쪽 열의 레이아웃으로 인해 코드보다 찾고 읽는 것이 시각적으로 더 명확합니다. 색상 코딩 위에 있습니다. 이것은 프로토타이핑할 때 정말 좋습니다.
• 이벤트 시트는 기본적으로 사용자의 노드 경로를 자동으로 처리할 수 있습니다. 따라서 이벤트 시트를 함께 구성할 때 무언가에 대한 상대 경로를 파악하여 다른 노드(부모 또는 자식)에 액세스할 필요가 없습니다. 코드 유연성에 대한 옵션은 여전히 ​​있지만 노드가 부모-자식 관계를 동적으로 변경하지 않을 경우 시스템에서 이를 처리합니다.
  노드에 도달하기 위해 수행하는 모든 작업은 도우미 메뉴에서 선택하는 것입니다. 이것은 작업 속도를 높입니다.
• 모든 표현식이 gdscript에 있기 때문에 여전히 gdscript와 매우 유사하지만 추가 생산성 혜택을 제공합니다. 잘만 된다면 gdscript 사용자들은 경험이 있든 없든 좋아할 것이라고 생각합니다.

특전을 요약해야한다면 다음과 같습니다.
초보자를 위해 - 코드는 언뜻 보기에 훨씬 명확하고 엔진의 API가 표시되는 방식과 내려놓은 논리에 시각적 힌트(노드 아이콘)가 있기 때문에 더 매력적입니다.

더 많은 경험을 위해 모든 표현식 필드에 gdscript를 작성할 수 있지만 이제 프로세스의 일부를 더 빠르게 할 수도 있습니다(예: 코드를 입력하여 다른 노드로 이동할 필요 없음), 실행을 변경하기 위해 로직을 끌어다 놓는 기능 주문 또는 요구 사항(자르기 및 붙여넣기 필요 없음)

나는 일종의 자바 스크립트 물건으로 편향되어 다른 사람들이 이것을 시도한다면 그것을 좋아할 것입니다 :) 그러나 다시 돌아올 것입니다

자체 시스템이어야 한다는 @mhilbrunner의 말에 동의하지만, 청사진 시스템과 결합할 수 있다면 좋을 것입니다. gdscript를 프로젝트에서 청사진과 결합할 수 있는 방법

@blurymind
그래서, 그런 플러그인을 작업 중이라고 하셨죠?
리포지토리의 이름은 무엇입니까? 이미 github에 있습니까?

나는 eventshee가 이해하기 더 쉽다는 것을 확인할 수 있습니다. 나는 약 10~11살 때 그것을 배웠고 영어가 서투른 반면(저는 원어민이 아닙니다) 방법을 배우는 데 훨씬 더 많은 시간과 영어 지식이 필요했습니다. 암호.

때로는 코드를 작성하는 것보다 빠를 수 있습니다. 익숙해지면 생각하는 만큼 빠르게 클릭할 수 있습니다.

내가 볼 수있는 유일한 단점은 전통적인 코드를 배워야 할 때 게으르다는 것입니다.

나는 이것에 대해 작업하기 시작했지만 당신의 코드는 내 것보다 더 발전된 것 같습니다. 도움이 될 수는 없지만 어쨌든 시도하고 싶습니다.

@Elmapul 나는 그의 repo가 ​​많은 도움이 될 것이라고 생각하지 않습니다.
그리고 실제로 코딩이 훨씬 빠릅니다. 그런 생각을 하면 Python과 같은 언어로 작업한 좋은 프로그래머가 아니라는 의미입니다.
EventSheet가 초보자에게 더 유용하고 관대하지만 그게 전부입니다.

몇 년 동안 다양한 도구를 사용해 왔기 때문에 언급할 내용이 있다고 생각했습니다.
나는 예술가이기 때문에 대부분의 시간을 예술을 만드는 데 보냅니다. 그것은 내가 가장 많은 시간을 할애하는 것이며 내 마음이 선호하도록 강화된 것입니다. 프리랜서 등 다른 예술적인 일을 하면서 코딩을 장기간 쉬는 경우가 많이 있습니다.
아티스트로서 이것은 이해를 유지하기 위해 일관되게 수행해야 하는 특정 구문 패턴을 요구하는 특정 gamedev 도구에서 날카롭게 유지하기 어렵게 만듭니다.
따라서 아티스트로서 아티스트는 구문 기반 코딩 스타일에 대해 동일한 일관성과 우선 순위를 갖지 않을 가능성이 큽니다.
이벤트 시트는 프로그래밍을 중단할 때마다 그 고비를 피할 수 있는 방법입니다(아티스트로서 코딩에만 연속 시간을 소비하지 않을 것으로 예상되기 때문입니다). 코딩에서 익숙해지는 구문 구조와 패턴에 대한 메모리가 덜 필요합니다.
이 때문에 계속해서 다시 배워야 하는 대신 더 생산적일 수 있기 때문에 이벤트 시트를 선호합니다. 더 많은 예술적 작업과 프로젝트에 마음을 사용한 후 다시 시작합니다. 정신적으로 더 쉬운 흐름입니다.

..그래서 기본적으로 내가 강조하고 싶은 것은 당신이 그 직업에 모든 시간을 할애하고 그 사고 방식을 선호하는 정신적 능력을 구축한다면 예스 코딩이 더 빠르다는 것입니다. 그들은 단순히 그것을 입력하고 이동합니다. 그들은 이러한 라이프 스타일/행동에서 결코 벗어나지 않습니다. 다른 사람들에게 이것은 결코 현실적인 선택이 아닐 것입니다. 왜냐하면 그들은 다른 유형의 행동과 관행을 강화하는 다른 일을 하는 데 평생을 바쳤기 때문입니다.
그래서 예.. 당신은 단지 .. 오, 당신이 될 수 있습니다. .. 당신이 풀 타임 프로그래머가되는 데 시간을 할애하지 않는 것은 유감입니다. 이는 결코 완전하지 않을 많은 사람들을 소외시킬 것입니다. 시간 프로그래머 또는 기술적으로 생각하는 사람. 그리고 그것은 개발자의 권리입니다.
그러나 다른 유형의 개인을 초대하고 기술 잠재력에 관계없이 도구를 실제로 사용하는 더 많은 사람들을 얻으려면 사물에 더 개방적이고 선호하는 시스템/워크플로를 일치시킬 수 없는 사람들을 도우려고 노력하는 것이 좋습니다. , 등..
이벤트 쉬팅이 게임 개발에 많은 도움이 되고, 사람이 갔다가 돌아올때마다 빠지는 현상이 없는것 같아서 계속 답변드립니다. , 그리고 그냥 정상적인 업무 라인으로 돌아가는 것입니다. 그래서 결국에는 기술적인 면에서 시간이 조금 더 걸리거나 덜 인상적이더라도 실제로 더 많은 것을 성취합니다.

@prominentdetail 모든 의도와 목적을 위해 Visual Scripting은 그렇게 할 수 있으므로 구현이 더 완료되면 구문 기억과 관련된 대부분의 예술적 문제를 해결할 것이므로 걱정할 필요가 없습니다.

나는 전체 눈물을 위해 코딩을 떠난 후 Blueprints를 사용했고 몇 분 안에 여전히 자연스럽고 적절하다고 느꼈습니다. 그래서 대부분의 사람들이 괜찮을 것이라고 생각합니다.

당신이 아는 언어는 중요하지 않습니다. 매우 짧은 변수 이름과 데이터 유형을 입력하지 않는 한 적절하게 그룹화된 이벤트 및 작업 옵션이 있는 시각적 스크립팅은 시간보다 빠릅니다.

즉, 이벤트가 키보드 단축키에 매핑된 경우 실제로 다시 "입력"하는 것이 더 빠르지만 여전히 처음부터 표준 코드보다 더 빠른 이벤트/동작입니다(동작 및 조건은 종종 전체 복잡한 기능을 나타내기 때문에 , 미리 만들어지고 대부분의 용도에 유연함).

내 주장은 이벤트 시트가 둘 다 배우기가 더 쉽다는 것입니다.
더 빠르게 설정할 수 있습니다.

또한 전환에 더 좋습니다.
실제 스크립팅 언어에 새로운 사람들.

이벤트 시트 시스템을 잘 설계하면 작성만큼 빠를 수 있습니다.
지디스크립트. 내 모형 gif를 보면- 그냥 타이핑하는 것과 매우 유사합니다.
도우미 메뉴 필터링을 사용할 때 자동 완성 기능이 있는 코드입니다.

어쨌든, 나는 이것을하는 방법을 여전히 알아 내고 있으며 고맙게도 Godot
gdscript는 유형 스크립팅을 받게 되며, 이는 더 적합합니다.
내 이벤트 시트에 대한 bbcode를 생성하기 위해.
예를 들어 멋진 것 중 하나
이벤트 시트 시스템의 표현식 필드는
예상되는 변수 유형의 명확한 표시 및 켜짐
유효한 경우 녹색입니다(clickteam fusion's 참조).
저는 현재 다음을 수행할 수 있는 표현식 필드를 수행하는 방법을 알아 내려고 노력하고 있습니다.
gdscript를 사용하지만 내가 만든 도우미 메뉴도 사용하십시오. 다시 말하지만 이것은 어떻게 작동하는지 실험하는 것입니다. 이것은 atm에서 사용할 수 있는 것과는 거리가 멀다.

2018년 5월 30일 수요일 22:59 Daven Bigelow, 알림 @github.com 작성:

당신이 아는 언어는 중요하지 않습니다. 적절한 비주얼 스크립팅
그룹화된 이벤트 및 작업 옵션은 소요 시간보다 빠릅니다.
매우 짧은 변수 이름과 데이터 유형을 입력하지 않는 한.

즉, 이벤트가 키보드 단축키에 매핑된 경우
실제로 다시 "입력"하는 것이 더 빠르지 만 여전히 이벤트/동작이
처음부터 표준 코드보다 빠릅니다(작업 및 조건이 자주
대부분의 사용을 위해 미리 만들어지고 유연한 전체 복잡한 기능을 나타냄).

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

@blurymind C++로 하는 것이 좋습니다. 이 방법을 사용하면 더 적합하고 완벽할 것입니다. 몇 주 전에 C++를 시작한 나도 이제 그것을 사용하고 버그 수정과 새로운 기능을 만들 수 있습니다. 그래서 그렇게 어렵지는 않습니다. 아마 약간일 것입니다. 그래도 여전히 stackoverflow를 사용해야 합니다.

그러나 GDScript를 계속 사용하고 다른 사람들이 완전한 도구로 변환할 수 있도록 프로토타입을 만들면 아무리 불완전하더라도 여기에서 저장소를 공유해야 한다고 생각합니다.
기꺼이 도와드리겠습니다. 저는 EventSystem의 아이디어를 정말 좋아합니다. 그리고 VisualScripting은 현재 고장나서 제가 할 일이 별로 없습니다.

문제는 이벤트 시스템이 구현하기 번거로울 수 있다는 것입니다. Godot에서는 이를 스크립팅 언어로 구현하고 있을 가능성이 높습니다. 그러나 그것은 이벤트 관리자의 의도가 아니므로 전역적이거나 전체 장면을 단독으로 처리할 수 있어야 하며 그룹을 사용하여 작업을 섹션으로 분리해야 합니다.
이 모든 것이 가능하며 구현하는 데 문제가 없어야 합니다.

@swarnimarun 새로운 UI를 생성하거나 기존 UI를 변경하는 hello world 모듈이 있습니까?
도움이 된 좋은 시작하기 튜토리얼을 추천할 수 있습니까?

어쨌든 지금은 도우미 메뉴가 생성할 gdscript 구문을 다음과 같이 입력된 gdscript로 변경할 생각입니다.
https://github.com/godotengine/godot/pull/19264
그런 다음 대화형 이벤트 시트 셀 인터페이스를 렌더링하는 bbcode로 변환됩니다.

현재 어떻게 작동하는지 설명하기 위해 이 순서도를 만들었습니다.
https://www.draw.io/#Hblurymind %2FGodot-eventSheetPrototype%2Fmaster%2FEventSheetDiagramPlan.xml

@blurymind 튜토리얼을 위해 촬영하지 말고 실제 연습이나 다른 개발자로부터 배우는 것이 좋습니다.
아무도 나를 정말로 도와주지 않았습니다. 나도 별로 도움이 필요하지 않았다. 나는 물건을 잘 줍는 편이다. 그래서 모든 것이 잘 되었다. 아직 경험이 풍부한 개발자에 비해 시작에 불과합니다.

그리고 나는 당신이 모든 프로그래밍을 하기 위해 GDScript를 사용하고 있다고 믿습니다. 아니면 C++를 사용하고 있습니까?
기본적으로 또는 시작할 때 아무 것도 할 수 있는 모듈이 없기 때문입니다. 이미 있는 것에서 배워야 합니다. 그리고 직접 만드세요.

Typed GDScript로 변환하는 것은 GDScript를 사용하는 경우 간단해야 하고 C++를 사용하는 경우 약간의 이식이 필요합니다. 그리고 내가 아는 한 PR은 지금 언제든지 병합되어야 합니다. 검토했고 괜찮은 것 같습니다. 아직 시도하지 않았지만 정말 흥분됩니다.

그리고 현재 추측해 보겠습니다. 아마도 get_method_list() 및 get_property_list()와 함께 GDScript를 사용하고 있을 것입니다. 하지만 시그널과 그룹도 사용하는 것이 좋습니다. 시그널은 Godot 이벤트 발생 메커니즘입니다. 나는 EventSystem에 대해 잘 모르지만 Godot에서 그런 것을 만들고 싶다면. Godot를 최대한 활용하세요.

마지막으로 도움이 필요하시면 Twitter나 Discord로 메시지를 보내주세요. 나는 지금 며칠 동안 자유로울 것이다.

@swarnimarun 저는 gdscript를 사용하여 애드온을 작성하고 있으며 이벤트 트리거와 같은 일에 이미 신호를 사용하고 있습니다.
예, get_method_list() 및 get_property_list()를 사용하여 도우미 메뉴도 렌더링합니다.

트위터와 디스코드에 같은 핸들이 있습니까?

현재 내 계획은 gdscript에서 GUI 프로토타입을 내가 C++보다 더 많이 알고 있는 것으로 만드는 것입니다.
나는 javascrit에도 약간의 경험이 있지만 여기에서 많은 도움이되지 않습니다.

입력된 gdscript는 도우미 메뉴가 표현식 모드에 대해 생성하는 것입니다. 서식 있는 텍스트 레이블이 있는 UI를 렌더링하기 위해 bbcode로 변환하는 것이 더 좋습니다.

@blurymind 그럼 아주 좋습니다. 위의 gif에서는 그것을 보지 못했습니다. 그래서 나는 몇 가지를 가정했습니다.

내 핸들은 Discord에 있는 것이 Swarnim입니다. 그리고 당신은 이미 내 트위터를 알고 있다고 생각합니다.

@blurymind - 훌륭한 작품입니다. 나는 말 그대로 GDScript와 비교할 때 Godot의 성능 향상 때문에 C++를 배우기 시작했습니다(측정 기준에 따라 3~4배 더 빠름 - bunnymark 참조). 그것이 가능하다면 나는 그것이 직장에서 배우는 것을 의미하더라도 금을 위해 바로 가서 이것을 위해 C++를 사용하는 것이 좋습니다 - 그것은 그만한 가치가 있습니다. C++에 대한 느낌을 얻을 수 있도록 몇 주만 시간을 주시면 제가 도와드리겠습니다.

@colludium 3~4배 빠른 속도는 C++를 배우는 노력의 가치가 없습니다. 더 최적화된 게임을 만드는 방법을 배우고 싶다면 대신 C#을 배우십시오(Godot에서 성숙해짐에 따라 더 빨라질 것입니다). 또한 이제 입력된 GDScript가 함께 제공되므로 GDScript가 이전보다 훨씬 빨라질 것입니다. C#에 가깝습니다.

C++은 고통스럽습니다. 날 믿어. 포인터와 참조, 코드 컴파일은 고통일 뿐입니다. 큰 회사의 게임 개발자로 미래를 만들고 싶거나 대학에서 공부하거나 너무 똑똑해서 GDScript를 완전히 알고 있거나 프로그래머로서 프로 수준이 아니라면.

계속해서 GDScript 코드를 동적으로 생성하는 방법을 배우고 싶다면 언어에 대한 내보내기 시스템을 생성하는 것이 고통스럽기 때문에 GDScript 코드를 직접 생성하면 모든 작업을 훨씬 쉽게 수행할 수 있습니다.
그리고 추가 보너스로 보기 코드를 볼 수 있고 초보자가 코딩을 더 빨리 배울 수 있습니다.

@blurymind 기본 원인으로 사용 중인 EventSystem의 버전을 묻고 싶었습니다. 시스템의 프로토타입을 C++ 모듈로 만들고 싶었기 때문에 최소한 기본 수준에서는 동기화하고 싶습니다.

@swarnimarun - C++에 대한 조언에 감사드립니다. 저는 JavaScript에서 온 취미 프로그래머입니다. 그래서 최소한의 고통/최대 성능 전환이 제가 찾던 것입니다. GDScript를 훨씬 더 빠르게 만들기 위해 계획된 개선 사항에 대해 알지 못했습니다. 이제 C#이나 GDScript를 배우기가 훨씬 더 쉬운 문제가 생겼습니다...

@colludium 당신이 더 쉽게 찾을 수 있는 것이 무엇이든, 배경이 Javascript인 것을 보고 나는 GDScript를 추천합니다. 동적 타이핑도 있고 들어오는 정적 타이핑과 함께 완벽한 동반자가 되어야 합니다.
그리고 C++가 배워야 할 언어라고 생각하는 경우 일부 포럼의 Rust vs C++ 페이지를 확인하십시오.

@swarnimarun 저는 Godot 3.0.2를 사용하고 있습니다
다음은 프로젝트를 추가한 테스트 저장소입니다.
https://github.com/blurymind/Godot-eventSheetPrototype
누구나 자유롭게 포크하거나 풀 리퀘스트를 할 수 있습니다 👍

C++ 모듈 작성을 시작하십시오. 지금까지 내가 가진 기능은 인터페이스의 핵심 빌딩 블록인 논리 셀 컨테이너입니다.

bbcode 파서(그냥 정규식 사용)와 도우미 메뉴 렌더링이 가장 유용할 수 있습니다. 개인적으로 작동 방식을 변경할 생각을 하고 있지만 작업과 다른 프로젝트 사이의 자유 시간에 함께 부딪쳤습니다. . 문제는 현명하게 코드가 엉망이므로 경험 많은 프로그래머가 있는 것이 나에게 큰 도움이 될 것입니다.

나머지는 스크린샷을 위한 정적 인터페이스일 뿐입니다.

해야 할 매우 중요한 한 가지는 장면의 모든 노드와 해당 경로를 추적하는 일종의 편집 가능한 사전을 만드는 것이므로 정적 노드 경로 대신 도우미 메뉴에서 사전의 경로를 사용하는 gdscript를 생성해야 합니다. 자동으로 업데이트하고 사용자가 노드를 삭제하고 이벤트 시트의 논리에서 찾지 못한 경우 다시 연결할 수 있습니다.

어쨌든, 기본적인 것이더라도 무언가가 있으면 공유하십시오. C++을 조금 더 배우고 여러분과 함께 모듈로 작성해 보겠습니다. :)

@blurymind 드디어! Godot Engine 3.x 비주얼 스크립팅이 쓸모없다는 것을 아주 분명히 이해한 사람 (초보자에게는 너무 복잡하고 전문가에게는 쓸모가 없습니다).

GDevelop 이벤트 시스템은 굉장합니다! 특히 완전한 2D 게임 템플릿을 만들고 나중에 GDScript를 통해 고급 기능을 추가할 때 매우 유용합니다. 이것은 Godot 게임 엔진을 훨씬 더 매력적이고 인기 있고 널리 퍼질 것입니다!

저는 Godot 엔진을 진심으로 사랑하지만 모바일 장치용 2D 게임을 만드는 것은 가장 쉽고 즉각적인 해결책이 아닙니다. 단순화된 시스템/이벤트 시스템으로 훨씬 더 많은 것을 제공할 수 있습니다. Godot는 뛰어난 애니메이션 편집기를 가지고 있습니다. 정말 훌륭하고 기능적입니다. 수천 줄의 코드를 작성하지 않고도 2D 플랫포머를 만들고 싶다면 더 사용자 친화적인 시스템만 있으면 됩니다. NES용 스타일 템플릿 mario bros).

나는 @blurymind의 아이디어는 환상적인 것을 발견! Godot 커뮤니티는 엄청나게 성장했고 저는 그것에 만족합니다. 이벤트 시스템이 다음 릴리스에서 구현된다는 데는 의심의 여지가 없습니다. Visual Scripting(반복합니다)은 현재 절대적으로 쓸모가 없습니다.

축하합니다. 멋진 작업에 감사드립니다!

@XenonCoder 마지막에 흥미로운 점을 지적합니다.

Visual Scripting(반복합니다)은 현재 절대적으로 쓸모가 없습니다.

이것은 어떤 것이 본질적으로 사용하기 어려운 곳의 좋은 예이며, 나중에 왜 그것이 하지 않아야 하는지를 설명하는 자기실현적 예언으로 사용될 것입니다(예: "보십시오! 아무도 시각적 스크립팅을 원하지 않습니다!"), 그것이 단순히 매력적이거나 초보자에게 친숙한 방식으로 수행되지 않았다는 것을 인정하는 것보다.

반쪽짜리 선물이나 다름없기 때문에 사후관리가 없으면 정말 소용이 없습니다.

잘 문서화되지 않았거나 예제와 함께 제공되지 않은 엔진에 추가하는 경우에도 마찬가지입니다.

@bigelod 전적으로 동의합니다. 제 의도를 오해하지 않으셨다니 다행입니다. 제 의도를 완벽하게 이해하셨습니다.

Godot 게임 엔진은 정말 환상적입니다! 그것은 놀라운 잠재력을 가지고 있습니다. 2D 게임을 만들려면 1순위! 수년 동안 저는 기존의 모든 게임 엔진과 프레임워크를 실험해 왔으며 Godot는 훌륭한 것을 약속하는 프로젝트라는 것을 절대적으로 확신할 수 있습니다.

예를 들어, 새로운 비주얼 셰이더는 매우 좋아 보이며 미래를 위해 훌륭한 것을 약속합니다. 나는 몇 가지 테스트를했고 아이디어로 매우 좋아합니다. 그러나 비디오 게임의 논리를 실현하기 위해 Visual Scripting은 함정입니다.

튜토리얼, 일반적인 문서, 무엇보다 Build 3, GDevelop, Game Maker Studio 2 스타일의 단순화된 시스템이 필요합니다. 처음에는 주로 2D 게임을 구현하기 위한 애드온으로, 향후 개선되어 공식적으로 구현됩니다. 나는 그것이 쉬운 일이 아니라는 것을 깨달았습니다. 그것은 Godot 게임 엔진을 매니아, 학생 및 비디오 게임 전문가를 위한 이상적인 솔루션으로 만드는 아이디어일 뿐입니다.

모두 감사합니다.

게임 엔진 주위에 상점이 형성되었습니다. 상업적으로 애드온을 작성하는 것이 정상이되었습니다. 구성을 포함합니다. 마지막으로 중요한 C2 플러그인은 모두 상업용입니다. 이것은 시장의 형성뿐만 아니라 제품의 복잡성, 호환성 오류를 테스트하고 수정하는 데 많은 시간을 소비하기 때문입니다.
제 생각에는... Godot는 다른 틈새 시장에 있으며 Juan이 단순화된 프로그래밍의 응용 프로그램을 작성하고 지원하지 않는다면 다른 누군가가 이 작업을 끝낼 가능성은 거의 없습니다.

저는 Klik 'n Play, The Games Factory 및 Multimedia Fusion과 함께 성장했으며 요즘에는 Construct 2를 사용합니다. 이벤트 시트를 사용한 비주얼 스크립팅은 서로 연결된 청사진 스타일의 상태 기계 노드를 사용하는 것과 완전히 다르며 이벤트 시트에 익숙한 사람들에게는 가장 쉽고 효율적인 프로그래밍 방법입니다. 이벤트 시트를 사용하여 GoDot에서 스크립팅하는 방법을 기꺼이 환영합니다.

gdscript, 문서 및 플러그인 API에서 몇 가지 제한 사항에 도달하여 애드온으로서의 비전을 완전히 실행할 수 없습니다. 기능적 상태가 되더라도 제한이 있을 수 있습니다.

내가 거기에 도달하는 데 엄청나게 도움이 될 한 가지는 선택적 유형의 gdscript입니다 - 이것이 내가 Godot에 있을 때까지 이 작업을 중단한 이유입니다. 이제 병합되었습니다. 시간이 있을 때마다 개념 증명 애드온으로 다시 작업하겠습니다.

아이디어는 이벤트 시트의 생성된 gdscript가 입력된다는 것입니다. 입력된 데이터는 이벤트 시트 GUI에 예상되는 매개변수 유형에 대한 추가 컨텍스트 데이터를 제공합니다.

적절한 C++ 모듈이나 gdnative 애드온으로 이에 대한 관심이 있다면 누구나 자유롭게 구현을 시도할 수 있습니다.

얼마나 많은 사람들이 그것을 원하는지 알면, 이것을 Godot의 일부로 만드는 것보다 더 행복한 일은 없을 것입니다. 또는 적어도 Godot의 일부로 일하는 것입니다.

불행히도 나는 현재 시간의 대부분을 차지하는 정규직이 있습니다 :(
업데이트가 느린 점 죄송합니다

이 토론에 추가하기 위해 여기 있는 모든 사람에게 노드 연결 기반 시각적 프로그래밍 접근 방식을 사용하는 시각적 스크립팅 엔진의 환상적인 예를 제시하고 싶습니다.
https://youtu.be/b8GZ21YCh50?t=4m12s
https://www.reddit.com/r/unrealengine/comments/4nt0up/need_help_debugging_this_blueprint/ 와 다소 유사합니다.

Gamesfromscratch가 제공하는 대안을 참고하세요.

이 디자인 제안에서 내가 피하고 싶은 한 가지는 노드가 이미 Godot에서 수행하는 것 외에 많은 탭과 GUI를 생성하는 동작을 미리 정의하는 것입니다.
Godot 이벤트 시트는 더 촉각/시각적인 방식으로만 gdscript 코드처럼 정확하게 작동해야 합니다.
Godot 위에 사용하기 쉬운 게임 엔진을 구축하려고 해서는 안 되며, 오히려 Godot가 더 쉽게 접근할 수 있고 더 빠르게 조합할 수 있도록 합니다.

시각적 스크립트를 사용하면 터치 스크린에서도 액세스할 수 있습니까?

실제로 이벤트 시트 스타일의 시각적 스크립팅은 터치에 매우 적합합니다.
스크린

2018년 8월 1일 수요일 06:46 Elmapul, [email protected]에서 다음과 같이 썼습니다.

시각적 스크립트를 사용하면 터치 스크린에서도 액세스할 수 있습니까?

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

@blurymind 플러그인 시스템에 이에 대한 개선이 필요한 경우 문제를 여십시오. 다른 플러그인이 특히 필요하기 때문에 이미 수정되었습니다.

좋은 아이디어입니다! 저는 이러한 청사진을 전혀 이해하지 못했지만 이벤트 기반 접근 방식은 특히 워크래프트 III 월드 에디터와 같은 모딩 커뮤니티에서 잘 알려져 있습니다.

예시 화면:


카테고리와 트리거의 깨끗한 목록은 적어도 나에게는 멋지게 보입니다. 첫 번째 포스트의 화면보다 알아보기 쉽습니다.

그것은 당신이 말한 것과 거의 동일하지만 조건을 작업으로 추가하고 추가 작업을 중첩할 수 있습니다.

@와이아도미
이 이미지는 너무 작아서 아무 것도 보거나 읽을 수 없습니다.

@엘마풀
죄송합니다. 문제가 발생했습니다. 업데이트되었습니다.

@Elmapul 제 컨셉 애드온은 아직 중첩이

@blurymind는 마침내 이벤트 시트 구현 작업을 시작했습니다. 연구 논문이나 작동 및 구현에 대한 기사와 같이 구현에 대해 자세히 설명하는 리소스를 알고 있습니까?
큰 도움이 될 것입니다. Godot용 이벤트 시트 시스템 디자인을 시작하기 위해.
왜냐하면 Godot의 작동 방식이 상당히 다르기 때문에 Construct 또는 GDevelop 방법을 사용하는 것은 정확하지 않을 것이기 때문입니다. 그리고 우리는 통합해야 하는 신호와 그 이상을 필요로 합니다.

일반 정보가 필요한 경우 여기에 구성의 이벤트 시트에 대한 정보가 있습니다: https://www.scirra.com/manual/74/events
다른 회사는 이벤트 시트를 서로 약간 다르게 구현하므로 각각 고유한 특성이 있습니다.
아마도 나는 구성 방법의 다양한 부분을 요약하는 비디오를 만들 수 있을 것입니다(현재로서는 이것이 아마도 가장 좋은 방법일 것입니다).. 어떤 연구 논문도 모릅니다. 찾아보면 흥미로울 것입니다.

@prominentdetail 링크 주셔서 감사합니다. 이벤트를 구성 시스템처럼 사용하기 쉽게 만드는 방법을 알아야 할 것 같습니다.
내 첫 번째 아이디어는 @blurymind 의 애드온과 비슷한 것을

따라서 이벤트 시스템에 사용 편의성을 위해 추가하거나 GDScript에 대한 래퍼가 되기 위해 다른 API가 있어야 한다고 생각하십니까?

@swarnimarun 정말 가장 좋은 것은 잠시 동안 엔진을 사용하고 이것이 어떻게 더 신랄한 방식으로 수행될 수 있는지 생각하는 것입니다. Construct classic과 gdevelop이 좋은 예입니다.

내 관점에서 Godot의 신호는 내장 함수 이벤트와 같습니다. 연결 신호는 이미 Godot에서 시각적입니다 :)

이벤트 시트에서 신호를 설정하는 것은 도우미 메뉴에서 사용할 수 있는 작업일 뿐입니다. 후드 아래에는 setter 메서드일 뿐입니다. 따라서 gdscript와 동일합니다.

노드에 내장 메소드가 포함되어 있으면 '내장 기능 추가'를 클릭할 때 표시되는 메뉴에서 사용할 수 있어야 합니다.

나는 우리가 그것을 단순하게 유지하고 형식화된 gdscript에 대한 래퍼가 되어야 한다고 강력히 생각합니다. 그러나 그것이 가능하지 않거나 실용적이지 않다면 다른 API가 될 수 있습니다. 현재 Godot에서 구현된 시각적 스크립트가 추상화로 작동하는 방식을 조사할 가치가 있습니다.

사용자 정의 함수가 구성에서 어떻게 만들어지는지 궁금하다면 여기 해당 문서에 대한 링크가 있습니다.
https://www.scirra.com/tutorials/823/creating-function
:)

@blurymind GDScript 의 래퍼로 유지하는 것이 실제로 훨씬 쉽고 훨씬 적은 작업이지만 문제는 이벤트 시트의 많은 기능이 적어도 내가 이해하는 방식으로 더 지루해질 것이라는 점입니다.
그래서 나는 초보자를 위해 그것을 동일하게 유지하고 나중에 필요한 경우 추가할 것이라고 생각합니다.

@swarnimarun 시간을 내어

가장 큰 문제는 VisualScript가 Godot를 스크립팅하는 데 사용할 수 있는 다른 모든 언어와 마찬가지로 함수, 변수, 신호 및 기타 모든 것을 포함하여 가능한 한 GDscript의 기능에 가깝게 하려고 한다는 것입니다. 많은 기능을 잃어버리기 때문에 이벤트 시트 시스템으로는 이것을 달성할 수 없습니다. (가능하다는 것을 알고 있지만 빨리 부풀어 오를 것입니다)

@Jummit 완전히 할 수

그리고 GDscript의 모든 기능을 가질 수 있습니까? 그러면 우리는 무엇을 기다리고 있습니까? Godot에서 이벤트 시트를 받으세요!

@Jummit godot는 '노드' 형태로 원하는 모든 기능을 갖추고 있습니다.

Godot의 '노드'는 구성 2의 '동작'과 같습니다.
구성2의 플랫포머 동작은 덜 강력한 kinematicbody2d 노드와 같습니다. :)
처음부터 모든 것을 스크립팅할 필요는 없습니다.

더 멋진 점은 이러한 노드를 부모 자식 관계에 중첩할 수 있지만 동작은 모듈처럼 단일 게임 개체에 연결되도록 제한된다는 것입니다.

이벤트 시트 기능이 내장된 Godot와 커뮤니티의 몇 가지 추가 플러그인이 구성 2 또는 3보다 프로토타이핑을 위한 더 빠른 엔진이 될 수 있다고 굳게 믿습니다.
아직 개발되지 않은 가능성이 많습니다.

C2에서 프로토타이핑의 속도는 주로 셀의 상호 작용에 의해 결정됩니다. 드롭다운 목록은 오류를 거의 완전히 제거하는 동안 조건 개체를 포함하여 핫키로 끌기, 복사 및 변경할 수 있습니다.

@swarnimarun , 다양한 구성 요소에 대한 일반적인 개요를 만들었습니다. https://www.youtube.com/watch?v=ioz3gHtA-Lg
기본적으로 구성에 대해 너무 익숙하지 않은 사람을 위한 것입니다. 모든 것을 계획하지 않았기 때문에 여러 가지를 간과했을 수도 있지만 기본적인 이해는 제공할 수 있습니다. 여러 가지에 대해 떠드는 대신 워크플로 측면을 보여주기 위해 실제로 더 많은 개발을 수행하는 비디오를 만들어야 할 것입니다. 다루거나 탐구하고 싶은 것이 있으면 알려주십시오.

그것은 나에게 f**k만큼 추하다. 즉, 비디오의 스크립트입니다.

@Wiadomy 저 영상보다

@Wiadomy , 화면 녹화로 인해 하나의 모니터를 사용해야했고 텍스트 크기도 상대적으로 크게 유지해야했습니다. Construct는 긴 연속 표현식을 입력할 경우 화면 공간으로 인해 일부 항목이 뭉칠 수 있도록 텍스트 형식을 지정합니다.
그 중 일부를 해결하기 위해 텍스트를 축소하고 다른 모니터를 사용하여 이벤트를 더 잘 나열할 수 있는 공간을 확보할 수도 있습니다.
또한 표현을 좀 더 깔끔하게 만들기 위해 분할할 수도 있지만 이것은 내 오래된 프로젝트이고 좀 더 실험적입니다.
또한 이벤트 시트의 구조에서 시각적 신호와 패턴에 익숙해지므로 이벤트의 다양한 부분을 모두 추적하기가 더 쉬워집니다. 이와 같은 표준 구조를 갖는 것은 모든 프로젝트에 적응할 수 있다는 점에서 매우 유용하고 워크플로를 매우 빠르게 만듭니다.

이 프로젝트는 이제 종료되었습니까?

@Amr512 죽었다고 생각하지 않습니다. 확실히 이 기능을 Godot에 가져오고자 하는 열망이 많이 있습니다.
@reduz 는 최근 트위터에서 gdevelop에 관심을 보였습니다.
https://twitter.com/reduzio/status/1085206844275081218

한동안 애드온에 대한 작업을 하지 않았지만 실제로 gdevelop 자체에 기여하기로 결정했습니다. 이벤트 시트가 어떻게 프로그래밍되는지 알아보고 유료 애드온의 더 나은 대안을 만드는 데 도움이 됩니다. 옵션.
https://github.com/4ian/GDevelop/

일부 대학은 프로그래밍 과정을 가르치기 위해 gdevelop을 선택하기 시작했습니다.
https://github.com/4ian/GDevelop/issues/882

내 buggy godot 애드온은 현재 프레젠테이션용이며 작동하려면 많은 작업이 필요합니다. 누구나 자유롭게 포크하고 더 나아가려고 할 수 있습니다.
내 애드온에 현재 누락된 한 가지 큰 점은 이벤트 행에 대한 정렬 가능한 트리 GUI 요소입니다. 실제로 이벤트 시트를 gdscript로 렌더링하는 기능도 아직 없으며 구문 자동 완성 및 색상 지정 기능이 있는 적절한 표현식 텍스트 편집기도 없습니다(이 아이디어는 구문에 표준 gdscript를 사용하는 것입니다). 이벤트 시트를 만드는 주요 요소가 많이 빠져 있지만 주요 목표는 이벤트 시트를 gdscript와 조합하여 표현식 구문에 사용할 수 있는 방법을 제시하는 것입니다. 경험 많은 개발자에게도 이 둘은 게임 프로토타이핑에 매우 강력한 조합이 될 것이라고 생각합니다.

@blurymind 귀하의 프로젝트에 티켓을 남겼습니다(Godot 3.1beta3의 오류).
나는 그 아이디어를 완전히 사랑한다.

우연히 이 문제를 발견했는데, 이 항목이 이미 다른 엔진/프레임워크에서 일반적으로 사용된다는 사실을 전혀 몰랐기 때문에 직접 작성해야 했습니다. 보기에는 매우 비슷하지 않나요? 👀

규칙 = 이벤트
이벤트 시트 = 계획

이전 구현에서는 상당히 "낮은 수준의" 속성 검사와 각각의 작업을 사용했지만 이러한 종류의 시스템은 실제로 더 "높은 수준의" 조건/작업 기본 스크립트를 확장하여 게임플레이 "구성 요소"를 정의하는 데 더 유용하다고 생각했습니다. 수준"을 추상화합니다. 그래서 처음에 "규칙"이라는 용어를 선택한 이유가 바로 이것입니다.

이것을 최대한 활용하려면 게임 플레이와 게임 프레임워크가 이미 구축되어 있어야 하므로 코딩 없이 게임을 작성하는 즉시 사용 가능한 경험을 제공하지 않지만 실제로 다음을 허용하는 방식으로 보완합니다. 기존 기능을 다양한 방식으로 결합하고 효율적으로 구성하려면 일반 GDScript를 사용하여 다른 조건과 작업으로 새 규칙을 작성하기만 하면 됩니다.

그리고 네, 플레이어가 모드를 통해 자신의 게임 모드/미션/챌린지를 만들 수 있도록 하는 것은 이러한 시스템을 사용하는 또 다른 이유입니다.

@Xrayez git repo를 공유할 수 있습니까? 내 구현이 너무 세분화되어 있다는 것은 당신이 옳다고 생각하지만, gdscript와 Godot의 API가 작동하는 방식에 대해서는 사실입니다.
또한 스크린샷만 보면 요점을 놓치고 있다고 생각합니다. 3열이 아니라 2열이어야 합니다. 왼쪽= 조건, 오른쪽= 행동. 또한 셀 간에 이벤트를 끌어다 놓을 수 있어야 하며 행을 끌어다 놓을 수도 있어야 합니다. 이것을 구축하려면 정렬 가능한 트리를 사용해야 합니다. gdevelop 및 구성과 함께 플레이하면 이 이벤트 시트가 왜 좋은지 더 잘 알게 될 것입니다.

아마도 내 구현은 DSL 과 유사한 것으로 간주될 수 있으므로 차이점이 나타날 수 있습니다. 많은 규칙은 특정 게임 플레이 요구 사항에 맞게 조정된 기능의 샌드박스 구현에 불과합니다. 본질적으로 조건과 작업은 자식 클래스에서 구현되어야 하는 메서드와 함께 이러한 작은 스크립트를 상속합니다.

class_name SchemeCondition extends Node

func is_met(object): # override
    return true

class_name SchemeAction extends Node

func perform(object): # override
    pass

규칙은 이러한 조건과 행동의 단지 모음 전부 또는 어떤 조건이 사실, 아무것도 너무 화려한를 충족 여부에 따라 실행됩니다.

코딩과 같은 것을 구현하고 기여하고 모든 사람들이 코딩 없는 프로그래밍의 매력을 보지는 않지만 많은 다른 사람들이 실제로 그것에 관심이 있다는 것을 알았습니다.

Construct, Gdevelop, Stencil, Game Maker, Playmaker, Bolt, Fungus for Unity, Unreal의 Blueprints, CryEngine의 Flow Graph 및 Schematyc 등...

비 코더를 위한 많은 도구가 만들어지고 사용됩니다. 덕분에 좋은 게임이 많이 만들어졌습니다.
할로우 나이트는 예를 들어 플레이메이커로 완료되었습니다.

Dreams 와 같은 것들이 꽤 소음을 내고 있습니다.

이러한 종류의 도구는 많은 매력과 접근성을 제공하여 Godot에 새로운 사람들을 가져다 줄 것입니다.

나는 최근에 다음과 같은 드롭다운을 통해 이벤트 시트에 새 지침을 추가하는 방법을 gdevelop에서 구현했습니다.

그것이 Godot에게 잘 맞을 수 있다고 생각하는 종류입니다.

Richtextlabel을 사용하여 각 셀을 렌더링합니다. 이러한 셀은 왼쪽 및 오른쪽 열에 중첩되어 행의 자식이 됩니다. 행은 정렬 가능한 트리에서 관리합니다. 각 행에는 인터프리터가 표현을 입력하기 위해 썸네일 및 클릭 가능한 영역이 있는 간단한 짧은 설명으로 렌더링하는 실제 gdscript가 포함되어 있습니다.
이것은 실제로 게임 메이커가 하는 일입니다. 그들의 시각적 프로그래밍 데이터는 실제 gml로 저장됩니다.

gdscript 확장으로 시작했을 때 발견한 까다로운 부분은 표현식 필드를 수행하는 것이었습니다. 코드 편집기를 입력 필드에 넣고 자동 완성을 하게 하려면 어떻게 해야 합니까? 완료 및 유효성 검사 컨텍스트를 어떻게 제공합니까? 검증된 자동 완성 표현식 필드가 없으면 이것은 물에 잠긴 것입니다.

우리는 이것을 Godot에 구축하기 위한 모든 UI 부분을 가지고 있지만, 말 그대로 그것에 대해 아무것도 하는 경험 많은 개발자가 없습니다. 지금까지 한 작품을 본 적이 없다.

어쨌든, 내 C++ 지식이 더 좋았다면 시도해 보았을 것입니다 :) 하지만 자바 스크립트를 알고 있으므로 내 기여는 대신 gdevelop으로 이동합니다.

Godot에서 이벤트 기반 솔루션을 보고 싶습니다. 예전에 Godot를 사용해 보았지만 작업 흐름이 마음에 들지 않았습니다. 내 마음은 게임을 개발할 예정이라면 이벤트 시트에 더 적합합니다.

저는 이제 프로그래머이고 엔진 개발에 뛰어들기 시작했습니다. 그러나 나는 여전히 이벤트 시트에 대해 꽤 자신있게 보증할 수 있습니다.

Construct 2는 사실 고등학교 때 수강한 수업을 통해 많은 기본적인 프로그래밍 개념에 대한 나의 첫 번째 노출이었습니다. 이벤트 시트에서 전환할 때 완전히 길을 잃지 않은 실제 코드로 충분히 밀접하게 번역하면서 특정 엔진과 일반적인 프로그래밍 모두에 대한 학습 프로세스를 크게 단순화하고 신속하게 처리했다고 생각합니다. 일반 오래된 텍스트 스크립팅에. 이것에 대해 100% 확신할 수는 없지만 스파게티 유형의 비주얼 스크립팅이 있었다면 그 혜택 중 어느 것도 같은 정도로 얻을 수 없었을 것이라고 생각합니다.

그러나 두 가지 다른 시각적 스크립팅 시스템을 유지하는 것은 아마도 나쁜 생각이라는 데 동의합니다. 즉, 우리가 이미 얻은 시스템이라는 이유만으로 현재 시스템을 고수해서는 안 된다고 생각합니다. 데이터가 보증한다면 다른 시스템으로 전환하는 것을 정말로 고려해야 한다고 생각합니다. 즉, 이벤트 시트 시스템이 현재 시스템에 비해 얼마나 더 접근하기 쉬운지에 대해 더 나은 아이디어를 얻으려고 노력해야 한다고 생각합니다. 시각적 스크립팅의 목표는 일반 스크립팅에 익숙하지 않거나 자신이 없는 사람들에게 엔진을 더 친숙하게 만드는 것이어야 합니다. 견고한 시각적 스크립팅 시스템은 Godot가 얼마나 접근하기 쉬운지에 큰 차이를 만들 수 있으며, 그렇지 않았다면 Godot를 고려하지 않았을 더 많은 사람들의 지원과 채택을 의미할 수 있습니다.

사실 내가 처음에 Construct 2에서 손을 뗀 가장 큰 이유는 단순히 3D에 입문하고 싶었기 때문입니다. 나는 Unity, Unreal, Godot, Amazon Lumberyard를 사용하다가 결국에는 열고 사용하기가 더 빠르고 가져오기 프로세스가 더 좋게 느껴졌기 때문에 Godot를 선택하게 되었습니다. 그러나 Godot에 이벤트 시트 스타일 시스템이 있었다면 저는 즉시 Godot로 기본 설정했을 것입니다. 물론 지금은 개인적으로 별 차이가 없지만 다시 말하지만 이것은 Godot를 프로그래머가 아닌 사람들(즉, 새로운/지망생 게임 개발자의 상당 부분)에게 가능한 한 친근하게 만드는 것입니다.

지금은 숨겨져 있는 112개의 게시물을 읽지 않았기 때문에 반복하거나 놓친 부분이 있으면 사과드립니다. 하지만 아이디어를 프로토타이핑하거나 테스트하고 고려하는 데 전적으로 관심이 있을 것입니다.

데이터가 보증한다면 다른 시스템으로 전환하는 것을 정말로 고려해야 한다고 생각합니다. 즉, 이벤트 시트 시스템이 현재 시스템에 비해 얼마나 더 접근하기 쉬운지에 대해 더 나은 아이디어를 얻으려고 노력해야 한다고 생각합니다.

우리는 이미 현재 비주얼 스크립팅 시스템에 대한 유지 관리자가 거의 없습니다. 나는 우리의 일생에 완전한 전환이 완료될 것이라고 생각하지 않습니다 :slightly_smiling_face:

우리는 이미 현재 비주얼 스크립팅 시스템에 대한 유지 관리자가 거의 없습니다. 나는 우리의 일생에 완전한 전환이 결코 완료되지 않을 것이라고 생각합니다 🙂

먼저 이벤트 시트의 작업 프로토타입을 얻는다고 가정하면 코드는 이미 대부분 완료되고 대신 해당 시스템으로 전환할지 여부에 대한 질문이 될 것입니다. 그렇죠?

나는 또한 Construct 2로 시작했고 이벤트 시트가 2를 해결하는 데 훌륭하다는 것을 발견했습니다.
문제:

• 모든 시각적 스크립팅과 마찬가지로 모든 가능성을 노출합니다.
  module/plugin/add-on/function, 이것은 새로운 코드를 배우는 데 매우 유용합니다.
  비주얼 노드는 꽤 빨리 스파게티 코드로 바뀝니다. (저는 믹서기 전문가입니다.
  합성기와 셰이더의 스파게티에 대해 알고 있습니다.)
• 이벤트 시트는 Rest API에 대한 swagger와 같으며 잘 문서화되어 시작됩니다.
  이벤트 시트 드롭다운 메뉴를 채우고 깨끗한 GUI를 얻는 코드
  코드를 사용하는 방법을 사용하면 지저분해지고 확장할 수 있습니다.
  그것에서 코드를 생성(Construct2의 JS), 따라서 내 질문:
  그것에서 코드를 생성?

그렇다면 사용 편의성을 위해 이벤트 시트가 우선 순위가 되어야 한다고 생각합니다.
모든 사람과 최적화된 저수준 코드 생성.
Godot를 사용하여 python/C#/... API를 깨끗한 집합으로 변환할 수 있다면
이벤트, 사용자 빌드 이벤트, 그리고 Godot는 그것으로부터 코드를 생성합니다, 당신은
매우 어려운 사용자 문제 해결: 간단한 UI에서 코딩하는 방법을 배웁니다.

나는 이벤트 시트가 모든 문제를 해결하지 못한다는 것을 알고 있지만 적어도 500을 코딩할 수 있습니다.
시각적으로 손실되지 않고 스프레드시트에서 수행하는 것과 같은 이벤트
여기저기 링크.

2020년 4월 8일 수요일 오후 7시 44분 Jay [email protected]이 다음과 같이 썼습니다.

현재 시각적 스크립팅에 대한 유지 관리자는 이미 거의 없습니다.
체계. 나는 우리의 완전한 전환이 결코 완료될 것이라고 생각하지 않는다.
평생 🙂

우리가 이벤트 시트의 작동하는 프로토타입을 얻었다고 가정하면, 그 다음 코드는
이미 대부분 완료되었을 것입니다.
그 대신에 전환하고 싶습니까?

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/godotengine/godot/issues/17795#issuecomment-611096608 ,
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AAAP6LM4PU6RYLO5NK5IL23RLSZWHANCNFSM4EXTBSVQ
.

나는 Construct 2를 사용하기 시작했고 결국 JavaScript를 사용하여 플러그인 개발로 넘어갔고, 그래서 이벤트 시트는 내 마음에 자리를 잡았습니다. 각 클래스(플러그인)에 대해 사용 가능한 메서드(작업 및 조건)를 쉽게 시각화하여 대부분의 마법을 사용하여 초심자에게 쉽고 직관적이었습니다. 솔직히 말해서, VSCode의 GDScript는 완전한 인텔리센스와 자동 완성 기능을 통해 삶을 산들바람처럼 만들어줍니다. 2년 전에는 이 아이디어의 열렬한 팬이었지만 지금은 생각이 바뀌었습니다. 차라리 Godot 개발 영웅들이 다른 엔진 개선 사항을 추가하는 데 시간과 노력을 집중했으면 합니다.

코드를 생성할 수 있습니까?

좀 더 살펴봐야 하겠지만, 솔직히 그렇게 하는 것은 아주 사소한 일이라고 생각하고, 실제로 가장 좋은 방법일 것입니다. 즉, 이벤트 시트 스타일을 처리하는 가장 좋은 방법은 기본적으로 일반 gdscript 파일에 대한 그래픽 프런트 엔드 역할을 하도록 하는 것입니다. 이벤트 시트 편집기에서 수행된 작업은 단순히 gdscript 파일을 편집합니다. 예를 들어 이벤트 시트 편집기에서 블록을 한 위치에서 다른 위치로 이동하는 것은 기본적으로 gdscript 파일에 가상 잘라내기+붙여넣기와 같은 작업을 수행합니다. 그리고 모든 gdscript 파일은 스크립트 편집기나 이벤트 시트 편집기에서 보고 편집할 수 있습니다. 이것은 사용성 관점과 구현 관점 모두에서 가장 좋은 방법인 것 같습니다. 아직 엔진 개발에 대해 잘 알지 못해서 틀릴 수 있습니다.

차라리 Godot 개발 영웅들이 다른 엔진 개선 사항을 추가하는 데 시간과 노력을 집중했으면 합니다.

꽤 동의합니다. 이에 대한 이상적인 방법은 작업하는 프로토타입을 함께 만들고자 하는 관심 있는 사람이라면 누구나 커뮤니티에서 메인 비주얼 스크립팅 시스템으로 전환할 가치가 있는지 알아낼 수 있을 것이라고 생각합니다. 나는 결정이 내려지거나 적어도 가까워질 때까지 이 아이디어에 대한 주요 개발 시간을 묻지 않을 것입니다.

나는 Gdscript나 Godot도 충분하지 않습니다.
하지만 내가 VS Code 확장으로 개발한 것도 이 광범위한 방식으로 진행되고 있습니다.
(https://github.com/j2l/blocklight).
코드 덩어리를 가지고 놀면서 시각적으로 코드를 이해하고 시각적으로
변수와 결과 연결(대부분의 시각적 스크립트의 노드 또는 색상
내 확장에서)는 많은 사람들에게 누락된 초석입니다.
사실, 우리는 학습을 마쳤을 때 코드를 이해하지만,
모든 정보를 얻기 전에 변수와 청크의 링크를 확인하십시오.
암호.
코딩 전 디자인 :)

2020년 4월 8일 수요일 오후 8시 08분 Jay [email protected]이 다음과 같이 썼습니다.

코드를 생성할 수 있습니까?

좀 더 지켜봐야 알겠지만 솔직히 예쁠 것 같아요
그렇게 하는 것은 사소하지만 실제로는 아마도 가장 좋은 방법일 것입니다. 그건,
이벤트 시트 스타일을 처리하는 가장 좋은 방법은 기본적으로
일반 gdscript 파일의 그래픽 프론트엔드 역할을 합니다. 행위
이벤트 시트 편집기에서 가져온 것은 단순히 gdscript 파일을 편집합니다. 움직이는
이벤트 시트 편집기에서 한 장소에서 다른 장소로의 블록은 기본적으로
후드 아래에서 gdscript 파일에 가상 잘라내기 + 붙여넣기를 수행합니다. 그리고
모든 gdscript 파일은 스크립트 편집기 또는 다음에서 보고 편집할 수 있습니다.
이벤트 시트 편집기. 이것이 가장 좋은 방법인 것 같습니다.
사용성 관점과 구현 관점에서. 그 말은 내가
아직 엔진 개발에 대해 잘 알지 못하기 때문에 실수할 수 있습니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/godotengine/godot/issues/17795#issuecomment-611108712 ,
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AAAP6LN7GFGSBDZ537XXA6DRLS4Q5ANCNFSM4EXTBSVQ
.

나는 그것이 일반 Gdscript 파일을 생성한다는 아이디어를 좋아합니다. 학습용으로 정말 좋을 것 같아요

내가 게임을 만들기 시작했을 때 Klik & Play의 이벤트 시스템은 프로그래밍 로직을 머리에 새기게 하는 정말 좋은 방법이었고, 지금도 여전히 예전으로 돌아가는 것을 좋아합니다.

나는 그것이 일반 Gdscript 파일을 생성한다는 아이디어를 좋아합니다. 학습용으로 정말 좋을 것 같아요

내가 게임을 만들기 시작했을 때 Klik & Play의 이벤트 시스템은 프로그래밍 로직을 머리에 새기게 하는 정말 좋은 방법이었고, 지금도 여전히 예전으로 돌아가는 것을 좋아합니다.

현재 스파게티 시스템에 비해 잠재적으로 가장 큰 장점 중 하나라고 생각합니다. 설계로 인해 사람들이 프로그래밍과 gdscript/godot의 API를 쉽게 배울 수 있을 것입니다.

여기에서 일부 사람들이 댓글을 달았지만 왜 귀찮게 했는지는 프레젠테이션에서 스크립팅하는 것과 너무 비슷합니다.
그에 대한 내 대답은 - 정확히입니다. 스파게티를 배우면 스파게티가 남습니다. 이벤트 시트를 배우면 gdscript가 생성하는 것을 보고 해당 표현식 필드를 사용하여 gdscript를 알 수 있습니다.

실행 순서와 코드 읽는 방법을 알려줍니다.

게임 메이커에서 GML로 변환하는 작업 보기
https://docs2.yoyogames.com/source/_build/3_scripting/1_drag_and_drop_overview/change_dnd.html

정말 흥미로운 블러마인드! 저도 같은 생각이었고 전적으로 지지합니다.
저는 여전히 Clickteam Fusion 2.5용 확장을 만들고 있지만 Fusion에 추가하고 싶은 것은 모두 Godot에 있습니다.
내가 필요한 것은 개발을 더 쉽게 만들기 위해 Godot에 추상화 레이어(이벤트 시트)를 하나 더 넣는 것입니다.
전체 스레드를 읽지는 않았지만 Godot의 시각적 스크립팅과 다른 게임 엔진의 이벤트 시트 간의 주요 차이점은 시각적 스크립팅은 코드의 "그저" 시각적 보기이고 이벤트 시트는 추상화라는 것입니다. 단순화된 보기의 코드입니다. 사람이 더 읽기 쉽고 한 줄에 여러 줄의 코드가 필요한 것을 인수분해하고 신호/슬롯 연결이 자동으로 수행됩니다.
사실, CF2.5 내장 객체를 추상화하고 여전히 GDScript를 사용하기 위해 일부 템플릿(미리 정의된 장면)을 추가하면 대부분의 작업을 수행할 수 있지만 이벤트 시트는 확실히 CF2.5에서 수행하는 것보다 Godot에서 더 효율적입니다. 지금.

정말 흥미로운 블러마인드! 저도 같은 생각이었고 전적으로 지지합니다.
저는 여전히 Clickteam Fusion 2.5용 확장을 만들고 있지만 Fusion에 추가하고 싶은 것은 모두 Godot에 있습니다.
내가 필요한 것은 개발을 더 쉽게 만들기 위해 Godot에 추상화 레이어(이벤트 시트)를 하나 더 넣는 것입니다.
전체 스레드를 읽지는 않았지만 Godot의 시각적 스크립팅과 다른 게임 엔진의 이벤트 시트 간의 주요 차이점은 시각적 스크립팅은 코드의 "그저" 시각적 보기이고 이벤트 시트는 추상화라는 것입니다. 단순화된 보기의 코드입니다. 사람이 더 읽기 쉽고 한 줄에 여러 줄의 코드가 필요한 것을 인수분해하고 신호/슬롯 연결이 자동으로 수행됩니다.
사실, CF2.5 내장 객체를 추상화하고 여전히 GDScript를 사용하기 위해 일부 템플릿(미리 정의된 장면)을 추가하면 대부분의 작업을 수행할 수 있지만 이벤트 시트는 확실히 CF2.5에서 수행하는 것보다 Godot에서 더 효율적입니다. 지금.

예전에 멀티미디어 퓨전이라고 하던 시절에 CF를 사용했는데, 영어를 못하는 아이처럼 배우기 쉬웠고, 연습한 후에는 무엇을 하느냐에 따라 매우 빠르게 할 수 있습니다. 타이핑보다 빠릅니다.
구성 및 CF는 좋은 시각적 스크립팅이 어떻게 생겼는지에 대한 참조입니다(gdevelop이 거기에 도달하고 있음).

감사합니다
이 멋진 아이디어를 지지합니다
그들은 건설 2가 은퇴할 것이라고 말합니다!
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505

이벤트 시스템의 오픈소스화를 위해 컨스트럭트 2의 개발자와 협의가 가능한지, Godot, Unity 등에서 사용 가능한지 궁금합니다.
2 이벤트 시스템 구축이 미사용 선반에 방치되어 있다는 것은 손실입니다.

감사합니다
이 멋진 아이디어를 지지합니다
그들은 건설 2가 은퇴할 것이라고 말합니다!
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505

이벤트 시스템의 오픈소스화를 위해 컨스트럭트 2의 개발자와 협의가 가능한지, Godot, Unity 등에서 사용 가능한지 궁금합니다.
2 이벤트 시스템 구축이 미사용 선반에 방치되어 있다는 것은 손실입니다.

나는 우리가 godot에서 구조2의 어떤 코드라도 사용할 수 있을지 의심스럽습니다. 그것들은 완전히 다른 코드베이스입니다.

오픈 소스 대안을 위한 최선의 방법은 gdevelop으로 이동하는 것입니다.
https://github.com/4ian/GDevelop

이 발행 티켓은 곧 종료될 것이므로 Godot에서 이 이벤트 시트에 관심이 있다면 곧 다른 곳으로 옮겨야 할 수도 있습니다 :) (또는 gdevelop)

이 발행 티켓은 곧 종료될 것이므로 Godot에서 이 이벤트 시트에 관심이 있다면 곧 다른 곳으로 옮겨야 할 수도 있습니다 :)

뭐? 왜요?

@TheGoklayeh 기능 제안을 Godot-proposals 로 마이그레이션하는 중이므로 폐쇄될 수 있습니다.

즉, @blurymind 는 제안서 템플릿 과 일치하도록 첫 번째 게시물을 편집할 수 있습니다. 그런 다음 이 문제를 제안 저장소로 이동할 수 있습니다.

이벤트 시트를 활용하는 3D 엔진이 정말 필요합니다.

감사합니다
이 멋진 아이디어를 지지합니다
그들은 건설 2가 은퇴할 것이라고 말합니다!
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505

이벤트 시스템의 오픈소스화를 위해 컨스트럭트 2의 개발자와 협의가 가능한지, Godot, Unity 등에서 사용 가능한지 궁금합니다.
2 이벤트 시스템 구축이 미사용 선반에 방치되어 있다는 것은 손실입니다.

그것은 그들의 사업을 망칠 수 있습니다. 그리고 clickteam.

감사합니다
이 멋진 아이디어를 지지합니다
그들은 건설 2가 은퇴할 것이라고 말합니다!
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505
이벤트 시스템의 오픈소스화를 위해 컨스트럭트 2의 개발자와 협의가 가능한지, Godot, Unity 등에서 사용 가능한지 궁금합니다.
2 이벤트 시스템 구축이 미사용 선반에 방치되어 있다는 것은 손실입니다.

그것은 그들의 사업을 망칠 수 있습니다. 그리고 clickteam.

무엇이든 그들을 죽이는 경우 - clickteam은 소프트웨어 업데이트가 부족하기 때문일 것입니다(마지막 업데이트는 2019년에 있음). Scirra는 사용자가 매년 비용을 지불하거나 잠겨. 두 회사 모두 결함이 있으며 해당 커뮤니티는 소프트웨어에 발생하는 일을 제어할 수 없습니다. 오픈소스가 빛을 발하는 곳

@TheGoklayeh 기능 제안을 Godot-proposals 로 마이그레이션하는 중이므로 폐쇄될 수 있습니다.

즉, @blurymind 는 제안서 템플릿 과 일치하도록 첫 번째 게시물을 편집할 수 있습니다. 그런 다음 이 문제를 제안 저장소로 이동할 수 있습니다.

나 대신 누군가가 그렇게 할 수 있습니까? :)
나는 이 기능이 (확장이 아닌) 기본적으로 Godot에 도달할 것이라는 희망을 잃었습니다. 스파게티 접근 방식은 Godot 사용자와 개발자를 압도했습니다.

@blurymind 더 이상 이 제안을 지지하지 않는다면 닫는 것이 낫다고 생각합니다. 이벤트 시트 접근 방식 작업에 관심이 있는 다른 사람이 godot-proposals 에 대한 새 제안을 열 수 있습니다. (필요한 작업량으로 인해 기술적으로 수행할 수 있는 사람이 아무도 없는 경우 제안서를 여는 것이 의미가 없다고 생각합니다.)

그래도 이 스레드에는 귀중한 토론이 많이 포함되어 있으므로 어쨌든 감사합니다 :slightly_smiling_face:

이 제안은 매우 어리석은 것 같아요 :)
하지만 우리는 구성 3 엔진으로 이벤트 시스템을 만들 수 있습니까?!
게임이 코드를 생성하고 node.js를 통해 Godot 엔진에 텍스트 파일로 보낼 수 있다고 생각합니다.

말도 안되는 소리지만 3번 구성은 이벤트 시스템을 만들기에 충분히 강하다고 생각합니다.
현재로서는 없는 것보다 낫다.

예, 적어도 우리는 Godot에서 그러한 시스템에 대한 아이디어, 현재의 비주얼 코딩 시스템에 대한 이점 및 이를 사용하는 다른 엔진에 대한 의견에 도달할 수 있기를 바랍니다.

솔직히 GDevelop이 하는 방식은 마음에 들지만 Godot가 이벤트 스크립트를 하는 것은 지금(요즘) 제가 좋아하는 것이 아닙니다.
한 번 구현하려고 했고 Godot가 Visual Scripting 시스템에서 직접 노출될 수 있는 매우 세분화된/낮은 수준의 API를 가지고 있다는 사실을 깨닫고 충격을 받았습니다.
현재 시각적 스크립팅 시스템이 포함되어 있으며 사용자 지정 추상화 레이어를 사용하면서도 여전히 강력한 것을 선호하는 이유가 있습니다.
이러한 구현은 각각이 엔진의 특정 부분에 사용되는 하위 이벤트 스크립트 언어와 같은 여러 DSL을 사용하지 않는 한 이벤트 스크립트에 대해 쓰기가 매우 어렵습니다.

간단하고 사용하기 쉬운 일반화된 비주얼 스크립팅 시스템은 달성하기가 상당히 어려울 것이며 제가 "유니콘 프로젝트"라고 생각하는 것입니다.
일반화의 증가는 해당 시스템의 복잡성을 훨씬 더 크게 증가시킬 가능성이 매우 높기 때문입니다.

Visual Scripting은 엔진의 모든 부분에 대해 특화된 인터페이스를 가질 수 있는 방향으로 점차적으로 나아갈 계획입니다.
블루프린트와 같이 표현식 노드가 있는 각 유형의 기본 복합 노드에 대해 다른 편집 방법을 상상해 보십시오.
https://docs.unrealengine.com/en-US/Engine/Blueprints/UserGuide/MathNode/index.html

하지만 분명히 말씀드리자면 저는 이벤트 스크립팅에 반대하는 것이 아닙니다. 누군가 Godot의 특정 시스템을 다룰 수 있는 제안을 하는 것을 보고 싶습니다. 그리고 그것이 왜 그리고 어떻게 유용할 수 있습니까? 개인적으로 저는 GDevelop이 어떻게 동작하는지 프로그래밍하는 것이 아주 좋다고 생각합니다.
http://wiki.compilgames.net/doku.php/gdevelop5/behaviors
http://wiki.compilgames.net/doku.php/gdevelop5/behaviors/events-based-behaviors

적절한 게임을 작성하는 데 사용하지는 않겠지만 간단한 동작이 있으면 드롭다운하여 가지고 놀 수 있습니다. 아이들이 게임 만드는 법을 배우는 프로젝트를 최적화할 수 있는 아주 재미있는 방법이라고 생각합니다.
또는 게임 잼에 사용하는 프로그래밍에 익숙하지 않은 사람.

VisualScript와 모듈화에 대해서도 마찬가지지만 이를 사용하면 훨씬 쉽게 달성할 수 있습니다. 문제는 통일성과 일관성입니다(Visual Shader와 VisualScript는 완전히 다른 코드베이스를 사용하며 유사성만 사용되는 UI 노드).
그래도 우리는 이벤트 스크립트 시스템을 커뮤니티에서 유지 관리할 수 있고 필요할 때 Godot에 추가할 수 있는 플러그인(C++ 플러그인, 4.0 이후에 하기 쉬워짐)으로 확실히 시도할 수 있습니다. (저는 모듈식 게임 엔진에 편향되어 있습니다)

어쨌든 그것은 내 2센트입니다.

내 댓글이 주제가 아닌 것으로 표시된 이유는 무엇입니까? 누군가가 커뮤니티를 검열하고 있습니까? 좋은 징조가 아닙니다. 저 말고도 주제를 벗어난 다른 댓글이 있습니다.

@prominentdetail 여기 내 충돌 방지 알림 메시지가 있습니다. 붙여넣는 것을 잊었습니다

중요한 새 정보를 제공하지 않고 문제를 부딪치지 마십시오. 대신 첫 번째 게시물에 :+1: 반응 버튼을 사용하세요.

(GitHub에 개인 메시지를 보낼 수 있는 방법이 있거나 최소한 숨기는 사용자 지정 이유를 지정하는 방법이 있었으면 좋겠습니다. 그래서 댓글 스레드를 이것으로 어지럽힐 필요가 없습니다.)

추신: 이것은 GitHub의 일반적인 에티켓입니다. 이 저장소에만 해당되는 것은 아닙니다.

나는 이 제안을 지지하지만 아무도 그것을 구현하는 데 시간을 할애하지 않을 것이라고 생각합니다.
실제로 실현할 수 있는 개발자의 강력한 지원이 없습니다.

시도해 볼 가치가 있었고 토론은 확실히 흥미로웠습니다. :)

여전히 제안을 지지하고 시간을 내어 GIP에 필요한 형식으로 작성할 의향이 있다면

Godot에 기능이 추가되는 방식은 기능에 관심이 있는 누군가가 기능을 구현하는 데 시간이 걸리는 경우입니다. 그것은 매우 무작위적이고 산발적입니다. 그러나 우리는 기능 추가를 무작위로 결정하는 기여자들에게 거의 전적으로 의존합니다.

따라서 현재 활동 중인 개발자들이 귀하의 제안에 관심을 갖지 않았다고 해서 누군가가 제안을 이행하지 않을 것이라는 의미는 아닙니다.