https://factorio.com/blog/post/fff-277



GUI 진행률 업데이트


이것은 FFF-269 부터 이어지는 마지막 상태 보고서의 연장이야

놀랍게도, 0.17 릴리즈에서 가장 크게 지체되는 부분은 GUI 였어

난 우리가 협력해서 GUI를 만들때 생긴 함정들로부터 많은 것을 배웠다고 생각해.


우리가 GUI를 재 설계하는 방법:


1. 2~3명의 사람들이 특정 GUI에서 무엇이 변화 할 수 있는가에 대해 토론하기 시작해. 몇몇 사람들은 무작위로 토론에 참여했고 마찬가지로 현재 진행중인 토론에서 떠났어. 특정 아이디어를 버리려는 논쟁은 계속되고 또 계속되었어. 그리고 그 토론은 무언가에 의해 끝이 나더라


2. 일주일 후 사람들은 다시 그 주제에 대해 이야기 하기 시작했어. 그들 중 대부분은 잊어버렸거나 다른 사람과 토론하고 있었기 때문에, 모든 사람들이 이해할 수 있도록 변화한 정보들을 모아다가 몇가지 세부 사항들을 만들었지.


3. 마침내 우리들은 어떻게 해야 하는가에 대한 합의에 도달해


4. 우리는 또 일주일 후에 그것에 대해 무작위로 토론을 했어. 하지만 개개인마다 어떻게 해야 할 건지에 대해 완전히 다른 생각을 가지고 있었으며, 그것을 제대로 설명하지 않았어. 우리들은 그 문제를 다시 풀고 다시 토론해야 하는 것에 대해 약간 화가 나기 시작했어.


5. 누군가가 GUI를 구현하기 시작했지만, 우리가 토론할 때 서로 오해한 부분이 개발 도중에 나타나고, 결국 1단계로 다시 이동해서 반복해야 했었어.



GUI가 워낙에 많다보니, 여러 항목이 동시에 토론되고 작업되기 때문에 우리가 합의한 결과들이 우리 머리속에서 막 뒤섞이는 문제가 생긴거야.

운 좋게도 우리는 결국 이런 식으로는 더 진행이 되지 않는다는 것을 느꼈어

GUI 작업이 많이 남아있기도 해서, 우리는 진행 절차를 만들었어:


1. 첫번째, 일단 평범하게 GUI에 대해 토론하고, 모든 팀원들이 참여해 아이디어를 공유할수 있도록 함


2. Kovarex 와 Twinsen 은 사무실에 쓸쓸히 앉아 잠시 동안 (몇 시간이 될 수도 있음) 어떻게 해야 하는지에 대해 모든 찬반 양론을 정리하고 어느정도 합의를 도출함.


3. Twinsen은 GUI에 관한 상세한 UX 문서를 만들어 내, 중요한 부분은 그 작업 방식을 상세히 기술해서 나중에 오해하지 않도록 함.


4. Kovarex 와 Twinsen 은 UX 문서에 대해 다시 한 번 토론하고, 최종 변경에 둘 다 수긍할 때 까지 변경 사항을 계속 제안함.


5. Albert 와 Aleš 가 이 UX 문서를 기반으로 UI 모형을 제작함.


6. Kovarex 랑 Twinsen, 그리고 Albert 는 UI 모형을 확인하고 변경 해야 할 부분을 제안하거나 해서 그 모형을 완성함.


7. 누군가가 UX 문서와 UI 모형을 기반으로 GUI를 구현할 수 있도록 지정됨.


8. Kovarex는 구현이 제대로 되는지 검토하고, 몇가지 모순을 지적함. 이 단계에서 우리는 가능한 한 많은 GUI 스타일과 코드를 다른 GUI에도 적용 가능한지 확인함.


9. Kovarex와 Albert는 마지막 검토를 하고, 두 사람 모두 완전히 완료됬다고 생각될 때 까지 마지막 변경 사항을 수정함.



우리는 "UI 문서/UI 실물 모형"을 적극적으로 이용하는게 시간 절약에 큰 도움이 된다는 것을 확인했어.

그것은 우리가 소통 문제를 해결하는 데 도움이 될 뿐만 아니라, 그저 문서를 열고 우리가 확인한 부분을 볼 수 있고

또 우리가 중단했던 곳부터 바로 다시 시작할 수 있기 떄문에 마지막 결정을 기억하고 다시 제안할 필요가 없어진거지.


이 엄격한 파이프라인의 좋은 점은 우리가 현재 진행하는 작업에 대해 얼마나 진행됬는지 더 잘 알 수 있게 된 거야.

다음은 0.17에 제공하고자 하는 GUI의 진행률이야.




여전히 해야할 일이 많지만, GUI 레이아웃/타일 세트/표준이 점점 더 많이 완료되고 재사용됨에 따라 작업이 빨라지는것 같아.

결론은 1월에 0.17 테스트가 가능하다는 거지만 2월이 될 수도 있어




작은 세부 사항


작업이 더디게 진행되는 또 다른 이유 중 하나는, 우리가 최종 버전을 만들고 있기 때문에, 그것을 다시 시작할 시간이 없기 때문에, 우리가 무언가를 고려하기 전에 그것을 세련되게 느끼고 싶기 때문이야.


예를 들어 모든 설정 화면에는 '기본값으로 재설정' 버튼이 있어

첫 번째 논리적 단계는 일부 옵션이 기본값과 다를 경우에만 버튼을 활성화 하는 것이야

그리고 다음 논리적 단계는 사용자가 재설정 버튼을 누를 때, 어떤 설정이 변경되는지 알려주는 거지.

그래서 우리는 초기화 버튼에 마우스를 올려 뒀을 때 기본 설정이 아닌 것들을 강조하며

네가 그 버튼을 눌렀을 때 무엇이 바뀌는지에 대한 즉각적인 피드백을 얻을 수 있어.



게임 내부 화면이 더 중요하기 때문에 잘 사용되지 않는 GUI에서 너무 많은 시간을 소비하는게 좋은 생각이 아닌 것처럼 보일 수 있어 하지만 우리가 알고 있는 이러한 원리들이 GUI의 변경 사항을 디자인 할 때 유용하게 쓰일 수 있을거야



스케일링 문제와 솔루션


GUI 개편에 관한 많은 목표들 중 하나는 가능한 모든 UI 스케일 값에서 GUI 가 정확하게 보이도록 하는 거야

정답은 모든 비율을 동일하게 유지하는 것, 그래서 그건 작아지기만 하고, 이상하게 변형되지는 않아.

이것은 작업이 간단한 것으로 보일 수도 있지만 모든 GUI 값(크기, 위젯 위치, 내부 여백 등등)이 항상 정수 값을 기대할 순 없기 때문에 결국에는 모든 요소에 특정 길이가 있어야 해


양 옆에 두 개의 20 픽셀 간격을 가진 버튼 안에 1픽셀 너비의 틈이 있다고 생각해봐

그리고 스케일(크기)를 120%로 표시하는거야

그 버튼의 20픽셀 간격은 24픽셀 간격으로 확대되지만, 1 픽셀짜리 간격은 1픽셀 혹은 아마 2픽셀이 될 수도 있어

그러면 레이아웃의 비율이 변경되버리는거지


이 문제(및 기타 문제)를 해결하기 위해 우리는 "모듈"이라고 부르는 것을 사용하기로 했어

1모듈은 표준 스케일(100%)에서 4 픽셀이며 거의 모은 것이 모듈 (크기, 위젯 위치, 내부 여백)의 곱셈으로 처리해.

또한 가능한 스케일 값을 25%의 배수로 제한했어 (75% ~ 200%) 이것은 모듈마다 크기가 다를 수 있다는 것을 의미해. (75%에서 3픽셀이면 200%에는 8픽셀까지)

그러나 모든 요소의 비율은 동일하므로, 언제나 똑같은 모양으로 보일꺼야.



이것은 지금까지 꽤 잘 작동하지만, 0.17에 또 다른 문제를 가져오게 되

누가 알아차렸는지 모르겠지만, 항목 슬롯(재고/로직 필터, 제작 슬롯 등)은 의도적으로 다른 UI 요소보다 작게 조정되었어. 그 이유는 우리가 모든 항목/유체/레시피들 - 32x32 크기의 아이콘을 더 키워버리면 보기에 좋지 않기 때문이야


그러나 이 0.17을 위해 이 특별 규칙을 폐지해야 했기 때문에 32x32 아이콘(항목 285개, 신호27개 액체 등)을 64x64 해상도로 만들어서, 모듈에 따라 지원되는 모든 UI 척도가 멋있게 보이도록 해야해

3D 모델 아이콘을 렌더링 해야하기 이것은 꽤 많은 작업이 될 것 같지만, 어쨋든 우리는 그걸 언젠가는 손 봤어야 했었어.
우리는 실험 단계동안 고해상도 아이콘을 0.17에 추가할 계획이야.



절차적 웨이브 방어(Procedural Wave defense)

우리는 몇 년 동안 게임에서 웨이브 방어 시나리오를 사용했고, 그 동안 많은 피드백을 수집했어.
내가 결정한 한 가지 문제는 고정 된 맵으로 인해 시나리오가 실제로 재생성(replayability)이 부족하다는 거야
지도는 변하지 않기 때문에 너희들이 블루프린드와 전술을 쓸 때가 되면 반복되는 웨이브는 매우 지루할꺼야.

최근의 변화와 TOGoS의 위대한 작업을 통해, 절차 맵 생성(procedural map generation)이 매우 잘 진행되고 있으며, 주어진 설정에 대해 매우 신뢰할 수 있는 결과를 보여줬어.
이것은 나에게 웨이브 방어 시나리오를 실행할 때마다 언제나 새로운 맵를 사용하게 하는 것이 가능할 지도 모른다는 아이디어를 줬어
몇가지 사전 설정값을 실험 해 봤는데, 실제로 잘 작동한거라고 생각해

하지만 나는 약간 망설여졌어, 손으로 만든 맞춤 지도와 무작위로 생선된 세계 사이엔 몇가지 장점과 단점이 있었어.


맞춤형 맵의 장점

1. 지도는 더 나은 과정을 위해 특별히 설계되고 수정될 수 있고, 나는 바이터들이 지도를 통해 움직이는 방법을 시험하고, 반복할 수 있고, 나무와 자원의 배치를 조정하고, 난이도를 조정하는 것 등을 할 수 있어

2. 우리는 지도 제작 엔진이 시나리오를 변경하는 것을 걱정 할 필요가 없어

3. 모든 플레이어가 같은 과정을 거치기 때문에 사람들은 지도에 좀 더 구체적인 조언, 디자인, 전략을 공유할 수 있어.


절차적 맵의 장점

1. 시나리오의 재생 가능성이 훨씬 더 커져

2. 지도 데이터, 타일, 엔티티 등을 최신 버젼으로 마이그레이션 하는 것에 대해 걱정할 필요가 없어

3. 지도 생성에 대한 모든 개선 사항은 시나리오에 반영될 거야

4. 우리는 다른 사람들의 블루프린트를 사용해서 시나리오를 만들 수 없어

5. 우리는 경험을 원하는 사람들을 위해 몇 가지 구성 옵션을 추가할 수 있어

6. 승리/실패 후에도 서버를 계속 운영할 수 있도록 지원을 추가하는 것이 쉬워


그래서 나는 절차가 효과가 있는지 테스트하기 위해 지금 변경 작업을 하고 있어. 시나리오 스크립트의 대부분이 그대로 유지되는 한 그렇게 오래 걸리지는 않을 꺼야.
나는 커뮤니티의 피드백과 생각을 묻고 시퍼 "여러분 중 많은 분들이 웨이브 방어를 해 본 적이 있는가? 랜덤맵이 더 재미있을 것 같나? 매번 지도가 다르다면 더 많이 플레이 할 수 있나?

항상 그럿듯이, 우리 포럼에서 어떻게 생각하는지 알려줘


===요약===

1. GUI 개편을 진행하는데 내부에서 병신짓을 좀 많이 함

2. 그래서 새로운 프로세스를 도입, kovarex 형 힘내여

3. 우린 이만큼 진행 됬고 열심히 할 건데 잘하면 0.17은 2월이 될 수도 있어

4. 사실 우리가 늦어지는건 세련됨을 위해서야.

5. GUI 모듈을 도입 75%부터 200%까지 25%단위로 UI크기 조정 가능

6. 제작 창의 아이콘 크기 업스케일링? 리메이크? 어쨋든 32x32 에서 64x64로 변경

7. "시나리오" > "웨이브 방어" 개편, 고정된 맵을 맵을 랜덤맵으로 바꾸려는듯

8. 매번 랜덤요소가 있고 블루프린트를 못 쓰니 웨이브 방어 개편되면 팩갤럼들 모여서 하면 재밌을듯