Приложения к заметкам о простых играх (интерфейсы)

Перейти вниз

Приложения к заметкам о простых играх (интерфейсы)

Сообщение автор Gudleifr в Ср Авг 16, 2017 9:20 am

Все авторы игр, независимо от совершенства компьютерной и программной материальной базы, находятся в жестких рамках ограничений: с одной стороны, небходимости обеспечить игроку наиболее полный контроль над действиями персонажа, с другой, нежелательности слишком усложнять его интерфейс. Если мы пренебрежем первым требованием, то очевидным решением будет использование схемы меню (как в любых "Окнах"). Если же мы, наоборот, плюнем на сложность интерфейса, то еще более очевидным решением будет создание честной модели мира, где персонаж сможет ходить куда попало, нажимать любые кнопки, отламывать и носить с собой любые детали мебели. Причем, не надо думать, что для этого необходима полная аппаратная поддержка виртуальной реальности. Например, в древних компьютерных играх нужно было просто ввести с клавиатуры описание действия персонажа или его реплику на обычном английском языке. В процессе эволюции компьютерных игр была найдена золотая середина. Решение, в общем-то, очевидное - разбить весь пользовательский интерфейс на ма-аленькие такие тематические и кристально прозрачные интерфейсики. Во-первых сразу упрощается смешение в одной игре нескольких жанров, во вторых сильно облегчается добавление в игру новых возможностей. Рассмотрим примеры из двух совсем старых игрушек - "Dune" и "Transarctica" и сравним их с честной трехмерностью "Battle Zone". Нельзя забывать, что с тех пор техника шагнула далеко вперед, и приходится только удивляться, почему за прошедшие годы практически ничего более запоминающегося не появилось.
avatar
Gudleifr
Admin

Сообщения : 879
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Приложения к заметкам о простых играх (интерфейсы)

Сообщение автор Gudleifr в Ср Авг 16, 2017 9:25 am

РАЗНОВИДНОСТИ КОМНАТ. DUNE И TRANSARCTICA

КОМНАТА -- подойти к персонажу или пульту. D: комнатой может быть и просто кусок пустыни.



ПУЛЬТ -- чем-нибудь управлять.



РАЗГОВОР -- общаться. TA: просто текст.



ПЛАН -- выбрать комнату. TA: план изображен в главном меню.



СРАТЕГИЧЕСКАЯ КАРТА -- раздать приказы сподвижникам, перемещаться.



ТАКТИЧЕСКАЯ КАРТА -- воевать. D: простенькая разновидность заставки (см. ниже).



КАБИНА -- как в играх-симуляторах. TA: только для отображения неожиданностей



МАГАЗИН -- торговать, заправляться. D: просто разновидность комнат с разговорами.



ЭНЦИКЛОПЕДИЯ - смотреть красивые картинки. TA: отсутствует.



ЗАСТАВКА - смотреть красивые мультики. Есть и там, и там. В Dune лучше.

ЗАПИСНАЯ КНИЖКА - вести дневниковые записи. D: нет. TA: только автоматическая регистрация событий и сообщений.
avatar
Gudleifr
Admin

Сообщения : 879
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Приложения к заметкам о простых играх (интерфейсы)

Сообщение автор Gudleifr в Ср Авг 16, 2017 9:33 am

НАОБОРОТ - BATTLE ZONE

Как же сдедано в "Battle Zone" (в нашем случае "II"), явно тяготеющей к построению полной модели мира? "Комнат" как таковых нет - персонаж свободно перемещается по полям и весям,



если нужно, заходя в здания.



Плюс состоит в том, что в любом месте он может совершать почти все доступные ему действия - отдавать команды, стрелять, ставить мины, использовать снайперскую винтовку.



Минус очевиден - число управляющих действий (клавиш) резко возрастает. Иногда даже сразу непонятно, какое действие с предметом следует совершить: "обследовать", "использовать" или просто подойти достаточно близко. Нахождение в "Кабине" практически ничем не отличается от пешеходного перемещения - только немного изменяется список доступных действий.



Некоторые "Кабины" настолько сложны, что туда лучше и не залезать, предоставив управление такими танками пилотам-профессионалам. "Карты", "Магазины" и, частично, "Энциклопедия" реализованы при помощи "Пультов".



Причем, "Карта" только одна - тактическая, и пользоваться ей часто очень неудобно. Во первых, для этого нужно на попутном танке добраться до ближайшего бункера, а, во-вторых, она ориентирована только на оборону базы и строительство укреплений.



"Разговоры" реализованы в виде "Заставок" или кратких текстовых сообщений.



"План" выродился в миникарту на дисплее. Чистая "Энциклопедия" присутствует только в меню архивов миссий. (Тут надо отметить, что жесткое разбиение игры на отдельные миссии несколько портит эффект присутствия в виртуальном мире.)



"Заставки" в обеих частях игры изумительны, и особенно приятно, что почти полностью выполнены теми же графическими средствами, которые видим и в течение всей игры.

Из данного обзора мне кажется очевидным, что честная модель мира не всегда идет на пользу играбельности.
avatar
Gudleifr
Admin

Сообщения : 879
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Приложения к заметкам о простых играх (интерфейсы)

Сообщение автор Gudleifr в Ср Авг 16, 2017 9:44 am

ИМЕЕТ ЛИ ВСЕ ВЫШЕОПИСАННОЕ КАКОЕ-ЛИБО ОТНОШЕНИЕ К ИГРАМ НАСТОЛЬНЫМ?

Мне кажется, да. Ведь что сделано практически во всех жетонных, миниатюрных или карточных играх?
Каждый ход разбит на фазы, в течение которых, игроки выполняют действия, свойственные именно текущей конкретной фазе. Чем не "Комнаты"?
Может имеет смысл потихоньку начать отказываться от жесткой временной последовательности фаз и переходить к некой более общей схеме переходов между состояниями игры (конечным автоматам)?

С ТОЧКИ ЗРЕНИЯ КОСМИЧЕСКОЙ ЛАБУДЫ О ВСЕОБЩЕЙ НЕОТВРАТИМОСТИ

Проблема КОМНАТ, недавно снова встала предо мною совсем не по-игровому.

Начал переписывать свои Windows-библиотеки и погряз в мусорной куче частностей, парадигм и замысловатых типовых фрагментов, которую представляет из себя WIN-API.

Что взять за основу графического интерфейса программы?
- Упрощенные "обезьянники" MS Visual Basic-ов и прочих Delphi? Так там - 90% времени уходит на копирование туда-сюда типовых экранных форм и их кода, а 9% процентов из оставшегося - попытка наглого взлома внутренних структур с целью сделать что-то нетривиальное.
- Упаковщики окон из Tcl/Tk - верх-низ-лево-право, по таблице, по кооординатам? 9% я сэкономлю, т.к. ничего сверхоригинального все равно не получить, но радости от этого мало.
- Приятнее всего на этом фоне выглядят формы HTML - простенько, но минимум проблем при реализации желания "все так же, но чуть-чуть левее".

Хочется чего-то более продвинутого.

Как-то так: Программа - организм. Смысловая часть - генотип. Принятые в твоей конторе оформительские соглашения - ограничения фенотипа. Зародыш развивается, заполняя своей биомассой структуру оконных форм (может - консоль, может - MDI). Гены лишь определяют ветвление в судьбоносные для зародыша моменты. Фенотип может быть представлен таблицей всех параметров всех окон, может списком отклонений стиля каждого окна от стандартного, может описанием совсем уж аппаратно-независимого дисплея.

Главное - минимум универсальности и максимум удобства.

Вот тут-то и вспомнил о КОМНАТАХ - ведь их возможности полностью покрывают не только нужды игрового интерфейса, но и любого другого интерфейса вообще.
Эврика, в общем...
avatar
Gudleifr
Admin

Сообщения : 879
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Приложения к заметкам о простых играх (интерфейсы)

Сообщение автор Gudleifr в Ср Авг 16, 2017 9:44 am

А КАК ГОВОРИЛ ЛЕМ? (АСТРОНАВТЫ, 1951)

На вырванном из блокнота листке он написал несколько уравнений, затем, нажав на какие-то кнопки и клавиши, перевел белый рычажок.
Тотчас же на одном из экранов появилась неподвижная светящаяся зеленоватая линия.

- Вот и решение. Если хотите знать его в цифрах, нужно дать особое задание.

Профессор нажал другую кнопку, и из узкой щели выпал кусок бумажной ленты с напечатанными на нем математическими знаками.
***

"Маракс" - это замкнутая система, стремящаяся к определенному равновесию токов. Как маятник, который при отклонении всегда стремится занять самое низкое положение. Давая задачу, мы выводим машину из состояния электронного равновесия. Стараясь вернуться к нему, "Маракс" как бы "по пути" решает задачу. Игра токов создает различные кривые, которые вы видите на этом экране, и они-то и являются ответом на заданный вопрос. Вы знаете, конечно, что всякую кривую линию можно выразить через математическое уравнение? Уравнение кривой, появившейся на экране, - это, собственно, и есть искомый ответ.
***

Сведения в "Мараксе" преобразовываются, изменяются и приспособляются, как в мозгу; потому-то они и сохраняются в виде пластичных колебаний тока, представляемых кривыми линиями. Вы знаете, конечно, что если наложить две кривые друг на друга, то получится третья, равнодействующая, не похожая ни на одну из них? Так вот, вопрос, заданный "Мараксу",- это одна кривая, сведения, использованные им в работе,- другая, а полученная от их сложения равнодействующая - это и есть ответ... Нет, я опять сказал это только для простоты. Нужны не три кривые, а миллиарды и биллионы.
***

... как задают машине вопросы? Это, конечно, нужно уметь. Во всяком случае, это не так просто, как задавать их мне. А что касается того, что кривыми нельзя выразить то, о чем я говорил, то ты ошибаешься, мой мальчик, потому что разве наше письмо - не та же кривая, петлистая, пересекающаяся, усложненная? Только не подумай, что мы так и разговариваем с "Мараксом". Кто знает, быть может, это и возможно, но это повлекло бы за собою множество технических осложнений. "Маракс" - как бы великий мудрец-чужеземец, который может очень многое нам рассказать, но только на своем языке. Поэтому стоит затратить немного труда, чтобы научиться его языку - языку кривых, начерченных быстро изменяющимися токами. Ну, а кто не умеет, может для перевода его ответов на обыкновенный язык воспользоваться специальным аппаратом, так называемым электроанализатором Мадера-Фурье. Но опытному оператору достаточно только взглянуть на экран, и он уже знает все.
***

Я упоминал о рояле и композиторе. Это сравнение мне кажется удачным. Подобно тому как настоящую прекрасную музыку может извлечь из инструмента только виртуоз, так только математик может полностью использовать хотя и ограниченные, но все же очень большие возможности "Маракса". Часто, когда я ночью сижу здесь и работаю, происходит странная вещь: мне кажется, будто исчезает граница между мною и "Мараксом". Иногда я ищу ответы на заданные вопросы в собственной голове, иногда пробегаю пальцами по клавишам и читаю ответы на экранах... и не чувствую существенной разницы. И то и другое - одно и то же, собственно говоря.
***
***

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

Короче: "Создай интерфейс, которым может пользоваться и дурак, и только дурак захочет им пользоваться!".


Последний раз редактировалось: Gudleifr (Ср Авг 16, 2017 9:48 am), всего редактировалось 1 раз(а)
avatar
Gudleifr
Admin

Сообщения : 879
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Приложения к заметкам о простых играх (интерфейсы)

Сообщение автор Gudleifr в Ср Авг 16, 2017 9:47 am

ИДЕЯ КОМНАТ, ДОВЕДЕННАЯ ДО АБСУРДА. MILLENNIUM & DEUTEROS

Итак, с одним источником сложности - попыткой ввести честную трехмерную карту - мы разобрались. Т.е. заклеймили позором... Что дальше? В этом нам поможет разобраться другая игра, в которой все честно поделено на комнаты, но сложностей предостаточно - Millenium: Return to Earth (и ее продолжение - Deuteros).
Речь идет о завоевании Солнечной системы Лунитами (Земляне - уничтожены, Марсиане - враждебны). В начале (не считая служебных кнопок) - семь комнат (лунная база). (Иллюстраций не будет, так что при чтении представляйте себе, как бы это выглядело в вашем любимом фантастическом произведении).

1. Лаборатория. ПУЛЬТ. Здесь можно что-то изобрести. Список возможных разработок растет во время игры, но ничего подобного дереву исследований Civilization или X-Com не сделано. Здесь же можно просмотреть энциклопедию старых изобретений.
2. Энергостанция. ПУЛЬТ. Здесь можно подключить к сети новую солнечную батарею, отключив старую, и порадоваться, что выходной мощности хватит и на добычу полезных ископаемых и на производство чего-либо особо энергоемкого.
3. Рудник. ПУЛЬТ. Если хватает энергии, его можно включить, а заодно, огорчиться, что у нас всего так мало запасено, добыча идет медленно, а чего-то на Луне просто нет.
4. Жилой блок. ПУЛЬТ. Тут можно пристраивать дополнительные жилые модули, видеть общее количество населения и недоумевать, зачем нам этими вопросами заниматься? Влияет ли величина народонаселения на что-нибудь в игре? Разве что не удастся наскрести экипаж на новый космолет.
5. Фабрика. ПУЛЬТ. Тут можно строить новые машины - лишь бы хватило материалов и энергии.
6. ПУЛЬТ ПВО. Тут можно взрывать навстречу вражеским истребителям рентгеновские спутники с ядерной накачкой и запускать свои истребители. Потом нам скажут чего натворили прорвавшиеся стервятники.
7. Космопорт. КОМНАТА. Здесь можно перейти в комнаты - Ангары кораблей (когда последние у нас будут) или припрятать что-нибудь на черный день в бункер (когда он у нас будет).

Как только мы станем гордыми кораблевладельцами, появится еще по две комнаты на корабль:
8. Ангар (ПУЛЬТ, доступен, когда корабль садится на базу) - сначала его нужно наименовать и снабдить экипажем, а затем можно раз- и загружать и выводить на орбиту.
9. Кабина (ПУЛЬТ, доступен, когда корабль находится на стационарной орбите), здесь им можно управлять: приказать перейти на орбиту вокруг любой другой планеты или планетки, совершить посадку, включить автопилот, посмотреть на груз.

Построив первый истребитель и дождавшись налета супостата, мы попадаем в новую комнату -
10. КАБИНА истребителя - совсем простенькая стрелялка.

Построив очередную космическую базу мы получаем новый комплект комнат 2, 3, 4, 6, 7. На других небесных телах, в отличие от родной Луны, нельзя ни исследовать (и не надо), ни производить (а вот это - кошмар). С другой стороны, на некоторых небесных телах поселенцы могут жить и вне жилых модулей.

Остальные экраны - просто разнообразные списки или обзорные экраны (ПЛАНЫ). Очень неудобные.

А в чем же смысл?

1. Где-то внутри спрятан маленький планетарий, благодаря которому мы можем перед сменой орбиты космического корабля получить информацию о длительности маневра. К сожалению, подобная информация выдается столь скудными порциями, что выбрать наиболее выгодную схему перелетов невозможно.
2. Списки количеств хим.элементов и соединений нужных для производства разных машин, мягко говоря, "перпендикулярны" спискам добываемых на разных небесных телах. Причем, последние меняются от игры к игре случайным образом (кроме Луны).
3. Кроме событий, порожденных нашим действием или бездействием, иногда случаются и "случайные" события, почему-то всегда в жесткой последовательности (образуя сюжет игры).
4. Цель игры - по-тихоньку развиваться, отбивая атаки Марсиан, пока не создадутся предпосылки для разгрома Марса и повторной колонизации Земли.

НЕСУРАЗНОСТИ

1. У авторов игры вынужденно очень плохо с химией и планетологией, иначе пропала бы "изюминка" игры - муторное управление перевозками сырья и продукции по всей Солнечной системе.
2. Население плодится с такой скоростью, что кролики позавидуют. Может к космонавтам "местные" присоединяются?
3. Очень многие ресурсы лишь загромождают игру, так как недостатка в них никогда не ощущается: население, метан (топливо космических кораблей?), сера (за всю игру понадобилось лишь несколько тонн), вода (нужно очень мало, но почему-то нельзя синтезировать из кислорода и водорода) и т.д.
4. Самое смешное, режим переключения в реальное время на период ожидания событий просто никому не нужен, все равно либо текущее событие прервать нельзя (полет космолета), либо не имеет смысла (приостановить без причины исследование/производство). Удобно, что выход на орбиту космолета осуществляется моментально, но безумно неудобно, что момент схода с орбиты точно не поймать вообще.
5. Очень удобна возможность запрограммировать косморудокопов на полеты в пояс астероидов и обратно, но почему, это единственная возможность автоматизации в игре?

ВЫВОДЫ

1. Вот оно зло - огромные бессмысленные таблицы. Очевидно, что изменив классификацию сырья, с химической, на производственную можно здорово все упростить.
2. В подобного рода играх режим реального времени нужен только в момент боя. В остальное время достаточно шага "от события - до события".
3. Упрощения интерфейса никому не надо, если при этом приходится вести подробные записи на бумажке.
4. Вполне вероятно, что многое можно упростить, совместив в одну КОМНАТУ несколько разных и даже разбросанных по всему космосу.
5. Малое количество органов управления в комнатах, и постепенное введение в игру новых комнат делают ненужными громоздкие обучалки и мануалы. Освоение правил становится частью игры.

ОГРЫЗКИ ЭНЦИКЛОПЕДИИ

- Конструкционные материалы - обычно Титан и Алюминий, реже - Кремний, Железо, Медь, Серебро и Платина. Причем, Медь приходится возить с Астероидов.
- Второстепенные материалы - нужны для производства в очень небольших количествах и их всегда в достатке. Кислород, Водород, Вода, Азот.
- Редкие материалы - нужны для постройки некоторых машин. О них - ниже.
***

- Probe - беспилотный зонд-разведчик небесных тел. Запускаем, переходим на орбиту нужного небесного тела, сажаем - в результате получаем доступ к исследованию возможности колонизации этого небесного тела и его минеральных ресурсах. Как писал выше, данные небесных тел вариируются от игры к игре. Иногда даже удается построить базы на планетах-гигантах (не спрашивайте меня, как). После запуска первого космического аппарата (обычно, это Probe) получаем "случайный" ультиматум от Марсиан, мол: "Кончай игру, а то хуже будет!". Первая Probe, пытающаяся прорваться к внешним планетам "случайно" гибнет в кольце Астероидов.
- Grazer - предтеча харвестеров других игр - самостоятельно (после первого полета) мотаются на Астероиды за сырьем.
- Waverider - малый транспорт, в игре практически не нужен.
- Carrack - большой транспорт. На базы возит обычно Истребители и Энергоблоки, а обратно, на Луну,- минералы. Единственный способ не запутаться - именовать Carracks так же, как небесное тело, на которое она мотается.
- S.I.O.S. - саморазворачивающаяся космическая база. Стоит кучу ресурсов. Строится под конкретное небесное тело (почему-то это не влияет на стоимость). Запускается сам, грузить не надо, летим, садимся. Почему-то имеет экипаж гораздо меньше транспорта. База готова, правда, работать пока не может, надо везти туда энергоблоки и ждать, пока подрастет население. В конце игры все базы "случайно" объявляют о независимости от Луны, и нам остается надеяться, что накопленных запасов хватит для окончания игры.
***

- SolaGen Mk1-10 - солнечные батареи - единственный источник энергии. Каждый следующий доступен для разработки и построения только после предыдущего, причем на раннем этапе для их производства приходится приостанавливать Рудник. Сильно усложняет жизнь "случайный" взрыв первого установленного Mk3, разрушающий заодно и все запасные энергоблоки. Следует учитывать, что на дальних планетах выход солнечной энергии катастрофически мал.
- Fighter - космический истребитель для защиты, а затем и для нападения на Марсиан. Налеты Марсиан - редкие действительно случайные события.
- Orbital Laser - с ядерной накачкой - очень сильное, но одноразовое средство ПВО. Нужен Редкий материал - Уран.
- Module - жилой модуль.
- Bunker - место, куда можно спрятать что-то (разве что энергоблоки) на случай катаклизма.
- Vaccina - разрабатывается и производится всего пару-другую раз - после "случайной" первой (и случайных остальных) вспышках эпидемии в колониях. Единственный за игру случай востребованности Серы.
- Fleet Carrier - космический авианосец. Может разрабатываться и производиться (один раз за игру) после "случайной" находки разбитого марсианского прототипа. Нужно очень много Конструкционных материалов. После его постройки можно "случайно" разбомбить Марс. В ответ последняя "случайная" волна марсианских истребителей практически до основания разрушает Луную базу (все лунатики гибнут, надо прилунять один из кораблей и его расплодить его экипаж).
- Terraformer - "случайно" изобретенная машина, которую нужно разработать, построить и доставить на Землю, для воскрешения последней. Кроме прочего, нужно много Редкого материала - Хрома, и немножко Урана.
- Juggernaut - машина для перевозки Terraformer. "Случайно" находится способ переделать в него Fleet Carrier.

ВО ВТОРОЙ СЕРИИ - DEUTEROS

Теперь мы начинаем с разрушенной и худо-бедно восстановленной Земли и заново завоевываем Солнечную систему (а заодно - и ближайшие звездные системы).
Производить теперь можно на любой базе. Схема производства стала более сложной - добавилась фаза сборки. Так, орбитальные базы собираются из 8 одинаковых модулей, планетарная - из двух одинаковых и из любого количества других одинаковых (добывающих), а корабли (бывают орбитальные, межпланетные, антигравитационные и межзвездные) - из двух разных. Если для баз подобное еще имеет смысл (их можно возить по частям), то для кораблей - никакого.
Проблема перевозки усложнена еще необходимостью использовать разные виды корабельных контейнеров - для сырья, механизмов, машин, истребителей. Появилась заправка кораблей топливом.
Непонятно зачем, люди разделены на Ученых, Инженеров и Космонавтов. Введены бригады из Людей - с лидерами и квалификацией.
Об энергии можно больше не беспокоиться.
Новая головная боль - корабли теперь делятся на орбитальные и свободного космоса, а базы - на планетарные и орбитальные. Число трасс удвоилось.
Истребители теперь размещаются только на кораблях.
Номенклатура оружия значительно расширилась. (В отличие от первой серии, здесь вполне можно продуть партию, не рассчитав своих сил перед началом космической войны).
Механизм "случайностей" используется по-прежнему, но так как игра значительно усложнилась, он уже не так заметен.
***

Вместо оригинальных фишек первой версии - каждая с уникальными свойствами - мы имеем теперь универсальный набор модулей для выполнения почти всех взможных в данной вселенной простейших операций. "Почти", потому что некоторые простейшие операции относятся к классу управленческих и должны выполнятся вручную. Чуть позже появляются модули для комбинирования простейших операций в более сложные и даже выполнения кое-каких управленческих операций. Вселеная становиться гораздо более "правильной".
Стало ли интереснее играть? Рассмотрим простейший цикл - построение колонии:
1. Везем куда-то 8 модулей орбитальной базы (за один рейс 3 модуля).
2. Везем на новую орбитальную базу Инженеров.
3. Долго возим туда же материалы.
4. Строим там орбитальный корабль.
5. Везем туда Космонавтов (их надо поднимать с Земли, впрочем, как и Инженеров).
6. Строим там (или везем с главной базы) 2 модуля наземной базы и горнорудные модули.
7. Заправляем орбитальный корабль.
8. Возим все нужное для постройки наземной базы вниз (орбитальный корабль вмещает только один модуль базы или несколько добывающих)...
ВЕРНИТЕ МНЕ ПЕРВУЮ ВЕРСИЮ!!!

ПРОДОЛЖЕНИЕ ВЫВОДОВ

Кроме вышеперечисленного, при таком усложнении вселенной система Комнат начинает давать сбои:
6. Появляются скучные "Анфилады" и "Коридоры".
7. Страдает графика игры. Рассматривая космолет, занимающий пять комнат, чувствуешь себя слепцом, ощупывающим слона.
8. Некоторые органы управления попадают явно "не в те" комнаты.
***

Почему мне нельзя создать проект новой базы и отдать приказ "Строить помаленьку"? Реализм? Какой реализм в игре, где в один космический модуль влезает 250 тонн либо Титановой руды, либо Водорода, а погрузочные работы и того, и другого выполняют мгновенно и бесплатно некие демоны? Плюс, жизнеобеспечение космонавтов и работяг берется из вакуума.
***

Главный вывод - интереснее не стало.
Выход видится в переклассификации грузов. Возить надо готовыми комплектами, вроде "1-ая очередь базы, согласно проекту #28". Тогда можно будет даже учесть разницу в местных условиях разных планет.
Возможно ли проектирование баз в модели Комнат, или придется вставлять в игру что-то вроде P-CAD? Думаю, при продуманой системе модулей и замене перетаскиваний мышкой на управление глобальными параметрами, вполне.

АЛЬТЕРНАТИВА

В качестве альтернативы можно рассмотреть такую же древнюю игрушку LUNAR COMMAND (построение базы на Луне) - оконный интерфейс в лучших традициях еще неродившегося Windows: проматывание карты, выпадающие менюшки, диалоговые окна, градусники... К чему это привело? Многостраничный обязательный к прочтению учебник, и ощущения не смелого покорителя космоса, а затюканного маркетоида...

Нет,- с КОМНАТАМИ лучше!
avatar
Gudleifr
Admin

Сообщения : 879
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Приложения к заметкам о простых играх (интерфейсы)

Сообщение автор Gudleifr в Ср Авг 16, 2017 9:54 am

ЭВОЛЮЦИЯ ИНТЕРФЕЙСОВ

Арракис учит "пониманию ножа", учит относится к жизни так: отрезать все несовершенное и незавершенное, говоря: "Вот теперь это совершенно и завершено - ибо кончается здесь". /Фр.Герберт, Дюна/

- Телевизор - экран - одно окно;
- SuperCalc - электронная таблица, т.е. разбиение экрана на клетки ограниченных типов и группировка этих клеток в области;
- Framework - экран - рабочий стол с документами-окнами;
- MS Windows 1 - фреймы, т.е. разбиение экрана на графические области;
- Xerox - графические окна, почти сразу появилась идея считать все органы управления (кнопки, списки, градусники...) тоже окнами;
- MS Excel - вложение одних окон в другие (MDI), в отличие от органов управления, дочерние окна MDI - почти как настоящие, и их можно растягивать, перемещать и т.д.;
- MS Visual Studio - фреймы-окна, т.е. окна, конечно можно таскать и растягивать, но удобнее прикрепить их к определенному месте на экране, создав нечто вроде мозаики;
- Xgl - трехмерный рабочий стол для размещения окон под разными углами;
- VR - честно-трехмерное окружение.

НА ЧЕМ ОСТАНОВИТЬСЯ?

Сразу понятно, что есть два ограничения - как ни крути, а придется встраивать наш интерфейс в Windows - значит, нам уже дан свыше механизм окон, и он, ни фига, не трехмерный. Очевидно, что можно было бы как-то зафиксировать в общей иерархии интерфейсов Windows уровень, соответствующий отдельной программе и научить нашу программу обеспечивать соответствующий интерфейс, однако, это невозможно: во-первых, если в ранних версиях Windows соотношение "одна программа - одно окно" было нормой, то теперь "нормой" стали программы, как состоящие из нескольких окон, так и программы, которые в рамках одного - родительского - окна, поддерживают в себе собственную иерархию дочерних окон; во-вторых, вопрос о том, делить на фреймы окно, либо делить фреймы на окна, тоже решается каждым программистом самостоятельно. Другой подход - либо совсем отказаться от окон и рисовать на экране, либо отказаться от стандартных органов управления и рисовать внутри своего окна самостоятельно, тоже вызывает нарекания, как со стороны программиста - зачем писать самому, то что уже кем-то написано, так и со стороны пользователя - он уже привык к стандартам.
***

Встречаются ли в дикой природе интерфейсы, которые, нравятся мне?
Во-первых, это "интерфейс ЦУП":



Во-вторых, это очень похожий интерфейс во 2-м фильме Матрица:



Если на то пошло, то интерфейс Quake (консоль поверх картинки) очень похож на эти два.
В-третьих, это интерфейс старых фильмов про хакеров. Там у каждого уважающего себя программиста (особенно, если речь о виртуальной реальности) было по два монитора - обычный большой цветной телевизор для всяких визуальных эффектов и маленький честно-текстовый монитор для, собственно, работы.
А вот, до кучи, еще один уродливо-прекрасный интерфейс (игра Critical Path):



Здесь есть один "телевизор" для картинок и три набора controls - диалога с персонажем (стрелки и кнопки "yes" и "no" - зеленый экранчик), ввода ключей (цифровые кнопки и кнопка подтверждения) и управления средой (текстовое табло и помеченные буквами кнопки с лампочками - под ним).
Можно поймать автора этого ПУЛЬТА на противоречии: буквы, которыми помечены органы диалога (стрелки - B, F, L, R - и ответы - N, Y) частично перекрываются с буквенными пометками органов управления средой. (Впрочем, честь изобретения самого известного "буквенного" противоречия принадлежит русификаторам клавиатуры IBM PC - на одной кнопке "Y[es]" и "Н[ет]").
***

Отсюда и родилась идея использовать, в основном, двухслойные окна: фоновая картинка + аппликация из текста, органов управления, иллюстраций и т.д (по возможности прозрачные).
Можно было бы немного усложнить, добавив рамку вокруг картинки - с органами управления на все случаи жизни. Однако, мне кажется, что той сложной рамки, которую мне навязывает Windows, и так достаточно.
***

Рассмотрим решения, применяемые в MD-интерфейсах:

Многооконность? Ведь, в чем прелесть окон?
- Возможность одновременного просмотра пары документов. В принципе, используется, обычно очень ограниченно - для сравнения текстов (часто форматированных), в меньшей степени - для сравнения картинок. Также, можно отметить, что большая часть подобных сравнений происходит между окнами, созданными разными экземплярами одной и той же программы, или между дочерними окнами одной и той же программы. Средства поиска различий документов в Windows практически отсутствуют.
- Возможность легкого перетаскивания из окна в окно документов в целом (в виде иконок, элементов списков), так их фрагментов (выделенных блоков). Перетаскивание блоков обычно используется в тех же ситуациях, что и сравнение окон. Там речь идет всегда о копировании фрагментов из одного документа в другой. Перетаскивание иконок-документов несет больше смысловой нагрузки, так как вид выполняемой операции очень сильно зависит от типа окна (иконки), в которое осуществляется перенос.
- Возможность использования в обоих этих случаях (сравнение и перетаскивание) стандартных MD-окон (браузеров, редакторов, корзин, портфелей и т.д.).
- Возможность легкого переключения между программами? Оно особо не требует никакой многооконности, достаточно самого факта наличия многозадачности и некоего общеоконного органа управления, содержащего список активных программ.

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

Многофреймовость? Роль этого механизма достаточно проста - вместить в одно окно больше, чем оно может вместить. Вместо окон-документов, сваливаемых обычно в беспорядочную кучу, система фреймов располагает документы и органы управления в виде плотной мозаики. Каждый фрейм имеет собственные инструменты прокрутки изображения, средства немного потеснить соседей или освободить им немного жизненного пространства, часто фреймы могут, в зависимости от потребности, переключаться на отображение другой информации, совсем убираться из окна или разворачиваться на все окно.
Разнообразные "подрамки" окна - меню, панели инструментов, статусные строки - тоже огульно буду считать фреймами.

ВозможностиОкнаФреймы
Взаимодействие с другими окнами на экране+-
Обработка большого количества однотипных документов+-
Возможность самостоятельной конфигурации рабочего стола, вплоть до разнесения информации на несколько мониторов+-
Перенос забот о дизайне с программиста на пользователя+-
Возможность использования большого количества инструментов, сложной диагностики и т.д.-+
Удобный поиск нужной информации в большой куче-+
Построение экранного образа документа в соответствии с его внутренней структурой-+

Органы управления (Controls)? Они являются некими кирпичами, из которых строится интерфейс, но по сложности своей превышают оба вышеприведенных класса:
- controls являются окнами и управляются программистом так же, как и окна (разве что, вместо того, чтобы написать процедуру управления control самому, программист должен вызывать бешеное количество специальных библиотечных),
- controls (кроме самых простых) представляют из себя тоже фрейм, состоящий из более простых controls. Правда, возможность ужаться или расшириться у control (или группы controls) сильно ограничены.

Связи между элементами? Их много:
- Кто кого породил.
- Кто внутри кого рисуется.
- Кто кому передает свои сообщения.
- Кто за кем следует в каком-либо порядке перебора...

Оценили? Умилились? И что со всем этим делать? Заключить в пузырек и перевязать розовым бантиком каждый возможный случай создания чего-либо графического? Или - выделить "достаточное" подмножество? Или - плюнуть и оставить "как есть" - общий метод реализации я сделал и описал, а про частные методы - читайте и реализуйте сами?
***

Прежде чем умствовать дальше, попробую ввести еще одну характеристику вычислительных средств - соответствие моим способностям. Действительно, существует некоторая скорость, с которой я могу писать, допустим, программу. Если возможности редактора или языка, на котором приходится писать, рассчитаны на другую скорость, работать будет неудобно. Например, я замечал, что наибольшая скорость написания программ для DOS достигалась в Multi-Editor (и она была по мне). В Windows наибольшую скорость можно развить в Визуальных Обезьянниках (например Borland C++ Builder), причем, эта скорость больше той, с которой я могу набирать программу. NotePad++, наоборот, меня тормозит, хотя он (как и MS Word) вполне соответствует моей скорости чтения и корректуры художественных текстов.
Тоже касается и языков программирования. Моя скорость - это FORTH и C. Язык Assembler-а и C++ очень тормозные (первый требует по много строк на каждый чих, а во втором процент рабочих операторов очень мал по сравнению с описательными). Perl и Python, возможно, рассчитаны на скорость ввода больше моей, по крайней мере, ошибки и побочные эффекты плодятся у меня как тараканы.
Что происходит при разнице скоростей? Например, надо что-то сваять на C++ в Borland C++ Builder. Писать начинаю гораздо раньше того момента, когда задача окончательно формализуется. Начинаю, как положено с иерархии классов, определяю все эти виртуальности и гомоморфности, пока не придумаю, как же решать задачу. Затем, наспех затыкаю дыры, чтоб заработало. Программа, конечно, работает, но приятного впечатления не производит.
***

Кроме того, надо учесть еще два противоречия интерфейсов:

- "Мышь - Клавиатура". Текстовые редакторы, в которых практически все можно сделать при помощи клавиатуры (например emacs), гораздо удобнее в работе (может быть, после некоторого привыкания), чем редакторы, в которых приходится постоянно отвлекаться на дергание мышкой (тот же MS Word). Доходит до смешного. Например, при постраничной печати документа хватило бы всего двух клавиш - "переход к следующей странице" и "печать текущей страницы", но именно их-то и нет - приходится возюкать мышкой.
К другим клавиатурно-ориентированным программам относится большинство игр, в которых игрок управляет только одним объектом - бойцом, самолетом, и т.п.
С другой стороны, межоконные сравнения и перетаскивания, о которых шла речь выше, иначе чем при помощи "мышинной возни" никак по-человечески и не реализуешь.

- "Меню - Controls". Одно вполне заменяет другое, что предпочесть - дело вкуса. А есть, ведь, еще "промежуточное решение" - контекстное меню, привязываемое к объекту, выбранному мышкой.

Возможно ли какое-то минимальное решение? Любая попытка построить таблицу "операции * органы управления" дает практически сплошное заполнение клеток "крестиками", за исключением нескольких редких случаев (операции над документом "в целом", использование "кармана"...). Так что, тут ловить нечего, разве что утвердиться в мысли, что надо создавать некие универсальные объекты функций обработки, автоматически добавляющие ссылки на себя во все списки органов управления, ведущиеся в окне (меню, кнопки, клавиши-акселераторы...).
Чего это будет стоить? Создания огромной библиотеки объектов на все случаи жизни? Или удастся свести все потребные функции в несколько классов (по типу операндов и операций)? Как быть в случае возникновения коллизий (например, одинаковых сочетаний клавиш)? Более того, сама возможность допущения вызова одной функции пятью-семью разными способами не кажется мне достойной затрат времени на ее реализацию (меня, скорее, заинтересует возможность автоматизации подобного вызова, например забиванием значений клавиш в буфер клавиатуры из другой программы).
Наоборот, привязывать функции к обобщенному вызывателю (конкретная реализация которого использует только один тип органов управления)? Но тогда, как этот "вызыватель" сорентируется в геометрии окна (сколько отводить места под кнопки, списки, картинки)?
avatar
Gudleifr
Admin

Сообщения : 879
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Приложения к заметкам о простых играх (интерфейсы)

Сообщение автор Gudleifr в Ср Авг 16, 2017 9:57 am

ПОПЫТКА ПОИСКАТЬ РЕШЕНИЕ НА СТОРОНЕ

Прочел книжку Джеффа Раскина "Интерфейс: новые направления в проектировании компьютерных систем" - PDF, 2.55Мб.
Во-первых, автор оказался мне близким по духу: он, так же, как и я, имеет слабость разбавлять изложение огромным количеством лирических отступлений и эпиграфов (как и у меня - до полной нечитаемости).
Во-вторых, невзирая на различия в терминологии, предложения Раскина достаточно прозрачно намекают на FORTH-ориентированность любых удачных решений в проектировании интерфейсов. Например, использование модели "существительное - глагол" (читай - постфиксная запись) и стека выборок.

Из практических решений, предложенных автором, следует безусловно упомянуть (в случайном порядке - как я запомнил):
- немодальность - т.е. отсутствие переключений интерфейса из одного режима в другой;
- монотонность - отсутствие вариантов вызова функций;
- выделение минимального множества классов функций;
- замена полос прокрутки масштабированием;
- универсальность текста - текст в любом месте интерфейса может обрабатываться (редактирование, проверка орфографии, макроподстановка...) и использоваться (поиск, копирование, вызов одноименной функции, формирование меню...) одинаково и одним набором функций;
- преобразование почти любого вида данных в любой другой, пригодный для пожирания вызванной пользователем функции;
- критический пересмотр существующих программных и аппаратных органов управления и их использования (а, заодно, механизмов хранения документов и устройства компьютеров в целом);
- безжалостное удаление из интерфейсов якобы страхующих и облегчающих управление команд, которые у компьютера хватит мозгов выполнить самому.

Неприятно поразили в этой книге только два момента:
- я так и не получил ответа на большинство своих вопросов,
- недостаточная программистская подготовка автора не позволила применить ему в своей работе удобный математический аппарат, более того, подозреваю, что, будучи созданным, такой аппарат опровергнет некоторые положения книги.
***

Самая грандиозная интерфейсная идея Раскина - фрактально-географическое размещение информации на мониторе. Идя состоит в том, чтобы отобразить на некотором огромном виртуальном экране все содержимое компьютера в виде огромной доски объявлений свободного формата. В качестве примера приведена система управления больничным комплексом. Пользователь при минимальном увеличении видит на своем терминале общий вид - географическую карту региона с размещением больниц. При максимальном увеличении весь экран занимает медицинская карта одного больного. Основной способ навигации (кроме тыканья мышкой в разные части карты) - текстовый пошаговый поиск (шаг состоит в добавлении пользователем к шаблону поиска следующей буквы и немедленном поиске программой текста, включающего новый шаблон).
Сразу бросается в глаза удачное использование рабочего пространства - экран двумерный, доска тоже двумерная, никаких операций проецирования не требуется. Навигация при помощи мышки и/или текстового поиска тоже кажется удобной - именно так я обычно и ищу информацию (по месту хранения и/или по содержанию).

Первый вопрос касается географии размещения информации на доске. В случае естественно-двумерных данных все просто, просто переношу их географию на экран. А, например, в случае некоторого вообще непредставимого комплекса данных, допустим, сложного программного комплекса на каком-нибудь C++? Заголовочное файлы должны отображаться внутри использующих их текстов? Или - слева? Или - справа, но в виде дерева? А сами тексты и библиотеки? А информация о компиляции? А результат прогона? Раскин уходит от данной проблемы очень просто - нечего использовать компьютер для вещей, непонятных обывателю. Математику же задача расчета роста заполненного информацией пространства на виртуальном экране покажется, наверное, занимательной. Вроде игры Конвея "Жизнь".

Второй вопрос, не будет ли ориентированность интерфейса на представление данных затруднять выполнение над ними каких-либо операций? Рассмотрим, например, переезд больного из одной больницы в другую.
- Находим больного (в худшем случае, по фамилии, перебрав сотню однофамильцев, но мы надеемся, что эту операцию выполняет тот, кто знает о ком идет речь и в какой он палате).
- Весь кусок информации о больном, а не только его фамилия, путем некоторых хитрых операций расширения выборки становится выбранным.
- Затем начинаем искать его новое пристанище. Мышкой, наверное, слишком долго, скорее начинаем набирать наиболее характерное слово в названии больницы. Нашли. На экране теперь - новая больница.
- Имело бы смысл уточнить пункт назначения, добавив к названию больницы номера корпуса, этажа, отделения, палаты, но Раскин не хочет и слышать о введении какой-либо явно определенной иерархии объектов, поэтому придется бросить больного в "приемном покое", а уже оттуда, установив нужное разрешение экрана перетащить мышкой в нужную палату.
- Для упрощения операции переезда имеет смысл создать дополнительный объект "автобус". Этот объект сможет сделать более безболезненным процесс переноса объектов при их переносах на большие "расстояния", требующих нескольких переключений масштаба.

Какие подобное решение вызывает проблемы?
- Наша стройная схема - "нет сущностей, кроме потребных", начинает обрастать вспомогательными объектами - "автобусами", "приемными покоями" и т.д., что здорово утяжелит систему.
- Процесс изъятия объекта из одного контекста и помещение его в другой требует некоторой обработки служебных данных, для которых Раскин не предусмотрел никакой "ниши" в своих рассуждениях. Например, я выдергиваю больного из палаты, т.е. вырезаю кусок (по мнению Раскина, чисто текстовый) из документа "Больница1" и переношу его в документ "Больница2". Что делать со всеми, в том числе неявными, ссылками из этого куска на документ "Больница1", например, с записью "Медсестра имярек должна сегодня в Ч часов сделать укол"? Никакого применения механизма баз данных автор не предусмотрел...
- Раскин, стремясь к минимизации воздействий пользователя и максимизации информации о прошлых воздействиях, хранимой компьютером, не предусмотрел никаких механизмов управления этим процессом. Например, между выборкой "Данные о больном" и выборкой "Больница2" вполне может вклинится несколько паразитных - "Город", "Район", "Соседняя больница".

Третий вопрос касается хранения динамических данных.
- "Где у нас Прокурор?- Там, где раньше Наполеон был." А где БЫЛ Наполеон? Считать, что запись с номером палаты появилась в документе "Наполеон" автоматически и ее можно найти? Но, тогда, сколько подобных автоматических записей будет в этом документе? Для всех проведенных с ним операций, включая отмененные?
- Пример из жизни. Попросили меня как-то написать базу данных небольшой гостиницы. Я, недолго думая, нарисовал что-то вроде предложенного Раскиным - псевдо-трехмерный (для красоты) план гостиницы, разместил на нем карточки постояльцев (с фотографиями)... Нет, говорят, нафиг нам это не нужно - нужна таблица вроде табельной с закрашенными клетками-днями, наглядно показывающими, какая комната когда освободится. Куда в схеме Раскина можно подобный документ засунуть? И когда засуну, как поддерживать связь между "планом" и "табелем"? Никак.

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


Последний раз редактировалось: Gudleifr (Ср Дек 06, 2017 1:18 pm), всего редактировалось 1 раз(а)
avatar
Gudleifr
Admin

Сообщения : 879
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Приложения к заметкам о простых играх (интерфейсы)

Сообщение автор Gudleifr в Ср Авг 16, 2017 10:01 am

РАЗБИЕНИЕ

Система КОМНАТ в том виде, как она приведена выше, конечно очень сырая, не говоря уже о том, что она очень игрушечно-ориентированная.
Попробуем ее разбить на более мелкие:

ЗАСТАВКА. Самая простая форма. Просто показ анимации. Если анимация генерируется динамически, тяготеет к вырожденной КАБИНЕ, если изобилует текстовыми фрагментами - к РАЗГОВОРУ.

РАЗГОВОР. Хотя эта форма кажется простейшей, она явно распадается на подклассы
- обычный MESSAGEBOX с кнопками - вариантами ответа;
- облегченная версия - выдача сообщения и кнопок в область текущей формы;
- сообщения, не требующие ответа (упрощеная ЗАСТАВКА);
- ожидание ответа в текстовой форме (под эту разновидность попадает и FORTH-консоль).

СРАТЕГИЧЕСКАЯ КАРТА. Пожалуй, единственная форма, где допустимы прокрутка изображения и изменение масштаба изображения (как показал Раскин, второе вполне заменяет первое). Для этой формы абсолютно необходим режим нанесения на фоновый рисунок (карту) аппликаций (иконок, топографических значков и т.д.). Основной орган управления - активные зоны экрана, связанные с аппликациями и элементами пейзажа, т.к. число этих зон ничем не ограничено.

МАГАЗИН. Наиболее "естественная" форма представления - ЭЛекткронная Таблица (ЭЛТ), состоящая из
- заголовка,
- строк с описанием "товара" (с иллюстрацией), органом управления для выбора (пометкой, кол-вом или парой-тройкой других параметров), вычисляемой "стоимости" (может быть составной);
- итога - вычисляемая сумма стоимостей (может, составная).
- кнопок принятия результата.
Применив здесь более универсальное средство - ЭЛТ, я предполагаю, что эта форма может быть применена и для других целей.

ЭНЦИКЛОПЕДИЯ. Если магазин - ЭЛТ, то эта форма - результат запроса к Базе Данных (БД). Как старый боевой конь, услышавший боевую трубу, я готов радостно ринуться в бой и начать здесь смаковать подробности моих старых наработок. Одни названия чего стоят: АМБA, ГЛЮКВА... Пока воздержусь, но замечу, что в некоторых случаях для навигации в БД можно использовать разновидность ЭЛТ. (Или, наоборот, удачная форма ЭНЦИКЛОПЕДИИ заменит МАГАЗИН?)

ЗАПИСНАЯ КНИЖКА. Это просто - текстовый редактор. С какими возможностями, пока неясно. Например, я могу реализовать гиперссылки прямо здесь, или использовать механизм АМБA.

КАБИНА. Хотел написать, что это единственная честно реал-таймовая форма, но потом вспомнил, что такими же свойствами должны обладать ТАКТИЧЕСКАЯ и СТРАТЕГИЧЕСКАЯ КАРТЫ, а ежели подумать (и учесть предложенную Раскиным схему выполнения компьютером команд автоматически и без уведомления пользователя), то элементы реал-тайм должны входить и во все остальные формы.

ПЛАН. Раскин бы сказал, что это разновидность СТРАТЕГИЧЕСКОЙ КАРТЫ (точнее специальное название для некоторого ее не очень крупного масштаба), но удобство этой формы для навигации и ее способность отражать изменение нашего ближайшего окружения делают ее наличие очень желательным. Более того, наверное, имеет смысл делать ее частью КОМНАТЫ.

ТАКТИЧЕСКАЯ КАРТА. Еще одно упрощение СТРАТЕГИЧЕСКОЙ КАРТЫ. Изменение масштаба, породившее изменение поведения игрока. Не перемещение и выбор (как на СТРАТЕГИЧЕСКОЙ КАРТЕ), но совершение каких-то действий (бой, решение головоломки, миниигра). Часто управляемым является один-единственный объект (персонаж). Другое отличие ТАКТИЧЕСКОЙ КАРТЫ от СТРАТЕГИЧЕСКОЙ - в том, что ее время жизни ограничено выполнением конкретной операции, когда в последнем случае подразумевается, скорее, существование формы на протяжении всего времени работы программы.

ПУЛЬТ. С одной стороны, упрощенная форма КАБИНЫ и ТАКТИЧЕСКОЙ КАРТЫ - т.е. тоже, что и там, но без динамической картинки и без ярко выраженной реакции компьютера на воздействия пользователя. Не осуществление какого-то действия, но подготовка к нему.
(С другой стороны, MD имеет специальный механизм для обеспечения этой функции - диалоговые панели. Однако, убогие Win-controls, допустимые в диалогах не позволяют сделать диалог хоть немного привлекательным. Уж лучше вернуться к ЭЛТ (с возможностью вставки анимированных иллюстраций)).

КОМНАТА. Самая общая форма (наравне со СТРАТЕГИЧЕСКОЙ КАРТОЙ). Пользователь тыкает мышкой в аппликацию вызывая самые разнообразные действия.

Другие формы. Очевидно, не упомянуто никаких форм, имеющих отношение к рисованию (разновидность ЗАПИСНОЙ КНИЖКИ?). Пиксельный редактор, наверное, не нужен - проще взять готовый, а, вот, простенький векторный может пригодиться.

Кроме того, нет никакой "охватывающей" формы (MDI-родителя). И, хотя, визуально MDI-форма никому не нужна, но сам механизм управления порождения и управления дочерними окнами надо к чему-то привязывать. Даже, если он будет реализован не средствами MDI, а путем "честного" MD-API, он, все равно нужен. Более того, т.к. controls - те же окна, ими надо управлять, т.е. иметь этот механизм встроенным в каждое окно.
***

Роль всякой формы - в осуществлении пользователем некого выбора, в широком смысле этого слова:
- ЗАСТАВКА. Выбор только между ожиданием окончания проигрывания и немедленным завершением. Оставить где-нибудь "дырку" для полного "магнитофонного" набора - пауза, стоп, промотка?
- ПЛАН, КОМНАТА. Выбор в чистом виде - куда ткнул, туда и попал. Добавлять возможность уточнения выбора в ПЛАНЕ путем его масштабирования? Нет, оставим это для СТРАТЕГИЧЕСКОЙ КАРТЫ. Отличие КОМНАТЫ - в разнородности альтернатив и вызываемых функций.
- РАЗГОВОР. Выбор с возможностью добавления новой альтернативы (набрать ответ руками).
- МАГАЗИН. Выбор с уточнением параметров (количество, качество...), возможно, множественный.
- ЭНЦИКЛОПЕДИЯ. Трехступенчатый выбор: сначала некоторого множества объектов, удовлетворяющих некому условию, затем - объекта(ов) из этого множества, после - действий над выбранным объектом.
- СРАТЕГИЧЕСКАЯ КАРТА, ТАКТИЧЕСКАЯ КАРТА, ПУЛЬТ, КАБИНА. Выбор с возможным уточнением действия над выбранным объектом (в порядке убывания этой возможности).
- ЗАПИСНАЯ КНИЖКА. Очень похожа на СТРАТЕГИЧЕСКУЮ КАРТУ, только активная зона одна - во весь экран. Выброр "объекта" - позиционирование курсора, выборка фрагмента.
***

Например, в голову приходят наиболее простые варианты:
- РАЗГОВОР: ДИАЛОГ - обмен репликами с персонажем (возможно, с наказанием или повтором при неудачном ответе), ОПРОС - устраиваемый нам экзамен с подсчетом заработанных очков.
- КОМНАТА: СТРЕЛКА - переход в другую форму, ОЖИДАНИЕ - в смысле, когда комната перейдет в нужное нам состояние.
- ЭНЦИКЛОПЕДИЯ: ИНФО - обычно несколько экранов, с простейшей навигацией.
- ТАКТИКА: ТЫЧКИ - нужно угадать, куда ткнуть мышкой, иногда в определенном порядке и/или с контролем времени.
- СТРАТЕГИЯ: ТЕРРИТОРИЯ - разной степени красивости карта, на которой отмечены доступные для посещения комнаты. Ни масштабирование, ни прокрутка не используются. Т.к. в большей части подобных игр практически никакие динамически перемещающиеся объекты на карте не присутствуют (только подсвечиваются доступные локации), то очень трудно отличить эту форму от плана или комнаты. Здесь ключевой признак - отображение общего хода игры.
- ЗАСТАВКА: МОНОЛОГ - кто-то что-то нам рассказывает и/или показывает, ПЕРЕБОР - иногда возможно перебрать несколько заставок из списка доступных.
- ПЛАН: КАРТА - все ее разновидности, кроме стратегической - выбор не только локации, но и персонажа, действия или еще чего-либо, возможно, чисто текстовый. Иногда - иерархическая. Практически всегда - часть более общей формы.
- КАБИНА: ЛАБИРИНТ - герой где-то плутает, АРКАДА - миниигра, РЕЗОНАНС - нужно совершать мышкой какие-то замысловатые движения, чтобы персонаж достиг нужного состояния, ПОПАДАНИЕ - нужно попасть мышкой в что-то движущееся, или кликнуть в определенный момент времени...
- ПУЛЬТ: ВЫБОР - в том случае, когда реакция на него осуществляется не сразу, а после подтверждения, ЗАДАЧА - какая-то нединамическая игра, головоломка...
- КНИЖКА: НАКОПИТЕЛЬ - обычно размазан по разным формам игры (например, энциклопедии). Записи игрока никогда не допускаются.
- МАГАЗИН: ПРЕДМЕТЫ - выбор с учетом ресурса (денег, доступности...), РЕСУРСЫ - управление ресурсами...
avatar
Gudleifr
Admin

Сообщения : 879
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Приложения к заметкам о простых играх (интерфейсы)

Сообщение автор Gudleifr в Ср Авг 16, 2017 10:02 am

ОБРАТНАЯ СБОРКА

Итак, перечислим кирпичики, из которых будет строится наше окно:
- Фоновая картинка, безусловно необходима она только в КАБИНЕ, во всех других формах - лишь желательна (где-то ее может заменить текст, где-то можно рисовать на "белом листе"). Возможны разновидности - динамическая (в КАБИНЕ), масштабируемая/прокручиваемая (на СТРАТЕГИЧЕСКОЙ КАРТЕ), анимированная (в ЗАСТАВКЕ), модифицируемая (подвид динамической - в ЗАПИСНОЙ КНИЖКЕ).
- Разметка (рамки, гриды, кнопочки, диаграммы и т.д. - т.е. рисование линий на экране) не является строго необходимой, но весьма полезна. Понятно, в большинстве случаев,- динамическая. Может быть частично анимированной - подсветка текущего элемента, вдавливание кнопки и т.д. Наиболее естественная реализация ПЛАНА.
- Аппликации делятся на иллюстрации и "топографические значки" (и то и другое - пиксельные картинки). Первые желательны в МАГАЗИНЕ и ЭНЦИКЛОПЕДИИ, вторые служат обозначением активных зон окна. Для первых желательно иметь возможность анимации, вторых - масштабируемости (для СТРАТЕГИЧЕСКОЙ КАРТЫ, реже, для КОМНАТ) и динамики (в ПУЛЬТЕ).
- Текст должен быть двух разновидностей - заблокированный и редактируемый. Возможность выделения и копирования должна быть предусмотрена для обоих видов. Желательна масштабируемость (и разные шрифты?).
- "Природные" Windows-controls допускаются только на рамке окна. Диалоговые панели не используются.
- Менеджер "подокон" должен базироваться на списках элементов каждого из приведенных типов (и, возможно, порожденных окон) и на привязке элементов к клеткам ЭЛТ.
avatar
Gudleifr
Admin

Сообщения : 879
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Приложения к заметкам о простых играх (интерфейсы)

Сообщение автор Gudleifr в Ср Авг 16, 2017 10:02 am

ВОЗМОЖЕН ЛИ "КОМНАТНЫЙ" ПОДХОД В СЛУЧАЕ "ОБЫЧНОЙ" ЗАДАЧИ?

Зацепился тут случайно за задачку: корректировать списки преподавателей-студентов. Все остальное - как бог на душу положит, только под Windows и на C++.
Сначала мне это показалось издевательством: ну создашь несколько типов окон, причем, по крайней мере одно будет присутствовать во многих экземплярах. Ну обвяжешь это все MDI-окном, по которому эти окна-списки будут разбросаны стопками и кучками... Так потом же замучаешься разрешать все коллизии перетаскиваний мышкой из окна в окно, и обеспечивать осмысленную реализацию команд копирования-вставки.
А если без этих MDI-стереотипов? Что есть? Две таблицы, объединенные связью многие-ко-многим. Нужно обеспечить как редактирование их самих, так и разнообразные перепривязывания. Как это сделать "по Раскину"?
Сначала подумал о размещении двух текстовых столбцов-списков по краям окна, а между ними - хитрой структуры связей, для красоты, возможно, отображающающей "географическое" размещение кафедр, деканатов и т.п. А потом осенило: так никакая связующая структура и не нужна!

Имеем на экране две страницы-столбца. Каждая разделена на две части - белую (в верху страницы) и серую (остальная часть), обе упорядоченные по алфавиту; и единственный "курсор". Курсор показывает текущую запись на одной из страниц, а белая часть другой страницы - связанные с ней записи. Курсор можно перекидывать со страницы на страницу, переходя от преподавателей к студентам и наоборот. Никакие перетаскивания мышкой не нужны, достаточно галочек у записей (поставишь у серой записи, та перепрыгнет в белую половину, снимешь у белой - уйдет в серую). Править содержимое записей можно прямо "по месту", никаких диалоговых окошек для этого не надо. Остается добавить только дополнительные точки-галочки для специального выделения записей да несколько специальных записей-кнопок - для операций прокрутки, сохранения-загрузки, добавления и удаления записей и т.п...
А если захочется сравнить несколько списков? Где то, за что мы любим окошки? Так, кто запретит запустить пару экземпляров этой программы? (Надо только следить за тем, чтобы они автоматически запускались в режиме "только для чтения").

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

На какую КОМНАТУ это больше похоже? Обилие текстовых операций, значит, ЗАПИСНАЯ КНИЖКА. Значит, надо предусмотреть в ней разбиение на поля. (Кто бы сомневался).
А если задача усложниться, и таблиц будет не две, а десять? Плодить (и связывать) уже не одиночные формочки, а наши продвинутые ЗАПИСНЫЕ КНИЖКИ? Или делать нашей "книге" сложное "оглавление"? Мне кажется, все проще. Нужно будет, просто, немного подумать и решить, что нам надо и как это проще реализовать.
avatar
Gudleifr
Admin

Сообщения : 879
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Приложения к заметкам о простых играх (интерфейсы)

Сообщение автор Gudleifr в Ср Авг 16, 2017 10:03 am

"ГЕНОТИП"

Например, есть рисунок "X-Fighter" с пояснениями. Как его отобразить? Возможны варианты:
- Рисунок - в центре, от него в стороны - сноски, возможно, в красивых рамочках.
- Рисунок. При наведении на его часть, всплывает пузырь с текстом.
- Рисунок - слева, пояснения - справа (в красивой рамочке). При перемещении мышки по рисунку текст пояснений переключается.
- Рисунок с числовыми пометками и с большой подписью-пояснением под ним (как в книгах)
- Наоборот, текст с всплывающим рисунком-иллюстрацией.
...

Это все "фенотипы". А "генотип"? В последнее время прихожу к выводу, что нужна КНИГА - текст на одной странице, рисунок - на другой (или наоборот, или оба текста, или оба рисунка). Важно только то, что выделению некоего слова-якоря на странице "слева" соответствует вывод новой страницы "справа"... Как вывести эти "страницы": рядом, одну поверх другой, одну скрыть...- дело конкретного фенотипа. В примере выше на одной странице пояснения, на другой - рисунок.

А как быть, если речь идет о некой форме/диалоге со многими полями? Никакой множественной связи "якорь слева - контрол справа"! Каждому якорю соответствует всегда новая страница! А то, что несколько страниц лишь представляют разные виды на одну и ту же форму, это "левую" страницу не волнует...

Т.е. я считаю, что "двухстраничного" генотипа хватит на любой интерфейс. Невзирая на то, по скольким панелькам раскидают наши "страницы" требования фенотипа. Сравнивая двухстраничный интерфейс с системами, упоминавшимися выше, можно отметить:
- Система КОМНАТ и интерфейс Раскина - "одностраничные".
- Интерфейс игры TransArctica, которую я привел, как пример КОМНАТНОЙ модели, явно двухстраничный.
- Также двухстраничный интерфейс применяется в игре Critical Path - см. в начале этой статьи.
- По сравнению с одностраничным интерфейсом, выигрыш очевиден - активная информация естественно делится на "важную" и "сиюминутную". Последнюю можно "перелистывать", не "забывая" первой (не переупаковывая данные).
- "Двухстраничность" многих оконных приложений является не плюсом, а минусом, например, требуя избыточных переключений с мышки на клавиатуру и обратно (тут Раскин был безусловно прав). Это потому, что там редактируемая информация оказалась на одной странице, а органы управления - на другой.

Где еще двухстраничная организация смотрится естественно?
- Текст с иллюстрациями/пояснениями.
- Наоборот, ведение заметок по мере чтения текста.
- Редактирование связи таблиц многие-ко-многим Базы Данных.
- Навигация в Базе Данных в стиле "список-объект" и/или "объект-атрибуты". (Контрпример: в редакторе Базы Данных Smalltalk использовалось аж пять "страниц").

Первые наметки к реализации:
- Всегда рассматривать общий случай - "страницы равноправны" - или отдельно различать более простые - "ведущая - ведомая"? Думаю, первое.
- Опыт HTML-реализации дал вид ссылки на страницу: "имя страницы-значения параметров", что позволяет вызывать одну и ту же страницу "по-разному". "Значения параметров" представляются в виде пар "параметр значение" и служат для настройки конкретного вида страницы, вода значений по умолчанию и/или настройки обратной связи.
- Опыт Баз Данных: это очень похоже на концепцию смены точки зрения. Т.е. текущее представление (страница) - выглядит как список кортежей БД (выдранных из одной или нескольких связанных таблиц), "видимых из некоторой точки", один из кортежей считается текущим. Возможны два вида смены точки зрения: выбор текущего кортежа "для более подробного рассмотрения" (например, переход от списка сотрудников к личной карточке), либо переход к связанной точке зрения (например к списку подчиненных этого сотрудника). В этом случае переходы первого рода естественно смотряться как обновление второй страницы. Однако, описанный выше пример с преподавателями-студентами, показывает, что все не так однозначно: там возникает смена точки зрения, связанная с перемещением фокуса между первой и второй страницами.
avatar
Gudleifr
Admin

Сообщения : 879
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Приложения к заметкам о простых играх (интерфейсы)

Сообщение автор Gudleifr в Ср Авг 16, 2017 10:04 am

ВЕРНЕМСЯ К НАШИМ FORMATАМ

Как выглядел ввод/вывод во времена FORTRAN? Операция содержала три параметра: номер устройства, шаблон, список переменных. Где шаблон представлял из себя описание преобразования из формата переменных в формат устройства - выдергивание чисел из текста на перфокарте при вводе и заполнение числами пробелов в печатаемой строке при выводе. Его классический вид - обычная строка текста с расставленными тут и там пометками "здесь число".
Позднее программисты сосредоточились на параметре "устройство" (т.е. "с кем обмениваемся"), а шаблон все больше и больше становился "просто еще одной строковой переменной". Дошло до того, что в некоторых библиотеках операция записывается как обращение к объекту-устройству со списком переменных и кусков шаблона вперемежку.
***

А, ведь, с точки зрения "генотипа", "кусок щаблона", привязываемый к переменной операцией ввода/вывода, это и есть идентификатор операции. И устройство, и способ преобразования переменной - это уже "фенотип". Для генотипа важно только то, что я ввожу "Число яблок" в переменную ЯБЛОКИ.
avatar
Gudleifr
Admin

Сообщения : 879
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Приложения к заметкам о простых играх (интерфейсы)

Сообщение автор Gudleifr в Ср Авг 16, 2017 10:04 am

ЛИНЕАРИЗАЦИЯ ИНТЕРФЕЙСОВ

Делал тут какую-то консольную игру и столкнулся с тем, как преобразовать в нее изначально графический интерфейс. Какие я знаю интерфейсы игр (см. выше "ограничения фенотипа")?

1. Набор "комнат", в каждой из которых может решать отдельные задачи. Как в квестах. Мол, на экране лаборатории можно заценить показания манометра, а на экране вездехода - связаться с Хьюстоном. Везде вид из глаз, заточенный именно под конкретную задачу. Переключение между "комнатами" - тычком в карту.

2. Оконная система - никуда особо не ходим, за исключением анимационных вставок и красивого задника, а тупо имеем все тот же "рабочий стол" в менюшках которого можно выбрать/вызвать диалоговые панели и для манометра и для вездехода.

3. Честное 3D - все комнаты честно строятся в пространстве и персонаж (вид из глаз или из-за спины) честно ходит по коридорам, останавливаясь перед приборами.

4. Карта квантована и игрок в 3/4 (или сверху) уныло бродит по многоклеточным локациям, заходя в комнаты и обшаривая ящики.

5. По современным ресурсам вполне можно было бы собрать интерфейс из кинофрагментов. Раньше метод использовался только в рельсовиках (дополнительные коротенькие фрагменты гибели персонажа) либо в диалогах (сами по себе короткие).

6. Проецирование - сплющивание 3D в 2D. Т.е. не добавление "честного мира" к "набору менюшек", а честное проецирование с сохранением значимых пропорций, расстояний, да и процесса беготни. "Сведение шутера к платформеру".

Как назло, мне досталась честно карточная игра (#6), которую в текст перевести сложнее всего. С горя даже изобрел добавление в текст второго измерения - времени. Т.е. текст может быть сделан "многослойным" путем вывода в его реальнов времени - бегущей строкой. Сначала - краткое описание текущей позиции, затем - все более подробные описания бсе большего количества частностей. Игрок останавливает вывод, как только посчитает, что прочел достаточно. Начальная же точка вывода, понятно, определяется положением "фишки игрока".
avatar
Gudleifr
Admin

Сообщения : 879
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Приложения к заметкам о простых играх (интерфейсы)

Сообщение автор Спонсируемый контент


Спонсируемый контент


Вернуться к началу Перейти вниз

Вернуться к началу


 
Права доступа к этому форуму:
Вы не можете отвечать на сообщения