Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / База данных игровых объектов: архитекстура системы сериализации и репликации произвольных объектов (5 стр)

База данных игровых объектов: архитекстура системы сериализации и репликации произвольных объектов (5 стр)

Страницы: 1 2 3 4 5 6 7 Следующая »
DelfigamerПостоялецwww2 июня 20180:14#60
tac
У меня в игре игрокам и противникам доступен широкий спектр оружия, каждое из которых стреляет своими собственными снарядами.
Похожая ситуация здесь, так что можешь смотреть сюда и сравнивать с этим.
Есть оружие, которое стреляет быстрыми снарядами, для их отображения используется одна текстура и у них хитбокс одного размера. В поведении снаряда нет ничего особенного - он перемещается с постоянной скоростью, пока не столкнётся со стеной или с игроком. Если он столкнулся со стеной - он просто исчезает. Если он столкнулся с персонажем - происходит проверка на стороны конфликта; если персонаж является союзником стреляющего - то ничего не происходит, и снаряд продолжает лететь как будто бы персонажа и нет вовсе. То есть, когда куча мобов стреляет посреди узкого коридора - они не должны расстреливать друг друга, вместо этого снаряды должны пролетать насквозь. Если же столкнувшийся со снарядом персонаж союзником стреляющего не является - то снаряд исчезает, а на персонажа накладывается фиксированное значение урона.
Есть несколько альтернативных вариантов оружия. Они стреляют своими снарядами, но они похожи на описанный - они тоже летят по прямой, проверяют на стороны конфликта и наносят разовый урон при столкновении. Однако, эти снаряды движутся медленнее, у них меньше размер, они рисуются другой текстурой и наносят меньше урона.
И таких прямолинейных снарядов у меня - с десяток вариантов.
По твоей логике -
> > откуда мне брать префабы?
> new AProjectile();
- для каждого варианта мне нужно объявить свой класс, в котором прописан один дефолт-конструктор, устанавливающий текстуру и хитбокс.

tac
> п.с. запомни студент, ты же ООП не в зуб ногой
Вот это новости. Я думал, это ты здесь только думаешь, что знаешь. Как быть?

Правка: 2 июня 2018 0:14

ZabПостоялецwww2 июня 20183:20#61
Delfigamer
Так, ты движок делаешь, что ли?
Если так, то брось бяку, фигней страдаешь.
Единственный смысл твоих технологий - как можно быстрее донести продукт на их основе до юзера, получить по башке он него при безуспешных попытках сопровождения и больше так не делать. Если сроки выпуска продукта планируются больше чем через год - эдак ты до старости не научишься. Этап то обучения не один...
Еще лучше взять чужой продукт построенный по подобной схеме (те же дельфевые контролы, к примеру) и попытаться с ними что-то нетривиальное сделать для своих нужд. Поймешь что так нельзя и время сэкономишь.
tacПостоялецwww2 июня 20189:23#62
Delfigamer
> для каждого варианта мне нужно объявить свой класс
именно так, это классика ООП, наследование ... но различие пуль ты должен как то объяснять игроку, разный калибр? вот и наследуешь по этому принципу .. а ты как делаешь? создаешь одинаковые объекты и потом меняешь им свойства, настраиваешь? я ж говорю, чет ты не догоняешь, и от этого все проблемы .. потом не понятно как и сериализацию делают

ладно, помощь бедным ..

есть другой пример, когда нужно сериализовать не только координаты. Например, в моей игре, есть бочка с водой, и игрок ее может наливать с 10% шагом ... при сохранении игры, конечно надо сохранить это свойство, насколько бочка наполнена, и тут конечно нет разных классов, она такая же самая. Но это единственное свойство для сохранения из 10-20 других которые сохранять не надо. Как делаем?

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

Правка: 2 июня 2018 9:58

ZabПостоялецwww2 июня 201811:22#63
tac
Не обязательно под каждый тип объектов свой класс. Можно и так, и эдак, в зависимости от того, что нужно.
Проблема в том, что когда человек решает не конкретную задачу, а пишет абстрактный "движок", он понятия не имеет что ему нужно. По сути, ему ничего не нужно, он просто развлекается, пересыпая камушки из кучки в кучку. Можно годы убить на такое раскладывание пасьянсов и ничему не научиться. Движки в руках начинающих - зло.
tacПостоялецwww2 июня 201823:08#64
Zab
> он просто развлекается, пересыпая камушки из кучки в кучку. Можно годы убить на
> такое раскладывание пасьянсов и ничему не научиться. Движки в руках начинающих
> - зло.
тут я согласен ..

Zab
> Не обязательно под каждый тип объектов свой класс. Можно и так, и эдак, в
> зависимости от того, что нужно.
вопрос декомпозиции, если у тебя интернет магазин, то класс попугай тебе нафиг не нужен, он частный случай товара ... если у тебя игра про попугаев, то класс Попугай обязателен

Sh.Tac.Постоялецwww2 июня 201823:31#65
tac
> если у тебя игра про попугаев, то класс Попугай обязателен
безусловно так делать не надо : )

потому как если завтра игра про морских свинок, то весь код про попугаев можно смело выкидывать
или, что встречается чаще, выясняется что попугаев недостаточно, надо ещё добавить туда морских свинок в ту же игру

даже смотреть на таких свинок, переделанных из попугаев на скорую руку, больно
не то что сопровождать код

Правка: 2 июня 2018 23:35

ZabПостоялецwww2 июня 201823:36#66
tac
> вопрос декомпозиции, если у тебя интернет магазин, то класс попугай тебе нафиг
> не нужен, он частный случай товара ... если у тебя игра про попугаев, то класс
> Попугай обязателен
Вопрос только, на каком языке будет у тебя этот класс. Вовсе не обязательно он должен определяться на С#, С++ или чем то подобном. Очень даже может верхний уровень задаваться скриптами или конфигами, от этого он классом быть не перестает. Но где такое пойдет на пользу, а где во вред - от задач зависит. Выделение классов не самоцель, оно под какие-то нужны делается, чего начинающие обычно не понимают.
tacПостоялецwww3 июня 20180:02#67
Sh.Tac.
> если завтра игра про морских свинок
то появится класс морская свинка, и ничего другого
tacПостоялецwww3 июня 20180:04#68
Zab
> может верхний уровень задаваться скриптами или конфигами
это какая та глупость прямо противоречащая ООП
DelfigamerПостоялецwww3 июня 20180:08#69
Забавно смотреть, как не очень опытные разработчики упорно называют меня начинающим.
Ради интереса - ну и сколько, по-вашему, у меня опыта, и сколько нужно для разных ступеней развития программиста?

Правка: 3 июня 2018 0:09

tacПостоялецwww3 июня 20180:14#70
Zab
> Выделение классов не самоцель, оно под какие-то нужны делается
нет, классы выделяются не под цели, все цели /в программном смысле, например, такие цели как безопасность, производительность и прочие/ впоследствии подчинены полученной декомпозиции. Декомпозиция выделяет классы в соответствии с абстрагированием реального мира ... и лишь выбор абстрагирования может быть подчинен задачам моделирования .. о чем я выше и сказал, приведя пример с попугаем
tacПостоялецwww3 июня 20180:17#71
Delfigamer
ну расскажи нам какой у тебя опыт? пока мы знаем, что диплома у тебя нет .. т.е. спокойно мы можем говорить, что ты нулевой .. расскажи, какие проекты ты реализовал, где и кем работал?

а ссылки на дискуссию, где недоучка со мной спорит, показывает лишь твой уровень понимания проблемы

Правка: 3 июня 2018 0:19

Sh.Tac.Постоялецwww3 июня 20180:18#72
tac
> то появится класс морская свинка, и ничего другого
а как же code reuse? : )

попугай уже ходит, зачем это дублировать?

ZabПостоялецwww3 июня 20180:19#73
Delfigamer
> Ну и сколько, по-вашему, у меня опыта, и сколько нужно для разных ступеней развития программиста?
А в чем измерять опыт? Развиваются то все с разной скоростью.
А начинающий ты потому, что ничего еще не понимаешь, жизни не видел, задач не решал. Пока ты создаешь проблемы, а не разруливаешь их. Это уровень юниор-программиста, в лучшем случае, которого без присмотра оставлять нельзя, чтобы не напакостил в проекте.

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

tacПостоялецwww3 июня 20180:20#74
Sh.Tac.
> попугай уже ходит, зачем это дублировать?
пссс .. ну так, наследование от животного никто не отменяет
Страницы: 1 2 3 4 5 6 7 Следующая »

/ Форум / Программирование игр / Общее

2001—2018 © GameDev.ru — Разработка игр