Хранение и вывод иллюстраций для игры
 

Друзья, вопрос по gui. Спасибо за дельные советы, прекрасно получилось организовывать все мелкие графические объекты (иконки, портреты персонажей, предметы и т.п.) в атласы. Все координаты хранятся в XML, выдаются по строковому идентификатору, загрузить саму BitmapData - дело техники. Красота!

Но вот встал вопрос, что делать с фоновыми картинками. В разрабатываемой мною игре (текстовый квест, под AIR) полноразмерные арты - основной и по сути единственный способ демонстрации происходящего игроку. Их будет много. В отличие от иконок, в спрайт-шит/атлас их не запихаешь. Лобовое решение - Embed-ить их всех и не впечатляться, но смущает ряд моментов. Во-первых, это будет лютый трэш и частокол, не то что аккуратный XML-чик. Во-вторых, не понимаю, как это будет с точки зрения расхода ресурсов. В общем, просьба поделиться опытом, как лучше организовывать хранение большого количества фоновых изображений, при условии, что выводятся они по одному в зависимости от контекста. Спасибо.

класть рядом и грузить по мере надобности.

С помощью Filestream или URLLoader? Сорри за тупые вопросы, я тут совсем плаваю. А у отца родного нашего - Мука - по AIR ничего нет :(

стримами обычно грузят потоковые данные(аудио/видео).Для картинок хватит и обычного Loader'а

Если не хочется при установке игры выкладывать все изображения в папку игры "как есть", можно попробовать упаковать их в архивы по, например, локациям или уровням, если есть в игре какая-то линейность и можно предполагать, что вот сейчас и в течении какого-то игрового времени понадобятся только вот такие слайды. Затем по мере надобности можно брать нужный архив и распаковывать его во временную директорию (в AIR есть такая возможность, File.createTempDirectory()), чтобы не занимать оперативку, и оттуда уже таскать нужные слайды.
Более сложный вариант — читать изображения в оперативку файлстримом из какого-то общего файла-хранилища-всех-изображений, но для этого надо будет знать position первого байта и длину файла для каждого слайда, и хранить их либо в отдельной описи, либо в этом же файле. Тут уже нужен некоторый опыт ковыряния в файлах и инструмент для сборки этого самого файла. Зато "на выходе" будет какой-то непонятный файл, который никто не сможет запросто посмотреть или отредактировать по своему хотению.

Так а что за игра то? Под плеер или под AIR?
Если под эйр то под какой, десктоп или мобильный?

да, и не забудь указать Wolsh-а в команде разработчиков)))

Спасибо, запомнил. Думаю, это пока излишне. На данный момент цель - сделать рабочий вариант вывода нужной картинки в нужный момент. Все эти фокусы можно оставить на потом ближе к релизу. К тому моменту и структура базы изображений будет более понятна. А если совсем честно, почему-то меня совсем не прут все эти внутрипрограммные утилиты. Движок делать, всю логику планировать, взаимодействие классов, визуальные компоненты и их работу - дико нравится и интересно. А все эти файл-, XML-, asset- и прочие менеджеры - нет. Просто хочется, чтоб работало и не отвлекало от содержательной работы :)

Ещё общий краткий вопрос, пока писать не начал. Я правильно понимаю, что когда изображение уже больше не нужно, достаточно его просто убрать из DOC, отменить все висящие на нём слушатели событий и записать null в переменную, в которой оно хранилось? Или ещё что-то, чтобы нормально уходило и не занимало ресурсы?

Всё та же, под десктоп на эйр. Личный проект в жанре RPG с механикой текстового квеста.

Я вас всех в команде разработчиков укажу, или как минимум в списке тех, кому благодарен и без кого ничего бы не вышло. :drinks: Главное, чтобы было где указывать. До релиза пока как до Китая :) Но прогресс идёт, а главное, доставляет удовольствие.

BitmapData#dispose().
"убрать из DOC" ты можешь только Битмап, а он весит около килобайта. Мегабайты весит БитмапДата; указанный метод очищает память от нее.

Тогда создай в проекте в папке bin папку под картинки и загружай просто при старте игры обычным Loader'ом. Если в бин будет лежать папка images, то из программы путь к ней будет такой: