https://store.steampowered.com/news/app/1366540/view/5311472123811585119?l=koreana
개발 로그: 전투 시스템
안녕 엔지니어!
TGS 2022에서 Dyson Sphere Program: Rise of the Dark Fog의 쇼케이스 이후 몇 달 동안 우리는 플레이어들로부터 많은 격려와 지원을 받았습니다. 이것은 우리 팀이 전투 관련 콘텐츠 개발에 더 많은 노력을 기울이도록 큰 동기를 부여했습니다. 현재 작업 중인 비주얼을 살펴보겠습니다.
![69708d91e4b0784b31d534430c9143e4a7f9b254.jpg]()
![098a1bcb3679ddb2b07c0d9d6f2d2c44e93dcce6.jpg]()
![4c5e484b1b4e25c25a5309cf79359d59f6bb5238.jpg]()
![341add2166d8815933824d360bcb1c7739a4a95e.jpg]()
전투 시스템 개발 중에 기존 게임 플레이 시스템의 일부 최적화도 도입되었습니다. 새로운 유통 물류 시스템, 더욱 발전된 화학 플랜트, 보관이 가능한 스플리터, 더욱 편리한 컨베이어 벨트 도구 등…
팀 제작 효율성을 극대화하기 위해 작업 흐름을 The Rise of the Dark Fog(전투 시스템) 분기와 기존 콘텐츠 업데이트의 두 분기로 분할했습니다. 이 두 가지 작업을 동시에 수행하고 전투 시스템 정보를 기밀로 유지하기 위해서입니다. 그러나 양측의 작업이 항상 동기화되도록 하려면 Update Branch의 변경 사항을 Combat Branch로 수시로 병합해야 합니다.
![21403e75ebeced1efcd60b9e4b53c09932b17db2.jpg]()
그러나 여기에 나쁜 소식도 있습니다. 전투 시스템 분기가 별도로 실행된 해 동안 해당 콘텐츠가 기본 분기와 충돌하여 많은 코드 및 리소스 문제가 발생했습니다. 우리는 매번 이러한 문제를 해결하기 위해 엄청난 양의 추가 노력과 시간을 투자해야 했고 때로는 전투 시스템 개발에서 우리를 많이 산만하게 하는 공통 리소스 및 저수준 코드 수정을 의도적으로 피해야 했습니다. 전투 시스템 개발의 속도를 높이기 위해 전투 계통에 총력을 기울이기로 결정했습니다. 다시 말해서,
이를 통해 전투 시스템 코드와 일부 하위 수준 코드를 리팩터링할 수 있습니다. 풍부한 콘텐츠를 배치로 추가한 후 게임의 성능 병목 현상이 분명해졌습니다. 제 오래된 PC(GTX660Ti)는 10 또는 9FPS에서 간신히 실행될 수 있었습니다. 이를 확인하고 프레임 속도에 부담을 주는 최적화할 수 없고 융통성 없는 일부 코드를 점검하기로 결정했습니다. 우리는 한 번 해봤으므로 경험이 있었고 더 나은 솔루션을 찾을 의향이 있습니다. 어려운 과정이지만 목표를 달성하기로 결정했습니다. 전투 시스템이 구현된 후 Dyson Sphere 프로그램이 원활하게 수행되어야 합니다.
![0d9f9192c51bba0ebe0c735e67425b742a4f56ee.png]()
"디자이너는 요구 사항을 만들고 프로그래머는 요구 사항을 구현합니다"라는 말이 우리에게 적합하지 않습니다. 성능 문제가 발생했을 때 디자이너가 "상관없어요. 프로그래머가 해결해야 할 의무입니다."라고 말하면 도움이 되지 않습니다. 또는 "잊어버려, 기술은 아직 거기에 있지 않다." 우리는 두 부서가 함께 생각하고 협력해야 한다고 믿습니다. 그들의 일은 결코 분리되지 않았습니다.
Dyson Sphere 프로그램에서 플레이어의 공장 개체는 수백만 규모에 쉽게 도달할 수 있으므로 성능이 확실히 우선 순위입니다. 게임의 궁극적인 성능 한계는 디자인 단계에서 결정되며, 그 한계에 도달하는 것은 프로그래머의 기술력에 달려 있습니다. 그렇기 때문에 설계 단계에서 가능한 한 많은 가능성을 창출하기 위해 남은 성능 공간을 현명하게 사용하도록 설계자에게 요청합니다. 게임 플레이 검증을 거친 후 디자인 목표를 세웠습니다. 아래 이미지는 플레이어와 Dark Fog 간의 가상 전투력 비교를 보여줍니다.
![e44756a6de69decd7a4b64457fdf5b2026d35c8f.jpg]()
Dark Fog가 플레이어의 개발 공간(및 CPU 컴퓨팅 리소스)을 차지하면 플레이어는 그것을 파괴하고 싶어할 것입니다. 따라서 Dark Fog의 활동과 플레이어의 공장은 거의 반비례하며, 이를 사용하여 다음과 같은 성능 최적화 목표를 설정했습니다
![c8313cf42cb6279050a619b3301ad2fcf23e765e.png]()
. 안개 하이브는 큰 부담이 될 것입니다. 그리고 이 시점에서 Dark Fog의 전체 생산 시스템(우주 둥지, 행성 기지)은 플레이어에 둔감하므로 플레이어 공장만큼 자주 업데이트할 필요가 없습니다.
![acb06fe8ffc30e4052678a6c3d6d9f078a1ee451.jpg]()
고려한 후 Dark Fog Nest의 업데이트 로직을 60 로직 프레임마다 한 번으로 설정하고 모든 Nest 업데이트는 한 프레임에서 너무 많은 로직을 업데이트하지 않도록 가능한 한 각 프레임에 고르게 분산됩니다. 예를 들어 플레이어가 60성 시작 빌드를 선택하면 각 논리 프레임이 한 행성계의 Dark Fog 둥지를 차례로 업데이트합니다. 다음은 몇 가지 간단한 로드 밸런싱 코드입니다.
![c70ef44c7c8c9e32ee6eab6f4e8988742cb85a79.png]()
위의 단순해 보이는 아이디어는 다른 문제를 야기합니다. Dark Fog가 60프레임마다 한 번씩 업데이트된다면 우주에 있는 다른 비건물 전투 유닛과 수송 유닛은 어떻게 될까요? Dark Fog 지상 건물의 애니메이션을 혼합하는 방법은 무엇입니까?
![8822abb0f720206646df61adde47eb8b1e61c877.png]()
![a561bf57a56be43dcc4b569df3b63ddca5456e9d.gif]()
이 경우 GPU를 사용하여 일부 계산을 처리하는 BIG MOVE를 수행해야 합니다.
Logistics Drones의 최적화와 마찬가지로 CPU는 항공기가 화물을 내리기 위해 A지점(xA, yA, zA)에서 B지점(xB, yB, zB)으로 이동하는 곡선을 계산할 필요가 없습니다. 몸체 회전, 상승 및 하강, 꼬리 불꽃 효과가 어떻게 변경되는지 등. 모든 CPU는 "t" 값을 더하기만 하면 됩니다.
![633a4423b3fc672a4d7ea259beedcd178cb6f7ab.png]()
그리고 GPU는 보다 복잡한 수학적 연산을 처리합니다.
![8e83896a214bfd05a7e1c585c705079c5eaaee87.png]()
![fd06bf2b5f1472cc02f4eb14365c20f25762c9e2.png]()
다음은 많은 수의 수송 항공기를 저장한 성능 테스트입니다. 관심이 있으시면 언제든지 다운로드하여 사용해보세요:
MilkyWay
Google 드라이브 다운로드
![38e8fed60ed31643e0ea24e4418578057aa646ec.png]()
![89dacba85f6cb7d8f8980c086cb5ee36260a5542.png]()
99%의 시간 동안 적 전투 유닛이 방황하는 행동을 하기 때문에 이동 경로를 나타내는 파라메트릭 방정식을 사용하여 궤적을 더 계산하기 쉽게 설계할 수 있습니다. 이렇게 하면 Logistics Drone과 마찬가지로 대부분의 방황하는 적들을 최적화할 수 있습니다.
다음으로 공격 모드에 들어가고 나올 때 GPU와 CPU 계산 사이를 원활하게 전환하고 방랑으로 돌아갈 계획입니다.
그러나 이 솔루션은 이러한 적을 공격할 때 자유 표적 발사체에 적합한 공격 대상을 찾는 것과 같은 몇 가지 문제도 제기합니다. 이것을 먼저 처리하고 다음에 오는 모든 것을 처리하십시오. 복잡성은 제거할 수 없으며 성능 최적화는 런타임 복잡성을 코드 복잡성으로 전환하는 것입니다.
그 외에도 최고 난이도로 새 게임을 시작할 때 64개의 행성계에 있는 어두운 안개 건물의 총 수가 200k(건물만)에 도달한다는 사실을 알게 되었습니다. 로직 오버헤드를 3ms 미만으로 줄였음에도 불구하고 Dark Fog는 여전히 약 50M의 세이브 데이터를 차지합니다.
![55dfe88694c8203d1e0c55a839edd2430ad7c6ce.png]()
새로 생성된 세이브의 경우 플레이어는 다른 행성계에서 다크 포그의 존재를 감지할 수 없으므로 이러한 대규모 세이브를 받아들이기가 어렵습니다. 한편, 우리는 멀리 있든 없든, Dark Fog는 특정 규칙에 따라 발전해야 하며 이러한 규칙의 결정론은 나중에 점점 더 중요해질 것입니다. 게임에서 "실제 우주"의 일관된 실행 논리와 마찬가지로 행성을 떠난다고 해서 행성에 있는 공장이 논리적 결정론을 잃지는 않습니다.
![c6a4ba519eaf980c60747686163306a147ac6176.png]()
따라서 다크 포그 성장의 논리와 데이터를 여러 결정적 LOD(세부 수준)로 분할하고 수준 간 전환 규칙을 지정해야 합니다.
그리고 안정성 확보를 위해 둥지 성장 프로세스를 재설계하여 고정된 나이와 난수 시드를 기반으로 특정 둥지 성장 맵을 간섭 없이 실시간으로 베이크할 수 있도록 했습니다. 이렇게 하면 각각의 네스트에 최대 2000개의 건물과 유닛이 포함되어 있어도 최소한 조우하지 않은 먼 네스트를 "나이", "랜덤 시드" 등과 같은 여러 헤더 데이터로 변환하고 중계국과 시드를 생성할 수 있습니다. 동시에 만나지 않은 Dark Fog가 여전히 바깥쪽으로 확장될 수 있도록 합니다.
![aa11419a2a68aec30203067b8e560037e55204df.png]()
![b8075d9d095037248d78a9a658f33a81553e06d0.png]()
우리는 여전히 전투 시스템의 코드를 리팩토링하는 작업을 하고 있습니다. 기본적으로 위 이미지에 표시된 파란색 및 빨간색 상자의 LOD와 Dark Fog 둥지의 자체 복제 및 확장을 완료했습니다. 리팩토링을 마치면 전투의 더 복잡한 측면을 최적화하는 작업으로 넘어갈 것입니다.
모델링을 위해 각 건물의 파괴 효과와 모든 짙은 안개 건물의 LOD, 각 LOD의 애니메이션을 개선해야 합니다.
![82af6c6da9d7a89f2775acdaad90dbfd177acb09.gif]()
많은 렌더링이 필요한 일부 복잡한 효과의 경우 여전히 셰이더를 사용하여 시뮬레이션해야 합니다. 일반적인 예는 발사체의 적중 효과입니다.
![6e21495925266ea055fb32f1a5647d2e6876e49a.gif]()
엔진에서 제공하는 파티클 시스템을 직접 사용하면 많은 수의 효과 인스턴스를 지원할 수 없습니다. 이전 개발 로그에서 언급한 방법을 사용하고 각 입자 시스템을 이러한 적중 효과의 셰이더 기반 시뮬레이션으로 변환해야 합니다. 다음은 그 중 하나입니다.
![8eed38820b45b71ad29097c76932de8a3ef0f8ab.gif]()
![6cecd170640244992b8b36cfe1a06b84766f8b0c.png]()
이 개발 로그의 끝에서 다시 한 번 상기시켜 드리고 싶습니다.
![4e1bc182a4b7ba6e129d9c655f7d7153399e263b.png]()
이것이 개발 로그의 끝입니다.
그런데 반가운 소식이 있습니다. 프로듀서 부부의 아기가 지난 달에 태어났습니다! 현재 그들은 여전히 병원에 있으며 한 손에는 아기를 안고 있고 다른 한 손에는 Dyson Sphere 프로그램을 코딩하고 있습니다.
이전 개발 로그에 관심이 있으시면 여기에서 확인하십시오 !
TGS 2022에서 Dyson Sphere Program: Rise of the Dark Fog의 쇼케이스 이후 몇 달 동안 우리는 플레이어들로부터 많은 격려와 지원을 받았습니다. 이것은 우리 팀이 전투 관련 콘텐츠 개발에 더 많은 노력을 기울이도록 큰 동기를 부여했습니다. 현재 작업 중인 비주얼을 살펴보겠습니다.




전투 시스템 개발 중에 기존 게임 플레이 시스템의 일부 최적화도 도입되었습니다. 새로운 유통 물류 시스템, 더욱 발전된 화학 플랜트, 보관이 가능한 스플리터, 더욱 편리한 컨베이어 벨트 도구 등…
팀 제작 효율성을 극대화하기 위해 작업 흐름을 The Rise of the Dark Fog(전투 시스템) 분기와 기존 콘텐츠 업데이트의 두 분기로 분할했습니다. 이 두 가지 작업을 동시에 수행하고 전투 시스템 정보를 기밀로 유지하기 위해서입니다. 그러나 양측의 작업이 항상 동기화되도록 하려면 Update Branch의 변경 사항을 Combat Branch로 수시로 병합해야 합니다.

그러나 여기에 나쁜 소식도 있습니다. 전투 시스템 분기가 별도로 실행된 해 동안 해당 콘텐츠가 기본 분기와 충돌하여 많은 코드 및 리소스 문제가 발생했습니다. 우리는 매번 이러한 문제를 해결하기 위해 엄청난 양의 추가 노력과 시간을 투자해야 했고 때로는 전투 시스템 개발에서 우리를 많이 산만하게 하는 공통 리소스 및 저수준 코드 수정을 의도적으로 피해야 했습니다. 전투 시스템 개발의 속도를 높이기 위해 전투 계통에 총력을 기울이기로 결정했습니다. 다시 말해서,
여전히 기존 게임 콘텐츠를 디버깅하고 수정할 수 있지만 전투 모드가 시작되기 전에는 새로운 기능을 추가할 수 없습니다.
.이를 통해 전투 시스템 코드와 일부 하위 수준 코드를 리팩터링할 수 있습니다. 풍부한 콘텐츠를 배치로 추가한 후 게임의 성능 병목 현상이 분명해졌습니다. 제 오래된 PC(GTX660Ti)는 10 또는 9FPS에서 간신히 실행될 수 있었습니다. 이를 확인하고 프레임 속도에 부담을 주는 최적화할 수 없고 융통성 없는 일부 코드를 점검하기로 결정했습니다. 우리는 한 번 해봤으므로 경험이 있었고 더 나은 솔루션을 찾을 의향이 있습니다. 어려운 과정이지만 목표를 달성하기로 결정했습니다. 전투 시스템이 구현된 후 Dyson Sphere 프로그램이 원활하게 수행되어야 합니다.

(일부 하드웨어 업그레이드도 함)
"디자이너는 요구 사항을 만들고 프로그래머는 요구 사항을 구현합니다"라는 말이 우리에게 적합하지 않습니다. 성능 문제가 발생했을 때 디자이너가 "상관없어요. 프로그래머가 해결해야 할 의무입니다."라고 말하면 도움이 되지 않습니다. 또는 "잊어버려, 기술은 아직 거기에 있지 않다." 우리는 두 부서가 함께 생각하고 협력해야 한다고 믿습니다. 그들의 일은 결코 분리되지 않았습니다.
Dyson Sphere 프로그램에서 플레이어의 공장 개체는 수백만 규모에 쉽게 도달할 수 있으므로 성능이 확실히 우선 순위입니다. 게임의 궁극적인 성능 한계는 디자인 단계에서 결정되며, 그 한계에 도달하는 것은 프로그래머의 기술력에 달려 있습니다. 그렇기 때문에 설계 단계에서 가능한 한 많은 가능성을 창출하기 위해 남은 성능 공간을 현명하게 사용하도록 설계자에게 요청합니다. 게임 플레이 검증을 거친 후 디자인 목표를 세웠습니다. 아래 이미지는 플레이어와 Dark Fog 간의 가상 전투력 비교를 보여줍니다.

Dark Fog가 플레이어의 개발 공간(및 CPU 컴퓨팅 리소스)을 차지하면 플레이어는 그것을 파괴하고 싶어할 것입니다. 따라서 Dark Fog의 활동과 플레이어의 공장은 거의 반비례하며, 이를 사용하여 다음과 같은 성능 최적화 목표를 설정했습니다

. 안개 하이브는 큰 부담이 될 것입니다. 그리고 이 시점에서 Dark Fog의 전체 생산 시스템(우주 둥지, 행성 기지)은 플레이어에 둔감하므로 플레이어 공장만큼 자주 업데이트할 필요가 없습니다.

(Dark Fog의 확장 논리)
고려한 후 Dark Fog Nest의 업데이트 로직을 60 로직 프레임마다 한 번으로 설정하고 모든 Nest 업데이트는 한 프레임에서 너무 많은 로직을 업데이트하지 않도록 가능한 한 각 프레임에 고르게 분산됩니다. 예를 들어 플레이어가 60성 시작 빌드를 선택하면 각 논리 프레임이 한 행성계의 Dark Fog 둥지를 차례로 업데이트합니다. 다음은 몇 가지 간단한 로드 밸런싱 코드입니다.

위의 단순해 보이는 아이디어는 다른 문제를 야기합니다. Dark Fog가 60프레임마다 한 번씩 업데이트된다면 우주에 있는 다른 비건물 전투 유닛과 수송 유닛은 어떻게 될까요? Dark Fog 지상 건물의 애니메이션을 혼합하는 방법은 무엇입니까?

(우주 유닛의 함대 매트릭스)

(지상 유닛의 그룹 동작)
이 경우 GPU를 사용하여 일부 계산을 처리하는 BIG MOVE를 수행해야 합니다.
Logistics Drones의 최적화와 마찬가지로 CPU는 항공기가 화물을 내리기 위해 A지점(xA, yA, zA)에서 B지점(xB, yB, zB)으로 이동하는 곡선을 계산할 필요가 없습니다. 몸체 회전, 상승 및 하강, 꼬리 불꽃 효과가 어떻게 변경되는지 등. 모든 CPU는 "t" 값을 더하기만 하면 됩니다.

그리고 GPU는 보다 복잡한 수학적 연산을 처리합니다.


다음은 많은 수의 수송 항공기를 저장한 성능 테스트입니다. 관심이 있으시면 언제든지 다운로드하여 사용해보세요:
MilkyWay
Google 드라이브 다운로드

(21,000대의 물류드론 동시 업데이트)

99%의 시간 동안 적 전투 유닛이 방황하는 행동을 하기 때문에 이동 경로를 나타내는 파라메트릭 방정식을 사용하여 궤적을 더 계산하기 쉽게 설계할 수 있습니다. 이렇게 하면 Logistics Drone과 마찬가지로 대부분의 방황하는 적들을 최적화할 수 있습니다.
다음으로 공격 모드에 들어가고 나올 때 GPU와 CPU 계산 사이를 원활하게 전환하고 방랑으로 돌아갈 계획입니다.
그러나 이 솔루션은 이러한 적을 공격할 때 자유 표적 발사체에 적합한 공격 대상을 찾는 것과 같은 몇 가지 문제도 제기합니다. 이것을 먼저 처리하고 다음에 오는 모든 것을 처리하십시오. 복잡성은 제거할 수 없으며 성능 최적화는 런타임 복잡성을 코드 복잡성으로 전환하는 것입니다.
그 외에도 최고 난이도로 새 게임을 시작할 때 64개의 행성계에 있는 어두운 안개 건물의 총 수가 200k(건물만)에 도달한다는 사실을 알게 되었습니다. 로직 오버헤드를 3ms 미만으로 줄였음에도 불구하고 Dark Fog는 여전히 약 50M의 세이브 데이터를 차지합니다.

새로 생성된 세이브의 경우 플레이어는 다른 행성계에서 다크 포그의 존재를 감지할 수 없으므로 이러한 대규모 세이브를 받아들이기가 어렵습니다. 한편, 우리는 멀리 있든 없든, Dark Fog는 특정 규칙에 따라 발전해야 하며 이러한 규칙의 결정론은 나중에 점점 더 중요해질 것입니다. 게임에서 "실제 우주"의 일관된 실행 논리와 마찬가지로 행성을 떠난다고 해서 행성에 있는 공장이 논리적 결정론을 잃지는 않습니다.

따라서 다크 포그 성장의 논리와 데이터를 여러 결정적 LOD(세부 수준)로 분할하고 수준 간 전환 규칙을 지정해야 합니다.
그리고 안정성 확보를 위해 둥지 성장 프로세스를 재설계하여 고정된 나이와 난수 시드를 기반으로 특정 둥지 성장 맵을 간섭 없이 실시간으로 베이크할 수 있도록 했습니다. 이렇게 하면 각각의 네스트에 최대 2000개의 건물과 유닛이 포함되어 있어도 최소한 조우하지 않은 먼 네스트를 "나이", "랜덤 시드" 등과 같은 여러 헤더 데이터로 변환하고 중계국과 시드를 생성할 수 있습니다. 동시에 만나지 않은 Dark Fog가 여전히 바깥쪽으로 확장될 수 있도록 합니다.

(최소 데이터 형식)

(파란색/빨간색/노란색 상자의 콘텐츠는 세 가지 LOD를 나타냅니다.)
우리는 여전히 전투 시스템의 코드를 리팩토링하는 작업을 하고 있습니다. 기본적으로 위 이미지에 표시된 파란색 및 빨간색 상자의 LOD와 Dark Fog 둥지의 자체 복제 및 확장을 완료했습니다. 리팩토링을 마치면 전투의 더 복잡한 측면을 최적화하는 작업으로 넘어갈 것입니다.
모델링을 위해 각 건물의 파괴 효과와 모든 짙은 안개 건물의 LOD, 각 LOD의 애니메이션을 개선해야 합니다.

많은 렌더링이 필요한 일부 복잡한 효과의 경우 여전히 셰이더를 사용하여 시뮬레이션해야 합니다. 일반적인 예는 발사체의 적중 효과입니다.

엔진에서 제공하는 파티클 시스템을 직접 사용하면 많은 수의 효과 인스턴스를 지원할 수 없습니다. 이전 개발 로그에서 언급한 방법을 사용하고 각 입자 시스템을 이러한 적중 효과의 셰이더 기반 시뮬레이션으로 변환해야 합니다. 다음은 그 중 하나입니다.


(진정해, 이건 시험일 뿐이야)
이 개발 로그의 끝에서 다시 한 번 상기시켜 드리고 싶습니다.
건설 및 관리를 선호하는 플레이어는 Dark Fog를 완전히 끌 수 있습니다.
. 또한 플레이어는 Dark Fog에 대한 일부 난이도 매개변수를 세부적으로 조정할 수도 있습니다.
(위에 표시된 옵션은 현재 디자인을 기반으로 하며 최종 버전이 아닙니다.)
이것이 개발 로그의 끝입니다.
그런데 반가운 소식이 있습니다. 프로듀서 부부의 아기가 지난 달에 태어났습니다! 현재 그들은 여전히 병원에 있으며 한 손에는 아기를 안고 있고 다른 한 손에는 Dyson Sphere 프로그램을 코딩하고 있습니다.
이전 개발 로그에 관심이 있으시면 여기에서 확인하십시오 !
읽어 주셔서 감사합니다! 다음에 만나요!
걍 구글 페이지 번역 돌려서 긁어왔음
씨이이이이이이바아아아알 큰 거오냐아아아아아아
아니 ㅅㅂ 병신들아 다른 겜에서 당연하게 하는거 자랑질하겠다고 ppt 쳐만들 시간에 최적화를 더 해라 좀 진짜 개패버리고 싶네
진짜 년단위로 밀려있는 불만사항에 이슈에 산더미인데 얼굴에 철판깔고 다 씹어버리네
지금 보여주는게 최적화 열심히 하고 있다고 보여주는거잖아
웰케 화남
새로 나오는걸 최적화 할게 아니라 있는거 손가락 좀 까딱하면 확 개선되는걸 안하니까 열받지 렌더링 로직 씹창나있는거 개선하는게 글케 어려운 것도 아닌데 왜 안해주는거야 ㅅㅂ
그래도 저거 만들면서 개선 많이 했겠지 진짜 이번엔 기대해봐야지 에휴
코로나본섭인데 늦는건어쩔수없음
코로나 전부터 그랬으니까 열받지
여전히 5명 개발이려나 한명만 패도 개발 중단일거 같다 참아락ㅋㅋ
그렇게 까딱하면 확 개선되는 어려운것도 아닌일이 있으면 모드로 만들어서 배포해주면 개 후빨받을 수 있는거 아님?
초반에 이유 나오잖아 수정이 가능하긴 한데 전투랑 따로 진행하면 개발이 존나 오래걸려서 전투시스템에 비중 늘린다고 그리고 최적화도 열심히 하고 있다잖아 오히려 난 1년가까이 뭘 하는지 궁금했는데 알려줘서 고맙구만 왜그래
실크송 몇년동안 개발 소식도 안 들리는거 보면 개발일지 써주는건 진짜 고마운거임 얼엑인데 돈먹튀 하는거 아니라 존나 열심히 개발하는 중이고 늦는 이유와 뭘 개발하는지, 왜 전투 외에 업뎃이 거의 없는지도 알려주잖아
그냥 니 컴이 구린걸로 이해하면 되는거지? 혼자 열폭이여 찐다쉑
좆문가새끼
그렇게 쉬우면 니가 손가락 까닥해서 모드 만들어서 올리던가 ㅋㅋ 방구석 좆문가새끼야 ㅋㅋㅋ