на каком языке написаны игры для сега

На каком языке программирования писались игры для сега?

Несмотря на то что это очень старая игрушка, играть в Некторые игры не так уж и просто, а для нас это воспоминания, просто вспомнить как это было и повеселиться, Просто показать нашим детям с чего все начиналось

Группа перевода игр «Шедевр» перевела множество отличных игр для сега и денди на их сайте можно найти множество переводов.

«Magicteam» группа перевода приставочных игр которая так же перевела немало игр для денди и сега которые присутствуют на их сайте.

owls-group только один перевод «Yu Yu Hakusho» для сеги, остальное для Nintendo DS

Тут нет лучше или хуже, тут есть новее и старее. Сега новее денди.

Лично мне нравится сега, на нее намного больше игр придумано.

И еще момент цена: денди дешевле чем сега.

Приставка была разработана исследовательской группой под руководством Масами Исикавы на основе аппаратного обеспечения аркадного автомата Sega System 16. В качестве первичного центрального процессора был определён Motorola 68000, вторичным стал Zilog Z80. На данную игровую систему было разработано более 900 игр, в создании которых принимала участие как сама компания Sega, так и сторонние издатели; игры распространялись на игровых картриджах. Sega Genesis имеет обратную совместимость с Sega Master System, которая достигается путём использования устройства Power Base Converter, поставлявшегося отдельно. Для консоли также были разработаны различные периферийные и сетевые устройства. Приставка выпускалась в различных вариациях, которые были направлены на улучшение функциональности.

Источник

Как писались игры на Dendy

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

Тогда и сейчас

В наше время разработка для игровых приставок все больше напоминает написание программ для обычных компьютеров, разница между тем что творилось тогда и тем, что имеет сегодняшний разработчик колоссальна. С одной стороны, сегодня, технологии и культура разработки шагнули далеко вперед, позволив вести разработку на языках высокого уровня, с другой — в 80-е фирмы, выпускающие приставки, еще не до конца понимали что следует дать сторонним разработчикам для создания игр. И поэтому если сейчас для очередной playstation можно получить документацию, пяток демо-дисков, а также мощную девелоперскую станцию, по сути гибрид самой приставки и компьютера общего назначения, пригодного для непосредственной разработки, то например в 80-е многие разработчики довольствовались книжечкой со спецификацией консоли. А вот за аппаратной частью приходилось идти на радиорынок (или что там было в штатах вместо них?).

Немного истории

Принято считать, что изначально была создана Nintendo Entertainment System (NES), с которой уже была спирачена наша Dendy и десятки других клонов по всему миру.

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

В далеком 1983 году Nintendo могла только мечтать о сторонних разработчиках для новоиспеченной консоли. Так что первые несколько игр были созданы самими авторами консоли. Некоторые из них были портами игр, уже существовавших на аркадных автоматах. Эти игры отличались примитивностью даже по меркам NES, не используя всех возможностей ее аппаратной начинки. Все игры того стартового периода умещались на один экран и не занимали более 32 килобайт данных на картридже. Наиболее известные игры того периода: Donkey Kong, Balloon Fighter, Mario Bros. Ирония заключалась в том, что NES имела специальную аппаратную поддержку для скроллинга уровней, но самые первые игры сайд-скроллерами не являлись, хотя и были выпущены компанией, которой сам бог велел, зная все особенности их консоли, выпускать игры, максимально подчеркивающие преимущества новой приставки.

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

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

Картриджи

Спецификации NES-картриджа до сих пор могут быть найдены в интернете, и, вообще, довольно подробно разобраны сообществом. Но сам процесс производства картриджей — это тайна покрытая мраком. Более менее достоверно известно что на территории Европы и США выпуском картриджей занималась исключительно Nintendo. В смысле, самих коробочек с микросхемами.

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

Каждый разработчик должен был явно указывать в заголовке скомпилированной игры(ROMа) перечень функций NES, которые будут использованы игрой. Некоторые функции поддерживались «обычными» картриджами — например маппер памяти, а вот за наличие сохранения или лишней оперативной памяти приходилось доплачивать Nintendo, чтобы та включила заветные чипы в ваш будущий картридж.

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

Архитектура картриджей подразумевала что сама программа и графические спрайты находятся в разных чипах. Вот например фотография картриджа Super Mario Bros.

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

Оборудование для разработки

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

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

В случае RAM-картриджей разработка шла гораздо быстрее. Можно было редактировать память прямо в процессе игры, используя для этого компьютер, на котором, собственно, и велась разработка. Чип EEPROM заменялся на банки оперативной памяти, которые с одной стороны виделись консолью как обычный картридж, а с другой стороны подключались к компьютеру разработчика и были для него обычной оперативной памятью… или диском… или устройством — все зависело от того, какой именно драйвер программист писал для своего детища.

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

На каких компьютерах проходила разработка — неизвестно, но, учитывая тот уровень возни с радиодеталями, который требовался чтобы запустить отладочную версию игры на приставке, особого значения модель компьютера не имела. Точно известно, что японские разработчики применяли компьютеры MSX. С большой долей вероятности можно сказать, что в США применялись компьютеры Apple 2, ввиду того, что они были довольно распространены, а также имели процессор, аналогичный используемому в NES.

Программное обеспечение

Основной и практически единственный язык программирования использовавшийся для разработки игр — ассемблер, некоторые счастливчики писали на С, если могли достать компилятор. Но даже в этом случае, некоторые фирмы не покупали у Nintendo ассемблер а писали свой собственный. Чем это было вызвано сказать тяжело, но многие источники говорят о том, что в первые годы существования NES Nintendo не делилась своими инструментами со сторонними разработчиками.

Процессор, который использовался в NES, также имелся и в компьютерах вроде Apple 2 или Commodore 64, для которых были и свои ассемблеры и даже компиляторы С. Но архитектура NES все же имела некоторые отличия, а дикие системные ограничения и наличие банкинга(необходимости выгружать старые и загружать новые куски программного кода в область доступную процессору) не давали возможности писать на С игры, которые бы использовали максимум возможностей консоли.

Ассемблер — далеко не единственная вещь, которую приходилось писать вручную: редакторы графики, программаторы, отладчики: все это было написано по несколько раз заботливыми руками программистов. Отдельной статьей можно считать редакторы карт — следует помнить, что компьютеры были слабы и малопамятны, так что, например, вся карта для Metroid была нарисована вручную на бумаге, а потом уже кусками кодировалась в игру.

Процесс разработки

В разработчики часто набирали вчерашних студентов, не видевших NES в глаза. Для львиной доли мелких компаний создававших игры как нельзя лучше подходил термин «шарашкина контора». Типовая игра занимала 3-6 месяцев времени на разработку. Команды чаще всего были небольшими — 3-10 человек. Было много контор, которые выпускали 1 игру и потом исчезали без следа.

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

Сперва дизайнер рисовал эскизы бэкграундов и персонажей, затем, после отбора подходящих рисунков, начиналась так называемая пикселизация — палитра NES поддерживала только 14 цветов на экране одновременно, так что приходилось перераскрашивать рисунки с учетом этого ограничения. Затем рисунок расчерчивался по сетке, и при необходимости растягивался или сжимался — NES аппаратно поддерживала спрайты размером 8×8 пикселей. Персонаж Марио рисовался в 4 прохода, после съедания гриба — в 8 проходов. Мелочь, но иногда из-за ее игнорирования мы видели в некоторых играх пропадающие спрайты, когда на экране становилось очень много врагов, так что программистам приходилось экономить и на спичках. Кстати видеопамяти было 2 вида — одна, в которой обычно хранились спрайты персонажей и прочая мелочевка, вторая, побольше в которой хранились карты уровней. Последняя находилась в отдельном адресном пространстве и поддерживала аппаратно ускоренные операции по скроллингу.

Работа композитора плавно перетекала в работу программиста — написать музыку это только часть дела, закодировать ее в игру — тоже дело наживное, а вот затем начиналось самое интересное. Как было сказано выше, иногда игра подтормаживала, так что если в предрелизе такие тормоза достигали небывалых показателей, то композитору давали задачу «оптимизировать» музыку — убрать лишние опкоды, чтобы ускорить работу игры в целом. Тут-то и выяснялось истинное мастерство композитора. Лишнюю монетку в копилку позора композитора добавлял тот факт, что далеко не всегда разработчик игр по фильму получал лицензию на… использование музыки из фильма. Таким образом композиторам приходилось писать что-то оригинальное, и далеко не всегда хорошее.

Среди игр для NES был распространен так называемый репэкедж — это когда на базе одной игры делают другую меняя спрайты и уровни, иногда немного меняя сам игровой процесс. Например Castlevania и Ninja Gaiden сделаны на одном движке, также как и Darkwing Duck был сделан на базе движка для серии игр Megaman(Rockman). Каковы были истинные масштабы репэкджа мы можем только догадываться, особенно учитывая тот факт, что огромный процент игр на денди — однотипные сайд-скроллеры.

Разработчики

Как уже было сказано — многие из них были вчерашними студентами. В то время архитектур было немало, так что для принятия на работу часто достаточно было знания хоть какого-то ассемблера. Большой поток кадров перекочевал из когорты программистов аркадных игровых автоматов. Последних очень просто отличить по интервью — они всякий раз пытаются оправдаться системными ограничениями NES, с которыми они столкнулись после смены платформы. И правда — NES не была создана на острие технологий своего времени, она уступала тому железу, что ставилось в игровые автоматы. Зато стоила меньших денег покупателям и большей фрустрации программистам. Хорошее объяснение ограничений NES с точки зрения конечного программиста можно увидеть в этом видео: http://www.youtube.com/watch?v=Hvx4xXhZMrU.

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

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

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

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

Сегодня

В наши дни немало людей пишет игры для NES, но это уже совсем не то — 99% программируют свои примеры исключительно для эмулятора, не задумываясь о создании картриджей. Даже нет, лучше так: сегодня у программистов есть эмуляторы со встроенным отладчиком, готовые макроассемблеры и компиляторы С, некоторое количество редакторов спрайтов и музыки, созданных коммьюнити. Сайт nesdev.com содержит все, чтобы самому заняться этим кропотливым делом. Или же хотя бы стоит просмотреть раздел Wiki на данном сайте, чтобы узнать как много вы не знали о Денди.

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

Источник

Создание игры для SEGA Mega Drive/Genesis в 2019 году

Даже сегодня люди по-прежнему продолжают создавать новые игры для старых консолей. Мы называем их «homebrew». Иногда это способ реализовать детскую мечту о создании игры для консоли, на которой играл ребёнком. Но кроме того это ещё и интересная задача для любого дизайнера или разработчика игр: ретро-железо обладало множеством ограничений, бросающих вызов креативности авторов. В 90-х для профессиональных разработчиков эти ограничения были привычными. Сегодня, когда у нас есть более совершенные инструменты, создание игр для подобных машин стало гораздо доступнее.

В прошлом году я написал статью о создании игры для Game Boy. Сегодня я поделюсь своим опытом создания трёх игр для домашней консоли SEGA Mega Drive/Genesis. Вероятно, благодаря современным мощным инструментам, это самая простая машина для разработки homebrew-игры. Например, мне даже удалось создать (очень простую) игру всего за 60 минут, и она на самом деле запускается на консоли!

В прошлом году, чтобы отметить 30-летнюю годовщину выпуска Genesis / Mega Drive, я создал игру под названием «30 Years of Nintendon’t». Как понятно из названия, это дань памяти лучшим играм консоли и агрессивному маркетингу, который SEGA использовала в то время (например, слоган «Genesis Does what Nintendon’t»).

В этой игре мы управляем евангелистом SEGA, который должен убедить игроков забыть о своих NES и SNES, потому что на Genesis игры лучше! Игра была бесплатно выпущена онлайн на 30-й день рождения консоли. В неё можно сыграть здесь: https://drludos.itch.io/30-years-of-nintendont

С тех пор я также создал для консоли две (небольшие) аркадные игры:

Все эти 3 игры продаются на картридже, изданном Cote Gamers:

Он поставляется в красивой пластиковой коробке, как настоящие винтажные игры, и с набором почтовых открыток.

Можно ли использовать Unity, Unreal Engine или Godot?

На сцене появляется Blast Processing

Как вам скажет любой программист старых систем, если писать программу на C вместо ассемблера, то это снизит производительность игры. И это правда. Но затраты в разных ретро-консолях сильно различаются. Они зависят от используемых ЦП, а также от эффективности современных компиляторов, создающих код для таких винтажных процессоров. К счастью, в Mega Drive/Genesis используется процессор Motorola 68000, который достаточно хорошо подходит для работы с особенностями языка C. Особенно справедливо это по сравнению с другими ЦП, например с 65816 консоли SNES. Хотя сам по себе он и мощен, ЦП SNES сложно заставить выполнять написанные на C программы с достаточной скоростью. То есть когда дело доходит до homebrew-разработки на языке C, «Blast Processing» оказывается не маркетинговым мифом, а реальностью!

Насколько быстро может выполняться код на C?

Вот пример из личного опыта — анимированный GIF моей игры MeteoRain, в котором спрайты 45 метеоритов без задержек движутся с частотой 60fps:

А вот ещё один пример взрыва из Break An Egg, состоящего из 40 частиц, движущихся с частотой 60fps:

Если взять для примера старые игры, то хорошим примером мощи ЦП Mega Drive/Genesis является Contra Hard Corps. Хотя игра разрабатывалась на ассемблере, а не на C (ведь это было в 90-х), разработчики могли использовать огромную вычислительную мощь для перемещения множества спрайтов по экрану и создать запоминающихся боссов с кучей подвижных частей и масштабными взрывами.

Для сравнения, Contra III на SNES была ограничена мощью ЦП и вместо перемещения кучи спрайтов Konami использовала уникальные графические эффекты, на которые был способен только видеочип SNES, например, эффект прозрачности.

Несмотря на то, что обе игры одинаково интересны, они отлично подчёркивают технические различия между SNES и Mega Drive/Genesis. Подробнее о том, как Konami создавала каждую из игр под соответствующую консоль, можно прочитать в статье «Making of Contra III and Hard Corps» из Retro Gamer №176.

Графические ограничения

Поскольку вычислительная мощь не является проблемой, основным «бутылочным горлышком» консоли Genesis / Mega Drive для homebrew-разработчиков стали её графические ограничения. А если конкретнее, то ограниченное количество отображаемых ею цветов. Хотя в общем консоль может генерировать 512 уникальных цветов, одновременно на экране может быть не более 64 цветов. Ой-ёй. Для сравнения: SNES могла отображать одновременно 256 цветов из палитры 32768 уникальных цветов. То есть художникам графики нужен был большой талант, чтобы игры на SEGA выглядели так же хорошо, как на консолях конкурентов. И во многих случаях им это удавалось. Несмотря на цветовые ограничения, многие старые игры для Mega Drive/Genesis выглядят красивыми, например, Comix Zone, the Story of Thor, Streets of Rage II, Ranger-X, Gunstar Heroes, Sonic 1-2-3, и т.д.

Comix Zone (1995 год)

Но в других случаях игры Mega Drive/Genesis выглядели довольно блекло по сравнению с версиями для SNES. Один из самых известных примеров — это Street Fighter II, где цветовые ограничения консоли очень заметны:

Оптимальное использование ограниченных палитр (4 палитры по 16 цветов у Genesis против 16 палитр по 16 цветов у SNES) было большой сложностью для разработчиков, для завершения проектов у которых обычно было очень мало времени. Сегодня талантливые участники SEGA-сообщества способны модифицировать некоторые игры для оптимизации использования цветов. Например, Габриель Пирон творит чудеса с играми наподобие Castlevania Blood Lines, Golden Axe, Outrun или с вышеупомянутой Street Fighter II:

(Сверху — цветовая палитра оригинала, внизу — модифицированная Габриелем)

С учётом этого, вы можете использовать для создания изображений любимый графический редактор, но быть очень аккуратным при выборе цветов! Если вам не удастся соответствовать 512-цветовой палитре, прошитой в оборудовании, то это не проблема: SGDK автоматически преобразует изображение в палитру Mega Drive/Genesis. Но когда дело касается общего количества используемых и отображаемых на экране цветов, то вам придётся заниматься этим самостоятельно!

Заставляем объекты двигаться

Чтобы отобразить что-нибудь на экране, нужно скопировать графические данные из ПЗУ в видео-ОЗУ. Графический процессор не имеет прямого доступа к данным в ROM, но способен считывать данные из RAM. Поэтому чтобы фон или анимации спрайтов менялись, вам нужно регулярно копировать новые данные из ROM в RAM. А общее количество видео-RAM (VRAM) ограничено: всего 64 КБ. По сравнению с размерами игровых ROM (от 512 КБ до 8 МБ) это довольно мало.

Узкое место №1: передача во VRAM

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

Количество графических данных, которое можно передать из ROM во VRAM в каждом кадре (т.е. 60 раз в секунду), ограничено. Если конкретнее, то это 7524 байт на кадр, то есть около 7 КБ. Когда необходимо отображать огромные анимированные спрайты плюс анимированные фоны, как в Street Fighter II, то это ограничение постоянно мешает. И ведь это только первая проблема.

Узкое место №2: ограничения спрайтов

У 8/16-битных консолей ещё одна сложность заключается в общем количестве спрайтов, которое может отображать оборудование. Обычно ограничений два: одно для общего количества спрайтов на экране, другое для общего количества спрайтов в одной горизонтальной строке. У 8-битных консолей, таких как NES и Master System, эти ограничения очень суровы: не более 8 спрайтов на горизонтальную строку, а общее количество не должно превышать 64 спрайта. Значит ли это, что мы можем отобразить на экране 64 раза Соника или Марио? Нет, имеются в виду «аппаратные спрайты», которые меньше того, что обычно называется спрайтом. Вот пример из Super Mario Bros для NES, где для отображения одного спрайта Марио требуется несколько аппаратных спрайтов размером 8×8 пикселей.

У 16-битных консолей ограничения спрайтов немного снижены. На Mega Drive/Genesis можно отображать до 80 аппаратных спрайтов. Но отдельный аппаратный спрайт может иметь размер до 32×32 (ранее — всего 8×8 пикселей). Вот несколько примеров разрезания «аппаратных спрайтов» на Mega Drive/Genesis. Вы заметили, что Соник отрисовывается всего из двух аппаратных спрайтов, а для Марио на NES требуется 8 спрайтов?

Узкое место №3: приоритеты спрайтов

Как будто это было недостаточно сложно, у Mega Drive/Genesis есть ещё одна специфическая черта: цепочка спрайтов. При наложении двух спрайтов консоль должна узнать, какой из них нужно отображать поверх другого. В Master System и в большинстве консолей Nintendo (NES, Game Boy, SNES) спрайты задавались в большой таблице и их порядок в таблице использовался для задания приоритета отображения. Не нужно говорить, что это довольно сложный в применении инструмент, потому что нужно постоянно переопределять эту большую таблицу для изменения приоритета спрайтов.

На Mega Drive/Genesis компания SEGA использовала более гибкую и простую систему. Как и в других консолях, все спрайты имеют номер индекса в большой таблице, но он не используется для задания приоритета спрайта. Вместо этого каждый спрайт хранит ссылку на следующий спрайт, который будет отображаться. В конечном итоге консоль создаёт цепочку спрайтов, начиная со спрайта 0. Каждый спрайт знает только то, что идёт после него. Благодаря этому гораздо проще изменять приоритеты спрайтов без упорядочивания всех спрайтов в большой «таблице ссылок на спрайты». Но честно говоря, хотя такая система проще в использовании, она всё равно раздражает при создании игры с часто меняющимся приоритетом спрайтов, например в beat’em up.

«Простой» способ: спрайтовый движок SGDK

Отображение подвижных спрайтов и прокручивающихся фонов с учётом всех этих узких мест — довольно сложная задача. С ней боролись все разработчики 90-х, и многие homebrew-разработчики продолжают это делать. Например, Мэтт Филлипс выпустил в 2018 году великолепную игру Tanglewood, но создал её при помощи инструментов 90-х. Он программировал игру на языке ассемблера и использовал официальный аппаратный комплект разработки, спроектированный примерно 30 лет назад. С его стороны это был осознанный выбор, он хотел полностью ощутить на себе методику разработки винтажной игры.

Но для людей не столь опытных и терпеливых, как Мэтт, современные инструменты могут снизить количество проблем, создаваемых техническими аппаратными ограничениями. Мы уже упоминали, что язык C обычно проще, чем ассемблер. Также стоит добавить, что использование высокоточного эмулятора Mega Drive/Genesis наподобие Blast’em в сочетании с Everdrive Flash Cart для тестирования на реальном оборудовании делает разработку игры практически безболезненной по сравнению с разработкой при помощи старых аппаратных эмуляторов в сочетании с набором DOS-инструментов. Но повторюсь, главный подарок современности — это SGDK.

Запишите игру на SD-карту, вставьте её в Mega Everdrive, и тестируйте игру на реальном оборудовании!

Среди прочего, SGDK также имеет мощный «Sprite Engine», сильно облегчающий жизнь разработчику. Это набор функций для обработки отображения спрайтов аналогично тому, как это делается в современных фреймворках. Во-первых, вам больше не нужно волноваться о количестве аппаратных спрайтов, требуемых для каждого кадра анимации: SGDK автоматически займётся этим. Кроме того, при работе с приоритетами спрайтов вам не придётся вручную задавать цепочку спрайтов, потому что SGDK делает это при помощи простого значения «приоритет спрайта», которое можно задавать каждому спрайту, как в любом современном фреймворке. И последнее: SGDK также обрабатывает все передачи во VRAM автоматически! Да, вы всё правильно поняли, благодаря Sprite Engine вам больше вообще не понадобится заботиться о VRAM! Можно просто приказать SGDK отобразить «анимацию X спрайта Y», и он выполнит всю технически сложную работу за вас. Если вам когда-нибудь приходилось работать с этими вещами вручную, то это покажется магией — всё просто и понятно!

Один только Sprite Engine фреймворка SGDK превращает Mega Drive/Genesis в самую простую для разработки игр ретро-консоль, особенно если у вас есть опыт работы с игровыми фреймворками на современных платформах. SGDK бесплатен и имеет открытые исходники, но если вы хотите помочь его автору Стефану Даллонгевилю в дальнейшей разработке ретро-магии, то это можно сделать на Patreon: https://www.patreon.com/SGDK/

Звук на ретро-железе тоже сам по себе является настоящим испытанием, и каждая консоль в этом отношении уникальна. В Mega Drive/Genesis для этой задачи есть отдельный процессор Z80, который напрямую подключен к звуковому оборудованию. То есть для создания звука и музыки для консоли сначала нужно написать «драйвер аудио»: программу для процессора Z80. В 90-х каждая игровая студия разрабатывала собственный драйвер аудио и подстраивала его под каждую игру. Ближе к концу жизни консоли появились стандартизированные драйверы, например GEMS компании Sega of America, использованный примерно в сотне игр западных разработчиков.

Создание хорошего звука для 8/16-битных консолей — это вопрос не только музыкальных, но и программистских навыков! Некоторые игры с хорошей музыкой или звуковыми эффектами были испорчены плохим драйвером аудио. Самым известным примером опять же является Street Fighter II. Драйвер аудио в этой игре страдает от багов, искажающих все голосовые сэмплы. Много лет спустя Стефан Даллонгевиль (автор SGDK и признанный волшебник) выполнил реверс-инжиниринг этого драйвера аудио и исправил его баги. В результате вы теперь можете играть в Street Fighter II с кристально чистым криком «Hadoken!». Вот видео, в котором можно услышать разницу:

Но давайте вернёмся к homebrew-разработке и любимому SGDK. Он имеет возможность выбора драйверов аудио, которые можно подбирать под требования своей игры. Например, есть PCM-драйвер, позволяющий воспроизводить по одному звуковому эффекту за раз в очень высоком качестве (например, голосовые сэмплы). Но также существует XGM-драйвер, способный одновременно проигрывать музыкальный трек + 4 звуковых эффекта. Лучше всего то, что вы можете переключаться между драйверами аудио во время игры. Например, в 30 Years of Nintendon’t голосовые сэмплы на экране заставки и конца игры воспроизводятся PCM-драйвером для высокого качества. Но во время игры мне нужно было воспроизводить одновременно несколько звуковых эффектов, поэтому я использовал XGM-драйвер.

Создать игру для Mega Drive/Genesis за 60 минут? Вызов принят!

Гейм-джемы — превосходный способ применения своих навыков гейм-дизайна и разработки игр: насколько хорошую игру вы сможете создать с нуля за ограниченное время (обычно 48 или 72 часа)?

С точки зрения времени, самым жёстким джемом является 0h Game Jam. Как понятно из названия, он проводится каждый год во время перехода на зимнее время. Вы начинаете создавать игру в 02:00, в ночь перевода часов. Проработав 60 минут, вы выпускаете игру онлайн в тот самый момент, когда часы возвращаются с 03:00 на 02:00. В прошлом году я решил поучаствовать в этом джеме. Только что завершив «30 Years of Nintendon’t», я накопил определённый опыт в создании игры для Mega Drive/Genesis и был вдохновлён простотой SGDK. Но сможет ли SGDK быть достаточно простым, чтобы я смог создать 16-битную homebrew всего за 60 минут? Вот ответ:

Давайте будем честными, результат совершенно не впечатляет. Баланс игры ужасен, а в генераторе случайных чисел есть огромный баг, из-за чего игра становитя непроходимой после пятого яйца. Кроме того, в ней нет фонового изображения, звука и т.д. Но всё-таки это новая игра для Mega Drive/Genesis, созданная с нуля за 60 минут, и запускаемая на настоящей консоли. Не знаю, как для вас, но для меня это уже своего рода достижение!

Более того, поскольку идея базового геймплея имела определённый потенциал, я продолжил работать над игрой в течение ещё множества часов. В результате у меня получилась довольно интересная аркадная игра, в которую можно сыграть здесь. Также она доступна на картридже 30 Years of Nintendon’t вместе с третьей игрой, уникальной для этого выпуска на физическом носителе — MeteoRain.

Много часов дополнительной работы!

От homebrew к indie

Хотя homebrew обычно является нишей для любителей (вроде меня), некоторые консоли и сегодня являются вполне коммерческой платформой для инди-студий. Прекрасным примером этого стали две недавно выпущенные игры. С одной стороны, Tanglewood была полностью разработана на ассемблере, как в 90-х, что сделало конечный результат ещё более впечатляющим. С другой стороны, столь же потрясающая Xeno Crisis была разработана с помощью SGDK и полностью воспользовалась преимуществом комфорта и простоты современных инструментов.

Tanglewood (2018 год)

Xeno Crisis (2019 год)

Итак, если вам нравятся ретро-игры, почему бы не создать сегодня свою первую игру для Mega Drive/Genesis?

В конце концов, чтобы получить SGDK, достаточно перейти по ссылке: https://github.com/Stephane-D/SGDK

В заключение

Надеюсь, вам понравилась эта статья о создании трёх игр для SEGA Mega Drive/Genesis при помощи современных технологий. Если вы хотите сыграть в мои игры на собственной консоли или просто поддержать мою работу, то можете купить картридж в красивой коробке с релизом моих игр у издателя Cote Gamers: http://cotegamers.com/shop/en/genesis-mega-drive/43-test.html

Если вас интересует только цифровой релиз (т.е. ROM-ы), то все мои ретро-игры можно найти здесь: http://drludos.itch.io/

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

Источник