Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 22
Основной секрет: игры писались на ассемблере, то есть приходилось почти напрямую говорить микросхемам, какие операции нужно производить.
Это утверждение вводит читателя в заблуждение. Ассемблер является языком программирования, который оперирует инструкциями процессора, а вовсе не логическим состоянием микросхем напрямую. Да, писать на ассемблере сложней, так как возможность построить собачью конуру из бетонных блоков весьма ограничена (правда современные уютные библиотечки таки решают проблему и предоставляют бетонные блоки для желающих), потому приходится ковырять зубилом и молотком.
Elite для ZX Spectrum помещалась в 48 килобайт. А там было, страшно подумать, семь галатик с сотней обитаемых звёзд, с разными названиями, торговой информацией и т.д. Видимо, был какой-то постоянный генератор для всего этого добра, потому что карта оставалась постоянной всегда :)
Все эти галактики создавались генератором псевдослучайных чисел — для одного сида последовательность была постоянной.
Восемь галактик. Генератор был на основе последовательности Фибоначчи.
48 это с видеопамятью и с «системой». От бейсика совсем уйти было сложно. Как минимум загрузчик был на бейсике, так что на него оставляли часть памяти. Часть им использовалась как служебная… Сейчас уже точно не вспомню, но вроде какая-то память использовалась для подпрограмм из ПЗУ. Если их затереть, то мы теряли работу с некоторыми стандартными библиотеками… В общем не припомню я, чтобы на программу можно было выделить больше 40кб (не считая конечно вариантов с диском, вариантов 128к и вариантов когда новые уровни подгружались с кассеты отдельно.)
На самом деле псевдослучайно генерируемых галактик было больше, если поменять константу в сейвке игры, то генерировались уже новые 8 галактик.
Сами демки там маленькие, а генерация текстур и звука производится на лету, но оно опирается на возможности директикса (который сам по себе — тонны кода) и вообще то не очень щадяще использует ресурсы. Хотя надо отдать должное — они выжимают из железа почти все на что оно способно, в отличие от не оптимально пишущихся современных тяжелых игр.
помню как сохранялся на кассету, затем мял магнитофонную пленку, загружал это «сохранение» и получал кучу бабок и оружия… эхх, детство
Окей. Раз уж программировал на Java ME — так Java ME. Когда я программировал, была там такая Nokia Series 40 с 64 килобайтами архива и 210 килобайтами памяти — не очень крута для игр, но достаточно дорога, безглючна и живёт с аккумулятора неделю. Там есть два направления экономии: экономия памяти и экономия архива.
1. Массивы, везде массивы. Отдельный класс отводил только на объекты, которых немного.
2. Мало классов, в которых большей частью static. Было много классов-утилит, состоящих из одного static’а (Dev=Device, G=Game, D=Data, Load=загрузка данных, Skin=внешний вид, Snd=sound…) — специальный препроцессор добавлял их к какому-то классу.
3. Банальная обфускация.
4. Инициализация массивов занимала много, все предвычисленные таблицы крупнее двух десятков элементов грузили из файлов.
5. Не моя уловка, а телефонная — но даже цифровые звуки кодировались очень эффективно, с качеством в 8 или 12 кб/с, тем же кодеком AMR, что используется в разговорах. Другие звуки — это несколько нот MIDI, около сотни байт.
6. Файлы данных объединялись в файлы покрупнее, чтобы сжать их эффективнее.
7. Минималистичные меню, которые всячески (зачастую без меры) украшали на телефонах, на которых памяти уже хватало.
8. Персонажи составлялись из маленьких кусочков специальной программой (написанной тоже мной). Координаты объектов на картинке можно было экспортировать в byte, можно в word — в зависимости от того, «малый» или «крупный» экран.
1. Массивы, везде массивы. Отдельный класс отводил только на объекты, которых немного.
2. Мало классов, в которых большей частью static. Было много классов-утилит, состоящих из одного static’а (Dev=Device, G=Game, D=Data, Load=загрузка данных, Skin=внешний вид, Snd=sound…) — специальный препроцессор добавлял их к какому-то классу.
3. Банальная обфускация.
4. Инициализация массивов занимала много, все предвычисленные таблицы крупнее двух десятков элементов грузили из файлов.
5. Не моя уловка, а телефонная — но даже цифровые звуки кодировались очень эффективно, с качеством в 8 или 12 кб/с, тем же кодеком AMR, что используется в разговорах. Другие звуки — это несколько нот MIDI, около сотни байт.
6. Файлы данных объединялись в файлы покрупнее, чтобы сжать их эффективнее.
7. Минималистичные меню, которые всячески (зачастую без меры) украшали на телефонах, на которых памяти уже хватало.
8. Персонажи составлялись из маленьких кусочков специальной программой (написанной тоже мной). Координаты объектов на картинке можно было экспортировать в byte, можно в word — в зависимости от того, «малый» или «крупный» экран.
Мне кажется, именно вследствие ограниченности ресурсов, старые игры имели тот шарм, который так редко встречается в играх новых. Тогда перед программистами постоянно стоял challenge. И все остальные разработчики игры впитывали этот дух и не отставали в своей работе.
Сейчас же, когда зачастую все инструментарии имеются и документированы, в основном нужны количественные решения — здесь 500 строк кода, там 150… Также работают дизайнеры и другие участники создания игры. Это ведёт к рутине и, в конце-концов, к халтуре.
Сейчас же, когда зачастую все инструментарии имеются и документированы, в основном нужны количественные решения — здесь 500 строк кода, там 150… Также работают дизайнеры и другие участники создания игры. Это ведёт к рутине и, в конце-концов, к халтуре.
Еще можно вспомнить River Raid, где уровни тоже генерировались на основе псевдослучайных последовательностей.
Насчет «генерации музыки на лету» — эта фраза несколько вводит в заблуждение, возникает впечатление, что на лету генерируются ноты. Нет, ноты хранятся в памяти. Но в компактной форме. На лету (в реальном времени) идет только синтез звука.
В некоторых играх использовалась генерация лабиринтов. Это не только позволяло иметь большие и сложные уровни, но добавляло в игру элемент случайности, когда уровни каждый раз разные, и игроку необходимо их исследовать заново.
Насчет «генерации музыки на лету» — эта фраза несколько вводит в заблуждение, возникает впечатление, что на лету генерируются ноты. Нет, ноты хранятся в памяти. Но в компактной форме. На лету (в реальном времени) идет только синтез звука.
В некоторых играх использовалась генерация лабиринтов. Это не только позволяло иметь большие и сложные уровни, но добавляло в игру элемент случайности, когда уровни каждый раз разные, и игроку необходимо их исследовать заново.
> Насчет «генерации музыки на лету» — эта фраза несколько вводит в заблуждение, возникает впечатление, что на лету генерируются ноты. Нет, ноты хранятся в памяти. Но в компактной форме. На лету (в реальном времени) идет только синтез звука.
Бывает и полностью на лету, без хранения нот (правда не знаю насколько широко она исполльзовалась на практике). Типа countercomplex.blogspot.ru/2011/10/algorithmic-symphonies-from-one-line-of.html
Бывает и полностью на лету, без хранения нот (правда не знаю насколько широко она исполльзовалась на практике). Типа countercomplex.blogspot.ru/2011/10/algorithmic-symphonies-from-one-line-of.html
не знаю насколько широко она исполльзовалась на практике
Насколько мне известно, мелодии так не генерировались никогда. Может быть, разве что, спецэффекты. Были программы для алгоритмической композиции, типа Algomusic на Амиге, но это было уже в 90х, и не на 8-битках, и как отдельное приложение, а не компонент игры.
Креш бандикут на первой плейстейшн — непревзойденный шедевр. До сих пор его скриншоты выглядят на уровне. А тогда просто дух захватывало.
Причин «ожирения» современного софта несколько.
Фреймворки. На вопрос «как уменьшить мою программу минимум в 10 раз» есть универсальный ответ — «выкинь фреймворки». Работает всегда, даже в древние времена Delphi отказ от VCL позволял снизить размер результирующего модуля с 300Кб до 30.
Сейчас же во всех областях софтостроения наблюдается просто засилие фреймворков. Вполне обычной стала ситуация, когда простой фонарик под Android весит за 20Мб и требует полный набор разрешений, а статическая вроде бы Web-страничка, где нет ничего кроме текста, заставляет ваш смартфон раскаляться в руках.
Особенно интересно тут то, что фреймворки — это такая большая уравниловка. Они упрощают работу для новичков, но существенно затрудняют для опытных кодеров, которые для реализации чего-то нестандартного зачастую вынуждены как-то обходить фреймворки, городя тонны костылей.
Кроссплатформенность. Задача создания кода, который бы запускался абсолютно везде, на корню убивает искусство программирования. Всё, что нам остаётся — следовать стандартам, создавая унылый, скучный код. И, опять же, уже даже речи не идёт о том, чтоб выжать из железа максимум. Зато приходится наворачивать тонны абстракций, опять же не идущих на пользу производительности. Думаю, многие программисты мечтают о том, чтобы появилось одно-единственное унифицированное устройство… или хотя бы облачные технологии развились настолько, чтоб игру можно было написать только для сервера, а клиентам всего лишь передавалась бы картинка и звук.
Защита от дурака. Все эти бесконечные песочницы и разграничения доступа, с помощью которых пытаются бороться с вирусами и троянами. В итоге троянам плевать — как были, так и есть — а вот нормальным программам достаётся куда меньше контроля над системой, т.ч. зачастую игра даже не в состоянии обеспечить предсказуемое время отклика или гарантировать, что в критический момент не начнёт вдруг отжирать мощности какой-то левый процесс.
Кризис перепроизводства. Когда ежедневно выходит больше игр, чем человек может хотя бы просмотреть — качество неизбежно будет ниже плинтуса. Потому что в таких условиях игра всего лишь должна быть не ниже среднего уровня, а все «лишние» средства и ресурсы предпочтительнее вложить в маркетинг. Шедевр, не потративший ни копейки на раскрутку, провалится со 100% гарантией, т.к. его просто не найдут в груде мусора.
Ну а когда вложения в рекламу дают бОльший выхоп, чем вложения в код, графику, идею и т.д., результат вполне очевиден. Сложно сказать, можно ли что-то с этим сделать — нужен какой-то способ ранжирования игр по их «крутости», а без продвинутого ИИ это малореально.
Фреймворки. На вопрос «как уменьшить мою программу минимум в 10 раз» есть универсальный ответ — «выкинь фреймворки». Работает всегда, даже в древние времена Delphi отказ от VCL позволял снизить размер результирующего модуля с 300Кб до 30.
Сейчас же во всех областях софтостроения наблюдается просто засилие фреймворков. Вполне обычной стала ситуация, когда простой фонарик под Android весит за 20Мб и требует полный набор разрешений, а статическая вроде бы Web-страничка, где нет ничего кроме текста, заставляет ваш смартфон раскаляться в руках.
Особенно интересно тут то, что фреймворки — это такая большая уравниловка. Они упрощают работу для новичков, но существенно затрудняют для опытных кодеров, которые для реализации чего-то нестандартного зачастую вынуждены как-то обходить фреймворки, городя тонны костылей.
Кроссплатформенность. Задача создания кода, который бы запускался абсолютно везде, на корню убивает искусство программирования. Всё, что нам остаётся — следовать стандартам, создавая унылый, скучный код. И, опять же, уже даже речи не идёт о том, чтоб выжать из железа максимум. Зато приходится наворачивать тонны абстракций, опять же не идущих на пользу производительности. Думаю, многие программисты мечтают о том, чтобы появилось одно-единственное унифицированное устройство… или хотя бы облачные технологии развились настолько, чтоб игру можно было написать только для сервера, а клиентам всего лишь передавалась бы картинка и звук.
Защита от дурака. Все эти бесконечные песочницы и разграничения доступа, с помощью которых пытаются бороться с вирусами и троянами. В итоге троянам плевать — как были, так и есть — а вот нормальным программам достаётся куда меньше контроля над системой, т.ч. зачастую игра даже не в состоянии обеспечить предсказуемое время отклика или гарантировать, что в критический момент не начнёт вдруг отжирать мощности какой-то левый процесс.
Кризис перепроизводства. Когда ежедневно выходит больше игр, чем человек может хотя бы просмотреть — качество неизбежно будет ниже плинтуса. Потому что в таких условиях игра всего лишь должна быть не ниже среднего уровня, а все «лишние» средства и ресурсы предпочтительнее вложить в маркетинг. Шедевр, не потративший ни копейки на раскрутку, провалится со 100% гарантией, т.к. его просто не найдут в груде мусора.
Ну а когда вложения в рекламу дают бОльший выхоп, чем вложения в код, графику, идею и т.д., результат вполне очевиден. Сложно сказать, можно ли что-то с этим сделать — нужен какой-то способ ранжирования игр по их «крутости», а без продвинутого ИИ это малореально.
> Фреймворки
Ну в нормальных окружениях это разделяемые библиотеки которые ставятся в систему единожды и используются всем софтом, поэтому как раз размер каждого конкретного приложения сокращается, а не растёт на размер фреймворка.
> Кроссплатформенность. Задача создания кода, который бы запускался абсолютно везде, на корню убивает искусство программирования. Всё, что нам остаётся — следовать стандартам, создавая унылый, скучный код.
Искусство программирования — в алгоритмах и архитуктуре, никто его не убивает. Да и для кросс-платформенного низкоуровнего программирования инструментов предостаточно.
А вот не-кроссплатформенный код, насколько бы изящно и изобретательно он не использовал недокументированные возможности для «выжимания всего из железа» — на деле мёртвый мусор: через N лет железо сменится и он перестанет работать как задумано, ещё через K железа вообще не останется, а запустить этот код получится даже не на каждом эмуляторе (например, игры, использующие свойства ЭЛТ дисплеев чтобы получить больше цветов чем позволяла система).
> Защита от дурака. Все эти бесконечные песочницы и разграничения доступа
Это вообще мимо, ибо этим занимается система.
> Кризис перепроизводства
Не понятно как это связано с ожирением софта.
Ну в нормальных окружениях это разделяемые библиотеки которые ставятся в систему единожды и используются всем софтом, поэтому как раз размер каждого конкретного приложения сокращается, а не растёт на размер фреймворка.
> Кроссплатформенность. Задача создания кода, который бы запускался абсолютно везде, на корню убивает искусство программирования. Всё, что нам остаётся — следовать стандартам, создавая унылый, скучный код.
Искусство программирования — в алгоритмах и архитуктуре, никто его не убивает. Да и для кросс-платформенного низкоуровнего программирования инструментов предостаточно.
А вот не-кроссплатформенный код, насколько бы изящно и изобретательно он не использовал недокументированные возможности для «выжимания всего из железа» — на деле мёртвый мусор: через N лет железо сменится и он перестанет работать как задумано, ещё через K железа вообще не останется, а запустить этот код получится даже не на каждом эмуляторе (например, игры, использующие свойства ЭЛТ дисплеев чтобы получить больше цветов чем позволяла система).
> Защита от дурака. Все эти бесконечные песочницы и разграничения доступа
Это вообще мимо, ибо этим занимается система.
> Кризис перепроизводства
Не понятно как это связано с ожирением софта.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Маленькие секреты большой экономии