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



안녕, 크리스마스와 새해 축제가 끝나고 비로소 우리 사무실은 차차 정상으로 돌아오고 있는거 같아



벨트 아이템 간격(Klonan)


1.0 업데이트에 대한 최종 마무리 작업중에는 게임의 튀는 부분을 정리하고 부드럽게 하는 작업 또한 포함되어 있어


다들 저번에 변화와 단순화에 대해 이야기했던 FFF-266을 기억할 거야

그 중 한가지가 바로 비우호적 개수였던 벨트 처리량(13.33)을 조정하는 것이었어


벨트 처리량은 2개의 변수로 이루어져 있어

벨트 위에서 얼마나 가까이 아이템이 붙어서 이동하는지 그리고 각 아이템 사이에 얼마나 많은 공간이 있는지에 의해 결정돼


운송벨트/빠른 운송 벨트/고속 운송 벨트 위에서 아이템들의 이동 속도는 각각 1틱 마다 1/2/3픽셀씩 움직여

왜냐하면 아이템들은 벨트 위에서 정수 픽셀 단위로만 이동할 수 있거든


즉, 운송 벨트의 처리량을 변경하는 유일한 방법은 물건과 물건 사이의 간격을 변경하는 방법 밖에는 없었어


현재 아이템간의 간격은 9 픽셀로 설정 되어 있어. 각 타일이 32픽셀이고 9가 32의 인수가 아니라는 사실은 처리량이 나누어 떨어지지 않는다는걸 의미해
또한 이 간격은 가끔 벨트가 아이템을 8개 옮길 때가 있고 때로는 6개만 옮길 때도 있어서
회로 네트워크를 사용해 벨트 내용을 읽을 때 카운트 시스템이 이상한 행동을 하게 돼:

(맨 바깥쪽 전구가 막 반짝반짝 거림)


이 시점에서 간격을 8 픽셀로 줄이는 건 매우 합리적이라고 생각해
이 간격은 32의 인수이며 초당 15.00개의 아이템을 운송할 수 있어
아래는 0.17버젼에 대응해 만들어진 결과물이야:

(벨트 간격이 미세하게 좁아짐)


8픽셀의 간격을 두면 벨트는 항상 정확하게 8개 아이템을 옮기기 때문에(각 벨트에 4개씩) 예를 들어 완전히 가득 찬 벨트를 회로로 읽으면 다음과 같이 신뢰할 수 있는 결과를 얻을 수 있어:



전체적인 변화로 봤을 때, 벨트는 평소보다 12.5%의 운송량을 더 제공하고, 공장 운영에 필요한 요구량을 계산하기 위한 멋진 정수를 제공하며 애매한 소숫점을 제거했어.


우리가 생각하고 있는 다음 업데이트 단계는 벨트 속도에 맞춰 용광로 레시피를 조정하는 건데, 그건 일단 나중으로 미뤄야 할 것 같아.




스크립트 렌더링(Bilka)



지난 몇 주 동안 나는 모드들이 게임 세계에서 기하학적 모양, 텍스트, 스프라이트를 쉽게 만들 수 있는 시스템을 연구하고 있었어.

많은 Modding 기능과 마찬가지로, 이 렌더링 시스템도 Modding 인터페이스를 수정해달라는 요청에 의해 만들어졌어


이 요청을 처음 받았을 때, 나는 단 한 명의 모드 작성자를 위해 저장과 렌더링을 처리할 수 있는 새로운 API를 추가하는 것이 실용적인지 의심했었어.


또 다른 모드 제작자는 한 플레이어에게만 보이는 텍스트를 만들기 위해 새로 추가된 방법을 발견했고, 더 많은 기능을 요청했어


이윽고 모드 제작자들과의 더 많은 논의를 통해, 그들은 오직 한 명의 플레이어에게만 일부 도우미 텍스트와 스프라이트를 보여줄 시스템을 찾고 있었다는게 분명해졌어.


당시 구현된 솔루션이 충분하지 않다는 것을 지적하기 위해 다른 모드 제작자들이 합류 했었고, 스크립트 렌더링 시스템 아이디어를 다시 구상했어. 나는 그 결과물을 구현하기 위해 작업을 시작했지.


당연히 우리는 먼저 이 시스템이 무엇을 할 수 있어야 하는지 모르는 상태에서 새로운 시스템을 개발하지는 않아

여기서 나는 팩토리오 디스코드 채널 #mod-make channel의 단골들에게 감사하고 싶어

그들은 기능을 제안하는데 큰 도움이 되었고 항상 그들 자신의 모드에서 렌더링 해 보고서 우리에게 대답해줬어.


또한 나는 포럼에서 새로운 인터페이스를 위해 현재 구형 인터페이스에 필요한 기능 요청 총 12건을 검토했어


이 정보들을 참조해서, 나는 실제로 구현하지 않고 그들이 원하는 특징들을 나열한 대략적인 설계 문서를 작성할 수 있었어.


스크립트 렌더링은 현재까지 8가지 서로 다른 오브젝트 유형을 보여주고 있어.

기본 모양은 선, 원, 직사각형, 곡선, 다각형이야.

또한 스프라이트, 조명 텍스트를 그릴 수도 있어

내 주요 목표 중 하나는 렌더링 객체의 모든 단일 속성을 만들고 변경 가능하도록 해서 시스템을 가능한 유연하게 만드려고 해

예를 들면 스프라이트를 파괴하거나 재생성하지 않고도 스프라이트의 크기나 방향을 변경 할 수 있다는 거야

이것은 이전의 모드 작업과는 달라서 그들은 원하는 방향이나 크기의 스프라이트를 가지고있는 많은 개체 프로토타입을 만들고, 스프라이트의 방향과 크기를 변경하기 위해 스프라이트를 변환할 수 윘어. 이러한 NTT 교체는 스크립트 렌더링으로 상당한 성능 비용을 절약할 수 있다고 생각해.


더욱이 랜더링한 개체는 LuaEntities보다 Lua에서 처리하기 쉬운 숫자 ID 로 식별할꺼야.

이 동적 시스템의 또다른 장점은 렌더링 시 데이터 스테이지에 의존하지 않는다는 거야.

언급된 NTT 프로토 타입 기술과는 달리 스크립트 렌더링에서는 프로토타입 데이터가 필요하지 않아

이것은 시나리오, 소위 '소프트 모드' 들이 이 새로운 시스템을 충분히 활용할 수 있을꺼야.


디자인 문서의 첫 번째 중요한 점은 어떤 대상이 개채 또는 위치가 될 수 있도록 허용하는 것이었어

이 부분은 NTT오프셋이 추가된 현재 게임 내에서 훌륭하게 작동되고 있어

물체는 실체에 '부착' 되거나 정적 위치에 배치될 수 있어, 같은 위치의 물체에 다수의 대상이 있을 경우 두 가지를 조합해도 돼

만약 도면 요소가 부착되었을 때 그 도면 요소가 파괴되면 랜더링 객체도 삭제될꺼야 이거 매우 유용한 작업인데,

왜냐하면 모드들이 단순히 모든 개체들 위에 일부 텍스트를 놓기를 원하는 경우, 그들은 그들의 개체가 플레이어에 의해 채굴되거나 바이터에 의해 먹힐 때 텍스트 삭제 처리를 할 필요가 없어지는 거지


두 번째 짚고 넘어가야할 점은 조건부 가시성(conditional visibility)이야

이것은 개채의 렌더링을 플레이어나 세력 단위로 제한 할 수 있다는 거야

이를 통해 구현을 촉발한 도우미 모델이 사용되기를 개인적으로 바라고 있어


이러한 조건부 가시성은 과거에 단순히 '구현되지 않을 것'으로 취급되었던 경우에도 요구되었어

이에 대한 주된 이유는 플레이어 화이트리스트를 기본 게임에 사용하는 많은 개체에 추가함으로써 예상되는 성능 효과였어.

이 성능 문제는 스크립트 렌더링을 사용할 때와 관련이 없어. 스크립트 렌더링은 기본 게임 렌더링과는 완전히 별개의 시스템이기 때문이야

만약 네가 모드를 사용하지 않는다면, 게임에 성능에 영향을 주지 않을꺼야.


새로운 렌더 시스템은 다른 모드 추가와 함께 흥미로운 모드 탐색 가능성을 열어주고 있어.
일반적으로 이 새로운 시스템은 모드들이 더이상 빔, 연기, 또는 렌더링을 위해 비행 문자와 같은 개체들을 남용하지 않아도 된다는 것을 의미하고 있어
이는 텍스트에 대한 사용자 정의 글꼴 또는 쉽게 변경할 수 있는 스프라이트의 방향과 같이 이전에는 고려할 수 없었단 새로운 렌더링 옵션의 많은 가능성을 열어줄 수 있어.
따라서 모드 개발자들은 모드에 어떤 렌더링 옵션이 유용한지 생각해 보고, 아직 구현되지 않았은 경우 포럼에서 해당 렌더링 옵션을 요청해주면 좋겠어

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


===요약===


1.벨트 간격을 9픽셀에서 8픽셀로 변경해 운송량을 13.33에서 15.00으로 바꿈.

2.벨트 운송량 12.5퍼센트 증가.

3.나중에 용광로 레시피 개편 가능성 언급.

2.스크립트 렌더링 기능 추가. 소프트 모더(시나리오 메이커)들을 비롯한 모드 제작자들에게 유용한 기능들이 추가된 듯