아트 스타일이 독창적임좀더 많은 사람들이 접할수 있는 최적화, 독보적인 스케일의 유연성독보적인 아트스타일과 비쥬얼 구현장르 : 스토리 + 시뮬레이션특징 : 활협전처럼하나의 게임에 수많은 세계선을 구현그 이유는? : 내가 보고싶고 가고싶지만, 볼수 없는 세계를 체험하기

오늘은 기초 학습 과제를 수행했다.C자신만만하게 달리기반을 선택..기초 문법에 그렇게 난이도 있는 내용은 없었으나ref와 out, as, is정도가 굉장히 생소했다.1\. is - 타입 확인 연산자핵심: 객체의 타입이 맞는지 확인 후 true/false를 반환한다.Ja
💡 첫 번째 단상: 버전이라는 이름의 괴물InvalidOperationException: You are trying to read Input using the UnityEngine.Input class, but you have switched active Input
프로젝트 개요: gcliwidget기술 스택: Java 21, JavaFX, Maven, jpackage, Google Gemini 1.5 Flash핵심 기능: 자연어 명령(CLI)을 통해 캘린더 일정을 관리하는 데스크탑 위젯 애플리케이션.개발 방식: AI(Gemini
로스트아크쿼터뷰 MMORPG 장비 강화 시스템세부 목표: 아이템 레벨 상승을 통한 캐릭터 성장 및 상위 콘텐츠 진입본 분석의 관점: 특정 시스템(장인의 기운 및 최종 보상 골드)이 유저 간의 계층화에 미치는 영향 및 이로 인한 게임 경험의 균형 파괴.1단계: 성장 목표
처음 내가 짠 이벤트 구조는 꽤나 단순했다.실행할 액션의 종류를 Enum으로 정의한다. (AddMoney, StartDialogue 등)GameActionHandler라는 거대한 싱글톤 클래스를 만들고, Enum 값에 따라 분기 처리하는 메서드를 구현한다.상호작용 오브
지금 우리는 인류 문명의 운영체제(OS)가 통째로 업그레이드되는 듯한 거대한 변혁의 한복판에 서 있다고 생각한다. AI, 특히 LLM(Large Language Models)이 가져오는 변화의 파도는 우리의 일하는 방식, 생각하는 방식, 그리고 궁극적으로 개발이라는 행
지난주, 내가 개발 중인 프로젝트의 코드 아키텍처에 대해 뤼튼에게 리뷰를 요청했다. 결과는 충격적이었다. 무려 55가지의 구조 개선사항을 지적받았다. 그 지적들을 마주하고 있으니 이른바 '내글구려병'에 깊이 걸린 기분이었다. 이 문제들을 해결하지 않고서는 도저히 다음
퇴사한 지 한 달도 채 되지 않았는데 "오랜만에 겪는 협업"이라는 말이 어색하게 들릴지도 모르겠다. 하지만 지난 회사에서는 그랬다. "이거 되나요?" "안 됩니다." "저건 되나요?" "됩니다." 내 개발 역량과 커뮤니케이션 능력의 한계였을 수도 있다. 하지만 과연 그

결국 두려워했던 그놈이 나타났다.물론 초급 프로젝트의 스크립트 충돌에 두려움은 없었으나...문제는 Scene <- 이놈이었다.오늘은 팀원들과 각자 작업한 내용을 병합하기로 한 날이었다.그런데 오후 2시쯤 자리에서 사라졌던 팀원이 4시가 다 되어 나타나더니 말을 꺼
대화기능을 먼저 작성하여 스토리작업을 함께 진행하고 싶은 욕심에 GameScene의 구현을 먼저 시작했더니 코드가 꼬이기 시작했다. GameLifetimeScope와 GameInitializer에 임시 코드나 나중에 삭제해야 할 코드가 계속해서 늘어나고 있었다. 이대로
부트캠프 2주 차, C하지만 이전 포스팅에서도 여러 번 언급했듯, 나에게는 잘 짜인 구조에 대한 아집과 집착, 그리고 하드코딩에 대한 일종의 트라우마가 있었다. 그래서 이 간단한 프로젝트조차 가볍게 끝내고 싶지 않았다. 마침 개인적으로 진행 중인 비주얼 노벨 프로젝트의
오늘은 내배캠에서 배포한 C솔직히 초반부는 기본적인 개발문법이라 그렇게 주의깊게 듣지않았으나..후반부부터는 확실히 생소한 내용들이 등장하기 시작했다.챕터4에서 다룬 내용들이다. Lambda는 뭐 CDelegate (델리게이트): 메서드를 넘기는 파이프라인 비슷한 것하지
내 프로젝트의 대화 기능에 대한 보충을 진행하고 있었다. 원래대로라면 게임 내 대화가 끝난 후 선택지가 자동으로 노출되어야 했지만, 선택지가 전혀 노출되지 않는 문제가 발생했다. 선택지 제시 기능 자체는 이전프로젝트에서 완성을 했었기에 오랫동안 테스트를 진행하지않고 방
추석연휴를 포함하면 거의 2주만에 쓰는 TIL이다.부트캠프는 주차로만 따지면 어느새 4주차에 돌입했다. 이번 주차의 주제는 C팀이 구성되고 팀원 모두가 당황했다. 지금까지의 조와는 다르게 팀원 전원이 경험자로 구성되어 있던 것이다. 나에게는 너무나 큰 기회로 느껴졌다.

오늘 기재할 내용은 어제에 이어 데이터 처리방식에 대한 고민이다.이 사고가 이어진 부분을 보여주기위해 이번 TextRpg프로젝트에서 발생했던 트러블슈팅을 하나 소개한다.아이템관리 기능에 인스턴스상의 아이템의 독립성을 부여하기 위한 아이디가 부여되어있었다.이렇게 Clon
부트캠프 이번 주차 과제는 유니티로 메타버스 Zep과 유사한 환경의 게임을 만드는 것이었다. Zep이라고는 하지만 사실상 zep의 핵심은 웹소켓 기반 네트워크 동시성이다. 즉 이해하기 쉽게 zep을 예로 들었지만 결국말하자면 상호작용이 들어간 2D 탑뷰 게임을 만드는
내일이 부트캠프 유니티 입문 주차 과제 제출일인데, 문득 지난주에 프로젝트를 완료하고 Cinemachine과 비동기 처리에 대한 트러블 슈팅만 정리했지, 전체 프로젝트 리뷰를 작성하지 않았다는 걸 깨달았다. 3일이나 늦었지만 이제라도 정리해보려 한다.Cinemachin
내 프로젝트에서 VContainer를 사용하고 있지만, ResourceManager는 AddressableService를 생성자 주입받지 않고 내부에서 직접 생성하는 구조를 채택했다. 언뜻 보면 DI 컨테이너의 철학과 맞지 않는 선택처럼 보일 수 있다.Addressab
지난주 유니티 입문 개인과제 피드백이 나왔다.결과는 참혹했다."고민이 실제 '게임'이라는 결과물로 이어지지 못한 점이 가장 큰 문제로 보입니다. 복잡한 구조나 기교보다는, 실제로 작동하는 게임을 만들고, 플레이 가능한 형태로 완성해보는 것이 우선입니다."뼈를 맞은 기분
관리 방식: 자동 메모리 관리 (LIFO 구조)저장 데이터: 값 타입(Value Type), 지역 변수, 메서드 호출 정보할당/해제: 컴파일 타임에 크기 결정, 스코프를 벗어나면 자동 해제성능: 매우 빠름크기: 제한적생명주기: 메서드 실행 동안만 유지관리 방식: GC(
EnemyPresenter와 EnemyView는 정상 작동하지만, EnemyView의 HP와 Stamina UI만 업데이트되지 않는 기묘한 현상이 발생했다.같은 CharacterView와 CharacterPresenter를 상속받는 PlayerPresenter 쪽은 문

5주 만의 TIL이다. 바빴다는 핑계도 있지만, 솔직히 불성실했던 게 더 맞는 것 같다.그간 파이널 프로젝트가 시작되었고, 우리 팀은 오토배틀러와 머지를 결합한 게임을 개발하고 있다. 나는 건물, 인벤토리, 내부 재화 시스템 등을 담당하게 되었다.처음에는 모듈화를 위해

파이널 프로젝트가 어느덧 3주차에 들어섰다.우리팀은 에셋과 컨셉이 꽤 늦게 정해졌는데, 건물 에셋 쪽은 꽤나 골치아팠다.우리가 필요한 건물 에셋은 7종류 × 5레벨 = 총 35개, 당연히 확장 가능성도 고려해야 했다. 또한 모든 건물이 일관된 스타일을 유지해야 했으며,

파이널 프로젝트 4주차다.우리팀은 에셋을 뒤늦게 정했는데 기존 작업을 조금 빠르게 끝마치고 할거 없어진 내가 캐릭터 애니메이션을 맡게되었다.우리팀이 구매한 캐릭터에셋 제너레이터의 사용은 굉장히 간단했다.첨부된 씬을 킨뒤에 원하는대로 커스터마이징하고 저장버튼을 누르면 프
준비내용 \*\*\*모의면접 내용