01.05. ЕСЛИ ТЫ НАСТОЯЩИЙ МУЖЧИНА, ПОСМОТРИ НА МЕНЯ В ПРОФИЛЬ!

Перейти вниз

01.05. ЕСЛИ ТЫ НАСТОЯЩИЙ МУЖЧИНА, ПОСМОТРИ НА МЕНЯ В ПРОФИЛЬ!

Сообщение автор Gudleifr в Пн Дек 04, 2017 11:53 am

ГЛАВА ПЯТАЯ. ЕСЛИ ТЫ НАСТОЯЩИЙ МУЖЧИНА, ПОСМОТРИ НА МЕНЯ В ПРОФИЛЬ!
Приняв в прошлой главе за нормальный вид "египетскую проекцию", трудно удержаться от искушения заставить солдатиков немного побегать.

ALLAN BLOMQUIST / RETRO GAME INTERNALS / CONTRA

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

CONTRA
Кратко об основных игровых объектах:

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

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

УРОВНИ
Каждый уровень состоит из некоторого количества экранов. На рисунке показаны 13 экранов первого уровня.



Каждый экран поделен на непересекающиеся большие плитки по 32*32 пикселей. 56 плиток - 8 по горизонтали и 7 по вертикали. Получается экран 256*224 пикселя. У NES экран 256*240 пикселей, так что остается неиспользуемая полоса, но это было нормально для игр того времени - полосу можно было убрать, подкрутив настройки телевизора.
На рисунке показано деление на большие плитки 7-го экрана первого уровня.



Каждая большая плитка состоит из 16 малых - по 8*8 пикселей. Такой размер экранных единиц диктуется аппаратурой NES.
***

[В чем суть метода плиток? Размер экрана большинства простых 16-разрядных компьютеров обычно около 64 тысяч точек, что примерно равно всему адресному пространству, опять же простых 16-разрядных процессоров (и простых программ, вроде наших BASIC). Т.е. либо считать, либо экран показывать.
Поэтому разработчики аппаратуры и программисты хитрили - а) отводили под графические массивы отдельную память, б) использовали стандартные элементы рисования (занимающие места в памяти меньше, чем на экране).
Пример обоих подходов мы видели в предыдущей главе - встраивание в BASIC-программы кодов, в принципе, способных иметь доступ к данным за пределами BASIC, и использование стандартных элементов - кирпичиков, линий.
Здесь - плитки. Т.е. опять стандартные элементы. Причем многоуровневые.
Картинка уровня состоит из больших плиток, т.е. занимает в памяти 56*13 ячеек (728 плиточных ячеек). Видов больших плиток заведомо гораздо меньше (например, на седьмом экране первого уровня их всего 12 видов). Поэтому, в принципе, может хватить 5-6 битных ячеек.
Каждая большая плитка состоит из 16 маленьких (8*8 пикселей). Как следует из дальнейшего описания, видов маленьких плиток 255, т.е. их описание в памяти занимает около 16k ячеек (размер ячейки зависит от количества используемых цветов, скорее всего 4 бита - 16 цветов).
Осталось выделить память под "справочник" больших плиток - 32-64 массивов по 16 ячеек (500-1000 ячеек, каждая ячейка по 8 бит). Тут что-то сильно сэкономить не получится.
Осталось "малое" - засунуть нашу картинку в эти массивы. Не только свести всю картинку к 255 видам квадратиков 8*8, но и упаковать их в 32-64 больших плиток. Больше видов больших плиток не получится физически - если все они будут состоять из разных малых их и 16-то будет не собрать (16*16=256). Экономия в малых плитках достигается, очевидно, двумя способами - большие однотонные пространства (например, неба), большие плитки схожего "устройства" (например, угловые и половинные варианты стандартных "кирпичиков").
Понятно, что выигрыш по сравнению с хранением картинки целиком огромен. Плата же кажется умеренной - т.к. большая часть чисел - степени двоек, то адресация ячеек получается не такой уж сложной.
Умеет ли так BASIC? В принципе, сами картинки (малые плитки) он может победить операторами BLOAD (загрузить кусок памяти из файла) и PUT (вывести кусок памяти на экран), но на промежуточных массивах массивы уровней и больших плиток мы потеряем очень много. Или, черт с ним, пара массивов по 1000 ячеек... По крайней мере, для экспериментов достаточно.- G.]
***

Карта элементов карты, т.е. не просто рисунков, но предметов окружения, контактирующих с фишками - платформ, по которым они бегают, препятствий и т.п., составляется из блоков - 16*16 пикселей - по 4 малых плитки в каждой. Т.е. при определении типа препятствия исследуется тип только верхней левой малой плитки в блоке.
На каждом уровне используется по 4 диапазона номеров плиток, соответствующих одному из четырех типов объектов. На первом уровне, например, плитки с номерами 0x01-0x05 - площадки, по которым фишки могут бегать, с номерами 0x06-0xF8 - пустые, 0xF9-0xFE - водные (фишка бегает по пояс в воде), 0xFF - твердые.
На рисунке показано деление экрана первого уровня на блоки. Синие - водные, зеленые - площадки, темные - пустые. Твердых тут нет.


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

ТОЛПЫ ВРАГОВ
Кроме врагов, прячущихся до времени в списке экрана, есть враги (бегущие солдатики), выскакивающие на экран случайно. Например, на рисунке ниже все солдатики выскочили случайно, пока игрок стоял на месте.



Система проста - каждый раз, когда некоторый таймер досчитывает до нуля, может выскочить враг, а таймер начинает новый отсчет. Начальное значение таймера зависит от уровня. Число 0 запрещает их появление вообще (например, на псевдообъемных уровнях). Кроме того, этот период сокращается на 20% при каждом новом успешном прохождении игры (увеличение сложности) и зависит от мощности оружия (P - 0, F - 1, M и L - 2 и S - 3) - примерно по 3% за уровень мощности. На рисунке выше показано число постоянно бегающих по экрану врагов в 4-й прохождении и с S-пушкой.
Скорость тиканья также зависит от скорости игрока: 0.75 - когда бежит, 1.0 - когда стоит. Видимо, чтобы вместе с врагами из списка выходило примерно одинаково.
Враги могут появиться с любой боковой стороны экрана, за исключением первого прохождения, первого уровня, с менее, чем 30 врагами, на экране - там, для облегчения игры они все появляются справа (навстречу). Для определения второй координаты используются три варианта алгоритма (в зависимости от числа пройденных экранов). Первую четверть времени программа ищет верхнюю платформу, четверть - нижнюю, остальное время - выбирает самую низкую платформу выше позиции игрока. Если игрок только один, враги появляются на верхней платформе половину времени.
Затем, проводится набор проверок, зависящих от уровня/экрана - не слишком ли высоко/низко платформа, не слишком ли высоко/близко стоит игрок, не пытается ли враг с запретной стороны... При невыполнении условий враг не появляется. Какие-то труднообъяснимые сценарные заморочки (или, наоборот, свидетельство кропотливой отладки)? Наконец, имеется шанс "случайного непоявления" (зависит от экрана - 0%, 50%, 75%, 100%).
В 25% случаев (за исключением уровня с водопадами и стояния на месте) порождается сразу группа из 3 солдатиков, которые почему-то никогда не стреляют (ошибка инициализации параметров?).
Иначе - один солдатик, который получает случайный параметр поведения-бега и параметр стрельбы из доступных на других экранах (чтобы разнообразить поведение врагов). Всего допустимо 7 видов поведения, но на уровне ангаров солдатики получают 8 тип поведения (что приводит к тому, что они обычно сразу убегают).
***

ВРАЖЕСКИЕ БАЗЫ
Эти псевдообъемные уровни тоже разделены на экраны, имеющие списки врагов, но работают последние иначе.



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

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

[Честно говоря, сомневаюсь, что правильно понял все написанное автором, или он - код. Слишком много врагов, которые появляются не там и не тогда. Или это только так кажется?- G.]
***

КОНТАКТЫ
Есть два вида контактов игровых объектов: между объектами и между объектами и элементами уровней. Обрабатываются они совершенно по-разному, разными процедурами.
***

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



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

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

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

[Обратим внимание на широкое применение в этих процедурах того же "метода плиток". Обнаружив, что некоторые наборы данных часто повторяются, их вырезают из одного массива и засовывают в другой (понятно, только в одном экземпляре), а во всех (повторяющихся) местах употребления - ставят ссылку (тип, например, тип врага, параметры поведения...). (В реляционных Базах Данных это называется нормализацией).
Причем, т.к. это делается для экономии места (т.е. уменьшения размера второго массива), то число комбинаций в типе должно быть малым. Как мы были ограничены в разнообразии плиток, так мы ограничены в числе типов врагов и типов поведения. Как только захочется сделать немного другого врага, "губы Никанора Ивановича да приставить к носу Ивана Кузьмича", вся экономия идет прахом.
Если речь идет не только о хранении данных, но о работе с ними - модификации, удалении и т.п., метод проваливается окончательно. С эти м можно столкнуться и в Теории Баз Данных, и в Объектно-Ориентированном Программировании.
В более "серьезных" языках гораздо удобнее вместо списка "типов" хранить список пар "функция - параметр", т.е. не просто "факт", а еще и "интерпретатор этого факта". В Contra это выглядит, по словам автора "кодом, который сам знает, как работать с этими данными".- G.]
***

ФИЗИКА ИГРОКА
Код, управляющий перемещением фишек игрока очень прост. Однако, вполне достаточен и презентабелен. Отслеживаются только координаты и скорость, представленные в формате 8.8 - в пикселях и пикселях на кадр, соответственно. Каждый кадр считается скорость и прибавляется к координатам. Горизонтальная скорость перед этим обнуляется - никакой инерции. Для врагов даже нет необходимости хранить свою скорость, ведь многие даже не двигаются. А у тех, кто двигается, скорость прописана в виде констант в их коде.
Изменение скорости производится процедурами, отвечающими за различные его телодвижения. Например, процедура бега усанавливает горизонтальную скорость и проверяет, не кончилась ли платформа, вертикальная скорость остается без измененений, контакты выше уровня головы не проверяются. Наоборот, при прыжке последние учитываются, а платформа - нет. В прыжке также учитывается вертикальное ускорение, дающее параболическую траекторию (ускорение - константа в алгоритме). Т.е. все движения разделены на элементарные операции, позволяющие обойтись простейшей арифметикой. Никаких интегрирований и лишних проверок.
***

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

[Т.е. мы имеем ту же "машину состояний", что и в "HIGN HOON", но "засунутую внутрь циклической": GOTO используется "с задержкой" - сначала устанавливается флаг, а, переход делается позже - по результатам опроса флагов в нужном месте цикла. Других способов реализовать работу в реальном режиме времени нет - процедуры отрисовки и ожидания команды игрока должны выполняться "параллельно", лучше в разных "процессах".- G.
***

В отличие, например, от игр Super Mario Bros., в Contra горизонтальная скорость обнуляется в начале каждого цикла, т.е. фишки игрока не обладает никакой инерцией и движется только, пока игрок жмет клавишу. В прыжке/падении эта самая горизонтальная инерция появляется - фишка сохраняет свою горизонтальную скорость, пока с чем-нибудь не столкнется (как в игре Metroid, а не в Mega Man). Когда игрок жмет клавиши в полете, флаги направления устанавливаются, но не сбрасываются, когда клавиша отпускается, и процедура читает по флагам прежнюю скорость.
В Contra используется возможность спрыгивания сквозь платформу, когда игрок одновременно жмет "вниз" и "прыжок". При этом используются флаги падения, а не прыжка. При этом фишка принудительно опускается на 20 пикселей, чтобы оказаться ниже элемента-платформы и лететь свободно.
***

СЛУЧАЙНЫЕ ЧИСЛА
Используется единственный 8-битный генератор (аппаратный), выдающий случайное число раз в кадр. Он настолько плох, что, например, для того, чтобы демоигра выглядела хотя бы немного по-другому, ее надо запустить на другом компьютере.
***

МАССИВЫ
Структуры массивов, а не массивы структур.
[То, что я выше называл нормализованными массивами.- G.]
Так удобнее организовать (индексированный) доступ к данным на 8-битном процессоре.
***

ЭКРАННЫЕ КООРДИНАТЫ
Все координаты в игре даны в координатах экрана (0 слева вверху). Поэтому при каждой прокрутке из горизонтальных координат всех объектов надо вычитать 1. Т.к. экран 256*240 хватает одного байта.
***

УСЛОЖНЕНИЕ УРОВНЕЙ
Многие числа в игре зависят от количества успешных прохождений игры (за один раз) и имеющегося у фишки игрока оружия. Чем дальше зашел игрок и чем он сильнее, тем сильнее и многочисленнее враги.
avatar
Gudleifr
Admin

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

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

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

Re: 01.05. ЕСЛИ ТЫ НАСТОЯЩИЙ МУЖЧИНА, ПОСМОТРИ НА МЕНЯ В ПРОФИЛЬ!

Сообщение автор Gudleifr в Пн Дек 04, 2017 11:59 am

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



Стало возможным и усложнение вселенной - увеличение числа разнообразных предметов и, соответственно, переноса центра тяжести игры со стрельбы на "выполнение заданий" - таковы, например, игры Metal Gear, Airborne Ranger. (Иногда допускалась хитрость - здание/машина снаружи выглядела меньше, чем изнутри. Т.е. на экране двора будка выглядела предметом, но, зайдя в нее, фишка игрока попадала на экран комнаты, размером с целый двор, со своим набором предметов мебели).



А где не хватало информативности, вставили диалоги:



Были и попытки заставить солдатиков выполнять чисто физические упражнения: отжиматься, бегать на время, стрелять на точность (в игре Boot Camp)...



И, даже, бегать толпой солдатиков (Cannon Fodder).



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

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

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

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

Re: 01.05. ЕСЛИ ТЫ НАСТОЯЩИЙ МУЖЧИНА, ПОСМОТРИ НА МЕНЯ В ПРОФИЛЬ!

Сообщение автор Gudleifr в Пн Дек 04, 2017 12:03 pm

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

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

Поэтому, вернемся на шаг назад и посмотрим, например, на "синхронизацию".
avatar
Gudleifr
Admin

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

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

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

Re: 01.05. ЕСЛИ ТЫ НАСТОЯЩИЙ МУЖЧИНА, ПОСМОТРИ НА МЕНЯ В ПРОФИЛЬ!

Сообщение автор Gudleifr в Пн Дек 04, 2017 12:12 pm

СЛОЖНОСТИ С ТАЙМЕРОМ

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

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

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

3. "Послать Быстроногого Оленя". В сложных Операционных Системах существует набор специальных процессов, способных посылать нашей программе сообщения или что-то делать параллельно.
Например, можно заказывать проигрывание музыки (не отвлекаясь на это в самой программе) - это проигрывание будет идти мимо нее.
Другой пример - создание процесса-таймера, который будет нам [периодически] сигнализировать.
Возможно также создание процессов, которые позволят распараллелить и саму программу - "считать космос отдельно от корабля". И сообщать, только, если их вычисления закончились и пора применять результат (грузить новые данные).
К сожалению, во-первых, набор стандартных сигнализирующих процессов не покрывает все потребности программирования игр, приходится писать самим, а, во-вторых, Операционные Системы, по большей части, не считают подобные процессы "нормальными" и требуют от программистов самостоятельной разработки их взаимодействия. Например, Windows худо-бедно гарантирует, что события вызовут свои процедуры-обработчики, но ему совершенно наплевать, не подпортят ли они данные друг друга. Программист сам должен думать, что будет, если один обработчик устанавливает переменную, второй - изменяет, третий - использует, а вызываться они будут в произвольном порядке.

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

Для простой игры - главное связать потребителей и источники сообщений в простую логическую структуру.
Иначе, будет как в анекдоте:
- Товарищ прапорщик, ваше приказание выполнено!
- Так я же ничего не приказывал!?
- А мы ничего и не делали!


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

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

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

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

Re: 01.05. ЕСЛИ ТЫ НАСТОЯЩИЙ МУЖЧИНА, ПОСМОТРИ НА МЕНЯ В ПРОФИЛЬ!

Сообщение автор Gudleifr в Пн Дек 04, 2017 12:38 pm

MIKE WIERING / MARIO & LUIGI SOURCE CODE / TURBO PASCAL 6.0 OR 7.0

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

Комментарии авторов (*.TXT);
Программные блоки (*.PAS);
Блоки картинок (*.$0?);
Блоки задников (*.BK).
TXT/RAR, 0.08Мб
Вот тут-то мы и посмотрим, зачем нужны программы такого размера.
***

Первое, что мы видим, PASCAL не является языком программирования IBM PC. Вместо того, чтобы объяснять машине, что делать, программист объясняет (очевидно, сам себе), что он имел в виду. Одна только информация о связях модулей занимает более 100 строк.

[/tbody]
МодульЧто делаетРазмер, строкКого использует
MarioГлавный747BackGr, Buffers, CPU286, Enemies, Figures, Joystick, KeyBoard, Palettes, Play, Players, Txt, VGA256, Worlds
CPU286Не дает программе запуститься, если процессор слабее 8028634-
JoystickИнтерфейс джойстика185-
KeyboardИнтерфейс клавиатуры365-
VGA256Интерфейс видеоадаптера1535-
BuffersВсе переменные в одном месте246VGA256
MusicИнтерфейс динамика102Buffers
PalettesНаборы палитр396Buffers
WorldsКарты уровней1810Buffers
GlitterИскры от удара головой и т.п.222Buffers, VGA256
StarsЗвезды на небе? не используется162Buffers, VGA256
TxtШрифты1051Buffers, VGA256
BackGrРисование задников1076Buffers, Palettes, VGA256
BlocksАнимированные плитки?100BackGr, Buffers, VGA256
StatusРисование строки состояния69Buffers, Txt, VGA256
FiguresРисование плиток карты939BackGr, Buffers, Palettes, VGA256
TmpObjВыскакивающая/пропадающая мелочь?341BackGr, Buffers, Glitter, Figures, Music, VGA256
EnemiesВстречные фишки1283Buffers, Figures, Glitter, Music, TmpObj, VGA256
PlayersПеремещение фишек игроков1106BackGr, Blocks, Buffers, Figures, Glitter, Enemies, Joystick, KeyBoard, Music, Txt, TmpObj, VGA256
PlayОдин уровень игры737BackGr, Blocks, Buffers, Enemies, Figures, Glitter, KeyBoard, Music, Palettes, Players, Stars, Status, TmpObj, Txt, VGA256
Видно, что принцип структурного/объектного программирования "вассал моего вассала - не мой вассал" не соблюдается, каждый модуль честно используется всеми, кто расположен до него (еще хуже, что в некоторых верхних модулях встречаются действия вопреки нижним - вплоть до программирования в кодах - например, некоторые модули лезут в видеопамять в обход VGA256.pas). По большому счету, такое ветвистое наследование позволяет программисту быстро добраться до любого места программы, но за счет жуткой избыточности перевода с языка одного модуля на язык другого.
Итак мы имеем:

- Пять с половиной тысяч (файлы *.$0? и *.BK) строк кода, описывающего картинки.
- Почти две тысячи (Worlds.pas) строк, описывающих расположение плиток уровней.
- Две тысячи строк (ассемблерного кода) - в драйверах (Joystick.pas, Keyboard.pas, VGA256.pas, Music.pas), предоставляющих аналоги BASIC-операций STICK, INKEY$, PUT, BEEP...
- Тысячу (Txt.pas) строк рисования букв.
- Еще почти восемь тысяч строк кода (в т.ч. немножко ассемблерного)...

К чему такая расточительность?
***

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

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

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

Сможем ли мы из такой "серьезной" программы извлечь хоть что-то полезное?
***

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

КАРТИНКИ
Автор программы предложил сложную в использовании, но быструю в работе и не требующую лишних затрат памяти схему. Сначала в простейшем графическом редакторе (GRED.EXE, прилагается к исходникам) создается картинка, сохраняемая в обычном бинарном файле.



Затем, этот файл преобразуется (BIN2PAS.EXE, тоже прилагается) в "кодовую процедуру":

procedure lwmar000; assembler;
asm
db   0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 16,  0,  0
db   0, 16, 54, 16,  0,  0, 50, 55,  5, 16,  0, 16, 16,  5, 60
db   0, 16, 16, 16,  5,  0,  0, 52, 50,  5,  0, 52, 54, 54, 50
db   0, 55, 54, 54, 16,  0, 52, 52, 54, 16,  0, 16, 16, 52, 53
db   0, 16, 16, 54, 52,  0,  0, 53, 52, 16,  0,  0, 50, 16, 60
db   0,107, 16,109,  5,  0, 16,109,110,  5,  0, 16,107,110,  5
db   0, 16, 16,107, 60,  0, 16,139, 16, 16,  0, 16,140,139,139
db   0, 16,139,140,140,  0,  0,139,140,139,  0,  0,140,140,138
db   0,  0,139,138, 16,  0, 16, 76, 50, 50,  0, 78, 16, 76, 76
db   0, 50, 16, 50, 50,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0
db   0, 16, 16,  0,  0,  0, 60,  5, 16,  0,  0,  5, 54,  5,  0
db   0, 16, 16,  5, 16, 16, 16, 16, 50, 50,  0, 52, 50, 16,  5
db   0, 54, 51, 52,  5,  0, 55, 54, 54, 52,  0, 52, 52, 52, 52
db   0, 16, 16, 54, 54,  0, 16, 16, 54, 16,  0, 50, 53, 52,  0
db   0,  0, 16, 50, 16,  0, 16,109, 16,  5, 16,141,111,109,  5
db  16,141,110,107,  5, 16,142,107, 16, 50,  0,141, 16,138, 16
db   0,140,140,139,139,  0,139,140,140,138,  0, 16, 16,140, 16
db   0,  0,139,140, 16,  0, 16,138,139,  0,  0, 50, 16, 76, 16
db   0, 77, 78, 76, 16,  0, 50, 50, 50, 16,  0,  0,  0,  0,  0
db   0,  0,  0,  0,  0,  0, 16, 16,  0,  0,  0,  5,  5, 16,  0
db   0, 54,  5,  5,  0, 16, 16, 16,  5,  0, 16, 16, 16,  5, 16
db   0, 50, 16, 16, 16,  0, 51, 16, 16, 50, 52, 55, 54, 52, 54
db  50, 52, 16, 16, 54,  0, 16, 16, 52, 50,  0, 16, 50, 53, 16
db   0, 52, 53, 50,  0,  0, 16,107,  5, 16, 16,141,111, 60, 60
db 111, 60,111, 16,  5,110,  5,110, 16, 50,107,141,107, 50, 16
db  16,141, 16,139, 16,  0,140,139,139, 16,  0,141,141,140, 16
db   0,139,140,140,  0,  0, 16, 16,140,  0,  0, 16, 16,139,  0
db   0, 76, 50, 76,  0,  0, 77, 77, 76,  0,  0, 50, 50, 50,  0
db   0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0, 16, 16,  0,  0
db   0, 54,  5,  0,  0, 16,111,  5, 16,  0, 16, 16, 60,  5,  0
db  16, 16, 16,  5,  0,  0, 16, 52, 50,  0, 52, 16, 54, 16, 16
db  55, 54, 54, 16, 50, 52, 52, 52, 16, 50, 16, 16, 16, 16, 16
db   0, 16, 54, 53,  0,  0, 53, 53, 16,  0,  0,139, 16, 60,  0
db  16, 60,110,  5, 16,110, 16,110,  5, 16,109, 16,110,  5, 16
db 107,140,107, 60,  0, 16,140, 16, 16,  0,  0,140,139,140,  0
db   0,139,140,140,  0,  0,140,141,140,  0,  0,139,140,139,  0
db   0,139, 16,138,  0,  0, 76, 50, 76,  0, 16, 77, 76, 76,  0
db  16, 50, 50, 50,  0
end;

Понятно, вызывать эту "процедуру" нельзя, но можно передать ее адрес процедуре рисования.
***

На BASIC так красиво не получается. Конечно, в известной BASIC-игре GORILLA.BAS (входит в поставку MS DOS 5.00), мы можем видеть что-то текстово похожее:

EGABanana:
'BananaLeft
DATA 458758, 202116096, 471604224, 943208448, 943208448,
943208448, 471604224, 202116096, 0

Но, во-первых, этот массив еще надо скопировать из программной памяти в память данных, а во-вторых, на это уйдет время.

RESTORE EGABanana
REDIM LBan&(8 ), RBan&(8 ), UBan&(8 ), DBan&(8 )
FOR i = 0 TO 8
READ LBan&(i)
NEXT i

И только потом можно будет рисовать (bc здесь означает выбор между рисованием и стиранием):

IF bc THEN PUT (xc#, yc#), LBan&, PSET ELSE PUT (xc#, yc#), LBan&, XOR



Поэтому саму гориллу в этой игре предпочитают рисовать по частям (как в AKALABETH):

'draw head
LINE (x - Scl(4), y)-(x + Scl(2.9), y + Scl(6)), OBJECTCOLOR, BF
LINE (x - Scl(5), y + Scl(2))-(x + Scl(4), y + Scl(4)), OBJECTCOLOR, BF
'draw eyes/brow
LINE (x - Scl(3), y + Scl(2))-(x + Scl(2), y + Scl(2)), 0
'draw nose if ega
IF Mode = 9 THEN
FOR i = -2 TO -1
PSET (x + i, y + 4), 0
PSET (x + i + 3, y + 4), 0
NEXT i
END IF
'neck
LINE (x - Scl(3), y + Scl(7))-(x + Scl(2), y + Scl(7)), OBJECTCOLOR
'body
LINE (x - Scl(8 ), y + Scl(8 ))-(x + Scl(6.9), y + Scl(14)), OBJECTCOLOR, BF
LINE (x - Scl(6), y + Scl(15))-(x + Scl(4.9), y + Scl(20)), OBJECTCOLOR, BF
'legs
FOR i = 0 TO 4
CIRCLE (x + Scl(i), y + Scl(25)), Scl(10), OBJECTCOLOR, 3 * pi# / 4, 9 * pi# / 8
CIRCLE (x + Scl(-6) + Scl(i - .1), y + Scl(25)), Scl(10), OBJECTCOLOR, 15 * pi# / 8, pi# / 4
NEXT
'chest
CIRCLE (x - Scl(4.9), y + Scl(10)), Scl(4.9), 0, 3 * pi# / 2, 0
CIRCLE (x + Scl(4.9), y + Scl(10)), Scl(4.9), 0, pi#, 3 * pi# / 2
FOR i = -5 TO -1
SELECT CASE arms
CASE 1
'Right arm up
CIRCLE (x + Scl(i - .1), y + Scl(14)), Scl(9), OBJECTCOLOR, 3 * pi# / 4, 5 * pi# / 4
CIRCLE (x + Scl(4.9) + Scl(i), y + Scl(4)), Scl(9), OBJECTCOLOR, 7 * pi# / 4, pi# / 4
GET (x - Scl(15), y - Scl(1))-(x + Scl(14), y + Scl(28 )), GorR&
CASE 2
'Left arm up
CIRCLE (x + Scl(i - .1), y + Scl(4)), Scl(9), OBJECTCOLOR, 3 * pi# / 4, 5 * pi# / 4
CIRCLE (x + Scl(4.9) + Scl(i), y + Scl(14)), Scl(9), OBJECTCOLOR, 7 * pi# / 4, pi# / 4
GET (x - Scl(15), y - Scl(1))-(x + Scl(14), y + Scl(28 )), GorL&
CASE 3
'Both arms down
CIRCLE (x + Scl(i - .1), y + Scl(14)), Scl(9), OBJECTCOLOR, 3 * pi# / 4, 5 * pi# / 4
CIRCLE (x + Scl(4.9) + Scl(i), y + Scl(14)), Scl(9), OBJECTCOLOR, 7 * pi# / 4, pi# / 4
GET (x - Scl(15), y - Scl(1))-(x + Scl(14), y + Scl(28 )), GorD&
END SELECT
NEXT i

Скорее же всего, надо будет, как указано выше, использовать комбинацию BLOAD и PUT, ища компромисс между скоростью и экономией места.
***

ОПЯТЬ ПЛИТКИ
Ландшафт экрана меню (из Worlds.pas):



procedure Intro_0; assembler;
asm
db 'AAч          '
db 'AAч          '
db 'AA           '
db 'AAрррр       '
db 'AAчр         '
db 'AAч          '
db 'AAррр        '
db 'AA           '
db 'AA           '
db 'AA           '
db 'AA           '
db 'AAррррр      '
db 'AAррр        '
db 'AAч          '
db 'AAч          '
db 'AA           '
db 'AA           '
end;

Для наглядности надо положить массив набок. Т.е. мы имеем примерно тот же набор плиток (описанных в файлах .$0?), что и на первой иллюстрации "про Contra". С двумя отличиями: а) оптимизирующего деления плиток на более мелкие не предусмотрено и б) программе интерпретации данных требуется не просто считывать коды плиток, но и рассчитывать их конкретную модификацию в зависимости от взаимного расположения (скругление верхней плитки изгороди (р), парность кустиков (ч)...). Коды плиток расшифровываются в жутких конструкциях выбора в зависимости от того, что нужно - рисовать, проверять контакты или еще что (например, кусочек для рисования "р"):

'р': case Options.Design of
1: if WorldMap^ [X, Y - 1] <> Ch then
Fig := @Fence001
else
Fig := @Fence000;
2: if WorldMap^ [X, Y - 1] <> Ch then
Fig := @SmTree000
else
Fig := @SmTree001;
end;

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

А КАК ЭТО РАБОТАЕТ?
Где то, что нас больше всего интересует: синхронизация событий/отрисовки?
А, нету!
Нет, конечно, нажатие игроком клавиш (INKEY$) то и дело отслеживается программой (как и потребность что-то где-то нарисовать), но никакой особой системы отследить невозможно. Мы можем построить могучие таблицы истинности флагов, описывающих эти ситуации, но это будет работа, которую сам автор программы не делал. Как в подобном случае писал Дейкстра: "... решили не рассматривать это решение (если оно было решением, что мы так и не смогли выяснить!)".
Если угодно, у меня был подобный опыт (большая графическая программа на PASCAL) и, кажется, автор завысил размер программы примерно на порядок.
Мы пойдем другим путем!


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

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

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

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

Re: 01.05. ЕСЛИ ТЫ НАСТОЯЩИЙ МУЖЧИНА, ПОСМОТРИ НА МЕНЯ В ПРОФИЛЬ!

Сообщение автор Gudleifr в Пн Дек 04, 2017 12:46 pm

ПРОБЛЕМЫ ИГРОВОЙ ГРАФИКИ И ИХ РЕШЕНИЯ

1. Что предпочесть: рисование/затирание графики "по месту" или вывод сцены целиком?
Второе выглядит гораздо лучше (рисуем экран в памяти, сбрасываем его целиком на дисплей, рисуем в памяти новый), но требует, по крайней мере, буфера размером с экран и процедур работы с памятью таких размеров.
2. Что предпочесть: "вид сбоку" или "перспективу"? Нужна ли прокрутка?
Видно, что набор удачных частных решений часто выглядит гораздо лучше, чем игра, которая выполнена в одном стиле, как бы он ни был хорош. А для BASIC-программ, ввиду скудости ресурсов, это может быть вынужденным решением - разные программы для разных уровней/режимов игры.
3. Как минимизировать число предметов обстановки и поз персонажей?
Это вопрос вопросов. Единственное, что как-то может помочь, обрезание лишнего при ответе на предыдущий вопрос.
4. Какова единица перемещения/прокрутки?
Чем грубее, тем лучше. Все равно, честную терхмерную съемку нам здесь не переплюнуть.
avatar
Gudleifr
Admin

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

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

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

Re: 01.05. ЕСЛИ ТЫ НАСТОЯЩИЙ МУЖЧИНА, ПОСМОТРИ НА МЕНЯ В ПРОФИЛЬ!

Сообщение автор Gudleifr в Пн Дек 04, 2017 12:57 pm

ГРАНИЦЫ ПРИМЕНИМОСТИ

А может ли подобная игра быть чем-то кроме "бегалки-стрелялки"?
Рассмотрим известную серию игр (WALLY WEEK) для ZX Spectrum:



Полные карты игровых миров - IMG/RAR, 0.58Мб.

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


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

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

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

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

Re: 01.05. ЕСЛИ ТЫ НАСТОЯЩИЙ МУЖЧИНА, ПОСМОТРИ НА МЕНЯ В ПРОФИЛЬ!

Сообщение автор Gudleifr в Пн Дек 04, 2017 1:08 pm

ДЛЯ САМЫХ МАЛЕНЬКИХ

"Курьер Юнеско" Апрель 1983
Роберт У. Лоулер в сотрудничестве с Мамаду Ньянгом и Мусой Гнингом
***

РОБЕРТ ЛОУЛЕР (США) - научный сотрудник Всемирного центра вычислительной техники и развития человека (Париж).
МАМАДУ НЬЯНГ и МУСА ГНИНГ (Сенегал) - преподаватели экспериментальной школы, при педагогическом училище в Дакаре.
Этa статья в значительной мере основана на материалах, опубликованных ранее в "Boston Review".
***

По мере того как компьютеры становятся все более распространенными и дешевыми в промышленно развитых странах, компьютерная революция охватывает все большее число стран. Пришло время решить основной вопрос: чему будут способствовать ЭВМ - единообразию или многообразию.
ЭВМ можно применять по-разному. Удастся ли сделать их использование разумным и восприимчивым к разным человеческим ценностям? Можно ли будет адаптировать их к культурному многообразию мира? Или же мы станем свидетелями применения ЭВМ без учета человеческих ценностей? Какой фактор окажется решающим при передаче технологии из развитых стран: поспешность или продуманность?
Если предпочесть многообразие единообразию, то возникает важный вопрос о том, как сделать компьютерную революцию восприимчивой к уникальным особенностям разных культур. Передача идей - процесс более важный, чем передача технологии. В нашей статье идея внедрения компьютерной техники рассматривается на базе подробного описания работ, которые я проделал со своей дочерью в США, и опыта использования результатов этих работ моими коллегами из Сенегала.

Микрокомпьютеры все активнее проникают в дома и школы промышленно развитых стран и скоро наводнят мир. Вероятно, пришло время задуматься о том, какое воздействие они окажут на наших детей. Изменят ли компьютеры методы обучения детей? Повлияют ли они на формирование их личности? Я считаю, что ответ на эти вопросы, скорее всего, будет утвердительным, и, хотя пока еще слишком рано для окончательных доказательств, мне хотелось привести свои доводы в подтверждение такой точки зрения.
Когда у нас появились дети, я уже проработал в компьютерной промьпцленности 16 лет, и меня заинтересовало, как может раннее знакомство детей с компьютерами повлиять на их обучение. Несколько лет назад, участвуя в проекте машинного языка в Массачусетском технологическом институте, я начал регулярно наблюдать, каким образом ежедневный доступ к компьютеру двух моих старших детей (6 и 8 лет) влиял на изучение ими начального курса арифметики. К тому времени, когда их младшей сестре, Пегги, исполнилось три года, микрокомпьютер стал в нашем доме предметом повседневного обихода, и я начал разрабатывать несколько программ для того, чтобы Пегги могла пользоваться компьютером. В течение последующих месяцев самостоятельно играя с компьютером по этим программам, Пегги начала делать то, что обычно делают дети, начиная читать и писать.
В самом деле, что значит принести домой микрокомпьютер и позволить трехлетнему ребенку играть с ним? Все зависит от того, кто вы, от ваших знаний и взглядов.


Пегги вводит в микромир грузовик.

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


Пегги ставит домик.

В США дети обычно начинают читать примерно в шесть лет. Большинство учится читать в школе, некоторые - раньше. В возрасте 3 лет и 3 месяцев Пегги, даже живя в семье, где любят книгу, до знакомства с компьютером, естественно, не умела читать. Ее знание алфавита ограничивалось лишь несколькими буквами, имевшими определенное символическое значение. Например, она знала, что "Р" - это первая буква ее имени (Peggy). Она также узнавала "G" - "мамину букву", поскольку маму зовут Гретхен (Gretchen).
Могла ли она произносить слова по буквам? Один случай дал мне об этом некоторое представление. Моя старшая дочь учила французские слова; и однажды Пегги заявила, что может "произносить по буквам французский", и действительно произнесла un, deux, trois, quatre, cinq. В другой раз пытаясь сделать то же самое, она произнесла несколько бессмысленных звуков. Пегги представляла орфографию как разложение значимого слова на ряд лишенных смысла символов; в то время она не понимала значения орфографии.


"Вот он".

Способность и желание Пегги отождествлять ряд символов с определенным словом имели весьма специфические корни. Получив в подарок от старшей сестры книгу (на форзаце которой сестра написала "Peggy Lawler"), Пегги истолковывала все группы букв как "Peggy Lawler". Co временем, поскольку ей часто читали, она начала узнавать одно слово из двух букв "by", которое всегда проставляется на титульном листе каждой книги перед фамилией автора. Нет никаких оснований считать, что она имела какое-либо представление о значении этого слова в том контексте. Ее знания о чтении как процессе интерпретации графического материала лучше всего характеризуются тем, что, с ее точки зрения, она читала КАРТИНКИ, а я читал СЛОВА. Из этого мы можем заключить, что она "читала", придумывая историю на основе своих представлений о значении картинок, и считала, что я делаю то же самое со словами. Неплохое предположение, однако полностью лишенное какой-либо информации о том, как именно слова передают то или иное понятие.
Теперь сравним это со знаниями Пегги семь месяцев спустя. Она практически уже знает алфавит, т.е. различает и может называть все 26 букв. Значительно расширились ее знания слов в плане толкования каждого из них в отдельности. Она читает вполне уверенно более двадцати слов. Но в отличие от детей, учившихся читать и писать обычным способом, она воспринимает произнесение слова по буквам как разбитый на отдельные шаги процесс при вводе этого слова в компьютер. Хотя ее общее представление о процессе чтения книг, возможно, и не изменилось, она приобрела иное, более ясное понятие о прочтении отдельных слов, которое является непосредственным результатом ее опыта игр по моим программам для компьютера. Знакомство Пегги с компьютером не имело прямого отношения к "чтению" с точки зрения понимания содержания, но ее желание управлять компьютером привело к тому, что она ввела в него свое первое "написанное" слово. Поскольку Пегги помогала вводить программы, нажимая клавиши на кассетном магнитофоне, однажды она сама напечатала "LO" на терминале и начала искать следующую букву. Через несколько дней она самостоятельно напечатала команду "load" ("загрузка").
Я называю компьютерную среду, созданную при помощи написанных мною программ, "микромиром", следуя терминологии, используемой Сеймуром Пейпертом, который сыграл основную роль в разработке машинного языка ЛОГО (LOGO), в книге "Mindstorms". Одним из первых микромиров было передвижение на экране цветных прямоугольников, другим (первоначально сделанным для старшей дочери, а затем перешедшим к Пегги) - создание графических композиций передвижением цветного "маркера". В то время как старшая дочь пользовалась этой графической программой для рисования, первой работой Пегги был большой прямоугольник, который она тут же превратила в букву "Р", добавив снизу ножку. Буквы очень заинтересовали Пегги. Они обладали какой-то непонятной для нее силой.
Несколько дней спустя Пегги ввела в компьютер букву "A" и объяснила мне, что "A"-это "apple" ("яблоко"). Ее объяснение навело меня на мысль о создании с помощью компьютера своего рода букваря. Буквари обычно содержат множество привлекательных картинок, размещенных в алфавитном порядке и сопровождаемых большой печатной буквой, ассоциирующейся с данной картинкой. Ребенок смотрит на картинку и понимает, что "А" - это "apple" ("яблоко"). В "азбучном микромире" связь букв с картинками обратная. Буква является "ключом" к картинке, т.е. при вводе буквы "D" появляется изображение собаки ("dog"). Вместо того чтобы по изображению узнавать букву, Пегги могла сначала нажимать любую букву на клавиатуре и видеть соответствующую картинку, а затем, если эта картинка интересовала ее, выяснить название буквы. Она управляла процессом своей учебы. Она могла учить то, ЧТО хотела, КОГДА хотела, и могла обращаться за советом или информацией, если ОНА решала, что НУЖДАЛАСЬ в этом. Азбучный микромир был сделан специально для Пегги. Изображения подбирались и создавались на компьютере старшей сестрой и братом Пегги, 10 и 12 лет. Играя с азбучным микромиром и другими, которые мы рассмотрим ниже, Пегги приобрела прочные и полезные знания букв алфавита.
"Пляжный микромир" более сложный и интересный, чем азбучный, является прекрасным полем деятельности. Волны и берег на переднем плане, затем трава, дорога, опять трава и облака на самом верху. На этом фоне Пегги могла изображать предмет, определяя название операции, а затем изменять его положение соответствующими командами. Пегги, как правило, начинала словом "sun" ("солнце"). На волнах появлялся желтый круг. Она поднимала его в небо, набирая несколько раз слово "up" ("вверх"), меняла его цвет, приводила его в движение другим словом или переходила к другому предмету. Она могла, например, изобразить машину, набрав слово "car" ("машина"), менять ее положение командами "up" ("вверх"), "down" ("вниз"), "move" ("движение"), задавать направление и скорость ее движения командами "turn" ("поворот"), "slow" ("медленно"), "fast" ("быстро"), "faster" ("быстрее") и "halt" ("стоп").
Эти микромиры были созданы с помощью ЛОГО, весьма доступного машинного языка, позволяющего вложить значение в любой ряд букв. Язык ЛОГО особенно хорошо подходит для нововведений в пляжный микромир. Когда Пегги первый раз стала играть в "пляж", ее не удовлетворяла скорость движения объектов и она попросила увеличить ее. Для этого потребовалось вложить новое слово ЛОГО - "zoom" ("трансфокатор"), позволяющее регулировать скорость движения объектов с помощью простой команды. Однажды старшая сестра Пегги построила на дисплее наездника на лошади и написала процедуру "pony" ("пони"), чтобы создать микромир "наездник и лошадь" и привести его в движение. Понаблюдав за сестрой, Пегги повторила определенные команды, стремясь построить собственный рисунок. (Ей не удалось с этим справиться, и в результате у нее получилось нагромождение перпендикулярных линий. На вопрос, что это такое, она сначала ответила: "Пони", а затем "Что-то важное".) Вполне возможно, что ученики начальных классов могут создавать собственные конструкции, повторяя и меняя процедуры, чтобы расширить или привести в соответствие со своими интересами словарь подобных микромиров.

КОМПЬЮТЕРНЫЕ МИКРОМИРЫ


"Пляжный микромир", созданный Робертом Лоулером для его дочери Пегги.


"Деревенский микромир", созданный Мамаду Ньянгом, Мусой Гнингом и Робертом Лоулером


для учеников экспериментальной школы педагогического училища в Дакаре, Сенегал.



Микромиры-это компьютерная среда, которой дети быстро учатся манипулировать и которую они могут дополнять придуманными ими объектами. Компьютеры - это поддающаяся адаптации техника, однако необходимо, чтобы программное обеспечение для них разрабатывалось с учетом различных человеческих ценностей и потребностей. В случае микромира сенегальской деревни программное обеспечение было приспособлено к языку волоф, одному из традиционных языков Сенегала. Значение сенегальских слов на фотографиях следующее: jant - солнце; tas - лошадь, doxal - гулять или идти, awyong - самолет, nit - человек, aaamaan - в небе, wene-eku-поворот, yeeg-вверх.
***

Непосредственным результатом игры с пляжным миром явилось то, что Пегги научилась "читать" около двадцати слов. Сначала она вводила с помощью клавиатуры названия и команды, копируя их буква за буквой из набора карточек. Вскоре она уже вводила свои любимые слова по памяти. Менее знакомые слова она находила, выискивая их в кипе карточек. Если у нее было настроение, она пробовала вводить новые, случайно попадавшиеся ей слова. Если показать ей эти слова на карточках или где-либо еще, она узнает изображения букв и ассоциирует их с соответствующим звуковым выражением. Кроме того, слова имеют для нее определенный смысл. Она знает, что они означают: предметы или действия.
В прошлом слова для чтения всегда были знаками алфавита, призванными вызывать определенный образ. Для Пегги они, кроме того, являются указанием, как ввести команду в компьютер. Удивительная особенность этой новой концепции слова по сравнению с квазифонетическим декодированием состоит в том, что ребенок и компьютер вместе декодируют буквенный ряд печатного слова в команду, которую выполняет компьютер и значение которой ребенок может оценить. И наконец, поскольку компьютер может интерпретировать определенные слова, которых ребенок еще не знает, ребенок может учиться у компьютера, самостоятельно определяя сферу исследований и экспериментов.
Главный урок, который я извлек из этого опыта, касается отнюдь не просто "мотивации" - хотя Пегги получала удовольствие от игры с этими микромирами и многому при этом научилась. Имеется один, принципиально новый и в то же время парадоксальный аспект. Новая техника может сделать восприятие более "естественным". Характер слов, воспринимаемых в качестве исполняемых процедур, поставил Пегги в новые отношения с языком; эти отношения отличаются от тех, которые были присущи обучению чтению в прошлом.
Обучение чтению с печатных форм неизбежно является для ребенка пассивным процессом. Слово в книге символизирует значение, которое ему придают другие. Пока дети не начнут писать, они не могут использовать написанные слова в своих целях. Микрокомпьютеры с самого начала объединяют чтение и письмо. Слово, которое Пегги может прочитать, она может также воспроизвести в интересующем ее компьютерном выражении. Для нее изучение алфавита стало скорее похожим на процесс обучения детей говорить со слуха. Если ребенка внимательно слушают, для него это проявление силы, даже если он знает всего несколько слов. Аналогичным образом изображение знаков алфавита, пусть даже одной буквы или одного слова, может иметь для ребенка большое значение, если компьютерный микромир становится терпеливым и разумным средством преобразования этих знаков.
Так как речь является естественным свойством человека всех культур нашего мира, вполне обоснован вопрос, могут ли самые общие и ценные аспекты опыта Пегги быть приспособлены для культур, отличных от той культуры, к которой принадлежит Пегги. Если бы ЭВМ могла сделать обучение чтению и письму более похожим на обучение речи и пониманию, то она, вероятно, коренным образом изменила бы интеллектуальный характер мира, в котором мы живем.
Главным достоинством машинного языка ЛОГО является то, что в нем любое слово, любой ряд символов могут быть наделены функцией. Например, слово "sun" ("солнце") может привести в действие машинную процедуру, которая воспроизведет графическое изображение солнца. Поскольку и орфография слова, и его смысловое значение задаются составленной командой, слова компьютерных микромиров не зависят от "естественного" языка программиста. Например, та же процедура, которая создает "sun", может быть введена для слова "soleil" ("солнце" по-французски) или "jant" ("солнце" по-сенегальски). Хотя компьютерные слова и не зависят от языка, все, что сделано для использования человеком, неразрывно связано с его культурой. Только люди, имеющие аутентичный культурный опыт, могут знать, чтб в рамках данной культуры подойдет их детям, будет соответствовать близкой их сердцу домашней обстановке и будет далее вовлекать их в учебу, прививая любовь к ней.
Какие именно из возможностей компьютерной техники нужно использовать для детей, должны определять сами дети, их родители, учителя и другие люди, работающие непосредственно с детьми и разделяющие их опыт. Хотелось бы, чтобы эти люди были внимательными и заботливыми наставниками, с прогрессивными взглядами к на обучение детей, которых они любят. Компьютеры и их языки должны быть доступны этим людям и просты в обращении как средства повседневной творческой деятельности. В противном случае они не будут отвечать интересам детей всего мира.
Однажды мы с Пегги показали пляжный микромир двум людям - Мамаду Ньянгу и Мусе Гнингу. Эти сенегальские учителя, приехавшие в Нью-йоркский ЛОГО-центр, чтобы ознакомиться с компьютерами и программным языком ЛОГО, очень увлеклись микромирами, которые я разработал для дочери. Они рассказали, что в Сенегале очень остро стоит проблема грамотности, и выразили надежду, что компьютеры будут способствовать обучению детей их страны. Впоследствии их коллега и технический советник Силла Фатимата объяснила, какую важную роль могли бы сыграть ЭВМ в этой области.
Сенегальские дети дошкольного возраста обычно живут в теплом семейном кругу. Дома они растут и воспитываются в культурной среде своих традиционных языков, таких, как волоф. В школе они попадают в холодную, безликую атмосферу, где обучение ведется на французском языке. Некоторые привыкают и успешно занимаются, но многие пугаются и не хотят учиться. Для них учеба в школе означает отчуждение от людей, которых они любят, и они отвергают это отчуждение, несмотря на все попытки увлечь их.
В связях Сенегала с внешним миром преобладающим языком является французский. Знание этого языка открывает возможности в правительственных кругах и сфере торговли. Кроме того, французский язык господствовал и продолжает господствовать в образовании. Сенегальцы намерены защитить и дать дорогу своим традиционным языкам с помощью современной техники, в частности для развития обучения детей языку волоф. Хотя волоф существует в письменной форме (на базе дополненного латинского алфавита) уже более ста лет, только в последнее десятилетие транскрипция языка была стандартизирована по всей стране. В результате возникает парадоксальная ситуация: многие образованные люди в стране знают французский и даже арабский язык, но не умеют читать и писать на своем традиционном языке, которым они пользуются дома и на работе, общаясь со своими африканскими коллегами.
Стремясь изменить такое положение, сенегальцы не без основания считают, что им лучше разрабатывать программы для компьютеров на языке волоф, чем на французском или любом другом языке изготовителя ЭВМ. Поскольку не существует твердого "учебного плана" по обучению с помощью компьютеров на французском языке и не было потрачено много лет на подготовку учителей для обучения французскому с помощью компьютеров, они справедливо полагают, что новая техника обладает огромным потенциалом, который, если не упустить эту возможность, можно использовать для развития традиционного языка и культуры.
Вместе с другими участниками сенегальского микрокомпьютерного проекта Мамаду Ньянг и Муса Гнинг приехали в Париж в Международный центр вычислительной техники и развития человека, чтобы расширить свои знания ЛОГО. Поскольку лучший способ научиться применять машинный язык - это использовать его с определенной целью, я предложил Мамаду придумать какой-нибудь микромир для сенегальских детей, а я бы помог ему в компьютеризации; моя идея заключалась в том, чтобы совместно разработать программы, которые понравятся сенегальским учащимся. Мамаду заметил, что в Сенегале, в частности в Дакаре, конечно, есть пляжи, но поскольку их задачей было заинтересовать всех сенегальских детей, то было бы целесообразней подумать о микромире с сельской тематикой. Он предложил деревню с несколькими небольшими зданиями и колодцем. Чтобы оживить такую сцену, потребуются люди и домашние животные, обычные для деревни, - коровы, лошади, кошки и т.п. Мы решили создать всего лишь несколько объектов, оставив детям радость творчества; мы хотели дать им самим возможность решать, что они хотели бы иметь в своем мире, и обеспечить их всем необходимым для осуществления этого.
Поскольку мы являемся представителями совершенно разных культур, было бы уместно рассказать о нашей совместной работе. Мы стремились к обмену идеями. Наibv рабочим языком был французский; в конце концов в Париже все говорят по-французски, а Мамаду и Муса владели французским гораздо лучше меня. Я был им признателен за то, что они терпимо относились к моим слабым знаниям французского, благодаря чему мы могли работать вместе. Компьютер, которым мы пользовались, был ЛОГО-компьютером на английском языке. Когда им удавалось разъяснить мне свою идею, я предлагал и демонстрировал им возможности программ и приемы воплощения в жизнь того, что хотел иметь в микромире Мамаду. На смеси французского, английского и машинного языков они начали с моей помощью программировать маленькие сценки, конструировать объекты для этих сценок и задавать некоторые команды для управления их внешним видом и действиями.
Когда мы создали сцену с несколькими командами на французском языке, научившись более или менее управлять задуманными объектами этого микромира, мы начали обсуждать возможность перехода на язык волоф. Особо важную роль в этом сыграл Муса. Как передовой методист преподавания языка волоф в начальных классах в Сенегале он мог проверить правильность орфографии в командах для создания и передвижения предметов нашего деревенского микромира. (Иногда приходилось советоваться с другими членами сенегальской делегации, в т.ч. с лингвистом Пате Диань.)
Поскольку на языке ЛОГО любой ряд "вводимых с мощью клавиатуры" символов может стать именем процедуры, мы смогли ввести для существующих процедур вместо французских слов соответствующие слова на языке волоф. Так мы получили систему процедур и изображений, способных воспроизводить деревенский микромир.
Если деревенский микромир кажется бедным и несовершенным, то на это есть свои причины. Он был создан не для того, чтобы произвести впечатление на программистов или служащих. Это не столько продукт, сколько npoект, дающий несколько примеров того, что возможно сделать. Это мир, создавать который придется сенегальским детям. Должен ли я решать, что им нужно? Должны ли даже учителя решать, какие существа и каких людей вводить им в мир их воображения?
Именно Мамаду лучше всех выразил верный подход к деревенскому микромиру. Когда я сказал, что образ "fas" неправдоподобен, совсем не похож на лошадь, он ответил: "Я уверен, что дети сделают лучше".


"Переделываем" лошадь.

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


Юные сенегальские школьники манипулируют деревенским микромиром под наблюдением Мусы Гнинга.

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

avatar
Gudleifr
Admin

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

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

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

Re: 01.05. ЕСЛИ ТЫ НАСТОЯЩИЙ МУЖЧИНА, ПОСМОТРИ НА МЕНЯ В ПРОФИЛЬ!

Сообщение автор Gudleifr в Пн Дек 04, 2017 1:20 pm

Я - ЗА МИНИМАЛИЗМ

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

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


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

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



Кроме выгод упрощения, такой подход нам дает возможность:

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

А насколько проще станет программа?



Смотрите - TXT, 0.11Мб! Если выкинуть 3/4 текста - DATA картинок и структурно/объектную обфускацию/комментирование - останется буквально сотня операторов "нарисовать фигульку, если выполнено условие, установить флаг" (и никаких "плиток" и косвенной адресации):

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

Даже синхронизация путем подбора нужной комбинации SLEEP и INKEY$ вполне очевидна. И всего одного цикла хватило!

DO
- TICK=TICK+1
- БЫСТРЫЕ СОБЫТИЯ
- AKEY=INKEY$
- IF TICK > SPEED
- - TICK=0
- - СЛУЧАИ И СОБЫТИЯ
- - - АВАРИИ
- - SLEEP 1
- - МЕРЦАНИЕ
- - ОБРАБОТКА AKEY
- - ДВИЖЕНИЕ ФИШКИ
LOOP WHILE AKEY <> ESC AND КОНЕЦ=0


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

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

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

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

Re: 01.05. ЕСЛИ ТЫ НАСТОЯЩИЙ МУЖЧИНА, ПОСМОТРИ НА МЕНЯ В ПРОФИЛЬ!

Сообщение автор Gudleifr в Пн Дек 04, 2017 1:34 pm

ПРИ ЧЕМ ЗДЕСЬ СОЛДАТИКИ?

Сейчас общепринятым считается мнение, что компьютерная игра должна иметь реалистичную трехмерную графику и позволять игроку, в принципе, делать то же, что и в жизни, плюс "дополнительные степени свободы" (a la Marvel). См. размышления о замене "комнат" честным 3D - gudleifr.forum2x2.ru/t34-topic.


Вот, например, кадр из осовремененной переделки Carrier Command. Причем, в игре качество гораздо выше. Настолько выше, что тонкости лежат за пределами нормального человеческого восприятия.

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



Тут уж вспоминается, скорее, цитата из Стругацких: "А, почему рога?" То ли дело, фантастика тех времен, когда не мы с Запада копировали, а они у нас:


Г.Адамов, "Изгнание владыки".

Зачем мне "лишние подробности"? Я - за соцреализм!

ТЕМА #15, АБЗАЦ #32
***

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

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

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

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

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

Re: 01.05. ЕСЛИ ТЫ НАСТОЯЩИЙ МУЖЧИНА, ПОСМОТРИ НА МЕНЯ В ПРОФИЛЬ!

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


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


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

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

- Похожие темы

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