게임개발자 허민영

보호되어 있는 글입니다.

https://drehzr.tistory.com/1190 Unity)Asmdef (어셈블리 정의)Asmdef (어셈블리 정의) Unity에서 어셈블리로 따로 정의해서 파일을 만들 수 있다. 어셈블리 파일로 관리를 하게되면 특정 스크립트만 따로 재 빌드해서 컴파일 시간을 단축할 수 있다. 어셈블리drehzr.tistory.comhttps://docs.unity3d.com/kr/2021.3/Manual/ScriptCompilationAssemblyDefinitionFiles.html 어셈블리 정의 - Unity 매뉴얼어셈블리 정의 및 어셈블리 레퍼런스는 스크립트를 어셈블리로 구성할 수 있는 에셋입니다.docs.unity3d.comUnity 어셈블리 정의 완벽 가이드1. 어셈블리란 무엇인가?기본 개념**어셈블..

구조적 사고를 위한 실용 가이드DI는 구조 문제를 가리는 화장술이다의존성 주입(DI)은 강력한 도구지만, 현실에서는 구조적 문제를 해결하는 대신 보이지 않게 만드는 화장술로 남용되는 경우가 많다. 복잡하게 얽힌 의존성을 컨테이너 안으로 밀어넣어서 "깔끔해 보이게" 만들지만, 근본적인 설계 문제는 그대로 남아있게 된다.진정한 해결책은 DI 컨테이너에 손을 뻗기 전에 구조적 개선 가능성부터 탐색하는 것이다.5가지 필수 질문DI를 사용하기 전에 반드시 다음 질문들에 답해보라:1. "이 의존성이 왜 이렇게 복잡한가?"PlayerController가 InputManager, AnimationController, SoundManager, UIManager에 모두 의존한다면, DI로 주입하기 전에 먼저 물어봐야 한다..

핵심 역량1 아키텍처 설계 전문성인디게임 팀에서 아키텍트 역할 수행 (4년 활동 중 2년 5개월)MV패턴 기반 코드 구조 개선으로 프로젝트 규모 6배 확장 (1달→6달 규모)유지보수성 향상을 통한 팀 개발 효율성 증대반응형 패러다임 기반 Akasha 아키텍처 설계 및 구현 소개글 [Akasha] Unity 게임 개발을 위한 체계적 아키텍처 프레임워크Unity 게임 개발에서 코드의 복잡성을 관리하고 관심사의 분리(SoC) 원칙을 적용한 체계적인 아키텍처 프레임워크를 소개합니다.핵심 설계 철학이 프레임워크는 관심사의 분리를 기반으로 두 가devakasha.tistory.com 국비교육 과정 중 아키텍처 설계 역량 인정받음2 창의적 문제해결 능력제조업 공정 개선 (LM디지털)ATG장비 제품 클리퍼 개발 및 장..

게임 개발의 이중 구조게임 개발은 다른 소프트웨어 개발과 구별되는 독특한 특성을 가지고 있다. **기획의 의도(재미 중심)**와 **구조의 정합성(효율 중심)**이라는 두 가지 목적이 게임 전반에 넓게 분포되어 있기 때문이다.기획의 의도 - 재미를 위한 확산목적: 플레이어의 재미와 몰입감특성: 주관적, 감정적, 유연한 변경 필요범위: 게임의 모든 요소에 스며들어야 함도구: 게임룰과 데이터를 통한 구현구조의 정합성 - 효율을 위한 확산목적: 시스템의 안정성과 성능특성: 객관적, 논리적, 일관성 유지 필요범위: 전체 시스템 아키텍처에 관통도구: 디자인패턴과 아키텍처를 통한 구현계층별 접근 전략상단 계층: 도메인 - 탑다운 접근재미: 게임의 최종 목표유저: 플레이어 경험 중심사람 이해: 플레이어 심리와 행동 ..

상태와 사이드이펙트의 본질적 관계프로그래밍에서 상태와 사이드이펙트는 본질적으로 같은 현상의 서로 다른 측면이라고 볼 수 있다. 철학적으로 접근하면, 상태 변경 자체가 사이드이펙트의 한 형태이다. 함수형 프로그래밍에서 x = x + 1과 같은 단순한 할당도 기존 상태를 변경하는 '부작용'으로 간주되는 것이 그 증거다.하지만 실용적 관점에서는 미묘한 차이가 존재한다. 상태는 프로그램이 의도적으로 관리하는 데이터를 의미하는 반면, 사이드이펙트는 주요 목적 외에 발생하는 부수적인 변화를 가리킨다. 또한 로컬 변수 변경은 제한된 범위의 상태 변화인 반면, 전역 상태나 I/O는 더 광범위한 사이드이펙트를 야기한다.의도하지 않은 상태와 사이드이펙트의 관계대부분의 사이드이펙트는 의도하지 않은 상태 변화에서 기인한다. ..

소프트웨어 개발에서 탑다운과 바텀업 접근방식은 단순한 개발 방법론을 넘어서 전체 시스템 설계와 팀 운영에 중요한 영향을 미친다. 이 두 접근방식을 효과적으로 활용하기 위해서는 각각이 어떤 상황과 계층에서 최적의 성과를 내는지 이해해야 한다.계층별 접근 전략상단 계층: 도메인 - 탑다운 접근최상위 도메인 계층에서는 탑다운 접근이 필수적이다. 이 단계에서는 비즈니스 요구사항과 도메인 지식에서 출발하여 전체적인 아키텍처와 시스템 경계를 설정한다. DDD(Domain-Driven Design)와 같은 방법론이 효과적이며, "무엇을 해야 하는가"에 대한 명확한 정의가 이루어진다.폭포수 모델과 선언형 프로그래밍이 어울리는 이유도 여기에 있다. 도메인의 복잡성과 비즈니스 로직을 체계적으로 분석하고 설계하는 과정에서는..

프로그래밍 설계 원칙에 대한 균형잡힌 관점프로그래밍의 근본적 어려움은 복잡한 현실을 코드로 옮기는 과정에서 발생한다. 현재 널리 받아들여지는 설계 원칙들과 아키텍처 패턴들이 많은 도움을 주고 있지만, 때로는 맥락을 고려하지 않은 채 획일적으로 적용될 때 예상치 못한 복잡성을 만들어낼 수 있다.SOLID 원칙의 맥락적 한계SOLID 원칙은 분명히 좋은 지침이지만, 모든 상황에 동일하게 적용하기에는 한계가 있다. 특히 의존성 역전 원칙(DIP)의 경우, 시스템 규모에 따른 적절한 결합 메커니즘을 고려해야 한다. 클래스 내부에서는 직접 호출이 효율적이고, 작은 규모에서는 구체 클래스 주입이 더 적합할 수 있다. 무조건적인 추상화는 때로는 불필요한 복잡성을 초래할 수 있다.리스코프 치환 원칙(LSP) 역시 이론..

메인 목표: 복잡한 게임 시스템을 안정적이고 확장 가능하게 관리할 수 있는 아키텍처 구축5가지 세부 목표1. 시스템 간 명확한 책임 분리WorldSystem과 UISystem으로 관심사를 분리하여 각각의 복잡도를 독립적으로 관리계층별 SoC(Separation of Concerns)를 통해 추상화 수준을 체계적으로 구분2. 반응형 데이터 흐름을 통한 느슨한 결합Rx 프로퍼티 시스템(RxVar, RxMod, FSM, RxStateFlagSet)으로 데이터 변화에 자동 반응하는 구조구독 패턴을 통해 컴포넌트 간 직접 의존성을 제거3. 모듈식 기능 분할로 코드 재사용성 극대화Entity-Part 시스템으로 기능을 작은 단위로 분할하여 조합 가능Effect 시스템으로 게임 로직을 재사용 가능한 효과 단위로 모듈..

프로그래밍의 근본적 어려움프로그래밍에서 지속적으로 고전하고 있는 문제들을 살펴보면, 복잡성 관리, 변화에 대한 대응, 코드의 가독성과 유지보수성, 그리고 성능과 추상화의 트레이드오프 등이 있다. 이러한 문제들은 단순히 기술적 한계가 아니라, 프로그래밍의 본질적 특성에서 기인한다.프로그래밍은 세상에 대한 객관적 인식을 코드로 작성하는 행위이다. 세상 자체가 복잡하기 때문에 코드도 복잡해지는 것이고, 세상이 실체적이기 때문에 추상화에도 비용이 따른다. 따라서 추상화나 간단한 코드는 프로그래머를 위해 필요한 것이지 실질적인 구동을 위해 필요한 것은 아니다. 이는 작성하는 코드와 동작하는 코드의 차이가 커도 된다는 것을 의미하며, 결국 프로그래밍 언어의 고도화를 통해 해결되어야 할 문제이다.패러다임 선택의 새로..