Маленькие секреты большой экономии

Поделиться



Почему 16 байт достаточно для сохранения игры, и другие мелочи
Пятьдесят и сто лет спустя у программистов будут всё те же проблемы: им будет очень сильно не хватать объёма доступной памяти для реализации всего, что хочется.

25 лет назад игровые картриджи содержали 64—128 килобайтов памяти, но каким-то образом этого объёма хватало, чтобы уместить игру на десятки часов геймплея. Сегодня 128 килобайт — это размер маленькой JPEG-картинки, а о том, что доступно в современном бытовом компьютере, в эпоху Super Mario Bros. даже не приходилось мечтать.

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

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

Другая маленькая деталь: многое программное обеспечение нужно писать так, чтобы его мог править и исправлять другой программист после тебя. Разработчикам игр под Atari 2600, Sega Master System, NES и SNES и даже под более поздние консоли конца 90-х типа PlayStation 1 или Nintendo 64, беспокоиться было не о чем: зачем кому-то за пределами команды знать, как работает продукт? После выпуска ничего уже не исправить, патч на картридж не накатишь. Наоборот, было предпочтительнее избегать всяких хакеров, выпускавших чит-системы, например, Game Genie. Игры имели почти полный контроль над консолью безо всяких операционных систем, поэтому не требовалось многослойной архитектуры, которую запихивают во все современные продукты для улучшения независимости от программных и аппаратных средств.

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




Читать дальше →