Jesus05 писал(а): ↑10 фев 2017, 07:24
Если хочется все-же ручками, и для сей тогда сгодитятся Qt-шные свойства.
По большому счету задача сейв лоада - сохранить загрузить текущее состояние объектов без потерь данных.
Если уже готовый велосипед может это делать минимизируя дальнейшие телодвижения программиста, сохраняя скопом все параметры объекта. И облегчая дальнейшее расширение проекта.
Почему бы и нет. Я так понял что ты пока просто не нашел еще этот велосипед.
Jesus05 писал(а): ↑10 фев 2017, 07:24
А я не говорил на каждого гоблина по классу, я говорил каждый тип данных должен быть отдельным классом.
HP отдельный класс данных
DAMAGE отдельный класс данных
Я тоже так когда-то думал.
Мол вот у класса ХР есть внутри базовое хп, вот бустед хп, вот макс хп. Он сам там все контролирует субстрактит и инкрементит и баффает и возвращает к базовому значению. Точно также с другими скиллами и статами.
Но по сути, так как он знает только свои параметры и ничего о вышестоящем мобе, весь класс сводится к проверкам граничных значений.
А основная кухня нанесения демеджа происходит в самом мобе.
Когда другой моб его ранит он вызывает функцию моба цели takeDamage куда передает структуру урона, которая и является единственной точкой входа для понижения ХП.
Функция рассчитывает броню, иммунитеты, и считает сколько дамаги по факту прошло, вызывает понижение ХП которое вынесенно в отдельный класс. (Который, какой молодец, проверил граничные условия.) И если дамага больше нуля мобовский takeDamage вызывает мобовскую приватную onTakeDamage().
onTakeDamage смотрит есть ли у моба специальный тег FARTING и тогда создает вонючее облако вокруг в восьми клетках.
Потом тот же мобовский takeDamage смотрит если ХП в нуле или ниже, то вызывает onDeath().
Которая в свою очередь проверяет есть ли у моба тег EXPLODE_ON_DEATH, и генерирует взрыв, плюс спавнит труп и лут в нем.
В итоге takeDamage еще и возвращает атакеру структуру дамаги которая прошла по факту, и тот еще проверяет должен ли он за ее счет вампирить ХП если у него такая опция.
Такие же точки входа для лечения и баффа ХП опять таки находятся в мобе называются healDamage и buffHP и тоже проверяют кучу параметров моба.
В итоге чем прописывать ручную сериализацию для беспонтового класса ХП, который только и умеет что проверить граничные условия , мне было проще убрать класс ХП, перенести проверку граничных условий в тот же мобовский takeDamage и в мобе же указать ручную сериализацию свойств бейз и макс ХП.
Со всяким дамеджем и броней та же песня, их классы максимум что могут сделать - проверить граничные условия. Если же ты хош перенести takeDamage прямо в класс ХП, ему тогда нужна обратная кольцевая ссылка на класс моба и знать его в хеадере, чтобы дергать его свойства и функции. Мой подход мне показался ближе к кип ит симпл стьюпид.
Jesus05 писал(а): ↑10 фев 2017, 07:24
На самом деле тот проект планировался к переносу под андроид после написания, а там выход из приложения несколько туманное понятие, и лучше-бы сохранять данные пользователя настолько часто насколько возможно, но сохранение занимало порядка 2 секунд (на более менее большой карте (1000 * 1000 клеток), а карта генерилась процедурно, небольшими блоками, в процессе исследования и могла расти до 2 000 000 000 * 2 000 000 000), и делать его каждый ход было накладно.
В андроиде есть по идее событие типа "лост фокус", когда пользователь переключается из твоего приложения в список задач или сворачивает его. Собственно оттуда приложение можно и остановить. Сейвся по нему. Ну или раз в сколько-то ходов.