Swift 개발자가 Unity 볼륨 학습 시작

왜 일이 지금까지도 유니티가 됩니까?
음, 솔직히 주관적인 감정론으로 말하자면 필자는 유닛을 특별히 좋아하거나 엔진에서 유닛을 좋아하지 않는다.이유가 많은데 그중 가장 큰 것은'효율이 높지 않다'는 거죠.특히X계까지(5. X계가 좋아졌다고 믿는다).그리고 제가 알고 있는 기존의 Unity로 제작된 게임에서 여러분의 장면 전환(예를 들어 게임 화면에서 메뉴 화면 등)이 매우 느리다는 특징이 있습니다.나는 이것이 유닛이 나쁜지 프로그래머가 나쁜지 모르겠지만, 적어도 나는 유닛에 대한 나의 인상이 그다지 좋지 않다는 것을 부인할 수 없다.
하지만 마이크로소프트는 지난해 홀로렌즈를 발표했다.대박이다.요즘 마이크로소프트 완전 멋있어.나는 좀 일찍 해 보고 뭘 좀 해 보고 싶다.하지만 SDK는 아직 공개되지 않았다.그리고 공개돼도 마이크로소프트 씨의 틀이니까요.NET죠. 언어를 개발하는 것도 C#이죠.하지만 C#를 전혀 접해본 적이 없어 문법도 모르고 SDK를 갑자기 공개해도 아무것도 할 수 없어.
여기서는 유닛이 나갈 차례다.3D 개발도 배우고 C#도 어느 정도 배울 수 있으니 일거양득이다.그래서 나는 바로 교재를 샀다.

그렇다면 이 기사의 목적은 유니티를 시도하고 싶지만 전혀 유니티 경험이 없는 스위프트 개발자(세상에 도대체 몇 명일까...)를 위해 곤경에 빠지기 쉬운 요점을 골라 대책을 전달하거나 의견을 묻는 것이다.

명명 규칙은 아직 익숙하지 않다

응, 이것도 참을 수밖에 없지.C#과 Unity는 모두 초보자가 아니어서 지금까지 만져본 적이 없어 어떤 이유인지는 모르겠지만, C#의 명명 규칙 때문에 어쨌든 Unity가 C#으로 개발했을 때 방법명도 upper CamelCase(Upper CamelCase, 약칭 UCC)였다.습관적인 문제일 수도 있지만 솔직히 원본 코드를 읽고 이해하기 어려운 부분도 있는데...
예를 들어 Swift(이전의 Obj-C도 마찬가지)의 경우 UCC는 클래스 이름, 프레임 이름 등'추상적인 것의 정의'에만 사용되기 때문에 구체적인 것, 즉 클래스에서 생성된 구체적인 실례명,인스턴스에 자연스럽게 들어가는 속성과 방법은 모두 LCC(lowerCamelCase, UCC와 구별되는 첫 번째 문자가 대문자인지 소문자인지)입니다.그런데 유니티면 방법명도 UCC인데 순간 "어? 이게 무슨 상대였지?"이런 반응.아, 그런데 C#이니까 대상을 만들 때new 키워드로 들어가면 되는 건가요?

아이디 스페어 너무 얄밉다.

응, 이건 아마 방법이 없을 거야.노력하는 습관만 있다.
그나저나 어디가 제일 얄밉냐면 이니셜을 넣고 보완 리스트가 나왔는데 실수로 보완 리스트를 잘못 골랐을 때다.이 경우 잘못된 보완 텍스트만 삭제해도 보완 목록이 다시 나타나지 않습니다(Visual Studio와 동일한 사양).방법이 없을까?
그리고 이것은 Unity5의 개악일 수도 있다. Swift는 2부터 전역 함수를 대폭 삭제하여protocol에 넣었고, Unity5는 오히려 실례적인 방법과 속성에 있던 것을 전역 함수로 변경했다.(예를 들어 상기 교과서의 Lesson2 샘플 코드에서 대상의 속도 벡터 코드를 얻었지만 Unity 4시rigidbody.velocity에서 Unity 5시GetComponent<Rigidbody>().velocity에서 얻은 코드를 얻었다.이 문제에 대해 말하자면 전체 함수가 많으면 바로 보충하기 어렵다.원래 보충하면 쓰레기야.

언어 규범에 명확한 지시가 없기 때문에 가끔 당황할 때가 있다

어떤 의미에서 보면 보전은 쓰레기의 연장선이다. 어쨌든 게임 대상류의 자류를 만들어야 하지 않겠는가?그래서 그 아반에서 부모님 반을 다시 쓰는 방법이 있지 않을까요?그러면 부모님 반 방법명을 입력해도 다 채워주지 않을 거예요.그래서 반드시 방법명을 모두 입력해야 하는데, 초보자이기 때문에 가끔 "그 방법명이 이래도 되나요?"라는 뜻이다.자그마한 맞춤법 오류로 이리저리 찾아다니는 경우도 있다.적어도 보완 효과가 있었으면 좋겠어요.게다가 Swift처럼 명시된 커버 문법이 가장 좋은데 몇 년 전 C#에서 최신 Swift를 요구하는 방법도 너무 심했다. 그렇게 말하면 Obj-C도 명시된 커버 문법이 아니겠지?늦을 테니 나는 침묵을 지킬 것이다.한마디로 이 방법이기 때문에 초보자에게만 각양각색의 기존 방법 명칭을 기억할 수 있다.

실행 전에 자동으로 저장되지 않음

실행하기 전에 저장하는 것을 잊지 마세요.Unity는 실행 전의 자동 저장 기능이 없기 때문에 실행하기 전에 반드시 파일을 저장해야 합니다.
그래도 방법을 생각해보길 바래요. 엑스코드 습관이 있어서 작은 소스 코드를 조금 수정해서 실행해 봤는데'어? 아까랑 똑같아?'이런 경험이 여러 번 있었다.다행히 편집에 저장되지 않은 파일에 표시를 해서 저장되지 않은 파일을 선택할 수 있었지만...
2016/02/09 추가

'추상류'가 편할 것 같아요.

이런 경우도 있죠. 자반에서는 재작업을 전제로 하는 방법이죠.Swift의 경우protocol는 확실히 아니다extension. 실체가 정의하는 방법은 모두 실장측에서 내용을 잘 정의해야 한다. 그러나 그것이 도대체 공통된 협의라든지 C#가 말한 공통된 인터페이스라든지 생각은 완전히 다른 것이다.응, 이 근처에도 코코아의 재작성이 필요해. 당분간은 어려울 것 같아..
아무튼 지금 이런 느낌이죠?뭔가 발견되면 언제든 추가할 생각이에요.
아니, 난 유니티 보러 갈 생각 없는데?많은 좌절과 익숙하지 않은 부분을 정리하는 데 목적이 있으니 유닛을 할 때 주의해야 한다.문자가 디스처럼 보이는 것은 작가의 마음이 오염되었기 때문일 것이다