Эволюция программистов

От сюда:


Уже не знаю в который раз сталкиваюсь с одним и тем же путем эволюции:
  1. Мы грузим уровень и загружаем все текстуры для него. Когда загружается второй уровень, недостающие текстуры также подгружаются в память (вопрос: если мы "за раз" пройдем всю игру, то в памяти будут собраны абсолютно все текстуры дистрибутива? ответ: хм, видимо, да)
  2. Мы грузим уровень и загружаем все текстуры для него. Когда загружается второй уровень, недостающие текстуры подгружаются в память, ненужные текстуры выгружаются (вопрос: то, что текстуры второго уровня грузятся в верхнюю память - не страшно? ответ: ну типа мы думаем, что там все красиво уйдет в свап).
  3. Мы заранее анализируем память, выгружаем ненужные текстуры, потом грузим следующий уровень (уже лучше).
  4. Мы собираем общие текстуры, которые используются во всех уровнях, в предварительный пак, который не трогается. Остальное грузится с уровнем, в двух наконец-то уже вполне приемлимых вариантах:
  5. Полная выгрузка уровня и загрузка нового, с перезагрузкой всех текстур, даже если там что-то встретится одинаковое
  6. Предварительный анализ и сохранение текстур предыдущего уровня, которые используются (с учетом того, что предварительный пак лежит в памяти).

Средний путь эволюции - порядка 4-6 лет.


Тема эволюции мне самому понравилась настолько, что я решил продолжить провокационные посты :)

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

  1. fopen("data\\level1.map"), fread()....
  2. Взять через _pgmptr или GetModuleHandle() каталог запуска exe, подготовить полный путь вместе с "data\\level1.map".
fopen(), fread()....
  1. CreateFile( .... FILE_FLAG_OVERLAPPED) // Появляется асинхронная загрузка, путь вычисляется глобально или локально (т.е. растет из пункта 1 или 2)
  2. 4. MASTER_CANDIDATE
OpenFileFromPack(...);

CreateFile(...)
  1. 5. file::Manager::LoadFileASync("pack:\\data\\level1.map"); // Где pack может быть замаплен на "живую" структуру файлов и папок, как вариант - задавать пути до pack:\ или exe:\ во внешнем файле, чтобы отлаживаться, не завязываясь на MASTER_CANDIDATE
P.S. Вариант 1 неприемлем даже для скромных казуалок.

P.P.S. Прошу не устраивать ругань в ЖЖ по поводу размеров ресурсов и возможности загрузки через блокирующее чтение. Хотя если у вас есть load on demand, то асинхронность должна быть по-любому.


  1. posPlayer += 5.0*deltat;
  2. const float SPEED = 5.0f;
posPlayer += SPEED*deltat;
  1. Сохранить SPEED в ini файле (или например в таблице LUA), считывать его при старте программы.
  2. См. пункт 3, но кроме того, править переменную можно из игровой консоли методом set SPEED 5.1
  3. Игра обзаводится GUI окном, в котором можно править настройки, причем они динамически применяются в игре и сохраняются обратно в ini-файл.
  4. Игра обзаводится полноценным редактором, в котором можно править эти настройки (ну и делать еще многое другое)
  5. Редактор становится отдельным приложением и общается с запущенной на PC/XBOX/... игрой по TCP/IP.
Гдето между пунктами 3 и 6 настройки начинают жить в файле под Source Control. До этого они живут на общем сервере или например в SQL базе, соответственно, локальная модификация параметров оказывается невозможной.Все оно очевидно стремится к:
  • методу WYSIWYP (what you see is what you play)
  • возможности интерактивно менять настройки, не прерываяя (это важно!) игрового процесса.

Очень много известных мне команд остановились пока что на уровне 3. Несколько команд дошли до уровня 6. Еще несколько разработчиков уже перешло из уровня 6 к 7. Ну и еще полторы команды находятся на уровне 8.


Ну и на закуску.

А вы на какой стадии эволюции в личном кодописательстве находитесь?

Последняя правка: пн, 29/08/2011 - 22:03
Submitted by Victor on

Комментарии

Про ресурсы. Мне больше нравиться подход с offline preprocess'ом, когда всё пакуется в platform-specific бинарники для быстрой загрузки (с минимальными преобразованиями во время этой самой загрузки); обычно есть "shared" паки и level-specific паки. Процесс паковки делает либо одна мегатулза с пачкой плугинов (в "своём" коде), либо пачка мелких специализированых тулзов (в "рабочем" коде). Во времена PowerTV очень хорошо пошёл вариант похожий на п.4. -- по умолчанию файло грузилось из ZIP'а, если не находилось в архивах то просто файл с диска (на самом деле из сетки, не суть) брался. Можно было быстро править ресурсы и смотреть результаты, а в релизе всё компактно и шустро (любая файловая операция крайне дорогой была). Про переменные/параметры. Обычно просто в конфиге; то что нужно интенсивно править, складыватся в структурки с псевдо-рефлекшн'ом, это мона читать/писать в конфиги и редактировать визуально (типо дерево переменных) на ходу.
Submitted by BLK Dragon on
Всё гениальное просто ), всё выгружаем и загружаем по новой, часто загружаемые ресурсы хранить в памяти, если есть свободная )Ресурсы в зип проблемы с дубликатами, но решаемые

Консоль да должна быть динамичная, но не все параметры можно менять динамически )

Submitted by Relyer on
всё выгружаем и загружаем по новой вот этого тебе пользователи не простят :) хотя бы проверять, действительно ли нужно выгружать/загружать
Submitted by BLK Dragon on

Ну почемуже, зато нету фрагментации памяти Smile и + чемто ж надо РАМ забивать Biggrin

Submitted by Relyer on
фрагментации можно и менее экстремальными методами избегать. Меня всегда удивляет как небрежно народ на пц память расходует, гигабайт туда, гибабайт сюда... :)
Submitted by BLK Dragon on
На то он и пц, на то она и память :)

Поправьте если ошибаюсь, но память на данный момент самый дешевый ресурс в пц.

Submitted by Victor on
Памяти всё равно ограниченное количество. Проблема даже не в самой памяти, а в ограниченном количестве _адресного_пространства_. Например есть тулза -- для паковки ресурсов -- которая берёт гигабайт памяти. В смысле она на старте делает reserve на гигабайт (и вполне может эту всю память в процессе работы заюзать). Так вот какой-нить макс одновременно уже не запустишь -- памяти не хватит. Игры современные (особенно пост-совкого изготовления) легко и свободно жрут около гига. Память то может и дешёвая, но больше 4 гиг просто так не воткнёш :) Я к чему -- Doom3 например грузил свой уровень весьма неторопливо, что-то около несколько минут на P4-1.7/1Gb/GF6600; для меня это дикость -- просто ждать несколько минут пока соизволит загрузицца уровень; за это время можно успеть включить PSP, запустить GripShift, проехать трассу, сохраниться и выключить PSP :)
Submitted by BLK Dragon on

>> Я к чему — Doom3 например грузил свой уровень весьма неторопливо, что–то около несколько минут на P4–1.7/1Gb/GF6600

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

Submitted by Victor on

Я тут думал-думал и решил начинать с уровня 16.

Submitted by S.I.M. on

GameDev.by