Статья о непрерывной подгрузке уровней на примере игры Dungeon Siege. Кроме самой статьи есть также слайды.
Вообще идея подгружать уровни непрерывно, не показывать игроку картинки с заставками и тем самым не прерывать геймплей очень интересна. Сейчас я это реализую в Winding Trail, но у нас все значительно проще, сама игра значительно меньше. В статье о Dungeon Siege рассказывается об организации непрерывной подгрузки, которую они делают отдельным потоком, что породило огромное количество странных багов, которые они потом ловили. Кроме этого говорится и о других проблемах, о которых при организации такого вот непрерывного мира сразу и не подумаешь. Например, у них начали переполняться float'ы при подсчете расстояний. Кроме всего прочего у них игра поддерживает многопользовательский режим, что еще добавило сложности. В итоге у них получился Игровой Мир с неевклидовой геометрией и одному из дизайнеров удалось создать в буквальном смысле слова бесконечную пустыню.
Статья очень хорошая, там не просто говорится "мы сделали так-то и так-то", а рассказывается почему они пришли именно к таким решениям, и какие претензии к этим решениям у них остались.
Там же они рекомендуют слайды на ту же тему: Stuart Denman. Highly Detailed Continuous Worlds: Streaming Game Resources from Slow Media. (PPT)
воскресенье, ноября 20, 2005
Непрерывная подгрузка уровней
Подписаться на:
Комментарии к сообщению (Atom)
Atom feed
2 коммент.:
> Сейчас я это реализую в Winding Trail, но у нас все значительно проще, сама игра значительно меньше.
Не столько "меньше", сколько "проще" в плане детализации. Все же там ландшафтные перемещения у нас - лиш част геймплея. Срртветсвенно и требования к ним попроще. По, собственно, площади поверхности - я так прикинул, на перемещение по прямой из края в край, без учета рельефа, сражений и квестов. Просто на тупое пересечение по прямой понадобится от 15 до 20 реальных минут. Это много. С учетом "приключений" и объездов, полагаю, около часа. По прямой. А прямых путей там не будет. Площадь в условных 1024 условных зон даст весьма внушительное "время пути".
Да ничё вроде особо сложного, обычные две очереди в двух потоках, в дополнительном грузится с диска в RAM, в основном выталкивается из RAM в видеокарту (вроде быстро).
Против переполнения float'ов нужно делать, похоже, обновление координат всех объектов в scene tree, через определённые промежутки времени.
Отправить комментарий