Блог розробників (FFF#277) – Прогрес оновлення GUI

Поделиться

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

Гарна частина цього суворого конвеєра полягає в тому, що тепер ми краще знаємо про стан роботи.
Це завдання графічного інтерфейсу, які ми сподіваємося надати в 0,17:

Загальний UX UX проект UX перегляд UI макет UI перегляд Реалізація проекту Перегляд реалізації Фінальний перегляд
Загрузка карти
Збереження карти
Настройки графіки
Настройки керування
Настройки звуку
Настройки інтерфейсу
Інші настройки
Генератор карти
 GUI технологій
Підказки технолоій
Підказка Рецепту/Предмета/Сутности
Панель дій
Панель ярликів
 GUI поїздів
Управління/настройка модів
Головний екран чата
Меню рецептів
Екран персонажа
Меню структур
Нова гра
Допомога
Вибір іконок чата
Бібліотека чертежів

Ви можете бачити, що багато ще належить зробити, але робота має тенденцію прискорюватися в міру того, як все більше і більше макетів / наборів / стандартів GUI допрацьовується і використовується повторно. Можна зробити висновок, що в січні можлива пробна версія 0,17, але може бути і в лютому :).

Маленькі деталі (kovarex)

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

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

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

Проблема масштабування і рішення (kovarex)

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

Уявіть, що між двома кнопками шириною 20 пікселів є розрив шириною 1 піксель, і ви хочете, щоб він відображався в 120%. Кнопки збільшені до 24 пікселів, але зазор або залишається 1 пікселем, або стає 2, але пропорції макета змінюються.

Щоб вирішити цю (і інші проблеми), ми вирішили використовувати те, що ми називаємо «модулями». 1 модуль має 4 пікселя в стандартному масштабі (100%), і майже все це множення модулів (розміри, позиції, відступи і т. Д.). Крім того, ми обмежили можливі значення масштабу кратними 25% (від 75% до 200%). Це означає, що розмір одного модуля може бути різним (від 3 пікселів при 75% до 8 пікселів при 200%), але пропорції залишаються незмінними, тому він виглядає правильно.

Поки це працює досить добре, але приносить ще одну проблему для 0.17. Я не знаю, чи помітив хтось, але слоти предметів (інвентар / логістичні фільтри, слоти крафта і т. Д.) Були навмисно масштабовані менше, ніж інші елементи призначеного для користувача інтерфейсу. Причина цього полягала в тому, що 32 × 32 іконки, які ми маємо для всіх предметів / рідин / рецептів, виглядають не дуже добре, якщо розтягувати занадто сильно.

Але так як нам довелося скасувати це спеціальне правило для 0.17, ми повинні переконатися, що всі значки 32 × 32 (285 елементів, 27 сигналів, рідин і т. Д.) Повинні бути надані з дозволом 64 × 64, тому всі підтримувані інтерфейси будуть добре виглядати. Це буде досить трудомістка робота, але так як ми все одно визуализируем іконки з 3D-моделей, це повинно бути керованим. Ми, ймовірно, випустимо значки з високою роздільною здатністю для 0,17 під час експериментальної фази.

Процедурна Захист від хвиль (Klonan)

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

Завдяки недавнім змінам і відмінній роботі TOGoS генерація процедурних карт працює дуже добре і дуже надійна для заданого набору налаштувань. Це наштовхнуло мене на думку, що, можливо, можна буде змусити Захист від хвиль використовувати нову карту кожен раз. Я експериментував з деякими встановленими значеннями, і я вважаю, що це буде працювати дуже добре

Однак у мене є деяка нерішучість всередині себе, і є кілька переваг і недоліків між призначеними для користувача картами ручної роботи і випадково генеруються світами.

Переваги карти на замовлення

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

Переваги процедурних карт

  • Сценарій має набагато більшу відтворюваність.
  • Нам не потрібно турбуватися про перенесення даних карт, клітин, об’єктів і т. Д В новіші версії.
  • Будь-які поліпшення в генерації карти будуть відображені в сценарії.
  • Люди не можуть продумати сценарій, використовуючи креслення інших людей.
  • Ми можемо додати деякі параметри конфігурації для людей, які хочуть адаптувати досвід гри.
  • Легко додати підтримку серверів для продовження роботи після перемоги / поразки.

Тому я роблю зміни зараз, щоб перевірити, чи може процедура працювати, і це не повинно зайняти багато часу, так як більша частина сценарію залишиться колишньою. Я хотів би попросити залишити деякі відгуки і думки спільноти: чи багато хто з вас грали в захисті від хвиль? Як ви думаєте, випадкова карта буде веселіше? Як ви думаєте, ви б грали більше, якби карта кожного разу відрізнялася?

Як завжди, ви можете повідомити нам, що ви думаєте на нашому форумі.


Поделиться

Comments: