전체 글

StartCoroutine의 가장 큰 장점은 비동기처럼 보이는 순차적인 코드를 쉽게 작성할 수 있다는 것※비동기는 멀티스레드가 아님비동기어떤 작업이 끝날 때까지 기다리지 않고, 다른 작업을 계속 수행하는 것 특히 좋은 경우 - 연출, 쿨타임, 여러 프레임에 걸친 작업, 순차적인 게임 로직 Coroutine 자체가 나쁜 게 아니라, 모든 로직을 Coroutine으로 관리하는 것이 문제 1. 상태 관리가 어려워짐- 특히 여러개의 코루틴이 동시에 실행되면 같은 변수에 접근하는 경우 문제가 발생할 수 있음2. 중단/취소 관리가 까다로움- 이벤트가 발생하게 되면 코루틴이 계속 실행되면 안될 수 있음- 그렇게 되면 코루틴을 변수로 할당받아서 관리가 필요해짐3. 디버깅이 불편함- 실행이 여러 프레임에 걸쳐 끊겨버리기..

BRG는 Unity가 대량의 오브젝트를 효율적으로 렌더링하기 위해 제공하는 저수준(low-level) 렌더링 APIUnity6에서도 계속 발전하며 핵심 렌더링 인프라로 자리잡고 있음 핵심 개념- CPU 측에서 오브젝트별 트랜스폼, 머티리얼 프로퍼티 등을 직접 GPU 버퍼에 채워넣고, Unity 렌더 파이프라인에 "이 배치들을 그려라"라고 지시하는 방식- 기존 MeshRenderer 컴포넌트 기반 렌더링을 거치지 않고, 개발자가 직접 인스턴스 데이터를 관리하는 구조라서 오버헤드가 매우 적음- 본질적으로 GPU Instancing을 대규모로, 그리고 완전히 커스터마이즈 가능한 형태로 수행하는 API 왜 필요한가- 수만~수십만 개의 오브젝트(나무, 군중, 파티클성 오브젝트 등)를 그릴 때 일반적인 GameOb..

SRP Batcher(Scriptable Render Pipeline Batcher)는 URP/HDRP 같은 SRP 기반 파이프라인에서 드로우콜 사이의 CPU 오버헤드를 줄이기 위한 렌더링 최적화 기능Unity6에서도 핵심 최적화 수단으로 계속 사용됨 기존 방식의 문제- 오브젝트마다 머티리얼이 달라도 쉐이더가 같으면, 원래는 매 드로우콜마다 쉐이더 바인딩, 여러 유니폼(상수 버퍼) 세팅 등 CPU 작업이 반복됨- 다이나믹/스태틱 배칭은 실제로 매쉬를 하나로 합쳐버리는 방식이라 버텍스가 많으면 오히려 손해고, 스키닝 매쉬나 대형 매쉬엔 적용이 잘 안됨 SRP Batcher의 동작 방식- 매쉬를 합치는게 아니라, 머티리얼의 프로퍼티(상수 버퍼)를 GPU 메모리에 미리 큰 버퍼로 업로드해두고, 오브젝트를 그릴..

암호화(Encryption)란?암호화는 원본 데이터를 특정 알고리즘과 키를 이용해 제3자가 읽을 수 없는 암호문으로 변환하는 기술크게 두 가지 방식이 있음- 대칭키 암호화 (Symmetric) : 암호화와 복호화에 같은 키를 사용. 빠르지만 키를 안전하게 공유하는 것이 문제. (예: AES, DES)- 비대칭키 암호화 (Asymmetric) : 공개키/개인키 쌍을 사용. 공개키로 암호화하면 개인키로만 복호화 가능. 키 공유 문제는 해결되지만 속도가 느림. (예: RSA, ECC) AES(Advanced Encryption Standard)- 2001년 미국 NIST가 표준으로 채택한 대칭키 블록 암호- DES를 대체하기 위해 만들어졌고, 현재 전 세계에서 가장 널리 쓰이는 암호화 표준- 블록 크기 : 1..

C#에서 enum이 byte를 상속받으면 얻는 이점1. 메모리 절약기본적으로 enum의 underlying type은 int(4바이트)byte로 지정하면 1바이트로 줄어듬- enum 배열이나 컬렉션을 대량으로 사용할 때 메모리 사용량이 크게 줄어듦- 캐시 효율이 좋아짐 (배열이 더 조밀해져서 CPU 캐시 라인에 더 많이 들어감) public enum Status : byte{ None = 0, Active = 1, Inactive = 2} 2. 직렬화/네트워크 프로토콜 호환바이너리 프로토콜, 파일 포맷, 게임 네트워크 패킷 등에서 필드 크기가 1바이트로 고정된 경우, enum을 byte로 맞추면 별도 변환 없이 그대로 매핑 가능 3. 구조체(struct) 크기 최적화struct 안에 enum 필드가 여러..

System.Collections.Generic 네임스페이스에 있는 키-값 쌍 컬렉션으로키를 기준으로 항상 정렬된 상태를 유지하는 딕셔너리 특징- 내부 구조 : 이진 검색 트리(Red-Black Tree)로 구현됨- 정렬 : 삽입 순서와 무관하게 항상 키 기준 오름차순 정렬 유지 (기본적으로 IComparable, 또는 생성자에 ICompare 전달 가능)- 중복 키 불가 : Dictionary와 마찬가지로 키는 유일해야 함 시간 복잡도연산복잡도삽입/삭제/검색O(log n)순회(정렬된 순서)O(n) 일반 Dictionary는 삽입/검색이 O(1)이지만 순서 보장이 없음SortedDictionary는 그 대가로 정렬을 얻는 대신 O(log n)이 됨 언제 쓰는가- 키를 항상 정렬된 순서로 순회해야 할 때-..

Unity 개발자가 Unreal Engine을 배우며 겪은 것들을 기록합니다.오늘 한 것Luneria 프로젝트에서 아이템 습득 시스템을 C++ 기반으로 구현했다.IInteractable 인터페이스, FItemData 구조체, USphereComponent 오버랩 감지까지 구조를 잡고, Blueprint에서 값을 조정하는 패턴으로 완성했다.Unity의 OnTriggerEnter + IInteractable 구조를 언리얼로 옮기는 과정이었는데, 생각보다 다른 점이 많았다.배운 개념1. Unreal Interface 패턴 — 왜 클래스가 두 개?Unity에서 인터페이스는 IInteractable 하나 선언하면 끝이다. 언리얼은 다르다.// UInteractable : UObject 상속, 리플렉션 등록용 껍데..

조작감과 관련된 프로젝트를 진행하였다기억이 살짝 가물가물하지만 활강하는 느낌을 내고 싶다고 생각했었고 3D는 확정이였으나 1인칭으로 할지 3인칭을 할지 고민했던 것 같다회의한 화이트보드를 보고 있는데 기억이 너무 가물가물하다결과적으로 활강 시뮬레이터가 되긴했는데팀원 중 한명이 프리미티브로만 다람쥐를 만들었었다그 당시 개발하느라 너무 바빠서 덜 느꼈던 것 같은데 너무 귀엽다..의도하고자 했던 것은 명확했다넓고 확 트인 공간에서 유저는 위에서 아래로 떨어지며 활공하는 느낌을 받을 수 있다컨트롤러를 이용해서 방향을 바꿀 수 있으며 FPS 형태로 총알을 쏴서 풍선을 맞추면 도토리를 얻을 수 있었다섬으로 착지를 잘해야했고 그대로 밑으로 떨어지게 되면 게임오버가 된다 카메라 버그가 발생해서 정말 많이 고생했다사실 ..

기수를 진행하시던 분들이 후기글을 대부분 많이 보시리라 생각이 든다.몇주차에 무엇을 하고.. 몇주차에는 무엇을 할 것이며.. 다음주에는 이걸 할 것이다!라는 걸 기수들끼리 얘기하는 재미도 있더랬지물론 나도 기수를 진행하던 동안에 많이 찾아봤었고, 전기수분들의 블로그 내용들로 다음 주차 내용을 유추(?) 하고 그랬었다. 그동안 쓰지 않았던 이유는 2기가 겪었던 커리큘럼과 그 다음 기수분들이 겪는 입학시험과 커리큘럼이 매우 다르다는 것을 다음 기수분들을 통해서 들었기 떄문이다.아마도 계속해서 추가하고 수정하고 변경하시면서 커리큘럼을 보완 해나가시는 거겠지 싶기도 하다.그리고 꼭 우리 기수가 겪었던 커리큘럼이 좋은 커리큘럼이라고 볼수도 없고 그 다음 기수분들이 겪었던 커리큘럼이 좋은 것이라 단정할 수 없다.완..

면접 준비를 하다 보니 특정 유형의 문제가 반복해서 나온다는 걸 느꼈다.특히 비트 연산(비트마스크)과 Merge Sort는 거의 빠지지 않고 등장한다.처음에는 단순히 “알고리즘 문제니까”라고 생각했는데,조금 더 공부해보니 이건 문제 풀이 자체보다클라이언트 프로그래머로서의 기본기를 확인하기 위한 질문에 가깝다는 생각이 들었다.이 글에서는 공부하면서 느낀 점을 기준으로왜 이 두 가지가 자주 나오는지 정리해보려고 한다.비트 연산과 비트마스크처음에는 단순한 최적화라고 생각했다비트 연산을 처음 접했을 때는그냥 “빠른 연산을 위한 트릭” 정도로 이해했다.하지만 계속 보다 보니 이건 단순한 연산 문제가 아니라데이터를 어떻게 표현할 것인가에 대한 문제였다.여러 상태를 하나로 관리하는 방식예를 들어 플레이어 상태를 관리..

1. 문제 상황기존 턴제 시스템을 구현할 때, 각 객체의 행동을 순차적으로 직접 호출하는 방식으로 구성했다.하지만 이 방식에는 다음과 같은 문제가 있었다.특정 행동이 끝나기 전에 다음 행동이 실행되는 문제객체 간 직접 참조로 인해 결합도가 높아지는 구조새로운 행동 추가 시 기존 코드 수정이 필요한 구조이로 인해 시스템의 확장성과 유지보수성이 떨어지는 문제가 발생했다.2. 해결 접근이 문제를 해결하기 위해 이벤트 큐(Event Queue) 기반의 턴 처리 시스템을 도입했다.핵심 아이디어는 다음과 같다.모든 행동을 “이벤트” 단위로 분리이벤트를 큐에 저장하여 순차적으로 실행중앙에서 전체 흐름을 관리이를 통해 각 객체가 서로를 직접 호출하지 않고,이벤트를 생성하여 전달하는 구조로 변경했다.3. 시스템 구조전체..

최근 채용 공고를 보다 보니“AI 에이전트 오케스트레이션이 가능하신 분”이라는 문구를 보게 됐다.처음에는 그냥“AI 잘 쓰는 사람을 말하는 건가?”정도로 생각했는데, 찾아볼수록 생각보다 애매한 개념이었다.그래서 이것저것 찾아보고,클라이언트 프로그래머 입장에서 어떻게 이해하면 좋을지 정리해봤다.이 글은 정확한 정의라기보다는..이렇게 이해하니까 조금 덜 헷갈리더라 정도의 정리다.AI 에이전트 오케스트레이션이란?내가 이해한 기준에서 이 개념을 한 줄로 정리하면 이렇다.여러 AI를 역할별로 나누고,그 역할들이 일정한 흐름과 조건에 따라 반복적으로 실행되도록 만드는 구조조금 더 풀어서 보면한 번의 요청으로 끝내는 게 아니라생성 → 검증 → 수정 같은 단계를 나누고그걸 반복하면서 결과를 개선해나가는 방식이다여기서 ..

벌써 2026년 2월 2일이다회고록은 사실 그 해 연말에 써야하는 것이 맞건만.. 연말에 이러저러한 여러가지 이슈가 있어 이제서야 적게되었다25년도에 나는 무엇을 했는지에 대해 복기하고 또 되짚어 보면서 올해는 어떤 개발자가 되고 싶을지 차차 생각해봐야겠다 1월크래프톤 역삼에서 [Dr.COG] 게임의 시연회를 했다 특정한 공간을 빌려서 전시를 할 수 있었다는 기쁨과 입구에서 틀어지는 영상 덕분에 우리가 게임 출시를 잘 마무리했구나! 하는 것을 체감할 수 있었다스팀에서 출시했던 것은 생각보다 현실에서는 크게 와닿지는 않았기에 전시를 하는 경험이 컸던 것 같다우리 팀의 자리가 좀 좋아서 많은 분들이 플레이를 해주셨었는데, 여기서 직접 눈으로 확인할 수 있었던 우리 게임의 고쳐야할 점들이 많이 눈에 띄었다이 ..

1. 서론• 게임 소개 (제목, 장르, 플랫폼, 개발사/퍼블리셔)Ooo 게임은 폭탄 애벌레의 대모험으로 2D 플랫폼 메트로베니아 퍼즐 장르입니다. 개발사는 Nama Takahashi, tiny caclus studio, Tsuyomi 입니다. Nama Takahashi님과 Tsuyomi 님 두분이서 전작인 Elec Head를 같이 개발하셨던 것으로 보아 두 분이서 계속 개발을 이어나가시는 듯합니다. 조작법이 비교적 간단한 게임들을 만드려고 하시는 것 같습니다.• 글을 쓰는 목적 (예: 디자인 분석, 재미 요소 해부, 개선 포인트 등)몇몇개의 디자인 분석을 통해 재미요소를 탐구해보는 것이 글을 쓰는 목적입니다. 왜 이 게임이 재미있으며 압도적으로 긍정적인 평가를 받았는지 어떠한 세일즈 포인트가 있는지 그리..

hELLO 티스토리 블로그 적용을 하다가 생기는 문제 중 하나가 무한로딩인데이는 여러가지 문제점이 있을 수 있으나 단순히 스킨 등록을 하다가 나오는 실수일 수도 있다  스킨 등록을 할 때추가하는 경우에 images 폴더만 올리는 경우이다안의 파일은 들어가지 않기 때문에 images 폴더 안에 들어가서 이 파일들을 추가해주어야한다  이것 외에 다른 부분들은 티스토리가 요즘 블로그를 개편하면서 잠수패치로 바꿔버리는 경우들이 있다고 한다해당 부분들은   GitHub - pronist/hello: 😎 당신의 블로그를 위한 최고의 티스토리 스킨😎 당신의 블로그를 위한 최고의 티스토리 스킨. Contribute to pronist/hello development by creating an account on G..