You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Godot은 오픈소스라는 특징, 가볍다. 2D게임에 특화된 것 같음, 사용성 좋음
Unity는 2D/3D다 좋음, 학습 곡선 중급 정도, 에셋 스토어 존재
unreal 고성능 3D에 매우 좋음, 대규모 프로젝트에 적합..?
본문
글은 여타 인터넷에 있는 글보다는 실제로 3개의 엔진을 사용해본 이정안의 입장에서 작성해본다. 개인적인 경험 위주로 작성할 예정이라 틀린 점이 있을 수 있다는 점 (발표용)
유니티는 처음 게임개발을 시작한 엔진으로 대부분의 게임 구조를 만들거나 떠올릴 때 유니티에 맞는 구조를 생각하게 된다. 유니티의 경우 컴포넌트 기반 (재사용성)의 아키텍처로 Mono를 상속받은 클래스를 게임오브젝트에 부착하여 유니티 라이플 사이클에 태워 게임이 동작하게 된다.
이러한 특성으로 처음 사용할 당시에 다양한 시도와 어려움이 있었다. 한 클래스안에 거대한 덩어리, 라이플사이클을 유지하기 위한 생각없이 Start, Awake 구조-> 후반에 가서 결국 엉킴, 관리자를 두기 위한 복잡한 게임 매니저 설계(싱글톤)
오브젝트마다 독립적인 라이프사이클을 가지다 보니 객체지향적인 구조를 가져가기 힘듬 물론 프리팹으로 묶거나 SO로 관리할 수 있는 방법이나 DI Framework(젝젝트)로 가능하지만 분명한 한계가 있음.. 따라서 게임의 성격에 맞게 구조를 설계하는 능력이 중요함
인디게임 개발자가 현 시점 가장 많이 상주하고 정보도 가장 많기 때문에 처음 게임개발을 시작한다면 유니티가 좋긴 함 -> but 현재 취업시장은 언리얼 부터 시작하는게 좋을 듯
언리얼은 약 6개월 정도 사용해봄 유니티와 다르게 학습곡선이 좀 쎔 이유는 C++을 기본 언어로 가져가기에 메모리 관리와 방대한 언리얼 구조를 익혀야 함
언리얼은 이러한 어려운 단점을 상쇄하고자 블루프린트라는 시각적 노드 기반 프로그래밍 툴을 두었으나 실상 AAA급을 제작하는 게임에선 최적화를 위해 C++로 하는 경우가 많음, 또한 유니티에 비해 강의나 정보가 한정적임
Unity에선 인터페이스를 통한 합성 구조가 많았지만 언리얼 툴 자체가 상속구조를 강하게 만들어 놔서 상속 관계를 놓치 못함
고도의 경우엔 두 엔진과 다르게 매우 특이한 구조를 가지고 있음, 트리 형태의 엔진으로 언어 자체도 파이썬과 비슷한 GDScript라는 동적 언어를 지원함, 대부분의 엔진에서 C계열을 사용하는 반면 고도 엔진의 경우 파이썬 문법을 그대로 사용함 물론 C#도 사용가능하지만 개발사에선 GDScript를 사용할 것을 권고
노드 기반이라는 것은 유니티 컴포넌트와 비슷할 수 있지만, 게임오브젝트라는 껍데기 없이 한 컴포넌트 당 노드 한개를 가지고 이를 트리로 구성하여 씬이라는 독립적인 객체로 묶어서 사용함 이러한 구조 특성 때문에 코드를 작성하다 보면 자연스럽게 모듈형태로 프로그램이 만들어짐
결국 모듈(씬) 하나마다 독립적으로 동작할 수 있어야 한다는 특징이 생기고 씬과 씬을 연결하는 시그널(델리게이트 비슷함)로 디커플링을 유지하게 됨
The text was updated successfully, but these errors were encountered:
Task: 게임 엔진 3종 비교
3가지에 대한 장단점, 경험적인 내용을 정리
item 정리
Godot은 오픈소스라는 특징, 가볍다. 2D게임에 특화된 것 같음, 사용성 좋음
Unity는 2D/3D다 좋음, 학습 곡선 중급 정도, 에셋 스토어 존재
unreal 고성능 3D에 매우 좋음, 대규모 프로젝트에 적합..?
본문
글은 여타 인터넷에 있는 글보다는 실제로 3개의 엔진을 사용해본 이정안의 입장에서 작성해본다. 개인적인 경험 위주로 작성할 예정이라 틀린 점이 있을 수 있다는 점 (발표용)
유니티는 처음 게임개발을 시작한 엔진으로 대부분의 게임 구조를 만들거나 떠올릴 때 유니티에 맞는 구조를 생각하게 된다. 유니티의 경우 컴포넌트 기반 (재사용성)의 아키텍처로 Mono를 상속받은 클래스를 게임오브젝트에 부착하여 유니티 라이플 사이클에 태워 게임이 동작하게 된다.
이러한 특성으로 처음 사용할 당시에 다양한 시도와 어려움이 있었다. 한 클래스안에 거대한 덩어리, 라이플사이클을 유지하기 위한 생각없이 Start, Awake 구조-> 후반에 가서 결국 엉킴, 관리자를 두기 위한 복잡한 게임 매니저 설계(싱글톤)
오브젝트마다 독립적인 라이프사이클을 가지다 보니 객체지향적인 구조를 가져가기 힘듬 물론 프리팹으로 묶거나 SO로 관리할 수 있는 방법이나 DI Framework(젝젝트)로 가능하지만 분명한 한계가 있음.. 따라서 게임의 성격에 맞게 구조를 설계하는 능력이 중요함
인디게임 개발자가 현 시점 가장 많이 상주하고 정보도 가장 많기 때문에 처음 게임개발을 시작한다면 유니티가 좋긴 함 -> but 현재 취업시장은 언리얼 부터 시작하는게 좋을 듯
언리얼은 약 6개월 정도 사용해봄 유니티와 다르게 학습곡선이 좀 쎔 이유는 C++을 기본 언어로 가져가기에 메모리 관리와 방대한 언리얼 구조를 익혀야 함
언리얼은 이러한 어려운 단점을 상쇄하고자 블루프린트라는 시각적 노드 기반 프로그래밍 툴을 두었으나 실상 AAA급을 제작하는 게임에선 최적화를 위해 C++로 하는 경우가 많음, 또한 유니티에 비해 강의나 정보가 한정적임
Unity에선 인터페이스를 통한 합성 구조가 많았지만 언리얼 툴 자체가 상속구조를 강하게 만들어 놔서 상속 관계를 놓치 못함
고도의 경우엔 두 엔진과 다르게 매우 특이한 구조를 가지고 있음, 트리 형태의 엔진으로 언어 자체도 파이썬과 비슷한 GDScript라는 동적 언어를 지원함, 대부분의 엔진에서 C계열을 사용하는 반면 고도 엔진의 경우 파이썬 문법을 그대로 사용함 물론 C#도 사용가능하지만 개발사에선 GDScript를 사용할 것을 권고
노드 기반이라는 것은 유니티 컴포넌트와 비슷할 수 있지만, 게임오브젝트라는 껍데기 없이 한 컴포넌트 당 노드 한개를 가지고 이를 트리로 구성하여 씬이라는 독립적인 객체로 묶어서 사용함 이러한 구조 특성 때문에 코드를 작성하다 보면 자연스럽게 모듈형태로 프로그램이 만들어짐
결국 모듈(씬) 하나마다 독립적으로 동작할 수 있어야 한다는 특징이 생기고 씬과 씬을 연결하는 시그널(델리게이트 비슷함)로 디커플링을 유지하게 됨
The text was updated successfully, but these errors were encountered: