от ·Нет комментариев

опубликовали kovarex, Klonan

Прогресс обновления GUI (kovarex)

Это продолжение последнего отчета FFF-269. Как не удивительно, самым большим узким местом патча 0.17 является графический интерфейс. Мне нравится верить, что мы многому научились из ловушек совместного творческого процесса GUI. Это типичный способ, которым мы перепроектировали GUI:

  • Два-три человека начали обсуждать, что может быть круто изменить в конкретном графическом интерфейсе. Некоторые люди случайно присоединились и покинули продолжающуюся дискуссию. Аргументы против определенных идей должны повторяться снова и снова. Тогда дискуссия заканчивается из-за чего-то.
  • Неделю спустя люди снова начинают говорить, большинство из них забыли большинство вещей или обсуждали это с разными людьми, поэтому они предполагают, что некоторые детали изменений будут понятны всем, а они – нет.
  • Они приходят к соглашению, как это должно быть сделано.
  • Они случайным образом обсуждают это неделю спустя и выясняют, что у них были совершенно разные идеи о том, как это должно быть сделано, они просто не сформулировали их точно. Оба недовольны тем, что им приходится вновь открывать и снова обсуждать эту тему.
  • Кто-то начинает реализовывать GUI, но на полпути через него обнаруживается, что при определении способа выполнения работы возникло еще одно недоразумение, и нам нужно снова перейти к шагу 1 и повторить.

Поскольку многие графические интерфейсы продуманы и работают над ними параллельно, эти ситуации накладывались друг на друга и усугубляли проблемы, возникающие в наших головах по поводу того, о чем мы договорились, в каком графическом интерфейсе.

К счастью, мы в конечном итоге выяснили, что это не может быть сделано так, и, поскольку в GUI много работы, нам нужно сделать процесс. Это выглядит так:

  • Во-первых, есть общее обсуждение графического интерфейса, все члены команды могут поделиться своими идеями.
  • kovarex + Twinsen сидят в офисе одни и обсуждают в течение некоторого времени (могут быть часы) все плюсы и минусы того, как все должно быть сделано, и договариваются.
  • Twinsen пишет подробный UX-документ о графическом интерфейсе, в котором подробно описана структура и, что более важно, поведение.
  • Twinsen + kovarex обсуждают документ UX и предлагают изменения, пока они не согласятся с окончательной версией.
  • Albert + Aleš берет документ UX и создает на его основе макет пользовательского интерфейса.
  • kovarex + Twinsen + Albert согласовывают макет пользовательского интерфейса или предлагают изменения.
  • Кто-то назначен для реализации GUI на основе документа UX и макета UI
  • kovarex проверяет правильность реализации и указывает на некоторые несоответствия, которые он может увидеть. Частью этого шага является обеспечение того, чтобы мы использовали как можно больше стилей и кода графического интерфейса для различных графических интерфейсов.
  • kovarex + Albert окончательно рассматривают реализацию и исправляют окончательные детали, пока они оба не согласятся, что задание полностью завершено.

Наличие всегда доступных  UX-документов / UI макетов значительно сэкономило время. Это не только помогает нам решать проблемы общения, нам также не нужно запоминать и переформулировать решения, принятые некоторое время назад, поскольку мы можем просто открыть документ и посмотреть, что мы согласовали, и немедленно продолжить с того места, где мы остановились.Читать далее


от ·Нет комментариев

опубликовали V453000 & Albert

Это последняя пятница 2018 года, и, как таковая, последняя ффф перед Новым 2019 годом.

Мы все надеемся, что у всех был отличный 2018 год, и с нетерпением ждем еще большего удовольствия от автоматизации в 2019 году. Альберт подготовил открытку, которой вы все могли бы поделиться, чтобы подвести итоги года.

Изменения науки в 0.17  (V453000)

Наука в Факторио или, более того, отдельно, технологии и научные пакеты, являются основными механизмами прогресса в игре, и все сущности разблокируются так. Это здорово, но это также означает, что когда мы изменим или добавим в игру почти что-нибудь, это, безусловно, окажет некоторое влияние на науку. Со временем мы несколько раз меняли технологии и научные пакеты, потому что их контекст и цели дизайна менялись и развивались вместе с игрой.Читать далее


от ·Нет комментариев

опубликовали Dominik, Klonan, kovarex

Новая система жидкости 2 (Dominik)

Привет Факторианцы,

Вот и я, Доминик, с обновленной информацией о жидкостях. На этот раз все почти закончено, поэтому я могу рассказать вам факты, а не только предположения. Вы найдете здесь, как будет работать новый алгоритм, и некоторые новые удобные функции использования.

В FFF-260 я писал о том, как все это началось, почему мы это делаем и каков план. Мы получили огромный отклик от всех вас, и я хочу поблагодарить всех за их вклад. Позвольте мне извиниться перед редакторами, так как в начале я начал отвечать на форумах, и когда я понял, что есть и Reddit, было слишком много комментариев для меня, чтобы справиться со всеми вопросами.

Пользователи форума выдвинули много идей о том, как система может работать. Около трети из них была идея телепортации жидкости, многие из которых были известны, но многие были совершенно новыми и интересными. То, что заинтриговало меня, было большим разнообразием направлений, из которых они пришли – различные виды инженеров (механика, CS, электротехника, …), математики, физики, и даже люди с практическим опытом с реальными трубами. Я не буду описывать их здесь, вы можете найти их на форумах или в Reddit. На форуме было два предложения, которые были настолько хороши, что попали в игру – от Quinor и TheYeast.

Оба эти предложения были очень похожи и похожи на логику что есть в игре. То, что их разделяет, – то, что механика все еще использует моделирование физики жидкости и объем в трубе как основу для вычисления движения. В результате не так много изменений на первый взгляд. Тем не менее, они добавляют акцент на том, что обновление текучей сети не зависит от текущего состояния (то есть обновление одной трубы зависит только от состояния с последнего тика) и, следовательно, не зависит от порядка оценки, что было одной из самых больших проблем старой модели, которая привела к иногда смешному поведению соединения. Разница между этими двумя вариантами была довольно небольшой – версия Quinor обеспечивала идеальную пропускную способность с 3 проходами через fluidbox (fluidbox управляет жидкостями для объектов, поэтому я говорю. о них), в то время как у TheYeast было 2 прохода с ¼ пропускной способностью. Что было замечательно, так это то, что физик TheYeast поддержал модель с хорошим теоретическим опытом и, более того, он создал потрясающий симулятор JS для тестирования и сравнения различных модификаций модели. Поскольку этот дополнительный проход в версии Quinor был слишком дорогим для идеальной пропускной способности, я выбрал два прохода TheYeast.

Поскольку старый алгоритм использовал только один проход, запускаемый объектами для обновления, мне сначала нужно было пересмотреть всю систему, чтобы позволить разместить новую. Переход от одного прохода к двум проходам обязательно означает более высокую сложность, поэтому мы приложили большие усилия, чтобы оптимизировать все, что могли, чтобы быть уверенными, что мы все равно окажемся быстрее, чем 0,16. Коварекс написал об этом в FFF-271.Читать далее


от ·Нет комментариев

опубликовали Oxyd, Wheybags, Klonan

Здравствуйте, мы получили прекрасные подарки от Steam на этой неделе:

В записке написано: С праздником! От команды Steam

Шоколадные конфеты вкусные и, кажется, не останутся на долго

Контроллер кат-сцен (Oxyd)

Одна из вещей, запланированных для релиза 1.0, – это правильная кампания и учебное пособие «New Player Experience». Оба они пытаются направлять игрока, и для этого нам иногда нужно отвлекать внимание игрока на конкретное место в виртуальном мире.

Другими словами, нам нужны ролики(кат-сцены). Базовые ролики – это относительно простые вещи: нам нужно отнять управление у игрока, переместить камеру, чтобы показать то, что нам нужно показать, и, возможно, отобразить некоторые сообщения на экране. Кат-сцены предназначены для запуска и управления сценариями, поэтому для сценариев необходим общий способ описания кат-сцены.Читать далее