?

Log in

No account? Create an account
29 сент, 2008 @ 15:26 Сохранения в играх
Подскажите, есть ли статьи, где бы рассказывалось об основных приемах создания сохранений в сложных играх?
в мечтах о дальних странах
borimir:
[User Picture Icon]
From:ufonaut
Date:Сентябрь, 29, 2008 17:01 (UTC)
(Ссылка)
Для начала -ищи инфу по сериализации (serialization) данных
(Ответить) (Ветвь дискуссии)
[User Picture Icon]
From:borimir
Date:Сентябрь, 29, 2008 18:07 (UTC)
(Ссылка)
Я владею технологией сериализации. Меня интересует структурное устройство подсистемы сохранения в сложных играх, где одной простой сериализации игрового мира в файл, не обойтись.
(Ответить) (Уровень выше) (Ветвь дискуссии)
[User Picture Icon]
From:aka_rider
Date:Сентябрь, 29, 2008 19:45 (UTC)
(Ссылка)
Все статьи, которые я встречал касательно сохранений в играх, сводятся к сериализации. Часто эта тема всплывала в серии Game Programming Gems.
Меня интересует структурное устройство подсистемы...
Функционал сохранения - неотъемлемая часть движка, поэтому если и есть статьи на эту тему - это будет что-то вроде части цикла "Движок игры своими руками".
Мне кажется - лучше всего исходники какой-то игры посмотреть.

P.S. Я владею технологией сериализации
Мне немного не по себе от этой фразы :)
(Ответить) (Уровень выше) (Ветвь дискуссии)
[User Picture Icon]
From:aka_rider
Date:Сентябрь, 29, 2008 19:47 (UTC)
(Ссылка)
Да, кстати.
Это не вопрос, это скорее проблема - панацеи не будет.
(Ответить) (Уровень выше) (Ветвь дискуссии)
[User Picture Icon]
From:ufonaut
Date:Сентябрь, 29, 2008 20:59 (UTC)
(Ссылка)
Ну а какое там устройство?..
Есть у тебя сценграф - сценграф и сериализуй - пиши "свойства" (мемберы объектов классов, обёрнутые какими-никакими метаданными), заменяй указатели на какие-ниубдь кошерные id, и лей в файл.
Со скриптами - там можно либо делать "hibernate" - считай, полный дамп виртуальной машины (для простых случаев покатит, lua pluto? если мне не изменяет память), либо, писать какую-то очередную обкрутку для (полу)автоматической сериализации - на прошлой работе было именно так (Lua с самопальным биндингом, расширенная API сериализации.)

Дальше - дебаг-дебаг-дебаг.

Если интересует политика обращения с файлами сохранений и пр. - на консолях это регламентируется весьма жёстко, на PC - свободнее, хотя Vista требует осторожного обращения (запись в папку приложения может быть запрещена и пр.).
(Ответить) (Уровень выше) (Ветвь дискуссии)
[User Picture Icon]
From:slatazan
Date:Сентябрь, 29, 2008 19:45 (UTC)
(Ссылка)
// я не в теме, но кой-какой опыт был
Рекомендую делать сложную игру, опираясь на зубо-дробительную простоту.
Если игровая фигура (Entity) изначально выглядит как цепочка байтов постоянной длины,
то не надо сериализовать-десериализовать - два места уже не будут вносить баги.
Так-что пишем в файл и считываем из файла ВСЕ игровые фигуры "как есть".
Осталось только "нормализовать игровые акции фигур" перед записью в файл.
И поставить загрузку фигур из файлов ровно на том месте, где они сохранились ...
Особое место в цикле.
Тоесть, сам вопрос нужно сместить в сторону "правильной линковки" между игровыми
фигурами ... Вобщем, надеюсь, что я правильно мыслю и вектор мысли понятен.
(Ответить) (Ветвь дискуссии)
[User Picture Icon]
From:unxp
Date:Сентябрь, 29, 2008 20:55 (UTC)
(Ссылка)
А как тогда будешь поддерживать совместимость сейвов в новых версиях?
(Ответить) (Уровень выше) (Ветвь дискуссии)
[User Picture Icon]
From:slatazan
Date:Сентябрь, 30, 2008 19:05 (UTC)
(Ссылка)
Допустим что вопрос был по поводу "лента байтов изменится и что делать?"
Значит патч будет содержать новый EXE, где будет и "старо-новая" проца загрузки игровых
фигур с переделыванием в "новую длину".
Основная проблема для Боримира - продумать "как сделать линковку игровых фигур", чтобы
их можно было "морозить" в любом кадре игры и возврашьать к норм-жизни без намека на баги.
(Ответить) (Уровень выше) (Ветвь дискуссии)
[User Picture Icon]
From:unxp
Date:Сентябрь, 30, 2008 23:04 (UTC)
(Ссылка)
Т.е с каждой новой версией надо будет еще писать конвертор сейвов и учитывать в нем все изменения в Entity? И жестко следить чтобы нигде никакой объект не изменился? Хммммм... На мой взгляд, это прямой путь к разнообразным скрытым граблям.

Хорошая система сериализации надежнее и более future proof.
(Ответить) (Уровень выше) (Ветвь дискуссии)
[User Picture Icon]
From:slatazan
Date:Октябрь, 1, 2008 22:29 (UTC)
(Ссылка)
//
Я говорил про сложную игру, в которой опытные разработчики не собираются
делать по патчу в месяц и перестраивать всю логику с ног-на-голову.
Если тебе симпатична идея про "ленту байтов", но ты боишся рисковать с ней,
то рекомендую просто не жадничать и побольше свойств в Entity напихать +
200 байт пустышек "на всякий случай". В этом случае вообше не надо конвертеров.

Еше раз проясню - самое сложное это ..
Создать гибкую систему связей, чтобы никогда не было "зацепок за мертвые фигуры"
и "никогда не пропадали Временные цели" (в кого юнит стреляет, за кем должен следовать).
Частично это решается "административными класами", которые не являются Entity и
не участвуют в сохранках, но чудом "на один кадр" линкуют всех кого надо ...

// примерно так может быть
Main_Loop
{
an1() //нечто с приемом Сигналов (возможно и сетевых) //управление
an2(); // Реализовать не обязательный админ-список "кого обнулить"
an3(); // через все энтити - поиск "сломаных" и обнуление их статуса (память под entity всегда остается)
an4(); // накрут через все - обнулить линки на фигуры, чей статус Ноль.
an_trySave(); // место вывода фигур из круга в постояную память
an_UpLoad(); // место заливки значений из постояной памяти в энтити //включая стриминг
an_crt(); // генерация неких игровых фигур аля спаунеры или копиры
an_Up(); // Обнова - как минимум два накрута через все активные и живые фигуры
an_Draw(); // Организовано накачиваем "рисовальную машину" по теме "как кого рисовать".
an_Finish(); // финиш кадра //некая статистика + рутина скриншотов
}
(Ответить) (Уровень выше) (Ветвь дискуссии)
[User Picture Icon]
From:unxp
Date:Октябрь, 2, 2008 00:24 (UTC)
(Ссылка)
> Я говорил про сложную игру, в которой опытные разработчики

Ну ты понимаешь ведь что даже ветераны могут допускать ошибки? Ну и команды состоят не из одних ветеранов.
Твой метод открывает простор для багов которые могут выявиться не сразу и найти их будет довольно сложно.
Сегодня баг может быть внесен в код, но игра начнет падать только через месяц...

>не собираются делать по патчу в месяц и перестраивать всю логику с ног-на-голову.

А на время разработки (с ежедневными билдами и всем прочим) о сохранении просто забыть? Возможно, если ига сравнительно простая это допустимо. А если большая и сложная - тестеры ведь завопят! =)

>просто не жадничать и побольше свойств в Entity напихать
>+ 200 байт пустышек "на всякий случай".


Это не поможет если, например, случайно оффсет или размер одного мембера изменится. Это очень легко и незаметно может произойти если объект от чего-то наследуется.

> Еше раз проясню - самое сложное это Создать гибкую систему связей

Можно подробнее про систему связей?
(Ответить) (Уровень выше) (Ветвь дискуссии)
[User Picture Icon]
From:slatazan
Date:Октябрь, 2, 2008 19:14 (UTC)
(Ссылка)
Если есть возможность, то откажись от "наследований" :)

Вобшем мне нравится модель построения из Максимально простых свойств.
class myEntity
{
int zero;
int status;
int active;
int здоровье_пехотного_юнита;
int здоровье_пехотного_юнита_добавка;
int здоровье_танк_юнита;
// еше 300 подобных свойств
int last;

flo zerof;
flo posX; // void TryMoveUnit( flo* LENTA ); // TryMoveUnit( &( pUnit->posX) );
flo posY;
// ...
flo lastf;
};
// Главное не позволять "переставлять имена свойств ради красоты".
// Для этого можно и парсером проверять время-от-времени.

// ---
По поводу линков - я их сам пока не придумал по-новому, но ранее кое-как получались.

Ниже отрывки моих записей "для себя" ..

// -- Норм-целевые линки
// Здесь главным является "учет лог-номеров" по "Сушьностям постояной памяти".
// Тоесть, среди "всех всех" Фигур проекта в "рабочей области хард-диска".
// В програме есть переменка, которая "только вперед" выдает новые лог-номера.
// Получится, что у каждой молекулы есть 32 бита под лог-номер ...

// Эти целевые линки не имеют "обратной линковки от жертвы к Звонителю".
// ююю
// где собраны пары "лог-номер-жертвы" + "тек-номер-жертвы в опер-памяти" (или его поинтер-адрес).

// Если "номер в опер-памяти" как ноль, то целевой линк считается в данный
// момент Виртуальным линком - фигура-жертва не подгружена - это особая тема.
// Линковка всегда идет только меж "участниками оперативной памяти".
(Ответить) (Уровень выше) (Ветвь дискуссии)
[User Picture Icon]
From:unxp
Date:Октябрь, 2, 2008 22:39 (UTC)
(Ссылка)
Не рекомендую пользоваться такими методами.
(Ответить) (Уровень выше) (Ветвь дискуссии)