M3까지의 일은 단순했다. 핵심컨텐츠를 개발하고자 했던만큼, 주력이 되는 캐릭터를 만들고 그와 매칭이 되는 배경을 만드는 일이다. 이제는 모든 캐릭터는 플레이가능한 상태. 여기까지 개발하면, 어쩐지 다 된 것처럼 보인다. 하지만 게임을 런칭해본 사람이라면 알고 있다. 진짜 일은 이제부터 시작이다. 먼저 남은 일을 정리해보자. 빠진 게 있으면 생각날 때마다 추가한다.
M4
네트워크 대전
다국어 지원시스템 구축
CPU대전 – AI준비
캐릭터 시나리오/대사 확정
시나리오 모드, 다이얼로그 시스템
일러스트레이션
스테이지 배경인물들 제작
스팀페이지 개설
도발 및 승리포즈2
M5
캐릭터 인트로/엔딩 웹툰
사운드(음성, bgm포함)
온라인 매칭
PV제작
미니게임(무한대전, 통깨기)
의상파괴 모델링
추가복장 모델링
코드는 GGPO를 사용한 네트워크 플레이를 위해 로딘의 손에 넘어가 있는 상태이다. 안정화 기간동안 그림을 그리자. 일단 손을 풀어야 한다. 컴퓨터로 그림을 그린 지 너무 오래 됐다. 난 AI이미지를 좋아하지만, 캐릭터 이미지엔 AI를 쓰지 않을 것이다. 그림을 그리는 게 이 프로젝트 최대의 즐거움인데 이걸 기계에게 넘겨줄 이유가 없다. 작업하기 귀찮은 배경에는 종종 사용할테지만, 이것도 에셋을 더 많이 쓰지 않을까 싶긴 하다.
연말동안은 그림만 그려보도록 하자. 일단 밥을 먹고…
시작
12.25
색칠 공부 중. 때늦은 케데헌 루미
12.26
그리다가 질린 루미와 (그리고 올리고 나서 발견한 요즘은 AI도 실수하지 않는다는 손가락 6개와)
토머먼트는 Parsec을 통해 진행이 됐지만, 아무래도 외부 프로그램을 사용한 네트워크 대전이라 그렇게 핑이 좋지 못했을 걸로 예상이 됩니다. 어려운 환경(?)속에도 토너먼트를 진행하느라 고생한 참여자분 모두에게 감사하다는 말을 전합니다.더불어 최종 승자이신 Elis01님께 큰 박수를 보냅니다. 아래는 경기 영상입니다!
현재 배틀퀸은 GGPO를 통한 자체 네트워크 통신을 개발 중에 있습니다. 전 네트워크 코딩을 못해서 지인의 도움을 받고 있어요. 다음 번이 있다면 조금이나마 나은 환경으로 게임을 할 수 있다면 좋겠네요!
비네트의 설정은 고민이 많다. 처음엔 숲속의 카페로 설정을 했다가, 그 다음엔 해변가로 바꿨다가… 결국 호수가 정도가 적절하다. 싶어서 그 정도에서 타협을 보려다가…카페란 설정이 적절한가? 싶다가… 고민이 많다. 캐릭터 자체가 인스타감성 충만한 백치이기 때문에 이렇게 설정하긴 했는데, 또 너무 현대적이면 안될 것 같고…
일단 제미니에게 물어서 이미지를 뽑아보았다.
괜찮기는 한데, 음.. 뭐 좋아. 하지만 게임에 사용하려면 나무를 하나하나 떼어서 리소스화 해야 한다. 쓸만할까. 나무를 하나만 그려줘.
아 옘ㅂ.. 이모지 만들고 싶은 게 아니고 리소스만들거야. 그리고 배경 투명도 아니잖아!
몇 번 리젝을 한 끝에 얻어낸 결과
쓸만은 한데, 원하는 나무 질감이 아니다. 이걸로 삽질할 바엔 그냥 그리는 게 속시원할 것 같다.
그런데 이런 재미니에게 의외의 재능이 있었는데
뜻밖에 텍스처를 되게 잘그려준다. 바닥 칠할 때 쓸만할 것 같다. 어쨌거나 AI는 재밌는 건 다 지가 해서 별로다. 텍스처나 원경같은 재미없는 것만 시켜야지…
이런 건 에셋써서 뽑으면 되는데, 너무 디테일하다… 제미니야. 이걸 좀 단순화시켜줄래?
옘ㅂ..ㅇㄴ롱ㄶㄹㅇㄴㅁ GPT야! 도와줘!
더 이상 진행했다간 홧병이 날 것 같으니 그만하자.
일단 호수가 카페설정은 유지하자. 건물이 한채 있지만 화려하면 안된다. 마침 에이콘에서 적당한 걸 발견했다.
재야의 고수가 살 것만 같은 집이다!
집을 기준으로 일단 러프 스케치
그리고 에셋스케치
오브젝트를 대충 배치하고 또 에셋스케치
12.11
제미니를 잘 쓰려면 어떻게 해야 할까? 를 고민… 전체씬을 렌더하는 건 예쁘긴 해도, 이미지를 조각을 내야 하는 입장에선 게임에 사용할 수가 없다. 여러모로 써본 결과로는 나노바나나가 아무리 좋다해도 결국 기존의 이미지 확산형 AI(스테이블 디퓨전)방식에서 크게 벗어나지 못했다는 느낌이 든다. 그냥 뎁스, 케니등의 스크립트가 일반인도 배우지 않고 사용할 수 있도록 쉽게 적용될 뿐. 이게 뭐가 문제냐면 게임 리소스로 사용하기 위해선 현실에 없는 것처럼 원근이 먹지 않거나 거의 없도록 렌더링해야 한다. 또한 스크롤과 애니를 위해 ‘부분’만 떼어야 하고, 완전한 사이드뷰 렌더링이 되어야 한다.
하지만 그 어떤 것도 알아먹지 못했다.
그렇다면 이 이미지를 로뎅에게 부탁해 3D로 만든 다음 사이드뷰로 캡처하는 방법을 생각해볼 수 있겠다. 하지만 로뎅은 지점토처럼 모델링을 해준다…그리고 그걸 수정할 바에야 손수 처음부터 만드는 편이 낫다.
결국 기존의 방식보다 나은 대안을 찾지 못했다. 하지만 하나 건진 건 있다. 원근을 피할 수 없다면 모든 사물을 탁자 위에 올려놓고 생성해달라고 부탁하면 된다.
이러면 이미지를 비교적 눈높이에 맞춰준다. 하지만 여전히 원근이 적용된 상태이기 때문에, 화분이나 풀같은 작은 소품만 가능하다. 소품을 모델링하거나 찾는 수고를 생각하면 상당히 쓸만할 지도 모른다.
제미니로 이것저것 시도하다가 도무지 견적이 안나와서 이것저것 찾아보다가 괜찮아 보이는 걸 발견했다.
가장 키가 작은 오로라는 잡히기 작업에서 키를 맞추어주어야 하기 때문에 일이 많다. 그래도 닐리보다야…
다른 게임들은 이런 잡히기 모션들을 공유해 쓰는 것처럼 보이던데, 어떻게 한 거지..
11.25
잡히기 작업이 생각보다 길고 코드 이슈가 없다. 흐음. 그렇다면 네트워크 작업을 위해 11월말까지 코드를 넘겨주는 편이 좋으니 코드작업을 선행하는 편이 좋겠다.
스턴은 버튼을 마구 누르면 빨리 풀 수 있다. 이는 원래 적용되어 있던 것이지만, 애니메이션의 속도를 조절해 명시적으로 알 수 있도록 변경
타격잡기의 경우 로직을 조금 변경했다. 이 때의 애니메이션 속도는 상대의 버튼연타 유무에 따라 느려질 수도 빨라질 수도 있다. 내가 더 많이 누르면 애니메이션 속도가 빨라지고, 상대가 더 많이 연타하면 느려지는 식. 여기서 일정 수준이하로 느려지게 된다면 좀 더 일찍 타격에서 풀려나게 된다.
프리오리가 연타했을 경우
Nate님의 의견대로 프리오리의 연계기를 하단으로 변경. 첫번째 공격은 OverHead, 두번째 공격은 Down이다. 즉, 첫번째는 서서, 두번째는 앉아서 막아야 한다. 덕분에 꽤 까다로운 조합이 됐다.
그 외의 수정사항
한여름 스킬들 상향
스턴 시 트레일이 튀는 현상 수정
KO시 줌블러 약화
작업보드에 적어둔 내용들은 비주얼과 관련된 내용을 제외하곤 모두 끝났다. 하지만 이것이 끝이 아니다. 이제 오래 전에 온 리포트를 점검할 시간이다.
앵커가 잡힌 UI라면 일반 position보단 AnchoredPosition의 부호를 반전시키는 쪽이 제어하기 더 쉽다는 사실을 깨달았다! 내친 김에 이것도 손을 보자.
키 바인딩 작업 중 적어놓을 것.
XBox360패드
Back – button6
Start – button7
스틱형 장치에선 Start가 작은 버튼이다. 7번버튼이 6으로 작동한다.
리팩토링한 코드에서도 조이스틱이 잘 작동하긴 하는데, 자료를 좀 찾아보니 InputSystem이란 게 새로 나왔다고 한다. 지금 와서 손보기엔 좀 늦은 것 같고 다음에 자료를 찾던가 말던가 하자.
키바인딩을 처리하기 위해 키입력을 변경하는 시스템과, 이를 저장하는 코드를 제작…하기 위해 또 한번 대대적인 리팩토링. 이번 리팩토링 중 안 사실이 있는데, InputManager의 Vertical은 위아래가 거꾸로 입력된다. 명백한 버그같은데 발견이 늦어져서 대처를 못한 느낌이다. 이게 왜 버그라고 생각되냐면 버튼형 스틱은 위아래가 제대로 입력되기 때문이다. 원인을 찾느라 한참걸렸는데 새 프로젝트를 만들어 확인한 결과 기본값이 위아래 인버스가 체크되어 있다. 에라이…. 어쨌거나 키바인딩 시스템의 기본은 완료했다. 에디트 버튼을 누르고 순차적으로 사용할 키를 누르면 된다.
핵심적인 구현은 끝났다. 이제 예외처리를 하고, UI를 붙여야 한다. 현재값을 기본값으로 돌리는 기능도 필요하고, 입력 중간에 취소할 수 있는 기능도 있어야 한다. back버튼을 누르면 게임을 종료 처리(최종 버전에서는 타이틀로 돌아감)하는 기능도 넣을 것이다
11.15
지스타 구경으로 인해 이틀간 부재였다. 11월이지만 부산은 따뜻했다. 그런데 서울 올라와 보니 서울도 따뜻했다. 그냥 따뜻한 시기같다. 다음 주부터 다시 추워진다고 한다.
키 바인딩의 핵심구현은 끝났지만, 예외처리와 마무리를 해주어야 한다. 신경쓸 게 많으니 목록을 적어두고 하나하나 처리해보자.
지정이 모두 끝나면 0.8초간 화면을 유지하고 있다가 화면이 닫힘
동시에 지정이 끝나면 키입력을 더 이상 받지 못하도록
키를 기본값으로 초기화하는 기능
스틱은 위로, 키보드는 F3, F4
지정할 수 있는 키에서 예외키를 제외
키보드 : 펑션, ctrl, alt, window키등
조이스틱 : 0~5번버튼까지만.
한 번 지정한 키를 다시 지정하지 못하도록 중복검사
조이스틱 자동감지
모두 처리했으나, 자동감지는 조금 위험하다. 행여나 게임기에서 키보드가 잡힌다면 달리 바꿀 방법이 없다. 따라서 이건 기기체크를 해서 스팀덱같은 게임기에선 1,2P를 모두 조이스틱으로 기본설정하는 편이 합리적으로 보인다. 다만 이건 아주 먼 이야기이므로 지금작업에서는 제외하자.
이제 UI가 필요하다. 키 설정은 조이스틱부와 키보드로 나뉜다.
11.16
작은 창에 사용되는 글씨가 꽤 굵게 느껴져서 얇은 글씨가 있으면 좋겠다고 생각했다. 어차피 앞으로 대사창이나 작은 UI에 사용해야 하므로, 미리 폰트를 만들어두는 편이 좋겠다.
Window – TextMeshPro – FontAssetCreator
이런 건 자주 안쓰는 기능이라 미리 세팅값을 저장해두는 편이 좋다. 특히나 한글폰트의 커스텀 레인지는 필요할 때마다 찾으니 박제해 두자.
32-126,44032-55203,12593-12643,8200-9900
윗쪽의 얇은 글씨가 새로 만든 폰트이다. SDF의 특성인가? 포토샵보다 한단계 굵게 나오므로, 보이는 것보다 한단계 낮은 얇기로 폰트를 만드는 편이 좋다.
폰트를 바꾸는 김에 이제 ‘우리(US)’가 아닌 진짜 VS로 변경.
11.17
비주얼을 붙이기 위해 셰이더를 짜고… 붙이고 연출하고…이것도 생각보다 꽤 걸리는 작업이었다. 총5벌의 키맵을 저장한다.
혼자 키보드를 쓸 때
둘이 키보드를 쓸때 2벌
조이스틱 2벌
싱글플레이는 키배열을 편하게 하기 위해 별도로 취급한다. 이걸 위해 구조를 다르게 짜고 예외를 처리하느라 꽤 오래 걸렸다. 힘들 거라 생각했고, 예상만큼 힘들었다.
자, 이제 다음은 뭐지?
11.18
닐리의 추가스킬, ↑A or B (BroomAttack)의 러프한 구현.
상승 후 A를 누르면 직선으로 날아가고
B를 누르면 하강한다.
방향 전환 딜레이가 길어서 콤보용으로는 못쓴다… 싶었는데 운좋으면 연결이 되기도 하네?!
11.20
이펙트를 만들던 도중 ‘이 셰이더를 어디에 썼더라…’싶어서 검색하는 기능을 찾으려 했지만 유니티에는 그런 기능이 없다. 이런 점은 레퍼런스 참조를 직관적으로 보여주는 언리얼이 좋다. 하지만 코파일럿에게 부탁하니 무려 툴을 만들어준다.
using UnityEngine;
using UnityEditor;
public class ShaderUsageFinderWindow : EditorWindow
{
Shader targetShader;
[MenuItem("Tools/Shader Usage Finder")]
public static void ShowWindow()
{
GetWindow<ShaderUsageFinderWindow>("Shader Usage Finder");
}
void OnGUI()
{
GUILayout.Label("🔍 셰이더 사용 머티리얼 찾기", EditorStyles.boldLabel);
targetShader = (Shader)EditorGUILayout.ObjectField("Target Shader", targetShader, typeof(Shader), false);
if (targetShader != null)
{
if (GUILayout.Button("사용 중인 머티리얼 찾기"))
{
FindShaderUsage(targetShader);
}
}
}
void FindShaderUsage(Shader shader)
{
string[] materialGuids = AssetDatabase.FindAssets("t:Material");
int count = 0;
foreach (string guid in materialGuids)
{
string path = AssetDatabase.GUIDToAssetPath(guid);
Material mat = AssetDatabase.LoadAssetAtPath<Material>(path);
if (mat != null && mat.shader == shader)
{
Debug.Log($"✅ 사용됨: {path}", mat);
count++;
}
}
if (count == 0)
{
Debug.LogWarning("해당 셰이더를 사용하는 머티리얼이 없습니다.");
}
else
{
Debug.Log($"총 {count}개의 머티리얼이 해당 셰이더를 사용 중입니다.");
}
}
}
AI를 뭘 쓰던 유니티와 관련된 질문은 정확도가 꽤 높은 편이다. 아마도 자료가 많아서 그런 것 같다. 어쨌거나 이를 바탕으로 불필요한 코드를 지운다.
이펙트까지 완성. 빗자루 공격은 중간에 2번까지 좌우 방향전환을 할 수 있다. 이걸 직선이동과 하강코스를 나누어 원하는대로 사용하려니 생각보다 꽤 힘들다. 숙련이 좀 필요한 기술이 되지 않을까.
스샷을 찍고 나니 역방향 먼지가 방향이 틀렸다는 걸 깨달았다. 일단 이걸 수정하고…
일은 왜 할 수록 늘지…?
KO시의 줌블러에 가시 효과를 추가 중. 확실히 셰이더 그래프는 언리얼에 비해 갈 길이 멀다. 무엇보다 무선 노드부터 좀 지원했으면 좋겠다.
요게 기존
요게 수정. 어째 박력이 더 떨어져 보인다..?!
노드정리를 하고, 텍스처를 다듬고.. 뚜닥뚜닥. 최종형태. 셰이더 그래프가 익숙치 않다보니 생각보다 시간이 걸린다. 포스트프로세스 셰이더 작업은 몰아서 하는 편이 좋겠다.
도레미의 초필에 관한 가장 많은 요청은 KO시엔 납작한 상태를 유지해달라는 것이었다. 이걸 구현하려면 코드는 어려운 게 없는데 데이터를 수정해야 했다. 지금은 종이가 완전히 아래로 깔리기 전에 회복하는 걸 전제로 애니메이션을 제작했는데, 이를 완전히 바닥에 깔리도록 수정해야한다. 그런데 이 작업을 하던 도중, 그림자가 90도 돌아가 출력되고 있는 현상을 발견했다. 수정하지 않았다면 큰 버그를 놓칠 뻔 했다.
납작이 잘 안보이기 때문에 눈속임이 조금 필요하다. 때문에 세로스케일을 3배로 늘려찍는다. 위에서 보면 아래와 같은 그림이 된다.
그 외의 문제들을 해결
스트레스 수치가 스턴을 거칠 때마다 10씩 상승하도록 수정했다. TOD를 막기 위한 조치
잡기 후 좌우가 반대로 입력되는 현상을 수정
달래의 설풍 후 달려가기를 막음. 무한 [달려가기-약손-설풍] 방지용
그레텔의 벽점프가 정방향일 때 반대쪽으로 점프하지 않는 문제를 수정
…를 하다보니 새로운 문제들이 속속 추가되어서 다시 수정 중. 대부분 입력시스템 변경에 따른 사이드 이펙트이다.
잡기 시에 입력키에 따른 방향전환 삭제
이는 0.26버전에선 작동하다가 0.45에서 버그가 있어 작동이 되지 않고 있었는데, 고치고 나니 캐릭터의 위치가 바뀌는 것이 별로 마음에 들지 않아서 삭제
11.6
이제 도레미의 휠윈드는 사소한 장풍을 피할 수 있다. 어쩐지 그래야 할 것 같았다.
프리오리의 초필은 점프과정이 불필요한 것 같아서 삭제. 점프가 없으므로 커맨드도 ↓(모아서)↑B에서 ←(모아서)→B로 변경
그레텔은 또 너프. 워프공격의 딜레이를 5프레임(0.167초 정도) 늘렸다.
그레텔의 강발을 무한히 쓸 수 있다는 제보가 있었는데, 맙소사! 방어 코드에 심각한 결함이 있음을 발견했다. 처음 동작을 디자인할 때, 큰 데미지의 전체 모션길이는 20frm으로 설정했지만, 무방비로 맞을 수 있는 시간(safeTime)은 10frm으로 설정했다. 때문에 딜을 넣으려면 10frm내에 해결해야 한다. 이 시간을 넘기면 데미지 모션 중일지라도 방어를 할 수 있는데, 리팩토링을 하며 부호가 잘못 들어가 있었다. 때문에 실제로 데미지 액션 중엔 계속 처맞는 버그가 있었고, 이것이 대부분의 공격이 20frm이하인 그레텔을 탑티어로 만드는데 기여했을 것이다.
그래서 이를 수정. 이제 무한히 딜을 넣는 건 불가능하다.
그 외 오늘의 사소한 해결사항들
SlamDamage를 공중에서 맞을 경우, 바로 회복되는 문제를 해결
모든 초필 도입부는 무적시간 적용. 약손에 초필이 씹히는 경우가 없도록.
앉아있을 땐 가까워도 잡기가 적용되지 않도록 수정.
프리오리의 장풍은 맞으면 넘어지도록 수정
11.7
넘어졌을 때 빠르게 일어날 수 있도록 방향성을 추가. 위아래키로는 예전처럼 제자리에서, 좌우키는 각 방향으로 구른다. 무적판정시간은 기존의 구르기와 같으나 여기엔 원론적인 문제가 있었다.
기존의 구르기는 판정에 버그가 있었다. 이것은 디스코드의 리포트로부터 알게 된 것으로 오래도록 묵혀둔 문제였다. 그런데 오늘 코드를 살펴보니 그냥 충돌판정이 잘못되어 있었다.
캐릭터가 이동할 땐 이동과 공격, 2가지를 위한 충돌검사를 한다. 2가지의 충돌검사는 병렬로 이루어져야 한다. 구르기의 경우 이동판정은 무시하지만, 공격판정은 적용되어야 하기 때문. 그런데 이 공격판정 코드가 이동판정안에 있어 이동이 무시되면 공격도 무시되게 처리되어 있었다.
해결책은 쉽다. 그냥 이동판정의 블럭에서 공격판정코드를 빼어 밖으로 배치하면 된다.
구르기의 무적판정은 8프레임이다. 8/30 = 0.267초 정도 된다.
11.8
배경 선택 기능을 위해 페이즈를 나눠 입력기능을 분리하다가 주먹구구식으로 처리하던 입력 지연 코드를 리팩토링. 짧아지는 코드를 보는 것은 언제나 기분좋은 일이다.
배경 수동 선택 구현. 필수적인 단계는 아니다. 그냥 기존처럼 랜덤으로 선택이 되지만, 원하면 바꿀 수 있다.
그 외 사소한 수정 사항들
스킬바 위치를 약간 낮춤. 캐릭터의 발 끝을 조금 덜 가리도록.
11.9
‘앉아 막기’에는 빈틈이 있었다. 캐릭터가 서 있을 땐 앉는다는 동작을 거친 후에야 막기가 가능했는데, 이것이 1프레임이 걸린다. 1/60초. 이 시간동안 타격이 있을 경우 막기가 안된다. 굉장히 짧은 시간이지만, 어쨌거나 일어난다.
때문에 방어를 할 경우 앉기를 동시에 판단하도록 설계를 변경. 일단 테스트는 잘된다. 실제 테스트때할 때도 좋은 결과가 있기를.
아래는 소소한 수정사항들
히트 후 연계기 유효 시간을 줄였다. 이게 길다보니 이상하게 공격이 연결되는 경우가 종종 있어 그림이 좋지 않았다. 벨의 달리기처럼 의도적인 딜레이를 주는 경우는 예외.
작업보드에 쌓인 내용들은 내가 적은 것들이니 수정사항의 일부이다. 이번 버그 픽스엔 디스코드 채널에서 온 리포트를 함께 고려하여야 한다. 대체로 2~3일이면 끝났던 작업이지만, 이번 작업은 조금 더 길어질 것 같다.
도레미의 베팅은 OP라는 평가가 많았다. 실제로 상대가 스턴에 걸리면 리스크 없는 데미지 증폭이 가능해서 문제가 있긴 하다. 이제 베팅을 위해선 칩의 수만큼 비용을 지불해야 한다.
10.26
코드가 의도한 대로 동작하지 않을 땐 답답하지만, 코드를 안짰는데 의도한대로 잘 작동할 때도 당황스럽긴 마찬가지다. 이게 왜 되지…? 무섭다… 후에 반드시 문제를 일으킬 것이니, 찾아서 해결해야 한다.
동시타는 자동으로 처리되는 것이 아니다. 예외 처리에 속한다. 추가로 작업해주어야 한다.
오로라의 초필 판정은 다소 열악했었다. 범위를 늘리고 앞으로 조금 전진.
여름이의 초필성공 거리 이슈가 고구마줄기처럼 다양한 문제가 줄줄이 엮인 이슈였다.
10.27
기본 공격이 2타인 공격들은 2번째 히트가 맞지 않았을 경우 데미지 손해를 보는 편이다. 이는 기본공격력을 절반으로 나눠 1,2타에 배정하기 때문에, 둘 중 하나를 실패할 경우 실제로는 절반의 데미지밖에 들어가지 않는다.
이를 개편하느라 데미지 공식을 좀 손봤더니 일이 커졌다. 수정방안은 1,2타중 처음으로 먹히는 공격에 대해 80%의 데미지를 입히고, 2타는 40%의 데미지를 갖는다. 1타를 실패하고 2타를 맞혀도 80%의 데미지는 보장이 된다. 이렇게 되면 2타를 모두 맞출 경우, 1타 공격보다 좋은 성능을 갖게 되는데, 실제로는 콤보 보정이 들어가기 때문에 10%감쇄가 일어나 1.16배정도로 줄어든다. 여기에 도레미 베팅, 멜라의 영역, 캐릭터의 공격력 스케일등이 추가로 계산된다. 그레텔의 캐릭터 공격력은 타 캐릭터의 0.9배로서, 너프되었다. 대신 발이 빠른 캐릭터가 될 것이다.
그 외에 스트레스 수치가 데미지 감쇄의 영향을 받게 되는 등의 수정이 있었다. 이로서 어지간한 무한 스턴은 막을 수가 있다.
10.28
사실 [동시에 잡기]는 대충 처리되어 있었다. 지상에서 잡을 땐 서로 밀려나긴 했지만 이펙트나 딜레이등이 구체적으로 설정되어 있지 않았고(충돌처리 한켠에 기생하는 코드로만 존재했다.) 공중잡기의 경우 충돌판정루틴이 1P를 먼저 도니까, 1P가 무조건 이기도록 설계되어 있었다. 이런 경우 자체가 매우 희박하기 때문에 크게 신경을 쓰지 않은 것인데, 놀랍게도 실제 게임에선 생각보단 빈번히 발생해서 제대로 된 코드를 만들었다. 프레임 처리 비용이 조금 늘어나긴 했지만, 확실한 게 좋으므로 처리해 두자.
차징어택(가드캔슬)은 문제가 많았다. 공중공격에는 잘 맞지도 않고, 비쌌다. 게다가 공격범위는 캐릭터가 제각각이었다. 달래같은 경우 그냥 지상 공격에도 잘 반격이 안되던 문제가 있었다.
그래서 비용을 깎고, 범위를 늘렸다. 그에 맞게 게이지도 2분할->3분할로 바꿨다.소소하지만 이 기술은 게이지를 쓰는 것인데, SP가 차오르는 문제도 있었다. 분류상 슈퍼 어택이므로 게이지가 차오르지 않아야 정보에 혼란을 덜 준다.
Nate님의 의견을 듣고 WarpAir의 발동딜레이를 좀 더 길게 조절했다. 이로서 이 기술을 절명기의 막타로 사용하기는 힘들 것이다.
10.29
입력 코드를 리팩토링 중이다. 시작은 AI를 추가하기 위함이었다. 앉아서 빠르게 약공격을 하는 기능이 필요했는데 현재 구조로는 이를 처리하기 힘들었다. 어차피 AI를 추가하려면 언젠가 손을 보긴 해야 할 터였다.
짜다 보니 산만하다. 전형적인 스파게티 코드. 세월의 흔적이 느껴졌다. 입력 코드는 0.26배포를 마지막으로 건든 적이 없다. 당시는 실력도 부족했고 챗GPT도 없었다. 비트마스크 알고리즘같은 건 생각도 못했다. 이제야 좋은 선생님을 만나 여러 모로 배우고 있다. 코드 줄 수가 획기적으로 줄었다. 원래 실속이 없으면 말이 많다. 안정화되려면 며칠 더 걸릴 것이다.
11.1
KopBot님의 의견을 받아들여 대공기의 후딜레이를 0.1초 늘렸다. 0.45버전에도 딜레이가 있긴 있었는데 아무래도 좀 약했나보다.
벨의 대공기도 바로 넉백이 되도록 변경.
11.2
닐리의 초필은 빈틈이 많았다. 연속기로 사용하기는 여전히 힘들겠지만, 이전보다는 나을 것이다.
이즈 본거지 