[💬] 언리얼은 어려운게 아니라 학습자료가 적은거임

[익명(222.109)]

막상 하는법 배워보면 오히려 유니티보다 생산성 더 좋음

블루프린트가 복잡해지면 더럽다고 하는데 복잡한부분은 코드로 하고 간단한부분만 블프로 하면 더러워질일이 전혀 없다

그리고 객체형식으로 나눠서 연결하면 더 그렇고

여기 애들 보니까 언리얼 제대로 해본적도 없는데 다른사람이 하는말만 듣고 그럼 그렇지 언리얼은 어려워

언리얼은 유니티보다 생산성이 떨어져서 인디는 유니티가 답이야

이런 유언비어 퍼트리는거 같은데 잘 모르면 그냥 아무말도 하지마라

유니티는 학습자료가 많고 그걸로 신규유입이 생기고 이런 사이클이 돌다 보니까 유니티가 만만해 보이고 쉬워보이는 거지

언리얼이 유니티보다 특별히 어렵거나 그런거 1도 없다

오히려 블루프린트의 엄청난 생산성으로 c# c++ 1도 모른 상태에서도 고퀄 게임 뽑아낼 수 있다

물론 복잡해지면 c++ 써야 되는데 안쓰고 싶으면 안쓰고도 가능하고

특히 인디 수준의 간단한 겜들은 c++ 전혀 안쓰고도 블루프린트만으로도 쌉가능하다

예전에는 언리얼 라이센스비용이 비싸고 블루프린트도 없고 그랬지만 한 5년 전부터 그런 장벽이 다 사라졌고

지금은 오히려 돈적으로나 생산성적으로나 언리얼이 유니티보다 위임

유니티를 써야하는 이유라면 3d 카툰그래픽형 캐주얼 게임 ( 원신 같은 ) 이거 하나는 유니티가 언리얼보다 뛰어나다

그거 아니고서는 인디레벨에서도 언리얼 안쓰고 유니티 써야할 이유 하나도 없음

아 언리얼 하려면 자료가 대부분 영어라서 영어가 좀 되야함 최소 4등급 이상

그게 아니면 동영상강의보단 한글로 된 책 사서 그 버전에 맞춰 기초 닦으면 된다

책은 처음부터 끝까지 체계적으로 알려줘서 그게 나음

나도 코딩 1도 모르고 한글로 된 책 사서 블루프린트랑 에셋으로 만들다가 c++도 배워보고 영어검색도 하면서 늘린거임
그전까지는 그냥 블루프린트로만으로 만들었었고
나중에는 유니티도 써봤는데 블루프린트가 훨씬 쉽다. ㄹㅇ 코딩 몰라도 조립하듯이 만들면 만들어짐

그리고 언리얼 질문은 여기해봤자 여기는 유니티가 대부분이라 의미없고 네이버에 언리얼 공식카페 있다
거기에 현직 전문가들 깔려있고 거기다 질문하면 시간은 걸리지만 하루정도 기다리면 엥간하면 답해줌

[익명(125.140)]

ㅇㅈ 난 컴공이 전공 아니라서 머리속 로직 c++로 바로 구현하라하면 한나절인데 BP는 그냥 짜여진 구조에서 노드만 가져다 쓰면되서 빠르게 프로토타이핑 가능함 글고 공대 수업과정에 c++은 있지만 c#은 없음 새로 또배우는거 귀찮 차피 로직 구현하려고 프로그래밍 하는데 굳이 언어를 잘할필욘 없잖아? 글고 영어말인데 논문급도 아니고 문제 없다고 생각함 요즘세대는 그정도 영어 충분히 된다고 생각하고 그래도 안됀다면 요즘 개발자들이 번역기 잘해놨으니 그거쓰면됨 쨋던 언리얼 엔진은 장점뿐이니 모두 언리얼 하도록

[익명(125.140)]

글고 사실 학습자료 적다는 말도 체감이 안돼는게 나는 어떤 분야던 공부할때 영어로된게 더 양질의 자료가 많다고 생각해서 영어로 보는데 언리얼 자료 차고 넘침 유니티는 한글로된 강좌가 많은가벼?

[익명(222.109)]

유니티는 대부분 한국인이 설명해주는 영상강의나 책이나 자료가 많아서 접근이 쉬운건 맞음 나때보단 지금 언리얼 한국자료도 늘긴했는데 유니티에 비하면 한국자료가 적은건 맞고 언리얼의 장벽이 사라진지 5년정도 됐는데 이게 긴것같아도 이미 인디사이클이 유니티쪽으로 넘어간 후라서 진입장벽이 안낮춰지는거 같음 그리고 네이버 카페같이 좀 찾아서 공부하는 노력도 필요하고 근데 어찌됐든 막상 배워보면 유니티보다 훨씬 쉬움

[익명(125.140)]

나는 시작을 언리얼 유니티 고민하다 그나마 아는 언어가 c++밖에 없어서 언리얼 입문했는데 똥컴 아니면 언리얼 안쓸이유가 없음 크래스플랫폼 패키징도 되니까 타겟시장 PC,모바일 구분안해도되고 없는거 있으면 엔진소스코드 공개되있으니까 좆고수들은 알아서 고쳐쓰겠지 똑똑한 사람들이 만들어 놨다는게 느껴짐 걍 요번 5.2 업뎃되면서 절차적 생성 나오는데 부랄을 탁쳤음 걍 언리얼 주식 풀매수 못하는게 아쉬울따름 요즘은 유치원생들도 번역기로 영어글 읽을수 있으니 걍 다 입문도 언리얼 했으면 좋겠음

[익명(121.159)]

오토데스크(캐드/마야), 유튭프리미엄, 챗지피티 어도비 등 (최대 80% 할인)
https://www.gamsgo.com/details/auto_desk/partner/DrKPG

[익명(222.109)]

혹시라도 언리얼 배워보고 싶은 사람들은 내말대로 하면 된다 1. 한글로된 언리얼 책 사서 그 버전에 맞춰 한권 뗀다 -> 기초 완성 ( 버전 바뀌어도 큰차이 없어서 금방적응 된다 ) 2. 만약에 아무리 생각해도 이해안가는게 있으면 네이버 언리얼 공식카페가서 질문하고 하루정도 기다린다 3. 기다리는거 싫고 구글링처럼 빨리 답얻고 싶으면 영어로 검색하면 된다

[익명(125.140)]

글내용 마지막을 이제봤네 질문계속 여따 올렸는데 네이버로 가볼게

[익명(125.140)]

근데 카툰그래픽에선 왜 유니티가 더 뛰어난거임 쉐이딩 방식같은게 다른가? 언리얼에서도 TA들이 구현할 수 있는거 아님? 인디레벨에서 힘들다는거지? 좆밥이라 잘몰라서그럼

[익명(222.109)]

구현하려면 당연히 가능하지 근데 유니티에서는 그 구현이 기본장착되어 있는거임 애초에 엔진 구조도 그런 카툰 쉐이딩에 적합한 구조로 발전해왔고 최적화 되어있고 언리얼로도 할려면 불가능한건 없음. 단지 3d 카툰이면 굳이 언리얼보단 유니티가 더 이득이라고 생각함

[익명(125.140)]

나중에 3d 카툰그래픽풍도 함 도전해볼건데 아마 언리얼은 신이니까 다될거임

[익명(121.169)]

이미 알고 잇을지 모르지만 한국겜중에서 제2의 나라가 언리얼 카툰그래픽임 카툰은 주어듣기론 언리얼도 가능한데 구지 언리얼로? 라는 느낌이라던데 같은 결과물도 유니티쪽이 좀더 이쁘게 나온다나 뭐라나

[익명(106.101)]

위 리플들 개소리고 카툰렌더링처럼 파이프라인 이리저리 뜯어고치는건 유니티가 언리얼 압살함. 언리얼은 파이프라인이 엔진에 너무 built-in 되어있어서 커스텀하려면 좆빠짐

[익명(125.140)]

오 궁금한데 파이프라인이 Work Flow 말하는거 맞으면 카툰렌더링은 어떤식으로 진행되는지 간단하게 알려주라 쥰네게 궁금함 유니티는 언리얼이랑 어캐다른지

[익명(125.185)]

이득우 그책 말하는건가 함 해봐야것다

[익명(125.140)]

나는 책으로 시작하는거 비추 영어 유튜브가 더 양질의 정보가 많음 번역서들은 유튭 찾아보면 나오는 내용이 대부분임

[익명(125.185)]

튜토리얼 추천좀 해줄수있나 영상도 여러개고 코딩은 처음이라 뭘 봐야할지 감이 안잡힘

[익명(125.140)]

음 아예 코딩 첨이면 양질의 정보 찾기보다 니가 만들 게임 장르정하고 그 장르이름뒤에 Unreal engine 붙여서 유튜브 검색해서 나오는거 보샘 처음하는 사람이면 오히려 양질의 정보 찾는다고 공식문서 보고 하다가 나가떨어질듯 그렇게 만들기 시작해도 충분히 늦지않다고 생각함 개인개발은 기술력 외적의 요소가 더 중요하다고 생각해서

[해당 댓글은 삭제되었습니다.]

해당 댓글은 삭제되었습니다.

[익명(125.140)]

유니티 안써봐서 모르겠는데 언리얼 커뮤니티 외쿡성님들도 그얘기 하긴함 Paper2d는 죽은프로젝트라고,,,

[익명(211.224)]

개인적으로 언리얼이 어렵다라고 생각하는 부분은, 만들어진것들이 되게 많아서 이 기능들 자체에 대해서 익혀야하는 부분이 많기때문이라고 생각함.

[익명(211.224)]

정확히는 다른놈이 만든 기능이니 이 기능을 어떻게 사용할지, 변경할지에 대한 부분은 사실상 소스코드보고, 도큐먼트보고 분석을 해야하는데 이게 정말로 쉽지않음.

[익명(211.224)]

이 언리얼 엔진에서 어디까지 얘들이 제공하는지에 대한 정보와 어떤 컴포넌트나 어떤 액터, 어떤 애셋이 어디까지 영향을 미쳐버리는지에 대한 정보가 없으면 정말 엄청나게 헤맬거임

[익명(211.224)]

애초에 상속기반 구조다보니 엄청나게 딱딱하긴해서..

[익명(119.194)]

둘다 찍먹해본 초보 입장에서 이 댓글에 100따봉드림.

[익명(125.140)]

나도 처음배울때 이거 느꼈는데 Learning Curve가 굉장히 가파른 편이라 생각함 근데 이걸 오히려 장점이라고 생각하는게, 비전공자 입장에서 에픽게임즈 측이 구현해준 안전한 시스템적 구조라고 해야하나 스키마? 그런 거대한 프로그램 돌아가는 부분을 하나하나 생각하고 많이 배울 수 있게 해줌 C++에 동적 배열도 모르던 상태로 시작했는데 지금은 디자인 패턴까지 공부하고 있으니 오히려 순기능을 한다고 생각함. 만들어진게 많아서 불편하다고 하려면 Unity도 똑같지 그렇게 치면 c++에 그래픽만 API 써서 하는게 가장 익혀야 되는게 적은건가? 그건 아닌거같음

[익명(211.224)]

유니티는 확실하게 언리얼보다는 미리 알아야할건 적지. 언리얼에선 완전하게 어떤 방법을 제공을 하고 그 방법대로 안쓰면 굉장히 손해보는 구조임. 유니티는 적어도 그런 강제적인 구조는 제약하진 않거든. 비록 제공된게 별로없어서 손수 만들긴해야하지만

[익명(125.140)]

그리고 액터나 컴포넌트 에셋이 영향미치는걸 모른다는게 무슨말인지는 모르겠는데 도큐먼트를 보고 하는게 짜증날거같다 싶으면 그냥 만들어서 써도됨 언리얼 엔진에서 Actor ,ActorComponent를 만들어 준게 오히려 장점이라고 생각하는데 비전공자라 잘 모르긴하는데 컴포넌트 구조라서 오히려 디커플링 용이성이랑 재사용성 면에서 좋아진거 아닌감?

[익명(125.140)]

근데 만들어진 대로 안쓰면 손해본다고 했는데 그건 당연한거 아님? 똑똑한사람들이 만들어 준거니까 구조랑 최적화면에서 신경써서 만들어준걸꺼고 , 유니티는 내가 직접 만든거니까 (언리얼에서도 만들어쓰면 됨) 이게 구조가 좋은건지 나쁜건지 손해를 보는건지 안보는건지 모르는 것 뿐 아님? 애초에 프로그래밍을 좋은 패턴으로 자기가 짜야하니까 퍼포먼스가 필요한 게임으로 갈수록 오히려 단점같은데 물론 2d는 사양 필요없으니 유니티가 빨리 구현하기 좋을것 같기는함

[익명(211.224)]

당연한거 맞지. 근데 완벽한 프로그램 만드는게 게임 개발자체 목적은 아니긴 하니까. 그래서 초보자 진입장벽에서 보았을때 언리얼이 진입장벽이 있다는말 하는거임. 이 진입장벽때문에 어렵다고 얘기하는거고

[익명(211.224)]

게임 스테이트랑 게임 모드 플레이어 컨트롤러 플레이어 스테이트 폰간 영향 미치는 관계나 캐릭터무브먼트 컴포넌트와 스켈레탈 메시간 관계나 이런게 미리 정의 되어져있다는 거지. 알고있으면 빠르게 문제 파악하기 쉽지만, 모르면 어디서 문제 생긴건지 파악하기도 어렵고. 게임프레임워크의 기본생성 액터의 경우는 일반적인 경우에선 대다수 논리적으로 맞아 떨어지지만, RTS의 경우에 왜 논리적으로 플레이어 컨트롤러가 단 하나의 pawn만 갖고있어야되는지에 대한 구조적 의문도 들고

[익명(211.224)]

언리얼로 정말 편하게 개발할수있는게 세션형 fps임. 이것만큼은 언리얼에서 사실상 다 제공해주는거나 마찬가지니

[익명(125.140)]

게임 스테이트랑 게임 모드,플레이어 컨트롤러 플레이어 스테이트 폰간 영향 미치는 관계나 캐릭터무브먼트 컴포넌트와 스켈레탈 메시간 관계나 이런게 미리 정의 되어져있다는거 맞음 이런거 세세한 내용 엔진 어떻게 실행되는지 부터 설명되있는 공식문서 봐야하는것도 맞음 그런데 그냥 깡 액터랑 유니티 Start(),Update() 같은 BeginPlay랑 Tick만써도 충분히 게임 만들 수 있음 근데 2d는 확실히 언리얼로 하기엔 좀 난해한거같음 RTS같은경우는 AIController사용하기도 하고 컨트롤러 안써서 구현할수도있음

[익명(211.224)]

그런 깡 Actor사용해서 제작하면 할수는 있지만 언리얼에서 제공해주는 그 캐릭터기반의 기능들 못쓰는 상황이 꽤 생겨서 손해본다고 생각한다. 그럴거면 그냥 유니티쓰는게 낫지 그래픽퀄리티 제외하고 생산성 따졌을때.

[익명(211.224)]

그냥 아예 깡 Actor사용해서 제작하고 게임스테이트 게임모드 이런 기본 프레임워크 싹다 비워있다고 생각하고 겜 제작한다면 니말대로 진입장벽이 낮다고 생각할수있지

[익명(211.224)]

천성이 프로그래머인 놈들한테 그런 쓸모없는 액터들이 왜 강제로 생성되어져있느냐에 대한 가려움은 존재하겠지만

[익명(125.140)]

내말은 그게 좋다는게 아님 언리얼은 그렇게도 할 수 있다는거지 유니티로 그렇게 깡통부터 제작해서 접근성이 쉽다고 하니깐, 언리얼도 깡통처럼 쓸라면 쓸 수 있다는거임 그래서 선택지의 폭이 넓어진다는거지 기능을 안쓰면 자기가 구현해야 하니까 손해가 될수도 있는거고. 유니티에서는 자기가 구현하는게 디폴트니깐 애초에 선택지가 더 적은거아니냐는거임 그렇다고 하면 언리얼 안쓸 이유가 없지않냐는 말이지 천성이 프로그래머라면 애초부터 C++달린 언리얼을 더 좋아하지 않을까? 좆고수들은 로우레벨 언어로 갈수록 좋아하는거 아니었냐구

[익명(125.140)]

그렇게 깡통처럼 쓰다가 나중에 성능이 아쉬울때가 오면 그때 공부시작해도 된다고생각함, UE5넘어오면서 루멘하고 나나이트 보면 진짜 이런 엔진을 무료로 풀어주는게 감사할정도

[익명(125.140)]

그리고 그래픽 제외하고 생산성이 좋다고했는데 언리얼엔진은 루멘이나 나나이트 또 5.2들오여먼서 절차적 생성도 생기고 아트적 생산성까지도 +로 늘려주는거임, 왜 게임개발에서 그래픽을 제외하는지를 모르겠음 로직구현은 BP로 접근쉽고, 퍼포먼스도 좋고, 그래픽적으로도 괜찮은데 왜 굳이 그 장점을 제외하고 봐야하는지를 모르것네

[익명(211.224)]

강제적 구조를 띄는점에서 프로그래머가 아키텍트 관점에서 싫을수 있는다는 점이라는 이야기지. 그게 C++이냐 C#이냐는 다른 문제긴한데.

[익명(211.224)]

니 말대로 절차적 생성이랑 뭐 기타 다른 대규모 워크플로우를 구축해야하는 게임 제작관점에선 언리얼이 생산성이 좋긴하지. 소규모 관점에선 유니티가 생산성이 더좋고. 내 관점에선 언리얼이 인디 게임 제작관점에선 진입장벽이 높은편이다라고 이야기하는 거임.

[익명(211.224)]

애초에 만들고자 하는 게임 목표가 대규모 3d 게임 제작이라는 목적이라면 언리얼이 그러한 게임을 만들기위해 들이는 노력은 적을거고.

[익명(211.224)]

원하는 최종결과물을 뽑는데는 언리얼이 쉬울순 있어도, 진입장벽관점에선 언리얼이 유니티보다 어렵다는 이야기라는게 내 입장이다.

[익명(125.140)]

궁금한게 아키텍트 관점까지 생각하는 프로그래머면 애초에 언리얼 구조에 진입장벽을 느낄 이유가 없는거아님?뭐 그렇다 치고 애초에 Unity,Unreal Engine,Godot 다 OOP기본이니까 상속구조 당연한거고 유니티는 게임오브젝트에 언리얼은 Actor에 컴포넌트 붙여서 만드는건데 둘다 콜리젼(콜라이더) 컴포 붙이고, 메쉬 컴포붙이고 하는 식으로 유니티는 게임 오브젝트를 프리팹 만들어서 쓰고 언리얼은 Blueprint나 Cpp Class로 만들어 쓰는거, 유니티에서 콜라이더 컴포넌트에서 상속받아서 만든 박스콜라이더 컴포넌트를 붙여쓰면서 상속 구조라서 딱딱하고 강제적이다 안하잖아.그냥 언리얼이 세세하게 기능많아서 그렇지 안쓰면 똑같은거다 같은 조건이면 기능이 많은걸 선택하는게 맞다고 생각함

[익명(211.224)]

1. 방금 얘기한 아키텍트 관점 이야기가 그런류 프로그래머에게 진입장벽이 된다는 이야기라는게 아님. 이거 내용이 굉장히 혼재되어져있는데, 강제적 구조를 띄기 때문에 그러한 구조를 갖추고 싶지않은 프로그래머에게 짜증난다는 이야기임. 2. 강제적 구조를 띄기 때문에 딱딱하다라는 이야기임. 단순히 액터나 액터컴포넌트 상속자체가 문제가 아니라 이미 만들어져있는 구조에 내가 덧붙인다는 개념이기 때문이라는 말임.

[익명(211.224)]

3. 완전 처음 진입하는 프로그래머에게 이러한 기본적으로 고정되어있는 구조를 배우는 게 힘들다라는 이야기임. 이때문에 난이도가 있다는 이야기고

[익명(125.140)]

게임엔진은 구조 당연히 다 있는거아니노... 그렇게 치면 유니티도 강제적 구조잖어 만들어있는 구조지 이벤트함수 실행순서 다 이미 짜져있고 씬(레벨) 로드 하고 첫프레임 전에Start하고 업데이트 순서도 정해져있는데 언리얼도 마찬가지고 컴포넌트도 상속구조 말하는것도 아니라고 하고 이벤트 함수실행순서는 엔진별로 유니티 언리얼 둘다 이미 정해져 있는 구조대로 가는거고 당연히 게임엔진을 사용한다는것 자체가 이미 만들어져 있는상태에서 덧붙인다는 건데 C++에 SDL2써서 개발하는것도 아니고 그런 구조가 강요되는건 당연한거잖아 근데 왜 언리얼은 강제성 구조이고 유니티는 더 자유롭다는 결론이 나오는지 이해가 안됌 아니면 니가 말하는 강제적 구조가 내가 말한게 아니면 뭘 말하는건지 알려주샘 이젠 궁금해졌어

[익명(211.224)]

기본 게임 프레임워크에서부터 시작해서 기본적으로 제공하는 기능들에 대해서 추상화가 굉장히 되어져있는편임. 당장 ui만 보더라도 언리얼에선 명확하게 "Button"라는 역할이 딱 정해져있는 편인데, 유니티의 ugui에선 이미지, 버튼 이렇게 따로 붙음. 사실상 개별로 동작하는 애들을 덕지덕지붙은거랑 비슷함. 그래서 뭔가 묶어서 관리하는게 아니고 흩뿌려진 파편들을 관리하는 느낌이나고. 그렇기 때문에 구조적인 면에서 자유롭다고 여질 부분이 있는거고. 이건 그냥 단적인 예이고, 애초에 유니티에선 추상화되어서 게임특화된 기능 그자체로서 제공하는게 별로없음

[익명(125.140)]

예시들은게 오류가 있어서 수정하자면 언리얼도 Button에 Image와 Text를 붙여서 UI를 만듬, 즉 세부단계로 분리되어있음 언리얼도 파편이라는거임 언리얼의 UMG시스템은 웹개발자라면 이해하기 쉬울텐데 html태그 구조와 굉장히 유사한 구조로 되어있음, css의 diplay flex같은 기능도 있고 align할때랑 비슷하게 Anchor라는 개념도있음,그러한 유사성을 바탕으로 JavaScript로 UI를 스크립팅 할 수 있는 플러그인까지 나와있을정도(NC에서 만듬)아마 근데 이건 유니티도 비슷했던걸로 기억함 애초에 언리얼 엔진의 액터를 베이스로한 폰,캐릭터 등등의 액터들은 전부 컴포넌트 파편을 붙여 만든거임

[익명(125.140)]

추상적인 표현을 자꾸 써서 나도 추상적으로 말하게 되는데 여태 말한내용으로만 보면 언리얼도 유니티처럼 "흩뿌려진 파편을 관리하는" 구조라는 거임 아까 말한 폰이나 캐릭터 같은 액터는 기본 액터에 여러가지 컴포넌트와 추가 기능 메소드를 붙여놨을뿐임, 싫으면 안쓰면 된다는거 실제로 캐릭터 액터 같은경우는 안쓰기도 하더라 LyraStarterGame이라고 EpicGames에서 낸 새로운 프레임워크 같은게 있는데 이 예제에서 원래 구조를 안쓰고 새로 만들어쓴다의 예시를 본인들이 증명해줌. 이처럼 걍 프로그래밍 자신 있으면 만들어 쓰면 되는거 그리고 동일실력기준 유니티나 언리얼이나 구현하는 수준은 같을거임. 언리얼에서 버벅거릴 실력이라면 유니티에서도 스파게티 코드가 될 가능성이 농후하다는거

[익명(125.140)]

그럴바엔 접근성 좋은 언리얼엔진 블루프린트로 입문하는게 제일 좋지 진입장벽도 낮고 유니티에서도 언리얼 엔진 블루프린트 보고 부랴부랴 볼트 만들었을 정도니깐

[익명(211.224)]

언리얼은 그 파편들을 "Button"이라는 하나의 클래스로 묶어서 관리한다는 이야기임. 하나의 클래스로 관리를 한다고 하면 유니티는 그렇지않다는 얘기고. 니말대로 안쓰고 개발하면 난이도 비슷한건 맞음. 근데 쓰고 기능 익히는데 들이는 학습량이 유니티보다 크다는거임. 알고리즘적 내용이 유니티가 더 필요할지언정 어떠한 구조로 묶여있는지 기능은 어떤게 있는지 파악하는건 언리얼이 더 노력 많이 들어간다는 이야기임. 그래서 초보자가 유니티쓰는게 편한건 그런부분에 있어서 기능파악을 덜할수있기때문에 그런거고, 알고리즘 개판으로 코딩해서 그 기능을 개발하는건 둘째치더라도말이야. 그리고 그러한 기능들을 안쓰고 개발하는게 언리얼에선 상당히 어렵다는 얘기임

[익명(211.224)]

방금말한 내용에 "안쓰고 개발하면 난이도 비슷한거 맞다"라는 문장은 기능 익히는데 들이는 노력과 시간이 비슷하다 라는 뜻임

[익명(125.140)]

알고리즘적 내용이 더필요하다는게 말이 안됀다는거, 유니티에서 개발하는 사람들이 머신러닝 연구자나 트리플A겜에 들어가는 특별한 Magic을 만드는게 아니고 어차피 게임에서 쓰는 알고리즘은 정해져있음 거기서 더 가는건 유니티고 언리얼이고 개발자가 직접 짜야하는걸로 동일함 언리얼에서 제공하는건 개발자가 하기싫은 어렵지 않지만 귀찮은 부분들을 대신 구현해준거임 거기서 그 일상적인 구현을 바꾸고 싶다 하면 유니티고 언리얼이고 새로 작성하면 되는것 뿐이고

[익명(211.224)]

유니티 개발자가 알고리즘적 내용이 더 특별한걸 쓴다는 이야기가 아니라, 직접구현하기때문에 구현하는데에 알고리즘이 필요하다는 이야기지. 별볼일 없는 내용이라할지라도말이야. 그리고 언리얼에서 그렇게 아예 새로 만드는것 자체가 엔진 자체에 대한 지식이 없으면 특히 어려운편임. 난 계속 입문자가 언리얼에 대해 입문하기 어렵다는 이야기를 하는거임. 언리얼에서 제공해주는 기능이 방대한건 맞지만 이러한 기능들을 학습해야하고 이렇게 쓰게 강제화시킨다는 점에서 학습난이도가 높다고 하는건데

[익명(125.140)]

그니깐 그부분이 보는 관점이 다른거같음 기본적으로 필요한 간단한 알고리즘도 초보자 입장에선 C#스크립트로 작성하기엔 두려울것같다는 거임 만약 프로그래밍에 전혀 관계없는 아트 직업군이 시작한다하면 C#과 블루프린트라면 기능을 조금이라도 공부해서라도 블루프린트가 더 편할듯 비주얼 스크립팅이니 가시성도 좋고 연결 연결 하면 되고 무엇보다 블루프린트는 예제도 많음 영어로 된 유튜브 강의도 쏟아짐 ㄹㅇ 어느정도 프로그래밍 언어에대한 지식이 있는 상태로 시작해야 한다하면 그것 자채로 진입장벽이 된다고 생각해

[익명(211.224)]

아. 아트나 다른직업군 관점이면 그럴수있을거같네. 플머베이스로 생각하다보니 내가 그렇게 말한듯.. ㅋㅋ

[익명(125.140)]

어느정도 실력있는 플머라는 전재하에도 언리얼 엔진이 좋다고 생각하긴함

[익명(211.224)]

가불기쓰네... ㅋㅋㅋ 실력없어서 입문하기 힘든거다 이런거냐? 애초에 유니티가 제공하는 기능이 적어서 알아야할 학습량이 적다라는 이야기인데 그래서 난이도가 낮다는 얘기고.

[익명(211.224)]

명확하게 엔진 그자체에 대해서 학습량이 적다는 이야기임. 엔진 자체에 대해서 공부할량이 적다는거야. 그래서 입문난이도 낮다는거고

[익명(211.224)]

엔진에 대한 학습량 자체가 적어서 내가 알고리즘만 알면 바로 개발에 뛰어들수있으니까 진입장벽이 낮다는 이야기고

[익명(125.140)]

애초에 그런식으로 보면 엔진 공부량 = 진입 장벽으로 보는갑네 그건 진짜 프로그래밍 공부하는 사람 입장인거같음 노베이스 시각으로 보면 유니티는 C#+엔진 으로 말그대로 컴퓨터랑 대화하는 법을 배워야하고, 언리얼은 블루프린트로 그래도 좀 순한맛으로 할 수 있는건데 나는 노베이스 관점에서 말한 진입장벽이었음

[익명(125.140)]

프로그래밍 언어에 대한 지식이 전무한 사람이라면 블루프린트 기능을 익히는 편이 더 쉬울거니깐

[익명(211.224)]

어느정도 실력있는 플머라는 전재하에도 언리얼 엔진이 입문하기 좋다고 생각한다<<< 라는 건 난 아니라고 본다. 유니티가 훨 쉽지

[익명(125.140)]

ㅇㅋ 나는 C++로 실력없는 상태로 입문해서 배우면서 비볐는데 비벼지더라고 실력있으면 더 쉽게 하지 않을까 해서 한말임 공대생인데 솔찌 전공보다 재밌었음 걍 의지 있으면 배우면서 해나가면 되긴해 뭐 유니티건 언리얼이건 잘나가는 사람이 정답이니깐 그정도로 강하게 꼴린다면 유니티 가는게 맞지 근데 여기 갤에서 시작하는 뉴비들은 다 언리얼로 시작해라

[익명(211.224)]

난 플머베이스에 언리얼 2년동안 붙잡았는데도 아직 언리얼 기능 모르는거 존나많아.. 처음 배울때도 알아야할것도 존나많았고

[익명(125.140)]

기능 뭐 굳이 처음부터 다알아야 하나 싶긴한데 필요할때 검색해서 찾으면 되지 않음? 깃헙도있고 스택오버플로도 있고 요즘은 GPT도 있는디

[익명(211.224)]

기능<<이거 아는건 그냥 검색해서 알면되고, 구조자체나 플러그인 형태로 제공하는 프레임워크 구조가 분석하기 개빡셋지. 이런건 검색해도 잘 안나옴..

[익명(125.140)]

플러그인 형태로 제공하는 프레임워크 이거완전 Lyra말하는거 아님니까

[익명(125.140)]

근데 그런거 안쓰면 됨걍 차피 그렇게 문서화 안돼있는 기능은 애초에 안써도 되는 기능들임 개인개발이잖음 뭐 엔진 뜯어서 소스코드 고치고 이럴필요까진 없지않나?

[익명(211.224)]

그런기능을 써야하니까 문제였지.. ㅋㅋ 언리얼 GAS로 네트워크 예측플레이 구조 생각하면서 소스코드 분석하면 대가리 빠개지더라.

[익명(125.140)]

GameplayAbilitySystem 문서화 되있고 강좌 널렸던데 엄청 옛날 기준인갑네

[익명(125.140)]

반대로 궁금한게 그걸 유니티에서 구현한다 생각하면 쉬움?

[익명(211.224)]

당연히 쉽지않겠지. 그래서 규모의 차이에따라 진입장벽이 있다고 얘기했고, 엔진자체 학습난이도라고 꾸준히 말했음. 특정한 게임 자체의 완성 난이도가아니라

[익명(211.224)]

그리고 GAS 강좌라 해봤자 전부 사용법 예제 정도고 네트워크상 동작과 어빌리티시스템 관련 분석은 내가 다해야하는구만..

[익명(125.140)]

플머입장에서는 어느정도 맞는 말인듯 / 노베 -> 언리얼 BP / 중수 -> 유니티 / 좆고수 -> 언리얼 로 보면 되나

[익명(211.224)]

학습난이도로 보면.. 뭐 어느정도 맞는듯. 그렇다고해서 좆고수가 언리얼입문한다고 언리얼 입문이 쉽다라는게 아니고 플머베이스면 좆고수든 허접이든 유니티가 입문난이도는 훨씬 쉬움

[설냥이(sulnyang712)]

언리얼 요즘 안무거움? gtx1060/i7 7700 정도 되는 게이밍노트북에선 그냥 어림도 없었는데 ue5 가면서 어떻게 바뀌었을지 잘 모르겠네 - dc App

[익명(125.140)]

나 그거보다 사양 구린거쓰는데 개잘돌아가는디 님사양이면 떡을칠듯 5가면서 약간 무거워진듯? 기능추가되서 그런감 체감상 4.27이 젤빠른느낌

[익명(121.169)]

언리얼로개발중인데 라이팅빌드하면 레벨특성상 좀 빡세서 메모리 90기가찍더라 ㅅㅂ 애매하게 64기가 썼으면 프리징 ㅈㄴ걸렸을듯

[익명(125.140)]

루멘은 신이야...

[익명(121.169)]

빌드온해도된다는게 너무 매력적인듯 뭔가 무버블과 스테틱라이트의 장점만 가져온느낌

[익명(121.169)]

안해도

[익명(7hvc5bphs4sv)]

3d한정임 도트겜은 언리얼지원이 너무없다 - dc App

[익명(211.168)]

3D한정 다 맞말ㅇㅇ