KRIEGSSPIELE!

GUDLEIFR СОЛДАТИКИ FORTH gudleifr.h1.ru
 
ФорумФорум  КалендарьКалендарь  ЧаВоЧаВо  ПоискПоиск  ПользователиПользователи  ГруппыГруппы  РегистрацияРегистрация  ВходВход  

Поделиться | 
 

 02.01. БЕЗ НАЗВАНИЯ

Перейти вниз 
АвторСообщение
Gudleifr
Admin
avatar

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

СообщениеТема: 02.01. БЕЗ НАЗВАНИЯ   Пт Дек 08, 2017 10:52 am

ТОМ II. ЧЕЛОВЕК ИГРАЕТ С МАШИНОЙ
Строим игру из того, что есть.

ГЛАВА ПЕРВАЯ. БЕЗ НАЗВАНИЯ

Мои любимые произведения о воистину компьютерных играх:
ВЛАДИМИР ПИРОЖНИКОВ / НА ПАЖИТЯХ НЕБЕСНЫХ / 1982
МАРЕК БАРАНЕЦКИЙ / ПРАВО АЛЬТЕРНАТИВЫ / 1984
ДЭВИД БИШОФ / НЕДЕТСКИЕ ИГРЫ / 1983
Обратите внимание на даты. То ли публикация этих произведений пришлась на то время, когда я как раз решал, стоит ли мне становится программистом. И поэтому они у меня отложились все вместе. То ли это было осознание писательским сообществом того факта, что кибернетика умерла и можно быстренько подвести итоги?

ТЕКСТОВОЕ ПРОГРАММИРОВАНИЕ

В первой части заметок, я попытался рассмотреть вопрос создания простых игр на основе простых идей.
Конечно, мы видим, что, если какая-либо простая игра приобретает популярность, на ее основе делают сложную (и не одну). Причем сложность здесь подразумевается в виде т.н. "контента". Т.е. практически не имеет отношения к, собственно, игре, а выполняет лишь украшашательно-завлекательную функцию.
Тут, главное, не перепутать, что считать сложным. Да, нарисовать целый мир, в котором будет бегать герой, сложно. Но это сложность художника. А засунуть в этот мир трехмерную куклу игрока - сложность аниматора. А выдавать всю эту живую картинку со всеми тенями, бликами и брызгами на экран с приемлемой скоростью - сложность... да, программиста, но не того программиста, который сам играет в то, что делает, а несчастного работяги, погрязшего в технических описаниях "новейшего аппаратно-программного обеспечения, без использования которого ваша игра будет третьесортной".
Если мы хотим погрузится во все эти сложности, то играть придется, в первую очередь, в манагера, а не творца.
Я же хочу поиграть в программирование игр: придумать мир игры, в котором мне будет интересно творить; определить правила своей игры с будущим игроком; ограничить свои хотелки компьютерными возможностями (и, как сказано выше, гораздо более скромными своими возможностями).
Т.е. допустим, что простенькая игра-концепция нас не устраивает, мы хотим целый мир "на пределе собственной сложности". (Это такой закон кибернетики: управляющий должен быть сложнее управляемого).
***

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

Так что, единственный способ начать создавать что-то сложное,- сформулировать задачу просто. А т.к. она сложная, то просто ее можно сформулировать лишь сложными словами (в сложных типах данных).
Для этого у нас есть естественное средство - человеческий язык. На нем мы можем выразить все, что понимаем. Поэтому мы принимаем первое решение - в рамках нашего проекта будем работать только с текстовыми данными. Исполняемые файлы, музыка, картинки - это лишь простые данные, которые можно записать проще, чем словами.
***

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

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

СообщениеТема: Re: 02.01. БЕЗ НАЗВАНИЯ   Пт Дек 08, 2017 10:55 am

ПОСТАНОВКА ЗАДАЧИ

В наличии имеются кое-как распознанные, структурированные и местами переведенные правила "тактических" игровых систем (категория #3 настольных игр - "шашки", тип 1а военных игр - "абстрактные с миниатюрами"): StarGrunt II (уровень взвода), DirtSide II (уровень батальона) и FullThrust (космические схватки). Кроме того, есть "недостающее" дивизионное звено - правила BOOTS, TRACKS, AND HOVERSKIRTS (BOOTS, TRACKS, AND ROTORS), выдранные из Сети, как есть.
Надо:

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

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

1. Обычный текст. Снабженный гиперссылками, позволяет визуализировать практически что угодно. Обязательна возможность макроподстановок. С другой стороны, с текстом могут быть связаны некие соглашения о его верстке - отступы, выравнивание, шрифты, буквицы, иллюстрации и т.д.
2. ЭЛектронная Таблица (ЭЛТ). Объединяет в себе универсальную экранную форму и способ пересчета данных при изменении одного из них.
3. Реляционная База Данных (БД). Позволяет хранить множества данных в виде таблиц и выдавать их в виде виртуальных таблиц. Кроме того, может визуализировать/редактировать данные согласно их типам.
4. Иерархический документ. Годится не только для построения оглавлений (каталогов), но и для построения списковых БД. Желательна возможность хранения альтернативных путей к данным. И хранения макропеременных. И наличия операции сравнения поддеревьев - унификации.

Конечно, свойства этих объектов сильно зависят от размера данных, например, БД начинают жутко тормозить при больших размерах таблиц, ЭЛТ становятся совершенно неудобными, когда данные не влезают в экран, а хранение списков маленьких фрагментов в иерархических документах и вовсе выглядит страшно... Но, надеюсь, в нашем случае (формализации смысла, заложенного в одном-двух мегабайтах текста) их мощностей хватит.


Последний раз редактировалось: Gudleifr (Пт Фев 09, 2018 12:32 am), всего редактировалось 1 раз(а)
Вернуться к началу Перейти вниз
Посмотреть профиль Online
Gudleifr
Admin
avatar

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

СообщениеТема: Re: 02.01. БЕЗ НАЗВАНИЯ   Пт Дек 08, 2017 11:14 am

ИСТОРИЧЕСКАЯ СПРАВКА

Я очень люблю древнюю компьютерную литературу. Хотя она и гораздо требовательнее к уровню подготовки читателей (заставляя иногда исчирикивать по паре-другой листов бумаги при очередном "далее - очевидно"), но это окупается. Размышления с позиции "что нам надо от компьютера" вместо "берите, что дают" привлекают гораздо сильнее.
Поэтому просто сошлюсь на книгу: В.М.Брябрин, Программное обеспечение персональных ЭВМ, 1988 - ТЕМА #15, АБЗАЦ #386. Точнее, на подробное описание там системы Framework (с. 187-193). Пусть это и "давно обычные для нас вещи". Ведь, первая версия этой программы была создана в 1984 для процессора 8086 и монохромного дисплея и занимала в памяти всего три сотни килобайт (т.е. в тысячи раз меньше современных программ). Так что надо удивляться не примитивности и обычности тех программ, а беспомощности современного программирования, не способного создать ничего нового.
***

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

ОСНОВНЫЕ СВОЙСТВА СИСТЕМЫ FRAMEWORK. Система Framework (произносится "фреймворк") обеспечивает следующие основные возможности: создание и обработку текстовых материалов, структурное представление документов, использование электронных таблиц и баз данных реляциоиного типа, графическое представление данных. Пользователю, обладающему программистской квалификацией, система предоставляет специальный язык программирования - Fred, с помощью которого можно описать сложные алгоритмы управления процессом обработки данных.

Отличительной чертой системы Framework является принцип, согласно которому все создаваемые пользователем информационные объекты рассматриваются с единой точки зрения: все они объявляются фреймами. Фрейм - это некоторый универсальный носитель информации, который, в свою очередь, может состоять из фреймов или же содержит конкретные данные, представленные в виде текста, таблиц, записей базы данных илн графиков разного вида.

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

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

Disk Create Edit Locate Frames Words Numbers Graphs Print

Эти команды соответствуют основным режимам работы. Выбор команды в этом меню осуществляется одновременным нажатием клавиши Ctrl и клавиши с первой буквой имени команды. При этом выделяется соответствующая позиция меню, и вслед за этим появляется вспомогательное меню, которое как бы "выпадает" из главного. Вспомогательное меню имеет вид столбца, в строчках которого расположены слова, поясняющие отдельные операции. Выбор позиции вспомогательного меню осуществляется с помощью стрелок "Вверх", "Вниз" с последующим нажатием клавиши "Исполнение" (рис.5.16).

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

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

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

Список имен внешних накопителей - А:, С:, D:, Е: - размещается в правой части экрана в виде узкого столбца.


Рис.5.16. Вид экрана в начале работы с системой Framework

В правом нижнем углу экрана во время работы возникает столбец с именами активизированных фреймов - это список рабочих фреймов. На рис.5.16, являющемся графической копией экрана, в этом списке видны рабочие фреймы с именами "Оглавление", "Таблица", "Текст", "График".

МЕТАФОРА РАБОЧЕГО КАБИНЕТА. При работе с системой человек может представить себя находящимся в рабочем кабинете. Обстановка этого "кабинета", имитируемого системой, включает "шкафы", в которых лежат "папки" с документами. Кроме того, имеется "рабочий стол", который можно использовать, во-первых, для того, чтобы сложить на углу нужные папки, во-вторых, для того, чтобы на его рабочей поверхности можно было раскладывать папки и вынимаемые из иих документы и работать с ними.

Сначала пользователь видит лишь "шкафы", роль которых играют накопители с именами А:, С:, D:, Е: (рис.5.17). Первое действие, которое совершает пользователь,- "открыть шкаф". Для этого он выбирает с помощью курсора имя соответствующего накопителя, например, С:, и нажимает клавишу "Исполнение". В рабочей области возникает вертикальное окно-столбец с именами фреймов (файлов), находящихся на данном внешнем накопителе. Это "папки", лежащие в "шкафу".


Рис.5.17. Вид экрана при выборе рабочих фреймов

Далее из выведенного списка можно выбрать один или несколько фреймов, нажимая клавишу "Исполнение" в соответствующих позициях. Выбранные фреймы, точнее, их имена перемещаются в список рабочих фреймов в правом нижнем углу экрана. Эту операцию можно представить как вынимание нужных "папок" из "шкафа" и складывание их в стопку на углу стола. На рис. 5.17 видна стопка фреймов с именами Tabl, tx1, DB1.

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

Папка "открывается", если на нее указать курсором и нажать "Исполнение". При этом в рабочем поле появляется раскрытый фрейм с соответствующим содержимым. На рис.5.17 виден раскрытый фрейм типа "база данных". Его имя - DB1.

Далее можно "погрузиться" в данный фрейм и начать работу с его содержимым. Способ работы определяется типом фрейма. Текстовый фрейм можно редактировать. Электронную таблицу можно просматривать и заполнять информацией. Базу данных можно просматривать, заполнять, сортировать и производить в ней поиск по значениям выделенных полей. Графики, диаграммы и гистограммы можно строить по данным, выбираемым из электронной таблицы или базы данных. Можно создавать, просматривать и модифицировать структурированные документы. Это и есть основные типы фреймов.


Рис.5.18. Внд экрана с перекрывающими друг друга фреймами

Дисплейное окно, в которое выводится фрейм, можно перемещать по экрану и изменять его размеры. Один особый случай изменения размеров фрейма реализуется нажатием клавиши F9, после чего активизированный в данный момент фрейм показывается во весь экран. Эта операция называется Zoom (укрупнение). Повторное нажатие клавиши F9 возвращает окно с фреймом к прежнему размеру и ставит его на прежнее место в рабочей области экрана. Раскрытые в рабочей области фреймы могут частично или полностью перекрывать друг друга - точно так же, как лежащие на столе раскрытые папки с документами (рис.5.18).

Всем описанным выше действиям соответствуют обратные действия, которые обычно вызываются повторными нажатиями клавиши "Исполнение". Так, раскрытый фрейм - папку можно сложить и убрать назад в стопку на столе. Закрытые фреймы - папки можно убрать в "шкаф" или удалить совсем, если оии больше никогда ие понадобятся. Можно закрыть "шкаф", т.е. убрать с экрана окно с каталогом соответствующего накопителя.

Для выполнения таких операций, как удаление или сохранение фрейма на диске, нужно использовать главное управляющее меню, т.е. нажать клавиши Ctrl+<первая буква команды> и затем в соответствии с выведенным списком вспомогательного меню выполнить требуемую операцию. По ходу выполнения возможен небольшой диалог между пользователем и системой - по поводу имен файлов и пр.

Подобный способ действий сравнительно легко и быстро осваивается любым пользователем. Когда у пользователя появляются проблемы, он всегда может обратиться к системной "подсказке": нажатие специальной клавиши выводит на экран подробный текст с разъяснениями. Текст подсказки структурирован по разделам и содержит пояснения по всем возможным операциям.

"ОБРАБОТКА ИДЕЙ". Одна из замечательных возможностей в системе Framework связана с так называемой обработкой идей. Пользователь может начать работать с фреймом типа структурированный документ. При этом первое, что появляется в соответствующем дисплейном окне, это пронумерованный и пока безымянный перечень разделов. Пользователь может начать с того, что для каждой позиции этого перечня указать сначала только имя и тип соответствующего подраздела.

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


Рнс.5.19. Вид экрана при создании структурного документа

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

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

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

Каждый фрейм в системе отображается в отдельный файл ДОС. Это очень важное свойство, позволяющее создавать информационные модели и документы произвольной сложности (ограничением является лишь доступный объем внешних устройств).

При работе в системе Framework пользователь может временно прервать основной процесс и обратиться к ДОС, а затем вновь вернуться к прерванной работе. Следуя общему принципу, обращение к ДОС оформляется просто как вызов специального фрейма с именем DOS. Выйдя в ДОС, можно, например, запустить какую-либо программу и результаты ее работы передать назад в систему - в другой фрейм. Чтобы вернуться нз ДОС в Framework, достаточно дать команду EXIT. Эта возможность делает систему очень близкой по свойствам к операционным оболочкам, основной целью которых является интегрирование автономных программ.

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

Нас в этом отрывке должны интересовать не пользовательский интерфейс и (не)удобство офисного применения (например, столь же древний Multi-Edit может делать все тоже самое, но другими методами). Мы видим три очень важных для дальнейших экспериментов решения:
1. набор основных типов информационных блоков/фреймов - текст, ЭЛТ, таблица БД;
2. дополнение этого набора "связующим" иерархическим фреймом;
3. использование единого для всех блоков языка программирования - Fred. В рамках этого языка любой фрейм/часть фрейма имеет значение, которое можно вычислить и подставить в другой фрейм (практически соответствует обычным формулам ЭЛТ).
***


MindJet - более современный "интегратор". Работает с обычными "офисными" документами.


Последний раз редактировалось: Gudleifr (Вс Фев 04, 2018 11:05 am), всего редактировалось 1 раз(а)
Вернуться к началу Перейти вниз
Посмотреть профиль Online
Gudleifr
Admin
avatar

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

СообщениеТема: Re: 02.01. БЕЗ НАЗВАНИЯ   Пт Дек 08, 2017 12:06 pm

ЗАДАЧА 1 ("ПРАВИЛА"). ЭТАП 0 ("РУЧНЫЕ ОПЕРАЦИИ")

Сами по себе все эти замечательные текстовые "кирпичики" никакой задачи не решат.

Надо решить:
1. Как этими данными описать то, что нам надо?
2. Какие программы нужны для манипулирования ими?
3. Как запустить эти программы на нашей машине?



По сути, это те cамые три части задачи, которые постоянно решает программист ТЕМА #15, АБЗАЦ #388. И аксиома #3 говорит нам, что решаются эти три части почти независимо друг от друга.

Лучше, конечно, начать с первой, т.к. она, все-таки, главная.
***

Какие форматы данных нам понадобятся для записи "ПРАВИЛ" и организации к ним "РУЧНОГО ДОСТУПА"?

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

В идеале, конечно текст хорошо бы упаковать в БД. (Подходит агент Малдер к компьютеру и вбивает: "Найди что-нибудь интересное". А тот ему в ответ: "Заметка из газеты за 1934-й год... Заметка за 1962-й... Вампир на фотографии - тот же самый... Четвертый справа в кепке...") Однако, такое возможно только когда мы уже пересчитали все возможные варианты текстов, выделили и классифицировали все их признаки и параметры... Этот подход действительно встречается - в "простых книгах-играх" ТЕМА #20, для которых написаны многочисленные редакторы/проигрыватели, держащие автора в достаточно жестких шорах, не позволяя писать того, что не предусмотрено.

Как же записывать то, что еще не готово? Только допуская запись в "свободном формате" и разрешая гибкую систему адресации.

После экспериментов с введением в БД дополнительных таблиц-справочников и попыток свести все к XML, я остановился на чисто текстовом формате:
1. Описываются только "листья" нашего "дерева".
2. При описании каждого "листа" указываются все пути - "ветви" - которые к нему ведут от самого "корня".
Это напоминает дисковую систему Unix, где один файл может быть привязан к нескольким директориям одновременно.

Исторически примером этого метода служит эта "база компонентов" (табуляцию эаменил на #):
Цитата :
\Конденсаторы\Кривые от Пети\ELV
\Конденсаторы\Электролитические алюмининиевые\Для поверхностного монтажа\ELV
ТАБЛИЦА
C, мкФ

6,3В
10В
16В
25В
35В
50В
63В
100В

0,1 # - # - # - # - # - # - # A\1,0 # - # -
0,22 # - # - # - # - # - # - # A\2,0 # - # -
0,33 # - # - # - # - # - # - # A\2,8 # - # -
0,47 # - # - # - # - # - # - # A\4,0 # - # -
1 # - # - # - # - # - # - # A\8,4 # - # -
2,2 # - # - # - # - # - # - # A\13 # - # -
3,3 # - # - # - # - # - # - # A\17 # - # -
4,7 # - # - # - # - # A\16 # A\18 # B\20 # - # E\80
10 # - # - # - # A\23 # B\27 # B\29 # C\33 # - # E\90
22 # - # A\28 # B\33 # B\37 # C\42 # C\46 # D\80 # E\75 # E\130
33 # A\28 # B\37 # B\41 # C\49 # C\52 # C\58 # E\200 # E\160 # F\170
47 # A\33 # B\45 # C\52 # C\58 # C\60 # D\115 # E\240 # E\170 # -
100 # B\56 # C\70 # C\76 # C\86 # D\160 # E\280 # F\500 # F\240 # -
220 # C\96 # D\150 # D\190 # E\290 # E\300 # F\570 # - # - # -
330 # - # D\210 # E\330 # E\330 # F\680 # - # - # - # -
470 # - # E\380 # F\680 # F\690 # - # - # - # - # -
1000 # - # F\700 # - # - # - # - # - # - # -

F ELV: C=\V, U=\С, Корпус=\0, Iп=\1
V \RмкФ

\Конденсаторы\Подстроечные\Для поверхностного монтажа\TZVY2
ЗАПИСИ
-
Емкость.min
Емкость.max
Темпер.коэфф.
Q
Цвет

TVY2Z030A110 # 1,5 # 3,0 # NP0 # 300 # св.-зел.
TVY2Z060A110 # 2,5 # 6,0 # NP0 # 500 # св.-зел.
TVY2Z100A110 # 3,0 # 10,0 # NP0 # 500 # св.-зел.
TVY2Z200A110 # 4,5 # 20 # N750 # 500 # кор.
TVY2Z250A110 # 5,5 # 25,0 # N750 # 300 # кор.
TVY2Z450A110 # 8,0 # 45,0 # N1000 # 300 # св.-кор.

F TVY2Z\0A110: C=\V
V \2

\Конденсаторы\Подстроечные\Для поверхностного монтажа
ЗАПИСИ

030 # 1,5 # 3,0 # NP0 # 300 # св.-зел.
060 # 2,5 # 6,0 # NP0 # 500 # св.-зел.
100 # 3,0 # 10,0 # NP0 # 500 # св.-зел.
200 # 4,5 # 20 # N750 # 500 # кор.
250 # 5,5 # 25,0 # N750 # 300 # кор.
450 # 8,0 # 45,0 # N1000 # 300 # св.-кор.

F TVY2Z\0A110: C=\V
V \2

\Тарифы телефонной кампании\Вариант 3
ТАБЛИЦА
Никому не нужная, тренировочная таблица
-
ВЫСОКИЙ ТАРИФ
# 1-я м.
# доп.м.
СРЕДНИЙ ТАРИФ
# 1-я м.
# доп.м.
НИЗКИЙ ТАРИФ
# 1-я м.
# доп.м.

Плата за соединение # Прямой вызов # .30 # # .20 # .22 # # .15 # .12 # # .09
\'' # # # # Оператор # # 1.20 # # \'' # 1.12 # # \'' # 1.02 # # \''
ПЛЮС # \-
Плата за расстояние # \, # # # .12\100m # \, # .10\100m # \, # .06\100m # \,

F \R (\C): \V
V \0

\Pro'sKit\Отвертки\8PK-509
ТЕКСТ
Набор состоит из \3\-х плоских и \3\-х крестовых отверток. Отвертки имеют длинный стержень и удобны для работы с глубоко утопленными винтами. Рукоятки выполнены из литого пластика, стержень выполнен из сплава никеля, хрома и молибдена.

F Набор отверток \N
V \0 плоских + \1 крестовых

\Pro'sKit\Кусачки
ТЕКСТ
Широкий выбор высококачественного инструмента, изготовленного из специальной стали, подвергнутой высокотемпературной обработке, с прекрасной режущей способностью и длительным сроком службы.

F Кусачки \N (\M) \L
M сталь

\Сан Саныч
\Тарифы телефонной кампании\Сан Саныч
ТАБЛИЦА

САМ ДУРАК! # \-
Плата за соединение # Прямой вызов # .30 # # .20 # .22 # # .15 # .12 # # .09
\'' # # # # Оператор # # 1.20 # # \'' # 1.12 # # \'' # 1.02 # # \''
ПЛЮС # \-
Плата за расстояние # \, # # # .12\100m # \, # .10\100m # \, # .06\100m # \,

F Вещь от Сан Саныча: \N

\Сан Саныч\Кусачки
\Тарифы телефонной кампании\Сан Саныч\Кусачки

F Кусачки от Сан Саныча: \N

\Pro'sKit\Кусачки\Инструмент для точных работ
\Сан Саныч\Кусачки\Инструмент для точных работ
\Тарифы телефонной кампании\Сан Саныч\Кусачки\Инструмент для точных работ
ТЕКСТ
Длинные, однако!
Очен-но длинные.
Однако!

L 125мм

\Pro'sKit\Кусачки\Инструмент для точных работ\1PK-727
\Сан Саныч\Кусачки\Инструмент для точных работ\1PK-727
\Тарифы телефонной кампании\Сан Саныч\Кусачки\Инструмент для точных работ\1PK-727

\Pro'sKit\Кусачки\Инструмент для точных работ\1PK-717
ТЕКСТ
Сами таким инструментом работайте!

\Pro'sKit\Кусачки\Инструмент для точных работ\1PK-704

Какие полезные свойства я обнаружил у этого способа за годы его использования?
1. Для любой порции информации без труда находится место.
2. Поиск по базе производится очень удобно.
3. Избыточность минимальна.
4. Перенос, копирование, клонирование и прочие операции над "узлами дерева" сводятся к операции замены подстрок в путях.
5. Можно управлять показом содержимого листа в зависимости от пути, по которому к нему пришли.

Какие выявились недостатки?
Требуется придумывать дополнительные дисциплины управления путями в каждом новом проекте. Иначе существует что вновь вводимые пути вызовут неожиданные последствия.

Впрочем, игровое применение данного способа, как раз, и требует изобретение такой дисциплины как части правил игры.


Последний раз редактировалось: Gudleifr (Пт Фев 09, 2018 12:46 am), всего редактировалось 6 раз(а)
Вернуться к началу Перейти вниз
Посмотреть профиль Online
Gudleifr
Admin
avatar

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

СообщениеТема: Re: 02.01. БЕЗ НАЗВАНИЯ   Пт Дек 08, 2017 12:09 pm

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

Приняв текст как способ хранения данных, мы имеем выбор, которого у нас не было, если бы мы использовали специализированные/бинарные/архивированные данные. Если данные нельзя "просто прочитать" из файла, то любая операция их редактирования должна состоять из трех частей: считываем текст/файл в структуры данных, преобразуем, загоняем структуры обратно в текст/файл. Назовем такие операции ОБЩИМИ.

Пример решения, состоящего из оконного скрипта на Tcl/Tk с вызовом Perl-скриптов (одного большого, обеспечивающего выполнение ОБЩИХ операций, и кучи маленьких - на одну операцию):



Если же мы оперируем текстом, нам доступны еще два вида операций: ПОСЛЕДОВАТЕЛЬНЫЕ (прогоняем текст/файл через какой-либо фильтр, как это всегда делалось в Unix) и ЧАСТНЫЕ (вырезаем из текста/файла нужный фрагмент, правим его в обычном
текстовом редакторе, записываем обратно).

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

Надо сразу понять связь между этитми тремя видами операций:
1. Считывание файла в память для проведения ОБЩЕЙ операции само по себе практически является ПОСЛЕДОВАТЕЛЬНОЙ операцией.
2. Вырезание из файла куска для ЧАСТНОЙ операции может являться ПОСЛЕДОВАТЕЛЬНОЙ операцией.
***

Т.о. программирование ПОСЛЕДОВАТЕЛЬНЫХ операций должно предшествовать программированию ОБЩИХ и ЧАСТНЫХ просто потому, что первые обеспечивают последним среду обитания.

Для моих "деревьев" существует простейшая "пустая" ПОСЛЕДОВАТЕЛЬНАЯ операция - перебрать весь список листов, отслеживая тип читаемой информации. Т.е. т.к. описания "листов" в файле состоят из описаний путей, типов, заголовков и содержимого, операция должна в каждый момент понимать, что из этого она в данный момент читает.

Написав программу этой операции мы без труда получим нужные нам ПОСЛЕДОВАТЕЛЬНЫЕ операции просто подставляя нужный код в ее "пустые" места.

По сути это почти "Машина Тьюринга", программа которой, как известно, представляет из себя таблицу

Символ * Состояние = (Нов.Символ, Нов.Состояние, Сдвиг.Курсора).

Наша машина проще, за единственным исключением: "Символы"-строки определяются регулярными выражениями.
Зато, "Нов.Символ" не используется. А "Сдвиг.Курсора" означает, лишь, ввести новую строку или оставить текущей старую.

Всего используется семь "Символов":
- пустая строка;
- строка, начинающаяся с "обратной косой" ("путь");
- строка с единственным словом ТЕКСТ;
- ... ТАБЛИЦА;
- ... ЗАПИСИ;
- строка начинающаяся с пары "латинская буква" и "пробел" ("параметр");
- любая другая строка.

И пять "Состояний":
- Garbage (мусор) - информация вне "листов";
- Path (путь) - путь к листу;
- Head (заголовок) - текст заголовка для "листов" типов ТАБЛИЦА и ЗАПИСИ;
- Text (текст) - текст "листа";
- Param (параметр) - параметры "листа".

СостояниеСимволНов.Состояние, строка
GarbageОбратная косаяPath, сохраняется
GarbageПустаяGarbage, новая
GarbageВсе остальныеGarbage, новая
PathОбратная косаяPath, новая
PathТАБЛИЦА или ЗАПИСИHead, новая
PathТЕКСТText, новая
PathЛитера и пробелParam, сохраняется
PathПустаяParam, новая
PathВсе остальныеGarbage, сохраняется
HeadПустаяText, новая
HeadВсе остальныеHead, новая
TextПустаяParam, новая
TextВсе остальныеText, новая
ParamОбратная косаяPath, сохраняется
ParamЛитера и пробелParam, новая
ParamПустаяGarbage, новая
ParamВсе остальныеGarbage, сохраняется

Можно заметить, что новую строку требуется ввести, если текущая заведомо обработается этим Состоянием (Нов.Состояние равно старому), или текущая строка не несет никакой дополнительной информации, кроме "переключательной" (пустая, тип "листа"). Сохраняется же строка, если осуществляется переход из "чужого" для нее Состояния, в Нов.Состояние, способное ее обработать.


Последний раз редактировалось: Gudleifr (Ср Фев 14, 2018 11:31 am), всего редактировалось 9 раз(а)
Вернуться к началу Перейти вниз
Посмотреть профиль Online
Gudleifr
Admin
avatar

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

СообщениеТема: Re: 02.01. БЕЗ НАЗВАНИЯ   Пт Дек 08, 2017 12:32 pm

Теперь, запрограммировав нашу задачу, мы можем ее запустить, переписав на одном из доступных нам языков.

Что выбрать?
1. Я за все годы использования этой машиной использовал только один способ реализации - на Perl, визуализируя полученный результат на Html своей странички (реже на Tcl/Tk - см.выше).
По тем временам это был почти идеальный способ программирования "на голом Windows". Заведи себе бесплатный хостинг и программируй свои CGI-программы на Perl или даже C, не имея на своей машине ничего, кроме текстового редактора и средств доступа к Сети. К сожалению, эта холява кончилась - ТЕМА #7.


Отработала ОБЩАЯ операция преобразования comp.txt в HTML путем построения в памяти полного "дерева".
(Обратите внимание на то, что кусачки 1PK-727 висят сразу на двух "ветках"):

Что можно сказать о "красоте" этой реализации? Она короткая и, по сравнению с другими, имеет минимальную избыточность и минимум ограничений на формат строк и размер файла. (Хотя, конечно, даже минимальная Perl-избыточность раздражает сильнее любой другой, т.к. язык-то позиционируется, как наиболее лексически совершенный).

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

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

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

3. Наиболее же наглядной реализацией остается старый добрый GW-BASIC.
- BASIC был основным языком первой части заметок.
- Как ни крути, различные BASIC-и являются основными языками программирования на IBM PC. Их достаточно легко найти: скачать GWBASIC.EXE (и, если захочется графики - dosbox, который обычно используют для запуска DOS-овских игр); или скачать любой из MS Visual Basic-ов (например, Visual Basic 3.0); или воспользоваться VBA из MS Office; или просто воспользоваться имеющимся в наличии WHS...
- Из всех BASIC-ов, GW-BASIC самый простой. Если уж на нем удастся написать все, что нам надо, то переписать на чем угодно не будет проблемой. В нем нет такого обилия мусора, как в более поздних версиях, и программы могут остаться читаемыми.

1000 REM GARBAGE
1010 IF LEN(S$)=0 THEN 2100
1020 IF LEFT$(S$,1)="\" THEN 2000
1030 GOTO 2200
1100 REM PATH
1110 IF LEN(S$)=0 THEN 2300
1120 IF MID$(S$,2,1)=" " THEN 2400 1130 IF LEFT$(S$,1)="\" THEN 2500
1140 IF LEFT$(S$,5)="ТЕКСТ" THEN 2600
1150 IF LEFT$(S$,7)="ТАБЛИЦА" THEN 2700
1160 IF LEFT$(S$,6)="ЗАПИСИ" THEN 2800
1170 GOTO 2900
1200 REM HEAD
1210 IF LEN(S$)=0 THEN 3000
1220 GOTO 3100
1300 REM TEXT
310 IF LEN(S$)=0 THEN 3200
1320 GOTO 3300
1400 REM PARAM
1410 IF LEN(S$)=0 THEN 3600
1420 IF LEFT$(S$,1)="\" THEN 3500
1430 IF MID$(S$,2,1)=" " THEN 3400
1440 GOTO 3700

2000 REM GARBAGE - ОБРАТНАЯ КОСАЯ - PATH
2090 GOTO 1100
2100 REM GARBAGE - ПУСТО - GARBAGE
2190 LINE INPUT#1, S$: GOTO 1000
2200 REM GARBAGE - ПРОЧЕЕ - GARBAGE
2290 LINE INPUT#1, S$: GOTO 1000
2300 REM PATH - ПУСТО - PARAM
2390 LINE INPUT#1, S$: GOTO 1400
2400 REM PATH - БУКВА+ПРОБЕЛ - PARAM
2490 GOTO 1400
2500 REM PATH - ОБР.КОСАЯ - PATH
2590 LINE INPUT#1, S$: GOTO 1100
2600 REM PATH - "ТЕКСТ" - TEXT
2690 LINE INPUT#1, S$: GOTO 1300
2700 REM PATH - "ТАБЛИЦА" - HEAD
2790 LINE INPUT#1, S$: GOTO 1200
2800 REM PATH - "ЗАПИСИ" - HEAD
2890 LINE INPUT#1, S$: GOTO 1200
2900 REM PATH - ПРОЧЕЕ - GARBAGE
2990 GOTO 1000
3000 REM HEAD - ПУСТО - TEXT
3090 LINE INPUT#1, S$: GOTO 1300
3100 REM HEAD - ПРОЧЕЕ - HEAD
3190 LINE INPUT#1, S$: GOTO 1200
3200 REM TEXT - ПУСТО - PARAM
3290 LINE INPUT#1, S$: GOTO 1400
3300 REM TEXT - ПРОЧЕЕ - TEXT
3390 LINE INPUT#1, S$: GOTO 1300
3400 REM PARAM - БУКВА+ПРОБЕЛ - PARAM
3490 LINE INPUT#1, S$: GOTO 1400
3500 REM PARAM - ОБР.КОСАЯ - PATH
3590 GOTO 1100
3600 REM PARAM - ПУСТО - GARBAGE
3690 LINE INPUT#1, S$: GOTO 1000
3700 REM PARAM - ПРОЧЕЕ - GARBAGE
3790 GOTO 1000

Данная реализация имеет ограничение на длину строк и, при использовании в ОБЩЕЙ операции, на размер файла, но, зато, самая понятная из всех, невзирая на все эти GOTO.

ОБЩАЯ операция построения полного "дерева" в памяти выглядит тогда так:

100 OPTION BASE 1:DIM P$(1024),L(1024): P=1024
110 DEF FNH(H,I)=((H*17+ASC(MID$(S$,I,1)))AND 1023)+1
200 DIM T(1024),C(1024),B(1024): Z=1

2510 GOSUB 6000

4000 REM ВСТАВКА ПОДСТРОКИ MID$(S$,N..K) В ХЭШ-ТАБЛИЦУ
4010 H=0
4020 FOR I=N TO K
4030 H=FNH(H,I)
4040 NEXT I
4050 Y=H
4060 IF MID$(S$,N,K-N+1)=P$(H) THEN RETURN
4070 H=L(H): IF H GOTO 4060
4080 IF P$(P)<>"" THEN P=P-1: GOTO 4080
4090 P$(P)=MID$(S$,N,K-N+1)
4100 L(P)=L(Y): L(Y)=P: H=P: RETURN

5000 REM ДОБАВЛЕНИЕ H К УЗЛУ T
5010 GOSUB 4000: C=C(T): B=0
5020 IF C GOTO 5060
5030 Z=Z+1: X=Z: T(X)=H
5040 IF B THEN B(X)=B(B): B(B)=X: T=X: RETURN
5050 B(X)=C(T): C(T)=X: T=X: RETURN
5060 IF T(C)=H THEN T=C: RETURN
5070 IF P$(T(C))<P$(H) THEN B=C: C=B(C): GOTO 5020
5080 GOTO 5030

6000 REM РЕГИСТРАЦИЯ ПУТИ
6010 T=1: N=2
6020 K=INSTR(N,S$,"\")
6030 IF K=0 THEN K=LEN(S$) ELSE K=K-1
6040 GOSUB 5000: N=K+2
6050 IF K<LEN(S$) GOTO 6020
6060 RETURN

Т.е. "дерево" строится в момент получения очередной "ветви" ("обратная косая" в состоянии Path). Дополнительные процедуры хранения строк (4000) и ветвей (5000) в ассоциативных массивах (и, особенно, большое количество связанных с этим служебных массивов - P$(), L(), T(), C(), B()) - на совести несовершенства GW-BASIC-а (и нашего желания писать на нем "правильно"). Очевидно, что более одной-двух таких "операций" BASIC-программа "не потянет" - станет слишком сложной для нашей игры.

4. Т.к. мне придется встраивать эту машину в НTML, уже без возможности нормального хостинга, то потребуется реализация на самом дебильном из всех известных мне языков программирования - на Java Script. Не хочу об этом говорить.


Последний раз редактировалось: Gudleifr (Ср Фев 14, 2018 11:58 am), всего редактировалось 5 раз(а)
Вернуться к началу Перейти вниз
Посмотреть профиль Online
Gudleifr
Admin
avatar

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

СообщениеТема: Re: 02.01. БЕЗ НАЗВАНИЯ   Ср Дек 20, 2017 8:06 pm

ОСНОВНАЯ ПОСЛЕДОВАТЕЛЬНАЯ ОПЕРАЦИЯ - ВЫРЕЗАТЕЛЬ

Просто так, приведенная пустая ПОСЛЕДОВАТЕЛЬНАЯ операция никому не интересна. Каким полезным смыслом ее можно наполнить?

Присмотревшись к проблемной части своей задачи, я обратил внимание на возможность наличия универсальной ПОСЛЕДОВАТЕЛЬНОЙ операции. Этот "кирпичик" - операция вырезания из файла куска информации. На входе - полный файл, а на выходе - остаток файла и вырезанный кусок. Это кажется естественным,  ведь разбиение информации по отдельным файлам в этой задаче встречалось постоянно (объединение заметок, сделанных на разных машинах, ускорение загрузки в сеть, попытки реорганизации материала). Возражения против постоянного перелопачивания файла при вырезании/слиянии не существенны. При современных объемах/скоростях это все почти ничего не весит.

Наблюдается некоторая аналогия с SQL - там тоже операция SELECT выполняет львиную долю работы. Только ее результат не может быть слит с общим файлом. Приходится для его изменения использовать другие операции.

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

Вторая машина, которая будет сортировать/вырезать строки (выдаваемые нашей первой машиной), тоже достаточно проста. Она должна уметь исполнять операции:
U - рассматривать текущую строку, как заведомо полезную;
S - рассматривать текущую строку, как заведомо бесполезную;
A - добавить текущую строку к потенциально полезным;
C - перевести потенциально полезные строки в заведомо полезные;
B - перевести потенциально полезные строки в заведомо бесполезные;
E - записать пустую в заведомо полезные;
T - записать пустую в заведомо бесполезные.

Сложность заключается не в командах, а в условиях их выполнения. Какая команда выполняется, зависит от...
... текущего Состояния и Символа (17 описанных выше ситуаций), в т.ч. обрабатывается ли текущая строка или передается для обработки далее,
... того, куда засунули предыдущую строку - команды U (C или E), A, S (B или T),
... того, закончен ли предыдущий блок пустой строкой - два флага: для полезных и бесполезных (можно избежать, добавляя пустые строки в конце всех блоков);
... того, подходит ли текущая строка (в ситуации A) под условие "вырезания" (*).

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

СитуацияU*ASНовый флаг
G\P, G0GIE-BT-A
GXGI, HXHI, TXTIUCUA-По операции
P0LI--BS-По операции
PLL--BTS-По операции
P\PI, PTTI, P#HI, PRHI--A-По операции
PXG--BT-A
H0TIU-A-По операции
T0LIU-BS-По операции
LLLIU--SПо операции
L\P, LXG----A
L0GIE--TA
Конец--B--
***

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

ОТРИСОВАТЬ(фигулька, условие, флаг)

Только "условие" (да, и "флаг") состоит из сложной комбинации условий. Как мы сожем их скомпилировать? Очевидно, в битовые шкалы, которые, содержат единички в позициях возможных операций внутри групп, определяемых условиями.

5000 REM OБРАБОТКА КОМАНД
5010 IF F<>768 THEN 5040 'СТОЛБЕЦ УСЛОВИЯ U
5020 IF O AND 256 THEN GOSUB 4000: GOTO 5130 'E
5030 IF O AND 512 THEN GOSUB 4500: GOTO 5130 'U
5040 IF F<>120 THEN 5100 'СТОЛБЕЦ УСЛОВИЯ A
5050 IF O AND 128 THEN IF INSTR(S$,"о") THEN GOSUB 4300: GOTO 5130 'ДОПОЛНИТЕЛЬНО *
5060 IF O AND 64 THEN GOSUB 4200: GOTO 5130 'A
5070 IF O AND 32 THEN GOSUB 4400 'B
5080 IF O AND 16 THEN GOSUB 4600 'T
5090 IF O AND 8 THEN GOSUB 4100: GOTO 5130 'S
5100 IF F<>6 THEN 5130 'СТОЛБЕЦ УСЛОВИЯ S
5110 IF O AND 4 THEN GOSUB 4600: GOTO 5130 'T
5120 IF O AND 2 THEN GOSUB 4100 'S
5130 IF O AND 1 THEN F=120 ' УСТАНОВКА УСЛОВИЯ A
5140 RETURN

Сами операции - ровно то, что мы хотим сделать со строками. Константы в комментариях - те, что использованы в коде обработки.

4000 REM ОПЕРАЦИЯ U. ГРУППА 768. ФЛАГ 256.
4010 PRINT#2,S$: F=768: RETURN
4100 REM ОПЕРАЦИЯ S. ГРУППЫ 120 И 6. ФЛАГИ 8 И 2.
4110 PRINT#3,S$: F=6: RETURN
4200 REM ОПЕРАЦИЯ A. ГРУППА 120. ФЛАГ 64. ФЛАГ УСТАНОВКИ 1.
4210 F=120: A=A+1: A$(A)=S$: RETURN
4300 REM ОПЕРАЦИЯ CU. УСЛОВИЕ 120. ФЛАГ 128.
4310 IF A=0 THEN 4000
4320 FOR I=1 TO A: PRINT#2,A$(I): NEXT I
4330 A=0: GOTO 4000
4400 REM ОПЕРАЦИЯ B. ГРУППА 120. ФЛАГ 32.
4410 IF A=0 THEN RETURN
4420 FOR I=1 TO A: PRINT#3,A$(I): NEXT I
4430 A=0: RETURN
4500 REM ОПЕРАЦИЯ E. ГРУППА 768. ФЛАГ 512.
4510 PRINT#2,"": RETURN
4600 REM ОПЕРАЦИЯ T. ГРУППЫ 120 И 6. ФЛАГИ 16 И 4.
4610 PRINT#3,"": RETURN

Остается только для каждой строчки таблицы вставить в код "пустой" машины нужную шкалу:

2010 O=561: GOSUB 5000
2110 O=561: GOSUB 5000
2210 O=448: GOSUB 5000
2310 O=40: GOSUB 5000
2410 O=56: GOSUB 5000
2510 O=64: GOSUB 5000
2610 O=64: GOSUB 5000
2710 O=64: GOSUB 5000
2810 O=64: GOSUB 5000
2910 O=49: GOSUB 5000
3010 O=320: GOSUB 5000
3110 O=448: GOSUB 5000
3210 O=296: GOSUB 5000
3310 O=448: GOSUB 5000
3410 O=258: GOSUB 5000
3510 O=1: GOSUB 5000
3610 O=517: GOSUB 5000
3710 O=1: GOSUB 5000

Конечно, можно упростить, перенести безусловную установку флага A в блок "вызовов", поджать разреженные шкалы... Но, здесь, нам важнее понять, что "табличное" решение гораздо проще "елочек" if-then-else и case... Пусть, даже и придется исписать пару салфеток в "Метрополе".
***

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

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

Однако, обычно полезны гораздо более ограниченные "вырезатели": точно этого (выбранного) листа, всего мусора, некой подстроки в любом месте листа, всех листов с русским текстом...

Наоборот, для выдачи полной информации о листе: всех его предках и потомках по всем путям, наследовании параметров по текущему пути, одной ПОСЛЕДОВАТЕЛЬНОЙ операции мало. Проще использовать ту же ОБЩУЮ операцию с построением полного дерева.


Последний раз редактировалось: Gudleifr (Вс Фев 18, 2018 11:10 pm), всего редактировалось 7 раз(а)
Вернуться к началу Перейти вниз
Посмотреть профиль Online
Gudleifr
Admin
avatar

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

СообщениеТема: Re: 02.01. БЕЗ НАЗВАНИЯ   Чт Дек 21, 2017 10:55 pm

ЕЩЕ ОДНА УТИЛИТА

Выше были рассмотрены простейшие "навигатор" и "вырезатель" из базы данных.
Осталось чисто формально добавить к ним "добавлятор".
Теперь полный цикл работы ОБЩИХ, ПОСЛЕДОВАТЕЛЬНЫХ и ЧАСТНЫХ операций будет замкнут.
***
Программа развешивания на "ветвях" базы-"дерева" фрагментов-"листьев", очевидно, должна состоять из двух частей: буфера редактирования, куда будет загружаться очередной фрагмент (возможно использование дополнительной подпрограммы-вырезателя для подгрузки из другой части базы), и некоторого генератора путей (я убедился на своем опыте, что копирование и модификация путей от листа к листу составляет значительную часть работы).


На заднем плане - просмотрщик базы, слева - "эрзац-вырезатель" - Perl-скрипт вырезал кусок, который я засунул в текстовый редактор,
справа - "добавлятор". Кроме того, текстовый редактор, сам играет роль ОБЩЕГО супер-управлятора (пока база мала, его хватает).
Пока это очень мало похоже на игру.


Последний раз редактировалось: Gudleifr (Пт Фев 09, 2018 1:05 am), всего редактировалось 1 раз(а)
Вернуться к началу Перейти вниз
Посмотреть профиль Online
Gudleifr
Admin
avatar

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

СообщениеТема: Re: 02.01. БЕЗ НАЗВАНИЯ   Чт Дек 28, 2017 12:54 pm

ПРИМЕР УНИВЕРСАЛЬНОЙ НАВИГАЦИИ В БАЗЕ ДАННЫХ

Оставшись без сервера, я остался и без естественного способа визуализации - HTML. Но, нет худа без добра. Появился повод подумать и о том, что и как выводить на экран.
***

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

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

ПРИМЕР
Для больших баз данных я давно придумал систему "точек зрения". Т.е. сеть запросов, между которыми возможны переходы согласно логики работы с данными. На SQL-баз оказалось достаточным добавить к любой базе данных всего две таблицы:

Цитата :
9. Общие сведения.
Система интерактивной навигации в базе данных ГЛЮК основана на использовании двух служебных таблиц - СОСТОЯНИЙ и СВЯЗЕЙ. В каждый момент времени пользователь имеет какую-то информацию о текущей точки зрения на базу, список сущностей, видимых из этой точки,  возможность получить доступ к любой из этих сущностей и, наконец, возможность изменить точку зрения, обычно, опираясь на текущую сущность. Таблица СОСТОЯНИЙ содержит описания этих точек зрения а таблица СВЯЗЕЙ - переходы между ними. Здесь приведен пример реализации системы ГЛЮК в рамках ВАСЕЦ-Jet.

10. Таблица СОСТОЯНИЙ.
ЗАГ - заголовок точки зрения.
ТИП - наличие иерархии в списке сущностей (поля ИЕР в запросе ВЫБ).
ВЫБ - SELECT *,... AS ИД, ... AS ИМЯ [, ... AS ИЕР] FROM ... - начало запроса для получения списка объектов (ИД - первичный ключ;
ИМЯ - терминал - имя сущности; ИЕР - внутренняя ссылка).
ГДЕ - WHERE ... - внутренние условия.
ПРД - ORDER BY имя поля ИМЯ или ИЕР - упорядочение списка сущностей.
ОБЪ - запрос для получения доступа к выбранной сущности.

11. Таблица СВЯЗЕЙ.
СТАР - точка зрения - родитель (номер в СОСТОЯНИЯХ).
НОВ - точка зрения - потомок (номер в СОСТОЯНИЯХ).
ЗАГ - новый заголовок потомка.
ТИП - сохранит ли потомок иерархию.
ИЗ - довесок к ВЫБ - имена промежуточных таблиц.
ДОБ - довесок к ГДЕ - условия порождения.
ПВБ - запрос вспомогательной выборки.

12. Пример кортежа из таблицы СВЯЗЕЙ.
Идя от сотрудника подразделения, получить список сотрудников всех подчиненных подразделений:
ЗАГ = "СОТРУДНИКИ ПОДЧИНЕННЫХ ПОДРАЗДЕЛЕНИЙ";
СТАР = СОТРУДНИКИ;
ТИП = безразлично, т.к.  СОТРУДНИКИ.ТИП=НЕТ;
НОВ = СОТРУДНИКИ;
ИЗ = "ПОДРАЗДЕЛЕНИЯ,СТАВКИ";
ДОБ = "СТАВКИ.СОТРУДНИК=СОТРУДНИКИ.СОТРУДНИК AND СТАВКИ.ПОДРАЗДЕЛЕНИЯ=ПОДРАЗДЕЛЕНИЯ.ПОДРАЗДЕЛЕНИЕ AND ПОДРАЗДЕЛЕНИЯ.ИЕРАРХИЯ LIKE '<ВРМ>*'";
ПВБ = "SELECT ПОДРАЗДЕЛЕНИЯ.ИЕРАРХИЯ AS ВРМ FROM ПОДРАЗДЕЛЕНИЯ, СТАВКИ WHERE ПОДРАЗДЕЛЕНИЯ.ПОДРАЗДЕЛЕНИЕ=СТАВКИ.ПОДРАЗДЕЛЕНИЕ AND СТАВКИ.СОТРУДНИК=<СОТРУДНИК>".

Результаты запрсов легко втюхивались в универсальную форму-просмотрщик:

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

Оказалось, что схожая механика работает и для описанного выше формата данных (кстати, он называется ГЛЮКВА). ПУТЬ - он и там, и там путь, ОБЪЕКТЫ - листьев-наследников, СВОЙСТВА - текст и параметры листа, ТЕМЫ - альтернативные пути к этому листу... Эта штука работала у меня на страничке. Правда, кроме удобства навигации, она с успехом служила эффективной "защитой от дурака"...

Дальнейшее совершенствование этого подхода должно бы привести к фукциональному разделению экранных форм, навроде "комнатной модели" ТЕМА #34...


Последний раз редактировалось: Gudleifr (Ср Фев 14, 2018 12:06 pm), всего редактировалось 2 раз(а)
Вернуться к началу Перейти вниз
Посмотреть профиль Online
Gudleifr
Admin
avatar

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

СообщениеТема: Re: 02.01. БЕЗ НАЗВАНИЯ   Пн Фев 12, 2018 11:28 am

ДЕЛАЕМ ИЗ МУХИ СЛОНА И НАОБОРОТ

Посмотрим на "блок-схему" игры, приведенную в первой главе записок. По идее, ЗАДАЧА 1, это преобразование "Идеи" в "Правила", пока без какой-либо спецификации "отдельных Машин".
В чем состоит наша "игра"?
Например, в X-Com игрок совершает некоторые игровые действия, по результатам которых ему постепенно открывается "полная энциклопедия инопланетян" - параграф за параграфом.
Для того, чтобы у нас получилось что-то подобное, нам надо... (далее - "поток сознания"):

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

Для этого надо в т.ч. придумать какие-либо очевидые начальные пути. Например, у меня было такое разделение материалов (именно для STARGRUNT II):
1) Антуражные иллюстрации - очень "маловысокохудожественные". Кто-то из "художников" самовыражался, кто-то "для прикола" ретушировал реальные фотографии, кто-то явно творил, сидя на скучном заседании или лекции. Пропускаем. Интереснее создавать свой антураж.
2) Пояснительные иллюстрации - отрисованы получше, да и смысла в них побольше будет, надо их вырезать и вставлять в перевод.
3) Антуражные тексты - моих знаний английского языка явно недостаточно не только для литературного перевода, но даже для оценки качества и полезности этих художественных вставок. Пропускаем.
4) Сопроводительные тексты, в которых авторы пытаются обосновать оригинальность игры, рассказать о ее истории, посоветовать, какими модельками в нее играть... передают приветы родственникам, в конце концов. Пропускаем без вопросов.
5) Собственно правила. Надо переводить. С поправкой на то, что английский язык (в отличие от русского/немецкого) совершенно не приспособлен для передачи технических знаний, и после выливания обязательной воды размер текста уменьшается на порядок.
6) Типовые сценарии игры. Переводить, но - потом, если руки дойдут.
7) Конструирование подразделений и техники - самые для меня интересные разделы правил. Конечно, переводить.
8 ) Таблицы, краткие памятки-шпаргалки, примеры. Очень удобная для переводчика вещь. Почти билингва. По ним можно проверить правильность перевода правил. Сюда же можно отнести пояснительные иллюстрации и подписи под ними.
9) Описания типовой вселенной. Ничего интересного, за исключением некоторых примеров, относящихся к предыдущему разделу.

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

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

Что в первую очередь интересует игроков? Общие слова о том, что модель покрывает наземно-воздушные тактические боестолкновения 2000-2500гг.? Это только слова. Игроков интересует, какими фишками играть, как ходить и как побеждать? Первое, что приходит в голову: какова общая последовательность игры (настольная пошаговая, она, в конце концов, или компьютерная реального времени)? Так и запишем:

1) ПОСЛЕДОВАТЕЛЬНОСТИ - подготовки к игре, хода игры, фаз одного хода... Т.е. алгоритмы, которые можно жестко привязать к общему алгоритму игры. Последовательности указывают нам, какие действия следует предпринять в каждый конкретный момент времени, но не конкретизируют точный вид этих самых действий, ограничиваясь общими терминами. Конкретные действия зависят от конкретной обстановки на игровом поле и конкретных сил игрока, вовлеченных в это действие. Самая главная последовательность - алгоритм проведения партии. От подготовки к игре - до присуждения победы одному из игроков. Понятно, эта последовательность может быть разделена на совершенно разнородные фрагменты - последовательности подготовки поля боя и армий; разбиения игры на раунды, а раундов - на ходы; методы подсчета трофеев... "Глубина" вложения одних последовательностей в другие может быть совершенно различной в разных частях игры. Где-то формализмы практически полностью определяют действия игроков одно за другим, а где - все делается "по договоренности". Например, шахматы. Основная последовательность - расставить фигуры и играть. Собственно игра распадается на последовательность поочередных ходов, а те - на фазы, так же жестко определенные правилами: "взялся - ходи", "напал на короля - скажи: "Шах""... Последовательность же расстановки фигур жестко не определяется, например, игроки обычно сами решают, кому играть белыми. В Го в основную последовательность добавляется фаза подсчета очков по завершении партии. Возможны и "надпоследовательности", например, в шахматных турнирах, где в них описываются правила чередования партий, подсчет очков, шахматного этикета. Описывать последовательности естественно так же, как алгоритмы вычислений - блок-схемами или в виде пронумерованных абзацев.
***

Уже на этом этапе становится очевидным, какими мы должны играть фишками. Ведь, если мы встречаем фразу "походить тылом дивизии", то становится понятным, что отдельных фишек-танков не будет. Однако, встретив фразу "выстрелить из танка", игрок вправе задать вопрос: "А как?",-  значит надо конкретизировать, как стреляют все типы танков, допустимых в игре.

2) ЗАВИСИМОСТИ, конкретизирующие алгоритмы действий игрока, при обращении им с разными частями комплекта игры и/или нахождения в конкретном состоянии последовательности. Описание зависимости должно включать указание на конкретное ее место в игровой последовательности, условия ее применения и требования к фишкам (или другим частям игрового комплекта), в ней задействованных. Шахматный пример: "ход лошадью" - во время фазы перемещения, при отсутствии шаха, конем - далее описание буквы "Г". Конечно, нельзя не отметить, что в большинстве игр подобные описания называются просто "правилами".
***

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

3) ИСКЛЮЧЕНИЯ, т.е. описания случаев, когда следование конкретным алгоритмам приводит к нарушению последовательностей действий. Здесь мы сталкиваемся с разновидностью последовательностей, которые привязываются не столько к какому-либо состоянию более общей последовательности, но к какому либо условию.
***

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

4) УСЛОВИЯ, определяющие изменения состояния сил игрока или состояния игры, которые невозможно привязать к конкретной последовательности. Формат описания подобных правил по необходимости сильно отличается от перечисленных выше. В условиях описывается лишь результат действия, но не его алгоритм. Например: "королева любит свой цвет".
***

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

5) ПАРАМЕТРЫ - переменные, используемые в алгоритмах игры. Важнейшая характеристика параметра - список алгоритмов, его использующих. Т.о. их описание должно обязательно включать ссылки на правила их использующие. Обычно, авторы этим пренебрегают. Это вполне объяснимо -  сразу становится наглядной ненужность многих параметров. Гораздо "наукообразней" подробно расписывать, в какую графу "паспорта" фишки нужное число крестиков поставить.
***

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

6) ФОРМУЛЫ, жестко привязанные к параметрам и описывающие конкретные алгоритмы их связей и применения, использующиеся в разных контекстах/ситуациях игры.
***

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

7) НЕОДНОРОДНОСТИ в составе армий противников - особые рода войск, спецподразделения и т.д. И, соответственно, различные виды боя.

III. Каким-либо образом оформить привязку листьев к новым путям (красивый "добавлятор"). Собственно, "Построение Правил": как размещать переведенные куски таким образом, чтобы самому было интересно? Более того, чтобы создавалось впечатление, что машина что-то делает сама, радуя нас неожиданным результатом?
***

Хочется надеяться, что все эти "проблемы" не выходят за пределы манипулирования путями листьев. Надо только собрать коллекцию нужных "вырезателей", "просмотрщиков" и "добавляторов", и научиться собирать их в наборы "по смыслу".
Вернуться к началу Перейти вниз
Посмотреть профиль Online
Спонсируемый контент




СообщениеТема: Re: 02.01. БЕЗ НАЗВАНИЯ   

Вернуться к началу Перейти вниз
 
02.01. БЕЗ НАЗВАНИЯ
Вернуться к началу 
Страница 1 из 1
 Похожие темы
-
» Шедевры живописи, ваши любимые картины
» SOS !!! Обесцвечивание окрашенных волос ....Как ?
» Выставка тропических птиц
» Аналоги наших лекарств в Турции
» названия лекарств

Права доступа к этому форуму:Вы не можете отвечать на сообщения
KRIEGSSPIELE! :: Заметки о простых играх-
Перейти: