| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 |
- 주우석
- 박기현
- hanbit.co.kr
- 김진홍 옮김
- C++
- 밑바닥부터 만드는 컴퓨팅 시스템 2판
- HANBIT Academy
- cyphenengine
- booksr.co.kr
- 이득우의 게임수학
- 게임 수학
- The Elements of Computing Systems 2/E
- 일기
- https://insightbook.co.kr/
- 입출력과 사칙연산
- 생능출판
- (주)책만
- C
- 잡생각 정리글
- BOJ
- 백준
- unity6
- 알고리즘
- 메타버스
- JavaScript
- Noam Nisan
- 이득우
- C#
- 데이터 통신과 컴퓨터 네트워크
- 전공자를 위한 C언어 프로그래밍
- Today
- Total
목록전체 글 (510)
cyphen156
지난 6월부터 에이전트를 사용해온 내 경험 기준의 체감을 써보겠다.에이전트 둘이서 헛짓거리하면서 통제를 자꾸 벗어나려 해서 쓰는 글 맞다.일단 내 원칙은 다음과 같다.절대로 원본 프로젝트를 직접 수정하도록 허용하지 않는다.수정 / 생성된 코드를 무단으로 반영하지 않는다. 항상 사용자에게 보고하고, 사용자가 직접 옮긴다.룰을 항상 확인하고 적용한다.지난 3개월간, 그리고 최근에 가장 심하게 느낀 문제점은 역시나 애플리케이션 설계에 대한 통제력과 인지적 오프로딩이다.물론 항상 문제가 생기는 건 아니다.오히려 에이전트를 쓰면서 굉장히 만족하는 부분도 많다.대표적으로 보일러플레이트.이미 내가 구조를 알고 있고, 어떻게 만들어져야 하는지도 알고 있는데 그냥 손으로 일일이 작성하기 귀찮은 코드들이 있다.반복되는 클..
분석 기준일 : 2026.08.26이 글은 네오플 : 던전 앤 파이터에 대한 사전지식이 있다면 더 이해하기 편할 것이라 생각합니다.과거에 출시된 캐릭터도 도트 개선, 스케일 조정, 리뉴얼 패치로 인해 리소스 구조가 변경되는 경우가 있다.하나의 직업군 안에 더 이상 사용하지 않는 구형 Skill Effect와 개편 이후의 Effect가 함께 남아 있을 수 있다.IMG의 사용 Version은 단순한 출시 세대만으로 정해지지 않으며 자산 유형과 리소스가 수정된 시점의 영향을 함께 받을 수 있다.캐릭터의 표현은 Body, Hair, Coat, Pants, Shoes, Weapon 같은 여러 Part와 아바타 슬롯, 장비 슬롯의 조합으로 만들어지며, 각 Part는 동일한 동작의 FrameNo에 맞춰 겹쳐진다.아바..
최근에 갑자기 던전앤파이터의 리소스를 뜯어보고 싶어졌다.그래서 관련 자료를 대강 뒤적거리다가, 바이브 코딩으로 만들게 된 NPK Asset Importer Unity Tool.처음부터 장기간 유지보수하거나 배포할 생각으로 만든 툴은 아니다.필요한 리소스를 한 번 가져오고 나면 역할이 거의 끝나는 도구이기 때문에 구현 자체는 전적으로 AI를 활용한 바이브 코딩에 맡겼다.대신 나는 주로 목표 설정, 지원 범위 결정, 시스템의 책임 분리, 생성된 로직 검증과 실제 데이터 대조를 담당했다.따라서 이 글은NPK/IMG 포맷을 처음부터 직접 역공학해서 Extractor를 만들었다.라는 내용은 아니다.공개되어 있는 자료와 기존 구현, AI를 활용해 포맷을 조사하고 실제 데이터를 직접 스캔하면서 내게 필요한 범위만 정..
지난 글에서 10,000개 객체 부하 테스트를 정리하면서 "과거 업데이트 구성이 없었을 때보다 평균 300FPS 정도 감소했다"고 적었다.그런데 그 판단의 기준이 애매했다. 비교 대상이 며칠 전 다른 환경에서 잰 수치였고, 그사이 백그라운드 부하도 달랐다.그래서 같은 장비에서 커밋을 하나씩 되짚어가며 다시 측정했다.측정 방법각 커밋을 체크아웃해서 빌드하고, 같은 세션 안에서 연속으로 잰다.main (#3 머지) Runtime 없음#4_12 Object 수명 · Runtime/World 소속 · Transform 저장소#4_13 Function Group 도입#4_14 평면 등록 · 실행 계측 추가#4_15 UpdateMan..
UpdateManager와 계층형 Update 참여 구현을 마친 뒤, 실제 Runtime 환경에서 객체 10,000개를 구성해 부하 테스트를 진행했다.이번 테스트는 단순히 동일한 Update 함수만 반복 호출하는 방식이 아니다.WorldObject, 일반 GameObject, Component 파생 타입에 네 가지 Update 단계의 가능한 16개 참여 조합을 분배하고,혼합 SubObject 트리를 실제 Runtime과 World에 등록한 상태에서 실행했다.테스트 구성GameRuntime 1개└─ World 3개Object 총 10,000개├─ GameObject ..
드디어 객체의 업데이트 루프가 Runtime 내부로 들어왔다.흔히 떠올리는 것처럼객체 소유 트리를 재귀적으로 순회하며 Update를 호출하는 방식이 아니라,Unreal Engine과 유사하게 업데이트 함수를 실행 그룹에 등록하고 해제하는 구조를 만들고 있다.단순해 보였던 작업이 오래 걸린 이유도 여기에 있는 것 같다.이 구조를 만들며 알게 된 점이 하나 있다.클래스에 Update를 구현하더라도 함수의 구현만 객체가 소유할 뿐,그 함수를 언제 실행할지 결정하는 책임까지 객체가 갖는 것은 아니다.실제 실행 참여 여부와 호출 순서는 Runtime의 업데이트 그룹이 관리한다.Unity 역시 Update, FixedUpdate, LateUpdate 같은 콜백을 구현한 MonoBehaviour를 내부 실행 목록으로..