와!!!!!

1.0!!!!!!!!


https://www.factorio.com/blog/post/fff-349


1.0 계획 


FFF-321에서는 버전 1.0의 출시 날짜를 발표했습니다. 최근의 사건들을 고려하여 우리는 1.0 발매일을 수정하기로 결정했습니다. 우리가 목표로 하는 새로운 날짜는 2020년 8월 14일 금요일로 원래 날짜보다 5주 빠릅니다.


발매일을 변경하는 주된 이유는 사이버펑크 2077의 발매 때문입니다. 올해 1월, CD Projekt Red는 사이버펑크 2077의 출시를 Factorio 1.0 출시 1주일 전인 9월 17일로 연기한다고 발표했습니다. 우리는 이런 기념비적인 게임에 가까운 출시물들은 모두 부정적인 효과를 느낄 것이라고 생각합니다.


그래서 우리는 사이버펑크 이전이나 꽤 오래 후에 출시하는 것이 가장 좋다고 생각했습니다. 두 가지 선택 사항을 고려하여, 우리는 출시 날짜를 앞당기는 것을 선택했습니다. 우리가 더 일찍 공개하기로 선택한 몇 가지 이유가 있습니다.




목표 하향


우리가 날짜를 발표했을 때(FF-321), 우리는 최종 릴리스에 포함될 많은 것들을 계획했습니다. 주요 주제는 새로운 캠페인, 유동 알고리즘 개선, 전체 GUI 재작성입니다. 독자적인 이유로 인해 새로운 캠페인(FF-331), 유체 개선 연기, GUI 재작업(FF-348)의 많은 부분을 삭감했습니다.


일정대로


일부 기능을 설명하는 것 외에도, 우리가 해왔던 다른 작업은 좋은 속도로 진행되고 있습니다. 0.18 실험 릴리스 구조(FF-314)는 상황을 정상 궤도에 올려놓는 데 큰 도움이 됩니다. 당초 예상은 지연에 대해 "항상 예상보다 시간이 오래 걸린다"는 일부 양보를 통해 이루어졌습니다. 글쎄요, 지난 6개월 동안, 대부분의 일들이 예상보다 오래 걸리지 않았고, 우리는 꽤 효과적으로 주제를 마무리하고 있습니다.


빠르면 빠를수록 좋아요


사무실의 일반적인 느낌은 게임이 거의 끝났다는 것이고, 가능한 한 빨리 게임을 출시하고 싶다는 것입니다. 버전 1.0을 빨리 끝낼수록 재미있고 흥미진진한 새로운 것에 대해 더 빨리 생각할 수 있습니다.



따라서 몇 가지 주요 기능들을 취소하는 공동 사건으로 인해, 우리는 출시 날짜를 앞당길 수 있습니다. 확실히, 우리는 사이버펑크 출시 날짜 때문에 어떤 기능도 취소하거나 연기하지 않았습니다.


이 새로운 출시 날짜는 10주이며, 이 시점부터 8월 14일 금요일까지 팀의 주요 관심사는 게임의 마무리, 트레일러 업데이트, 마케팅 자료 준비입니다.




viewimage.php?id=2bbcd332eac031a9&no=24b0d769e1d32ca73fed81fa11d0283146878605f8ff89cb706fdb048768f609e8804691388b36420eb75c618db90295643488e52addf235752b5a5c48defca4a2a131



번역 계획과 현지화 작업 동결


게임을 마무리하는 과정 중 하나는 게임의 커뮤니티 번역 작업을 마무리하는 데 있습니다. 오랫동안 우리는 모든 번역을 소싱하기 위해 크라우딘을 사용해 왔습니다. 크라우딩은 매우 잘 작동했으며, NAT의 워크플로우(FF-48)에 깊이 통합되어 있습니다.


그러나 일부 언어는 100% 적용되지 않으며 전반적인 교정이 이루어지지 않았습니다. 이러한 이유로 우리는 부족한 부분을 채워주고 모든 것을 교정할 수 있는 전문 번역 회사를 찾기로 했습니다. 우리는 특히 Crowdin을 통해 일할 회사가 필요했습니다. 그곳의 커뮤니티는 수년간의 게임 경험을 가지고 있고, 우리 쪽에서는 어떤 관리도 필요하지 않을 것이기 때문입니다.


많은 회사들과 다른 많은 게임 개발자들과 그들의 생각을 협의한 후, 우리는 독일 베를린에 본사를 둔 Altagram과 협력하기로 결정했습니다.


최종 GUI 업데이트가 완료됨에 따라 번역을 동결했습니다. 따라서 추가 또는 변경 사항이 발생하지 않습니다(합리적인 만큼). 영어 원문에 대한 교정이 있을 것이고, 그 이후에는 모든 대상 언어에 대한 교정이 있을 것입니다.


절대적으로 명확하게 하기 위해 Altagram은 계획과 프로세스를 그들의 관점에서 자세히 설명했습니다.


-  커뮤니티가 크라우딘의 번역에 대한 기여를 완료했다는 것을 알게 되면, 우리는 필요에 따라 문법이나 양식적 개선을 제공하기 위해 영어 출처 텍스트를 교정하기 시작할 것입니다. 일단 영어가 세련되면, 2차 언어 교정을 시작할 것입니다.


-  모두 게이머이며 게임 국산화 전문가인 언어학자들이 마법을 부려 대상 언어가 가능한 한 소스 텍스트에 충실하도록 하고, 플레이하는 언어와 관계없이 팩토리오의 모든 플레이어가 동일한 경험을 할 수 있도록 할 것이다.


-  언어학자들이 목표 언어를 교정할 때 확인할 몇 가지 사항은 다음과 같습니다: 텍스트 자체, 특히 모든 게임 내 용어가 일관되도록 하는 것; 철자와 문법이 정확하다는 것; 그리고 번역이 의도한 것과 같은 의미와 감정을 전달한다는 것.


제안서를 제출한 후, 해당 텍스트는 게임에 적용하기 전에 커뮤니티에 최종 승인을 받기 위해 다시 보내질 것입니다.



지금부터 1.0 릴리스까지 번역 동결은 버그픽스, 새 그래픽, 사운드 디자인 등 새로운 문자열이 필요하지 않은 항목만 작업한다는 것을 의미합니다.








프로토타입 탐색기 GUI/프로토타입 GUI 


영감


Factorio는 수년에 걸쳐 수많은 디버그 기능과 도구를 내장하고 있습니다. 일부는 광범위하게 사용되며(FPS/UPS 표시), 다른 일부는 우리가 (GUI 스타일 검사 툴팁) 없이 어떻게 했는지 궁금해합니다. 모두 목적을 위해 추가되었고, 결국 원래의 목적보다 훨씬 더 많은 효용성을 제공하게 되었습니다. 그 점을 염두에 두고, 그리고 그들도 결국 (나에게) 아주 재미있어지게 되기 때문입니다. 저는 GUI 스타일 검사 툴팁 로직을 통해 발견한 문제를 수정하는 작업을 하던 중, 스스로 생각했습니다. 게임 내 모든 프로토타입에 이런 것이 있으면 좋지 않을까? 그게 제가 현실적으로 할 수 있는 일인가요? 어떻게 보일까요? 어떻게 모든 둥지를 처리할까요? 재밌을 것 같았어요.


그래서 저는 이런 것이 어떤 효용성을 가질 수 있는지 알아보기로 했습니다.


-  모드의 변경 또는 변경 여부를 파악합니다. 또는 수정해야 하거나 변경하지 않아야 하는지를 파악하십시오 (모드 버그 보고서와 모드의 개발 중에 공통).

-  게임이 다른 곳에서는 볼 수 없는 정보를 추출할 수 있는 장소를 제공합니다 (모드 API를 통해 모든 것이 노출되는 것은 아니며, 다른 사람이 API 전체를 기억하기를 기대하는 것은 비현실적임).

-  게임 컨셉에서 Wiki에 대한 자세한 설명으로 연결하십시오.


혜택 목록은 적어도 그 아이디어를 생각해 볼 만한 가치가 있는 것 같았습니다.



viewimage.php?id=2bbcd332eac031a9&no=24b0d769e1d32ca73fed81fa11d0283146878605f8ff89cb706fdb048768f609e8804691388b36420eb75c618db90295643488e52addf264772b0f5948d9f2a4f342c4



기술 디자인


제가 알아내야 할 첫 번째 부분은 제가 어떻게 모든 것을 GUI로 바꾸어야 하는지에 대한 것이었습니다. Factorio는 C++로 작성되고 C++는 반영되지 않습니다. "이것이 가지고 있는 모든 변수들에 대해, 이렇게 하라"라고 말하는 것은 쉬운 방법이 아닙니다. 실제로 모든 것을 다루는 유일한 방법은 GUI에 각 항목을 보내는 것입니다. 예쁘지는 않지만, 현재 개발 단계에서는 프로토타입을 자주 변경하지 않습니다. 또한, 어떤 것이 "잘못된" 경우 충돌/오류를 일으키지 않습니다. 그것은 누구나 할 수 있는 쉬운 해결책입니다. 그 부분은 나중에 많은 지루한 타이핑이 다뤄졌습니다.


그 어떤 것도 결코 쉽거나 단순하지 않습니다.

표시할 각 항목에 대해 이름 표시, 값 표시, 유형 표시 등을 수행합니다. 그것은 단순하게 들렸지만 결코 그렇지 않습니다.


-  그 유형은 믿을 수 없을 정도로 장황할 수도 있고 인간에게는 쓸모없을 수도 있습니다: 이것이 무엇을 의미할까요? "class std::basic_string, class std:::class std:::classator > (스트링입니다...)

-  값이 클 수 있으므로 접기를 만들어야 합니다.

-  값은 어떤 항목의 배열일 수 있으므로 빈 배열의 경우 "비어 있음"이 표시되어야 합니다.

-  하나의 값을 가진 물건들의 배열은 하나의 값만 보여주기만 하면 됩니다.

-  설정되지 않은 경우 옵션 항목이 "비어 있음"으로 표시되어야 합니다.

-  어떤 것들은 다른 것들과 연결되기 때문에 연결은 생성되어야 합니다.

-  이 모든 것은 어떤 중첩 수준에서도 작동해야합니다.



하지만 그게 바로 팩토리오이고, 광택이 좋기 때문입니다. 그 중 하나도 후회하지 않아요.



Wiki 연결


개발 초기 단계에 저는 이것을 사용하는 누구에게나 가장 쉬운 방법은 어떤 "유형"이 무엇이고 어떻게 사용되어야 하는지 위키 페이지에 보여주는 것이라고 결정했습니다. 위키에는 이것이 무엇을 보여줄 것인지에 대한 매우 상세한 정보가 담겨있으며, 그것을 이용하는 것은 논리적으로만 보였습니다. 하지만 난 하드코드 링크를 원하지 않았어요... 끝이 좋지 않네요


제 생각은 게임 유형 -> 위키 URL의 매핑을 제공하는 위키 페이지입니다. 게임은 매핑을 다운로드하고 GUI를 채우는 동안 매핑에 존재하는 유형을 발견하면 Wiki에 연결합니다. 빌카는 위키 부분을 빠르게 설정해 놓았습니다. 게임 쪽이죠... "어떤 것도 결코 쉽거나 단순하지 않습니다."


-  GUI가 열릴 때마다 Wiki 페이지를 다운로드하고 싶지 않았습니다. 그러면 낭비가 될 것입니다.

-  게임이 시작될 때마다 Wiki 페이지를 다운로드하고 싶지 않았습니다. 페이지가 자주 변경되지 않으므로 낭비될 수 있습니다.

-  그러나 페이지가 변경될 때 페이지를 다시 다운로드해야 합니다.

-  다운로드가 실행되는 동안 게임이 일시 중지되지 않도록 했습니다.

-  내결함성이 있어야 합니다(모든 사용자가 인터넷에 연결되어 있거나 페이지가 올바르게 다운로드될 것이라고 말할 수 있는 것은 아님).

-  그래서 간단한 "위키와 연결"이 다음과 같이 변했습니다.

-  마지막으로 Wiki 페이지를 다운로드한 시간과 수정기호 ID를 기억합니다.

-  GUI 중 하나를 처음 열 때만 수정기호 ID를 다운로드하려고 합니다.

-  수정기호 ID가 변경되었거나 로컬로 매핑되지 않은 경우 최신 Wiki 매핑을 다운로드하려고 시도합니다.

-  다운로드가 성공하면 다음 번을 위해 저장하고 GUI 링크를 채웁니다.

-  이 중 하나라도 실패하면 실행된 내용을 기록하고 자동으로 계속 실행됩니다(결국 인터넷입니다. 무작위 오류가 예상됨).

-  이 모든 것은 백그라운드 스레드에서 발생하므로 이 논리가 작동하는 동안 게임이 일시 중지되지 않습니다.


그리고 모든 것이 완벽하게 작동합니다.



viewimage.php?id=2bbcd332eac031a9&no=24b0d769e1d32ca73fed81fa11d0283146878605f8ff89cb706fdb048768f609e8804691388b36420eb75c618db90295643488e52addf2312371095718daafa4980f13



고유 루아 일련화


지난주에 Rseding으로부터 Lua 테이블 반복기를 C++ 쪽에서 자주 반복하고 이 작업은 느리기 때문에 상태 저장 Lua 테이블 반복기를 어떻게 구현할 수 있는지 알아보라는 요청을 받았습니다. 이로 인해 루아의 내신과 테이블을 저장하는 법을 배울 수 밖에 없었습니다. 이때까지 지도가 저장되고 루아 상태가 연재되어야 할 때, 우리는 뱀.dump (독사 도서관에서)를 사용하여 글로벌이라는 변수를 루아 쪽의 문자열로 변환한 다음 그것을 꺼내 저장해 두었습니다.


C++ 쪽에서 루아 테이블을 통과하는 것이 꽤 쉬웠기 때문에, 저는 실험을 위해 루아 계열사를 구현하기로 결정했습니다. 이를 통해 우리는 뱀.dump를 사용하여 완전히 건너뛰고 대신 직접 저장할 수 있었습니다. 기존 형식에서 저장된 데이터는 루아가 구문 분석 및 실행해야 하는 문자열이었기 때문에 로딩 시간을 줄이는 것이 제 1차 목표였어요.


나중에 알게 된 바와 같이(제가 아닌) 저장 중에 Lua 작업이 실행되지 않고 선형 시간 내에 저장하기 위해 데이터에 대한 순수 트래버설만 수행되므로 절약 속도가 크게 향상되었습니다.


스크립트 데이터가 상당히 많은 하나의 저장 파일을 사용하고 있었습니다(script.dat 약 60MB). 결과는 3회 테스트 실행의 평균입니다.


Saving:

-Old = 285.429s

-New = 2.847s

Loading:

-Old = 47.034s

-New = 22.755s


이 값에는 Rseding에 의해 구현된 일부 최적화도 포함됩니다.


그러나 일련 번호를 변경하면 비용이 발생합니다. 뱀.dump는 글로브에 저장된 루아 함수의 일련화를 수행하고 있었습니다. 어쨌든 우리로부터 공식적으로 지원을 받지는 않았지만, 몇몇 모드는 "그들이 효과가 있는 것 같아서" 그것들을 사용하고 있었습니다. 새로운 시리얼 제조사와 함께 저는 그것의 복잡성과 본질적인 한계 때문에 그것을 전혀 구현하지 않기로 결정했습니다. (어쨌든 압류는 깨졌습니다.) 이로 인해 모드가 일부 깨졌지만(일부 베이스 게임 시나리오도 포함) 수리가 쉽습니다.


저장 중 글로벌에 Lua 기능이 있을 때 저장하지 못하거나 메타테이블과 같은 경우 자동으로 삭제해야 하는 경우를 추가로 고려했습니다. 첫 번째 접근 방식은 준수하지 않는 모든 모드를 신속하게 포착하는 최선의 방법으로 간주되었지만 나중에 모든 스크립트를 다시 로드하도록 요청하는 0.18.28에 대한 기본 게임 마이그레이션으로 인해 마이그레이션이 거의 불가능했기 때문에 저장 시 일부 정보를 로그 파일에 제공하는 것이 더 낫다고 판단했습니다. 즉, Lua를 저장하십시오. 아직 글로벌에 남아 있는 Lua 기능으로 인해 즉시 저장을 중단하는 상태입니다.










요약 :


사펑 2077 발매일때문에 팩토리오 발매일을 5주가량 당겨서 8월 14일 금요일로 확정.


다만 계획을 당겼다고 기존 작업 목표와 크게 달라지는 일은 없을거임



번역작업 일단 멈출거임. 정발하고나서 전문 번역 회사랑 손잡고 현지화할거임.



그다음은 뭔가 게임 내에 위키를 연결하는 작업같은데 뭔소린지 졸려서 이해가 안되서 대충 구글번역 돌림

부드럽게 읽히게 해볼랬는데 실패


알아서 알아먹으샘