소개
안녕하세요, 게임을 사랑하고 개발을 사랑하는 게임 프로그래머 Developer G입니다.
저는 어떻게하면 깔끔하고 체계적인 코드를 작성할 수 있을지 항상 고민하는데요,
제 고민의 결과물들을 여러분들에게 아낌없이 가르쳐드리겠습니다!
강의
전체2수강평
- 너무 재밌게 공부한 퀘스트 시스템입니다! 다음 강의도 준비 완료
Lim sumin
2024.03.28
0
- 유니티 클라 개발자라면 한번씩은 들어야 할듯
uty1993
2024.03.13
0
- 진짜 좋은 강의였습니다^^
김규민
2023.09.13
0
- 최고입니다.
초보자
2023.07.03
0
- 잘안쓰던 문법 자꾸 나와서 힘들지만, 유익합니다.
Nayuki
2023.05.29
0
게시글
질문&답변
2024.05.30
멀티 게임에서의 State Machine에 대해서 궁금한 점있습니다.
수강해주셔서 감사합니다. State를 어떻게 구현하냐에 따라 다를 순 있지만 보통은 현재 State만 동기화해주면 됩니다. 실제로 StateMachine을 작동할 필요는 없구요, 네트워크 객체의 StateMachine의 Update를 끄고 RPC로 현재 State가 뭔지만 기록해서 그 값으로 네트워크 객체의 상태를 확인하면 됩니다. State를 동기화해주지 않으면 P2P 환경에서 '기절 상태인 적에게 추가 데미지'와 같은 효과를 구현할 수 없습니다. 감사합니다.
- 0
- 1
- 22
질문&답변
2024.05.28
사소한 질문이 있습니다
추가적으로 더 확인을 해보니 2023.2 version에서 해당 문제가 발생되는걸 확인하였습니다. 해당 version은 bug가 유난히 많은 version인지라 문제가 발생한 것 같습니다.
- 0
- 2
- 57
질문&답변
2024.05.27
궁금한게있습니다
안녕하세요. 방식은 보통 두 가지가 있습니다. 하나는 보통 존 혹은 심리스 로딩이라고 불리는 방식으로 큰 맵을 여러 구역으로 쪼갠 뒤, 주변 맵을 캐릭터의 위치에 따라 동적으로 로딩하는 방식입니다. https://www.youtube.com/watch?v=AKfjpCspFy8 해당 영상을 보시면 이해가 빠르실겁니다. 다른 하나는 위와 비슷하게 하나의 씬을 여러 씬으로 쪼개뒤(객체 별로 비슷한 속성의 것들끼리 모아서) Additive 모드로 Loading하는 방식입니다. 플레이를 하면서 실시간으로 전체 맵을 Load해가는거죠. 옛날 3D 게임들을 보면 맵이 실시간으로 Load되는 모습을 쉽게 볼 수 있구요, Scene이 실시간으로 Load되는 모습을 유저에게 보이면 디자인적으로 좋지 않다고 여겨지기 때문에 많은 게임들이 맵 디자인과 다양한 눈속임으로 실시간으로 Load되는 모습을 감춥니다. 상대적으로 맵 규모가 작다면 이 방식이 훨씬 편합니다. 위 두 방식을 섞어 사용해서 Loading 시간을 더욱 단축시키기도 합니다. 참고로 유니티에선 위 두 방식을 직접 구현해야하지만 언리얼 엔진에서는 레벨 스트리밍이라는 이름으로 기능을 제공합니다. Loading씬으로 빠른 전환이 필요하시다면 이것 또한 속임수가 있습니다. 바로 Loading Scene 이동을 시키는 것이 아니라 Additive 모드로 Loading Scene을 불러와서 화면에 Loading Scene이 보이게 한 다음, Main Scene을 Unload하고 다음 Scene의 Loading을 진행하면 실제론 Loading Scene에서 이전 Scene의 해제와 새로운 Scene의 Load가 다 일어나지만 유저가 보기에는 바로 Loading Scene으로 넘어와서 새로운 Scene의 Load만 일어나는 것처럼 보이게 됩니다. 물론 눈속임이기 때문에 Main Scene 해제에 15초, 다음 Scene Loading에 15초가 걸렸다면 유저는 다음 Scene Loading만 30초가 걸리는 것처럼 보일겁니다. 조삼모사이긴 하지만 Main Scene의 해제가 오래걸린다면 효과적인 방법입니다. 위 두 방식에 이런 눈속임까지 섞는다면 로딩이 더욱 빨라보이겠죠. 이처럼 실제 Loading 시간과 유저가 느끼는 체감 Loading 시간을 줄이기 위해서는 다양한 기법과 속임수가 필요하며 많은 개발자들이 항상 고민하는 문제이기도하니 다각도로 접근해보시기 바랍니다. 다만 Loading 시간을 줄이기 위해서 동적 로딩 방식을 취하게되면 그에 따라서 여러 설정들도 동기화 시켜야하기 때문에 개발 난도가 올라간다는 점은 명심하셔야합니다. 감사합니다.
- 0
- 1
- 61
질문&답변
2024.05.27
사소한 질문이 있습니다
수강해주셔서 감사합니다. OnGUI에선 따로 Font 설정을 하지 않기 때문에 유니티 기본 Font를 사용하게 됩니다. 혹시나하여 프로젝트를 확인해봤으나 제작 버전과 유니티6 버전 모두 정상적으로 한글이 나오는 것을 확인하였습니다. Stat View는 그저 Stat의 간단한 Debugging용 UI로만 사용되니 다른 문제가 없으시다면 그대로 진행하셔도 무방하실 것 같습니다. 감사합니다.
- 0
- 2
- 57
질문&답변
2024.05.25
스크립터블 오브젝트 Instantiate?
수강해주셔서 감사합니다. 말씀해주신 부분은 반은 맞고 반은 틀리다고 얘기드릴 수 있을 것 같습니다. 꼭 ScriptableObject뿐만 아니라 Instantiate 함수를 쓰는 것 자체가 성능에 좋지 않습니다. 정확한 통계는 아니지만 일반 Class를 생성하는 것보다 최소 20배정도 느리다고 알려져있습니다. Serialize된 Data를 Deserialize하는 작업을 해야하기 때문입니다. 즉, ScriptableObject를 Runtime에서 복사하면 좋지 않다는 말은 GameObject도 Runtime에서 복사하면 좋지 않으니 지양하라는 말과 같습니다. 만약 극단적으로 매 Frame마다 단일 GameObject를 Instantiate 함수로 5개씩 Clone을 만든다면 성능에 문제가 생길까요? GameObject가 계속 쌓이면 언젠가는 문제가 되겠지만, 보통은 Clone을 5개씩 생성한다는 그 자체로는 성능에 유의미한 영향을 주지못할겁니다. ScriptableObject도 마찬가지입니다. 심지어 ScriptableObject는 GameObjec에 비하면 일반적으로 Clone 생성이 빠르며(Component가 없으므로) 필요할 때 한번씩 생성하죠. ScriptableObject의 생성 비용이 두려워서 지양하겠다는 말은 기본 연산자는 성능에 좋지 않으니 모든 연산자를 비트 연산자로 바꿔 사용하자는 것과 같은 얘기입니다. 실제 프로그램엔 아무 영향이 없는걸 이론적으론 이러하니 바꾸자는 소리죠. "야, 비트 연산자를 쓰면 그냥 연산자를 쓰는 것보다 0.0000001초 빨라. 비트 연산자 쓰자"(물론 이런 극단적인 최적화가 필요한 분야도 있긴 합니다.) ScriptableObject Architecture를 사용하지 말자고 얘기하는 여러 프로그래머들을 봐왔고 그들 나름의 주장이 있고 제가 그에 반박할 주장도 있지만 진지하게 Performance 비용 때문에 ScriptableObject를 쓰지 말자고 주장하는 프로그래머는 보지 못했던 것 같습니다. 그들도 개발자고 저도 개발자이기 때문에 그게 얼마나 의미없는 소리인지와 제대로 쓰면 Performance 문제가 생길 일이 없다는 것을 알기 때문입니다. 그와 별개로, 일반 class가 더 좋겠다 하시면 그렇게 전환하셔도 됩니다. ScriptableObject 같은 경우 직접 Destory 함수로 객체를 파괴해줘야하기 때문에 번거로움이 좀 있긴하죠. 하지만 반대로 편한 Data 관리와 다른 객체로 Drag and Drop을 통한 Serialize를 포기해야하는 등 여러 이점도 포기해야한다는 부분을 명심하셔야합니다. 결론적으로, 의미없는 Performance 문제가 아니라 '실용' 측면에서 스스로 다각도로 면밀히 판단하여 어떻게 할지 결정하시면 될 것 같습니다. 강의는 그저 길잡이일뿐 수강생분께서 더 낫다고 생각되는 방향으로 가시면 됩니다. 실제로 저도 상황에 따라서 어떤 것은 ScriptableObject로 만들고, 어떤 것은 그냥 Class List로 만드는 등 섞어서 사용합니다. 감사합니다.
- 0
- 1
- 56