опублікували 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 макетів значно зекономило час. Це не тільки допомагає нам вирішувати проблеми спілкування, нам також не потрібно запам’ятовувати і переформулювати рішення, прийняті деякий час назад, оскільки ми можемо просто відкрити документ і подивитися, що ми погодили, і негайно продовжити з того місця, де ми зупинилися.
Continue reading


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

Нова система рідин 2 (Dominik)

Привіт Factorians

Вот и я, Доминик, з новою інформацією про рідини. На цей раз все майже завершено, тому я можу розповісти вам факти, а не тільки припущення. Ви знайдете тут, як буде працювати новий алгоритм, і деякі нові зручні функції використання.

В FFF-260 я писав про те, як все це почалося, чому ми це робимо і який план. Ми отримали величезний відгук від всіх вас, і я хочу подякувати всім за їх внесок. Дозвольте мені перепросити перед редакторами, так як на початку я почав відповідати на форумах, і коли я зрозумів, що є і Reddit, було занадто багато коментарів для мене, щоб впоратися з усіма питаннями.

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

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

Оскільки старий алгоритм використовував тільки один прохід, що запускається об’єктами для оновлення, мені спочатку потрібно було переглянути всю систему, щоб дозволити розмістити нову. Перехід від одного проходу до двох  обов’язково означає вищу складність, тому ми доклали великих зусиль, щоб оптимізувати все, що могли, щоб бути впевненими, що ми всеодно станемо швидше, ніж 0,16. Коварекс написав про це в FFF-271.Continue reading


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

Привіт, ми отримали чудові подарунки від Steam на цьому тижні:

У записці написано: Зі святом! Від команди Steam

Шоколадні цукерки смачні і, здається, не залишаться на довго

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

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

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

Continue reading


опублікував Twinsen

Привіт,
велика частина команди відвідує GDS, якщо ви перебуваєте в Празі і зацікавлені в Іграх, ви також можете приїхати.

Новий інтерфейс управління / установки / оновлення модів (Twinsen)

Коли ми переглядали головне меню, покращуючи зовнішній вигляд, а іноді і взаємодію більшості графічних інтерфейсів, було очевидно, що управління модами вимагає деякої уваги. Велика частина взаємодії була досить неінтуітівна і обмежена, і більшість гравців вважають за краще використовувати веб-версію і управляти файлами вручну.

Моди будуть управлятися, встановлюватися і оновлюватися з одного і того ж графічного інтерфейсу, а три операції відображаються як 3 вкладки. Взаємодія, розташування і інтуїтивність GUI повинні бути значно покращені. Меню як і раніше не буде мати всіх можливостей онлайн-порталу (наприклад, обговорення), але забезпечує дуже швидкий спосіб встановлення та оновлення модів без необхідності працювати з файлами.

Continue reading