На всякий случай бампану пиком, привлекающим зрелых Кармаков
Грамотно делать так, чтобы была экономия ресурсов. К примеру с твоим хмелем.
Первый вариант - гном производит хмель. Но допустим гном может производить не только хмель, но и много всякой херни на других станках. Тогда, когда гном сядет за станок идет примерно так: Гном сел за станок - Проверка какой станок - Производить хмель. Ежели делать, что станок производит хмель, то будет так: Станок проверяет наличие гнома - делать хмель. Ну а в большинстве все это дело вкуса! Удачки
Первый вариант - гном производит хмель. Но допустим гном может производить не только хмель, но и много всякой херни на других станках. Тогда, когда гном сядет за станок идет примерно так: Гном сел за станок - Проверка какой станок - Производить хмель. Ежели делать, что станок производит хмель, то будет так: Станок проверяет наличие гнома - делать хмель. Ну а в большинстве все это дело вкуса! Удачки
>Предположим, ты делаешь тридэ-экшон
Код разбит на подсистемы. Физика - одна система, расчет урона - другая система. Физика работает с коллизиями. Для объектов, участвующих в нужных столкновениях есть набор колбэков. При столкновении - в данном случае попадании снаряда куда-то - вызывается весь список колбэков, которые есть у снаряда. И в данном случае там будет колбэк, который добавить в систему "нанесения урона" соотв. событие, что такой-то снаряд попал в такую-то цель. Когда очередь дойдет до системы обработки урона, она все эти события по очереди выполнит или не по очереди, для того очередь и делается, чтобы ей можно было крутить-вертеть. Возьмет из каждого события данные об снаряде, противнике, рассчитает урон и отнимет от хп.
Как всегда, можно не заморачиваться и сделать проще - при попадании снаряда урон будет считаться сразу в общем методе, которому передаются урон снаряда, ссылки на цель (чтобы вычесть урон от здоровья), броня цели и т.д. и т.п.
Я смотрю у тебя фундаментальный провал опец в области ООП.
Делаешь абстракции и постепенно доходишь до специализации.
То есть стремись всегда выделять любое действие в узкие классы.
Скажем, твой пример со станком и гномом. Очевидно, что у гнома гораздо больше возможностей, чем у станка делающего говно.
Соответственно он и должен обрабатывать все, что касается производства говна.
Далее пример с пулей. Тоже самое. Герой - у него есть характеристика хп, но тут элементарно ты можешь представить, в игре явно хп отнимает не только пуля, значит неразумно все методы впихивать герою. То есть нет такого метода в игре получение урона, есть "нанесение" урона.
Значит берешь конкретный тип пули, прописываешь его урон и если пуля попала в игрока вычитаешь из хп игрока дамаг пули и удаляешь ее. Объект сделал свое дело он может уходить.
Ну и самое главное правило построения любой игры - сделай диздок, либо набросок всего, что ты хочешь видеть в игре. Лучше именно визуально.
Нарисуй игрока - напиши его методы, скажем "ходить", "драца", "струлять", "умирать". Далее формируй группы, например "боевка", "инвентарь", "движение".
Желательно вести такую карту походу проекта, куда постоянно добавлять все новые идеи. Это будет что-то типа твоей макроблоксхемы, тебе не нужно будет лезть в код, чтобы вспомнить где и что у тебя происходит, все важные вещи будут на виду.
Это нужно всегда делать перед написанием кода. Скажем, сегодня ты хочешь сделать то-то, рисуешь это сначала. Вставляешь на рисунке куда это лучше подойдет. Затем делаешь.
Это годится только для больших проектов, разумеется миниигры обычно пилятся с ходу. По крайней мере, если код не больше 4к строчек, я обычно даже не парюсь этим, держу в голове, но вот больше начинают выпадать важные моменты. Карта проекта в этом случае для меня мас хэв.
Делаешь абстракции и постепенно доходишь до специализации.
То есть стремись всегда выделять любое действие в узкие классы.
Скажем, твой пример со станком и гномом. Очевидно, что у гнома гораздо больше возможностей, чем у станка делающего говно.
Соответственно он и должен обрабатывать все, что касается производства говна.
Далее пример с пулей. Тоже самое. Герой - у него есть характеристика хп, но тут элементарно ты можешь представить, в игре явно хп отнимает не только пуля, значит неразумно все методы впихивать герою. То есть нет такого метода в игре получение урона, есть "нанесение" урона.
Значит берешь конкретный тип пули, прописываешь его урон и если пуля попала в игрока вычитаешь из хп игрока дамаг пули и удаляешь ее. Объект сделал свое дело он может уходить.
Ну и самое главное правило построения любой игры - сделай диздок, либо набросок всего, что ты хочешь видеть в игре. Лучше именно визуально.
Нарисуй игрока - напиши его методы, скажем "ходить", "драца", "струлять", "умирать". Далее формируй группы, например "боевка", "инвентарь", "движение".
Желательно вести такую карту походу проекта, куда постоянно добавлять все новые идеи. Это будет что-то типа твоей макроблоксхемы, тебе не нужно будет лезть в код, чтобы вспомнить где и что у тебя происходит, все важные вещи будут на виду.
Это нужно всегда делать перед написанием кода. Скажем, сегодня ты хочешь сделать то-то, рисуешь это сначала. Вставляешь на рисунке куда это лучше подойдет. Затем делаешь.
Это годится только для больших проектов, разумеется миниигры обычно пилятся с ходу. По крайней мере, если код не больше 4к строчек, я обычно даже не парюсь этим, держу в голове, но вот больше начинают выпадать важные моменты. Карта проекта в этом случае для меня мас хэв.
Пишешь отдельный класс BrewMaker, который реализует интерфейс IBrewMaker и делает хмель. Гнома и станок передаешь ему в конструктор.
Не стесняйся писать новые классы. Каждый класс должен выполнять ровно одну функцию и делегировать все остальное другим.
Мне требуется больше объяснений, милорды!
Я всё равно не понимат, почему в первом случае ты говоришь, что у гнома больше возможностей, поэтому нужно выделять действия на гнома, а во втором случае, где у героя очевидно тоже больше возможностей, я выделяю действие уже на пулю. Разве станок из первого примера — не то же самое, что пуля из второго? А если это станок не по производству хмеля, а по отхилу гнома? Тогда и в том и в другом случае же будут производиться действия с ХП героя? Короче, я не понимат! И как вообще ты решаешь, на кого вешать действия? Чем ты руководствуешься? И правильно ли я понимаю, что чтобы это всё понять, мне нужно копать в сторону теоретического и абстрактного ООП? Есть какое-то чтиво на тему ООП без привязки к конкретному языку?
Всё круто, только я не понимат, почему станок проверяет наличие гнома, а не гном наличие станка? И каким образом это сэкономит ресурс?
И у тебя всё круто, но непонятно, кто вызывает эти коллбэки. Ты вот говоришь «вызывается», а у меня именно в этом-то и вопрос, как решить, кем это вызывается
А у тебя не круто, потому что я, похоже, дурачок и не понимаю, что такое классы и конструкторы. Класс — это как раз тот самый абстрактный хмель, висящий в бэкграунде, о котором я писал в оппосте?
Я всё равно не понимат, почему в первом случае ты говоришь, что у гнома больше возможностей, поэтому нужно выделять действия на гнома, а во втором случае, где у героя очевидно тоже больше возможностей, я выделяю действие уже на пулю. Разве станок из первого примера — не то же самое, что пуля из второго? А если это станок не по производству хмеля, а по отхилу гнома? Тогда и в том и в другом случае же будут производиться действия с ХП героя? Короче, я не понимат! И как вообще ты решаешь, на кого вешать действия? Чем ты руководствуешься? И правильно ли я понимаю, что чтобы это всё понять, мне нужно копать в сторону теоретического и абстрактного ООП? Есть какое-то чтиво на тему ООП без привязки к конкретному языку?
Всё круто, только я не понимат, почему станок проверяет наличие гнома, а не гном наличие станка? И каким образом это сэкономит ресурс?
И у тебя всё круто, но непонятно, кто вызывает эти коллбэки. Ты вот говоришь «вызывается», а у меня именно в этом-то и вопрос, как решить, кем это вызывается
А у тебя не круто, потому что я, похоже, дурачок и не понимаю, что такое классы и конструкторы. Класс — это как раз тот самый абстрактный хмель, висящий в бэкграунде, о котором я писал в оппосте?
Зависит. Не совсем согласен с коллегами и , но большую часть вещей они говорят верно. Во-первых, если у тебя не-ООП имплементация (а судя по вопросам про классы и конструкторы, это именно так), то бросай это дело и учи ООП. По правде говоря, полноценная entity-component system после определённого размера будет удобнее, но для первого проекта пилить её самому оверкилл Без объектов игры писать можно, но очень тяжело. В качестве чтива на тему ООП бери википедию либо любой вводный курс языка, сильно заточенного под ООП (Java, Python, кресты), остальное от лукавого. В качестве примера можешь полистать вот этот гайд по рогаликам, он в принципе эволюцию кода в небольшом проекте хорошо иллюстрирует: http://www.roguebasin.com/index.php?title=Complete_Roguelike_Tutorial,_using_python%2Blibtcod Как разберёшься - читай Game Programming Patterns, там куча кейсов разобрана. Но это довольно сложная книжка, без как минимум понимания ООП браться не стоит.
Во-вторых, пример с пулей примерно таков (будут упоминания паттернов, разберёшься посредством той же википедии). К пушке прикручена фабрика, создающая при каждом выстреле объекты класса "Пуля" (вероятно, подкласс какого-нибудь Projectile). После выстрела пушке до пули нет никакого дела. На каждом тике проверяется, не въебалась ли пуля в кого-нибудь. В зависимости от движка, это делает либо сама пуля, либо некий хитроумный синглетон-счётчик коллизий. Ежели въебалась - вызывается коллбэк жертвы, скажем, get_collided_by() и передаётся пуля в качестве аргумента. Коллбэк считает дамаг и модифицирует соответствующие аттрибуты жертвы, пуля после этого забывается. В какой момент отрисовывается брызнувшая кровь - опять же зависит от движка. Если аттрибуты (например, хитпойнты) задаются через нормально написанные сеттеры, то смерть и/или увечье наступят сами собой. Если с пулей при попадании должно произойти что-то помимо воздействия на цель, то у неё тоже должен быть аналогичный коллбэк.
Гномов разбирать не буду, это куда более хитроумная система и вариантов слишком много.
Во-вторых, пример с пулей примерно таков (будут упоминания паттернов, разберёшься посредством той же википедии). К пушке прикручена фабрика, создающая при каждом выстреле объекты класса "Пуля" (вероятно, подкласс какого-нибудь Projectile). После выстрела пушке до пули нет никакого дела. На каждом тике проверяется, не въебалась ли пуля в кого-нибудь. В зависимости от движка, это делает либо сама пуля, либо некий хитроумный синглетон-счётчик коллизий. Ежели въебалась - вызывается коллбэк жертвы, скажем, get_collided_by() и передаётся пуля в качестве аргумента. Коллбэк считает дамаг и модифицирует соответствующие аттрибуты жертвы, пуля после этого забывается. В какой момент отрисовывается брызнувшая кровь - опять же зависит от движка. Если аттрибуты (например, хитпойнты) задаются через нормально написанные сеттеры, то смерть и/или увечье наступят сами собой. Если с пулей при попадании должно произойти что-то помимо воздействия на цель, то у неё тоже должен быть аналогичный коллбэк.
Гномов разбирать не буду, это куда более хитроумная система и вариантов слишком много.
Меньше операций же.
Если гном, то он еще проверяет КАКОЙ это станок.
>По правде говоря, полноценная entity-component system после определённого размера будет удобнее, но для первого проекта пилить её самому оверкилл
Такой-то оверкилл. Огроменная система просто.
http://pastebin.com/3rT9fpNG
Дрочить некое абстрактное ООП смысла нет, паттернов вообще куча. Надо просто выучить как устроены удобные для игор, навроде стейта, компонентов, этц.
http://gameprogrammingpatterns.com/component.html
Не следует делегировать гному ничего лишнего. Да у него есть некоторые данные, типа хп, имени, позиции в мире, методы перемещения, причем они не у гнома, а наследуются из родителей, например группы юнитов.
То есть у гнома должны быть исключительно специфичные гному методы и свойства, ничего больше.
Например если только он может получать урон от пуль тогда да, логично именно в нем производить обсчет урона, но ЭТО ЖЕ НЕ ТАК! Поэтому пуля должна сама определить в кого попала и нанести только этому объекту. Не гном должен это делать. Пуля может кого угодно дамажить.
То есть у гнома должны быть исключительно специфичные гному методы и свойства, ничего больше.
Например если только он может получать урон от пуль тогда да, логично именно в нем производить обсчет урона, но ЭТО ЖЕ НЕ ТАК! Поэтому пуля должна сама определить в кого попала и нанести только этому объекту. Не гном должен это делать. Пуля может кого угодно дамажить.
Святые говны, это оказывается достаточно сложно, дорогие сэры! Вы открыли мне целый новый мир, друзья, двести пятьдесят пять интернетов вам, сдачу оставьте себе! Тред всё равно буду периодически бампать, хочу ещё ваших мнений и советов мудрых на тему паттернов, классов и вот этой всей крутой хуевни.
Так посмотри как устроен движок какой-нибудь простой.
Ну да, спрототипировать её просто, кто бы спорил. Но потом возникают вопросы типа "В какой компонент засунуть рокетджамп, если у него есть кулдаун и вроде как похоже на спелл, но он перемещает героя и вроде как имеет отношение к движению, а ещё очевидно должен проверять наличие ракет в инвентаре". Ответы на них существуют, но требуют большой и умной системы с продуманным взаимодействием компонентов.
Для первой игры можно проще, без ооп.
Типа вот такого.
- Есть миллион глобальных переменных и массивов. Массив людей, массив пуль.
- Есть неебических размеров глобальный цикл. Для каждой пули инкремент положения и проверка, не в голове ли она человека.
Для каждого человека проверка, не стреляет ли он.
Короче. Если делаешь игру реально как ДФ, то желательно втыкать в норм архитектуру и ооп. Если делаешь хуиту в десять сущностей, лучше обойдись говнокодом. Хоть игру доделаешь. А ооп и архитектуру можно до старости дрочить и не достичь идеала.
Но у тебя не ECS. И попробуй теперь сделать компонент, который считает коллизии.
Алсо, вы уже заебали ссылаться на этого дворника из ЕА.
>ECS
Почему? Напиши тогда правильный ECS. Не ради срача спрашиваю, мне правда интересно.
Я пытаюсь идти по пути наименьшего сопротивления.
Берем шутер и идем логическим путем. Пули это короткоживущие обьекты, которых может быть достаточно много, от разных врагов или игроков, от разных видов оружия и так далее. Нагружать такое колличество короткоживущих объектов лишними вычислениями - не рационально, ведь чем больше ты стреляешь, тем больше вычислений нужно сделать. Стрелок или цель? У цели всегда есть показатель хитпоинтов. То есть, универсальный класс для получения урона (от разных типов пуль в том числе) может использоваться любой целью. Поскольку у нас пуля, как мы уже решили, объект практически без вычислений, а регистрация столкновений, если это не мгновенные попадания, происходит между пулей и целью, то и ответ, собственно говоря, очевиден - вычисления нужно проводить у цели.
То же самое и с гномом. Станок, он один а, а гномов много. Каждый занят своими вычислениями, помимо станка. Если каждый станет еще проверять за станком ли он, сколько ему времени для производства нужно, то на каждую такую проверку для каждого гнома уйдет много вычислений, в то время как станку достаточно проверить всего один раз, есть ли за ним рабочий.
В общем нужно руководствоваться логикой и здравым смыслом. Сесть, набросать на бумаге алгоритм, взаимодействия и посмотреть что затратнее, и чем можно пожертвовать для удобства в ущерб производительности. Я кончил.
Дохуя писать. Вот попытка в недоплатформер на ecs на питоне 2.7 http://rgho.st/private/8vrMQRSDs/15b1797152b5929447063eaa599f72e8
Только там что-то совсем плохо написано, при том, что это не первая моя попытка в компоненты и системы. Вообще, под неё надо мышление переделывать.
Алсо, если хочешь душевное здоровье сохранить, то не смотри в файл с коллизиями.
> от разных видов оружия
Урон должен зависеть от типа оружия, а не от типа пули.
Но ведь, есть разные калибры/типы боеприпасов : разрывные, бронебойные,зажигательные и т.д....
А если сделать генерацию кастомных пуль, создавать их исходя из оружия, которым стреляют. Передавать в конструктор ее урон и тип (сделать вроде enum). М?
мимокрок
>Станок, он один а, а гномов много. Каждый занят своими вычислениями, помимо станка. Если каждый станет еще проверять за станком ли он, сколько ему времени для производства нужно, то на каждую такую проверку для каждого гнома уйдет много вычислений
Но нахуя проверять? У дварфа а не гнома должна быть переменная. отвечающая за текущий таск, в таске - указатель на станок или его ИД. В апдейте обрабатываешь таск и все.
Господа хорошие, кто знает что можно почитать, чтобы научиться пилить конкретно в юнете хорошую архитектуру. А то у меня любой более менее разросшийся проект превращается в ебучий хаос.
>Пуля должна сама определить в кого попала
Пуля должна знать, в кого попала, потому что коллизию за неё уже обнаружил физический движок. А у дворфа коллбэк должен быть не прописан в классе гнома, очевидно, (ты же на это намекаешь?), он должен либо наследоваться из Актора, либо сидеть в компоненте, ответственном за пулепробиваемость.
> А то у меня любой более менее разросшийся проект превращается в ебучий хаос.
Что ты имеешь ввиду?
Приведёшь примеры?
Так и должно быть.
Короче смари
1) определи все объекты которые нужны чтобы это твое действие совершить. Для пули это может быть только пуля и враг, в которого попали. Либо еще игрок, чтобы ему +1 фраг засчитать. То же самое для гнома - это будет гном, станок, и еще место куда попадет продукция.
2) посмотри какой класс знает о существовании всех задействованных сущностей. Надеюсь, не надо объяснять, что классы должны проектироваться с минимальным числом зависимостей? loose coupling.
Если нет такого класса, его надо создать. Более того, после этого ты поймешь что какой-то существующий класс(или несколько) перегружены, и их надо отрефакторить.
3) вот этот-то класс и должен производить действие.
Ну например я сделал базовый класс для апгрейдов. Как только они прокачиваются, появляется gameobject с этим классом и вызывается метод InitUpgrade, который изменяет статы. А потом мне пришла идея сделать апгрейд, который увеличивает статы в зависимости от другого (изменяемого) стата. Теперь этому апгрейду приходится хранить последнее значение изменяемого стата и при несовпадении последнего значения и текущего вызывать ReInitUpgrade, который сначала бафает с отрицательным старым значением стата, изменяет его, а потом бафает с новым. Выглядит это как ебучий костыль. И из таких костылей состоит весь проект.
Мне кажется у тебя изначально несколько не правильно всё проектировалось.
А как бы ты спроектировал систему улучшений?
Вот есть например абстрактный герой с кучей статов и возможностей и апгрейды для него.
Когда у героя меняется стат, он постит сообщение MobStatChanged(IMob mob, StatType statType, int oldValue, int newValue).
Другой класс UpgradesService получает это сообщение и меняет статы в зависимости от.
Чтобы знать, обрабатывать ли таск ну и слово ты подобрал, нужно сделать проверку на то, какое значение переменной в данный момент. В апдейте это делается каждый тик. Для тысячи гномов это тысяча проверок. Для одного станка это одна проверка.
Вот этот хуй достаточно просто пояснил схему, мне нравится. Кто-нибудь может прувнуть, что это правильная логика?
Я пруваю, правильно всё говорит. Если класс знает о существовании всех сущностей - то он занимается их взаимодействием, пусть он и отслеживает. Если класс знает о существовании всех трёх сущностей, но их взаимодействием не занимается, то зачем он об этом знает?
Другой хуй
>И у тебя всё круто, но непонятно, кто вызывает эти коллбэки
Их вызывает система физики. Как - зависит от системы. Если она позволяет регистрировать методы-обработчики коллизий с определенными фильтрами (например "пуля-цель" Nape умеет например), то такие методы-обработчики уже и есть колбэки. При том эти обработчики могут быть где угодно в коде на самом деле. В отдельном классе- инициализаторе например.
>Я не уверен, что то, о чём я говорю, называется логической архитектурой, поэтому поясню на примере. Предположим, ты делаешь тридэ-экшон, у тебя есть герой, есть пушка у героя, есть снаряд, вылетающий из пушки, и есть враг. Каким образом ты решаешь, как эти предметы будут взаимодействовать?
Это называется гейм-дизайн.
Нет, мудак, это не гейм-дизайн
Друг, я снова выхожу на связь, и мне снова нужен предметный совет. Я все понял и уяснил насчёт классов, коллбэков и прочей архитектуры, но теперь у меня вопрос про логику. Вернёмся к моему примеру с гномами и станками, но на этот раз представим себе двух гномов и один станок. В очередной тик двум гномам приходит в голову желание поработать на этом станке, и тут-то и возникает логическая проблема: как им этот станок поделить между собой? Кто из них должен занять станок и почему? Должны ли они знать, занят станок или нет и как они об этом должны узнавать? Бежать вдвоём на рабочее место и пусть победит быстрейший? Или представить, что они телепаты и знают всегда, занят станок или нет? В общем, как бы ты решил эту задачу, и главное, почему именно так?
Прежде всего нужно перестать быть диванным и перестать думать о каких-то абстрактным вещах, а надо начать делать игры, ибо у тебя нет достаточного опыта чтобы думать в абстракциях, а этот опыт приобретается только когда ты делаешь игры.
Делай самый простейший вариант который можешь придумать, и пиши какой хочешь говнокод, он потом сам уйдет через пару лет программирования.
>Или представить, что они телепаты
Лично я бы так и сделал. Первому гному приходит в голову идея поработать на станке, и в станке выставляем свойство worker=наш гном, остальные гномы уже тогда не могут его занять, так как для этого требуется, чтобы worker был равен null.
Тред не читал.
Можно ещё что-бы второй гном не просто смотрел что станок занят, но и определял своё расстояние до станка и расстояние первого гнома. Если расстояние первого гнома дальше - то он идёт нахуй, а за станок становится второй гном. Короче что бы гном из Австралии не шёл до станка в Канаде и не проёбывал время.
> и мне снова нужен предметный совет.
Конкретно здесь - совета предметного о логической архитектуре быть не может, дележ станка - вопрос гейм-дизайна.
Решение выбирается исключительно из конкретных нужд.
Если делаем систему-супервизор, которая управляет роем роботов, которые что-то делают, то очевидно этот супервизор будет читать данные от роботов и планировать за них, в какую точку пр-ва им двигаться, на основе какой-то оценки - от банального минимального расстояния до ближайшей свободной цели, до учета тех состояния движителей и встречного ветра.
Без системы супервизора - каждый робот в рое - сам себе велосипед, сам принимает решения, на основе того, что видит. Видит цель - идет к ней. Видит, что кто-то пришел к цели раньше него - ищет другую цель.
мог бы игры делать
> Кармак, продумываешь и реализуешь логическую архитектуру твоей игры?
Всё по философии Реймонда. Модульно, с компактными модулями общающимися человеческим языком, с человекочитаемыми конфигами, с тестами модулей и т.д.
> Каким образом ты решаешь, как эти предметы будут взаимодействовать?
> снаряды с хп
Если это триде, то через модуль коллизий.
Если это что-то схематичное, например изометрия, то через модуль сверки скиллов. Хватило (своего скилла + точности оружия + рандома - уворот врага - помехи на линии прицеливания) на попадание, значит попал. Снаряды как таковые выносятся в область аутизма.
> пушка должна проверять столкновение выпущенного снаряда и снимать НР?
Так как в экшоне всё делается через модуль коллизий, то таки надо нарисовать снаряд, даже если это лазерный луч. Заодно будет возможность ограничить лазер ньютоновской скоростью света и если вдруг все перейдут на квантовые компы, способные отрисовывать солнечную систему, то проект останется актуальным.
> Каким образом решить, что должно производить хмель?
Конфигом гейм-объектов.
> Станок должен проверять наличие работающего гнома рядом и производить хмель или гном должен проверять наличие станка рядом и работать/производить хмель?
Как ИИ распишешь, так и будет.
Разумно сделать UML с иерархической структурой объектов, где расписать кто что каким скиллом активирует и кому потом отчитывается.
Андройдовские UML-редакторы ставьте аккуратно, они могут отсылать данные вашего проекта не тому кому надо. Смотрите чтобы в "разрешениях" не было сети (разрешение неявное, при установке не спрашивается - разрешать или нет).
p.s. Если хочешь писать много говна, в котором не разберёшься через полгода, то выбирай ООП. Если хочешь писать мало, но то что будет работать вечно, бери функциональщину.
ООП - неплохая прокладка между логикой и обычным_пользователем и только.
> я, похоже, дурачок и не понимаю, что такое классы и конструкторы
Это слова-детекторы объектодебила.
> Меньше операций же.
Время компьютера дёшево, время программиста дорого.
Поэтому нехуй делать нетривиальные решения. Логику пиши по таску раз-раз-раз.
> проще, без ооп
> Нагружать такое колличество короткоживущих объектов лишними вычислениями - не рационально, ведь чем больше ты стреляешь, тем больше вычислений нужно сделать.
А на хуй тебе вообще нужен компьютер, если не для того, чтобы делать вычисления, долбоёб?
А если ты хочешь сделать нормальную стрелялку наконец, в которой будут человеческие рикошеты? Надо всего то будет дописать пару формул (рикошета, целостности пули и разлёта осколков) в коллизию пули и пожалуйста - у тебя игра уровня CS:GO. Нет, мы будем оптимизировать дизайн и использовать ООП, чтобы вышло всем давно известное кривое жирное говно, но зато компьютеру, ставшему со времён выхода оригинального квейка в 1000 крат быстрее, не надо будет лишний раз считать траекторию пары сотен пуль.
https://www.youtube.com/watch?v=QfVYlNCoZlI
> Господа хорошие, кто знает что можно почитать, чтобы научиться пилить конкретно в юнете хорошую архитектуру.
Везде.
Правило модульности: Пишите простые части, соединяемые понятными интерфейсами.
Правило ясности: Ясность лучше заумности.
Правило композиции: Разрабатывайте программы так, чтобы их можно было соединить с другими программами.
Правило разделения: Отделяйте правила (policy) от механизма (mechanism); отделяйте интерфейс от движка (engine).
Правило простоты: Нацельтесь на простоту; добавляйте сложность, только где необходимо.
Правило экономности: Пишите большую программу только когда другими средствами выполнить необходимую задачу не удастся.
Правило прозрачности: Разрабатывайте прозрачные программы для облегчения последующего пересмотра и отладки.
Правило надёжности: Надёжность — дитя прозрачности и простоты.
Правило представления: Храните знания в данных так, чтобы логика программы была тупой и надёжной.
Правило наименьшего удивления: При разработке интерфейса всегда делайте как можно меньше неожиданных вещей.
Правило тишины: Если программе нечего сказать, пусть лучше молчит.
Правило восстановления: Если надо выйти из строя, делайте это шумно и как можно быстрее.
Правило экономии: Время программиста дорого; сократите его, используя машинное время.
Правило генерации: Избегайте ручного набора кода; при любом удобном случае пишите программы, которые бы писали программы.
Правило оптимизации: Сначала — опытный образец, потом — «причесывание». Добейтесь стабильной работы, только потом оптимизируйте.
Правило многообразия: Отвергайте все утверждения о «единственно правильном пути».
Правило расширяемости: Разрабатывайте для будущего. Оно наступит быстрее, чем вы думаете.
Это таки гейм-дизайн, если мы говорим о крупном проекте.
ГД делает принципиальную схему программы.
Принципиальная схема порождает функции.
Функции порождают таски.
Таски порождают программу.
ГД тогда поддерживает альтер-схему, каррент-схему (изначально - обкорнав альтер-схему до прототипа) и список функций, необходимых для реализации каррент-схемы.
Главный программер разбивает функции на таски по написанию модулей функций и тестов для этих модулей.
Программисты занимаются реализацией тасков. Если таск проходит тест с первого раза, программист получает премию. Если ни один таск не проходит ни один тест долгое время, то программист перестаёт быть программистом в этой конторе.
Бывают конечно и другие решения, типа "скрам", когда ГД с отделом маркетинга пальцем на стене сортира чё-нить чертят, определяют что они будут воровать (как близзард например пытается спиздить TF и DOTA у валва) или покупают каких-нибудь несчастных бомжей с хорошей идеей (как Take Two Interactive купили Illusion Softworks), главный программист и прожект менеджер занимаются тем, что погоняют хуями программистов, пока те что-нибудь не родят, устраивая ежедневную еблю, на которой требут от программистов же написание ближайших тасков (то есть выполнения работы ГД). Потом отдел маркетинга хайпает поделие, а промытые дети покупают кривую говноподелку по предзаказу.
Быдло при этом верещит, что программист - это творческая личность, поэтому скрам это нормально. Текучка кадров естественно огромная. Чтобы удержать быдлецо, ему накидывают чисто-сектантские картиночки про "любовь дружба радость счастье ум совесть честь исполнительность". Главный ответ на все вопросы о сроках "ты же подводишь команду". В команду набирают негров и феминисток, генерирующих полуграмотные тексты, 3д-сканящих модельки и ездиющих в командировки в райцентр делать мойшен кепчур. Они так же хуесосят быдло с позиции начальства, изображая что они дохуя сделали и жутко незаменимы. Отрицательная мотивация конечно же прекрасно работает.
Ты аутист, склонный к рекурсии, да? Сегодня есть возможность делать более приближенные к реальности модели, чем вчера. Ты - контроллер, посылаешь пешке команду шмальни, пешка посылает команду шмальнуть пушке. Пушка спавнит пульку, пулька летит и при коллизии посылает через интерфейс сообщение "вам пришел урон", а уже в цели может быть реализован интерфейс или нет, принимает она сообщение и рассчитывает, сколько же урона было нанесено с учетом брони например. Можно расчет и в пульку засунуть, и в стрелка, все равно этот расчет будет выполнятся, но при наличии гибкой среды разработки, лучше засунуть всякую хуйню туда, где ей место. Но это очень простой пример, гораздо сложнее например система инвентаря с модифицируемыми айтемами самого различного типа, вот там уже можно тыщей способов одно и то же сделать и еще и спорить до инсульта, какой же способ лучше.
Гном через интерфейс посылает станку сообщение сделать что-нибудь, станок принимает сообщение и делает хмель. Интерфейсы, небо, аллах.
>Если гном, то он еще проверяет КАКОЙ это станок.
Сука, интерфейсы вкури, дебил. Я ебал.
Суп сосоны, у меня такой вопрос: какая архитектура должна быть у системы коллизий?
Суть в том, что я пилю простенький платформер, у меня есть неподвижные и подвижные сталкиваемые объекты, все прямоугольные. Естественно, неподвижные с неподвижными сталкиваться не могут.
Так вот, где должен находиться метод, который, собственно, проверяет объекты на столкновения? В самих объектах? В отдельном классе?
Суть в том, что я пилю простенький платформер, у меня есть неподвижные и подвижные сталкиваемые объекты, все прямоугольные. Естественно, неподвижные с неподвижными сталкиваться не могут.
Так вот, где должен находиться метод, который, собственно, проверяет объекты на столкновения? В самих объектах? В отдельном классе?
Обычно делают отдельный класс физики, в котором содержатся все физические объекты, и там все происходит.
В самих объектах максимум только скорости устанавливать при передвижении, да флаги всякие проверять.
Спасибо, я так и думал.
Теперь другой вопрос: как я уже говорил, у меня есть подвижные и неподвижные объекты. Я вначале хотел обработать столкновения подвижных объектов с неподвижными(типа персонаж игрока <-> паверапы и сам уровень), а затем уже подвижных с подвижными(типа игрок <-> враги). Это разумно? Или в индустрии уже есть какой-то best practice?
Это нормальный подход.
Можно вообще все в одном цикле делать, просто сначала проверять, что оба объекта не неподвижные, условия мало жрут вообще.
>Или в индустрии уже есть какой-то best practice?
Использование готовых физ. движков. Хотя для простых аркадок можно и самописный физон замутить, он несложно и недолго делается, при этом не придется делать костыли, как при использовании "тру"-физических движков, для создания аркадности движения (хотя и такой подход также используется в играх).
> какая архитектура должна быть у системы коллизий?
Векторная или пиксельная?
Если вектор, то при отрисовке смотри попадают ли вершины на территорию других объектов.
Если пиксель, то либо попадание пикселей на пиксели при отрисовке, либо пересечение объектов по x&&y.
> в индустрии уже есть какой-то best practice?
Нет. Слишком специфическая и легко решаемая задача, чтобы из неё выводить целую практику. Особенно на 2д.
На n-мерных пространствах наверняка что-то есть.
Из практик можно сказать заранее только, что тебе не надо заниматься делением объектов на подвижные и неподвижные, пока твоя программа не начнёт тормозить.
1. Реализация.
2. Отладка.
3. Оптимизация.
И никак ещё.
А у тебя игра про дварфов гномы? какие гномы? или про станки? А рубку деревьев как проверять будеш - проверять все деревья? А переноску камней? А сбор урожая?
Вызывать метод апдейта у каждого дварфакаждый тик - это нормально на самом деле - можешь вызывать каждый тик апдейт у трети гномов, для экономии, так как игра про дварфов. В апдейте дварф анализирует окружение пора ли жрат/спат и т.д. и чето делает - реагирует на окружение/ищет доступное задание если таск от task - задача, задание не нравится/продолжает выполнение предыдущего.
И все это создает впечатление живого мира - каждый дварф живет своей жизнью.
>мимослоупок
>будешь
будешь, офкос
бля, обосрался с разметкой
>Для одного станка это одна проверка.
Если у тебя игра про станки, в которой твои гномики могут только работать на станках - это конечно норм. Только гномы наверное у тебя ещё будут гулять, голодать, выискивать работу, сражаться с траллями, собирать ресурсы, разговаривать, строить, исследовать.
В конечном итоге объектов взаимодействия и действий будет побольше, а ещё нужно где-то каждый тик просчитывать реакцию гнома на обстановку вокруг него.
>А потом мне пришла идея
Это основная причина захламления у тебя.
Я не уверен, что то, о чём я говорю, называется логической архитектурой, поэтому поясню на примере. Предположим, ты делаешь тридэ-экшон, у тебя есть герой, есть пушка у героя, есть снаряд, вылетающий из пушки, и есть враг. Каким образом ты решаешь, как эти предметы будут взаимодействовать? Если при попадании снаряда должны сниматься НР у врага, то кто их должен снять внутри кода — снаряд при столкновении с врагом или враг при получении снаряда? Или вообще пушка должна проверять столкновение выпущенного снаряда и снимать НР?
Или вот другой пример. Предположим, ты делаешь дворф фортрещ, у тебя есть гном и есть станок, за которым работает гном и производит хмель. Каким образом решить, что должно производить хмель? Станок должен проверять наличие работающего гнома рядом и производить хмель или гном должен проверять наличие станка рядом и работать/производить хмель? Или вообще в фоне должен висеть абстрактный хмель, проверяющий пересечение работающего гнома и станка, и спавнить свои хмелесущности?
В общем, дорогой дружище Кармак, если не сложно, либо дай мне правильное название того, что я описал, чтобы я это мог разгуглить самостоятельно, либо давай с тобой потрём на эту тему в этом треде. Ты можешь рассказать примеры, как ты создавал подобную логику для своих ААА-хитов, или какие полезные материалы ты читал на эту тему, или просто запости хлопьев раби в этот тред. Спасибо, что дочитал до конца, традиционно, соси хуй быдло. Пик самхау рилейтед.