История видеоигр, часть 4: OXO (1952)

Надо сказать, ведение блога заставляет меня напрягать воображение. Делать второй обзор на крестики-нолики всего через одну статью - непростая задача. К несчастью для меня, пройдёт ещё много времени, прежде чем игроделы начнут заморачиваться такими вещами, как графическое оформление, сюжет, персонажи, сеттинг и прочее. Сейчас же 1952 год, и Александер С. Дуглас разрабатывает программу для EDSAC, которая позволит схлестнуться в крестики-нолики с искусственным интеллектом. Обратите внимание, что это первая игра, для которой не создавалось специальной аппаратной платформы: EDSAC - компьютер общего назначения, не заточенный под OXO.

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

EDSAC был одним из первых компьютеров, который при исполнении программы мог как считывать данные из памяти, так и записывать их туда. Для отображения состояния памяти он был оборудован тремя дисплеями 35х16 точек, один из которых Дуглас приспособил для вывода игрового поля. Игрок делал ходы, крутя наборный диск (как у старых телефонов). Компьютер отвечал, играя "идеальную партию", то есть следуя алгоритму, при котором игра всегда сводилась к ничьей или проигрышу человека. Так-то.

Оригинал статьи

Уроки ОСдева №3: блок параметров BIOS

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

Олдфажного геймдева пост номер 3

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

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

Теперь про опознание предметов. Тоже стандартная вещь для рогаликов и RPG, к которой я решил подойти с необычной стороны. Для опознания вещей определённого типа нужно обладать соответствующим навыком. Например, герой с развитым навыком медицины будет различать зелья регенерации, антидоты и прочее, а без него увидит просто potion(?).

Работы ещё до чёрта. Из пока нереализованного:

- главный и побочные квесты, 6 концовок. Прописаны пока только на бумажке.

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

- магия и боевые умения для героя и его противников.

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

- апгрейд и ремонт снаряжения. Впрочем, оно пока и не ломается.

- черты персонажа, открываемые за развитие навыков или атрибутов. Что-то похожее было в Oblivion, если кто помнит.

- возможность слышать звуки из соседних комнат.

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

- примерно по полсотни видов противников и снаряжения.

- механика обезвреживания ловушек.

История видеоигр, часть 3: Nimrod (1951)

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

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

Машина размером 3,65 на 2,74 на 1,52 метров была собрана специально для этой задачи и представлена на Фестивале Британии. Как и другие игровые аппараты этой эпохи, Nimrod был создан для демонстрация технических возможностей или инноваций компании-производителя. Реализацией проекта занимались служащие Ferranti австралиец Джон Беннетт и британец Реймонд Стюарт-Виллиамс. Первый был ответственен за разработку концепции и схемы устройства, второй - за практическое исполнение.

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

Несмотря на произведённый на выставке ажиотаж, Nimrod был разобран, а компания Ferranti продолжила делать компьютеры общего назначения. Оба автора в становлении игровой индустрии тоже никак не участвовали.

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

Уроки ОСдева №2: схемы адресации и твоя первая программа на ассемблере

Если кто-то решил следовать этим туторам, самое время обзавестись необходимыми инструментами. Скачайте turbo assembler (TASM) или любой другой привычный вам. Установите виртуальную машину с Windows XP. Работать с большинством используемых программ проще в ней. Я бы посоветовал Oracle VirtualBox.

CHS

В прошлый раз мы выяснили несколько важных вещей:

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

- программа-загрузчик должна занимать ровно 512 байт, причём последние два байта должны содержать метку загрузчика (AA55h).

- программа-загрузчик должна располагаться в первом физическом секторе носителя.

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

На картине выше - структура дискового носителя. Это может быть жёсткий диск, дискета или CD, суть не поменяется. Головка, она же лицо, - это одна сторона поверхности носителя (пластины). У жёсткого диска на рисунке 4 двусторонних пластины, то есть 8 головок. Головка в свою очередь разбита на концентрические дорожки (они же цилиндры), а те - на одинакового размера (как правило 512 байт) секторы. Независимо от радиуса цилиндра в каждом из них одинаковое число секторов, что позволяет для доступа к любому конкретному сектору использовать трёхкомпонентную координату Цилиндр-Головка-Сектор (Cylinder-Head-Sector, CHS). Важно помнить, что в системе CHS цилиндры и головки нумеруются с 0, а секторы - с 1. То есть для доступа к первому физическому сектору носителя наши координаты будут иметь значения: 0(цилиндр), 0(головка), 1(сектор).

Проблема в том, что привычные нам файловые системы скрывают физическую геометрию носителей за набором абстракций вроде файлов и папок. К счастью, есть альтернативы. Например, в Windows есть команда debug. Выглядит так:

debug boot.bin(имя файла, загружается в память по адресу 100h)

-w(запись) 100(адрес загруженного файла) 0(номер привода) 0(номер первого сектора) 1(число секторов для загрузки)

-q(выход)

Я выше писал, что секторы нумеруются с 1, но debug закон не писан. Всё остальное время правило в силе.

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

LBA

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

boot.asm

Итак, мы разобрались, как поместить нашу программу в нужное место на дискете. Самое время приступать к написанию кода! Мы, конечно, не будем в этот раз писать полный загрузчик. Это будет просто небольшая вводная в турбо ассемблер. Она предназначена для людей без опыта в ассемблере и подразумевает, что вы будете пользоваться TASM. Если вы уже знаете x86 ассемблер и намерены пользоваться каким-то другим - смело пропускайте конец статьи.

Скачали TASM? Отлично, инсталлируйте его в какое-нибудь легкодоступное место на диске и в папке BIN/ создайте папки OS/boot/stage1/.

Теперь в stage1/ создайте пустой текстовый файл, переименуйте его в boot.asm и откройте текстовым редактором. В файле создайте следующий текст:

.386p

CSEG segment use16

ASSUME cs:CSEG, ds:CSEG, es:CSEG, fs:CSEG, gs:CSEG, ss:CSEG

begin:

CSEG ends

end begin

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

.386p - указание компилятору сверять инструкции с набором для 386 процессора в защищённом (protected, отсюда p) режиме. Соответственно, если компилятор встретит инструкцию, которую данный процессор не поддерживает, он выдаст ошибку.

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

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

begin - метка начала программы. Отсюда будет начинаться собственно код.

CSEG ends - конец сегмента CSEG.

end begin - метка конца программы.

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

.386p

CSEG segment use16

ASSUME cs:CSEG, ds:CSEG, es:CSEG, fs:CSEG, gs:CSEG, ss:CSEG

begin:                    cli

                             hlt

CSEG ends

end begin

Мы добавили 2 команды: cli и hlt. Первая запрещает прерывания, то есть не даёт устройствам отправить сигнал процессору, а вторая останавливает сам процессор. Таким образом, сейчас наша программа при запуске просто "вешает" компьютер. Тем не менее, её уже можно превратить в исполняемый файл.

Откройте командную строку, перейдите в папку BIN/ и введите: tasm OS/boot/stage1/boot.asm. После нажатия enter в папке BIN/ появится файл BOOT.OBJ. Это ещё не конец. Файл .obj - это инструкция для линкера, так что пишите: tlink boot.obj. Теперь у вас добавились два новых файла, BOOT.MAP и BOOT.EXE, последний из которых - и есть исполняемый файл, который нам нужен! Незадача в том, что мы пишем не приложение под DOS, а операционную систему, которая должна будет работать на голом железе. exe-формат содержит таблицы релокации и всякие прочие данные, которые нам будут мешать. В нашем исполняемом файле должны быть только инструкции программы и больше ничего. К счастью, и тут есть готовое решение. Пишите в командной строке exe2bin boot.exe и жмите enter. Появился файл boot.bin. Проверьте его размер, он должен занимать ровно 2 байта, по одному байту на инструкции cli и hlt. Успех!

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

Олдфажного геймдева пост номер 2

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

Для начала - о том, что есть сейчас. Бой проходит в пошаговом, разумеется, режиме. Врагов может быть до четырёх штук. Игрок выбирает цель, затем выводятся результаты раунда. Попал или не попал, если попал, то сколько нанёс урона и убита ли цель. То же самое для противников. Очередность действий участников определяется сравнением их Dexterity.

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

С первым пунктом у меня достаточно просто. Враг может быть In melee range - доступен для атаки любым способом и может атаковать в ответ. Out of melee range - достать можно копьём, стрелой или магией, но и сам он атаковать может только дистанционно. Враги начинают бой в случайной позиции, но у каждого есть предпочтительное положение и в процессе боя он будет стараться занять именно его. Сблизиться на дистанцию ближнего боя с врагами в тылу можно только после того как будут убиты все "передние". Особняком стоят летучие враги - этих можно достать дистанционной, магической или контратакой, но нельзя обычной атакой копьём.

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

Добавьте к этому разнообразные эффекты, которые влияют на поведение противников: ошеломление, горение, заморозка, отравление и т.п. Кроме того, есть магические заклинания, которые позволяют накладывать эффект на всё поле боя: поджечь, покрыть льдом или заполнить ядовитым дымом.

Фуx. Это ещё не все запланированные боевые возможности, но для одного раза достаточно. Пы сы: из этого поста можно заключить, что бои - это основная, если не единственная, часть игры, но нет. Я сторонник идеи, что игроку нужно давать свободу двигаться к цели тем способом, который ему нравится, поэтому игру можно будет пройти скрытно или за счёт дипломатии.

История видеоигр, часть 2: Bertie the Brain

Всего через три года после Cathode-ray tube amusment device на свет появился второй кандидат на звание первой в мире видеоигры. Как мы увидим позже, Bertie the Brain также не удовлетворяет всем критериям определения "видеоигры", так что вопрос о первенстве остаётся открытым.

Автор, Джозеф Кейтс (Кац), родился в 1921 году в Вене в семье австрийских евреев Баруха и Анны Кац. Как вы понимаете, жизнь еврейского юноши в то время оказалась нелёгкой: бегство от нацистов в Италию, а потом в Британию, депортация как потенциально враждебного элемента в Канаду, два года в лагере. После выхода на свободу в 1942 году Джозеф осел в Торонто и устроился на работу в Имперскую Оптическую Компанию, где два года занимался созданием точной оптики для канадского флота. Оттуда перешёл в Rogers Vacuum Tube Company, а затем в вычислительный центр при Университете Торонто. В обоих местах деятельность Кейтса была связана с разработкой радиоламп. Где-то в начале 50-го года Джозеф Кейтс решил, что настало его время двигать прогресс и сконструировал лампу-аддитрон. Одна такая лампа могла выполнять роль полного сумматора, для чего требовался комплект из 10 обычных вакуумных ламп.

Для демонстрации своего изобретения на Национальной выставке в Торонто Кейтс и собрал устройство, которое назвал Bertie the Brain. По сути это компьютер для игры в крестики-нолики. Внушительное устройство состояло из 4-метрового корпуса, панели с девятью кнопками, организованными в поле 3 на 3, и дисплея для отображения хода игры. Справа от дисплея располагались индикаторы, которые показывали, чей сейчас ход.

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

Как и CRTAD, Bertie the Brain остался просто малоизвестным историческим курьёзом, и даже его основная задача - продвижение лампы-аддитрона - оказалась проваленной: ещё до того, как Кейтс уладил все дела с патентом, вакуумные лампы были вытеснены транзисторами. Это не нанесло непоправимого вреда карьере Джозефа Кейтса, который позже стал основателем своей собственной компании, не имеющей, однако, никакого отношения к игровой индустрии и поэтому для нас малоинтересной. После выставки Bertie the Brain был разобран и навсегда забыт.

Раз уж мы здесь, почему бы не взглянуть одним глазом на историю игры, ставшей основой для Betie the Brain? У нас она известна под именем "крестики-нолики" или ранее как "херики-оники". Считается, что происходит от древней китайской игры "вэй-чи" или "гомоку" по-японски, где два игрока по очереди выкладывали на расчерченную клетками доску белые и чёрные камешки, пытаясь выложить линию нужной длины и не дать сделать того же своему противнику.

История видеоигр, часть 1: Cathode-Ray Tube Amusement Device

Небольшое предисловие: текст ниже взят из моего блога Silicon Darwin. Зачем я перепощиваю его здесь вместо того, чтобы просто кинуть ссыль? Начиная блог, я xотел делать, что называется, качественный контент. Жизнь внесла свои коррективы, и как-то так вышло, что статьи писались в спешке, на коленке, с головой, занятой другими вещами. Недавно я пробежался по блогу и решил, что он мне не нравится. Я xочу переписать всю сотню статей, что там накопилась. Спокойно, без спешки, добавить исторический контекст, рассказы об автораx, всякое такое. По мере обновления буду выкладывать сюда. Тем не менее, для желающиx вот ссыль.

Спорный вопрос, можно ли считать УУЭЛТ первой видеоигрой. Технически оно удовлетворяет не всем критериям: не имеет цифрового компьютера и не использует программного кода. Тем не менее, я считаю правильным начать именно с него. К сожалению, изображений УУЭЛТ не сохранилось, читателю придётся довольствоваться моим путаным объяснением. ЭЛТ использовалась для вывода движущейся точки на экран осциллографа (напоминавший экраны радаров, над которым Голдсмит работал во время войны). Вращая одну из двух управляющих рукояток, игрок мог изменять высоту дуги, по которой точка перемещалась из одного конца экрана в другой. Эта точка символизировала летящий артиллерийский снаряд. В определённый момент, наступление которого можно было регулировать другой рукояткой, точка расплывалась, что обозначало взрыв. Поверх экрана были наклеены полупрозрачные силуэты разной военной техники, которые использовались в качестве целей: механизмов для вывода сложной графики тогда не было. Разумеется, игра не могла сама вести счёт, рядом с игроком должен был сидеть беспристрастный судья, фиксирующий его успехи.

Появление УУЭЛТ нельзя назвать отправной точкой в формировании игровой индустрии. Время и обстоятельства к этому не располагали: DuMont Laboratories не стали запускать устройство в продукцию, и до недавнего времени широкие массы вообще о нём не знали. УУЭЛТ осталось просто историческим курьёзом, а его создатели занялись другими, более важными и интересными вещами. Тем не менее, как и в живой природе, эволюция не идёт по прямой. Эволюция это пробы, ошибки и миллионы тупиковых путей, которые, хотя никуда и не ведут, интересны сами по себе.

Уроки ОСдева №1

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

P.S.: если знаете английский, советую зайти сюда. Это довольно старая серия уроков по ОСдеву для новичков. Я в своё время почерпнул там очень много и в своих постах наверняка буду невольно цитировать оттуда.

Часть 1, теоретическая.

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

Я думаю, стоит начать с включения компьютера. Это не шутка: чтобы создать свою операционную систему, надо до определённой степени понимать как работает компьютер. Что происходит, когда вы нажимаете кнопку POWER на системном блоке и как у вас на экране оказывается ваш заваленный ярлыками и "новыми папками" рабочий стол? Для того, чтобы программа (а наша ОС - это, конечно же, программа) начала исполняться, она должна сначала попасть в оперативную память. Содержимое оперативной памяти же на момент включения пусто. Если среди читающих есть инженеры, советую зажмуриться и пропустить до следующего абзаца: сейчас будет упрощённая модель.

1. Нажатая кнопка POWER посылает электрический сигнал на материнскую плату.

2. Сигнал доходит до материнской платы и отправляется к блоку питания.

3. Блок питания просыпается и начинает подавать энергию подключенным устройствам.

4. Блок питания посылает сигнал на материнскую плату, начинает исполняться программа BIOS.

5. BIOS проводит POST (power-on self-test), посылая сигналы разным устройствам и получая (или не получая) от них ответ. Если устройство не отправило ответ, оно помечается как нерабочее или отсутствующее. Тут же BIOS определяет количество оперативной памяти и некоторые другие параметры системы.

6. Если POST окончен и никаких критических поломок не выявлено, BIOS сверяется со списком загрузочных устройств. Наверняка вы хоть раз его видели, если устанавливали Windows: его обычно можно настроить через интерфейс BIOS, выбрав, с чего загружать ОС (floppy, HDD, USB, ...).

Вот тут начинается часть, которая интересует нас. Предположим, мы вставили дискету с нашей ОС в привод и настроили приоритет загрузки следующим образом: CD-ROM, флоппи-привод, жёсткий диск, USB. Как BIOS определит, что на одном из носителей есть операционная система для загрузки? Физическое устройство цифровых носителей и способы доступа к информации на них это тема для отдельного урока или даже нескольких, так что пока удовольствуемся упрощённой схемой: BIOS считывает с 0 по 511 байты носителя и проверяет, чему равны байты 510 и 511. Если они равны 170 и 85 (AAh и 55h в шестнадцатеричной системе), BIOS считает, что нашёл программу-загрузчик. После этого считанный участок носителя размером в 512 байт загружается в оперативную память и запускается центральный процессор компьютера, который начинает выполнять загруженную программу. Программа-загрузчик догружает остальные файлы ОС и располагает их в памяти нужным образом, а потом говорит процессору, откуда нужно начать выполнение ОС.

Какие выводы можно сделать из полученной информации?

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

2. Загрузчик должен быть не больше 510 байт, ведь BIOS считывает 512 и последние два из них заняты меткой загрузчика.

3. Последние два байта программы-загрузчика должны быть равны AA55h.

3. Загрузчик должен занимать строго определённое место на носителе: с 0 по 511 байты. Думаю, вы замечали, что когда копируете файлы на носитель обычными методами, никто не спрашивает вас, в какой именно участок памяти вы хотите их поместить. Значит, копировать загрузчик нужно каким-то особенным способом.

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

Олдфажного геймдева пост

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

Несколько лет назад я по приколу начал пилить с нуля ОС для ПК с x86-ми процами. Без комментариев, просто заxотелось. Потиxоньку занимаюсь ею и по сию пору. Появилось порядка 20 нерабочиx версий, одна полурабочая и одна (будем надеяться) нормальная, которая ещё не окончена. Операционка получилась как я люблю: грузится с дискеты, даёт минимальный интерфейс к  клавиатуре, дисплею и флоппи-приводу, позволяет запускать плоские бинарники с точкой вxода 500000h и не мешает. В следующей версии будут ещё всякие излишества вроде поддержки жёсткого диска и графическиx режимов VGA, но сейчас не о том.

Мне стало жаль просто убрать в ящик ту полурабочую версию оси и я решил написать под неё игру. Конечно, в дуxе самой ОС: олдфажный текстовый рогалик, как бы плод запретной связи Colossal Cave Advenure и Rogue. От первой достались текстовые описания и перемещение по "комнатам", от второй - процедурная генерация, голод, xолод и пермасмерть.

Сразу опишу основные фишки проекта и приведу немного цифр:

- 1000 комнат

- 7 концовок

- износ, ремонт и апгрейд снаряжения

- прокачка атрибутов, заклинаний и навыков от использования

- около 50 видов монстров

- около 25 видов магии

- около 1,5 часов на успешную партию

- дружелюбный интерфейс

Ну и напоследок несколько скринов из последней и старыx версий:

Игра в процессе разработки, текущая версия готова процентов на 30 в смысле меxаник и примерно на 5 в смысле контента. Если кому интересно, в следующем посте выложу ссыль и инструкцию для запуска. Ну а так - приветствую комменты и просто потрепаться за жизнь, низкоуровневое программирование и геймдев.