[📜일지] HUD/UI의 디자인 초안 완성, 다음 작업 계획.

[부리바2(exit5693)]

HUD 패널 및 UI 요소 디자인 초안

내가 봐도 아름답다. 

흑흑...

GPT는 내게 후에 변동될 여지가 크니 간단하게 하라고 조언했지만 기계 새끼 말은 듣지 않는다.

수정은 수정이 필요하면 다시 작업하면 되는거다.

빈 칸이 많아 보이지만, 버튼 규격 맞춰서 다 제작된 상태고 안에 글자나 그림만 넣으면 되는 상태.

뿐만 아니라 완성 단계를 기준으로 작업 했기에 그 과정에서 수 많은 부품을 창출해낼 수 있었고

그걸 이용해서 후에 추가될 패널이나 다른 UI/HUD를 순식간에 뽑아낼 수 있음

얼마 없어보이지만 해당 이미지는 일부 조각 부품들만 나와있고 실제로는 70 레이어 정도 됨 + 폐기한 패널 디자인까지 하면 더 많고.

이 덕분에 조각별로 타일화해서 코딩으로 다양하고 개성있는 동일 테마의 패널들을 양산하는 것도 가능해짐 

사실상 모든 UI 디자인 스프라이트 요소가 레고 블럭화 되어있는 상태. 

이제 UI/HUD 스프라이트 작업은 완료로 치고 타일맵과 캐릭터 스프라이트 작업에 들어가는데. 

그것들도 이 UI/HUD 스프라이트 들 처럼 편집 재사용이 가능하도록 블럭화 해볼 예정...

오브젝트 스프라이트는 확실하게 블럭화가 가능할거라고 생각되는데

현재 작업중인 캐릭터 스프라이트는 잘 모르게쓰, 뿐만 아니라 지금 글쓰면서 본건데 머리가 좀 큰것같아서 1-2픽셀 줄여야할듯

그리고 확실히 탑뷰에서 쿼터뷰로 전환하고 느껴지는 그림 난이도 압박이 좀 쌘듯

특히 캐릭터 스프라이트는 애니메이션도 고려해야해서, 각 부위와 명암 디테일에 규격을 정해놓고 그리는게 좋을 것 같음

그래도 최근 아스프라이트 브러쉬에서 쉐이딩 브러쉬 기능을 알아낸 덕에 채색 작업 속도 및 픽셀 노가다 효율이 엄청 좋아져서 다행.

마치 마법처럼 명암이 알아서 그려지는게 좋아써...

[기존 테스트용 애니메이션 스프라이트]

평범한 애니메이션은 보통 24fps처럼 기준 프레임을 정해 두고, 그 흐름에 맞춰 그림을 그리는 방식인데

반면 게임 애니메이션은 프레임 기준보다, 하나의 행동에 몇 장의 스프라이트를 사용할지 정하는 느낌에 더 가까운 듯

예를 들어 0.5초짜리 애니메이션이라면, 24fps 기준으로 총 12장이 필요하고

이를 출발 / 중간 / 도착으로 3등분해 각 4장씩 배치하고, 여기에 연결 프레임과 정지 프레임(임팩트 구간)을 조절해서 대략 6~8장 정도로 설계할 수 있는데,

그런데 게임 애니메이션은 조금 다르다.

단순히 행동 그대로 애니메이션을 만들면 조작 반응 속도와 맞지 않아 어색한 느낌이 남

이 부분은 결국 직접 박아보며 깨달아야할 부분인 듯 

그래서 SNK의 스프라이트 시트를 보면서 연구 중인데, 아마 한동안은 애니메이션 공부만 하게 될 듯

현재 FX 효과 작업은 최대한 뒤로 미뤄둠, 아무래도 FX가 가장 난이도가 높을 것 같아서

그리고 애니메이션 관련 글을 쓰다가 새삼 깨달은 점이 있음

게임 애니메이션은 결국 스프라이트 시트를 카메라가 이동하거나 전환하는 방식으로 출력하는 구조라는 것

그렇다면 이런 카메라 이동식 출력 방식을 활용해서, Pan 효과나 Zoom 효과로 다양한 연출도 가능할 듯

예를 들어 숫자 0~9를 세로로 길게 배치해 두고, 카메라를 위아래로 이동시키면 숫자가 바뀌는 장면을 다이얼이 돌아가는 듯한 방식으로 연출할 수도 있을 듯

[그래픽 테스트 화면]

탑뷰에서 쿼터뷰로 바꾸고 테스트 해봤는데 ㄹㅇ 탑뷰가 깡패긴하다.

저 위의 테스트 스프라이트는 기존에 테스트 용으로 내가 그렸던 정면 스프라이트를 나노바나나한테 부탁해서 쿼터뷰 시점으로 바꾼건데

ㄹㅇ AI 도랐음, 저거 한번 뽑아보고 나노바나나 쓸까 존나 고민했었는데 

그냥 저정도는 내가 해도 되고 사람이 하는 쪽이 좋을것같아서 내가 하기로함

코딩도 사실상 코덱스한테 짬때렸는데 최소한 인간이 그래픽은 하는게 맞지.

그래도 코덱스 시발년이 전부 하드코딩 했을때 개빡쳐서 하드코딩 한거 Json 데이터화 시키는 기획안 작성한다고 6시간 소모했을 때는 좀 프로그래머 된 느낌이었음

지금은 기획안md 줄 때 버튼 클릭 방식부터 어느 스크립트와 함수와 연결되고 그 과정에서 무슨 스크립트와 json이 생성되는지, 데이터 스키마 기준 어떻게 세워야하는지 까지 다 기획해줌. 

github이랑 gpt 연결해서 한세션 끝나는 분기마다 정밀 보고 작성후 흝고 수정 기획, 개발방향 로드맵 작성해주고

존나 해커된 느낌 ㄹㅇ

그 결과 시스템 자체는 확실히 로그상으로나 그레이박스 적으로나 잘 작동하는게 보이는데, UX/ 그래픽적으로는 검증할 수 없어서 걱정

아마 진짜 개발 지옥은 UX/그래픽 개발 단계 부터 시작일듯;

벌써 토나옴.

"BEEP BOOP, You've hit your usage limit. Upgrade to Pro"

 -Codex-

스모크 테스트 검증 통과해서 무결정하라고 지시했더니 하드코딩된 스모크 테스트로 무결점 검증해버려서 로그로 버그 못찾는 상황 발생했었는데

UX단계 때 얼마나 많은 사고가 발생할지 벌써 토나옴 

리펙토링로 초기에 잘 하라고 지시해서 기준 고정해놨는데 

며칠 전 한번 점검해보니까, 임시로 테스트용 gd 만들어 놨던게 스크립트 9000줄 짜리 코어 엔진이 되어있었음.

이거 리펙토링 하라니까, 지금 하면 겜 터진다고 현재 개발중인 알파 기능을 완성한 뒤 해체하는게 더 효율적이고 안전하다면서 미뤄버렸음.

인간 말도 안들음, 이새끼도 아는듯. 지없으면 겜 개발 안되는거 ㄹㅇ. 코덱스 이새끼 자아 있음. 

codex 시발년은 좀 사이코패스같음, ㄹㅇ.  GPT는 핵심 찔려 박히는거 좋아하는 마조년이고

클로드 많이 쓰는것같은데 이 개발 상황에서 클로드 넣으면 100퍼 충돌 날것같아서 못넣겠음

codex랑 gpt랑 형제인데 클로드 이새끼 투입되는 순간 클로드 따당해서 우울해질듯

codex와 GPT 콤보의 최대 장점은 한 구독료로 둘을 사용가능 하단 것과, GITHUB 연결로 작업효율이 좋다는 것일듯.

지금은 게임의 기획안이 완성되고 모든게 고정된 상태라 사실상 코딩 부분만 코덱스가 빠르게하면 되는 단계,

인간인 내가 그래픽을 빠르게 양산해내고 그걸 게임에 입히면 실플레이 까지 가능한 수준인듯.

뿐 만 아니라 현재 설계한 작업용 에디터툴 엔진을 만들고 있어서 이게 완성되면 

저번 에디터 테스트 검증 때 json 파일 수정과 맵 제작, 트리거 설정까지 확인했으니

이정도면 게임 레벨 디자인 부터 필드맵 같은건 내가 뽑아낼 수 있어서 

그 때부터는 AI 의존도가 지금 보다 현저히 덜 할 듯, 에디터에 필요한 기능만 코딩으로 추가하게 하면 되니까.

이런거 보면 AI가 얼마나 발전했는지, 또 Godot엔진이 얼마나 대단한 엔진인지 깨닿게됨;

나같은 좁밥도 게임 '디벨로퍼' 가 될 수 있다니...

[sdf(symphony1272)]

이거 고도 바이럴이네요

[211214(tomatoss)]

[엔록(whale0407)]

[엔록(whale0407)]

기술부채... 갚아야쥐?

[부리바2(exit5693)]

[Indie 1(218.155)]

고수네

[르미(abuse3308)]

개성있어서 좋아요