Этого треда уже нет.
Это копия, сохраненная 1 августа 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 1 августа 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
В треде будут по большей части рассуждения, так как я не знаю как реализовать ту или иную функцию. Для начала моя самая большая хотелка: Уникальная система крафта персонажа, предметов, окружения, врагов, эффектов. То есть, все находящееся в игровом пространстве может быть как разбито на некие составляющие, так и быть составлено из них. На самом деле все, на этом все заканчивается, но посмотрим как реализовать хотя бы это. Интересует меня в большей степени внутренняя составляющая игры, поэтому графику и прочее я оставлю на потом.
Писать планирую на C# с оглядкой на многочисленные библиотеки со вспомогательными функциями для создания roguelike игр (там тебе и генерация карт и игровые сущности). В общем, есть куда подсмотреть в случае чего
Ну так вот, рассуждения:
Есть некая область (обычный прямоугольник, для начала) внутри нее расположены игровые сущности, такие как сам игрок, враги, предметы, также в каждой клетке имеется что-то вроде эффекта, который невидим с точки зрения занимаемого пространства, но вполне себе может оказывать влияние на окружающее пространство со всеми объектами в нем. Также я бы выделил такой базовый объект как действие, с помощью которого игровые объекты будут влиять как на себя, так и друг на друга.
Итого:
Пространство
Игрок, враги (или экземпляры одного объекта или просто наследуются от общего опредка)
Предмет
Эффект
Действие
Есть некая область (обычный прямоугольник, для начала) внутри нее расположены игровые сущности, такие как сам игрок, враги, предметы, также в каждой клетке имеется что-то вроде эффекта, который невидим с точки зрения занимаемого пространства, но вполне себе может оказывать влияние на окружающее пространство со всеми объектами в нем. Также я бы выделил такой базовый объект как действие, с помощью которого игровые объекты будут влиять как на себя, так и друг на друга.
Итого:
Пространство
Игрок, враги (или экземпляры одного объекта или просто наследуются от общего опредка)
Предмет
Эффект
Действие
Само собой для простоты разработки все должно быть разбито на группы, то есть, если это это эффект, то у него должна быть определенная природа (физическое воздействие, химическое или наоборот, защита от этого воздействия), если это предмет, то его свойства должны также учитывать наличие этих типов взаимодействия
>>558391
Лично я столкнулся с очередным маняфантазированием в гд, вот сижу прикидываю через сколько дней сдохнет тред.
Лично я столкнулся с очередным маняфантазированием в гд, вот сижу прикидываю через сколько дней сдохнет тред.
>>558394
Ого, целых три дня. Не плохо. Я то думал уже сегодня вечером исчезнуть из треда
Ого, целых три дня. Не плохо. Я то думал уже сегодня вечером исчезнуть из треда
»558364
Почему у тебя "эффект" и "действие" - базовые объекты? Не кажется ли тебе оптимальным описать всевозможные взаимоидействия и эффекты внутри классов "игрок, враги" и "предметы", ты вообще с ООП знаком? Ну и рогалики, требущие .net - такое себе, конечно.
Почему у тебя "эффект" и "действие" - базовые объекты? Не кажется ли тебе оптимальным описать всевозможные взаимоидействия и эффекты внутри классов "игрок, враги" и "предметы", ты вообще с ООП знаком? Ну и рогалики, требущие .net - такое себе, конечно.
>>558396
Разве так не будет проще их переиспользовать?
Что будет в том случае, если классы игрок, враг или предмет должны будут иметь одинаковый эффект или действие? Дублировать код?
Вообще знаком, но критику с радостью приму. Будет круто, если ты чуть более подробно распишешь то, что я делаю не так, потому что сейчас я не понимаю в чем именно проблема. Мне всегда казалось, что ООП должен решать проблему переиспользуемости кода.
Согласен, но рогалик, это просто пет. проджект для изучения net, потому и такой стек технологий
>Почему у тебя "эффект" и "действие" - базовые объекты?
Разве так не будет проще их переиспользовать?
> Не кажется ли тебе оптимальным описать всевозможные взаимоидействия и эффекты внутри классов "игрок, враги" и "предметы"
Что будет в том случае, если классы игрок, враг или предмет должны будут иметь одинаковый эффект или действие? Дублировать код?
>ты вообще с ООП знаком?
Вообще знаком, но критику с радостью приму. Будет круто, если ты чуть более подробно распишешь то, что я делаю не так, потому что сейчас я не понимаю в чем именно проблема. Мне всегда казалось, что ООП должен решать проблему переиспользуемости кода.
>Ну и рогалики, требущие .net - такое себе, конечно.
Согласен, но рогалик, это просто пет. проджект для изучения net, потому и такой стек технологий
>>558398
И да, любой эффект может применять действие и любое действие может накладывать эффект. Поэтому они должны существовать как отдельные от всего сущности.
>Почему у тебя "эффект" и "действие" - базовые объекты?
>Разве так не будет проще их переиспользовать?
И да, любой эффект может применять действие и любое действие может накладывать эффект. Поэтому они должны существовать как отдельные от всего сущности.
>>558398
Юзай ECS
А вообще сделай тупой прототип за 2 дня, и там все подводные будет видно. Потом просто с нуля уже начнешь писать с необходимой архитектурой. Главное еще не переусложнять.
мимо
>если классы игрок, враг или предмет должны будут иметь одинаковый эффект или действие? Дублировать код?
>решать проблему переиспользуемости кода
Юзай ECS
А вообще сделай тупой прототип за 2 дня, и там все подводные будет видно. Потом просто с нуля уже начнешь писать с необходимой архитектурой. Главное еще не переусложнять.
мимо
Так, а вот и я.
>>558402
Спасибо, почитал, тема очень интересная, буду продолжать ее изучать. На хабре наткнулся на статью о том как ребята пилил свое решение и оттуда уже нашел еще несколько уже готовых библиотек, но но если все это начать подключать, то никакого фана не будет, поэтому попробую разобраться как это работает и реализую функционал сам.
>>558402
Спасибо, почитал, тема очень интересная, буду продолжать ее изучать. На хабре наткнулся на статью о том как ребята пилил свое решение и оттуда уже нашел еще несколько уже готовых библиотек, но но если все это начать подключать, то никакого фана не будет, поэтому попробую разобраться как это работает и реализую функционал сам.
216 Кб, 1931x460Сегодня за пару часов накидал небольшой проект с классами базовых объектов, картой и разными вспомогательными плюшками. Выглядит это сейчас так:
Писал с оглядкой на https://github.com/Chris3606/GoRogue , но мне он не очень пока нравится. Например, в классе Coord (Из названия понятно, что он призван облегчить нам работу с координатами) зачем-то используется Xna, который от майкрософта. Также по коду идет много оптимизаций и костылей, которые вроде как описаны и документированы, но все равно режут глаз. В общем, будем писать все свое.
Сейчас нужно немного переосмыслить то, что я тут наделал. Такое ощущение, что я хуйни написал.
По мне, ты слишком много внимания уделяешь архитектуре, классам и т.п. Ради чего всё это? Сама то игра у тебя в голове есть?
>>558398
А, ну тогда понятно. Но всё равно, даже практиковаться, имхо, лучше на том к чему есть хоть какие-то идеи и интерес.
>>558398
>рогалик, это просто пет. проджект для изучения net
А, ну тогда понятно. Но всё равно, даже практиковаться, имхо, лучше на том к чему есть хоть какие-то идеи и интерес.
>>562325
Есть и интерес и идеи. Обычные приложения пилить как раз намного более скучное дело, чем игру. Тем более, что мелкие приложения уже все запилены, а что-то более масштабное в одиночку просто не поднять. Тем более, что сам я страдаю уже несколько лет игровой импотенцией и мне всегда чего-то не хватало в играх.
Есть и интерес и идеи. Обычные приложения пилить как раз намного более скучное дело, чем игру. Тем более, что мелкие приложения уже все запилены, а что-то более масштабное в одиночку просто не поднять. Тем более, что сам я страдаю уже несколько лет игровой импотенцией и мне всегда чего-то не хватало в играх.
>>562325
И да, для меня написание всего этого - уже игра. Получаю удовольствие от построения архитектуры
>По мне, ты слишком много внимания уделяешь архитектуре, классам и т.п. Ради чего всё это?
И да, для меня написание всего этого - уже игра. Получаю удовольствие от построения архитектуры
>>562398
А что, нет?
У меня есть базовый класс "иди нахуй", в котором очень много витиеватого трёхэтажного кода, написанного много раз. Теперь, чтобы послать нахуй залётного ЕЦС-чушкана, мне достаточно просто сконструировать класс с инициализатором. И это всё одной строкой!
var посыл = ИдиНахуй.new(){КогоПослать = "ЕЦС-чушкан"}
Далее, если мне нужно плотно работать с чушканом (если он с первого раза не понял), я могу унаследоваться от базового класса:
class ИдиНахуйЕЦСЧушкан : ИдиНахуй { КогоПослать = "ЕЦС-чушкан" }
И далее, просто конструировать класс-потомок.
А что, нет?
У меня есть базовый класс "иди нахуй", в котором очень много витиеватого трёхэтажного кода, написанного много раз. Теперь, чтобы послать нахуй залётного ЕЦС-чушкана, мне достаточно просто сконструировать класс с инициализатором. И это всё одной строкой!
var посыл = ИдиНахуй.new(){КогоПослать = "ЕЦС-чушкан"}
Далее, если мне нужно плотно работать с чушканом (если он с первого раза не понял), я могу унаследоваться от базового класса:
class ИдиНахуйЕЦСЧушкан : ИдиНахуй { КогоПослать = "ЕЦС-чушкан" }
И далее, просто конструировать класс-потомок.
>>562448
Ничего себе, ты дажи класы с носледованием выучил. Кокой ты крутой прогромист.
Шучу, на самом деле твой пост детектит в тебе нюфаню.
Ничего себе, ты дажи класы с носледованием выучил. Кокой ты крутой прогромист.
Шучу, на самом деле твой пост детектит в тебе нюфаню.
>>562576
И да, добавлю: серебряной пули не существет. Не стоит толкать ООП туда где ему не место и наоборот, если проблема отлично решается средствами ООП, то почему бы его не применить?
И да, добавлю: серебряной пули не существет. Не стоит толкать ООП туда где ему не место и наоборот, если проблема отлично решается средствами ООП, то почему бы его не применить?
>>562397
Скрин из их инструмента для рисования
Скрин из их инструмента для рисования
>>558364
Ты просто движкописец. Видимо твоё призвание - писить движки
Ты просто движкописец. Видимо твоё призвание - писить движки
Движкописец в треде.
В общем, переосмыслил написанное ранее. Пришел к выводу, что нужно делать так:
1. Есть карта
2. На карте расположены ячейки (Cell) в виде двумерной сетки с координатами x и y соответственно
3. У каждой ячейки есть своя координата и массив объектов находящияхся в ней [в ячейке]
4. Каждый объект находящийся в ячейке может иметь метод Step, который, собственно и может реализовывать часть логики отвечающей за ход данного объекта
Переписал немного логику движка, и на базе всего этого собрал небольшую комнатку по стене которого ползет плотоядная плесень, а сам гг был замурован в углу этой комнаты, чтобы его не сожрали
На самом деле никого бы не сожрали, потому что плесень умеет только двигаться
В общем, переосмыслил написанное ранее. Пришел к выводу, что нужно делать так:
1. Есть карта
2. На карте расположены ячейки (Cell) в виде двумерной сетки с координатами x и y соответственно
3. У каждой ячейки есть своя координата и массив объектов находящияхся в ней [в ячейке]
4. Каждый объект находящийся в ячейке может иметь метод Step, который, собственно и может реализовывать часть логики отвечающей за ход данного объекта
Переписал немного логику движка, и на базе всего этого собрал небольшую комнатку по стене которого ползет плотоядная плесень, а сам гг был замурован в углу этой комнаты, чтобы его не сожрали
На самом деле никого бы не сожрали, потому что плесень умеет только двигаться
>>563596
Которая, кстати, реализована с помощью клеточного автомата: https://ru.wikipedia.org/wiki/Клеточный_автомат
>ползет плотоядная плесень
Которая, кстати, реализована с помощью клеточного автомата: https://ru.wikipedia.org/wiki/Клеточный_автомат
7 Кб, 225x192>>563601
Но сама логика автомата пока собрана из говна и палок. В итоге хотелось бы прийти к описательному формату типа пикрил
Но сама логика автомата пока собрана из говна и палок. В итоге хотелось бы прийти к описательному формату типа пикрил
>>563729
Если про код, то из моей головы. Так вижу решение проблемы описания правил для клеточного автомата. Решение не окончательное, конечно, а просто как пример. А скрин из какой-то онлайновой ide, чтобы подсветка кода была
Если про код, то из моей головы. Так вижу решение проблемы описания правил для клеточного автомата. Решение не окончательное, конечно, а просто как пример. А скрин из какой-то онлайновой ide, чтобы подсветка кода была
Ты это всё мутишь на С#? Блин, мне тоже интересна тема рогаликоварения, правда я начал с С++. Хотелось бы тоже обоюдный обмен опытом на стабильной основе запилить, дашь фейкомыло?
>>570398
Это сделать же можно через доп bool active, что то такое? чтобы в массив обработки степа добавлялись только обьекты с этим фрагом, и степпер обсчтиывал только их. А пуляться и забираться обьекты будут при их появлении/уничтожении. Не знаю как идея, расскажите о подводных
мимо-не-оп
Это сделать же можно через доп bool active, что то такое? чтобы в массив обработки степа добавлялись только обьекты с этим фрагом, и степпер обсчтиывал только их. А пуляться и забираться обьекты будут при их появлении/уничтожении. Не знаю как идея, расскажите о подводных
мимо-не-оп
>>570398
Нет, все объекты, которые можно будет степнуть в том числе регистрируются в специальном синглтон-хранилище, откуда я их переберу обычным циклом. В ячейках они регистрируются чтобы удобнее было делать потом выборку указав конкретную ячейку
Мимо ОП
>И потом, чтобы stepнуть все объекты, ты будешь перебирать все ячейки?
Нет, все объекты, которые можно будет степнуть в том числе регистрируются в специальном синглтон-хранилище, откуда я их переберу обычным циклом. В ячейках они регистрируются чтобы удобнее было делать потом выборку указав конкретную ячейку
Мимо ОП
Рад, что тред не умирает и даже кому-то интересен. У меня тут нужда небольшая в деньгах появилась и по вечерам шабашу. Как только закрою проект, так сразу продолжим кодить, а пока можно подумать над альтернативой регистрацией объекта в ячейку и отдельное хранилище. Мне кажется, что это не самый лучший способ
>>570391
Пиши в тред, друг. Здесь, если мы хуйни понарошку нас хоть люди поправят, но если очень хочется, то я позже заведу фейк и кину в тред
Оп
Пиши в тред, друг. Здесь, если мы хуйни понарошку нас хоть люди поправят, но если очень хочется, то я позже заведу фейк и кину в тред
Оп
>>570619
Объясню пока. Это скорее даже не костыль, а просто плохо масштабируемое решение. Если представить, что у нас появляются ещё какие-то критерии по которым мы бы хотели делать выборки, то сразу становится ясно, что ми по итогу просто будем перебирать каждый раз это самое общее хранилище. Непорядок.
>регистрацией объекта в ячейку и отдельное хранилище. Мне кажется, что это не самый лучший способ
Объясню пока. Это скорее даже не костыль, а просто плохо масштабируемое решение. Если представить, что у нас появляются ещё какие-то критерии по которым мы бы хотели делать выборки, то сразу становится ясно, что ми по итогу просто будем перебирать каждый раз это самое общее хранилище. Непорядок.
>>570623
Лишь бы ты не ищезал внезапно.
К слову, я смотрю ты филигранно расставляешь архитектуру игры, но у тебя есть концепт со стороны пользователя? Вот что он будет видеть?
Мне тоже интересна дико тема проработки архитектуры, правда пока-что не хватает умишка прорабатывать это всё. И твоя идея даже подожгла немного меня.
То есть допустим, несмотря на то, что у тебя шикарная идея, не понятно как это будет со стороны пользователя выглядеть, что ты хза игру создать хочешь, что за вселенную, чем там можно и нужно будет заниматься? Чем она будет увлекать? Насколько можно будет отождествляться со своим персонажем? (Как пример, тут Cogmind несмотря на всю свою эпичность механик, сильно проигрывает в связи с персонажем Cataclysm DDA, предполагаю, что причина тому совершенно ни на что не похожий мир, и персонаж, который представляется абстрактным роботом) Рогалики это довольно неординарная ветвь игр, но её основное требование, и в то же время преимущество, это то, что здесь можно невозбранно экспериментировать с механиками, структурой мира, ядром игры и прочим. Создавать по-настоящему симулятивные программы. Очень хороший пример это Дварф Фортресс.
Я лично, хотел бы поэкспериментировать с механом магически/псионических способностей (совсем не в том виде, в котором их видит фентези), или с механом повреждения и модификации человека. Тобишь все органы работют, всё можно при определённых условиях заменить (и не только на бионические протезы). Но это пока просто маняфантазии
Я хотел получить почту, или что-нибудь еще (телегу дискорд или тому подобное) чтобы более оперативно общаться на эту тему.
Лишь бы ты не ищезал внезапно.
К слову, я смотрю ты филигранно расставляешь архитектуру игры, но у тебя есть концепт со стороны пользователя? Вот что он будет видеть?
Мне тоже интересна дико тема проработки архитектуры, правда пока-что не хватает умишка прорабатывать это всё. И твоя идея даже подожгла немного меня.
То есть допустим, несмотря на то, что у тебя шикарная идея, не понятно как это будет со стороны пользователя выглядеть, что ты хза игру создать хочешь, что за вселенную, чем там можно и нужно будет заниматься? Чем она будет увлекать? Насколько можно будет отождествляться со своим персонажем? (Как пример, тут Cogmind несмотря на всю свою эпичность механик, сильно проигрывает в связи с персонажем Cataclysm DDA, предполагаю, что причина тому совершенно ни на что не похожий мир, и персонаж, который представляется абстрактным роботом) Рогалики это довольно неординарная ветвь игр, но её основное требование, и в то же время преимущество, это то, что здесь можно невозбранно экспериментировать с механиками, структурой мира, ядром игры и прочим. Создавать по-настоящему симулятивные программы. Очень хороший пример это Дварф Фортресс.
Я лично, хотел бы поэкспериментировать с механом магически/псионических способностей (совсем не в том виде, в котором их видит фентези), или с механом повреждения и модификации человека. Тобишь все органы работют, всё можно при определённых условиях заменить (и не только на бионические протезы). Но это пока просто маняфантазии
Я хотел получить почту, или что-нибудь еще (телегу дискорд или тому подобное) чтобы более оперативно общаться на эту тему.
142 Кб, 800x800>>570652
На самом деле о геймплее очень рано заводить речь. Будет так: у меня есть ряд технологий, которые мне сейчас интересно освоить. Это и клеточные автоматы, и ии (ml.net), и скриптовые языки внутри приложения. И как будет запилен некий набор функций, я его облачу в геймплей в сеттинге «самосборка». С таким подходом модно будет даже попробовать поэкспериментировать с геймплеем, используя пикрил архитектуру
На самом деле о геймплее очень рано заводить речь. Будет так: у меня есть ряд технологий, которые мне сейчас интересно освоить. Это и клеточные автоматы, и ии (ml.net), и скриптовые языки внутри приложения. И как будет запилен некий набор функций, я его облачу в геймплей в сеттинге «самосборка». С таким подходом модно будет даже попробовать поэкспериментировать с геймплеем, используя пикрил архитектуру
>>570950
Кстати я тоже маняфантазировал, как бы самосбор выглядел в рогалике.
Я думаю что это всё должно так или ниаче паралельно идти. Потому что вдруг ты сочтёшь нужным применить какую-нибудь геймплейную механику, а у тебя тех возможности не будет нормальной, и придётся пилить это через костыли, или вообще отказаться от этой идеи.
Кстати, я в этой теме далеко не ведающий, пояснить как ты будет машин лёрнинг использовать?
Как можно расшифровать пикрил?
К слову, как у тебя будет карта реализована? стандартным нетхаковским методом? (одна карта на весь экран, каждый z уровень отдельно, а не является 3д структурой), или как в том же катаклизме? (герой в центре бесшовной карты, а z уровни являются частью игры (хотя конечно в кате с я уровнями проблема ебанутая, там вообще их по сути нету, но кит исправился во второй части. И забросил её.))
И как ты видишь Самосбор рогалик? Как выживастик? Или как симуляцию, где @ должен будет существовать?
Кстати я тоже маняфантазировал, как бы самосбор выглядел в рогалике.
Я думаю что это всё должно так или ниаче паралельно идти. Потому что вдруг ты сочтёшь нужным применить какую-нибудь геймплейную механику, а у тебя тех возможности не будет нормальной, и придётся пилить это через костыли, или вообще отказаться от этой идеи.
Кстати, я в этой теме далеко не ведающий, пояснить как ты будет машин лёрнинг использовать?
Как можно расшифровать пикрил?
К слову, как у тебя будет карта реализована? стандартным нетхаковским методом? (одна карта на весь экран, каждый z уровень отдельно, а не является 3д структурой), или как в том же катаклизме? (герой в центре бесшовной карты, а z уровни являются частью игры (хотя конечно в кате с я уровнями проблема ебанутая, там вообще их по сути нету, но кит исправился во второй части. И забросил её.))
И как ты видишь Самосбор рогалик? Как выживастик? Или как симуляцию, где @ должен будет существовать?
>>571030
Если для описания игровой логики (геймплея) мне чего-то не хватает и приходится городить костыли, значит я что-то сделал неправильно и нужно будет это исправлять, а не городить костыли. Цель - не конечный результат, а скорее увлекательный процесс написания и проектирования движка.
майкрософт выпустили библиотеку для машинлернинга, которая может встраиваться в .net приложения с минимальной болью, считай просто из коробки. Применений можно придумать много, но все это будет понятно, когда я начну ее изучать.
https://metanit.com/sharp/mvc5/23.1.php
Там все доступно рассказнно.
У меня пока это просто 2д сетка, по которой перемещаются игровые объекты. Она не бесконечная.
Во всех рогаликах, что я играл, мне не хватало "глубины" погружения. Создавалось впечатление каких-то пластмассовых, заскриптованых декораций, по которым бродит персонаж. По задумке, все функции, которые я реализую, должны каким-то образом комбинироваться порождая огромное число разных механик. Конечно, все это может вырости в неуправляемую хуету, но так даже интереснее. В общем, будет некий, существующий по своим внутренним законам мир, а персонаж просто будет по нему бегать.
>Я думаю что это всё должно так или ниаче паралельно идти. Потому что вдруг ты сочтёшь нужным применить какую-нибудь геймплейную механику, а у тебя тех возможности не будет нормальной, и придётся пилить это через костыли, или вообще отказаться от этой идеи.
Если для описания игровой логики (геймплея) мне чего-то не хватает и приходится городить костыли, значит я что-то сделал неправильно и нужно будет это исправлять, а не городить костыли. Цель - не конечный результат, а скорее увлекательный процесс написания и проектирования движка.
>пояснить как ты будет машин лёрнинг использовать
майкрософт выпустили библиотеку для машинлернинга, которая может встраиваться в .net приложения с минимальной болью, считай просто из коробки. Применений можно придумать много, но все это будет понятно, когда я начну ее изучать.
>Как можно расшифровать пикрил?
https://metanit.com/sharp/mvc5/23.1.php
Там все доступно рассказнно.
>К слову, как у тебя будет карта реализована? стандартным нетхаковским методом?
У меня пока это просто 2д сетка, по которой перемещаются игровые объекты. Она не бесконечная.
>И как ты видишь Самосбор рогалик? Как выживастик? Или как симуляцию, где @ должен будет существовать?
Во всех рогаликах, что я играл, мне не хватало "глубины" погружения. Создавалось впечатление каких-то пластмассовых, заскриптованых декораций, по которым бродит персонаж. По задумке, все функции, которые я реализую, должны каким-то образом комбинироваться порождая огромное число разных механик. Конечно, все это может вырости в неуправляемую хуету, но так даже интереснее. В общем, будет некий, существующий по своим внутренним законам мир, а персонаж просто будет по нему бегать.
>>571140
Галочка
Галочка
>>571140
Тобишь ты будешь потом перепиливать всё?
Насколько я знаю, машин лёрнинг пока можно обучать в очень узких специальностях. Может быть можно написать площадку с группой юинтов А, и одним юнитом Б, и их обучать убиению друг друга, тренируя pathfinding и стратегию, хотя я честно не уверен насколько это возможно.
Еще можно натренировать чтобы локации генерировались более интересным образом.
Еще были маняидеи насчёт написания StoryTeller'a, грубо говоря бота рассказчика, который бы формировал текст путешествия в форме логов, но при этом учитывая огромное количество переменных, или может даже меня окружение/квесты.
Это конечно да, не спорю...
Вот в этом проблема уже есть, в плане того, что у тебя так или иначе должно быть понимание как всё работает, и должна быть единая система, полностью изначально расписанная.
К слову, чего пишешь сейчас там? Интересно узнать как сама разработка происходит.
>У меня пока это просто 2д сетка, по которой перемещаются игровые объекты. Она не бесконечная.
Тобишь ты будешь потом перепиливать всё?
>майкрософт выпустили библиотеку для машинлернинга, которая может встраиваться в .net приложения с минимальной болью, считай просто из коробки. Применений можно придумать много, но все это будет понятно, когда я начну ее изучать.
Насколько я знаю, машин лёрнинг пока можно обучать в очень узких специальностях. Может быть можно написать площадку с группой юинтов А, и одним юнитом Б, и их обучать убиению друг друга, тренируя pathfinding и стратегию, хотя я честно не уверен насколько это возможно.
Еще можно натренировать чтобы локации генерировались более интересным образом.
Еще были маняидеи насчёт написания StoryTeller'a, грубо говоря бота рассказчика, который бы формировал текст путешествия в форме логов, но при этом учитывая огромное количество переменных, или может даже меня окружение/квесты.
>Во всех рогаликах, что я играл, мне не хватало "глубины" погружения. Создавалось впечатление каких-то пластмассовых, заскриптованых декораций, по которым бродит персонаж.
Это конечно да, не спорю...
>По задумке, все функции, которые я реализую, должны каким-то образом комбинироваться порождая огромное число разных механик.
Вот в этом проблема уже есть, в плане того, что у тебя так или иначе должно быть понимание как всё работает, и должна быть единая система, полностью изначально расписанная.
К слову, чего пишешь сейчас там? Интересно узнать как сама разработка происходит.
>>571236
Если текущее решение не будет меня устраивать - конечно. Проблемы в этом никакой нет, ведь с каждым разом должно получаться все лучше и лучше
Расписал крупноблочно (на высоком уровне абстракции так сказатб) чтобы определиться с направлением. Сейчас идет этап исследования, когда я просто экспериментирую. Обычно после этого этапа требования и уточняются.
Сейчас работаю над другими проектами (за которые мне платят), а рогалик, это домашний проект, который получается все оставшееся время (которого пока нет). Поэтому пока ничего нового показать не смогу
>Тобишь ты будешь потом перепиливать всё?
Если текущее решение не будет меня устраивать - конечно. Проблемы в этом никакой нет, ведь с каждым разом должно получаться все лучше и лучше
>Вот в этом проблема уже есть, в плане того, что у тебя так или иначе должно быть понимание как всё работает, и должна быть единая система, полностью изначально расписанная.
Расписал крупноблочно (на высоком уровне абстракции так сказатб) чтобы определиться с направлением. Сейчас идет этап исследования, когда я просто экспериментирую. Обычно после этого этапа требования и уточняются.
>К слову, чего пишешь сейчас там? Интересно узнать как сама разработка происходит.
Сейчас работаю над другими проектами (за которые мне платят), а рогалик, это домашний проект, который получается все оставшееся время (которого пока нет). Поэтому пока ничего нового показать не смогу
>>571307
Да, ты писал уже об этом. Ну буду мониторить тебя. К слову, може ты на гитхаб зальёшь исходники, или как-нибудь еще рашшеришь? Мне интересно посмотреть исходники
Да, ты писал уже об этом. Ну буду мониторить тебя. К слову, може ты на гитхаб зальёшь исходники, или как-нибудь еще рашшеришь? Мне интересно посмотреть исходники
>>571333
Да, так позже и сделаю.
Да, так позже и сделаю.
>>572060
Работу работаю. Абу мне не платит за этот тред и приходится зарабатывать работая на дядю. Так что давай запасемся терпением лучше.
Работу работаю. Абу мне не платит за этот тред и приходится зарабатывать работая на дядю. Так что давай запасемся терпением лучше.
>>572114
ты сюда время от времени хотя бы измышления свои вываливай, может думки по механикам и архитекртуре там.
ты сюда время от времени хотя бы измышления свои вываливай, может думки по механикам и архитекртуре там.
>>572302
Ааа, ладно. Завтра планирую новый рогалик начать писать, ибо мне не очень понравилось как я реализовал предыдущий, хоть и много всего сделал, если вам будет интересно может буду показывать свои результаты, не знаю.
Ааа, ладно. Завтра планирую новый рогалик начать писать, ибо мне не очень понравилось как я реализовал предыдущий, хоть и много всего сделал, если вам будет интересно может буду показывать свои результаты, не знаю.
>>572313
А что у тебя за рогалик? И почему ты решил остановиться? Что не так было с предыдущим? Какая там архитектура была?
А что у тебя за рогалик? И почему ты решил остановиться? Что не так было с предыдущим? Какая там архитектура была?
>>572314
Вообще читая тред я наверное осознал какой простой у меня рогалик, ибо у меня все как то намного проще получилось, да и вообще зашкварно или нет, но я его писал на lua, думаю может на c++ попробовать, хз. Ну вообще рогалик как рогалик получился, графика тайловая, в папке с игрой лежит тайлсет чтоб каждый мог изменять его, над генерацией я не сильно заморачивался, думал и пытался реализовать чтоб были подземелья, комнаты все такое, а в итоге получился генератор пещеры, ну я и решил оставить ибо выглядело неплохо. Игра очень сложная, мобы живут своей жизнью, размножаются, игрок может свой мини домик построить. 10 класс и 10 рас, в общем довольно много сделал, долго объяснять) Но как то мне он не нравится, по этому планирую новый рогалик с опорой на реализм в механике боевки, типа можем атаковать любую часть тела моба, моб будет погибать от тяжёлых ран или от потери крови, скиллы прокачиваются взависимости от того, что ты делаешь, в общем наверное как то так, ух, многовато как то я написал.
Вообще читая тред я наверное осознал какой простой у меня рогалик, ибо у меня все как то намного проще получилось, да и вообще зашкварно или нет, но я его писал на lua, думаю может на c++ попробовать, хз. Ну вообще рогалик как рогалик получился, графика тайловая, в папке с игрой лежит тайлсет чтоб каждый мог изменять его, над генерацией я не сильно заморачивался, думал и пытался реализовать чтоб были подземелья, комнаты все такое, а в итоге получился генератор пещеры, ну я и решил оставить ибо выглядело неплохо. Игра очень сложная, мобы живут своей жизнью, размножаются, игрок может свой мини домик построить. 10 класс и 10 рас, в общем довольно много сделал, долго объяснять) Но как то мне он не нравится, по этому планирую новый рогалик с опорой на реализм в механике боевки, типа можем атаковать любую часть тела моба, моб будет погибать от тяжёлых ран или от потери крови, скиллы прокачиваются взависимости от того, что ты делаешь, в общем наверное как то так, ух, многовато как то я написал.
>>572317
Неплохо. Мне казалось фундамент так или иначе нужно будет закладывать на С++, или С#. Я просто начал плюски задрачивать, потому и выбрал их. А ОП о-очень интересные идеи в плане архитектуры подаёт. С заделом на будущее.
Идея написать полное и гибкое ядро на спп допустим, а остальной контент и функционал пилить на том же луа, или питоне. Как по мне, так это довольно интересная задумка, которая позволит создать универсальный движок для рогаликов. Но это конечно надо тщательно прорабатывать архитекртуру, и обдрачиваться предиктивностью. И тут конечно вопрос оптимизации опять вылезет. Хоть рогалик и игра пошаговая, о работать она тоже быстро по-своему должна.
Неплохо. Мне казалось фундамент так или иначе нужно будет закладывать на С++, или С#. Я просто начал плюски задрачивать, потому и выбрал их. А ОП о-очень интересные идеи в плане архитектуры подаёт. С заделом на будущее.
Идея написать полное и гибкое ядро на спп допустим, а остальной контент и функционал пилить на том же луа, или питоне. Как по мне, так это довольно интересная задумка, которая позволит создать универсальный движок для рогаликов. Но это конечно надо тщательно прорабатывать архитекртуру, и обдрачиваться предиктивностью. И тут конечно вопрос оптимизации опять вылезет. Хоть рогалик и игра пошаговая, о работать она тоже быстро по-своему должна.
>>572319
Круто, в общем завтра скину скриншот рогалика который получился, а сейчас спать, удачи :3
Круто, в общем завтра скину скриншот рогалика который получился, а сейчас спать, удачи :3
14 Кб, 734x255Так. Сейчас попробуем порассуждать на тему юнитов и принятых ими решений.
Представим, что существует некая условная йоба (человек, дрон, плотоядная плесень, лужа йоба-слизи). Вокруг йобы представлен мир, а у самой йобы имеются некие сенсоры, позволяющие получать информацию из этого самого мира. Если это человек, то в роли сенсоров могут выступать глаза, уши, нос. Если это плесень, то она может получать только информацию о том, что находится в тех клетках где она распространена и немного рядом (те клетки, с которыми она соприкасается). Так как время в игре квантовано (разделено на шаги) очевидно, что каждый ход юнит должен просто анализировать полученную им информацию и выдавать своему телу или чему-то еще команду.
На пике максимум упрощенно показано то, что я сейчас проговорил.
Из чего по итогу состоит юнит:
1. "сенсоры" собирающие данные об окружающем мире и самом юните (например, сенсор отвечающий за чувство голода)
2. модульное тело, каждая часть которого может иметь свои уникальные функции
3. черный ящик принимающий решения и отдающий команды модулям тела
Далее о черном ящике. Сам он должен быть также модульным, (модуль клеточного автомата, модуль ИИ). Даже не один модуль, а целая цепочка, если так как универсальный ИИ создать будет для меня практически невозможно, а вот ИИ отвечающий за какую-то определенну. функцию - легко.
Вообще, по задумке, внутри ящика будет существовать некий объект со внутренней информацией (некий scope, в котором будет храниться также контекст (дополнительная информация))
Вот такие размышления. Добавлю, что все, что я буду разрабатывать для черного ящика, также будет использоваться мной уже в других проектах. По крайней мере очень хотелось бы.
ваш ОП
Представим, что существует некая условная йоба (человек, дрон, плотоядная плесень, лужа йоба-слизи). Вокруг йобы представлен мир, а у самой йобы имеются некие сенсоры, позволяющие получать информацию из этого самого мира. Если это человек, то в роли сенсоров могут выступать глаза, уши, нос. Если это плесень, то она может получать только информацию о том, что находится в тех клетках где она распространена и немного рядом (те клетки, с которыми она соприкасается). Так как время в игре квантовано (разделено на шаги) очевидно, что каждый ход юнит должен просто анализировать полученную им информацию и выдавать своему телу или чему-то еще команду.
На пике максимум упрощенно показано то, что я сейчас проговорил.
Из чего по итогу состоит юнит:
1. "сенсоры" собирающие данные об окружающем мире и самом юните (например, сенсор отвечающий за чувство голода)
2. модульное тело, каждая часть которого может иметь свои уникальные функции
3. черный ящик принимающий решения и отдающий команды модулям тела
Далее о черном ящике. Сам он должен быть также модульным, (модуль клеточного автомата, модуль ИИ). Даже не один модуль, а целая цепочка, если так как универсальный ИИ создать будет для меня практически невозможно, а вот ИИ отвечающий за какую-то определенну. функцию - легко.
Вообще, по задумке, внутри ящика будет существовать некий объект со внутренней информацией (некий scope, в котором будет храниться также контекст (дополнительная информация))
Вот такие размышления. Добавлю, что все, что я буду разрабатывать для черного ящика, также будет использоваться мной уже в других проектах. По крайней мере очень хотелось бы.
ваш ОП
>>572335
Там же будет какой-нибудь скриптовый язык, чтобы можно было написать логику просто руками. Например, lisp (интерпретатор которого мы напишем сами, конечно же)
>(модуль клеточного автомата, модуль ИИ)
Там же будет какой-нибудь скриптовый язык, чтобы можно было написать логику просто руками. Например, lisp (интерпретатор которого мы напишем сами, конечно же)
>>572325
Я сам хз, но по идее для простых рогаликов подойдёт ченить высокоуровневое, сам юзаю OpenGL в самой простой вариации(шэйдеры и массивы примитивов для координат квада) потому что по-другому никак.
Если не охота байтоебить можно начать с Love2D какого-нибудь.
Я сам хз, но по идее для простых рогаликов подойдёт ченить высокоуровневое, сам юзаю OpenGL в самой простой вариации(шэйдеры и массивы примитивов для координат квада) потому что по-другому никак.
Если не охота байтоебить можно начать с Love2D какого-нибудь.
>>572351
Любая достаточно сложная программа на C или Фортране содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp (Филип Гринспен)
А если по существу, то так и воткну. Это же скриптовый язык. Для него лишь необходим так называемый интерпретатор, который в свою очередь может быть написан на чем угодно (уже написан почти на всем, на чем только можно, в том числе c#)
Любая достаточно сложная программа на C или Фортране содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp (Филип Гринспен)
А если по существу, то так и воткну. Это же скриптовый язык. Для него лишь необходим так называемый интерпретатор, который в свою очередь может быть написан на чем угодно (уже написан почти на всем, на чем только можно, в том числе c#)
>>572452
Как-то слабовато получилось
Как-то слабовато получилось
Спасибо, Абу, почистил тред
>>572335
Ну в общих чертах это конечно очевидное описание. Вот скорее интересно, получается, каждый юнит будет получать каждый ход заного всю карту? как вообще будет представляться в уме ИИ всё пространство? Как информация будет интерпретироваться? Условно, для простого ИИ обычного импа-чухана, можно просто вложить тайлы препятствий, тайлы опасности и тайлы агрессивно-дружественных существ. Хотя каждый ход прогонять заного всё это, смысла особого нет, как по мне. Не оптимальненько. При этом тебе придётся либо писать каждому виду существ "модели" поведения, или же можно создать 1 модульный вид интеллекта, который будет ограничиваться "знаниями", которые у него имеются (а-ля флаги).
Еще к слову вопрос масштабируемости. будет ли у тебя идти "общий" просчёт всего, что находится за "пузырём"? Или же вне, мир будет замирать?
>>572343
Меня парит больше вопрос оптимизации, и кроссплатформенность, Можно и побайтоёбить, но немного, и чтобы не было слишком сложно, а-ля брейнфак бля, без фанатизма в общем.
>>572336
Чем тут Лисп от Луа отличается?
И меня постоянно почему-то парит то, что такие скриптовые языки будут невероятно медленные, по сравнению с компилированным кодом, и что им можно только давать простую логику. Но при этом желание сделать core игры так сказать на Сишке, а дописать механ на Луа довольно неслабо перевешивает.
Ну в общих чертах это конечно очевидное описание. Вот скорее интересно, получается, каждый юнит будет получать каждый ход заного всю карту? как вообще будет представляться в уме ИИ всё пространство? Как информация будет интерпретироваться? Условно, для простого ИИ обычного импа-чухана, можно просто вложить тайлы препятствий, тайлы опасности и тайлы агрессивно-дружественных существ. Хотя каждый ход прогонять заного всё это, смысла особого нет, как по мне. Не оптимальненько. При этом тебе придётся либо писать каждому виду существ "модели" поведения, или же можно создать 1 модульный вид интеллекта, который будет ограничиваться "знаниями", которые у него имеются (а-ля флаги).
Еще к слову вопрос масштабируемости. будет ли у тебя идти "общий" просчёт всего, что находится за "пузырём"? Или же вне, мир будет замирать?
>>572343
Меня парит больше вопрос оптимизации, и кроссплатформенность, Можно и побайтоёбить, но немного, и чтобы не было слишком сложно, а-ля брейнфак бля, без фанатизма в общем.
>>572336
Чем тут Лисп от Луа отличается?
И меня постоянно почему-то парит то, что такие скриптовые языки будут невероятно медленные, по сравнению с компилированным кодом, и что им можно только давать простую логику. Но при этом желание сделать core игры так сказать на Сишке, а дописать механ на Луа довольно неслабо перевешивает.
>>572324
К сожалению, не заморачивался над этим, и просто использовал Love 2D, там используется function love.draw(), что довольно все облегчает. В следующем моем посте, прикреплю уже скрины с тем моим рогаликом, о котором я писал.
К сожалению, не заморачивался над этим, и просто использовал Love 2D, там используется function love.draw(), что довольно все облегчает. В следующем моем посте, прикреплю уже скрины с тем моим рогаликом, о котором я писал.
Вот собственно тот рогалик о котором я писал:
1) скрин - меню,создание персонажа, выбор расы и класса. Sy - Satiety, Ka - Karma(в игре можно помолиться богу в сложной ситуации, и чем больше у тебя карма, тем больше шанс, что бог тебе поможет,кстати не все расы веруют в бога, типа есть расы атеисты)
2) скрин - сама игра, спрайты выполнены в размере 21x21, в папке с игрой находится tileset. справа открыт инвентарь, любая вещь имеет свой бафф, урон(если будешь кидать эту вещь во врага), вес и цена. На скрине мы видим торговца, масло на полу(на нем любой может подскользнуться и упасть), ловушки, статую,лестницы вниз и мобов.
3) скрин - игра как она выглядит на самом деле, то есть то, что игрок не сможет увидеть,ибо он видит только то. что в зоне его видимости. Есть 2 типа стен: целые и полуразрушенные. вторые игрок может сломать и руками, но -немного hp будет, либо любую стенку киркой, так же можно и строить стены, статуи, ковер и создать свой домик. Так же на скрине мы видим алтари.
4) скрин - вакханалия, я просто дал убить себя слизням, подождал много ходов и вот они размножились жестко, ибо эт слизни.
1) скрин - меню,создание персонажа, выбор расы и класса. Sy - Satiety, Ka - Karma(в игре можно помолиться богу в сложной ситуации, и чем больше у тебя карма, тем больше шанс, что бог тебе поможет,кстати не все расы веруют в бога, типа есть расы атеисты)
2) скрин - сама игра, спрайты выполнены в размере 21x21, в папке с игрой находится tileset. справа открыт инвентарь, любая вещь имеет свой бафф, урон(если будешь кидать эту вещь во врага), вес и цена. На скрине мы видим торговца, масло на полу(на нем любой может подскользнуться и упасть), ловушки, статую,лестницы вниз и мобов.
3) скрин - игра как она выглядит на самом деле, то есть то, что игрок не сможет увидеть,ибо он видит только то. что в зоне его видимости. Есть 2 типа стен: целые и полуразрушенные. вторые игрок может сломать и руками, но -немного hp будет, либо любую стенку киркой, так же можно и строить стены, статуи, ковер и создать свой домик. Так же на скрине мы видим алтари.
4) скрин - вакханалия, я просто дал убить себя слизням, подождал много ходов и вот они размножились жестко, ибо эт слизни.
>>572542
Забыл добавить, чтобы повысить карму, нужно кормить котиков) А еще они всегда за тобой ходят, убив котика ты получишь мясо, но -карма.
Забыл добавить, чтобы повысить карму, нужно кормить котиков) А еще они всегда за тобой ходят, убив котика ты получишь мясо, но -карма.
15 Кб, 645x741>>572542
А вот и мой тайлсет, кстати в игре могут заспавнится надписи, типа тех, кто был здесь до игрока, они выглядят очень неразборчиво, написанные кровью, мелом и тд(это генерируется) и фишка в том, что надпись может быть вообще выглядеть не понятно, типа HEL##O W##LD
А вот и мой тайлсет, кстати в игре могут заспавнится надписи, типа тех, кто был здесь до игрока, они выглядят очень неразборчиво, написанные кровью, мелом и тд(это генерируется) и фишка в том, что надпись может быть вообще выглядеть не понятно, типа HEL##O W##LD
Я тут тоже маняфантазиями балуюсь
- Отражать скованность персонажа (от одежды), оглушённость, и невозможность двигаться параметром от 0 да 100%. От громоздкой одежды повышается скованость, также как и от допустим захвата персонажа ручками. Скованость можно распрастраняться на отдельные части тела. "Нулём" можно считать базовую скорость/ловкость персонажа, который "условно" голый. 100 процентов, это полное обездвиживание той или иной части тела.
- Обработку STЕP (каждый ход) можно проводить добавляя в массив все активные объекты в "пузыре", активные объекты будут добавляться при инциализации баббла, а также при удалении или входе в него.
- Все сущности будут иметь физические и нефизические части тела, физические условно создают простой объект среды, коих будет много, на него можно влиять снаружи и он также может влиять. Имеет параметры, и методы воздействия, засчёт как единичных органов, так и комплексных систем, которые получают свой функцинал только когда будут собраны. (Опорной двигательная, пищеварение) Также будут иметься нефизические, вероятно они будут взаимозависимы от физических, и существовать только с помощью физических свойств. Допустим условная "разумность" это блок обработки ИИ, или передача контроля сущностью игроку, которая находится в мозге. Нефизическими могут также быть любые другие объекты, которые являются более абстрактными, и не поддающиммся непосредственному обнаружению в игре (не точно). Вопрос чем это будет, просто преписываемыми к частям тела параметрами (как например душа(ии или игрок) к мозгу). Или они будут занимать не локальную позицию (аки абстрактное количество "чакры" как из Наруто, или же имунная система)
- Любой предмет можно будет использовать для удара по цели, но без условных "знаний" или "перков навыка" удар будет стандартным образом, как если бы оружие не предполагало свойство атаковать им Сила удара будет зависеть от материала, веса, возможно обьема и силы атакующей сущности. Таким образом, чтобы использовать определённый предмет адекватным образом, нужно "знать" его работу. Возможно именно в этом ключе будут работать навыки и "перки", условные знания-умения, позволяющие так или иначе использовать предмет, извлекая из него дополнительную выгоду. Умения также могут древовидно развиваться иногда даже эволюционируя в допустим те же самые боевые искусства, которые технически, будут менять дефолтный метод взаимодействия предмета. В пример, НПС, у которого отсутствует знания об огнестреле, не сможет его использовать, а будет драться им в рукопашную. Все действия, которые можно совершить с предметом (кроме основных, типо стрельбы, или же можно даже это изменить, но выставить стрельбу как дефолтное первичное действие) будут скрыты в меню, которое открывается через R удобно будет выбрать вместо перезарядки r какое либо другое действие. В меню удара или перед атакой или стрельбой можно указывать цель на существе, но становится не понятно как действовать с целями нестандартной анатомии. Каждое существо имеет свою условную "оболочку", которая определяется мышцекостями, и служит ограничением по возможному объёму органов, будут иметься безопасный и максимальный уровни Это позволяет расхардкодить форму любого существа, позволяя менять его оболочку, или даже легко создавать существ прямо внутри игры (привет некромантия) Проблема остаётся при переопределение размеров органов. Изменение органических существ в основном будет производиться из-за мутаций (хотя кач мышц можно также учитывать, вкупе с фактом что сердце объём не меняет от этого), Тем самым изменять органы пропооционально.
- Вопрос организации активируемых способностей игрока. Технически, любое действие игрока, кроме заранее захардкоженых, можно считать активируемой способностью. Определяются и скалируются они из наличия знаний и имеющихся частей организма (бионика и мутации). То есть любая способность будет появляться только в случае, если сущность "знает" как пользоваться той или иной способностью. Из этого появляется вопрос о том, как же структурировать магию, которая технически, будет более комплексными способностями. В то же время, имеется желание отделить магическую систему от обычных способностей, при этом не создавая отдельный, захардкоженый, "висящий в воздухе" модуль.
- Отражать скованность персонажа (от одежды), оглушённость, и невозможность двигаться параметром от 0 да 100%. От громоздкой одежды повышается скованость, также как и от допустим захвата персонажа ручками. Скованость можно распрастраняться на отдельные части тела. "Нулём" можно считать базовую скорость/ловкость персонажа, который "условно" голый. 100 процентов, это полное обездвиживание той или иной части тела.
- Обработку STЕP (каждый ход) можно проводить добавляя в массив все активные объекты в "пузыре", активные объекты будут добавляться при инциализации баббла, а также при удалении или входе в него.
- Все сущности будут иметь физические и нефизические части тела, физические условно создают простой объект среды, коих будет много, на него можно влиять снаружи и он также может влиять. Имеет параметры, и методы воздействия, засчёт как единичных органов, так и комплексных систем, которые получают свой функцинал только когда будут собраны. (Опорной двигательная, пищеварение) Также будут иметься нефизические, вероятно они будут взаимозависимы от физических, и существовать только с помощью физических свойств. Допустим условная "разумность" это блок обработки ИИ, или передача контроля сущностью игроку, которая находится в мозге. Нефизическими могут также быть любые другие объекты, которые являются более абстрактными, и не поддающиммся непосредственному обнаружению в игре (не точно). Вопрос чем это будет, просто преписываемыми к частям тела параметрами (как например душа(ии или игрок) к мозгу). Или они будут занимать не локальную позицию (аки абстрактное количество "чакры" как из Наруто, или же имунная система)
- Любой предмет можно будет использовать для удара по цели, но без условных "знаний" или "перков навыка" удар будет стандартным образом, как если бы оружие не предполагало свойство атаковать им Сила удара будет зависеть от материала, веса, возможно обьема и силы атакующей сущности. Таким образом, чтобы использовать определённый предмет адекватным образом, нужно "знать" его работу. Возможно именно в этом ключе будут работать навыки и "перки", условные знания-умения, позволяющие так или иначе использовать предмет, извлекая из него дополнительную выгоду. Умения также могут древовидно развиваться иногда даже эволюционируя в допустим те же самые боевые искусства, которые технически, будут менять дефолтный метод взаимодействия предмета. В пример, НПС, у которого отсутствует знания об огнестреле, не сможет его использовать, а будет драться им в рукопашную. Все действия, которые можно совершить с предметом (кроме основных, типо стрельбы, или же можно даже это изменить, но выставить стрельбу как дефолтное первичное действие) будут скрыты в меню, которое открывается через R удобно будет выбрать вместо перезарядки r какое либо другое действие. В меню удара или перед атакой или стрельбой можно указывать цель на существе, но становится не понятно как действовать с целями нестандартной анатомии. Каждое существо имеет свою условную "оболочку", которая определяется мышцекостями, и служит ограничением по возможному объёму органов, будут иметься безопасный и максимальный уровни Это позволяет расхардкодить форму любого существа, позволяя менять его оболочку, или даже легко создавать существ прямо внутри игры (привет некромантия) Проблема остаётся при переопределение размеров органов. Изменение органических существ в основном будет производиться из-за мутаций (хотя кач мышц можно также учитывать, вкупе с фактом что сердце объём не меняет от этого), Тем самым изменять органы пропооционально.
- Вопрос организации активируемых способностей игрока. Технически, любое действие игрока, кроме заранее захардкоженых, можно считать активируемой способностью. Определяются и скалируются они из наличия знаний и имеющихся частей организма (бионика и мутации). То есть любая способность будет появляться только в случае, если сущность "знает" как пользоваться той или иной способностью. Из этого появляется вопрос о том, как же структурировать магию, которая технически, будет более комплексными способностями. В то же время, имеется желание отделить магическую систему от обычных способностей, при этом не создавая отдельный, захардкоженый, "висящий в воздухе" модуль.
Я тут тоже маняфантазиями балуюсь
- Отражать скованность персонажа (от одежды), оглушённость, и невозможность двигаться параметром от 0 да 100%. От громоздкой одежды повышается скованость, также как и от допустим захвата персонажа ручками. Скованость можно распрастраняться на отдельные части тела. "Нулём" можно считать базовую скорость/ловкость персонажа, который "условно" голый. 100 процентов, это полное обездвиживание той или иной части тела.
- Обработку STЕP (каждый ход) можно проводить добавляя в массив все активные объекты в "пузыре", активные объекты будут добавляться при инциализации баббла, а также при удалении или входе в него.
- Все сущности будут иметь физические и нефизические части тела, физические условно создают простой объект среды, коих будет много, на него можно влиять снаружи и он также может влиять. Имеет параметры, и методы воздействия, засчёт как единичных органов, так и комплексных систем, которые получают свой функцинал только когда будут собраны. (Опорной двигательная, пищеварение) Также будут иметься нефизические, вероятно они будут взаимозависимы от физических, и существовать только с помощью физических свойств. Допустим условная "разумность" это блок обработки ИИ, или передача контроля сущностью игроку, которая находится в мозге. Нефизическими могут также быть любые другие объекты, которые являются более абстрактными, и не поддающиммся непосредственному обнаружению в игре (не точно). Вопрос чем это будет, просто преписываемыми к частям тела параметрами (как например душа(ии или игрок) к мозгу). Или они будут занимать не локальную позицию (аки абстрактное количество "чакры" как из Наруто, или же имунная система)
- Любой предмет можно будет использовать для удара по цели, но без условных "знаний" или "перков навыка" удар будет стандартным образом, как если бы оружие не предполагало свойство атаковать им Сила удара будет зависеть от материала, веса, возможно обьема и силы атакующей сущности. Таким образом, чтобы использовать определённый предмет адекватным образом, нужно "знать" его работу. Возможно именно в этом ключе будут работать навыки и "перки", условные знания-умения, позволяющие так или иначе использовать предмет, извлекая из него дополнительную выгоду. Умения также могут древовидно развиваться иногда даже эволюционируя в допустим те же самые боевые искусства, которые технически, будут менять дефолтный метод взаимодействия предмета. В пример, НПС, у которого отсутствует знания об огнестреле, не сможет его использовать, а будет драться им в рукопашную. Все действия, которые можно совершить с предметом (кроме основных, типо стрельбы, или же можно даже это изменить, но выставить стрельбу как дефолтное первичное действие) будут скрыты в меню, которое открывается через R удобно будет выбрать вместо перезарядки r какое либо другое действие. В меню удара или перед атакой или стрельбой можно указывать цель на существе, но становится не понятно как действовать с целями нестандартной анатомии. Каждое существо имеет свою условную "оболочку", которая определяется мышцекостями, и служит ограничением по возможному объёму органов, будут иметься безопасный и максимальный уровни Это позволяет расхардкодить форму любого существа, позволяя менять его оболочку, или даже легко создавать существ прямо внутри игры (привет некромантия) Проблема остаётся при переопределение размеров органов. Изменение органических существ в основном будет производиться из-за мутаций (хотя кач мышц можно также учитывать, вкупе с фактом что сердце объём не меняет от этого), Тем самым изменять органы пропооционально.
- Вопрос организации активируемых способностей игрока. Технически, любое действие игрока, кроме заранее захардкоженых, можно считать активируемой способностью. Определяются и скалируются они из наличия знаний и имеющихся частей организма (бионика и мутации). То есть любая способность будет появляться только в случае, если сущность "знает" как пользоваться той или иной способностью. Из этого появляется вопрос о том, как же структурировать магию, которая технически, будет более комплексными способностями. В то же время, имеется желание отделить магическую систему от обычных способностей, при этом не создавая отдельный, захардкоженый, "висящий в воздухе" модуль.
- Отражать скованность персонажа (от одежды), оглушённость, и невозможность двигаться параметром от 0 да 100%. От громоздкой одежды повышается скованость, также как и от допустим захвата персонажа ручками. Скованость можно распрастраняться на отдельные части тела. "Нулём" можно считать базовую скорость/ловкость персонажа, который "условно" голый. 100 процентов, это полное обездвиживание той или иной части тела.
- Обработку STЕP (каждый ход) можно проводить добавляя в массив все активные объекты в "пузыре", активные объекты будут добавляться при инциализации баббла, а также при удалении или входе в него.
- Все сущности будут иметь физические и нефизические части тела, физические условно создают простой объект среды, коих будет много, на него можно влиять снаружи и он также может влиять. Имеет параметры, и методы воздействия, засчёт как единичных органов, так и комплексных систем, которые получают свой функцинал только когда будут собраны. (Опорной двигательная, пищеварение) Также будут иметься нефизические, вероятно они будут взаимозависимы от физических, и существовать только с помощью физических свойств. Допустим условная "разумность" это блок обработки ИИ, или передача контроля сущностью игроку, которая находится в мозге. Нефизическими могут также быть любые другие объекты, которые являются более абстрактными, и не поддающиммся непосредственному обнаружению в игре (не точно). Вопрос чем это будет, просто преписываемыми к частям тела параметрами (как например душа(ии или игрок) к мозгу). Или они будут занимать не локальную позицию (аки абстрактное количество "чакры" как из Наруто, или же имунная система)
- Любой предмет можно будет использовать для удара по цели, но без условных "знаний" или "перков навыка" удар будет стандартным образом, как если бы оружие не предполагало свойство атаковать им Сила удара будет зависеть от материала, веса, возможно обьема и силы атакующей сущности. Таким образом, чтобы использовать определённый предмет адекватным образом, нужно "знать" его работу. Возможно именно в этом ключе будут работать навыки и "перки", условные знания-умения, позволяющие так или иначе использовать предмет, извлекая из него дополнительную выгоду. Умения также могут древовидно развиваться иногда даже эволюционируя в допустим те же самые боевые искусства, которые технически, будут менять дефолтный метод взаимодействия предмета. В пример, НПС, у которого отсутствует знания об огнестреле, не сможет его использовать, а будет драться им в рукопашную. Все действия, которые можно совершить с предметом (кроме основных, типо стрельбы, или же можно даже это изменить, но выставить стрельбу как дефолтное первичное действие) будут скрыты в меню, которое открывается через R удобно будет выбрать вместо перезарядки r какое либо другое действие. В меню удара или перед атакой или стрельбой можно указывать цель на существе, но становится не понятно как действовать с целями нестандартной анатомии. Каждое существо имеет свою условную "оболочку", которая определяется мышцекостями, и служит ограничением по возможному объёму органов, будут иметься безопасный и максимальный уровни Это позволяет расхардкодить форму любого существа, позволяя менять его оболочку, или даже легко создавать существ прямо внутри игры (привет некромантия) Проблема остаётся при переопределение размеров органов. Изменение органических существ в основном будет производиться из-за мутаций (хотя кач мышц можно также учитывать, вкупе с фактом что сердце объём не меняет от этого), Тем самым изменять органы пропооционально.
- Вопрос организации активируемых способностей игрока. Технически, любое действие игрока, кроме заранее захардкоженых, можно считать активируемой способностью. Определяются и скалируются они из наличия знаний и имеющихся частей организма (бионика и мутации). То есть любая способность будет появляться только в случае, если сущность "знает" как пользоваться той или иной способностью. Из этого появляется вопрос о том, как же структурировать магию, которая технически, будет более комплексными способностями. В то же время, имеется желание отделить магическую систему от обычных способностей, при этом не создавая отдельный, захардкоженый, "висящий в воздухе" модуль.
>>572678
Ты это кому?
Ты это кому?
Вечер в хату. Не знаю, будет ли галка, но это я - ОП
Проект на c# успешно загнулся, но оставил за собой не мало опыта. Теперь мы возьмем этот опыт и запилим второй проект, но уже на typescript
Проект на c# успешно загнулся, но оставил за собой не мало опыта. Теперь мы возьмем этот опыт и запилим второй проект, но уже на typescript
>>606594
Из прошлого проекта мы должны взять все лучшее, а именно - клеточные автоматы. Но на этот раз правила для них будут писаться не руками, а генерироваться. Возникла идея отображения характеристик и свойств объектов некой n-мерной плоскостью, по которой эти клеточные автоматы и будут передвигаться. Непонятно, конечно, как это будет выглядеть, но в голове представить это себе я могу.
Из прошлого проекта мы должны взять все лучшее, а именно - клеточные автоматы. Но на этот раз правила для них будут писаться не руками, а генерироваться. Возникла идея отображения характеристик и свойств объектов некой n-мерной плоскостью, по которой эти клеточные автоматы и будут передвигаться. Непонятно, конечно, как это будет выглядеть, но в голове представить это себе я могу.
>>606594
Поставь в браузер куки-экспортер и носи свои куки с собой.
> Не знаю, будет ли галка, но это я - ОП
Поставь в браузер куки-экспортер и носи свои куки с собой.
>>607117
Потому что изначально все начиналось как пет проджект для обучения сишарпу. Сишарп был выучен, работа для которой он учился выполнена и я снова вернулся на старые рельсы фронтенд разработки, а там typescript и вот это вот все. На самом деле продолжил бы, но что-то мне не очень понравилось. Не хочу лезть в c# пока дальше.
Потому что изначально все начиналось как пет проджект для обучения сишарпу. Сишарп был выучен, работа для которой он учился выполнена и я снова вернулся на старые рельсы фронтенд разработки, а там typescript и вот это вот все. На самом деле продолжил бы, но что-то мне не очень понравилось. Не хочу лезть в c# пока дальше.
>>607288
Назови хоть один успешный проект на сиришотке, кроме ебучего KSP, которое даже на топовом железе умудряется тормозить?
Назови хоть один успешный проект на сиришотке, кроме ебучего KSP, которое даже на топовом железе умудряется тормозить?
>>607292
А чем мы успех измеряем? В компании где я работаю, на c# вполне приличный спрос. И продукты написанные на нем продаются. Или ты намекаешь на низкую производительность?
А чем мы успех измеряем? В компании где я работаю, на c# вполне приличный спрос. И продукты написанные на нем продаются. Или ты намекаешь на низкую производительность?
>>607292
Играл на 2 ядра-2гига, чет нихуя не тормозило.
>которое даже на топовом железе умудряется тормозить
Играл на 2 ядра-2гига, чет нихуя не тормозило.
7 Кб, 236x223>>606599
Зря бросил прошлый проект на с#, по второму кругу делать будет уже не так интересно + потеряется былой энтузиазм после пары недель. Выглядело между прочем не плохо, подкрутить механики, ui, и вот уже альфа рогалика готова, эх.... анон, анонович...
Зря бросил прошлый проект на с#, по второму кругу делать будет уже не так интересно + потеряется былой энтузиазм после пары недель. Выглядело между прочем не плохо, подкрутить механики, ui, и вот уже альфа рогалика готова, эх.... анон, анонович...
>>607298
Да брось, во второй раз будет еще лучше. Тогда по сути написание кода заняло в общем всего пару дней. Остальное, это размышления, которые прекрасно лягут и по второму кругу.
Да брось, во второй раз будет еще лучше. Тогда по сути написание кода заняло в общем всего пару дней. Остальное, это размышления, которые прекрасно лягут и по второму кругу.
>>607302
Ох ёёёёёё, только заметил дату создания треда, R.I.P в общем.
Ох ёёёёёё, только заметил дату создания треда, R.I.P в общем.
Не совсем ведаю за typescript. Рзве о подойдёт для того чтобы написать более-менее оптимизированный рогуль?
>>607362
Нет, конечно. Это говно очевидно будет безбожно глючить, как и любое приложение на js. Оп, наверное, подался в корпоративные рабы, вот и учит тайпскрипт.
Нет, конечно. Это говно очевидно будет безбожно глючить, как и любое приложение на js. Оп, наверное, подался в корпоративные рабы, вот и учит тайпскрипт.
>>607362
тайпскрипт это джаваскрипт в который добавили минимальную поддержку типов и свою собственную обёртку над прототипами ака классы помимо той что есть в последней версии джаваскрипта
в джаваскрипте ты можешь написать практически всё, я например хочу следующим проектом написать приложение для мобилок для сочинения электронной музыки лол
не очень сложное правда, все-таки поддержка звука в рн не оч.
а тем более игру, рогалик или простой платформер можно без либ, хотя где тайпскрипт там обычно ещё и фреймворк есть
мимо воннаби фронтэндер
тайпскрипт это джаваскрипт в который добавили минимальную поддержку типов и свою собственную обёртку над прототипами ака классы помимо той что есть в последней версии джаваскрипта
в джаваскрипте ты можешь написать практически всё, я например хочу следующим проектом написать приложение для мобилок для сочинения электронной музыки лол
не очень сложное правда, все-таки поддержка звука в рн не оч.
а тем более игру, рогалик или простой платформер можно без либ, хотя где тайпскрипт там обычно ещё и фреймворк есть
мимо воннаби фронтэндер
>>607367
скажет начальник что будешь использовать тайпскрипт значит будешь, не скажет тебя никто не заставляет
скажет начальник что будешь использовать тайпскрипт значит будешь, не скажет тебя никто не заставляет
>>607371
Ну это понятно, но как сказано выше, встаёт вопрос чисто оптимизации всего этого дела. жоваскрипт жеж.
Ну это понятно, но как сказано выше, встаёт вопрос чисто оптимизации всего этого дела. жоваскрипт жеж.
>>607377
ты гониш шоле? рогалис на анриле писать, это как пытаться самокат нахуй на базе ракетного шаттла делать. + опять же в анриле много ненужного груза, а для рогаликов, если пилить прямо конкретно его, потребуется для обсчитки много ресурсов. В общем рогули писать это не игры делать, там именно движкописание важно
ты гониш шоле? рогалис на анриле писать, это как пытаться самокат нахуй на базе ракетного шаттла делать. + опять же в анриле много ненужного груза, а для рогаликов, если пилить прямо конкретно его, потребуется для обсчитки много ресурсов. В общем рогули писать это не игры делать, там именно движкописание важно
>>607375
ты не понял мой пост
тайпскрипт это суперсет джаваскрипта
буквально джаваскрипт в котором ты можешь указать ожидаемый тип переменной и который будет ругаться но все равно работать если переменная окажется другого типа
он транслирует код в es5 джаваскрипт
а так мне джаваскрипт нравится на нем бы и написал
даже на тайпскрипте лол, мне его тоже получить надо
мой следующий проект тоже будет на тайпскрипте ещё и с ридаксом хотя он мне не нужен как и тайпскрипт но учить то нужно
>>607374
довольно быстрый язык
ты не понял мой пост
тайпскрипт это суперсет джаваскрипта
буквально джаваскрипт в котором ты можешь указать ожидаемый тип переменной и который будет ругаться но все равно работать если переменная окажется другого типа
он транслирует код в es5 джаваскрипт
а так мне джаваскрипт нравится на нем бы и написал
даже на тайпскрипте лол, мне его тоже получить надо
мой следующий проект тоже будет на тайпскрипте ещё и с ридаксом хотя он мне не нужен как и тайпскрипт но учить то нужно
>>607374
довольно быстрый язык
>>607378
Сразу видно что ты не шаришь в анриле. Ничо, для тя поясню - внутри анрила есть 2 классные штуки, первОЯ это кресты, на них можно написать шо душе угодно, но вторая еще вкуснее и проще это блюпринты, так вот, ты идёшь, качаешь бесплатный унрил, куришь мануалы по блюпринтам, и делаешь рогалик не написав не одной строчки кода, ахуеть да? Прогресс то идёт, время дроча консолички, и все остального прошло.
Сразу видно что ты не шаришь в анриле. Ничо, для тя поясню - внутри анрила есть 2 классные штуки, первОЯ это кресты, на них можно написать шо душе угодно, но вторая еще вкуснее и проще это блюпринты, так вот, ты идёшь, качаешь бесплатный унрил, куришь мануалы по блюпринтам, и делаешь рогалик не написав не одной строчки кода, ахуеть да? Прогресс то идёт, время дроча консолички, и все остального прошло.
>>607376
ты знаешь в чём преимущество типизированых языков над динамическими? можно легче отловить многие невнятные баги. если твой проект сложный может оно того и стоит
ты знаешь в чём преимущество типизированых языков над динамическими? можно легче отловить многие невнятные баги. если твой проект сложный может оно того и стоит
>>607380
Я знаю про это, и ты меня видать не понял. Я знаю и про бллюпринты и про встроенные кресты, конечно можно написать рогалик, никто не спорит, но суть рогаликов именно и в том, что ты полностью знаешь как у тебя код работает, ты сам подстраиваешь все обработчики и прочеее нахуй хуё моё, а тут в анриле много лишнего функционала, это просто невыгодно нахуй с точки зрения оптитмизации. Конечно если ты лепишь какую нибудь поеботу простецкую (без сложных вычислений имеется), а-ля нетхак то никаких проблем - пиши. Но попробуй тот же ДФ перенести на анрил, что то не подкасывает всё станет ещё несоразмернее хуже с оптимизоном.
Я знаю про это, и ты меня видать не понял. Я знаю и про бллюпринты и про встроенные кресты, конечно можно написать рогалик, никто не спорит, но суть рогаликов именно и в том, что ты полностью знаешь как у тебя код работает, ты сам подстраиваешь все обработчики и прочеее нахуй хуё моё, а тут в анриле много лишнего функционала, это просто невыгодно нахуй с точки зрения оптитмизации. Конечно если ты лепишь какую нибудь поеботу простецкую (без сложных вычислений имеется), а-ля нетхак то никаких проблем - пиши. Но попробуй тот же ДФ перенести на анрил, что то не подкасывает всё станет ещё несоразмернее хуже с оптимизоном.
>>607380
рогалик это очень простая пошаговая игра
зачем ей фреймворк?
ее можно сделать буквально в браузере управляя дом деревом лол
рогалик это очень простая пошаговая игра
зачем ей фреймворк?
ее можно сделать буквально в браузере управляя дом деревом лол
>>607385
в дф довольно много вычислений иирк, нужен сервер и какая нибудь либа. в джаваскрипт есть биндинги к куче либ так что при желании можно хоть нейросеть прикрутить
в дф довольно много вычислений иирк, нужен сервер и какая нибудь либа. в джаваскрипт есть биндинги к куче либ так что при желании можно хоть нейросеть прикрутить
>>607382
1. Если ты делаешь 2Д, не 3Д, то проблем с оптимизоном в унриле у тебя не будет, вот 100%, исключение составляют лишь бесконечные циклы если ты где то проебёшься с ними.
2. Если ты знаешь, но не решаешься сделать, значит у тебя не достаточно опыта, либо предвзятое мнение и не желание разбираться в движке.
3. Судя по твоему описанию склоняюсь к тому что уаньку ты мало трогал, и не шаришь в ней, следовательно, идёшь курить мануалы по блюпринтам, это займёт максимум пару дней, и еще пару по поути.
4. Перенести ДФ как раз таки будет легко по причине того что ты видишь конечный продукт + знание механики освобождает от придумывания своей, остаётся только графон и заблюпринтить.
Всё таки советую анон покурить анрильку, думаю ты удивишься сколько всего можно сделать на ней не глюченого, если не 3Д!!
>>607383
Время 3++ в консолечке прошло, ало дядя, за тебя всё движок делает, тебе надо лишь нафантазировать механики, спиздить графон и музон, всё!
1. Если ты делаешь 2Д, не 3Д, то проблем с оптимизоном в унриле у тебя не будет, вот 100%, исключение составляют лишь бесконечные циклы если ты где то проебёшься с ними.
2. Если ты знаешь, но не решаешься сделать, значит у тебя не достаточно опыта, либо предвзятое мнение и не желание разбираться в движке.
3. Судя по твоему описанию склоняюсь к тому что уаньку ты мало трогал, и не шаришь в ней, следовательно, идёшь курить мануалы по блюпринтам, это займёт максимум пару дней, и еще пару по поути.
4. Перенести ДФ как раз таки будет легко по причине того что ты видишь конечный продукт + знание механики освобождает от придумывания своей, остаётся только графон и заблюпринтить.
Всё таки советую анон покурить анрильку, думаю ты удивишься сколько всего можно сделать на ней не глюченого, если не 3Д!!
>>607383
Время 3++ в консолечке прошло, ало дядя, за тебя всё движок делает, тебе надо лишь нафантазировать механики, спиздить графон и музон, всё!
ну в смысле сервер если это веб рогалик, но это не обязательно
>>607387
МОжет быть я и ошибаюсь, хочу ошибалться даже. Раз ты такой ведающий, разъясни момент с оптимизацией? Это зависит исключительно от того как написан код самой игры, сложных обработчиков и процедур? Просто ДФ, как ты говоришь перенести легко относительно, никто не спорит, но меня ОЧЕНЬ заботит оптимизация игры, вот захочу я повысить количество обрабатываемых обьектов в мире даже больше чем в ДФ, и что? Насколько сам движок будет влиять? Или допустим ты если пишешь сложную логику, то надо хотя бы иметь опенсурс от анрила, чтобы понимать как те или иные функции работают, это опять же вопрос не невозможности реализовать, а оптимизации этого всего действа.
МОжет быть я и ошибаюсь, хочу ошибалться даже. Раз ты такой ведающий, разъясни момент с оптимизацией? Это зависит исключительно от того как написан код самой игры, сложных обработчиков и процедур? Просто ДФ, как ты говоришь перенести легко относительно, никто не спорит, но меня ОЧЕНЬ заботит оптимизация игры, вот захочу я повысить количество обрабатываемых обьектов в мире даже больше чем в ДФ, и что? Насколько сам движок будет влиять? Или допустим ты если пишешь сложную логику, то надо хотя бы иметь опенсурс от анрила, чтобы понимать как те или иные функции работают, это опять же вопрос не невозможности реализовать, а оптимизации этого всего действа.
>>607389
Насчёт оптимизации, здесь выигрывают как раз готовые движки по типу анрила, юнити, потому что за нас уже всё продумано и реализовано, и остаётся лишь курить мануалы и применять готовые решения(Не путать с тасканием ассетов!). Вот как писал анон выше, написать рогалик самому к примеру на голых плюсах, или на java, объём работы увеличивается в разы, а с ним самая важная часть, это понимание архитектуры куда, какую функцию записать, что бы определить правильную последовательность обращений из одного файла в другой и т.д, в движке же, как я упомянул раньше всё проще, многие фишки в том числе с оптимизация просто у мешаются в пару строк кода. Из минусов как многие сразу могут написать есть лишь то что закрытый код() и если захочется тонкой настройки это нэт, костыль на костыле будет получаться, Но для обычного инди девелопа идеально подходит, всё что остаётся это творить, и изредка думать над оптимизацией.
Насчёт оптимизации, здесь выигрывают как раз готовые движки по типу анрила, юнити, потому что за нас уже всё продумано и реализовано, и остаётся лишь курить мануалы и применять готовые решения(Не путать с тасканием ассетов!). Вот как писал анон выше, написать рогалик самому к примеру на голых плюсах, или на java, объём работы увеличивается в разы, а с ним самая важная часть, это понимание архитектуры куда, какую функцию записать, что бы определить правильную последовательность обращений из одного файла в другой и т.д, в движке же, как я упомянул раньше всё проще, многие фишки в том числе с оптимизация просто у мешаются в пару строк кода. Из минусов как многие сразу могут написать есть лишь то что закрытый код() и если захочется тонкой настройки это нэт, костыль на костыле будет получаться, Но для обычного инди девелопа идеально подходит, всё что остаётся это творить, и изредка думать над оптимизацией.
63 Кб, 1920x1080>>607389
Если ты будешь пилить на уе4, то должен понимать, что есть просто колоссальное количество подводных камней. Текстовый вывод в консольку? Похуй, нужна видеокарта с DX11. Примитивная игра практически без логики? Похуй, твой восьмиядерный интол будет загружен на 98%. Нет контента? Похуй, билд игры будет весить не меньше гигабайта.
Если ты будешь пилить на уе4, то должен понимать, что есть просто колоссальное количество подводных камней. Текстовый вывод в консольку? Похуй, нужна видеокарта с DX11. Примитивная игра практически без логики? Похуй, твой восьмиядерный интол будет загружен на 98%. Нет контента? Похуй, билд игры будет весить не меньше гигабайта.
>>607393
Ой пиздабол, ой пиздабол... Узнаю стандартные мантры немощного который даже не собирал билд в юньке.
Ой пиздабол, ой пиздабол... Узнаю стандартные мантры немощного который даже не собирал билд в юньке.
>>607392
Да, иммено, ты мне про Фому я те про Ерёму, пиание рогаликов, хардкорное, as it is вообще никак не идёт в сравнение с обычным инди деланием. Это скорее какой-то хтонический байтодрочерский процесс (немного преувеличил но ты понял), где вся архитектура перепиливается с нуля. Естесна если ты хочешь создать простенькую игру которую можно будет только условно назвать рогаликом (на деле симуляции всего и вся там конечно же не будет.), то готовые движки будет самое то. Тут же у нас идёт йобаный хардкор, с пересборкой велосипедов под езде по рельсам и воздухоплаванию одновременно.
>>607393
ЧТД.
Да, иммено, ты мне про Фому я те про Ерёму, пиание рогаликов, хардкорное, as it is вообще никак не идёт в сравнение с обычным инди деланием. Это скорее какой-то хтонический байтодрочерский процесс (немного преувеличил но ты понял), где вся архитектура перепиливается с нуля. Естесна если ты хочешь создать простенькую игру которую можно будет только условно назвать рогаликом (на деле симуляции всего и вся там конечно же не будет.), то готовые движки будет самое то. Тут же у нас идёт йобаный хардкор, с пересборкой велосипедов под езде по рельсам и воздухоплаванию одновременно.
>>607393
ЧТД.
честно говоря я в игродвижках не разбираюсь (игры слишком долго делать есть много других интересных вещей которые можно сделать быстрее) но как давний фэн рогаликов, который даже написал раз безбиблиотечный простенький рогалик на си на анси-кодах в консоли мне сама идея что монстр вроде юнити будет использоваться для рогалика кажется кощунством лол
в рогаликах главное дизайн игры, мир, механики, генерация уровней т.е. логика, в них перемещение происходит пошагово и по фиксированной двухмерной сетке, зачем для них монстр предназначенный для сложной графики
в рогаликах главное дизайн игры, мир, механики, генерация уровней т.е. логика, в них перемещение происходит пошагово и по фиксированной двухмерной сетке, зачем для них монстр предназначенный для сложной графики
>>607399
эм
какая стимуляция
рогалик это в первую очередь каменный суп, адом, ангбанд с его клонами, нетхак, все такое
эм
какая стимуляция
рогалик это в первую очередь каменный суп, адом, ангбанд с его клонами, нетхак, все такое
>>607400
Затем чтобы довести своё поделии до альфы, а не бросить спустя пол года дрочения голого кода.
Затем чтобы довести своё поделии до альфы, а не бросить спустя пол года дрочения голого кода.
>>607399
Ладн я понял, забей, если ты так одержим своим то лучше это и используй, если получится то супер, если нет, мб пересмотришь свои взгляды в дальнейшем.
Ладн я понял, забей, если ты так одержим своим то лучше это и используй, если получится то супер, если нет, мб пересмотришь свои взгляды в дальнейшем.
>>607403
ты не понимаешь, перемещение персонажа по экрану и т.п. фигня в рогалике самое простое и делается день или за несколько дней
ты не понимаешь, перемещение персонажа по экрану и т.п. фигня в рогалике самое простое и делается день или за несколько дней
>>607401
ну вроде как бы и да, но мне кажется что интереснее рогалики-гиганты, типо ДФ, с его невзъебенной симуляцией каждой хуйни и дотошным вычислением всего, Катаклизм ДДА, CoQ и прочее. Мне просто лично кажется обычные-примитивные дунжон кравлеры себя уже давно изжили, и это просто мягко говоря заэбало.
ну вроде как бы и да, но мне кажется что интереснее рогалики-гиганты, типо ДФ, с его невзъебенной симуляцией каждой хуйни и дотошным вычислением всего, Катаклизм ДДА, CoQ и прочее. Мне просто лично кажется обычные-примитивные дунжон кравлеры себя уже давно изжили, и это просто мягко говоря заэбало.
>>607405
Ох мой юный анончик, ты даже не представляешь что тебя ждёт впереди... С другой стороны, если попробуешь заниматься гей девом тебе откроется много интересного, завидую тебе даже...
Ох мой юный анончик, ты даже не представляешь что тебя ждёт впереди... С другой стороны, если попробуешь заниматься гей девом тебе откроется много интересного, завидую тебе даже...
>>607406
я лично куууууда больше времени убил на дксс, адом и посченг чем на катаклизм и дф
дело вкуса, дксс вообще вызов был, я спидранил сприганнами лол
я лично куууууда больше времени убил на дксс, адом и посченг чем на катаклизм и дф
дело вкуса, дксс вообще вызов был, я спидранил сприганнами лол
341 Кб, 1024x577>>607403
Считай это своеобразным естественным отбором.
>>607404
Можно сказать и да, но всё же объясни в чём проблема, Ты предлагаешь использование двиков, но я не говорю что движки это плохо, просто это немного не та сфера куда их можно применить. Так что и майкрософт ворд можно на анрил энжон ебануть, лол.
>>607410
Может быть это я просто уже изыгрался, такой метамодерн пошёл.
Считай это своеобразным естественным отбором.
>>607404
Можно сказать и да, но всё же объясни в чём проблема, Ты предлагаешь использование двиков, но я не говорю что движки это плохо, просто это немного не та сфера куда их можно применить. Так что и майкрософт ворд можно на анрил энжон ебануть, лол.
>>607410
Может быть это я просто уже изыгрался, такой метамодерн пошёл.
>>607407
и что же? рогалик я лично написал бы браузерный без специального игрового фреймворка, что-то 2д с реалтайм перемещением наверное взял бы какой-нибудь phaser, 3д не трогал бы вообще
но повторю мне написание игр кажется тратой времени, уд слишком много людей их пишет
и что же? рогалик я лично написал бы браузерный без специального игрового фреймворка, что-то 2д с реалтайм перемещением наверное взял бы какой-нибудь phaser, 3д не трогал бы вообще
но повторю мне написание игр кажется тратой времени, уд слишком много людей их пишет
>>607415
Это зависит еще от того что ты сам напишешь. Посредственностей конечно дохуя, но при этом выдающиеся вещи (если таковыю сможешь родить) в узких рогаликоведческих кругах известна будет.
Это зависит еще от того что ты сам напишешь. Посредственностей конечно дохуя, но при этом выдающиеся вещи (если таковыю сможешь родить) в узких рогаликоведческих кругах известна будет.
>>607415
Ты уж определись ты это делаешь ради денег? Тогда надо идти в мобилкоговно рыночек. Для хобби? Тогда пиши на чём душе угодна, когда угодна, хоть в блокноте, даже если выйдет говно, главное чтобы получалось удовольствие от процесса. Для кого-то? Небольшой публики? Тогда придётся что-то изучать, осваивать, тратить время на не интересные вещи, но нужны для прогресса и понимания.
>слишком много людей их пишет
Ты уж определись ты это делаешь ради денег? Тогда надо идти в мобилкоговно рыночек. Для хобби? Тогда пиши на чём душе угодна, когда угодна, хоть в блокноте, даже если выйдет говно, главное чтобы получалось удовольствие от процесса. Для кого-то? Небольшой публики? Тогда придётся что-то изучать, осваивать, тратить время на не интересные вещи, но нужны для прогресса и понимания.
>>562448
всегда ору с ооп фанатов и их любви делать классы
зачем для этого класс?
const Посыл = require('./посылы/Посыл'); //ты эту часть вообще упустил где у тебя код базового класса хранится
const посылЕЦС = Посыл.кого("ЕЦС-чушкан");
все. никаких конструкторов. никаких классов на пустом месте
можно сделать обертку с дефолтным значением аргумента
function ИдиНахуй(КогоПослать = "ЕЦС-чушкан") {
const Посыл = require('./посылы/Посыл');
return Посыл.кого(КогоПослать);
}
никакого говнонаследования
всегда ору с ооп фанатов и их любви делать классы
>У меня есть базовый класс "иди нахуй", в котором очень много витиеватого трёхэтажного кода, написанного много раз.
>Теперь, чтобы послать нахуй залётного ЕЦС-чушкана, мне достаточно просто сконструировать класс с инициализатором. И это всё одной строкой!
>var посыл = ИдиНахуй.new(){КогоПослать = "ЕЦС-чушкан"}
зачем для этого класс?
const Посыл = require('./посылы/Посыл'); //ты эту часть вообще упустил где у тебя код базового класса хранится
const посылЕЦС = Посыл.кого("ЕЦС-чушкан");
все. никаких конструкторов. никаких классов на пустом месте
>Далее, если мне нужно плотно работать с чушканом (если он с первого раза не понял), я >могу унаследоваться от базового класса:
>class ИдиНахуйЕЦСЧушкан : ИдиНахуй { КогоПослать = "ЕЦС-чушкан" }
>И далее, просто конструировать класс-потомок.
можно сделать обертку с дефолтным значением аргумента
function ИдиНахуй(КогоПослать = "ЕЦС-чушкан") {
const Посыл = require('./посылы/Посыл');
return Посыл.кого(КогоПослать);
}
никакого говнонаследования
>>571236
я скорее не вижу зачем это надо
можно запилить очень эффективное ай без мл см. sil
может с помощью мл можно запилить еще более умных мобов, но... советую поиграть в sil, умные мобы напрягают, конкретно умные мобы будут напрягать конкретно
>>572335
обычно это делается просто через систему видимости (самая простая это конечно сделать левел полностью видимым). она может быть симметричной как в dcss и асимметричной как в *бандах например. симметричная видимость очень забавная вещь кстати, не знаю пофиксили ее или нет, но в dcss некоторые люди проходили игру специально уменьшив себе видимость артифактом - это соответственно уменьшало видимость монстров и делало их слепыми лол. все равно как гулять в клочке тумана. ну и помимо видимости добавляют еще всякое экстрасенсорное восприятие, дрожь поверхности, запах и т.п. чему не мешают стены
>>572531
как насчет сделать функцию/класс/назови как хочешь которая будет вычислять что видит монстр которого ей передали как аргумент и его реакцию в зависимости от флагов самого монстра и уровня который тоже в нее предан как аргумент. возвращать будет движение монстра. просто первое что в голову пришло
>>572542
такая генерация уровней годится только для некоторых открытых уровней имо, надо однозначно сделать и другие уровни, более закрытые, иначе игра будет сплошные разборки со стаями мобов без какой-то особой тактики связанной с местностью. двери нужны кстати. алсо это не пещера а какой-то торговый центр лол
интерфейс странный - на не полностью открытой карте у тебя справа информация о персонаже, а на полностью открытой ее нет. карту нельзя открыть полностью чтоле?
стены надо однозначно темнее
у самого верхнего торговца левый верхний сундук это мимик? если нет, то у тебя наложилось два тайла
>Насколько я знаю, машин лёрнинг пока можно обучать в очень узких специальностях. Может быть можно написать площадку с группой юинтов А, и одним юнитом Б, и их обучать убиению друг друга, тренируя pathfinding и стратегию, хотя я честно не уверен насколько это возможно.
я скорее не вижу зачем это надо
можно запилить очень эффективное ай без мл см. sil
может с помощью мл можно запилить еще более умных мобов, но... советую поиграть в sil, умные мобы напрягают, конкретно умные мобы будут напрягать конкретно
>>572335
обычно это делается просто через систему видимости (самая простая это конечно сделать левел полностью видимым). она может быть симметричной как в dcss и асимметричной как в *бандах например. симметричная видимость очень забавная вещь кстати, не знаю пофиксили ее или нет, но в dcss некоторые люди проходили игру специально уменьшив себе видимость артифактом - это соответственно уменьшало видимость монстров и делало их слепыми лол. все равно как гулять в клочке тумана. ну и помимо видимости добавляют еще всякое экстрасенсорное восприятие, дрожь поверхности, запах и т.п. чему не мешают стены
>>572531
как насчет сделать функцию/класс/назови как хочешь которая будет вычислять что видит монстр которого ей передали как аргумент и его реакцию в зависимости от флагов самого монстра и уровня который тоже в нее предан как аргумент. возвращать будет движение монстра. просто первое что в голову пришло
>>572542
такая генерация уровней годится только для некоторых открытых уровней имо, надо однозначно сделать и другие уровни, более закрытые, иначе игра будет сплошные разборки со стаями мобов без какой-то особой тактики связанной с местностью. двери нужны кстати. алсо это не пещера а какой-то торговый центр лол
интерфейс странный - на не полностью открытой карте у тебя справа информация о персонаже, а на полностью открытой ее нет. карту нельзя открыть полностью чтоле?
стены надо однозначно темнее
у самого верхнего торговца левый верхний сундук это мимик? если нет, то у тебя наложилось два тайла
>>571236
я скорее не вижу зачем это надо
можно запилить очень эффективное ай без мл см. sil
может с помощью мл можно запилить еще более умных мобов, но... советую поиграть в sil, умные мобы напрягают, конкретно умные мобы будут напрягать конкретно
>>572335
обычно это делается просто через систему видимости (самая простая это конечно сделать левел полностью видимым). она может быть симметричной как в dcss и асимметричной как в *бандах например. симметричная видимость очень забавная вещь кстати, не знаю пофиксили ее или нет, но в dcss некоторые люди проходили игру специально уменьшив себе видимость артифактом - это соответственно уменьшало видимость монстров и делало их слепыми лол. все равно как гулять в клочке тумана. ну и помимо видимости добавляют еще всякое экстрасенсорное восприятие, дрожь поверхности, запах и т.п. чему не мешают стены
>>572531
как насчет сделать функцию/класс/назови как хочешь которая будет вычислять что видит монстр которого ей передали как аргумент и его реакцию в зависимости от флагов самого монстра и уровня который тоже в нее предан как аргумент. возвращать будет движение монстра. просто первое что в голову пришло
>>572542
такая генерация уровней годится только для некоторых открытых уровней имо, надо однозначно сделать и другие уровни, более закрытые, иначе игра будет сплошные разборки со стаями мобов без какой-то особой тактики связанной с местностью. двери нужны кстати. алсо это не пещера а какой-то торговый центр лол
интерфейс странный - на не полностью открытой карте у тебя справа информация о персонаже, а на полностью открытой ее нет. карту нельзя открыть полностью чтоле?
стены надо однозначно темнее
у самого верхнего торговца левый верхний сундук это мимик? если нет, то у тебя наложилось два тайла
>Насколько я знаю, машин лёрнинг пока можно обучать в очень узких специальностях. Может быть можно написать площадку с группой юинтов А, и одним юнитом Б, и их обучать убиению друг друга, тренируя pathfinding и стратегию, хотя я честно не уверен насколько это возможно.
я скорее не вижу зачем это надо
можно запилить очень эффективное ай без мл см. sil
может с помощью мл можно запилить еще более умных мобов, но... советую поиграть в sil, умные мобы напрягают, конкретно умные мобы будут напрягать конкретно
>>572335
обычно это делается просто через систему видимости (самая простая это конечно сделать левел полностью видимым). она может быть симметричной как в dcss и асимметричной как в *бандах например. симметричная видимость очень забавная вещь кстати, не знаю пофиксили ее или нет, но в dcss некоторые люди проходили игру специально уменьшив себе видимость артифактом - это соответственно уменьшало видимость монстров и делало их слепыми лол. все равно как гулять в клочке тумана. ну и помимо видимости добавляют еще всякое экстрасенсорное восприятие, дрожь поверхности, запах и т.п. чему не мешают стены
>>572531
как насчет сделать функцию/класс/назови как хочешь которая будет вычислять что видит монстр которого ей передали как аргумент и его реакцию в зависимости от флагов самого монстра и уровня который тоже в нее предан как аргумент. возвращать будет движение монстра. просто первое что в голову пришло
>>572542
такая генерация уровней годится только для некоторых открытых уровней имо, надо однозначно сделать и другие уровни, более закрытые, иначе игра будет сплошные разборки со стаями мобов без какой-то особой тактики связанной с местностью. двери нужны кстати. алсо это не пещера а какой-то торговый центр лол
интерфейс странный - на не полностью открытой карте у тебя справа информация о персонаже, а на полностью открытой ее нет. карту нельзя открыть полностью чтоле?
стены надо однозначно темнее
у самого верхнего торговца левый верхний сундук это мимик? если нет, то у тебя наложилось два тайла
>>558364
Сейчас бы разделять игрока и врагов в рогалике. Все живые существа должны быть частью симуляции и работать по одним правилам.
Поэтому во всех трушных рогаликах игрок и враг это один и тот же класс, они имеют одинаковые параметры, атрибуты, инвентари, и различаются только тем, что игрок управляется через контроллер игрока, враг - через контроллер AI, который посылает по сути те же команды, что и игрок с клавиатуры. Так везде, от dungeon crawl'a до катаклизма.
Сейчас бы разделять игрока и врагов в рогалике. Все живые существа должны быть частью симуляции и работать по одним правилам.
Поэтому во всех трушных рогаликах игрок и враг это один и тот же класс, они имеют одинаковые параметры, атрибуты, инвентари, и различаются только тем, что игрок управляется через контроллер игрока, враг - через контроллер AI, который посылает по сути те же команды, что и игрок с клавиатуры. Так везде, от dungeon crawl'a до катаклизма.
>>607968
Нет, маня, ты не права. Логика врагов основывается на алгоритмах (поиск пути, таргетирование и т.д.), а логика игрока - на том, что у него вместо мозгов в башке. Соотвественно, классы априори уже не могут быть идентичны. Ну или могут, но это будет уже как консируктор солянки. Залупа в общем конская.
Нет, маня, ты не права. Логика врагов основывается на алгоритмах (поиск пути, таргетирование и т.д.), а логика игрока - на том, что у него вместо мозгов в башке. Соотвественно, классы априори уже не могут быть идентичны. Ну или могут, но это будет уже как консируктор солянки. Залупа в общем конская.
>>607367
C++, SDL, emscripten.
>>607386
А машинное обучение с бигдатой на блокчейне можно прикрутить, чтобы побыстрее работало? Что ты несешь, дурачок?
>>607392
Продуман и реализован движок общего назначения, цель которого покрыть любую возможную разновидность игр. Используя тот же юнити для рогалика, ты будешь юзать 5% от его фич, а остальные фичи будут висеть мертвым грузом в дистрибутиве, ветвлениями в коде. Кастомный движок, написаный с нуля под конкретный набор фич ВСЕГДА разносит по перфомансу и размеру дистрибутива движок общего назначения. На юнити твой рогалик будет весить 200 Мб и позволять обрабатывать 1000 юнитов без просадки фпс, на голых плюсах это будет 10 мегабайт и десятки/сотни тысяч, зависит от твоего скилла и подхода к работе с данными. Чем меньше абстракций, ООП, паттернов, уровней наследования юзается - тем выше перфоманс. На ecs с хитрыми оптимизациями симулировать сотни тысяч сущностей вообще не проблема, даже на не самом топовом железе.
>>607970
Маня, ты путаешь класс персонажа и контроллер персонажа. Сваливать обработку ввода и симуляцию персонажа в один класс это первый признак говноархитектуры, это еще в конце 90х поняли и уже в первом анриле был отдельно Pawn, класс персонажа, и контроллеры PlayerController и AiController, которые работают с одним и тем же персонажем, просто по-разному его контролируют. Персонаж содержит все данные, здоровье, опыт, скиллы, инвентарь, и базовую логику взаимодействия, идти вперед, перейти в точку, атаковать. А контроллер отвечает именно за управление, обработку ввода.
На ecs это элементарно реализуется, контроллер подключается как отдельный компонент и управляет связанным с ним персонажем. В случае контроллера игрока он ловит ввод с клавиатуры, AI контроллер как раз определяет цель и строит путь. С таким унифицированным подходом легко реализовать переселение души, например, просто переключаешь компонент с одного персонажа на другого, и ты можешь управлять уже врагом (либо одним из своих юнитов). Либо наоборот, перевести своего персонажа в режим ИИ, чтобы он автоматом бегал по уровню и дрался.
В ООП это тоже просто делается через агрегацию.
А залупа конская у тебя вместо мозга, похоже.
C++, SDL, emscripten.
>>607386
>что при желании можно хоть нейросеть прикрутить
А машинное обучение с бигдатой на блокчейне можно прикрутить, чтобы побыстрее работало? Что ты несешь, дурачок?
>>607392
>Насчёт оптимизации, здесь выигрывают как раз готовые движки по типу анрила, юнити, потому что за нас уже всё продумано и реализовано,
Продуман и реализован движок общего назначения, цель которого покрыть любую возможную разновидность игр. Используя тот же юнити для рогалика, ты будешь юзать 5% от его фич, а остальные фичи будут висеть мертвым грузом в дистрибутиве, ветвлениями в коде. Кастомный движок, написаный с нуля под конкретный набор фич ВСЕГДА разносит по перфомансу и размеру дистрибутива движок общего назначения. На юнити твой рогалик будет весить 200 Мб и позволять обрабатывать 1000 юнитов без просадки фпс, на голых плюсах это будет 10 мегабайт и десятки/сотни тысяч, зависит от твоего скилла и подхода к работе с данными. Чем меньше абстракций, ООП, паттернов, уровней наследования юзается - тем выше перфоманс. На ecs с хитрыми оптимизациями симулировать сотни тысяч сущностей вообще не проблема, даже на не самом топовом железе.
>>607970
Маня, ты путаешь класс персонажа и контроллер персонажа. Сваливать обработку ввода и симуляцию персонажа в один класс это первый признак говноархитектуры, это еще в конце 90х поняли и уже в первом анриле был отдельно Pawn, класс персонажа, и контроллеры PlayerController и AiController, которые работают с одним и тем же персонажем, просто по-разному его контролируют. Персонаж содержит все данные, здоровье, опыт, скиллы, инвентарь, и базовую логику взаимодействия, идти вперед, перейти в точку, атаковать. А контроллер отвечает именно за управление, обработку ввода.
На ecs это элементарно реализуется, контроллер подключается как отдельный компонент и управляет связанным с ним персонажем. В случае контроллера игрока он ловит ввод с клавиатуры, AI контроллер как раз определяет цель и строит путь. С таким унифицированным подходом легко реализовать переселение души, например, просто переключаешь компонент с одного персонажа на другого, и ты можешь управлять уже врагом (либо одним из своих юнитов). Либо наоборот, перевести своего персонажа в режим ИИ, чтобы он автоматом бегал по уровню и дрался.
В ООП это тоже просто делается через агрегацию.
А залупа конская у тебя вместо мозга, похоже.
>>607367
C++, SDL, emscripten.
>>607386
А машинное обучение с бигдатой на блокчейне можно прикрутить, чтобы побыстрее работало? Что ты несешь, дурачок?
>>607392
Продуман и реализован движок общего назначения, цель которого покрыть любую возможную разновидность игр. Используя тот же юнити для рогалика, ты будешь юзать 5% от его фич, а остальные фичи будут висеть мертвым грузом в дистрибутиве, ветвлениями в коде. Кастомный движок, написаный с нуля под конкретный набор фич ВСЕГДА разносит по перфомансу и размеру дистрибутива движок общего назначения. На юнити твой рогалик будет весить 200 Мб и позволять обрабатывать 1000 юнитов без просадки фпс, на голых плюсах это будет 10 мегабайт и десятки/сотни тысяч, зависит от твоего скилла и подхода к работе с данными. Чем меньше абстракций, ООП, паттернов, уровней наследования юзается - тем выше перфоманс. На ecs с хитрыми оптимизациями симулировать сотни тысяч сущностей вообще не проблема, даже на не самом топовом железе.
>>607970
Маня, ты путаешь класс персонажа и контроллер персонажа. Сваливать обработку ввода и симуляцию персонажа в один класс это первый признак говноархитектуры, это еще в конце 90х поняли и уже в первом анриле был отдельно Pawn, класс персонажа, и контроллеры PlayerController и AiController, которые работают с одним и тем же персонажем, просто по-разному его контролируют. Персонаж содержит все данные, здоровье, опыт, скиллы, инвентарь, и базовую логику взаимодействия, идти вперед, перейти в точку, атаковать. А контроллер отвечает именно за управление, обработку ввода.
На ecs это элементарно реализуется, контроллер подключается как отдельный компонент и управляет связанным с ним персонажем. В случае контроллера игрока он ловит ввод с клавиатуры, AI контроллер как раз определяет цель и строит путь. С таким унифицированным подходом легко реализовать переселение души, например, просто переключаешь компонент с одного персонажа на другого, и ты можешь управлять уже врагом (либо одним из своих юнитов). Либо наоборот, перевести своего персонажа в режим ИИ, чтобы он автоматом бегал по уровню и дрался.
В ООП это тоже просто делается через агрегацию.
А залупа конская у тебя вместо мозга, похоже.
C++, SDL, emscripten.
>>607386
>что при желании можно хоть нейросеть прикрутить
А машинное обучение с бигдатой на блокчейне можно прикрутить, чтобы побыстрее работало? Что ты несешь, дурачок?
>>607392
>Насчёт оптимизации, здесь выигрывают как раз готовые движки по типу анрила, юнити, потому что за нас уже всё продумано и реализовано,
Продуман и реализован движок общего назначения, цель которого покрыть любую возможную разновидность игр. Используя тот же юнити для рогалика, ты будешь юзать 5% от его фич, а остальные фичи будут висеть мертвым грузом в дистрибутиве, ветвлениями в коде. Кастомный движок, написаный с нуля под конкретный набор фич ВСЕГДА разносит по перфомансу и размеру дистрибутива движок общего назначения. На юнити твой рогалик будет весить 200 Мб и позволять обрабатывать 1000 юнитов без просадки фпс, на голых плюсах это будет 10 мегабайт и десятки/сотни тысяч, зависит от твоего скилла и подхода к работе с данными. Чем меньше абстракций, ООП, паттернов, уровней наследования юзается - тем выше перфоманс. На ecs с хитрыми оптимизациями симулировать сотни тысяч сущностей вообще не проблема, даже на не самом топовом железе.
>>607970
Маня, ты путаешь класс персонажа и контроллер персонажа. Сваливать обработку ввода и симуляцию персонажа в один класс это первый признак говноархитектуры, это еще в конце 90х поняли и уже в первом анриле был отдельно Pawn, класс персонажа, и контроллеры PlayerController и AiController, которые работают с одним и тем же персонажем, просто по-разному его контролируют. Персонаж содержит все данные, здоровье, опыт, скиллы, инвентарь, и базовую логику взаимодействия, идти вперед, перейти в точку, атаковать. А контроллер отвечает именно за управление, обработку ввода.
На ecs это элементарно реализуется, контроллер подключается как отдельный компонент и управляет связанным с ним персонажем. В случае контроллера игрока он ловит ввод с клавиатуры, AI контроллер как раз определяет цель и строит путь. С таким унифицированным подходом легко реализовать переселение души, например, просто переключаешь компонент с одного персонажа на другого, и ты можешь управлять уже врагом (либо одним из своих юнитов). Либо наоборот, перевести своего персонажа в режим ИИ, чтобы он автоматом бегал по уровню и дрался.
В ООП это тоже просто делается через агрегацию.
А залупа конская у тебя вместо мозга, похоже.
вообще одна из самых сложных вещей это время
рогалики конечно пошаговые, но если каждое действие будет отбирать один ход и у всех одна скорость игра будет унылая
тогда как сделать фракционные ходы совсем не просто
>>607968
не совсем так
в адоме раньше когда он собственно и обрёл свою популярность не было инвентаря у мобов например в отличие от игрока
впрочем учитывая что он написан на си там и класса моб наверняка нет и не было лол, хотя объекты в си конечно есть и даже можно методы им приделать
>>607970
чушь какая
см. выше я уже написал как это легко делается функцией которой скармливают объекты мобов
рогалики конечно пошаговые, но если каждое действие будет отбирать один ход и у всех одна скорость игра будет унылая
тогда как сделать фракционные ходы совсем не просто
>>607968
не совсем так
в адоме раньше когда он собственно и обрёл свою популярность не было инвентаря у мобов например в отличие от игрока
впрочем учитывая что он написан на си там и класса моб наверняка нет и не было лол, хотя объекты в си конечно есть и даже можно методы им приделать
>>607970
чушь какая
см. выше я уже написал как это легко делается функцией которой скармливают объекты мобов
>>607974
Опять это шизик таблетки не принял.
>а остальные фичи будут висеть мертвым грузом в дистрибутиве, ветвлениями в коде.
Опять это шизик таблетки не принял.
>>607967
Сборка же
Сборка же
193 Кб, 1024x576>>607974
Всё намного проще, из 100 велосипедистов 1 сделает игру, ну допустим немного другие числа 95/5 и т.д, есть шанс что это будешь ты, но намного больше шансов, что ты забросишь свою разработку, своего уникального движка, всё. Вывод прост, не надо делать велосипед когда ты ставишь себе цель что-то выпустить, а не кодить ради удовольствия.
Всё намного проще, из 100 велосипедистов 1 сделает игру, ну допустим немного другие числа 95/5 и т.д, есть шанс что это будешь ты, но намного больше шансов, что ты забросишь свою разработку, своего уникального движка, всё. Вывод прост, не надо делать велосипед когда ты ставишь себе цель что-то выпустить, а не кодить ради удовольствия.
>>608105
ты просто не разбираешься в рогаликах
с одной стороны они достаточно простые в плане графики
с другой их фишкой являются особенности механики
в итоге их сплошь и рядом пишут без фреймворков или со специализированными фреймворками вроде ncurses и libtcod
ты просто не разбираешься в рогаликах
с одной стороны они достаточно простые в плане графики
с другой их фишкой являются особенности механики
в итоге их сплошь и рядом пишут без фреймворков или со специализированными фреймворками вроде ncurses и libtcod
>>608105
Пилили же рогалики десятилетиями до выхода юнитей, и сейчас продолжают пилить, не переживай. Все знаковые рогалики от кравла до катаклизма - на кастомных движках.
Можешь сколько угодно оправдывать своё нежелание писать код, просто скорее всего разработка рогаликов - не твоё. Скачай юнити, таскай ассеты по сценке, сделай шедевр и спокойно продавай его в стиме. А хадркодную разработку оставь увлеченным ребятам.
Пилили же рогалики десятилетиями до выхода юнитей, и сейчас продолжают пилить, не переживай. Все знаковые рогалики от кравла до катаклизма - на кастомных движках.
Можешь сколько угодно оправдывать своё нежелание писать код, просто скорее всего разработка рогаликов - не твоё. Скачай юнити, таскай ассеты по сценке, сделай шедевр и спокойно продавай его в стиме. А хадркодную разработку оставь увлеченным ребятам.
>>608242
И что? А ты живешь в сказочном маня-мире, где у всех всё получается и все обязательно приходят к успеху?
Ты в курсе, что в любой деятельности так? 100 крутых музыкантов на 100.000 тех, кто взял в руки гитару, но так и не научился играть. 100 миллионеров на 100.000 нищебродов. 100 успешных юнити-проектов на 100.000 тех, кто скачал юнити, потаскал ассеты по сценке и забил.
Добро пожаловать в реальность, Мань. Пытаются многие, получается у единиц, обладающих специфическими качествами - упорством, силой воли, те кто на самом деле горят и кого не останавливают трудности.
Если человек хочет запилить рогалик, игру, которая на 99% состоит из кода и алгоритмов, но при этом его пугает необходимость написать немного кода своими руками - он уже опустился и проиграл, даже не попробовав.
И что? А ты живешь в сказочном маня-мире, где у всех всё получается и все обязательно приходят к успеху?
Ты в курсе, что в любой деятельности так? 100 крутых музыкантов на 100.000 тех, кто взял в руки гитару, но так и не научился играть. 100 миллионеров на 100.000 нищебродов. 100 успешных юнити-проектов на 100.000 тех, кто скачал юнити, потаскал ассеты по сценке и забил.
Добро пожаловать в реальность, Мань. Пытаются многие, получается у единиц, обладающих специфическими качествами - упорством, силой воли, те кто на самом деле горят и кого не останавливают трудности.
Если человек хочет запилить рогалик, игру, которая на 99% состоит из кода и алгоритмов, но при этом его пугает необходимость написать немного кода своими руками - он уже опустился и проиграл, даже не попробовав.
>>608258
Маня тут только ты, мы пришли к цифрам потому что я привёл как пример что шанс придти к успеху выше в 90-95% у тех кто пользуется готовыми материалами(движками), а не кодит всё с нуля. А ты приводишь в пример из общего числа тех кто лишь попытался, это не верно.
Маня тут только ты, мы пришли к цифрам потому что я привёл как пример что шанс придти к успеху выше в 90-95% у тех кто пользуется готовыми материалами(движками), а не кодит всё с нуля. А ты приводишь в пример из общего числа тех кто лишь попытался, это не верно.
>>608259
Цифры из своего маня-мирка взял? Или это тебе маркетологи юнити внушили, чтобы ты продлял ежемесячную подписку?
Для рогаликов готовый движок не нужен, фреймворк для вывода буковок/тайлов по сетке напишет студент-первокурсник за пару вечеров. А дальше начинается уже симуляция мира самой игры, которую в любом случае предстоит писать, даже с готовым движком.
А вероятность успеха зависит не от выбора движка/написания своего, а от кучи других факторов. Тот, кто может - сможет и на готовом движке, и на своём, его не остановят трудности и необходимость что-то изучить. Тот, кто изначально ставит себя в положение опущенного, признавая, что ему не по силам писать код и хочет готовенькое - тот скорее всего не сможет ничего сделать и на готовом движке, потому что при разработке будет куча проблем, требующих алгоритмической подготовки для их решения, а нежная манька код писать не приучена.
>90-95%
Цифры из своего маня-мирка взял? Или это тебе маркетологи юнити внушили, чтобы ты продлял ежемесячную подписку?
Для рогаликов готовый движок не нужен, фреймворк для вывода буковок/тайлов по сетке напишет студент-первокурсник за пару вечеров. А дальше начинается уже симуляция мира самой игры, которую в любом случае предстоит писать, даже с готовым движком.
А вероятность успеха зависит не от выбора движка/написания своего, а от кучи других факторов. Тот, кто может - сможет и на готовом движке, и на своём, его не остановят трудности и необходимость что-то изучить. Тот, кто изначально ставит себя в положение опущенного, признавая, что ему не по силам писать код и хочет готовенькое - тот скорее всего не сможет ничего сделать и на готовом движке, потому что при разработке будет куча проблем, требующих алгоритмической подготовки для их решения, а нежная манька код писать не приучена.
>>608269
Хорошо, ты меня убедил, победа твоя, ты прав. Удаляюсь из треда. Даже не знаю, спойлер так для прикола короч
Хорошо, ты меня убедил, победа твоя, ты прав. Удаляюсь из треда. Даже не знаю, спойлер так для прикола короч
>>608272
чувак, но он прав. рогалики это игры которые пилятся не ради выстреливания, а ради процесса, к тому же использование двигла в среде рогаликоделов скорее моветон.
это всё, разумеется, в силе ровно до тех пор пока ты не решишь делать на них деньги
чувак, но он прав. рогалики это игры которые пилятся не ради выстреливания, а ради процесса, к тому же использование двигла в среде рогаликоделов скорее моветон.
это всё, разумеется, в силе ровно до тех пор пока ты не решишь делать на них деньги
>>608275
Да понял я, понял, уже обоссался и спрятался в уголку.
Да понял я, понял, уже обоссался и спрятался в уголку.
>>608258
В Японии не так, ты занимаешься всю жизнь одним делом, причем скорее всего семейным, которым твой отец и дед занимались, и добиваешься успеха. Если ты художник - ты становишься успешным мангакой и рисуешь аниме. Если ты музыкант - сочиняешь для них опенинги. Только программисты почему-то из японцев хуевые выходят, наверное не было в роду.
В Японии не так, ты занимаешься всю жизнь одним делом, причем скорее всего семейным, которым твой отец и дед занимались, и добиваешься успеха. Если ты художник - ты становишься успешным мангакой и рисуешь аниме. Если ты музыкант - сочиняешь для них опенинги. Только программисты почему-то из японцев хуевые выходят, наверное не было в роду.
>>608269
Движок решает совершенно конкретные проблемы и задачи. А именно работу с железом - с тысячами моделей видеокарт со своими тараканами, с сотнями разных дистрибутивов линукса и с десятками версий винды. Те кто отказываются от движка, берут на себя работу пройти весь этот путь по граблям заново и сжечь задницу нахуй.
Да, успешные рогалики были сделаны на самописных движках, потому что они были успешны лет за 20 до появления юнити.
Движок решает совершенно конкретные проблемы и задачи. А именно работу с железом - с тысячами моделей видеокарт со своими тараканами, с сотнями разных дистрибутивов линукса и с десятками версий винды. Те кто отказываются от движка, берут на себя работу пройти весь этот путь по граблям заново и сжечь задницу нахуй.
Да, успешные рогалики были сделаны на самописных движках, потому что они были успешны лет за 20 до появления юнити.
>>608283
японец руби создал
>>608275
если взять коммерческие то.. адом - самописный, томе4 - самописный, даже какой нибудь данжн оф дредмор кастомный движок
>>608290
эти проблемы решает среда разработки а не игровой движок лол. игровой движок в основном отвечает за сложную графику и физику, потому он и не интересен особо
японец руби создал
>>608275
если взять коммерческие то.. адом - самописный, томе4 - самописный, даже какой нибудь данжн оф дредмор кастомный движок
>>608290
эти проблемы решает среда разработки а не игровой движок лол. игровой движок в основном отвечает за сложную графику и физику, потому он и не интересен особо
>>608290
DirectX (Direct3d, XAudio, XInput)
Линукс не нужен
>А именно работу с железом - с тысячами моделей видеокарт со своими тараканами,
DirectX (Direct3d, XAudio, XInput)
>с сотнями разных дистрибутивов линукса
Линукс не нужен
>>608304
Это не гарантирует ни то, что ты на нем сможешь нормально окно инициализировать (учитывая всякие нюансы вроде второго монитора), ни то, что не объебешься где-то в вызовах апи или шейдерах.
>DirectX
Это не гарантирует ни то, что ты на нем сможешь нормально окно инициализировать (учитывая всякие нюансы вроде второго монитора), ни то, что не объебешься где-то в вызовах апи или шейдерах.
>>608333
>>608290
Вот это дивный маня-мир, давно такого не встречал.
Ты правда думаешь, что при разработке без движка тебе нужно писать код отдельно для каждой из существующих видеокарт?
Ты вообще не представляешь, что такое кросс-платформенная разработка?
Ты берешь либу типа SDL/GLFW и одной строчкой получаешь окошко с контекстом opengl нужной версии. Под любую систему, от кофеварки до телефона, не говоря про десктопы. Ты даже можешь взять bgfx в качестве абстракции графического апи, на винде он будет компилиться под directx, на линуксе/мобилках - под opengl.
Ты пишешь код один раз, и потом компилишь его без изменений под любую платформу. Версий винды не десятки, на дистрибутивы тоже поебать. В 2к19 достаточно одного билда статического бинарника под x64 шин и одного под x64 линукс. Всё.
Вылезай из маня-мира. А то как-то неудобно получается, убеждаешь всех, что без движка невозможно разрабатывать, но при этом фантазируешь, что там надо писать код под тысячи видеокарт. Зачем фантазировать, если ты не пробовал?
>>608290
Вот это дивный маня-мир, давно такого не встречал.
Ты правда думаешь, что при разработке без движка тебе нужно писать код отдельно для каждой из существующих видеокарт?
Ты вообще не представляешь, что такое кросс-платформенная разработка?
Ты берешь либу типа SDL/GLFW и одной строчкой получаешь окошко с контекстом opengl нужной версии. Под любую систему, от кофеварки до телефона, не говоря про десктопы. Ты даже можешь взять bgfx в качестве абстракции графического апи, на винде он будет компилиться под directx, на линуксе/мобилках - под opengl.
Ты пишешь код один раз, и потом компилишь его без изменений под любую платформу. Версий винды не десятки, на дистрибутивы тоже поебать. В 2к19 достаточно одного билда статического бинарника под x64 шин и одного под x64 линукс. Всё.
Вылезай из маня-мира. А то как-то неудобно получается, убеждаешь всех, что без движка невозможно разрабатывать, но при этом фантазируешь, что там надо писать код под тысячи видеокарт. Зачем фантазировать, если ты не пробовал?
>>608338
Да, тебе будет нужно учитывать НЮАНСЫ для каждой из существующих видеокарт.
Для того, чтобы ты понимал, отсылаю к блеклисту хрома. А это всего лишь рендер текста и картиночек.
https://chromium.googlesource.com/chromium/src/gpu/+/master/config/software_rendering_list.json
Началось сектанство, твой bgfx уже везде обоссали, те кто им пользовался как раз ноют от того, что он нихуя не кроссплатформенный, что его внутренний абстрактный язык шейдеров раскрывается на реальном железе в нерабочие конструкции.
Ну конечно, что еще спизданешь? Для XP и для 10-ки нужны разные сборки, более того, в 10-ке есть разные билды, и иногда софт для новых не работает в старых.
Нинужно, ясно-понятно. Бонусом у тебя не будет видимо и андроид версий, тоже нинужно.
Ну если тебе хочется вместо работы над игрой исправлять баги связанные с видеокартами, потому что тебе весь стим засрут отрицательными отзывами не работает - вперед и с песней.
>Ты правда думаешь, что при разработке без движка тебе нужно писать код отдельно для каждой из существующих видеокарт?
Да, тебе будет нужно учитывать НЮАНСЫ для каждой из существующих видеокарт.
Для того, чтобы ты понимал, отсылаю к блеклисту хрома. А это всего лишь рендер текста и картиночек.
https://chromium.googlesource.com/chromium/src/gpu/+/master/config/software_rendering_list.json
>Ты даже можешь взять bgfx
Началось сектанство, твой bgfx уже везде обоссали, те кто им пользовался как раз ноют от того, что он нихуя не кроссплатформенный, что его внутренний абстрактный язык шейдеров раскрывается на реальном железе в нерабочие конструкции.
>Версий винды не десятки,
Ну конечно, что еще спизданешь? Для XP и для 10-ки нужны разные сборки, более того, в 10-ке есть разные билды, и иногда софт для новых не работает в старых.
>на дистрибутивы тоже поебать.
Нинужно, ясно-понятно. Бонусом у тебя не будет видимо и андроид версий, тоже нинужно.
>А то как-то неудобно получается, убеждаешь всех, что без движка невозможно разрабатывать, но при этом фантазируешь, что там надо писать код под тысячи видеокарт.
Ну если тебе хочется вместо работы над игрой исправлять баги связанные с видеокартами, потому что тебе весь стим засрут отрицательными отзывами не работает - вперед и с песней.
блин какая фигня
вот смотри
https://jsfiddle.net/690wuLxa/
это набросок рогалика, я набросал сегодня под влиянием треда. в нем 135 строк кода. можно ходить кроме стен во всех восьми направлениях, можно убить беззащитного монстра и условно собрать лут. алсо удобный ручной левел редактор прямо в том же флаконе лол. дальше можно было бы запилить видимость и небольшую прокрутку экрана например и все такое
чисто как иллюстрация - он будет работать на любом девайсе который поддерживает современный браузер и десктопную клавиатуру. какие нюансы какие нафиг видеокарты лол. я вообще смутно представляю что такое видеокарта. если бы jsfiddle лучше поддерживал мобилки я бы не поленился сделал бы и поддержку таучскринов
вот смотри
https://jsfiddle.net/690wuLxa/
это набросок рогалика, я набросал сегодня под влиянием треда. в нем 135 строк кода. можно ходить кроме стен во всех восьми направлениях, можно убить беззащитного монстра и условно собрать лут. алсо удобный ручной левел редактор прямо в том же флаконе лол. дальше можно было бы запилить видимость и небольшую прокрутку экрана например и все такое
чисто как иллюстрация - он будет работать на любом девайсе который поддерживает современный браузер и десктопную клавиатуру. какие нюансы какие нафиг видеокарты лол. я вообще смутно представляю что такое видеокарта. если бы jsfiddle лучше поддерживал мобилки я бы не поленился сделал бы и поддержку таучскринов
>>608341
Ну-ну.
Нинужно потому, что один статический билд под линукс x64 работает на любом дистрибутиве.
Сейчас бы сравнивать рендер браузера и рогалика.
Опять пошли маня-фантазии. Ни одной программы не написал, зато испугался багов с видеокартами.
Все правильно пишешь, сложна, нивазможна, даже не пробуй ничего писать сам, если пускаешь жидкую подливу в штаны от одних маня-фантазий, даже не написав ни строчки кода. Видимо геймдев это в целом не твоё.
Возьмешь вот юнити тот же, начнешь что-то пилить и наткнешься на какой-нибудь баг в ui подсистеме, сразу пукнешь в штаны. А если краш словишь, вдруг еще сердце не выдержит от испуга.
>XP
>2k19
Ну-ну.
>Нинужно, ясно-понятно.
Нинужно потому, что один статический билд под линукс x64 работает на любом дистрибутиве.
>ля того, чтобы ты понимал, отсылаю к блеклисту хрома.
Сейчас бы сравнивать рендер браузера и рогалика.
>Ну если тебе хочется вместо работы над игрой исправлять баги связанные с видеокартами
Опять пошли маня-фантазии. Ни одной программы не написал, зато испугался багов с видеокартами.
Все правильно пишешь, сложна, нивазможна, даже не пробуй ничего писать сам, если пускаешь жидкую подливу в штаны от одних маня-фантазий, даже не написав ни строчки кода. Видимо геймдев это в целом не твоё.
Возьмешь вот юнити тот же, начнешь что-то пилить и наткнешься на какой-нибудь баг в ui подсистеме, сразу пукнешь в штаны. А если краш словишь, вдруг еще сердце не выдержит от испуга.
и да, тайлы тоже несложно прикрутить при желании
>>608345
Рогалики всегда славились тем, что могут работать даже в терминале, даже в досе, а твой не может работать нигде ниже win7/10 - вот это реально "ну-ну". Вопрос - а нахуя такой самописный движок нужен тогда?
Линуксоиды тебе просто у виска пальцем покрутят, ну да ладно, линукс же нинужно.
И что же в них такого, почему их нельзя сравнивать? Картинки и текст там и там.
Ну все пошли проекции. Иди пиши движки, в /pr например, никто тебе не запрещает. А тут люди игры делают.
>XP
>2k19
Рогалики всегда славились тем, что могут работать даже в терминале, даже в досе, а твой не может работать нигде ниже win7/10 - вот это реально "ну-ну". Вопрос - а нахуя такой самописный движок нужен тогда?
> один статический билд под линукс x64 работает на любом дистрибутиве.
Линуксоиды тебе просто у виска пальцем покрутят, ну да ладно, линукс же нинужно.
>Сейчас бы сравнивать рендер браузера и рогалика.
И что же в них такого, почему их нельзя сравнивать? Картинки и текст там и там.
> Ни одной программы не написал, зато испугался багов с видеокартами.
>пускаешь жидкую подливу в штаны от одних маня-фантазий, даже не написав ни строчки кода.
Ну все пошли проекции. Иди пиши движки, в /pr например, никто тебе не запрещает. А тут люди игры делают.
>>608344
Браузерка это конечно вариант.
Там, естественно, будут свои проблемы, не с видеокартами, а с браузерами. Например, с тем же масштабированием игры под размер окна. Или чтобы работало во всех браузерах, на разных мобильных устройствах, с разным увеличением шрифта, с разным адблоками, и т.д. (уже предвижу нинужно)
Браузерка это конечно вариант.
Там, естественно, будут свои проблемы, не с видеокартами, а с браузерами. Например, с тем же масштабированием игры под размер окна. Или чтобы работало во всех браузерах, на разных мобильных устройствах, с разным увеличением шрифта, с разным адблоками, и т.д. (уже предвижу нинужно)
>>608351
Те кто ебется в очко и любит быть обоссаным, всегда славились тем, что носят обувь и верхнюю одежду.
НИКТО ТЕБЕ НЕ ЗАПРЕЩАЕТ
@
[ЗАПРЕЩАЕТ]
В голос, какой же кал у тебя в голове
мимо
>Рогалики всегда славились тем
Те кто ебется в очко и любит быть обоссаным, всегда славились тем, что носят обувь и верхнюю одежду.
>Иди пиши движки, в /pr например, никто тебе не запрещает.
НИКТО ТЕБЕ НЕ ЗАПРЕЩАЕТ
@
[ЗАПРЕЩАЕТ]
В голос, какой же кал у тебя в голове
мимо
>>608355
Ты блядь поехавший нахуй, ты просто высрал рандомные слова, а аргументы требуешь с меня, проорал.
Ты блядь поехавший нахуй, ты просто высрал рандомные слова, а аргументы требуешь с меня, проорал.
>>608356
А, ну так ты сразу бы сказал, что тупой. Давай объясню:
1. То, что рогалики «всегда славились» тем что запускаются даже в терминале, это вообще ничего не значит. Ради примера я привёл тебе маргиналов, которые точно так же носят как и ты, одежду, и обувь, но это не делает тебя таким же маргиналом, ведь нужны какие-то более конкретные признаки. В случае с рогаликами, это берлинская интерпретация (о терминале там ни слова)
2. В одном и том же предложении ты запрещаешь (якобы написание игрового движка, это видите ли не написание самой игры) и сразу же пишешь «никто тебе не запрещает»
А, ну так ты сразу бы сказал, что тупой. Давай объясню:
1. То, что рогалики «всегда славились» тем что запускаются даже в терминале, это вообще ничего не значит. Ради примера я привёл тебе маргиналов, которые точно так же носят как и ты, одежду, и обувь, но это не делает тебя таким же маргиналом, ведь нужны какие-то более конкретные признаки. В случае с рогаликами, это берлинская интерпретация (о терминале там ни слова)
2. В одном и том же предложении ты запрещаешь (якобы написание игрового движка, это видите ли не написание самой игры) и сразу же пишешь «никто тебе не запрещает»
>>608359
Ты наверное первокурсник или что-то типа того, короче молодой еще и аутично все воспринимаешь буквально. ну давай смахнемся.
1. Рогалики в терминале - это не маргинальность, а мейнстрим. Возможно ты называешь рогаликами рогалайты, но это уже твоя проблема, поскольку у рогаликов довольно четкое определение. И большинство топовых рогаликов запускается в терминале (brogue, dcss, nethack, adom и т.д.)
2. Вот именно что никто ему не запрещает, я же прямым текстом говорю флаг в руки, пиши движок и трать на его поддержку больше времени, чем на написание игры на готовом движке, кто против то? Покажи в каком посте я написал "не сметь, запрещено, не имеешь право" и я сожру какое-нибудь гавно с пруфами.
Ты наверное первокурсник или что-то типа того, короче молодой еще и аутично все воспринимаешь буквально. ну давай смахнемся.
1. Рогалики в терминале - это не маргинальность, а мейнстрим. Возможно ты называешь рогаликами рогалайты, но это уже твоя проблема, поскольку у рогаликов довольно четкое определение. И большинство топовых рогаликов запускается в терминале (brogue, dcss, nethack, adom и т.д.)
2. Вот именно что никто ему не запрещает, я же прямым текстом говорю флаг в руки, пиши движок и трать на его поддержку больше времени, чем на написание игры на готовом движке, кто против то? Покажи в каком посте я написал "не сметь, запрещено, не имеешь право" и я сожру какое-нибудь гавно с пруфами.
>>608365
Вот тебе тобой же написанный текст:
то есть ты буквально говоришь человеку уйти в другой раздел, потому что «тут люди игры делают»
>Вот именно что никто ему не запрещает, я же прямым текстом говорю флаг в руки, пиши движок и трать на его поддержку больше времени, чем на написание игры на готовом движке, кто против то? Покажи в каком посте я написал "не сметь, запрещено, не имеешь право" и я сожру какое-нибудь гавно с пруфами.
Вот тебе тобой же написанный текст:
>Ну все пошли проекции. Иди пиши движки, в /pr например, никто тебе не запрещает. А тут люди игры делают.
то есть ты буквально говоришь человеку уйти в другой раздел, потому что «тут люди игры делают»
>>608365
А это не одно и то же? Можно объяснения по этому поводу?
>Возможно ты называешь рогаликами рогалайты
А это не одно и то же? Можно объяснения по этому поводу?
>>608370
Никто не запрещает ему в /pr писать движки, а тут запрещают, потому что «тут люди игры делают. На структуру предложения посмотри, даун. Ты либо тупой настолько, что не смог предложение правильно построить, либо не очень, но все же тупой, ведь сейчас так тухло увиливаешь
Никто не запрещает ему в /pr писать движки, а тут запрещают, потому что «тут люди игры делают. На структуру предложения посмотри, даун. Ты либо тупой настолько, что не смог предложение правильно построить, либо не очень, но все же тупой, ведь сейчас так тухло увиливаешь
>>608368
Немного лень, вон анон выше писал про берлинскую интерпретацию, можно сказать так: была игра rogue, рогалики это rogue-like, т.е. похожие на нее, а roguelite это roguelike-like, т.е. похожие на рогалик, но не имеющие каких то ключевых моментов, или слишком сильно изменившие механику или дизайн.
Например, Faster Than Lite часто записывают в рогалики, но ведь всем понятно что это не рогалик, ты же не чистишь пещеры, лол. Это чисто маркетинг.
Немного лень, вон анон выше писал про берлинскую интерпретацию, можно сказать так: была игра rogue, рогалики это rogue-like, т.е. похожие на нее, а roguelite это roguelike-like, т.е. похожие на рогалик, но не имеющие каких то ключевых моментов, или слишком сильно изменившие механику или дизайн.
Например, Faster Than Lite часто записывают в рогалики, но ведь всем понятно что это не рогалик, ты же не чистишь пещеры, лол. Это чисто маркетинг.
>>608371
Предложение составлено тонко, а в том что ты его так интерпретируешь виноват только ты сам :3 Нигде не сказано что движки делают только в /pr.
Предложение составлено тонко, а в том что ты его так интерпретируешь виноват только ты сам :3 Нигде не сказано что движки делают только в /pr.
>>608371
Кстати ты тож маневрируешь, изначально то ты утверждал что "вообще" запрещают.
>а тут запрещают,
>тут
Кстати ты тож маневрируешь, изначально то ты утверждал что "вообще" запрещают.
>>608373
Достаточно того, что сказано, что их не делают в gd
>Нигде не сказано что движки делают только в /pr.
Достаточно того, что сказано, что их не делают в gd
>>608374
Ты уже дрожащими руками промахиваешься кому ответить?
Ты уже дрожащими руками промахиваешься кому ответить?
>>607974
Ебать, поясни конкретнее, такое рил возможно? Вот захочу я въебать овер 100 сущностей на карте, у каждого из которых будет свои инвентари и сложная анатомия, разве это возможно чтобы двигло и проц эту всю хуйню вывозили? я просто смотрю на те же Дварф фортерсы и котяклизьмы, там что-то подобных совсем не пахнет.
>На ecs с хитрыми оптимизациями симулировать сотни тысяч сущностей вообще не проблема, даже на не самом топовом железе.
Ебать, поясни конкретнее, такое рил возможно? Вот захочу я въебать овер 100 сущностей на карте, у каждого из которых будет свои инвентари и сложная анатомия, разве это возможно чтобы двигло и проц эту всю хуйню вывозили? я просто смотрю на те же Дварф фортерсы и котяклизьмы, там что-то подобных совсем не пахнет.
>>608352
я выше писал что проблемы с железом решает среда. это не уникально для браузерки, например пишешь под андроид их решили бы андроид специфичные библиотеки. это слишком низкоуровневые проблемы чтобы большинству кодеров интересоваться ими
это элементарный веб дизайн, адаптивная верстка, это все обычнейшие вещи которые решает создатель любой веб странички (и тут им даже фреймворки не помогают)
будет. я написал сейчас в es6, он поддерживается всеми браузерами кроме осла, но совсем несложно транслировать в es5 и поддержать даже дрова мамонта
для поддержки мобилок надо всего лишь добавить поддержку таучскринов, это несложно, ещё один ивент листенер, надо только придумать как именно юзер будет использовать пальцы, т.к. просто таскать героя по экрану пальцем ему конечно нельзя позволять, надо или регистрировать пуш и вычислять в какую сторону двинуть героя чтобы он шёл к точке пуша, или делать дрэг не более чем на а одну клетку за раз, или делать визуальные кнопочки перемещения для мобилок (для действий все-равно придётся т.к. мобильные клавиатуры не фигачат кейдаун ивенты)
вот, это проблема, но её никакой игровой фреймворк не решит, монетизировать браузерный рогалик наверное сложно. можно сделать отслеживалку адблока, которая лочила бы страницу с просьбой отключить адблок, боюсь так можно многих распугать, плюс надо платить за сервер и все равно много не набежит, наверное
для монетизации я бы в react native скорее писал бы и выложил в гугл плей
я выше писал что проблемы с железом решает среда. это не уникально для браузерки, например пишешь под андроид их решили бы андроид специфичные библиотеки. это слишком низкоуровневые проблемы чтобы большинству кодеров интересоваться ими
> Например, с тем же масштабированием игры под размер окна.
>с разным увеличением шрифта
это элементарный веб дизайн, адаптивная верстка, это все обычнейшие вещи которые решает создатель любой веб странички (и тут им даже фреймворки не помогают)
>Или чтобы работало во всех браузерах
будет. я написал сейчас в es6, он поддерживается всеми браузерами кроме осла, но совсем несложно транслировать в es5 и поддержать даже дрова мамонта
>на разных мобильных устройствах
для поддержки мобилок надо всего лишь добавить поддержку таучскринов, это несложно, ещё один ивент листенер, надо только придумать как именно юзер будет использовать пальцы, т.к. просто таскать героя по экрану пальцем ему конечно нельзя позволять, надо или регистрировать пуш и вычислять в какую сторону двинуть героя чтобы он шёл к точке пуша, или делать дрэг не более чем на а одну клетку за раз, или делать визуальные кнопочки перемещения для мобилок (для действий все-равно придётся т.к. мобильные клавиатуры не фигачат кейдаун ивенты)
>с разным адблоками, и т.д.
вот, это проблема, но её никакой игровой фреймворк не решит, монетизировать браузерный рогалик наверное сложно. можно сделать отслеживалку адблока, которая лочила бы страницу с просьбой отключить адблок, боюсь так можно многих распугать, плюс надо платить за сервер и все равно много не набежит, наверное
для монетизации я бы в react native скорее писал бы и выложил в гугл плей
>>608415
Верно, а при написании своего движка придется в этом разбираться. Потому что именно он будет мостом между игровой логикой и средой, называй как хочешь.
На словах у всех все элементарно, лол, а потом везде ничего не влезает и вылезают скроллбары по бокам.
Смотря каких фич ты туда надобавляешь, например нет гарантии что это будет работать на встроенном браузере андроида 4.4
Не только, например еще придется повоевать с вылезающими тулбарами сверху и снизу.
А я не в плане монетизации говорил, а в плане технической работы, у разных людей в разных браузерах стоят разные дополнения, которые могут резать всякий контент от чего верстка поедет.
>это слишком низкоуровневые проблемы чтобы большинству кодеров интересоваться ими
Верно, а при написании своего движка придется в этом разбираться. Потому что именно он будет мостом между игровой логикой и средой, называй как хочешь.
>это элементарный веб дизайн, адаптивная верстка, это все обычнейшие вещи которые решает создатель любой веб странички
На словах у всех все элементарно, лол, а потом везде ничего не влезает и вылезают скроллбары по бокам.
>я написал сейчас в es6, он поддерживается всеми браузерами
Смотря каких фич ты туда надобавляешь, например нет гарантии что это будет работать на встроенном браузере андроида 4.4
>для поддержки мобилок надо всего лишь добавить
Не только, например еще придется повоевать с вылезающими тулбарами сверху и снизу.
>монетизировать
А я не в плане монетизации говорил, а в плане технической работы, у разных людей в разных браузерах стоят разные дополнения, которые могут резать всякий контент от чего верстка поедет.
>>608396
я видел сотни существ на карте и достаточно сложных хотя анатомии у них толком не было иирк. инвентари, куча скиллов и итемов и они друг с другом дрались ещё под управлением компьютера
incursion та же
только все шансы что на плюсах это у тебя будет течь и глючить как все та же incursion
я видел сотни существ на карте и достаточно сложных хотя анатомии у них толком не было иирк. инвентари, куча скиллов и итемов и они друг с другом дрались ещё под управлением компьютера
incursion та же
только все шансы что на плюсах это у тебя будет течь и глючить как все та же incursion
>>608419
А при чём тут плюсы, если не секрет? Может это просто скорее вопрос оптимизации, кода?
А при чём тут плюсы, если не секрет? Может это просто скорее вопрос оптимизации, кода?
>>608423
мне показалось тот анон который интересуется сложной симуляцией - плюсовик и я его предупреждаю что на плюсах это может быть непросто, это сложный язык
мне показалось тот анон который интересуется сложной симуляцией - плюсовик и я его предупреждаю что на плюсах это может быть непросто, это сложный язык
>>608426
Если брать с++11 и делать без raw указателей, то не так уж и страшно в наши дни.
Если брать с++11 и делать без raw указателей, то не так уж и страшно в наши дни.
>>608426
Да, это я, и я предполагал С++, но я подводных не знаю. В каком образе он непростой? И ты можешь порекомендовать что-то лучше?
Да, это я, и я предполагал С++, но я подводных не знаю. В каком образе он непростой? И ты можешь порекомендовать что-то лучше?
>>608351
Схуяли? Как раз таки рогалик на моём самописном движке сможет работать где угодно. Я могу запилить логику в бэкенде + фроненд под терминал, под дос, подо что угодно. Могу поддерживать любые системы.
А на готовом движке ты соснешь хуйца, тот же юнити под xp без костылей не заведется, насколько знаю.
> а твой не может работать нигде ниже win7/10 - вот это реально "ну-ну".
Схуяли? Как раз таки рогалик на моём самописном движке сможет работать где угодно. Я могу запилить логику в бэкенде + фроненд под терминал, под дос, подо что угодно. Могу поддерживать любые системы.
А на готовом движке ты соснешь хуйца, тот же юнити под xp без костылей не заведется, насколько знаю.
>>608351
Спешите видеть, манька не знает, что такое статическая линковка. И линукс наверное видела только на картинках. Зато с умным видом кудахтает что-то от имени линуксоидов.
Потому что это абсолютно разные по сложности, объему и принципу работы вещи, в принципе не сравниваемые. Рендер браузера во много раз сложнее рендера любой 2д игры, не обязательно текстовой, dom-дерево отрендерить со всеми css правилами это не хуй собачий.
В общем, можешь продолжать подливиться и дристать себе на лицо, но посоветую тебе проследовать в юнити тред и там кудахтать.
>Линуксоиды тебе просто у виска пальцем покрутят, ну да ладно, линукс же нинужно.
Спешите видеть, манька не знает, что такое статическая линковка. И линукс наверное видела только на картинках. Зато с умным видом кудахтает что-то от имени линуксоидов.
>И что же в них такого, почему их нельзя сравнивать? Картинки и текст там и там.
Потому что это абсолютно разные по сложности, объему и принципу работы вещи, в принципе не сравниваемые. Рендер браузера во много раз сложнее рендера любой 2д игры, не обязательно текстовой, dom-дерево отрендерить со всеми css правилами это не хуй собачий.
В общем, можешь продолжать подливиться и дристать себе на лицо, но посоветую тебе проследовать в юнити тред и там кудахтать.
>>608365
Боюсь спросить, как ты собрался рогалик на юнити запускать в терминале.
>И большинство топовых рогаликов запускается в терминале
>чем на написание игры на готовом движке, кто против то
Боюсь спросить, как ты собрался рогалик на юнити запускать в терминале.
>>608437
Если хочешь по хардкору упороться, то для рогалика с тяжелой симуляцией мира rust лучше С++ по всем параметрам.
Там в принципе невозможен ряд проблем, которые бывают с плюсами - утечки памяти, сегфолты. При этом, код летает так же быстро. Но придется вложить время в изучение.
Если хочешь по хардкору упороться, то для рогалика с тяжелой симуляцией мира rust лучше С++ по всем параметрам.
Там в принципе невозможен ряд проблем, которые бывают с плюсами - утечки памяти, сегфолты. При этом, код летает так же быстро. Но придется вложить время в изучение.
>>608437
Тяжело тогда придется.
Самые быстрые языки это C/C++/Rust. Но они и сложные.
А из остальных пофиг что брать, C#/Java/Go/JS/Swift они там примерно одинаковы по скорости. Только питон медленнее.
>С++, но я подводных не знаю.
Тяжело тогда придется.
>можешь порекомендовать что-то лучше?
Самые быстрые языки это C/C++/Rust. Но они и сложные.
А из остальных пофиг что брать, C#/Java/Go/JS/Swift они там примерно одинаковы по скорости. Только питон медленнее.
>>608454
Вот когда напишешь и отладишь под все платформы, тогда и приходи. Может поддерживать он, лол.
Вот когда напишешь и отладишь под все платформы, тогда и приходи. Может поддерживать он, лол.
>>608461
А ты когда на готовом движке сделаешь хоть что-то, тоже приходи.
А ты когда на готовом движке сделаешь хоть что-то, тоже приходи.
>>608458
что-то ты меня заинтересовал, я когда-то учил си и мне интересно как это язык быстрый без проблем ручного управления памятью, надо почитать о нём
мимо другой анон
>Там в принципе невозможен ряд проблем, которые бывают с плюсами - утечки памяти, сегфолты
что-то ты меня заинтересовал, я когда-то учил си и мне интересно как это язык быстрый без проблем ручного управления памятью, надо почитать о нём
мимо другой анон
>>608456
Ты прям все ядро с собой прилинкуешь, и никаких системных вызовов делать не будешь, а рисовать и ввод делать будет святой дух, ясно-понятно. Если бы все было так просто как ты говоришь, то всякие вальвы бы так и релизили, но однако же это так не работает.
Нет, это не так.
Нет, не сложнее, 2д игры это несколько слоев с разным параллаксом, динамическое освещение, деревья сцен и объектов, ровно то же самое.
А вот это показывает, что ты тупой даун и вообще не понимаешь, о чем шла речь. Я где-то писал о разборе dom и css? Нет, я писал только о том, что когда рендерят то, что уже разобрано, в opengl и подобном, глючит на реальном железе и драйверах.
Свободен.
>Спешите видеть, манька не знает, что такое статическая линковка.
Ты прям все ядро с собой прилинкуешь, и никаких системных вызовов делать не будешь, а рисовать и ввод делать будет святой дух, ясно-понятно. Если бы все было так просто как ты говоришь, то всякие вальвы бы так и релизили, но однако же это так не работает.
>Потому что это абсолютно разные по сложности, объему и принципу работы вещи, в принципе не сравниваемые.
Нет, это не так.
>. Рендер браузера во много раз сложнее рендера любой 2д игры
Нет, не сложнее, 2д игры это несколько слоев с разным параллаксом, динамическое освещение, деревья сцен и объектов, ровно то же самое.
> dom-дерево отрендерить со всеми css правилами это не хуй собачий.
А вот это показывает, что ты тупой даун и вообще не понимаешь, о чем шла речь. Я где-то писал о разборе dom и css? Нет, я писал только о том, что когда рендерят то, что уже разобрано, в opengl и подобном, глючит на реальном железе и драйверах.
Свободен.
>>608463
Это пиздец ебанутый язык, тебе там придется управлять временем жизни, и уговаривать компилятор собрать хоть что нибудь, короче мем уровня хаскеля, делать на нем конечно ничего не возможно, а учить наверное дольше чем c++ раз в 10.
Это пиздец ебанутый язык, тебе там придется управлять временем жизни, и уговаривать компилятор собрать хоть что нибудь, короче мем уровня хаскеля, делать на нем конечно ничего не возможно, а учить наверное дольше чем c++ раз в 10.
>>608465
Ну да, а посоны-то и не знали. Уже овердохуя компаний юзает его в продакшене.
https://www.rust-lang.org/production/users
Я так понял, что для тебя всё, что не юнити и все, где нельзя таскать ассеты по сценке - пиздец ебанутое. Можешь не продолжать.
>>608464
Я даже разбирать это не буду, бред шизофреника, видевшего линукс только на картинке и не понимающего смысла слов, которые он пишет.
Вот тебе пример статического бинарника, который просто качается и запускается на любом дистрибутиве.
https://godotengine.org/download/linux
Нет, это так. Можешь посмотреть исходники какого-нибудь хромиума, там один рендеринг по объему кода больше чем весь условный годот.
А вот это показывает, что ты тупой даун и вообще не понимаешь, о чем шла речь. Я где-то писал о разборе слоёв и паралакса, и дерева сцен? Нет, я писал только о том, что когда рендерят то, что уже разобрано, в opengl и подобном, глючит на реальном железе и драйверах.
В общем, обдристался ты знатно, лучше не продолжай дальше позориться.
Не переживай, это анонимный форум, никто не запомнит твой обсёр, так что можешь расслабиться и перестать усираться в ответ.
>делать на нем конечно ничего не возможно
Ну да, а посоны-то и не знали. Уже овердохуя компаний юзает его в продакшене.
https://www.rust-lang.org/production/users
>Это пиздец ебанутый язык
Я так понял, что для тебя всё, что не юнити и все, где нельзя таскать ассеты по сценке - пиздец ебанутое. Можешь не продолжать.
>>608464
>Ты прям все ядро с собой прилинкуешь, и никаких системных вызовов делать не будешь, а рисовать и ввод делать будет святой дух, ясно-понятно.
Я даже разбирать это не буду, бред шизофреника, видевшего линукс только на картинке и не понимающего смысла слов, которые он пишет.
Вот тебе пример статического бинарника, который просто качается и запускается на любом дистрибутиве.
https://godotengine.org/download/linux
>Нет, это не так.
Нет, это так. Можешь посмотреть исходники какого-нибудь хромиума, там один рендеринг по объему кода больше чем весь условный годот.
>Нет, не сложнее, 2д игры это несколько слоев с разным параллаксом, динамическое освещение, деревья сцен и объектов, ровно то же самое.
А вот это показывает, что ты тупой даун и вообще не понимаешь, о чем шла речь. Я где-то писал о разборе слоёв и паралакса, и дерева сцен? Нет, я писал только о том, что когда рендерят то, что уже разобрано, в opengl и подобном, глючит на реальном железе и драйверах.
В общем, обдристался ты знатно, лучше не продолжай дальше позориться.
Не переживай, это анонимный форум, никто не запомнит твой обсёр, так что можешь расслабиться и перестать усираться в ответ.
>>608469
Его юзают професси_аналы с з/п от 200к рублей, причем тут 2ch gd?
>Ну да, а посоны-то и не знали. Уже овердохуя компаний юзает его в продакшене.
Его юзают професси_аналы с з/п от 200к рублей, причем тут 2ch gd?
>>608470
звучит как повод выучить раст лол
вангую впрочем что туда сложно вкатиться и большинство борщехлебы на низкой зп
звучит как повод выучить раст лол
вангую впрочем что туда сложно вкатиться и большинство борщехлебы на низкой зп
>>608470
Ну ты изначально спизданул что-то про язык-мем и что на нём ничего нельзя сделать, а теперь пытаешься оправдаться и соскочить за счет того, что на 2ch gd не может сидеть профессиональный программист.
Ну ты изначально спизданул что-то про язык-мем и что на нём ничего нельзя сделать, а теперь пытаешься оправдаться и соскочить за счет того, что на 2ch gd не может сидеть профессиональный программист.
>>608471
Раст для вката в айти не подходит, никому джуны на расте не нужны, его юзают как второй язык бэкендщики с опытом, когда у плюсов не хватает безопасности, а у какой-нибудь джавы скорости.
А для программирования для души он отлично подходит, в том числе и для геймдева. Много обучающих материалов, удобная экосистема, пакетный менеджер.
Раст для вката в айти не подходит, никому джуны на расте не нужны, его юзают как второй язык бэкендщики с опытом, когда у плюсов не хватает безопасности, а у какой-нибудь джавы скорости.
А для программирования для души он отлично подходит, в том числе и для геймдева. Много обучающих материалов, удобная экосистема, пакетный менеджер.
>>608471
Выучи, если сможешь. Там и игровые движки уже есть так то.
Выучи, если сможешь. Там и игровые движки уже есть так то.
>>608472
Так и на Хаскеле несколько человек в мире пишет всякую телефонию, но для большинства он иначе как мемом не является.
Так и на Хаскеле несколько человек в мире пишет всякую телефонию, но для большинства он иначе как мемом не является.
>>608477
Я надеюсь, что это троллинг тупостью, потому что если у тебя на полном серьёзе такое в голове, то это даже немного грустно.
>приравнивать несколько человек и несколько сотен компаний уровня mozilla, dropbox, atlassian, cloudflare, npm
Я надеюсь, что это троллинг тупостью, потому что если у тебя на полном серьёзе такое в голове, то это даже немного грустно.
>>608481
А в чем ты усматриваешь противоречие? В mozilla, dropbox, npm и т.д тоже не все на расте пишут, наверное это очевидно, что там тоже всего несколько человек этим занимается?
У хаскеля тоже есть именитые компании
Напрмер Intel, nvidia, qualcomm, AT&T, пара банков америки и т.д.
https://wiki.haskell.org/Haskell_in_industry
А в чем ты усматриваешь противоречие? В mozilla, dropbox, npm и т.д тоже не все на расте пишут, наверное это очевидно, что там тоже всего несколько человек этим занимается?
У хаскеля тоже есть именитые компании
Напрмер Intel, nvidia, qualcomm, AT&T, пара банков америки и т.д.
https://wiki.haskell.org/Haskell_in_industry
>>608469
А тут даже и видеть линукс не надо, качаем твою годотю, открываем в readelf, читаем вывод. Опа, ты пиздабол, NEEDED libc и прочее конкретной версии. Вот тебе и "все" дистры в пролете.
Раздутость хрома как аргумент? Нет пути! ну давай сравнивать, ой, как же так, размер годотю которую ты скинул такой же как у хромиум эмбеддед, надо же оказывается ты опять напиздел!
А, ты решил паясничать, клоун, ну окей. Тогда и в хроме нет никаких dom и css а есть только текст и картинки.
Хорошо что ты наконец признал, что на реальном железе и драйерах глючит и движкописателю с этим разбираться.
Пока что обсираешься только ты, шизюнь.
>Вот тебе пример статического бинарника, который просто качается и запускается на любом дистрибутиве.
А тут даже и видеть линукс не надо, качаем твою годотю, открываем в readelf, читаем вывод. Опа, ты пиздабол, NEEDED libc и прочее конкретной версии. Вот тебе и "все" дистры в пролете.
>Нет, это так. Можешь посмотреть исходники какого-нибудь хромиума, там один рендеринг по объему кода больше чем весь условный годот.
Раздутость хрома как аргумент? Нет пути! ну давай сравнивать, ой, как же так, размер годотю которую ты скинул такой же как у хромиум эмбеддед, надо же оказывается ты опять напиздел!
>А вот это показывает, что ты тупой даун и вообще не понимаешь, о чем шла речь. Я где-то писал о разборе слоёв и паралакса, и дерева сцен?
А, ты решил паясничать, клоун, ну окей. Тогда и в хроме нет никаких dom и css а есть только текст и картинки.
>Нет, я писал только о том, что когда рендерят то, что уже разобрано, в opengl и подобном, глючит на реальном железе и драйверах.
Хорошо что ты наконец признал, что на реальном железе и драйерах глючит и движкописателю с этим разбираться.
>В общем, обдристался ты знатно, лучше не продолжай дальше позориться.
>Не переживай, это анонимный форум, никто не запомнит твой обсёр, так что можешь расслабиться и перестать усираться в ответ.
Пока что обсираешься только ты, шизюнь.
>>608483
Ничего серьезного там на хаскеле не пишут. Какие-то энтузиасты по недосмотру начальства пишут всякую мелочь типа утилит и генераторов отчетов.
На одной из моих прошлых работ у нас был человек, который написал утилиту на F#, правда никто кроме него ей не пользовался и когда он ушел про нее забыли. Вот примерно на таком уровне весь этот haskell in industry и находится
>Напрмер Intel, nvidia, qualcomm, AT&T, пара банков америки и т.д.
Ничего серьезного там на хаскеле не пишут. Какие-то энтузиасты по недосмотру начальства пишут всякую мелочь типа утилит и генераторов отчетов.
На одной из моих прошлых работ у нас был человек, который написал утилиту на F#, правда никто кроме него ей не пользовался и когда он ушел про нее забыли. Вот примерно на таком уровне весь этот haskell in industry и находится
>>608492
Ну вот и раст примерно такой же.
F# охуенный, да. Классный паттерн матчинг, функциональщина, и при этом вся мощь дотнета на кончиках пальцев. Когда годот научится в экспорт c# в emscripten, я сразу перейду на него и прикручу.
Ну вот и раст примерно такой же.
F# охуенный, да. Классный паттерн матчинг, функциональщина, и при этом вся мощь дотнета на кончиках пальцев. Когда годот научится в экспорт c# в emscripten, я сразу перейду на него и прикручу.
17 Кб, 400x400>>608460
На сложность пiхуй, я готов въебать и наебать и того сего нахуй, динамическая память тыры пыры ебать делать, в общем под завязку обмазаться этим языком, если как говорите они сложные только, то всё тогда хорошо.
>>608458
Опять же, время на изучение это всё ничто для меня, вот о ряде проблем хотелось бы знать заранее, как избежать их?
-Про уточки памяти я знаю вроде только в общих чертах, но не знаю пока когда они возникают (при ебланском использовании динамической памяти, и не уборке за собой?)
- Про сегфорты не знаю вообще. Разъясните позюзя...
>Тяжело тогда придется.
>Самые быстрые языки это C/C++/Rust. Но они и сложные.
На сложность пiхуй, я готов въебать и наебать и того сего нахуй, динамическая память тыры пыры ебать делать, в общем под завязку обмазаться этим языком, если как говорите они сложные только, то всё тогда хорошо.
>>608458
Опять же, время на изучение это всё ничто для меня, вот о ряде проблем хотелось бы знать заранее, как избежать их?
-Про уточки памяти я знаю вроде только в общих чертах, но не знаю пока когда они возникают (при ебланском использовании динамической памяти, и не уборке за собой?)
- Про сегфорты не знаю вообще. Разъясните позюзя...
>>608538
Я этот термин не слышал
Я этот термин не слышал
>>608535
Типа того, когда например вызываешь new для какого-то временного буфера в цикле, а потом не вызываешь delete. И когда выходишь из этого цикла, ты теряешь указатель на эту область и уже ничего не можешь с ней сделать, она остается выделенной.
Но в современном С++ это уже не проблема, можно написать 99% программ вообще без ручного выделения памяти через new, с помощью RAII, умных указателей, стандартных структур типа вектора, и т.д.
Сегфолты возникают тоже при ручной работе с памятью, когда ошибся указателем и лезешь в недоступную область памяти, или пытаешься записать в read-only память.
В расте такие ошибки в принципе невозможны, программа с ними просто не скомпилится.
> (при ебланском использовании динамической памяти, и не уборке за собой?)
Типа того, когда например вызываешь new для какого-то временного буфера в цикле, а потом не вызываешь delete. И когда выходишь из этого цикла, ты теряешь указатель на эту область и уже ничего не можешь с ней сделать, она остается выделенной.
Но в современном С++ это уже не проблема, можно написать 99% программ вообще без ручного выделения памяти через new, с помощью RAII, умных указателей, стандартных структур типа вектора, и т.д.
Сегфолты возникают тоже при ручной работе с памятью, когда ошибся указателем и лезешь в недоступную область памяти, или пытаешься записать в read-only память.
В расте такие ошибки в принципе невозможны, программа с ними просто не скомпилится.
>>608609
Ну впринципе это еще хуйня, то есть банально быть внимательным и уже как бы эти ошибки отсечены. Еще какие-то подводные камни крестов?
Ну впринципе это еще хуйня, то есть банально быть внимательным и уже как бы эти ошибки отсечены. Еще какие-то подводные камни крестов?
224 Кб, 870x400>>608486
А посоны-то и не знали. Они спокойно юзали бинарник годота на любом дистрибутиве, но тут пришла чмоня с двача и сказал, что они все оказывается в пролёте
Ого, ты умеешь читать, неожиданно. Если внимательно почитаешь список библиотек на скрине, то увидишь, что эти библиотеки есть в любой линукс-системе с установленными иксами, т.е. на любом дистрибутиве, кроме серверных.
Опять пиздёж и непонимание, как работает линковка. Привязки к конкретным версиям системных библиотек нет, автоматически будут подхвачены системные либы, установленные в дистрибутиве, независимо от версии.
libc.so.6, например, это не конкретная версия библиотеки, это симлинк на версию, установленную в системе.
libasound.so.2 например в моём дистре резолвится на ALSA_0.9.0rc4, на другом дистре это может быть другая версия.
Я понимаю, что это так весело, спорить на тему, в которой ты нихуя не понимаешь, про операционную систему, которую ты видел только на картинках и мемах из интернета, сидя под виндовсом, но лучше бы ты прекратил дристать себе в штаны на глазах у всей борды.
>Вот тебе и "все" дистры в пролете.
А посоны-то и не знали. Они спокойно юзали бинарник годота на любом дистрибутиве, но тут пришла чмоня с двача и сказал, что они все оказывается в пролёте
>читаем вывод.
Ого, ты умеешь читать, неожиданно. Если внимательно почитаешь список библиотек на скрине, то увидишь, что эти библиотеки есть в любой линукс-системе с установленными иксами, т.е. на любом дистрибутиве, кроме серверных.
>и прочее конкретной версии
Опять пиздёж и непонимание, как работает линковка. Привязки к конкретным версиям системных библиотек нет, автоматически будут подхвачены системные либы, установленные в дистрибутиве, независимо от версии.
libc.so.6, например, это не конкретная версия библиотеки, это симлинк на версию, установленную в системе.
libasound.so.2 например в моём дистре резолвится на ALSA_0.9.0rc4, на другом дистре это может быть другая версия.
Я понимаю, что это так весело, спорить на тему, в которой ты нихуя не понимаешь, про операционную систему, которую ты видел только на картинках и мемах из интернета, сидя под виндовсом, но лучше бы ты прекратил дристать себе в штаны на глазах у всей борды.
>>608615
Это только кажется, что просто. Но весь код просто невозможно контролировать. Вот выделил ты память, потом вызываешь метод из какой-нибудь левой либы, а она бросает эксепшен. Пусть даже у тебя стоит обработчик эксепшенов где-то, ты отловил этот эксепшен, но стек фрейм уже потерян, указатель на выделенную память просран и случилась учетка.
Нет пакетного менеджера, сложно менеджить зависимости, надо либо ставить все либы руками, либо юзать конан, но тогда придется писать под него пакеты, либо пойти по пути годота и тупо переносить исходники зависимостей в свой проект и билдить всё вместе.
Придется разбираться с линковкой, чтобы билдить переносимые бинарники. Ты можешь собрать бинарник, который будет работать у тебя, но пропустить какую-нибудь либу, не вкомпилить её в бинарник, и на другом компе оно не заведется.
Модули пока не завезли, придется ебаться с заголовочными файлами, это не очень удобно, особенно если надо писать темплейты.
В расте всех этих проблем нет, там пакетный менеджер, модули, билд переносимых статических бинарников.
> банально быть внимательным
Это только кажется, что просто. Но весь код просто невозможно контролировать. Вот выделил ты память, потом вызываешь метод из какой-нибудь левой либы, а она бросает эксепшен. Пусть даже у тебя стоит обработчик эксепшенов где-то, ты отловил этот эксепшен, но стек фрейм уже потерян, указатель на выделенную память просран и случилась учетка.
>Еще какие-то подводные камни крестов?
Нет пакетного менеджера, сложно менеджить зависимости, надо либо ставить все либы руками, либо юзать конан, но тогда придется писать под него пакеты, либо пойти по пути годота и тупо переносить исходники зависимостей в свой проект и билдить всё вместе.
Придется разбираться с линковкой, чтобы билдить переносимые бинарники. Ты можешь собрать бинарник, который будет работать у тебя, но пропустить какую-нибудь либу, не вкомпилить её в бинарник, и на другом компе оно не заведется.
Модули пока не завезли, придется ебаться с заголовочными файлами, это не очень удобно, особенно если надо писать темплейты.
В расте всех этих проблем нет, там пакетный менеджер, модули, билд переносимых статических бинарников.
>>608616
Да что же тебе так нравится серить себе на голову, а потом размазывать по своим волосам и лицу говно? Все и так уже поняли что у тебя "работает на всех дистрибутивах" означает "на моей убунте запустилось, УМВР", а то что на других семействах может быть libc другой версии, с другим ABI, тебе естественно невдомек. Ну что тут сказать, если уж даже я, который по твоим словам "видел линукс только на мемах" знает больше тебя, выходит ты ламер хуже червя-пидора и обсуждать с тобой тащемта и нечего.
Да что же тебе так нравится серить себе на голову, а потом размазывать по своим волосам и лицу говно? Все и так уже поняли что у тебя "работает на всех дистрибутивах" означает "на моей убунте запустилось, УМВР", а то что на других семействах может быть libc другой версии, с другим ABI, тебе естественно невдомек. Ну что тут сказать, если уж даже я, который по твоим словам "видел линукс только на мемах" знает больше тебя, выходит ты ламер хуже червя-пидора и обсуждать с тобой тащемта и нечего.
49 Кб, 500x361>>608619
>Да что же тебе так нравится серить себе на голову, а потом размазывать по своим волосам и лицу говно? Все и так уже поняли что у тебя "работает на всех дистрибутивах" означает "на моей убунте запустилось, УМВР", а то что на других семействах может быть libc другой версии, с другим ABI, тебе естественно невдомек. Ну что тут сказать, если уж даже я, который по твоим словам "видел линукс только на мемах" знает больше тебя, выходит ты ламер хуже червя-пидора и обсуждать с тобой тащемта и нечего.
>>608619
Так вроде бы еще с начала девяностых на всех десктопных дистрах стоит libc.so.6.
А в целом, в теории конечно может, у одного процента пердоликов, билдивших линукс из сорцов, или у какого-нибудь любителя некрожелеза. А у 99% юзеров обычных десктопных дистров будет стоять libc.so.6.
Но твою позицию я понял, если твой билд не будет работать у одного пердолика из пяти миллионов обычных пользователей, то это конечно пиздец как хуёво, с таким раскладом лучше вообще ничего не программировать и не компилировать. А то вдруг именно этот пердолик скачает, а у него не запустится, это пиздец как хуёво будет, что посоны подумают.
>, а то что на других семействах может быть libc другой версии, с другим ABI,
Так вроде бы еще с начала девяностых на всех десктопных дистрах стоит libc.so.6.
А в целом, в теории конечно может, у одного процента пердоликов, билдивших линукс из сорцов, или у какого-нибудь любителя некрожелеза. А у 99% юзеров обычных десктопных дистров будет стоять libc.so.6.
Но твою позицию я понял, если твой билд не будет работать у одного пердолика из пяти миллионов обычных пользователей, то это конечно пиздец как хуёво, с таким раскладом лучше вообще ничего не программировать и не компилировать. А то вдруг именно этот пердолик скачает, а у него не запустится, это пиздец как хуёво будет, что посоны подумают.
>>608618
у меня пока синдром утёнка не разрешает перейти на раст, я этот язык мало знаю, и пока не уверен в его скажем так эффективности по сравнению с крестами теми же. А за поясняловую благодарствую
у меня пока синдром утёнка не разрешает перейти на раст, я этот язык мало знаю, и пока не уверен в его скажем так эффективности по сравнению с крестами теми же. А за поясняловую благодарствую
Поясните анончики любимые, смысл срача? Почему всем не придерживаться просто правила -> Хочешь делать игру, берёшь Юнити,Уеч,гейм макер. Хочешь просто кодить -> любой голый язык или веб. Всё, срачи пропадут.
84 Кб, 720x1280>>608638
если ты делаешь рогалик или даже платформер тебе не особо нужен фреймворк вообще
вот поиграй например в платформер в несколько сотен строк https://eloquentjavascript.net/17_canvas.html
пикрил где искать на странице и как запустить, я пишу с мобилы, но там нужен десктоп
в рогаликах от фреймворка вообще мало толку, в платформерах хоть риал тайм физика есть и она более менее универсальная. а в рогалике тайловый пошаговый мир с одной стороны, это несложно в плане перемещения и столкновений, а с другой например я хочу такую вот систему видимости, а фреймворк её делает по другому, короче связывает руки
если ты делаешь рогалик или даже платформер тебе не особо нужен фреймворк вообще
вот поиграй например в платформер в несколько сотен строк https://eloquentjavascript.net/17_canvas.html
пикрил где искать на странице и как запустить, я пишу с мобилы, но там нужен десктоп
в рогаликах от фреймворка вообще мало толку, в платформерах хоть риал тайм физика есть и она более менее универсальная. а в рогалике тайловый пошаговый мир с одной стороны, это несложно в плане перемещения и столкновений, а с другой например я хочу такую вот систему видимости, а фреймворк её делает по другому, короче связывает руки
>>608648
РРРЯЯ НИВАЗМОЖНАЯ ЮПИНИ НАДА БРАТЬ!! НИЛЬЗЯ ТАК, ТЫ САМЫЙ УМНЫЙ ЧТОЛИ? ЮПИТИ ПРИДУМАЛИ, НАДО ЕГО БРАТЬ, ТОЛЬКО В ЮПЕИТИ МОЖНО ДЕЛАТЬ ИГРЫ!!11
РРРЯЯ НИВАЗМОЖНАЯ ЮПИНИ НАДА БРАТЬ!! НИЛЬЗЯ ТАК, ТЫ САМЫЙ УМНЫЙ ЧТОЛИ? ЮПИТИ ПРИДУМАЛИ, НАДО ЕГО БРАТЬ, ТОЛЬКО В ЮПЕИТИ МОЖНО ДЕЛАТЬ ИГРЫ!!11
>>608691
Сорян, в отличие от тебя сосуна я релизю игры и делаю тысячи бакинских в месяц ;)
Сорян, в отличие от тебя сосуна я релизю игры и делаю тысячи бакинских в месяц ;)
>>572542
Сука, ты заебал. Что так сложно ответить почему выбрал такой размер спрайтов?
>спрайты выполнены в размере 21x21
Сука, ты заебал. Что так сложно ответить почему выбрал такой размер спрайтов?
>>608895
Какая разница то лол? Ну выбрал он и выбрал. Нечетный размер позволяет симметрию кстати.
Какая разница то лол? Ну выбрал он и выбрал. Нечетный размер позволяет симметрию кстати.
>>607968
И там и там разные. Ты хоть в код заглядывал, а не в свои фантазии?
>> Поэтому во всех трушных рогаликах игрок и враг это один и тот же класс. Так везде, от dungeon crawl'a до катаклизма.
И там и там разные. Ты хоть в код заглядывал, а не в свои фантазии?
>>609330
Мимокрокодил, заинтересовался. Поясните, какие подводные камни, если сделать класс Персонаж, в котором описать меш, коллизии, анимации движения, от него унаследовать класс "Игрок" в котором описать управление с инпута, и класс "НПЦ" в котором описать управление от ИИ?
Или, если кому неугодно, сделать класс "Персонаж", в котором описать меш, коллизии, анимации движения, а так же задать поле для хранения компонентов, создать класс "Компонент", от него унаследовать класс "Управление", от него унаследовать класс "Игрок" в котором описать управление с инпута, и класс "НПЦ" в котором описать управление от ИИ и объекту "Игрок" класса "Персонаж" накинуть компонент "Игрок"?
Мимокрокодил, заинтересовался. Поясните, какие подводные камни, если сделать класс Персонаж, в котором описать меш, коллизии, анимации движения, от него унаследовать класс "Игрок" в котором описать управление с инпута, и класс "НПЦ" в котором описать управление от ИИ?
Или, если кому неугодно, сделать класс "Персонаж", в котором описать меш, коллизии, анимации движения, а так же задать поле для хранения компонентов, создать класс "Компонент", от него унаследовать класс "Управление", от него унаследовать класс "Игрок" в котором описать управление с инпута, и класс "НПЦ" в котором описать управление от ИИ и объекту "Игрок" класса "Персонаж" накинуть компонент "Игрок"?
>>609366
Ебать ты тупой. Слово "компонент" не нашёл? Или после слова "наследовать" дальшенечитал?
Ебать ты тупой. Слово "компонент" не нашёл? Или после слова "наследовать" дальшенечитал?
>>609360
Если ты захочешь одновременно подключить и управление игроком, и управление ИИ, ты соснул с наследованием. Например, чтобы персонаж автоматом уклонялся от пуль, но при этом можно было контролировать его вручную.
Компоненты в ecs подразумевают модульность, их можно подключать сразу несколько к одной сущности.
Накидываешь компонент брони на сущность шлема, можешь надевать его. Накидываешь еще компонент оружия с колющим уроном - можешь дополнительно бодаться им.
А на ООП ты жидко пукнешь спермой, не зная что от чего наследовать, шлем от оружия или оружие от шлема.
>. Поясните, какие подводные камни, если сделать класс Персонаж, в котором описать меш, коллизии, анимации движения, от него унаследовать класс "Игрок" в котором описать управление с инпута, и класс "НПЦ" в котором описать управление от ИИ?
Если ты захочешь одновременно подключить и управление игроком, и управление ИИ, ты соснул с наследованием. Например, чтобы персонаж автоматом уклонялся от пуль, но при этом можно было контролировать его вручную.
Компоненты в ecs подразумевают модульность, их можно подключать сразу несколько к одной сущности.
Накидываешь компонент брони на сущность шлема, можешь надевать его. Накидываешь еще компонент оружия с колющим уроном - можешь дополнительно бодаться им.
А на ООП ты жидко пукнешь спермой, не зная что от чего наследовать, шлем от оружия или оружие от шлема.
>>609397
В ecs ты точно так же жидко пукаешь, если у тебя коллизия между полями компонентов. Мозг в любом случае придется юзать, чтобы выделять и именовать сущности. Оружие и шлем очевидно пронаследуются от единицы снаряжения.
В ecs ты точно так же жидко пукаешь, если у тебя коллизия между полями компонентов. Мозг в любом случае придется юзать, чтобы выделять и именовать сущности. Оружие и шлем очевидно пронаследуются от единицы снаряжения.
>>609413
Нет никаких коллизий в нормальном ООП, ты видимо просто нормальный не видел, жертва ECS головного мозга.
У тебя в ecs будет поле снижение урона в броне и снижение урона в шлеме, и ты не будешь знать каким пользоваться - вот уровень твоей аргументации.
Нет никаких коллизий в нормальном ООП, ты видимо просто нормальный не видел, жертва ECS головного мозга.
>"не зная что от чего наследовать, шлем от оружия или оружие от шлема."
У тебя в ecs будет поле снижение урона в броне и снижение урона в шлеме, и ты не будешь знать каким пользоваться - вот уровень твоей аргументации.
>>609360
Если ты спрашиваешь за код тех проектов, то так не делали, т.к. у тех же зомби в кате нет кучи параметров, что есть у персонажа, которые им вообще не нужны или делают симуляцию избыточной, что отжирает ресурсы, которые перенаправляют на что-то более полезное.
Да, это красивая история про то, что можно давать управление персонажа компу, но почти всегда это не оправдано больше ничем, кроме просто затем, чтобы было.
Про то, что ты описал - выше уже сказали, что лучше сделать через ecs. У тебя будет компонент отображения: меш, анимации, частицы.. компонент контроллер: игрок/ии.. все это компоненты какой-то сущности будут, например, персонаж.
Если ты спрашиваешь за код тех проектов, то так не делали, т.к. у тех же зомби в кате нет кучи параметров, что есть у персонажа, которые им вообще не нужны или делают симуляцию избыточной, что отжирает ресурсы, которые перенаправляют на что-то более полезное.
Да, это красивая история про то, что можно давать управление персонажа компу, но почти всегда это не оправдано больше ничем, кроме просто затем, чтобы было.
Про то, что ты описал - выше уже сказали, что лучше сделать через ecs. У тебя будет компонент отображения: меш, анимации, частицы.. компонент контроллер: игрок/ии.. все это компоненты какой-то сущности будут, например, персонаж.
>>609421
Еще раз, возвращайся в свой юнити-загон. Я понимаю, ты скачал юнити, научился таскать ассеты по сценке, и тебе теперь до сверби в очке хочется спиздануть своё экспертное мнение, но иногда лучше промолчать, чтобы не позориться.
Ты даже не понял смысл компонентов ecs, что впрочем неудивительно для умственно-отсталого пользователя юнити.
Ладно, еще раз объясню, может дойдет со второго раза. Есть компонент оружия, есть компонент шлема. Логика оружия и атак в компоненте оружия, кол-во брони и логика защиты в компоненте шлема. Если ты делаешь обычное оружие, ты используешь один компонент оружия. Обычный шлем - компонент шлема. А если захотел, то комбинируешь два компонента в одной сущности, получаешь рогатый шлем, который дает защиту, и позволяет атаковать рогами.
В рамках ООП тебе уже придется делать наследование от двух классов с общим родительским классом, что приводит к diamond problem. Да и во многих языках множественное наследование запрещено, т.к. приводит к куче проблем. Разве что в С++ можно полноценно юзать множественное наследование, но поскольку ты умственно отсталый, то вряд ли умеешь писать на плюсах.
А если тебе отрубили рога, ты просто на лету дропаешь компонент и получаешь опять обычный шлем без атаки. В нормальном ecs все компоненты хранятся в раздельных хранилищах, поэтому компоненты легко отсоединяются/отключаются, память при этом освобождается.
В ООП так не получится сделать, если юзаешь наследование/агрегацию, в рантайме на лету ты не разделишь компоненты сущности.
Еще раз, возвращайся в свой юнити-загон. Я понимаю, ты скачал юнити, научился таскать ассеты по сценке, и тебе теперь до сверби в очке хочется спиздануть своё экспертное мнение, но иногда лучше промолчать, чтобы не позориться.
>Оружие и шлем очевидно пронаследуются от единицы снаряжения.
Ты даже не понял смысл компонентов ecs, что впрочем неудивительно для умственно-отсталого пользователя юнити.
Ладно, еще раз объясню, может дойдет со второго раза. Есть компонент оружия, есть компонент шлема. Логика оружия и атак в компоненте оружия, кол-во брони и логика защиты в компоненте шлема. Если ты делаешь обычное оружие, ты используешь один компонент оружия. Обычный шлем - компонент шлема. А если захотел, то комбинируешь два компонента в одной сущности, получаешь рогатый шлем, который дает защиту, и позволяет атаковать рогами.
В рамках ООП тебе уже придется делать наследование от двух классов с общим родительским классом, что приводит к diamond problem. Да и во многих языках множественное наследование запрещено, т.к. приводит к куче проблем. Разве что в С++ можно полноценно юзать множественное наследование, но поскольку ты умственно отсталый, то вряд ли умеешь писать на плюсах.
А если тебе отрубили рога, ты просто на лету дропаешь компонент и получаешь опять обычный шлем без атаки. В нормальном ecs все компоненты хранятся в раздельных хранилищах, поэтому компоненты легко отсоединяются/отключаются, память при этом освобождается.
В ООП так не получится сделать, если юзаешь наследование/агрегацию, в рантайме на лету ты не разделишь компоненты сущности.
>>609435
Дегенерат, ты высрал много хуйни и даже не понял мой простейший пост - в ecs у тебя ровно та же самая diamond problem, ты от нее никогда не уйдешь, просто сдвигаешь немного в другую плоскость, да даже на твоем же примере, хуй разберешься как рассчитывать атаку, поскольку она идет и от оружия и от рогов шлема, значит у тебя уже ограничение, что можно атаковать только одним из них, то есть ничем не лучше как если бы в ооп ты наследовался не множественным наследованием а ограничивал все одним предком.
Дегенерат, ты высрал много хуйни и даже не понял мой простейший пост - в ecs у тебя ровно та же самая diamond problem, ты от нее никогда не уйдешь, просто сдвигаешь немного в другую плоскость, да даже на твоем же примере, хуй разберешься как рассчитывать атаку, поскольку она идет и от оружия и от рогов шлема, значит у тебя уже ограничение, что можно атаковать только одним из них, то есть ничем не лучше как если бы в ооп ты наследовался не множественным наследованием а ограничивал все одним предком.
>>609442
Вот это обида умственно отсталого. Ничего, всё нормально, не обижайся, ты хороший мальчик. Иди запусти юнити, скачай ассет из стора, перетащи на сцену. Молодец, ты у нас умница, почти как настоящий взрослый разрабочик игр.
Нет, её нет.
Элементарно разберёшься.
Зависит от механик игры. Можно атаковать одним, сортировать компоненты по атрибуту приоритета/урону.
Можно проводить двойную атаку, в духе нескольких бросков кубика в d&d играх.
Можно давать игроку список действий на выбор,пробегаться по всем подключенным компонентам и строить набор доступных действий - стукнуть мечом, боднуть, пнуть, бросить этот сраный шлем во врага - этот функционал легко включить, просто подключив компонент "Бросаемый" к шлему. Ты можешь подключить этот же компонент к тому же мечу одной строчкой в конфиге сущностей, и для его броска будет задействован тот же код. Он будет так же бросаться, действие для броска так же автоматически будет доступно, без строчки дополнительного кода.
Удачи в ООП пробегаться по всем предкам сущности, чтобы понять, какие действия с ней можно делать.
Вот это обида умственно отсталого. Ничего, всё нормально, не обижайся, ты хороший мальчик. Иди запусти юнити, скачай ассет из стора, перетащи на сцену. Молодец, ты у нас умница, почти как настоящий взрослый разрабочик игр.
> в ecs у тебя ровно та же самая diamond problem
Нет, её нет.
>хуй разберешься как рассчитывать атаку
Элементарно разберёшься.
> значит у тебя уже ограничение, что можно атаковать только одним из них
Зависит от механик игры. Можно атаковать одним, сортировать компоненты по атрибуту приоритета/урону.
Можно проводить двойную атаку, в духе нескольких бросков кубика в d&d играх.
Можно давать игроку список действий на выбор,пробегаться по всем подключенным компонентам и строить набор доступных действий - стукнуть мечом, боднуть, пнуть, бросить этот сраный шлем во врага - этот функционал легко включить, просто подключив компонент "Бросаемый" к шлему. Ты можешь подключить этот же компонент к тому же мечу одной строчкой в конфиге сущностей, и для его броска будет задействован тот же код. Он будет так же бросаться, действие для броска так же автоматически будет доступно, без строчки дополнительного кода.
Удачи в ООП пробегаться по всем предкам сущности, чтобы понять, какие действия с ней можно делать.
>>609448
Лол, вот это боль юнитимакаки, которая умеет только возякать ассеты, и ничего не понимает в ООП.
Ты даже не понимаешь, шизоид, что ты просто ручками прописываешь все то, что у тебя будет само работать с наследованием. Просто смирись, программирование и геймдев - это не для всех, иди раскладывать товары в пятерочке.
Лол, вот это боль юнитимакаки, которая умеет только возякать ассеты, и ничего не понимает в ООП.
>Можно давать игроку список действий на выбор,пробегаться по всем подключенным компонентам и строить набор доступных действий - стукнуть мечом, боднуть, пнуть, бросить этот сраный шлем во врага
Ты даже не понимаешь, шизоид, что ты просто ручками прописываешь все то, что у тебя будет само работать с наследованием. Просто смирись, программирование и геймдев - это не для всех, иди раскладывать товары в пятерочке.
>>609448
хуесос, ассет от моделлера чемменяет этот процесс? прекроди срать себе в рот
>запусти юнити, скачай ассет из стора, перетащи на сцену. Молодец, ты у нас умница, почти как настоящий взрослый разрабочик игр.
хуесос, ассет от моделлера чемменяет этот процесс? прекроди срать себе в рот
>>609435
using Unity;
public class Component {}
public class Entity {
public List<Component> components
}
Дальше разъёбывать тебя, энтитух? Или ты уже понял, где обосрался?
> если юзаешь наследование/агрегацию, в рантайме на лету ты не разделишь компоненты сущности
using Unity;
public class Component {}
public class Entity {
public List<Component> components
}
Дальше разъёбывать тебя, энтитух? Или ты уже понял, где обосрался?
135 Кб, 300x190>>609429
Это даёт мододелам возможность пилить моды со своими сюжетами любого уровня сложности. Например, в основной игре, ты даже не думал о том, персонажем игрока может управлять ИИ, но всё же вложил эту возможность. И вот один моддер сделал мод, где все персонажи управляются игроком в стиле изометрических РПГ. А другой моддер запилил мод с квестом, в рамках которого некий монстр может удалённо контролировать персонажа игрока и игроку предстоит с этим разобраться. А третий моддер запилил мод на оборотня, где ГГ по ночам теряет разум и бежит охотиться, а игрок в ужасе наблюдает, не в силах ничего поделать. А пятый моддер запилил еблемод, где ГГ ебут.
> почти всегда это не оправдано больше ничем, кроме просто затем, чтобы было
Это даёт мододелам возможность пилить моды со своими сюжетами любого уровня сложности. Например, в основной игре, ты даже не думал о том, персонажем игрока может управлять ИИ, но всё же вложил эту возможность. И вот один моддер сделал мод, где все персонажи управляются игроком в стиле изометрических РПГ. А другой моддер запилил мод с квестом, в рамках которого некий монстр может удалённо контролировать персонажа игрока и игроку предстоит с этим разобраться. А третий моддер запилил мод на оборотня, где ГГ по ночам теряет разум и бежит охотиться, а игрок в ужасе наблюдает, не в силах ничего поделать. А пятый моддер запилил еблемод, где ГГ ебут.
>>609745
Нам очень важно ваше мнение. Пожалуйста, оставайтесь на линии, ближайший освободившийся оператор службы выслушивания охуительно важных мнений школоты и хомячья, обязательно ответит вам!
Нам очень важно ваше мнение. Пожалуйста, оставайтесь на линии, ближайший освободившийся оператор службы выслушивания охуительно важных мнений школоты и хомячья, обязательно ответит вам!
>>609709
Ты мог бы продать две игры, а в результате продал одну, а эту идею подарил какому то моддеру. Потом он выпускает игру ТОДА 2, которая становится популярной, а твой проект сосет бибу.
>один моддер сделал мод, где все персонажи управляются игроком в стиле изометрических РПГ
Ты мог бы продать две игры, а в результате продал одну, а эту идею подарил какому то моддеру. Потом он выпускает игру ТОДА 2, которая становится популярной, а твой проект сосет бибу.
>>609751
Нам очень важно ваше мнение. Пожалуйста, оставайтесь на линии, ближайший освободившийся оператор службы выслушивания охуительно важных мнений школоты и хомячья, обязательно ответит вам!
Нам очень важно ваше мнение. Пожалуйста, оставайтесь на линии, ближайший освободившийся оператор службы выслушивания охуительно важных мнений школоты и хомячья, обязательно ответит вам!
>>609755
Кто не рискует, тот не нюхает кокс с жоп шлюх.
Кто не рискует, тот не нюхает кокс с жоп шлюх.
>>609756
Я понял, понял. У вас там в школе все заняты хомячками.
Я понял, понял. У вас там в школе все заняты хомячками.
129 Кб, 480x480>>609702
Нахуя там юнити? Там же юзаются один List из стандартной либы. Или ты без юнити пукнуть уже не можешь?
Ну давай, разберем по частям тобою написанное.
Твоя реализация по перфомансу против полноценного ECS - это как бабка на костылях против спорткара.
В ECS компоненты хранятся в cache-friendly структурах, плотными массивами, при обработке системой они выгружаются на линии кэша процессора пачками и молниеносно обрабатываются.
У тебя же список, который хранит указатели на объекты в рандомных местах кучи, т.е. вся куча засрана дерьмом, по которому приходится скакать при обработке, кэш при этом вымывается мусором при каждой итерации.
Дальше, ты как ты представляешь себе код обработки высранной тобой структуры? Как системы узнают, что у сущности X в листе компонентов находятся компоненты типа, обрабатываемого данной системой? Я так полагаю, ты собрался для каждой сущности пробегаться по всем компонентам и делать тайп чек? Ты представляешь какой это оверхед по сравнению с настоящей реализацией ECS, где все компоненты одного типа лежат в отдельном массиве, и каждая система заранее знает, где взять эти компоненты без оверхеда?
Так что обосрался прямо себе на лицо пока что только ты.
Впрочем, от умственно отсталого потребителя юнити ничего другого и не ожидалось.
>using Unity
Нахуя там юнити? Там же юзаются один List из стандартной либы. Или ты без юнити пукнуть уже не можешь?
>Дальше разъёбывать тебя, энтитух?
Ну давай, разберем по частям тобою написанное.
Твоя реализация по перфомансу против полноценного ECS - это как бабка на костылях против спорткара.
В ECS компоненты хранятся в cache-friendly структурах, плотными массивами, при обработке системой они выгружаются на линии кэша процессора пачками и молниеносно обрабатываются.
У тебя же список, который хранит указатели на объекты в рандомных местах кучи, т.е. вся куча засрана дерьмом, по которому приходится скакать при обработке, кэш при этом вымывается мусором при каждой итерации.
Дальше, ты как ты представляешь себе код обработки высранной тобой структуры? Как системы узнают, что у сущности X в листе компонентов находятся компоненты типа, обрабатываемого данной системой? Я так полагаю, ты собрался для каждой сущности пробегаться по всем компонентам и делать тайп чек? Ты представляешь какой это оверхед по сравнению с настоящей реализацией ECS, где все компоненты одного типа лежат в отдельном массиве, и каждая система заранее знает, где взять эти компоненты без оверхеда?
Так что обосрался прямо себе на лицо пока что только ты.
Впрочем, от умственно отсталого потребителя юнити ничего другого и не ожидалось.
>>609955
У меня сейчас будет аргумент уровня "миллионы мух не могут ошибаться", но скайрим блядь, так много раз продавался, что об этом в интернетах легенды (и мемасы) ходят. И бойчее всего он продаётся на платформах, где моддинг затруднён.
У меня сейчас будет аргумент уровня "миллионы мух не могут ошибаться", но скайрим блядь, так много раз продавался, что об этом в интернетах легенды (и мемасы) ходят. И бойчее всего он продаётся на платформах, где моддинг затруднён.
>>609943
Во вселенной своих фантазий ты волен выбирать, что угодно.
Во вселенной своих фантазий ты волен выбирать, что угодно.
>>558393
Он там в стиме на альфаре уже выкатился, игрокам нравится и выглядит очень необычно.
Он там в стиме на альфаре уже выкатился, игрокам нравится и выглядит очень необычно.
>>614729
Пацаны, смотрите, бота как далеко занесло.
Пацаны, смотрите, бота как далеко занесло.
89 Кб, 1223x855Небольшие попытки осмыслить архитектуру ECS, как метод выражения Сущностей игрового мира
>>616191
я не понимаю в чем вы все страдаете этим ECS? это же абстракция ради абстракций, когда простые вещи делаются через стопятсот абстрактностей ради какой-то мифической расширяемости которой на самом деле никогда не будет (не будет у тебя никогда стопятсот компонент)
(это как в свое время с++шники страдали шаблономагией из-за выхода книги от Александреску
А еще упарывались дата-драйверцы со своими горячими перезагрузками и джейсон-ресурсами которые нахрен никому не сдались (в юнини вон так и забросили эту идею и работает там через одно место)
Там где-то еще эвентники вклинивались со своим "все должно быть на событиях"
А дедушки наверное вспомнят функциональщиков...
короче, всё это говно, мода пройдет и закопают. ECS ничего не дает кроме вымышленных решений на будущее, тогда как надо писать на сейчас.
впрочем у тебя на скрине не ECS.
я не понимаю в чем вы все страдаете этим ECS? это же абстракция ради абстракций, когда простые вещи делаются через стопятсот абстрактностей ради какой-то мифической расширяемости которой на самом деле никогда не будет (не будет у тебя никогда стопятсот компонент)
(это как в свое время с++шники страдали шаблономагией из-за выхода книги от Александреску
А еще упарывались дата-драйверцы со своими горячими перезагрузками и джейсон-ресурсами которые нахрен никому не сдались (в юнини вон так и забросили эту идею и работает там через одно место)
Там где-то еще эвентники вклинивались со своим "все должно быть на событиях"
А дедушки наверное вспомнят функциональщиков...
короче, всё это говно, мода пройдет и закопают. ECS ничего не дает кроме вымышленных решений на будущее, тогда как надо писать на сейчас.
впрочем у тебя на скрине не ECS.
>>616228
Дед, не ори.
Просто ты уже старенький стал, мозги закостенели, за старое держижшься, ух.
И что ж ты предложишь? ООП?
Дед, не ори.
Просто ты уже старенький стал, мозги закостенели, за старое держижшься, ух.
И что ж ты предложишь? ООП?
>>616228
+ где тут написано что это ECS?
+ где тут написано что это ECS?
>>616228
пиздец ты школьник, не нюхавший программирования) Ну когда будете проходить про расположение структур в памяти, тогда пояснят принципиальную разницу oop/ecs для высоконагруженных приложений.
Понятно, что для твоих задачек школьных и хеллоуворлдов по урокам с ютьюбчика пойдет любое и разницы ты не увидишь.
пиздец ты школьник, не нюхавший программирования) Ну когда будете проходить про расположение структур в памяти, тогда пояснят принципиальную разницу oop/ecs для высоконагруженных приложений.
Понятно, что для твоих задачек школьных и хеллоуворлдов по урокам с ютьюбчика пойдет любое и разницы ты не увидишь.
62 Кб, 288x175>>616233
что еще можно предложить?
что еще можно предложить?
>>616298
Так он то же самое и написал, только про тебя.
>для твоих задачек школьных и хеллоуворлдов по урокам с ютьюбчика пойдет любое и разницы ты не увидишь
Так он то же самое и написал, только про тебя.
>>616298
сразу видно школьника, ты бы хоть сам-то узнал что такое ECS
Но я добрый, лови статейку где все разжевано
https://github.com/SanderMertens/ecs-faq
ну во-первых не структуры, ты даже в терминологию не можешь.
Во-вторых от того что ты решил что у тебя ECS, твой код не станет кешфрендли и это тебя не спасет от сache miss.
Как минимум придется написать и свой аллокатор памяти чтобы гарантировать что твои компоненты реально лежат друг за другом, а не по всей памяти.
Да и вообще побайтоебить... Ведь вот какой прикол, гарантированное расположение в памяти тебе дается только для POD структур, только вот там запрещен полиморфизм (виртуальное наследование)
https://ru.wikipedia.org/wiki/Простая_структура_данных
сразу видно школьника, ты бы хоть сам-то узнал что такое ECS
Но я добрый, лови статейку где все разжевано
https://github.com/SanderMertens/ecs-faq
>>проходить про расположение структур в памяти,
ну во-первых не структуры, ты даже в терминологию не можешь.
Во-вторых от того что ты решил что у тебя ECS, твой код не станет кешфрендли и это тебя не спасет от сache miss.
Как минимум придется написать и свой аллокатор памяти чтобы гарантировать что твои компоненты реально лежат друг за другом, а не по всей памяти.
Да и вообще побайтоебить... Ведь вот какой прикол, гарантированное расположение в памяти тебе дается только для POD структур, только вот там запрещен полиморфизм (виртуальное наследование)
https://ru.wikipedia.org/wiki/Простая_структура_данных
>>616359
Естественно у ECS свои проблемы, тут спору нет. Но мне кажется это не так страшно, по сравнению в вечным рефакторингом ООП, когда ты только собираешься въебать новый функционал.
Естественно у ECS свои проблемы, тут спору нет. Но мне кажется это не так страшно, по сравнению в вечным рефакторингом ООП, когда ты только собираешься въебать новый функционал.
>>616359
Так шо я думаю, блядь, ну блять, ECS метод, он относительно молодой, и хули, понятное дело что он будет вызывать новвые проблемы. Но бяддь, мне вот лично не западло изучить еще небольшую тонну материала, и разобраться по хорошему с аллокацией памяти, побайтоёбить, и создать просто хороший, добротный движок для рогулька, на основе ECS. Дык в итоге это же будет монолитный фундамент, на который ты сможешь СТОЛЬКО вещей надеть, добавить, постоянно модифицировать, что оно всё окупит.
Так шо я думаю, блядь, ну блять, ECS метод, он относительно молодой, и хули, понятное дело что он будет вызывать новвые проблемы. Но бяддь, мне вот лично не западло изучить еще небольшую тонну материала, и разобраться по хорошему с аллокацией памяти, побайтоёбить, и создать просто хороший, добротный движок для рогулька, на основе ECS. Дык в итоге это же будет монолитный фундамент, на который ты сможешь СТОЛЬКО вещей надеть, добавить, постоянно модифицировать, что оно всё окупит.
>>616359
Вот сижу и думаю, от чего бы мне отнаследовать количество здоровья персонажа, или его координаты. Ведь компоненты в ecs ну никак нельзя делать без виртуального наследования. Нельзя же просто сделать using Health = float, надо обязательно сделать class Health : public AbstractHealth, а AbstractHealth - наследовать от AbstractComponent, а AbstractComponent от AbstractProxyFactorySingletonComponentFactoryBean, иначе не трушное ООП получится.
>Ведь вот какой прикол, гарантированное расположение в памяти тебе дается только для POD структур, только вот там запрещен полиморфизм (виртуальное наследование)
Вот сижу и думаю, от чего бы мне отнаследовать количество здоровья персонажа, или его координаты. Ведь компоненты в ecs ну никак нельзя делать без виртуального наследования. Нельзя же просто сделать using Health = float, надо обязательно сделать class Health : public AbstractHealth, а AbstractHealth - наследовать от AbstractComponent, а AbstractComponent от AbstractProxyFactorySingletonComponentFactoryBean, иначе не трушное ООП получится.
>>616410
Компоненты не надо наследовать. И вообще это должны быть не классы, а структуры. И называться типа HasHealth. И на каждой итерации твоя HealthSystem проверяет все компоненты HasHealth, и если значение достигло нуля, то удаляет эту сущность, например
Компоненты не надо наследовать. И вообще это должны быть не классы, а структуры. И называться типа HasHealth. И на каждой итерации твоя HealthSystem проверяет все компоненты HasHealth, и если значение достигло нуля, то удаляет эту сущность, например
>>616411
А, это ирония была, ну ладно
А, это ирония была, ну ладно
>>616411
А почему нельзя не итерациями производить события, а условно создать поток, или пул, в который каждый компонент, если он должен измениться будет вкидывать себя на очередь, допустим? Какие подводные?
А почему нельзя не итерациями производить события, а условно создать поток, или пул, в который каждый компонент, если он должен измениться будет вкидывать себя на очередь, допустим? Какие подводные?
>>616451
Ты вообще можешь сделать как хочешь. ECS это просто реализация поведения объектов, которое описывается набором характеристик. Например, объект реализует поведение оружия, если у него есть характеристики предмет и стреляющий.
Системы - это конкретный процедурный способ реализации поведения объекта. Можно сделать как в юнити, и поведения добавить внутрь самих компонентов.
Ты вообще можешь сделать как хочешь. ECS это просто реализация поведения объектов, которое описывается набором характеристик. Например, объект реализует поведение оружия, если у него есть характеристики предмет и стреляющий.
Системы - это конкретный процедурный способ реализации поведения объекта. Можно сделать как в юнити, и поведения добавить внутрь самих компонентов.
>>616459
Ну как бы да, могу как хочу, это был скорее вопрос к самой ценности вышевысказанной идеи.
Ну как бы да, могу как хочу, это был скорее вопрос к самой ценности вышевысказанной идеи.
>>616359
а что у вас в школе маллоки не проходят уже, что написать аллокатор памяти для своих структур в игре - это проблема?
а, нынче только сисярпить могут
а что у вас в школе маллоки не проходят уже, что написать аллокатор памяти для своих структур в игре - это проблема?
а, нынче только сисярпить могут
>>616459
Если как раньше в юнитях, то это EC архитектура у них была, на ECS они только переходят.
Если как раньше в юнитях, то это EC архитектура у них была, на ECS они только переходят.
>>616451
Потому что компонент ничего не знает о том, что он должен как-то изменится. Это просто набор данных.
Потому что компонент ничего не знает о том, что он должен как-то изменится. Это просто набор данных.
>>616632
Система как раз и знает как изменяются компоненты и содержит логику их изменений. Удачи в школе сегодня.
Система как раз и знает как изменяются компоненты и содержит логику их изменений. Удачи в школе сегодня.
Возрадуйтесь, ибо грядет)
https://suvitruf.ru/2019/07/20/6387/csharp-android-support-godot-3-2/
https://suvitruf.ru/2019/07/20/6387/csharp-android-support-godot-3-2/
>>616635
Да это то понятно, умник ёпта. Я просто думал над оптимизацией самого процесса вызова этих функций. Как в пример можно взять события через Update на юнити. Которые засирают нахуй пул ненужным мусором. Но при этом нам надо как-то отображать изменеия тех или иных объектов во времени. Вот я и думаю, насчёт идеи создания пула, в который будут все изменения вкидываться уже самими функциями, когда они хотят изменить что-то и выполняться уже в порядке очереди.
Да это то понятно, умник ёпта. Я просто думал над оптимизацией самого процесса вызова этих функций. Как в пример можно взять события через Update на юнити. Которые засирают нахуй пул ненужным мусором. Но при этом нам надо как-то отображать изменеия тех или иных объектов во времени. Вот я и думаю, насчёт идеи создания пула, в который будут все изменения вкидываться уже самими функциями, когда они хотят изменить что-то и выполняться уже в порядке очереди.
>>616653
Ты чего злой такой, пиздец? Я вообще просто как пример неэффектисвной реализации привёл, я юнитями не пользуюсь. А ты блять вот так нахуй. Как так нахуй?
Ты чего злой такой, пиздец? Я вообще просто как пример неэффектисвной реализации привёл, я юнитями не пользуюсь. А ты блять вот так нахуй. Как так нахуй?
>>616629
щас бы аллокатор на маллоках писать, лол.
Вот тебе случайный аллокатор
https://github.com/EmuraDaisuke/MemoryAllocator.KanameShiki
щас бы аллокатор на маллоках писать, лол.
Вот тебе случайный аллокатор
https://github.com/EmuraDaisuke/MemoryAllocator.KanameShiki
>>616658
А есть какая-нибудь соотвествующая лит-ра, где о проблемах аллокации говорится вот прямо подробно. И желательно вообще о любых проблемах-решениях оптимизации на уровне железа, или байтоёбства?
буду намагниченной иголочкой транзисторы флипать аыаыа
А есть какая-нибудь соотвествующая лит-ра, где о проблемах аллокации говорится вот прямо подробно. И желательно вообще о любых проблемах-решениях оптимизации на уровне железа, или байтоёбства?
буду намагниченной иголочкой транзисторы флипать аыаыа
>>616659
была бы вообще хоть какая-то единая обобщенная лит-ра... эх.
А так смотришь чужие презентации (что-нибудь по поиску Game Dev Memory Allocation или Engine Memory Allocation),
плюс вникаешь в работу процессора с памятью...
Суть там в чем:
1) в основном цикле не должно быть выделений памяти, потому что это дорого. Выделять можно в начале, или там один раз
2) память любит срать во все дыры (фрагментация - то есть твой класс раскидывается по всем уголкам), а процессору очень тяжело прыгать по памяти, а еще он верит что следующий блок ему нужен (и если это не так, то бо-бо)... Тут короче гуглить кеш промахи (Cache Miss) и всё про это
по 1 пункту - в низкоуровневых компиляторах есть возможность выделить кусок памяти, а потом в него писать (В С++ это делается через placement new).
по 2 пункту... ведь данные у нас часто одинакого размера (например миллион transform компонент), можно под каждый тип данных выделить свой блок памяти - тогда фрагментации не будет (удалил один, на его место записал другой)
Короче, тема слишком большая, вникать долго. Не факт что нужно.
Просто стоит понять что ECS из коробки оптимизации не даст, если не разбираешься в работе с памятью
была бы вообще хоть какая-то единая обобщенная лит-ра... эх.
А так смотришь чужие презентации (что-нибудь по поиску Game Dev Memory Allocation или Engine Memory Allocation),
плюс вникаешь в работу процессора с памятью...
Суть там в чем:
1) в основном цикле не должно быть выделений памяти, потому что это дорого. Выделять можно в начале, или там один раз
2) память любит срать во все дыры (фрагментация - то есть твой класс раскидывается по всем уголкам), а процессору очень тяжело прыгать по памяти, а еще он верит что следующий блок ему нужен (и если это не так, то бо-бо)... Тут короче гуглить кеш промахи (Cache Miss) и всё про это
по 1 пункту - в низкоуровневых компиляторах есть возможность выделить кусок памяти, а потом в него писать (В С++ это делается через placement new).
по 2 пункту... ведь данные у нас часто одинакого размера (например миллион transform компонент), можно под каждый тип данных выделить свой блок памяти - тогда фрагментации не будет (удалил один, на его место записал другой)
Короче, тема слишком большая, вникать долго. Не факт что нужно.
Просто стоит понять что ECS из коробки оптимизации не даст, если не разбираешься в работе с памятью
>>616660
Я от ECS панацеи не ждал, ясен хуебасен что без прямых рук, свежей головы и какой нибудь хуйни еще можно и ECS засрать. Мне этот паттерн понравился больше из за гибкости в перепиливании, и добавлении новых вещей. А то что можно хорошо так, по доброму еще и с памятью поработать, оптимизировать движок, то это вообще роскошь.
А за литературу да... НА ум только совершенный код приходит, и еще книжечка одна про компиляторы. Не знаю насколько это в сама деле полезно.
Я от ECS панацеи не ждал, ясен хуебасен что без прямых рук, свежей головы и какой нибудь хуйни еще можно и ECS засрать. Мне этот паттерн понравился больше из за гибкости в перепиливании, и добавлении новых вещей. А то что можно хорошо так, по доброму еще и с памятью поработать, оптимизировать движок, то это вообще роскошь.
А за литературу да... НА ум только совершенный код приходит, и еще книжечка одна про компиляторы. Не знаю насколько это в сама деле полезно.
>>616661
вообще всегда можно глянуть как сделано у серьезных дядек.
например скачай исходники unity 4 (спираченные китайцами, а не огрызок от разработчика). (старье, да, но с другой стороны 4 версия не тормозила даже на кофеварках в отличие от текущих)
Там понятный код аллокатора. (или исходники unigine 2010 - там вообще легко читается)
(но ссылку на код юньки не помню, надо в китайских помойках копаться что-то на source leak unity 4 yoyoyo)
вообще всегда можно глянуть как сделано у серьезных дядек.
например скачай исходники unity 4 (спираченные китайцами, а не огрызок от разработчика). (старье, да, но с другой стороны 4 версия не тормозила даже на кофеварках в отличие от текущих)
Там понятный код аллокатора. (или исходники unigine 2010 - там вообще легко читается)
(но ссылку на код юньки не помню, надо в китайских помойках копаться что-то на source leak unity 4 yoyoyo)
>>616662
Уох бля, слили? Вот так внезапно. Ну ладно, буду посмотреть. А вообще, вернёмся к теме рогуляков. Есть ли смысл тут задрачиваться так с памятью и оптимизацией, и если есть, какие бенефиты это может привнести? Вот допустим если есть идея создать игровой мир так Это выглядит как убераутизм, но это и есть смысл RLSim'ов название придумал вчера, чтобы внутри каждого существа, каждый обьект-орган был включён, и здоровье было не просто как счётчик, а фактическое состояие существ. НУ вот в пример возьмём Dwarf Fortress. Я уже думал над тем, как можно сохранять тонны предметов в одном "существе", каким образом можно говорить системам что "вот это у нас для дыхания, а вот это кровеносная система, но немного не в порядке, потому что давление падает из за повреждения сосудов левой пятки правой ноги".
Я уже накириллил в Evernote пару десятков листов подобного сырого описания механик и алгоримтов. Если надо, могу высрать.
Уох бля, слили? Вот так внезапно. Ну ладно, буду посмотреть. А вообще, вернёмся к теме рогуляков. Есть ли смысл тут задрачиваться так с памятью и оптимизацией, и если есть, какие бенефиты это может привнести? Вот допустим если есть идея создать игровой мир так Это выглядит как убераутизм, но это и есть смысл RLSim'ов название придумал вчера, чтобы внутри каждого существа, каждый обьект-орган был включён, и здоровье было не просто как счётчик, а фактическое состояие существ. НУ вот в пример возьмём Dwarf Fortress. Я уже думал над тем, как можно сохранять тонны предметов в одном "существе", каким образом можно говорить системам что "вот это у нас для дыхания, а вот это кровеносная система, но немного не в порядке, потому что давление падает из за повреждения сосудов левой пятки правой ноги".
Я уже накириллил в Evernote пару десятков листов подобного сырого описания механик и алгоримтов. Если надо, могу высрать.
>>616663
Если у тебя в игре будет 10 дварфов с органами, то можшь не заморачиваться. Если предполагается обсчет 1000 существ и физика мира будет достаточно сложной, то - да, стоит.
Если у тебя в игре будет 10 дварфов с органами, то можшь не заморачиваться. Если предполагается обсчет 1000 существ и физика мира будет достаточно сложной, то - да, стоит.
>>616663
по теме сложно сказать. в 90% индюшатины (и тем более рогаликов) - не нужно.
С другой стороны если делать Dwarf Fortress - то там очень даже нужно - DF тормозит еще так - много расчетов (а может просто разрабу лень что-то оптимизировать)
>>616663
Во, оказывается слив юнити и на дваче обсуждали (из архива - успей пока не удалили https://m2ch.hk/pr/res/1252860.html)
по теме сложно сказать. в 90% индюшатины (и тем более рогаликов) - не нужно.
С другой стороны если делать Dwarf Fortress - то там очень даже нужно - DF тормозит еще так - много расчетов (а может просто разрабу лень что-то оптимизировать)
>>616663
Во, оказывается слив юнити и на дваче обсуждали (из архива - успей пока не удалили https://m2ch.hk/pr/res/1252860.html)
>>616664
Ну физика не сказать чтобы прямо сложная будет, хотя предполагается что в баббле могут начать пиздиться и активно производить тактические манёвры 300-500 ёбел. При этом стоит не забывать что мир трёхмерный. При этом также будут иметься движущиеся механизмы (машины, или огромные крепости). Вот с последним я думал думал, там пиздец нахуй морока будет. Ибо пересчитывать перемещение каждой клеточки, это можно ебануться к хуям. Думал можно поизъёбываться, и сделать так, что в мире у движущегося механизма будет единый центральный блок, который только будет двигаться, и все внутренние вычисления перемещения будут происходить уже относительно него. Тобишь двигать каждый блок уже не потребуется, хотя думаю тут если дойдет до оптимизиации, вылезит такое дикое количество нюансов, что жопу придётся рвать крайне интенсивно.
>>616666
Там даже потоковость не поодерживается. Да и что-то мне подсказывает, что автор проебал уже давно всю последвательность архитектурную, и просто городушки делает, не знаю. Но да, оптимизон нужон.
Ну физика не сказать чтобы прямо сложная будет, хотя предполагается что в баббле могут начать пиздиться и активно производить тактические манёвры 300-500 ёбел. При этом стоит не забывать что мир трёхмерный. При этом также будут иметься движущиеся механизмы (машины, или огромные крепости). Вот с последним я думал думал, там пиздец нахуй морока будет. Ибо пересчитывать перемещение каждой клеточки, это можно ебануться к хуям. Думал можно поизъёбываться, и сделать так, что в мире у движущегося механизма будет единый центральный блок, который только будет двигаться, и все внутренние вычисления перемещения будут происходить уже относительно него. Тобишь двигать каждый блок уже не потребуется, хотя думаю тут если дойдет до оптимизиации, вылезит такое дикое количество нюансов, что жопу придётся рвать крайне интенсивно.
>>616666
Там даже потоковость не поодерживается. Да и что-то мне подсказывает, что автор проебал уже давно всю последвательность архитектурную, и просто городушки делает, не знаю. Но да, оптимизон нужон.
>>616667
Ну если вводишь многоклеточные структуры и такие эпичные битвы - тогда лучше с начала разработки учесть методы оптимизации при проектировании.
Так коллизию всей этой структуры все равно придется точно также обсчитывать в трехмерном мире: т.е. все граничные клетки твоей структуры в направлении вектора движения.
Ну если вводишь многоклеточные структуры и такие эпичные битвы - тогда лучше с начала разработки учесть методы оптимизации при проектировании.
>> Думал можно поизъёбываться, и сделать так, что в мире у движущегося механизма будет единый центральный блок, который только будет двигаться, и все внутренние вычисления перемещения будут происходить уже относительно него.
Так коллизию всей этой структуры все равно придется точно также обсчитывать в трехмерном мире: т.е. все граничные клетки твоей структуры в направлении вектора движения.
>>616671
Естественно, никто не спорит.
А про оптимизацию да, я собственно, по этой причине-то и интерисуюсь
Естественно, никто не спорит.
А про оптимизацию да, я собственно, по этой причине-то и интерисуюсь
>>616690
ну если конкретно для цикла
Правильный вариант:
for
отступ body
Пропускаем отступ:
for
body
- получаем ошибку, что не хватает знака табуляции после объявления цикла
ну если конкретно для цикла
Правильный вариант:
for
отступ body
Пропускаем отступ:
for
body
- получаем ошибку, что не хватает знака табуляции после объявления цикла
>>616692
Ебать опять боты пизданулись, че за хуйня
Ебать опять боты пизданулись, че за хуйня
>>616690
промахнулся, не тебе
промахнулся, не тебе
ТЭкс, пока ОП умер нахуй, я решил сам начать пилить Движок, и сам рогалик. Пока в быстром порядке отзубриваю кресты С++, ООП, ЕЦС, SDL и прочее ебланство, попутно нанизывая на собранный ручками из говна и палок недодвижок. Сразу вопрос про либку SDL. Это вообще законно/канонично, если я начну хуячить весь рендер (Сейчас я по немного разделяю рендер архитектурно через интерфейс) через SDL_Renderer, или мне лучше попробовать подрочиться с windows.h, и пилить вывод прямо в терминал? Я хочу как минимум его на Win32/Linux въебать, но совершенно не знаю особенности кроссплатформенности под линукс.
>>618792
Раз так, то тебе стоит сфокусироваться на SDL. Для неё вроде даже есть драйвер, выводящий картинку в ascii-art.
>Я хочу как минимум его на Win32/Linux въебать
Раз так, то тебе стоит сфокусироваться на SDL. Для неё вроде даже есть драйвер, выводящий картинку в ascii-art.
>>618797
Ну это не будет само собой непосредственно терминальное окно. Там получается что вот пока у меня выводится графическиий рендер, на котором уже ttf текст рендерится. Вроде как бы и норм, но по мне так исполнение - дикая хуйня. И поясни за драйваер, он прямо непосредственно буфер терминала перехватывает, или просто какая-то свистоперделка для рендерера?
Ну это не будет само собой непосредственно терминальное окно. Там получается что вот пока у меня выводится графическиий рендер, на котором уже ttf текст рендерится. Вроде как бы и норм, но по мне так исполнение - дикая хуйня. И поясни за драйваер, он прямо непосредственно буфер терминала перехватывает, или просто какая-то свистоперделка для рендерера?
>>618797
Хотя если так подумать, хуй еще пойми, реально ли надо именно таким "стандартным" для рогулей образом выводить игру. хуй еще знает кароче.
Хотя если так подумать, хуй еще пойми, реально ли надо именно таким "стандартным" для рогулей образом выводить игру. хуй еще знает кароче.
>>618810
Ебать, разве это не просто обработчик медиа под стиль ASCII?
Ебать, разве это не просто обработчик медиа под стиль ASCII?
>>619409
Я пока решил начать пилить рогуль с BearLibTerminal, в ней очень много всяких плюшечек есть, и она вполне себе хорошо подходит для моих задач. НА первое время, скажем так, можно взять её. Вкручу её в код через интерфейсы, потом может когда-нибудь, если понадобится, напишу собственный рендерер, а пока буду занят чисто логикой игры и структурой кода
Я пока решил начать пилить рогуль с BearLibTerminal, в ней очень много всяких плюшечек есть, и она вполне себе хорошо подходит для моих задач. НА первое время, скажем так, можно взять её. Вкручу её в код через интерфейсы, потом может когда-нибудь, если понадобится, напишу собственный рендерер, а пока буду занят чисто логикой игры и структурой кода
>>558349 (OP)
Есть у кого-нибудь опыт с T-Engine 4? Это на котором ToME4 написан. Там луа, и разобраться вроде несложно, но я так и не понял, насколько движок свободный. Смогу я игру, сделанную на нём, продавать в стиме? Алсо, не могу понять, можно ли сделать полностью отдельную игру, а не .team-мод для ToME, хотя на 4drl вроде делали.
Есть у кого-нибудь опыт с T-Engine 4? Это на котором ToME4 написан. Там луа, и разобраться вроде несложно, но я так и не понял, насколько движок свободный. Смогу я игру, сделанную на нём, продавать в стиме? Алсо, не могу понять, можно ли сделать полностью отдельную игру, а не .team-мод для ToME, хотя на 4drl вроде делали.
Вкатываюсь в тред, пилю рогуалик на питоне, вывод графики через pygame, остальное сам пишу ибо интересно.
И раз тут нашелся такой уютный тредос, поделюсь наболевшим.
Пилил короче генерацию данжа, решил от квадратных комнат перейти к пещерообразным. Почитал про cellular automata, реализовал невзъебенную функцию в пол-экрана, которая генерит комнату и "причесывает" ее 5 раз, чтобы было похоже на пещеру, все в соответствии со статьями на roguebasine - но закономерно столкнулся с проблемой, что алгоритм может тебе сделать 2 или более несоединенных пещер, а значит это тоже надо проверять. Сделал доп. функцию, которая проверяет цельность пещеры, если не цельна - переделывает. И короче при таком подходе одна пещера генерится секунд 5-7. Одна!
Долго думал, что где оптимизировать, но кодер я так себе, так что хрен там. Но через день случайно почитал про алгоритм drunkard walk или random walk. Реализовал функцию в пять строк. И о чудо! Пещеры генерятся моментально, эффект точно такой же, как в предыдущем варианте, может даже лучше.
Короче нахуй cellular automata, посоны. Юзайте drunkard walk и будет вам счастье.
И раз тут нашелся такой уютный тредос, поделюсь наболевшим.
Пилил короче генерацию данжа, решил от квадратных комнат перейти к пещерообразным. Почитал про cellular automata, реализовал невзъебенную функцию в пол-экрана, которая генерит комнату и "причесывает" ее 5 раз, чтобы было похоже на пещеру, все в соответствии со статьями на roguebasine - но закономерно столкнулся с проблемой, что алгоритм может тебе сделать 2 или более несоединенных пещер, а значит это тоже надо проверять. Сделал доп. функцию, которая проверяет цельность пещеры, если не цельна - переделывает. И короче при таком подходе одна пещера генерится секунд 5-7. Одна!
Долго думал, что где оптимизировать, но кодер я так себе, так что хрен там. Но через день случайно почитал про алгоритм drunkard walk или random walk. Реализовал функцию в пять строк. И о чудо! Пещеры генерятся моментально, эффект точно такой же, как в предыдущем варианте, может даже лучше.
Короче нахуй cellular automata, посоны. Юзайте drunkard walk и будет вам счастье.
>>647714
Ты не показал содержимое find_4_tiles_around() подозреваю, что там 6-8 строк, но тем не менее, тут можно доебаться.
Ты не показал содержимое find_4_tiles_around() подозреваю, что там 6-8 строк, но тем не менее, тут можно доебаться.
>>647714
Спасибо за инсайт, сделал пометочку в своём эверноте.
Если что, спрашивай, я как раз на питонах зарабатываю на хлебушек.
Удачи
У тебя на скрине ГГ лысый лол
> Короче нахуй cellular automata, посоны. Юзайте drunkard walk и будет вам счастье.
Спасибо за инсайт, сделал пометочку в своём эверноте.
> кодер я так себе, так что хрен там
Если что, спрашивай, я как раз на питонах зарабатываю на хлебушек.
Удачи
У тебя на скрине ГГ лысый лол
>>647868
А питонисты разве до сих пор нужны? Как вообще там? Я сам изучаю раст, но чую что он пока мало кому нужен, хотя язык лучше даже крестов в каком-то смысле
А питонисты разве до сих пор нужны? Как вообще там? Я сам изучаю раст, но чую что он пока мало кому нужен, хотя язык лучше даже крестов в каком-то смысле
>>648012
Более чем все прочие. У меня между разными галерами пауз в работе больше месяца не было.
Как земля. Что узнать-то хотел? Конкретно спрашивай.
Правильно чуешь.
> А питонисты разве до сих пор нужны?
Более чем все прочие. У меня между разными галерами пауз в работе больше месяца не было.
> Как вообще там?
Как земля. Что узнать-то хотел? Конкретно спрашивай.
> раст, но чую что он пока мало кому нужен
Правильно чуешь.
Кириллишь десятилетиями рогалик мечты.
@
Авторы холлов найт нюхают кокс с жоп шлюх.
@
Авторы ори купили по второй ферари.
@
Жидко пукнув помираешь от старости.
@
Авторы холлов найт нюхают кокс с жоп шлюх.
@
Авторы ори купили по второй ферари.
@
Жидко пукнув помираешь от старости.
>>648014
А я его и начинал учить кстати, пока не понял что ебись оно всё в жопу эти ебучие GC.
Ну значит потом буду снова его учить.
>>648025
Конкретно о том какие задачи на нём чаще всего приходится решать , и какой уровень тупизны ваших братьев погромистов там (Про тебя ничего не говорю).
>Правильно чуешь.
Но он мне люто нравится, поэту я буду продолжать его учить.
А я его и начинал учить кстати, пока не понял что ебись оно всё в жопу эти ебучие GC.
Ну значит потом буду снова его учить.
>>648025
>Что узнать-то хотел? Конкретно спрашивай.
Конкретно о том какие задачи на нём чаще всего приходится решать , и какой уровень тупизны ваших братьев погромистов там (Про тебя ничего не говорю).
>Правильно чуешь.
Но он мне люто нравится, поэту я буду продолжать его учить.
>>648095
Я на нём по работе лабаю вебсервисы на джанге. Ещё есть слухи, что в нашу контору хайрили датасатаниста, тоже на питонах, удои повышать.
У меня охуенные коллеги, от которых я узнаю много новых полезных штук, но, возможно, это мне так повезло. В среднем в этой области, как я понимаю, дохуя вкатывальщиков.
Бесценное время твоей жизни принадлежит только тебе, решать, на что его тратить, тоже только тебе.
> Конкретно о том какие задачи на нём чаще всего приходится решать
Я на нём по работе лабаю вебсервисы на джанге. Ещё есть слухи, что в нашу контору хайрили датасатаниста, тоже на питонах, удои повышать.
> какой уровень тупизны ваших братьев погромистов там
У меня охуенные коллеги, от которых я узнаю много новых полезных штук, но, возможно, это мне так повезло. В среднем в этой области, как я понимаю, дохуя вкатывальщиков.
> Но он мне люто нравится, поэту я буду продолжать его учить.
Бесценное время твоей жизни принадлежит только тебе, решать, на что его тратить, тоже только тебе.
>>648106
Органически не переношу игры, для игры в которые нужен только раздроченный спинной мозг, так что ну его нахуй я всё в INT вкачал, AGI у меня околонулевое
Органически не переношу игры, для игры в которые нужен только раздроченный спинной мозг, так что ну его нахуй я всё в INT вкачал, AGI у меня околонулевое
>>648106
А рогалик - пик развития топдаун эрпогэ?
А рогалик - пик развития топдаун эрпогэ?
Продолжаем попил приключений лысого ананаса в подземельях с монстрами.
Сделал кривейший line of sight и fog of war через такие костыли, что просто ужас. Но эй, оно работает и не тормозит, так что - пойдет.
Как сделал los: Как водится, через рейкастинг - но потайловый; берем начальную координату (позицию лысого), и потайлово проверяем в каком-либо направлении, не уперлись ли мы в стену или закрытую дверь. Проверяется так только 8 направлений, т. к. мне было лень нормально делать, так что я до кучи добавляю в los все тайлы комнаты, если она next to лысый. Сам в ужасе от системы, но мне нравится придерживаться позиции "хочешь сделать что-то - сделай как-нибудь, потом почитай у умных дядек, как правильно".
Как сделал fog of var:
Покрыл все тайлы стен и пола доп. слоем спрайтов шахматной сетки, который рендерю, если он не попадает в los. Все остальное рендерится, если попадает в los. Ну, кроме стен, дверей и тайлов - они рендерятся, если попали в los хоть раз.
Вообще, писать о процессе довольно сильно включает критическое мышление на тему "чего я хочу от того, что делаю". Так что всем рекомендую. Может девблог завести какой-нить
Сделал кривейший line of sight и fog of war через такие костыли, что просто ужас. Но эй, оно работает и не тормозит, так что - пойдет.
Как сделал los: Как водится, через рейкастинг - но потайловый; берем начальную координату (позицию лысого), и потайлово проверяем в каком-либо направлении, не уперлись ли мы в стену или закрытую дверь. Проверяется так только 8 направлений, т. к. мне было лень нормально делать, так что я до кучи добавляю в los все тайлы комнаты, если она next to лысый. Сам в ужасе от системы, но мне нравится придерживаться позиции "хочешь сделать что-то - сделай как-нибудь, потом почитай у умных дядек, как правильно".
Как сделал fog of var:
Покрыл все тайлы стен и пола доп. слоем спрайтов шахматной сетки, который рендерю, если он не попадает в los. Все остальное рендерится, если попадает в los. Ну, кроме стен, дверей и тайлов - они рендерятся, если попали в los хоть раз.
Вообще, писать о процессе довольно сильно включает критическое мышление на тему "чего я хочу от того, что делаю". Так что всем рекомендую. Может девблог завести какой-нить
>>648986
Тред не читай @ сразу отвечай
los это список координат [x,y]. заполняется каждый ход. Каждый ход происходит проверка, попали ли в [x, y] мобы, тайлы и прочее барахло.
Кто-нибудь может адекватно за ECS пояснить? Не вкуриваю концепт вообще.
Тред не читай @ сразу отвечай
los это список координат [x,y]. заполняется каждый ход. Каждый ход происходит проверка, попали ли в [x, y] мобы, тайлы и прочее барахло.
Кто-нибудь может адекватно за ECS пояснить? Не вкуриваю концепт вообще.
>>649102
Я могу, потому что дрочу на ECS.
Сначала пойдём от противного, и немного про минусы ООП:
Кароче смотри, у нас есть ебучий ооп который заебись но определённые вещи в нём ломают всё в пизду нахуй. По вервых это наследование, которое создаёт ебейшее связывание всего кода программы и его частей, что приводит с нагромождению костылей, багам, проёбаным попыткам недублирования кода и прочего говна. Связано это с тем что в большинстве случаем ООП-ом пользуются макаки которым втюхали что раз объекты это отражение мира значит всё заебись можно так и делать. так то оно частично так, но вот только в жизни принцип наследования не существует сука! А его все используют причмокивая. В жизни существует только композиция. это хороший ООП путь в самом деле (тот же раст который я полюбил ссыт на наследование там этого сделать вообще нельзя, но можно агрегировать и композировать части программы).
Вторая проблема, в том что ООП программы ссать хотели на процессы стоящие за управлением памятью, кэшированием и вообще производительность. Так как данные инкапсулированы по классам, (а особенно когда используется наследование), они загружаются и разбрасываются в в памяти просто блядь в разные стороны, и процессору постоянно приходится прыгать по секторам памяти. Не говоря уже про кэш-промахи, которые вообще въёбывают перфоманс в десятки раз.
Теперь совсем чуть чуть про DOD (Data Oriented Design), базис ECS:
Если в ООП мы работаем с отдельными блоками, инкапсулированных частей программы - классов, то концепция дата ориентированного дизайна предполагает что вся архитектура программы будет строиться уже из централизации данных, и наращивания таких "микросервисов", каждый из которых выполняет только определённую задачу, не хранит никакие данные а только получает доступ к ним, а также желательно не растёт "вверх" (то есть опять же в пизду наследование). Весь сок в том, что DOD архитектура очень эффективно складывает данные одного вида в огромные цепочки одинаковых последовательных данных, и каждый микросерсвис в единицу времени может без прыжков хоть за раз захавать в кэш эту линию данных, и очень быстро его обработать. В общем говоря концепция DOD построена вокруг очень узкого места в компустере, а именно общения RAM - процессор. Можно почитать тут ещё немного:https://habr.com/ru/post/321106/
А теперь о УСЫ:
Сразу скажу, что есть огромное количество ECS реализаций разного качества и направленности, и у всех взаимодействия между этими компонентами устроены по-разному.
- У нас есть компоненты, это просто данные без логики, можешь представлять их как struct в С++ или аналогичных языках. Могут быть разных типов. Каждый тип компонента имеет фиксированную длину, и они укладываются в памяти в массивы.
- Есть Системы. Это просто код без данных, который исполняется в какой-то последовательности, или через задачи. Тут как бы у разных ECS свои реализации, он может быть сделан просто через потиковый update, может через планировщик, можно сделать как вообще душе угодно, тут тебя не ограничивают. Я лично хотел орагнизовать гибридку из самых простых планировщиков, и дочерних под систем.
- Есть entity. Они являются просто "клеем" для всех компонентов, чтобы выледить их из общей кучи и приписать к одной сущности программной.
Микропример:
Вот у нас есть компоненты:
- Имя - строка
- Позиция - 3 числа
- Вектор движения - 3 числа.
- Объём жира - число
Запускаем игру, инициализиуем игровые ентити ( да из того же json граббаем), и собираем по компонентам ентити:
Entity 1:
Имя: "Жирный с \бе"
Позиция: (1, 2, 0)
Вектор движения: (0, 0, 10)
Объём жира: (9000)
Entity 2:
Имя: "Кирилл"
Позиция: (0, -90, 0)
Самая суть в том, что в памяти ентити лежат в одном месте, и имеют только id типа компонента и его индекс, а таким компоненты лежат как то так:
Имя - ("Жирный с \бе"), ("Кирилл") ... ("Домики")
Системы же устроены так, что им вообще похуй нахуй насчёт того кого они обрабатывают. Вот у нас допустим есть система которая отвественна за движение, всё что ей нужно это взять 2 массива движения и вектора, и складывать их значения соотвественно.
В общем рассказал как мог, спрашивай ответы я попробую сделать так чтобы ты всё понял, сам люто влюбился в ECS и готовлюсь по чуть чуть свой рогуль с анатомией и аутизмом делать. Но нужно время.
Я могу, потому что дрочу на ECS.
Сначала пойдём от противного, и немного про минусы ООП:
Кароче смотри, у нас есть ебучий ооп который заебись но определённые вещи в нём ломают всё в пизду нахуй. По вервых это наследование, которое создаёт ебейшее связывание всего кода программы и его частей, что приводит с нагромождению костылей, багам, проёбаным попыткам недублирования кода и прочего говна. Связано это с тем что в большинстве случаем ООП-ом пользуются макаки которым втюхали что раз объекты это отражение мира значит всё заебись можно так и делать. так то оно частично так, но вот только в жизни принцип наследования не существует сука! А его все используют причмокивая. В жизни существует только композиция. это хороший ООП путь в самом деле (тот же раст который я полюбил ссыт на наследование там этого сделать вообще нельзя, но можно агрегировать и композировать части программы).
Вторая проблема, в том что ООП программы ссать хотели на процессы стоящие за управлением памятью, кэшированием и вообще производительность. Так как данные инкапсулированы по классам, (а особенно когда используется наследование), они загружаются и разбрасываются в в памяти просто блядь в разные стороны, и процессору постоянно приходится прыгать по секторам памяти. Не говоря уже про кэш-промахи, которые вообще въёбывают перфоманс в десятки раз.
Теперь совсем чуть чуть про DOD (Data Oriented Design), базис ECS:
Если в ООП мы работаем с отдельными блоками, инкапсулированных частей программы - классов, то концепция дата ориентированного дизайна предполагает что вся архитектура программы будет строиться уже из централизации данных, и наращивания таких "микросервисов", каждый из которых выполняет только определённую задачу, не хранит никакие данные а только получает доступ к ним, а также желательно не растёт "вверх" (то есть опять же в пизду наследование). Весь сок в том, что DOD архитектура очень эффективно складывает данные одного вида в огромные цепочки одинаковых последовательных данных, и каждый микросерсвис в единицу времени может без прыжков хоть за раз захавать в кэш эту линию данных, и очень быстро его обработать. В общем говоря концепция DOD построена вокруг очень узкого места в компустере, а именно общения RAM - процессор. Можно почитать тут ещё немного:https://habr.com/ru/post/321106/
А теперь о УСЫ:
Сразу скажу, что есть огромное количество ECS реализаций разного качества и направленности, и у всех взаимодействия между этими компонентами устроены по-разному.
- У нас есть компоненты, это просто данные без логики, можешь представлять их как struct в С++ или аналогичных языках. Могут быть разных типов. Каждый тип компонента имеет фиксированную длину, и они укладываются в памяти в массивы.
- Есть Системы. Это просто код без данных, который исполняется в какой-то последовательности, или через задачи. Тут как бы у разных ECS свои реализации, он может быть сделан просто через потиковый update, может через планировщик, можно сделать как вообще душе угодно, тут тебя не ограничивают. Я лично хотел орагнизовать гибридку из самых простых планировщиков, и дочерних под систем.
- Есть entity. Они являются просто "клеем" для всех компонентов, чтобы выледить их из общей кучи и приписать к одной сущности программной.
Микропример:
Вот у нас есть компоненты:
- Имя - строка
- Позиция - 3 числа
- Вектор движения - 3 числа.
- Объём жира - число
Запускаем игру, инициализиуем игровые ентити ( да из того же json граббаем), и собираем по компонентам ентити:
Entity 1:
Имя: "Жирный с \бе"
Позиция: (1, 2, 0)
Вектор движения: (0, 0, 10)
Объём жира: (9000)
Entity 2:
Имя: "Кирилл"
Позиция: (0, -90, 0)
Самая суть в том, что в памяти ентити лежат в одном месте, и имеют только id типа компонента и его индекс, а таким компоненты лежат как то так:
Имя - ("Жирный с \бе"), ("Кирилл") ... ("Домики")
Системы же устроены так, что им вообще похуй нахуй насчёт того кого они обрабатывают. Вот у нас допустим есть система которая отвественна за движение, всё что ей нужно это взять 2 массива движения и вектора, и складывать их значения соотвественно.
В общем рассказал как мог, спрашивай ответы я попробую сделать так чтобы ты всё понял, сам люто влюбился в ECS и готовлюсь по чуть чуть свой рогуль с анатомией и аутизмом делать. Но нужно время.
>>649102
Я могу, потому что дрочу на ECS.
Сначала пойдём от противного, и немного про минусы ООП:
Кароче смотри, у нас есть ебучий ооп который заебись но определённые вещи в нём ломают всё в пизду нахуй. По вервых это наследование, которое создаёт ебейшее связывание всего кода программы и его частей, что приводит с нагромождению костылей, багам, проёбаным попыткам недублирования кода и прочего говна. Связано это с тем что в большинстве случаем ООП-ом пользуются макаки которым втюхали что раз объекты это отражение мира значит всё заебись можно так и делать. так то оно частично так, но вот только в жизни принцип наследования не существует сука! А его все используют причмокивая. В жизни существует только композиция. это хороший ООП путь в самом деле (тот же раст который я полюбил ссыт на наследование там этого сделать вообще нельзя, но можно агрегировать и композировать части программы).
Вторая проблема, в том что ООП программы ссать хотели на процессы стоящие за управлением памятью, кэшированием и вообще производительность. Так как данные инкапсулированы по классам, (а особенно когда используется наследование), они загружаются и разбрасываются в в памяти просто блядь в разные стороны, и процессору постоянно приходится прыгать по секторам памяти. Не говоря уже про кэш-промахи, которые вообще въёбывают перфоманс в десятки раз.
Теперь совсем чуть чуть про DOD (Data Oriented Design), базис ECS:
Если в ООП мы работаем с отдельными блоками, инкапсулированных частей программы - классов, то концепция дата ориентированного дизайна предполагает что вся архитектура программы будет строиться уже из централизации данных, и наращивания таких "микросервисов", каждый из которых выполняет только определённую задачу, не хранит никакие данные а только получает доступ к ним, а также желательно не растёт "вверх" (то есть опять же в пизду наследование). Весь сок в том, что DOD архитектура очень эффективно складывает данные одного вида в огромные цепочки одинаковых последовательных данных, и каждый микросерсвис в единицу времени может без прыжков хоть за раз захавать в кэш эту линию данных, и очень быстро его обработать. В общем говоря концепция DOD построена вокруг очень узкого места в компустере, а именно общения RAM - процессор. Можно почитать тут ещё немного:https://habr.com/ru/post/321106/
А теперь о УСЫ:
Сразу скажу, что есть огромное количество ECS реализаций разного качества и направленности, и у всех взаимодействия между этими компонентами устроены по-разному.
- У нас есть компоненты, это просто данные без логики, можешь представлять их как struct в С++ или аналогичных языках. Могут быть разных типов. Каждый тип компонента имеет фиксированную длину, и они укладываются в памяти в массивы.
- Есть Системы. Это просто код без данных, который исполняется в какой-то последовательности, или через задачи. Тут как бы у разных ECS свои реализации, он может быть сделан просто через потиковый update, может через планировщик, можно сделать как вообще душе угодно, тут тебя не ограничивают. Я лично хотел орагнизовать гибридку из самых простых планировщиков, и дочерних под систем.
- Есть entity. Они являются просто "клеем" для всех компонентов, чтобы выледить их из общей кучи и приписать к одной сущности программной.
Микропример:
Вот у нас есть компоненты:
- Имя - строка
- Позиция - 3 числа
- Вектор движения - 3 числа.
- Объём жира - число
Запускаем игру, инициализиуем игровые ентити ( да из того же json граббаем), и собираем по компонентам ентити:
Entity 1:
Имя: "Жирный с \бе"
Позиция: (1, 2, 0)
Вектор движения: (0, 0, 10)
Объём жира: (9000)
Entity 2:
Имя: "Кирилл"
Позиция: (0, -90, 0)
Самая суть в том, что в памяти ентити лежат в одном месте, и имеют только id типа компонента и его индекс, а таким компоненты лежат как то так:
Имя - ("Жирный с \бе"), ("Кирилл") ... ("Домики")
Системы же устроены так, что им вообще похуй нахуй насчёт того кого они обрабатывают. Вот у нас допустим есть система которая отвественна за движение, всё что ей нужно это взять 2 массива движения и вектора, и складывать их значения соотвественно.
В общем рассказал как мог, спрашивай ответы я попробую сделать так чтобы ты всё понял, сам люто влюбился в ECS и готовлюсь по чуть чуть свой рогуль с анатомией и аутизмом делать. Но нужно время.
Я могу, потому что дрочу на ECS.
Сначала пойдём от противного, и немного про минусы ООП:
Кароче смотри, у нас есть ебучий ооп который заебись но определённые вещи в нём ломают всё в пизду нахуй. По вервых это наследование, которое создаёт ебейшее связывание всего кода программы и его частей, что приводит с нагромождению костылей, багам, проёбаным попыткам недублирования кода и прочего говна. Связано это с тем что в большинстве случаем ООП-ом пользуются макаки которым втюхали что раз объекты это отражение мира значит всё заебись можно так и делать. так то оно частично так, но вот только в жизни принцип наследования не существует сука! А его все используют причмокивая. В жизни существует только композиция. это хороший ООП путь в самом деле (тот же раст который я полюбил ссыт на наследование там этого сделать вообще нельзя, но можно агрегировать и композировать части программы).
Вторая проблема, в том что ООП программы ссать хотели на процессы стоящие за управлением памятью, кэшированием и вообще производительность. Так как данные инкапсулированы по классам, (а особенно когда используется наследование), они загружаются и разбрасываются в в памяти просто блядь в разные стороны, и процессору постоянно приходится прыгать по секторам памяти. Не говоря уже про кэш-промахи, которые вообще въёбывают перфоманс в десятки раз.
Теперь совсем чуть чуть про DOD (Data Oriented Design), базис ECS:
Если в ООП мы работаем с отдельными блоками, инкапсулированных частей программы - классов, то концепция дата ориентированного дизайна предполагает что вся архитектура программы будет строиться уже из централизации данных, и наращивания таких "микросервисов", каждый из которых выполняет только определённую задачу, не хранит никакие данные а только получает доступ к ним, а также желательно не растёт "вверх" (то есть опять же в пизду наследование). Весь сок в том, что DOD архитектура очень эффективно складывает данные одного вида в огромные цепочки одинаковых последовательных данных, и каждый микросерсвис в единицу времени может без прыжков хоть за раз захавать в кэш эту линию данных, и очень быстро его обработать. В общем говоря концепция DOD построена вокруг очень узкого места в компустере, а именно общения RAM - процессор. Можно почитать тут ещё немного:https://habr.com/ru/post/321106/
А теперь о УСЫ:
Сразу скажу, что есть огромное количество ECS реализаций разного качества и направленности, и у всех взаимодействия между этими компонентами устроены по-разному.
- У нас есть компоненты, это просто данные без логики, можешь представлять их как struct в С++ или аналогичных языках. Могут быть разных типов. Каждый тип компонента имеет фиксированную длину, и они укладываются в памяти в массивы.
- Есть Системы. Это просто код без данных, который исполняется в какой-то последовательности, или через задачи. Тут как бы у разных ECS свои реализации, он может быть сделан просто через потиковый update, может через планировщик, можно сделать как вообще душе угодно, тут тебя не ограничивают. Я лично хотел орагнизовать гибридку из самых простых планировщиков, и дочерних под систем.
- Есть entity. Они являются просто "клеем" для всех компонентов, чтобы выледить их из общей кучи и приписать к одной сущности программной.
Микропример:
Вот у нас есть компоненты:
- Имя - строка
- Позиция - 3 числа
- Вектор движения - 3 числа.
- Объём жира - число
Запускаем игру, инициализиуем игровые ентити ( да из того же json граббаем), и собираем по компонентам ентити:
Entity 1:
Имя: "Жирный с \бе"
Позиция: (1, 2, 0)
Вектор движения: (0, 0, 10)
Объём жира: (9000)
Entity 2:
Имя: "Кирилл"
Позиция: (0, -90, 0)
Самая суть в том, что в памяти ентити лежат в одном месте, и имеют только id типа компонента и его индекс, а таким компоненты лежат как то так:
Имя - ("Жирный с \бе"), ("Кирилл") ... ("Домики")
Системы же устроены так, что им вообще похуй нахуй насчёт того кого они обрабатывают. Вот у нас допустим есть система которая отвественна за движение, всё что ей нужно это взять 2 массива движения и вектора, и складывать их значения соотвественно.
В общем рассказал как мог, спрашивай ответы я попробую сделать так чтобы ты всё понял, сам люто влюбился в ECS и готовлюсь по чуть чуть свой рогуль с анатомией и аутизмом делать. Но нужно время.
>>649122
https://habr.com/ru/post/343778/
Добавлю вот эту статью. У этого паренька лютая ECS. Хотя для моих запросов не подходит.
https://habr.com/ru/post/343778/
Добавлю вот эту статью. У этого паренька лютая ECS. Хотя для моих запросов не подходит.
>>649132
Они инициализируются при загрузке с диска же, вообще префабы - это отдельная сложная тема, которую статьи энтри-левела про ECS аккуратно обходят стороной. Я в своём аутичном самописном движке запилил механизм префабов, есличо, спрашивай вопросы. Ну или дефолтными значениями какими-то.
Ещё накидаю в этот добротред своих ссылок по ECS:
Ресурсы по DDD: https://github.com/dbartolini/data-oriented-design
На рюзском про ECS: https://fateev.pro/ru/gamedev/entity-component-system.html
Канонiчная статья по ECS: http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/
Пример списка систем в игре: https://www.reddit.com/r/roguelikedev/comments/7yhil8/entity_component_system/duqbdho/
Они инициализируются при загрузке с диска же, вообще префабы - это отдельная сложная тема, которую статьи энтри-левела про ECS аккуратно обходят стороной. Я в своём аутичном самописном движке запилил механизм префабов, есличо, спрашивай вопросы. Ну или дефолтными значениями какими-то.
Ещё накидаю в этот добротред своих ссылок по ECS:
Ресурсы по DDD: https://github.com/dbartolini/data-oriented-design
На рюзском про ECS: https://fateev.pro/ru/gamedev/entity-component-system.html
Канонiчная статья по ECS: http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/
Пример списка систем в игре: https://www.reddit.com/r/roguelikedev/comments/7yhil8/entity_component_system/duqbdho/
>>649132
>>649142
Это кстати не я отвечал (составитель высера про ECS), а какой-то другой чел. Я вообще не знаю про префабы, это что-то связанное с Юнити ECS а мне на него как-то похуй в силу того что я двиг только для рогалика затачиваю.
>>649132
Опять же, ты можешь любым образом как хочешь это делать. Можно создавать разные деревья систем, где одна другие будет вызывать и инициализировать. Можно создать систему которая будет подгружать сохранение, другое, а потом любые системы будут уже иметь доступ к этим массивам. Это в общем довольно узкий и местечковый вопрос.
>>649142
Годные ссылки. Что есть такое Префабы, это же действительно только в юнити ЕЦС реализации встречается? или я только что гранату?
>>649142
Это кстати не я отвечал (составитель высера про ECS), а какой-то другой чел. Я вообще не знаю про префабы, это что-то связанное с Юнити ECS а мне на него как-то похуй в силу того что я двиг только для рогалика затачиваю.
>>649132
Опять же, ты можешь любым образом как хочешь это делать. Можно создавать разные деревья систем, где одна другие будет вызывать и инициализировать. Можно создать систему которая будет подгружать сохранение, другое, а потом любые системы будут уже иметь доступ к этим массивам. Это в общем довольно узкий и местечковый вопрос.
>>649142
Годные ссылки. Что есть такое Префабы, это же действительно только в юнити ЕЦС реализации встречается? или я только что гранату?
53 Кб, 604x604>>649142
Я вообще думал чтобы внутри игры у меня был огромный такой блядь сисЭм, который как планировщик принимал разные таски, или составлял расписание обхода по флагам, которые стоят у предметов. Не знаю точно, пока очень усердно думаю над тем как это можно разрулить это дело, чтобы изначально всё сука такое гибкое было пиздец. Есть уже много абстрактных описаний того как это будет работать, но пока не подвёл все эти вещи под общий знаменатель.
Я вообще думал чтобы внутри игры у меня был огромный такой блядь сисЭм, который как планировщик принимал разные таски, или составлял расписание обхода по флагам, которые стоят у предметов. Не знаю точно, пока очень усердно думаю над тем как это можно разрулить это дело, чтобы изначально всё сука такое гибкое было пиздец. Есть уже много абстрактных описаний того как это будет работать, но пока не подвёл все эти вещи под общий знаменатель.
>>649163
Дело в том, что моча > говно > гной китайских стариков, умирающих от пневмонии, вызванной коронавирусом > юнити префабы есть не только в юнити, но поисковая выдача засрана статьями для бывших таксистов и официантов, которые думают, что на сирешётке можно быстро вкатиться в геймдев и сделать свою убер-игру.
Префабом я называю этакое лекало, шаблон, по которому будут клепаться новые компоненты. Например, у тебя есть компонент, отвечающий за отрисовку спрайта монстра. Ты же не будешь для каждого монстра подгружать одну и ту же картинку с диска, правильно? Не будешь, ты один раз её подгрузишь вначале и затем будешь записывать в соответствующее поле в компоненте монстра.
Вот ещё пара ссылок по поводу:
https://gamedev.stackexchange.com/questions/163914/how-to-design-prefabs-in-entity-component-systems
https://www.reddit.com/r/gamedev/comments/80490i/efficient_prefabs_instancing_with_ecs/
> Что есть такое Префабы, это же действительно только в юнити ЕЦС реализации встречается?
Дело в том, что моча > говно > гной китайских стариков, умирающих от пневмонии, вызванной коронавирусом > юнити префабы есть не только в юнити, но поисковая выдача засрана статьями для бывших таксистов и официантов, которые думают, что на сирешётке можно быстро вкатиться в геймдев и сделать свою убер-игру.
Префабом я называю этакое лекало, шаблон, по которому будут клепаться новые компоненты. Например, у тебя есть компонент, отвечающий за отрисовку спрайта монстра. Ты же не будешь для каждого монстра подгружать одну и ту же картинку с диска, правильно? Не будешь, ты один раз её подгрузишь вначале и затем будешь записывать в соответствующее поле в компоненте монстра.
Вот ещё пара ссылок по поводу:
https://gamedev.stackexchange.com/questions/163914/how-to-design-prefabs-in-entity-component-systems
https://www.reddit.com/r/gamedev/comments/80490i/efficient_prefabs_instancing_with_ecs/
>>649175
А, то есть паттерны такие? Ну вот допустим я когда задумывался над этой темой пришёл в выводу о том что следует создавать отдельную систему и тип компонентов отвественных за подгрузку моделек в игру, а там уже для каждой ентити просто опять же давать id этой модельки, или текстурки. Но не знал что такой метод называется префабом.
Кстати почему ты так красноречиво отозвался о юнити? я слышал краем уха про его Job System и Burst, разве это дело не исправило? (Сам потом подумывал после рогуля попробовать юнити как движок для песочницы)
А, то есть паттерны такие? Ну вот допустим я когда задумывался над этой темой пришёл в выводу о том что следует создавать отдельную систему и тип компонентов отвественных за подгрузку моделек в игру, а там уже для каждой ентити просто опять же давать id этой модельки, или текстурки. Но не знал что такой метод называется префабом.
Кстати почему ты так красноречиво отозвался о юнити? я слышал краем уха про его Job System и Burst, разве это дело не исправило? (Сам потом подумывал после рогуля попробовать юнити как движок для песочницы)
>>649175
да, я думал про то как такие префабы организовывать в условии когда у меня каждое существо будет состоять из органов тканей и прочего, как это ToadOne делает, только более интересным образом я это провернул. Там у меня получаются лютые деревья, и я пока вообще совершенно не имею понятия как организовывать gameObject-creature. Я могу высраться о том что я там накириллил в еверноуте, раз Оп давно обосрался насмерть.
да, я думал про то как такие префабы организовывать в условии когда у меня каждое существо будет состоять из органов тканей и прочего, как это ToadOne делает, только более интересным образом я это провернул. Там у меня получаются лютые деревья, и я пока вообще совершенно не имею понятия как организовывать gameObject-creature. Я могу высраться о том что я там накириллил в еверноуте, раз Оп давно обосрался насмерть.
>>649182
Братюнь, каждый день, когда ты думаешь над своей мега-системой, ты над ней не работаешь. Это у тебя такая форма прокрастинации. Начни делать хоть как-то, хоть по чуть-чуть, сделай первую хуёвую верию, зато сделав её, поймёшь, как надо делать лучше и начнёшь делать лучше. Я сам такой.
Потому что хуюнити вообще и сирешётка в частности - это распиаренное говно для нубов, которые существуют только из-за нечеловеческих вливаний бабла в их маркетинг мокросовтом. Человек, профессионально занимающийся программированием или геймдевом, это говно будет десятой дорогой обходить.
Если перейти на язык метафор, это как если бы качок вместо того, чтобы готовить себе условную куру с гречей и прочий спортпит, жрал бы в макдаке.
Братюнь, каждый день, когда ты думаешь над своей мега-системой, ты над ней не работаешь. Это у тебя такая форма прокрастинации. Начни делать хоть как-то, хоть по чуть-чуть, сделай первую хуёвую верию, зато сделав её, поймёшь, как надо делать лучше и начнёшь делать лучше. Я сам такой.
> Кстати почему ты так красноречиво отозвался о юнити?
Потому что хуюнити вообще и сирешётка в частности - это распиаренное говно для нубов, которые существуют только из-за нечеловеческих вливаний бабла в их маркетинг мокросовтом. Человек, профессионально занимающийся программированием или геймдевом, это говно будет десятой дорогой обходить.
Если перейти на язык метафор, это как если бы качок вместо того, чтобы готовить себе условную куру с гречей и прочий спортпит, жрал бы в макдаке.
604 Кб, 800x595Ого как тред подорвало.
Ну, во-первых, братюни, спасибо за обстоятельные ответы.
Прежде чем сформулировать следующий вопрос, отправляюсь изучать данные ссылки и матчасть.
Гифка текущего прогресса, ака "костыли и велосипеды", для поддержания интереса к треду.
Ну, во-первых, братюни, спасибо за обстоятельные ответы.
Прежде чем сформулировать следующий вопрос, отправляюсь изучать данные ссылки и матчасть.
Гифка текущего прогресса, ака "костыли и велосипеды", для поддержания интереса к треду.
>>649183
Да, я слышал что решётка это хуйпизда по перфомансу, поэтому сразу перепрыннул на Rust-lang.
Весь как раз СЭС в том сейчас, что я стараюсь изо всех сил задрочить погромирование хоть на каком-то уровне чтобы написать что-то годное. Сейчас конкретно вроде более менее немного осталось чтобы уже схватить за жопу legion ECS (быстрая как понос либа на расте, на которой я немного попрототипирую) и bearLib чтобы попробовать хоть что-то высрать.
Те надумки в основном скопились у меня за год того времени что я старательно не хотел вкатываться в геймдев потому что знал что обратной дороги нет, но не удержался :D
>>649187
Тут нас по идее 3 аутиста всего навскидку. Я тред уже год мониторю, ОП точно сдох.
Да, я слышал что решётка это хуйпизда по перфомансу, поэтому сразу перепрыннул на Rust-lang.
>Братюнь, каждый день, когда ты думаешь над своей мега-системой, ты над ней не работаешь.
Весь как раз СЭС в том сейчас, что я стараюсь изо всех сил задрочить погромирование хоть на каком-то уровне чтобы написать что-то годное. Сейчас конкретно вроде более менее немного осталось чтобы уже схватить за жопу legion ECS (быстрая как понос либа на расте, на которой я немного попрототипирую) и bearLib чтобы попробовать хоть что-то высрать.
Те надумки в основном скопились у меня за год того времени что я старательно не хотел вкатываться в геймдев потому что знал что обратной дороги нет, но не удержался :D
>>649187
Тут нас по идее 3 аутиста всего навскидку. Я тред уже год мониторю, ОП точно сдох.
мне до сих пор не ясно нахера в "игровом движке" наружу торчит только шарп(который потом все равно в крешты перекатывается)
зачем эта прокладка? типа легче что ли?
зачем эта прокладка? типа легче что ли?
>>649191
Ну и ладно, качество > количества. И я не ожидал, честно говоря, что задав вопрос получу ответ, это же двач. А оно вон как.
И раз тред называется "рогалики", я так понимаю что это не тред одного анона а что-то вроде sharing saturday на r/roguelikedev, так что можно лить любой свой высер (что и делаю, лол).
=> Давайте лить.
(алсо, разглядывая гифку, нашел багу в расчете line of sight. Так что постить в тред еще и полезно!)
Ну и ладно, качество > количества. И я не ожидал, честно говоря, что задав вопрос получу ответ, это же двач. А оно вон как.
И раз тред называется "рогалики", я так понимаю что это не тред одного анона а что-то вроде sharing saturday на r/roguelikedev, так что можно лить любой свой высер (что и делаю, лол).
=> Давайте лить.
(алсо, разглядывая гифку, нашел багу в расчете line of sight. Так что постить в тред еще и полезно!)
![My+eyes+bleed+from+reading+so+much+in+one+sitting+c2b1cc660[...].png](https://2ch.hk//gd/src/558349/15842810913860.png)
>>649191
Тоже зашквар, конечно, но не такой страшный, как мокросовт - ржавчину проталкивает мозилла, они, несмотря на засилье сжв-пидоров, вроде как за свободный интернет и всё такое.
> Да, я слышал что решётка это хуйпизда по перфомансу, поэтому сразу перепрыннул на Rust-lang.
Тоже зашквар, конечно, но не такой страшный, как мокросовт - ржавчину проталкивает мозилла, они, несмотря на засилье сжв-пидоров, вроде как за свободный интернет и всё такое.
>>649212
Почему Rust зашквар? Он довольно быстрый, очень безопасный, что для многопоточных приложений вообще самая мякотка. Чтобы писать такого же качества код без сегфолтов на С++ надо отхуярить на нём десяток лет.
Почему Rust зашквар? Он довольно быстрый, очень безопасный, что для многопоточных приложений вообще самая мякотка. Чтобы писать такого же качества код без сегфолтов на С++ надо отхуярить на нём десяток лет.
>>649215
Если закрыть глаза на сырость языка, с этим твоим аргументом я полностью согласен. Повторю свой аргумент ещё раз: rust проталкивает mozilla. Я не верю в языки, в маркетинг которых вкладываются многомиллионные транснациональные корпорации. Если язык так хорош, зачем ему маркетинг? Спецы увидят, что он хорош и будут его использовать из-за того, что он хорош, а не из-за того, что из каждого утюга им говорят, что он хорош.
> Он довольно быстрый, очень безопасный, что для многопоточных приложений вообще самая мякотка. Чтобы писать такого же качества код без сегфолтов на С++ надо отхуярить на нём десяток лет.
Если закрыть глаза на сырость языка, с этим твоим аргументом я полностью согласен. Повторю свой аргумент ещё раз: rust проталкивает mozilla. Я не верю в языки, в маркетинг которых вкладываются многомиллионные транснациональные корпорации. Если язык так хорош, зачем ему маркетинг? Спецы увидят, что он хорош и будут его использовать из-за того, что он хорош, а не из-за того, что из каждого утюга им говорят, что он хорош.
>>649376
Я думаю, чтобы вставлять палки в колёса гуглу с его Goвном. Зачем, по-твоему, были созданы Java, C#, Go, Rust? Чтобы оттяпать долю айтишного рынка.
Я думаю, чтобы вставлять палки в колёса гуглу с его Goвном. Зачем, по-твоему, были созданы Java, C#, Go, Rust? Чтобы оттяпать долю айтишного рынка.
>>649368
Ну во первых это уже выходит за рамки самого языка, а входит в рамки психологии, что там кто увидит и почему кому-то внезапно надо переходить на Rust.
Могу сказать только то, что он удобный, у него есть хороший подгрузчик модулей crates, но пока попросту нету софта нужного. Вообще я понял что разрабам С++, особенно старичкам таким будет очень хуёво на Rust из за того что правила написания кода запрещают мутить просто так какую-то хтоническую хуйню с памятью, чем обычно и занимались они на крестах. Вместо этого подобные проблемы на расте решаются общим пересмотром метода решения задачи. Конечно если и единицы исключения, которым будет легко поменять парадигму в голове, но таких много. Вот и получается, кто старший давится синдромум утёнка и говорит что раст это говно, а кто младший и только вкатывается в основном обсираются из за его сложности. Я в общем-то срал на все эти политические маняврирования корпораций, просто похуй, понимаешь бля? Если я беру инструмент и смотрю что он хороший, то похуй какой там логотип.
>>649388
Вот опять же, нас эта пизделовка вообще не касается, потому что если человек достаточно ясно видит всю хуйню, он сам увидит пытается ли маркетинг сраку жёваную впарить или же что-то стоящее. Реальность over Видение.
Ну во первых это уже выходит за рамки самого языка, а входит в рамки психологии, что там кто увидит и почему кому-то внезапно надо переходить на Rust.
Могу сказать только то, что он удобный, у него есть хороший подгрузчик модулей crates, но пока попросту нету софта нужного. Вообще я понял что разрабам С++, особенно старичкам таким будет очень хуёво на Rust из за того что правила написания кода запрещают мутить просто так какую-то хтоническую хуйню с памятью, чем обычно и занимались они на крестах. Вместо этого подобные проблемы на расте решаются общим пересмотром метода решения задачи. Конечно если и единицы исключения, которым будет легко поменять парадигму в голове, но таких много. Вот и получается, кто старший давится синдромум утёнка и говорит что раст это говно, а кто младший и только вкатывается в основном обсираются из за его сложности. Я в общем-то срал на все эти политические маняврирования корпораций, просто похуй, понимаешь бля? Если я беру инструмент и смотрю что он хороший, то похуй какой там логотип.
>>649388
Вот опять же, нас эта пизделовка вообще не касается, потому что если человек достаточно ясно видит всю хуйню, он сам увидит пытается ли маркетинг сраку жёваную впарить или же что-то стоящее. Реальность over Видение.
>>649368
Первая стабильная версия вышла 5 лет назад, проснись.
Язык уже стабильнее некуда, никакой "сырости" там нет, его уже спокойно юзают в продакшене овердохуя компаний.
Шизик, тогда тебе нельзя программировать на c# - его многомиллионный майкрософт создал и продвигал. На джаве тоже нельзя - её многомиллионный оракл продвигал.
На С++ тоже нельзя, его развитием и продвижением занимались десятки многомиллионных компаний, в том числе и майкрософт.
С твоими критериями тебе остается два языка на выбор - бейсик и фри паскаль, выбирай.
Чтобы "спецы" про него узнали, нет? Откуда они еще узнают про язык, если про него не будут рассказывать, а просто где-то на серваке будет лежать билд, без описания, документации, статей.
Ты совсем поехавший, или притворяешься?
>Если закрыть глаза на сырость языка
Первая стабильная версия вышла 5 лет назад, проснись.
Язык уже стабильнее некуда, никакой "сырости" там нет, его уже спокойно юзают в продакшене овердохуя компаний.
>Я не верю в языки, в маркетинг которых вкладываются многомиллионные транснациональные корпорации
Шизик, тогда тебе нельзя программировать на c# - его многомиллионный майкрософт создал и продвигал. На джаве тоже нельзя - её многомиллионный оракл продвигал.
На С++ тоже нельзя, его развитием и продвижением занимались десятки многомиллионных компаний, в том числе и майкрософт.
С твоими критериями тебе остается два языка на выбор - бейсик и фри паскаль, выбирай.
>Если язык так хорош, зачем ему маркетинг? Спецы увидят, что он хорош и будут его использовать
Чтобы "спецы" про него узнали, нет? Откуда они еще узнают про язык, если про него не будут рассказывать, а просто где-то на серваке будет лежать билд, без описания, документации, статей.
Ты совсем поехавший, или притворяешься?
>>649419
Я не он, но анонче не ругайся и не разводи срачи. Блять хоть не тут, нас и так мало вы ещё срётесь.
Я не он, но анонче не ругайся и не разводи срачи. Блять хоть не тут, нас и так мало вы ещё срётесь.
>>649419
А я что, разве давал повод подозревать себя в таком страшном говноедстве?
> тебе нельзя программировать на c#
А я что, разве давал повод подозревать себя в таком страшном говноедстве?
раз уж тут за языки трут, что думаете о jai посоны? пилится игроделом для игроделов, философия мне по нраву
https://sites.google.com/site/jailanguageprimer/
https://sites.google.com/site/jailanguageprimer/
61 Кб, 881x628>>649448
Ну у него интересные есть особенности, бесспорно. Но без долгой разработки и большой базы людей которые работают с этим ЯП это к сожалению говно без задач. Есть огромное количество всяких годных языков андеграундных языков, но мне кажется адекватный человек который собирается пилить долгоиграющий и большой проект не будет выбирать что-то подобное. К сожалению.
Алсо, нашёл репку на гитхабе и обосрался. Нет спасибо точно не надо.
Ну у него интересные есть особенности, бесспорно. Но без долгой разработки и большой базы людей которые работают с этим ЯП это к сожалению говно без задач. Есть огромное количество всяких годных языков андеграундных языков, но мне кажется адекватный человек который собирается пилить долгоиграющий и большой проект не будет выбирать что-то подобное. К сожалению.
Алсо, нашёл репку на гитхабе и обосрался. Нет спасибо точно не надо.
>>649454
У тебя биполярочка?
>ряя я не верю в языки, в маркетинг которых вкладываются многомиллионные транснациональные корпорации
>ряя язык пилит полтора инвалида в свободное от работы время, нинужон
У тебя биполярочка?
100 Кб, 654x458А мы продолжаем пилить рогалик на пиииииитонеее DDDDDD
В какой-то момент пришла мысль, что я очень завязался на pygame, и мои игровая логика, хранение данных и визуализация начали замешиваться в одну огромную кучу - и выглядит это с точки зрения кода неприглядно, а разрабатывать это добро - еще хуже, чем оно выглядит. В связи с этим я принял решение эти три вещи разделить, и начал отвязку от pygame с точки зрения визуализации. Но чтобы не терять общую картинку, напилил визуализацию через консоль - чистые print и cls. Получилось очень аутентично, я считаю.
Вопрос про ECS номер раз: Пока у меня прям труевый ООП по классике. Пример - есть класс Creature, которое имеет всякие свойства x, y, damage, health и методы в духе move , attack, die - а также унаследованные от него классы player, zombie, slime и так далее.
Из того, что я понял про ECS, чтобы адекватно перекатить это все в эту модель, нужно:
1) внутренние методы класса Creature превратить в классы
2) сделать в каждом классе метод типа succeed
3) В каждом классе моба (slime, zombie и т.д.) сделать по объекту этих превращенных методоклассов
4) дергать метод succeed для каждого этого объекта.
Так примерно?
В какой-то момент пришла мысль, что я очень завязался на pygame, и мои игровая логика, хранение данных и визуализация начали замешиваться в одну огромную кучу - и выглядит это с точки зрения кода неприглядно, а разрабатывать это добро - еще хуже, чем оно выглядит. В связи с этим я принял решение эти три вещи разделить, и начал отвязку от pygame с точки зрения визуализации. Но чтобы не терять общую картинку, напилил визуализацию через консоль - чистые print и cls. Получилось очень аутентично, я считаю.
Вопрос про ECS номер раз: Пока у меня прям труевый ООП по классике. Пример - есть класс Creature, которое имеет всякие свойства x, y, damage, health и методы в духе move , attack, die - а также унаследованные от него классы player, zombie, slime и так далее.
Из того, что я понял про ECS, чтобы адекватно перекатить это все в эту модель, нужно:
1) внутренние методы класса Creature превратить в классы
2) сделать в каждом классе метод типа succeed
3) В каждом классе моба (slime, zombie и т.д.) сделать по объекту этих превращенных методоклассов
4) дергать метод succeed для каждого этого объекта.
Так примерно?
>>649519
Ну надо
Ну надо
150 Кб, 655x458А, line of sight забыл!
Поправлено.
Все что угодно, лишь бы нормально не писать дальше. Хотя именно эту часть мне кажется я сделал заебца.
Поправлено.
Все что угодно, лишь бы нормально не писать дальше. Хотя именно эту часть мне кажется я сделал заебца.
>>649475
Конечно, потому что это писал не я.
Конечно, потому что это писал не я.
>>649551
Дак я что, недостаточно выше описал а бляТЬ? Просил же вопросы вопрошай.
Дак я что, недостаточно выше описал а бляТЬ? Просил же вопросы вопрошай.
>>649495
Из того, что я понял про ECS, чтобы адекватно перекатить это все в эту модель, нужно:
1. Удалить нахуй Класс Creature Создать Класс Component и написать ему базовые методы взаимодействия (добавить удалить найти). Отнаследовать Component и сделать каждый такой тип, а также массив данных внутри него.
2. Все методы и весь испольняющий код вытащить наружу и сделать только как классы без полей. Сделать так чтобы системы были ориентированы только на работу с определёнными компонентами.
Но понимаешь какая фишка. Сейчас твой год нельзя просто взять и перенести на ECS, потому что ECS это очень глобальное изменение архитектуры кода. Советую сразу найти либу на питон для ECS и не пытаться что-то своё городить если не понимаешь есц глубоко.
А вообще советую хуй забить на него потому что реально без понимания ты только ещё больше запутаешься в каше из методологий ООП и ЕЦС и потом будешь орать "УЛЮЛЮ ЕСЦ ГОВНО БЕЗ ЗАДАЧ ДЛЯ ПИТУШКОВ"
Из того, что я понял про ECS, чтобы адекватно перекатить это все в эту модель, нужно:
1. Удалить нахуй Класс Creature Создать Класс Component и написать ему базовые методы взаимодействия (добавить удалить найти). Отнаследовать Component и сделать каждый такой тип, а также массив данных внутри него.
2. Все методы и весь испольняющий код вытащить наружу и сделать только как классы без полей. Сделать так чтобы системы были ориентированы только на работу с определёнными компонентами.
Но понимаешь какая фишка. Сейчас твой год нельзя просто взять и перенести на ECS, потому что ECS это очень глобальное изменение архитектуры кода. Советую сразу найти либу на питон для ECS и не пытаться что-то своё городить если не понимаешь есц глубоко.
А вообще советую хуй забить на него потому что реально без понимания ты только ещё больше запутаешься в каше из методологий ООП и ЕЦС и потом будешь орать "УЛЮЛЮ ЕСЦ ГОВНО БЕЗ ЗАДАЧ ДЛЯ ПИТУШКОВ"
31 Кб, 765x537>>649519
Да в любой игре если она обещает быть комплексной более менее требуется ЕСЦ, потому что он решает проблемы связности кода, перекрёстности механик, и скорости работы.
Конечно если ручки прямые.
А для рогаликов писать их на ECS сам бох велел
Да в любой игре если она обещает быть комплексной более менее требуется ЕСЦ, потому что он решает проблемы связности кода, перекрёстности механик, и скорости работы.
Конечно если ручки прямые.
А для рогаликов писать их на ECS сам бох велел
>>649586
Орды зомби. Если выхватить из толпы одного из них, он ведёт себя как зомби: бежит, хватает, кусает, рычит. Все вместе они обсчитываются, как жидкость, которая растекается по локации, заполняя пустоты.
На других паттернах ты заебёшься такое делать, а сделав, заебёшься оптимизировать. На ЕЦС у тебя будет две системы: зомбиОрда - обсчитывающая поведение жидкости, состоящая из частиц в виде отдельных зомби, бегущих при движении и стоящих при остановке, и зомбиНПЦ - которая выхватывает "частицы" у орды, накидывает на них свой набор компонентов и убирает компоненты орды. После чего частица жидкости превращается в зомби и накидывается на тебя. Соответственно, перехватывает частицы при приближении к игроку, отпускает при удалении (при условии, что выделенный зомби перестал преследовать) и зомбиОрда снова подхватывает ничейную сущность, как свою частицу, навешивая на неё свои компоненты.
Соответственно, при добавлении простых НПЦ, если они заражаются, они перехватываются одной из вышеуказанных систем.
Орды зомби. Если выхватить из толпы одного из них, он ведёт себя как зомби: бежит, хватает, кусает, рычит. Все вместе они обсчитываются, как жидкость, которая растекается по локации, заполняя пустоты.
На других паттернах ты заебёшься такое делать, а сделав, заебёшься оптимизировать. На ЕЦС у тебя будет две системы: зомбиОрда - обсчитывающая поведение жидкости, состоящая из частиц в виде отдельных зомби, бегущих при движении и стоящих при остановке, и зомбиНПЦ - которая выхватывает "частицы" у орды, накидывает на них свой набор компонентов и убирает компоненты орды. После чего частица жидкости превращается в зомби и накидывается на тебя. Соответственно, перехватывает частицы при приближении к игроку, отпускает при удалении (при условии, что выделенный зомби перестал преследовать) и зомбиОрда снова подхватывает ничейную сущность, как свою частицу, навешивая на неё свои компоненты.
Соответственно, при добавлении простых НПЦ, если они заражаются, они перехватываются одной из вышеуказанных систем.
>>649586
Связности меньше. У тебя есть данные, разные виды которых ты можешь свободно удалять и добавлять. Есть системы, которые друг с другом не пересекаются по сути и не лезут в функционал друг друга. Опять же не связные.
В большинстве приложений (особенно сделаными дилетантами) связанная архитектура можешь сам нагуглить проекты, примеры или игры если хочешь это подтвердить, не хочу тратиь на это время. Тобишь отдельные части системы связанны между собой, легко изменяемы и прочее. Если мы берём в пример игру, то при использовании стандартных методов проектирования её системы растут и вверх (наследование) и в стороны. части программы должны как-то общаться и часто сложным образом взаимодействовать между собой. Из за этого части модули очень крепко подогнаны под вероятный функционал других модулей, из за чего добавление нового функционала становится всё сложнее и сложнее, а баги скрывающиеся в этой паутине могут быть очень заковыристыми. ЕСЦ просто растаскивает данные и логику по разным углам, поэтому системам не требуется доступ к другим системам, потому что они ничего не хранят ВООБЩЕ (ну разве что может какие-нибудь внутренние служебные переменные исчезающие при проходе системы). Из за этого связность очень сильно уменьшается, приложение растёт теперь только по горизонтали, любой модуль можно спокойно вытащить и переписать не боясь что он что-то сломает (если конечно ты сам не напортачил, потому что шанс обосраться тебе дан всегда.)
Читани тут
https://github.com/adnzzzzZ/blog/issues/24
Связности меньше. У тебя есть данные, разные виды которых ты можешь свободно удалять и добавлять. Есть системы, которые друг с другом не пересекаются по сути и не лезут в функционал друг друга. Опять же не связные.
В большинстве приложений (особенно сделаными дилетантами) связанная архитектура можешь сам нагуглить проекты, примеры или игры если хочешь это подтвердить, не хочу тратиь на это время. Тобишь отдельные части системы связанны между собой, легко изменяемы и прочее. Если мы берём в пример игру, то при использовании стандартных методов проектирования её системы растут и вверх (наследование) и в стороны. части программы должны как-то общаться и часто сложным образом взаимодействовать между собой. Из за этого части модули очень крепко подогнаны под вероятный функционал других модулей, из за чего добавление нового функционала становится всё сложнее и сложнее, а баги скрывающиеся в этой паутине могут быть очень заковыристыми. ЕСЦ просто растаскивает данные и логику по разным углам, поэтому системам не требуется доступ к другим системам, потому что они ничего не хранят ВООБЩЕ (ну разве что может какие-нибудь внутренние служебные переменные исчезающие при проходе системы). Из за этого связность очень сильно уменьшается, приложение растёт теперь только по горизонтали, любой модуль можно спокойно вытащить и переписать не боясь что он что-то сломает (если конечно ты сам не напортачил, потому что шанс обосраться тебе дан всегда.)
Читани тут
https://github.com/adnzzzzZ/blog/issues/24
>>649600
Какое у тебя конечно ебанутое описание, анон)
Какое у тебя конечно ебанутое описание, анон)
>>649586
Поиграй в caves of qud, хороший пример рогалика, построенного на ecs.
В ней все предметы, артефакты состоят из компонентов.
Например, есть броня, к которой подключен компонент контейнера для жидкости - и в ней можно хранить воду, сюжетно это объясняется тем, что в неё встроены меха для хранения воды. Если подключить компонент питания от батарейки - броне потребуется заряд, нужно вставить в неё батарейку, чтобы работала, и т.д.
С ООП подходом ты быстро и элегантно это не решишь, т.к. множественного наследования нет в большинстве языков, а там где есть - это костыль и антипаттерн, тебе придется городить костыли и обрабатывать этот случай в особом порядке. А с ecs все просто, у тебя есть базовая сущность, ты накидываешь на неё набор компонентов - компонент брони, контейнеры, питания - и ты можешь надевать этот предмет, хранить в нем воду, питать от батарейки.
>>649495
Начни с того, что выкинь питухон и возьми нормальный язык с готовыми многопоточными реализациями ecs, например rust + specs/legion.
Поиграй в caves of qud, хороший пример рогалика, построенного на ecs.
В ней все предметы, артефакты состоят из компонентов.
Например, есть броня, к которой подключен компонент контейнера для жидкости - и в ней можно хранить воду, сюжетно это объясняется тем, что в неё встроены меха для хранения воды. Если подключить компонент питания от батарейки - броне потребуется заряд, нужно вставить в неё батарейку, чтобы работала, и т.д.
С ООП подходом ты быстро и элегантно это не решишь, т.к. множественного наследования нет в большинстве языков, а там где есть - это костыль и антипаттерн, тебе придется городить костыли и обрабатывать этот случай в особом порядке. А с ecs все просто, у тебя есть базовая сущность, ты накидываешь на неё набор компонентов - компонент брони, контейнеры, питания - и ты можешь надевать этот предмет, хранить в нем воду, питать от батарейки.
>>649495
Начни с того, что выкинь питухон и возьми нормальный язык с готовыми многопоточными реализациями ecs, например rust + specs/legion.
>>649616
Ну наконец-то нормальные советы подъехали, как же я без этого жил-то. Теперь точно перейду на нормальный язык, либы подключу нормальные, рогалик напишу многопоточный, с ECS у меня наконец будет.
Серьезно, давай без языкосрача. Я пишу рогалик потому что меня конкретные вопросы волнуют; я их решаю и учусь на этом. Вопрос выбора языка в этих вопроса не присутствует.
>>649562
Скоро отпишусь по теме
Ну наконец-то нормальные советы подъехали, как же я без этого жил-то. Теперь точно перейду на нормальный язык, либы подключу нормальные, рогалик напишу многопоточный, с ECS у меня наконец будет.
Серьезно, давай без языкосрача. Я пишу рогалик потому что меня конкретные вопросы волнуют; я их решаю и учусь на этом. Вопрос выбора языка в этих вопроса не присутствует.
>>649562
Скоро отпишусь по теме
5,2 Мб, 945x565В общем, про ECS:
Я прочел все материалы, на которые были даны ссылки, (пост на хабре - отличный), пообщался со знакомым, занятыми в геймдеве, посмотрел немного канала roguelike celebration (особенно роскошный видос Bob Nystrom - Is There More to Game Architecture than ECS?, откуда я тиснул функцию move для своего рогаля) - и в общем, кажется, я понял. ECS штука совершенно роскошная, если ты пишешь что-то типа dwarf fortress или caves of cud, где тебе нужно, допустим, чтобы сундук и предметы хранил и диалоги мог разговаривать. Применение данного подхода требует определенного анти-логического мышления - очень непривычно, что все объекты, с которыми ты в коде работаешь (ну, или максимальное их количество - смотря как напишешь ECS) это просто обертка, в которую может быть насовано все что угодно, любые методы, которые на самом деле еще и объекты.
Если ты делаешь свой маленький pixel dungeon, можно и без этого, на ООП выезжать.
Спасибо всем за исчерпывающие ответы. Скорее всего попробую на нем что-нибудь написать с нуля, попозже. А этот догоню до какого-нибудь логического конца.
That being said, я заделал-таки компонент про спрайты, и теперь pygame у меня вертит этот компонент, рисуя таким образом графоний в окне.
Другие новости (как будто кому-то интересно) - я пытался прокачать свой расчет Line of sight по блогу того же Нюстрома - там есть отличная статья https://journal.stuffwithstuff.com/2015/09/07/what-the-hero-sees/, но я вкуриваю тупо и медленно, поэтому пока без теней - реализовал расчет октантов и накостылил гибрид рейкастинга и кастинга октантов. Гифку прилагаю.
Ах да, двойной вывод, лол.
Всем добра
Я прочел все материалы, на которые были даны ссылки, (пост на хабре - отличный), пообщался со знакомым, занятыми в геймдеве, посмотрел немного канала roguelike celebration (особенно роскошный видос Bob Nystrom - Is There More to Game Architecture than ECS?, откуда я тиснул функцию move для своего рогаля) - и в общем, кажется, я понял. ECS штука совершенно роскошная, если ты пишешь что-то типа dwarf fortress или caves of cud, где тебе нужно, допустим, чтобы сундук и предметы хранил и диалоги мог разговаривать. Применение данного подхода требует определенного анти-логического мышления - очень непривычно, что все объекты, с которыми ты в коде работаешь (ну, или максимальное их количество - смотря как напишешь ECS) это просто обертка, в которую может быть насовано все что угодно, любые методы, которые на самом деле еще и объекты.
Если ты делаешь свой маленький pixel dungeon, можно и без этого, на ООП выезжать.
Спасибо всем за исчерпывающие ответы. Скорее всего попробую на нем что-нибудь написать с нуля, попозже. А этот догоню до какого-нибудь логического конца.
That being said, я заделал-таки компонент про спрайты, и теперь pygame у меня вертит этот компонент, рисуя таким образом графоний в окне.
Другие новости (как будто кому-то интересно) - я пытался прокачать свой расчет Line of sight по блогу того же Нюстрома - там есть отличная статья https://journal.stuffwithstuff.com/2015/09/07/what-the-hero-sees/, но я вкуриваю тупо и медленно, поэтому пока без теней - реализовал расчет октантов и накостылил гибрид рейкастинга и кастинга октантов. Гифку прилагаю.
Ах да, двойной вывод, лол.
Всем добра
>>650122
Это значит что ты его нихуя не понял. Как раз копоненты и есть более естественный метод для программирования не только игр вышесказанных, но и вообще любых симуляций (читай игр) где у тебя есть много одинаковых объектов или большое количество пересекающихся аспектов программы (это важная черта игр.)
>Применение данного подхода требует определенного анти-логического мышления - очень непривычно, что все объекты, с которыми ты в коде работаешь (ну, или максимальное их количество - смотря как напишешь ECS) это просто обертка, в которую может быть насовано все что угодно, любые методы, которые на самом деле еще и объекты.
Это значит что ты его нихуя не понял. Как раз копоненты и есть более естественный метод для программирования не только игр вышесказанных, но и вообще любых симуляций (читай игр) где у тебя есть много одинаковых объектов или большое количество пересекающихся аспектов программы (это важная черта игр.)
>>649632
Второй год удивляюсь, как народ трепещет перед ЕЦС, будто это какая-то невъебенно сложная технология. ЕЦС состоит из 2х частей:
1. Никакого наследования, только композиция.
2. Глобальные переменные достаём из файлов с данными.
Вот и весь ЕЦС.
> ECS реализации
Второй год удивляюсь, как народ трепещет перед ЕЦС, будто это какая-то невъебенно сложная технология. ЕЦС состоит из 2х частей:
1. Никакого наследования, только композиция.
2. Глобальные переменные достаём из файлов с данными.
Вот и весь ЕЦС.
>>650136
Потому что когда дело доходит до реализации всплывает немало проблем связанных с тем что технология требует использовать другую парадигму построения программы, не ООП к котому все привыкли а компонентно ориентированную. Также есть много проблем связанных с тем как реализовать саму ECS, ведь там есть сотни разных подходов так скажем.
Потому что когда дело доходит до реализации всплывает немало проблем связанных с тем что технология требует использовать другую парадигму построения программы, не ООП к котому все привыкли а компонентно ориентированную. Также есть много проблем связанных с тем как реализовать саму ECS, ведь там есть сотни разных подходов так скажем.
>>650136
У кукаретиков всё просто, а ты попробуй написать нормальный производительный рантайм для ецс, жидко обмякнешь.
Specs например строит граф зависимостей систем, смотрит какие системы какие компоненты используют, и на основе этого параллелит выполнение по ядрам процессора, чтобы ты мог не Х сущностей обработать за такт, а число ядер * X.
Legion ecs позволяет делать sql-подобные запросы, чтобы отбирать сущности для обработки, типа, выбрать сущности, у которых есть компонент Х, нет компонента У, а параметр Z компонента W больше или равен какой-то величине, при этом работает это очень быстро.
>Вот и весь ЕЦС.
У кукаретиков всё просто, а ты попробуй написать нормальный производительный рантайм для ецс, жидко обмякнешь.
Specs например строит граф зависимостей систем, смотрит какие системы какие компоненты используют, и на основе этого параллелит выполнение по ядрам процессора, чтобы ты мог не Х сущностей обработать за такт, а число ядер * X.
Legion ecs позволяет делать sql-подобные запросы, чтобы отбирать сущности для обработки, типа, выбрать сущности, у которых есть компонент Х, нет компонента У, а параметр Z компонента W больше или равен какой-то величине, при этом работает это очень быстро.
>>650152
Подтверждаю.
Подходов для даже простого решения как реализовать хранение компонентов и каком виде немало. При том что каждый из них даёт свои бенефиты но и ограничивает.
>>650122
А тебе скажу - выброси нахуй ЕСЦ если пользоваться им не умеешь. Нельзя просто части игры перевести нп использование комопнетов, ты только больше усложнишь код и сделаешь такую хуйню в которой сам увязнешь.
Подтверждаю.
Подходов для даже простого решения как реализовать хранение компонентов и каком виде немало. При том что каждый из них даёт свои бенефиты но и ограничивает.
>>650122
А тебе скажу - выброси нахуй ЕСЦ если пользоваться им не умеешь. Нельзя просто части игры перевести нп использование комопнетов, ты только больше усложнишь код и сделаешь такую хуйню в которой сам увязнешь.
>>650152
зачем его должен строить фреймворк, если лучше его явно создать пользователю. в юнити такая-же ерунда. неявное указывание зависимостей размазанное по системам только усложняет программирование. намного проще в одном месте явно создать граф объектов, где какие-то выполняются одновременно, какие-то по очереди.
алсо, ты не понимаешь сути рогалика. там событийная архитектура. там нет смысла в чистом ECS. компоненты - это по сути просто обработчики событий.
>Specs например строит граф зависимостей систем
зачем его должен строить фреймворк, если лучше его явно создать пользователю. в юнити такая-же ерунда. неявное указывание зависимостей размазанное по системам только усложняет программирование. намного проще в одном месте явно создать граф объектов, где какие-то выполняются одновременно, какие-то по очереди.
алсо, ты не понимаешь сути рогалика. там событийная архитектура. там нет смысла в чистом ECS. компоненты - это по сути просто обработчики событий.
>>650286
У него все нипанимают, один он ПОНИМАЕТ.
Ни одного рогалика, тем более на ecs, он естественно, не сделал. Он просто ПОНИМАЕТ.
У него все нипанимают, один он ПОНИМАЕТ.
Ни одного рогалика, тем более на ecs, он естественно, не сделал. Он просто ПОНИМАЕТ.
>>650122
А вот если бы ты прочитал книгу банды четырех про паттерны, то внезапно бы обнаружил что данная задача (а именно конструирование объекта из компонент (не путай с ecs)) давно уже решена в классическом ООП множеством способов
(подозреваю что многие "фанаты" ECS просто ничего не читали по ООП, вот им и кажется что это идеальное решение.
То что сейчас все писаются радугой при любом упоминании ECS - потому что такова природа программистов - все хотят быть не как все. Мода пройдет, и ECS станет антипаттерном за который через пять лет будут бить по рукам топором.
А всё потому что у ECS есть куча недостатков:
- плодит сущности, что сильно усложняет код и ведет к спагетти-коду. Читать такой код невозможно. В реальном мире, в мире программистов и в мире ООП - сундук, это сундук. В ECS - нет никакого сундука. Есть цифровой идентификатор под номером таким-то, есть стопятсот компонент и есть стопятсот систем под каждый компонент.
- совершенно не приспособлено для отладки - так как часто невозможно идентифицировать логические связи.
- кроме того по факту почти невозможно выделить компоненты независимыми друг от друга - рендердрав никак не сможет без трансформа и т.д. из-за чего ECS все равно превращается в обычное ООП с костылями чтобы сохранять видимость ECS (аля юнити)
Короче, у ECS нет будущего.
>ECS штука совершенно роскошная, если ты пишешь что-то типа dwarf fortress или caves of cud, где тебе нужно, допустим, чтобы сундук и предметы хранил и диалоги мог разговаривать
А вот если бы ты прочитал книгу банды четырех про паттерны, то внезапно бы обнаружил что данная задача (а именно конструирование объекта из компонент (не путай с ecs)) давно уже решена в классическом ООП множеством способов
(подозреваю что многие "фанаты" ECS просто ничего не читали по ООП, вот им и кажется что это идеальное решение.
То что сейчас все писаются радугой при любом упоминании ECS - потому что такова природа программистов - все хотят быть не как все. Мода пройдет, и ECS станет антипаттерном за который через пять лет будут бить по рукам топором.
А всё потому что у ECS есть куча недостатков:
- плодит сущности, что сильно усложняет код и ведет к спагетти-коду. Читать такой код невозможно. В реальном мире, в мире программистов и в мире ООП - сундук, это сундук. В ECS - нет никакого сундука. Есть цифровой идентификатор под номером таким-то, есть стопятсот компонент и есть стопятсот систем под каждый компонент.
- совершенно не приспособлено для отладки - так как часто невозможно идентифицировать логические связи.
- кроме того по факту почти невозможно выделить компоненты независимыми друг от друга - рендердрав никак не сможет без трансформа и т.д. из-за чего ECS все равно превращается в обычное ООП с костылями чтобы сохранять видимость ECS (аля юнити)
Короче, у ECS нет будущего.
>>650130
нет. ECS реально требует другого мышления. А то что ты описал - это обычная агрегация из ООП (то есть возможность выделять разные черты в разные классы - это не компоненты из ECS)
>Как раз копоненты и есть более естественный метод для программирования не только игр вышесказанных, но и вообще любых симуляций (читай игр) где у тебя есть много одинаковых объектов или большое количество пересекающихся аспектов программы (это важная черта игр.)
нет. ECS реально требует другого мышления. А то что ты описал - это обычная агрегация из ООП (то есть возможность выделять разные черты в разные классы - это не компоненты из ECS)
>>650289
давно уже решена в классическом ООП множеством способов
Ну так покажи мне пожалуйста хоть один удобоваримый способ, чтобы это не проёбывало масштабируемость и не срало на раскладку данных в памяти пожалуйста.
давно уже решена в классическом ООП множеством способов
Ну так покажи мне пожалуйста хоть один удобоваримый способ, чтобы это не проёбывало масштабируемость и не срало на раскладку данных в памяти пожалуйста.
>>650290
Подумал немного, с этим согласен что агрегация/композиция тут будет более "естественна", но при правильном подходе ECS может очень гибко жонглировать свойствами объектов даже прямо в runtime.
Подумал немного, с этим согласен что агрегация/композиция тут будет более "естественна", но при правильном подходе ECS может очень гибко жонглировать свойствами объектов даже прямо в runtime.
263 Кб, 604x604>>650289
Вопрос организации кода. Если на ум ничего больше не приходит как нахуярить сотни компонентов, то это проблемы твои а не концепции.
опять же глупость полнейшая, написать профилировщик или отладчик который будет выводить информацию по иерархии систем или создавать слепки с ентити, распределяя их по типам (опять же это всё вопросы реализации)
Кто вообще сказал что их нужно разделять и делать независимыми?
В общем вся твоя писанина выглядит так что ты намеренно не пытаешься копать глубже а твоя задача обосрать ECS по дефолту, намернно подибраешь самые глупые из возможных решений в ECS реализациях чтобы выставить его говном a priori, а не понять что действительно лучше. Если будешь продолжать в том же духе, то уёбывай дядя.
>есть стопятсот компонент и есть стопятсот систем под каждый компонент.
Вопрос организации кода. Если на ум ничего больше не приходит как нахуярить сотни компонентов, то это проблемы твои а не концепции.
>совершенно не приспособлено для отладки - так как часто невозможно идентифицировать логические связи.
опять же глупость полнейшая, написать профилировщик или отладчик который будет выводить информацию по иерархии систем или создавать слепки с ентити, распределяя их по типам (опять же это всё вопросы реализации)
>кроме того по факту почти невозможно выделить компоненты независимыми друг от друга
Кто вообще сказал что их нужно разделять и делать независимыми?
В общем вся твоя писанина выглядит так что ты намеренно не пытаешься копать глубже а твоя задача обосрать ECS по дефолту, намернно подибраешь самые глупые из возможных решений в ECS реализациях чтобы выставить его говном a priori, а не понять что действительно лучше. Если будешь продолжать в том же духе, то уёбывай дядя.
>>650291
решений много. Даже банально:
class Entity{
array<Component> c;
};
(то есть избавляемся от систем, и храним компоненты в самом Entity - это ООП, а не ECS)
А так, фасад, билдер, фабрики и т.д.
На геймдеве еще был пример асспекто-ориентированного подхода.
>>650291
а ты уверен что тебе в твоем рогалике это нужно? кеш-фредли вообще-то для консолей старого поколения делали, у которых процы как говно. Для пк это уровень "буду писать рогалик на ассемблере".
ААА игры на классической нодсцене ни у кого не тормозили даже 20 лет назад, а твой рогалик вот не сможет работать?
>Ну так покажи мне пожалуйста хоть один удобоваримый способ, чтобы это не проёбывало масштабируемость
решений много. Даже банально:
class Entity{
array<Component> c;
};
(то есть избавляемся от систем, и храним компоненты в самом Entity - это ООП, а не ECS)
А так, фасад, билдер, фабрики и т.д.
На геймдеве еще был пример асспекто-ориентированного подхода.
>>650291
>и не срало на раскладку данных в памяти пожалуйста.
а ты уверен что тебе в твоем рогалике это нужно? кеш-фредли вообще-то для консолей старого поколения делали, у которых процы как говно. Для пк это уровень "буду писать рогалик на ассемблере".
ААА игры на классической нодсцене ни у кого не тормозили даже 20 лет назад, а твой рогалик вот не сможет работать?
>>650294
если ты весь функционал фигачишь в один компонент - то ты нарушаешь концепцию ECS
В ECS ты должен выделять наибольшее количество компонентов. И конечно под каждое из них будет своя система. В тех же презентациях рогаликов показывали на экране сотни компонент.
>>650294
сама философия ECS.
Короче, всегда ржал с людей которые защищают ECS, но при этом совершенно неправильно его понимают.
>Вопрос организации кода. Если на ум ничего больше не приходит как нахуярить сотни компонентов, то это проблемы твои а не концепции.
если ты весь функционал фигачишь в один компонент - то ты нарушаешь концепцию ECS
В ECS ты должен выделять наибольшее количество компонентов. И конечно под каждое из них будет своя система. В тех же презентациях рогаликов показывали на экране сотни компонент.
>>650294
>Кто вообще сказал что их нужно разделять и делать независимыми?
сама философия ECS.
Короче, всегда ржал с людей которые защищают ECS, но при этом совершенно неправильно его понимают.
>>650321
>>650322
Вопрос реализации.
Запас производительности всегда можно куда-нибудь потратить.
Построй на основе компонентов систему тэгов и подключай системы по соотвествию тэгов. Вот ты по сути один тип компонентов переиспользовал. Вариаций масса, но да, в основном их много. Но не то чтобы это проблема, просто нужно делать это без фанатизма. Разделяй и властвуй.
Философия ECS говорит делать данные от систем независимыми. А отношениря между саими данными регламентируются не так прочно и являются предметом споров.
Ты блять пропогандист своего мнения просто, и этот >>650288 среньк про тебя скорее.
В общем отвечу если что когда что-нибудь годное по-настоящему выскажешь.
>>650322
>решений много.
Вопрос реализации.
>а твой рогалик вот не сможет работать
Запас производительности всегда можно куда-нибудь потратить.
>В ECS ты должен выделять наибольшее количество компонентов.
>если ты весь функционал фигачишь в один компонент - то ты нарушаешь концепцию ECS.
Построй на основе компонентов систему тэгов и подключай системы по соотвествию тэгов. Вот ты по сути один тип компонентов переиспользовал. Вариаций масса, но да, в основном их много. Но не то чтобы это проблема, просто нужно делать это без фанатизма. Разделяй и властвуй.
>сама философия ECS.
Философия ECS говорит делать данные от систем независимыми. А отношениря между саими данными регламентируются не так прочно и являются предметом споров.
>но при этом совершенно неправильно его понимают.
Ты блять пропогандист своего мнения просто, и этот >>650288 среньк про тебя скорее.
В общем отвечу если что когда что-нибудь годное по-настоящему выскажешь.
>>650326
ну вот например я сейчас ковыряюсь с паттерном property container - оно делает то что нужно - возможность добавлять новые свойства классу без всяких там наследований и т.д.
>>650326
не факт что этот запас будет, да, компоненты кеш-фредли, но вот оно будет жрать больше памяти (потому что компоненты надо выделять один раз с запасом в огромном куске памяти, иначе не будет этого кеш-фредли).
Да и там возможно такие мизерные запасы
>Вопрос реализации.
ну вот например я сейчас ковыряюсь с паттерном property container - оно делает то что нужно - возможность добавлять новые свойства классу без всяких там наследований и т.д.
>>650326
>Запас производительности всегда можно куда-нибудь потратить.
не факт что этот запас будет, да, компоненты кеш-фредли, но вот оно будет жрать больше памяти (потому что компоненты надо выделять один раз с запасом в огромном куске памяти, иначе не будет этого кеш-фредли).
Да и там возможно такие мизерные запасы
>>650327
Интересная штука. Насколько абстрактно она реализуется?
ну в основном это относится к менеджменту памяти. Обычно компоненты всегда лежат одинаковыми блоками. Конечно постоянное удаление-добавление фрагментирует память, но вполне можно сохранять свободные индексы или дефрагментировать в потоке это всё дело. Наблюдай за тем как legion ECS справляется с этой задачей, я его как раз ковыряю сейчас.
>ну вот например я сейчас ковыряюсь с паттерном property container
Интересная штука. Насколько абстрактно она реализуется?
>потому что компоненты надо выделять один раз с запасом в огромном куске памяти, иначе не будет этого кеш-фредли
ну в основном это относится к менеджменту памяти. Обычно компоненты всегда лежат одинаковыми блоками. Конечно постоянное удаление-добавление фрагментирует память, но вполне можно сохранять свободные индексы или дефрагментировать в потоке это всё дело. Наблюдай за тем как legion ECS справляется с этой задачей, я его как раз ковыряю сейчас.
>>650327
Кстати о legion ECS
Specs specifically utilizes sparse component storage. That means whenever you are joining 2 or more components, you are jumping between 2 arbitrary locations in memory repeatedly, for every single entity. This is very hard on CPU caching, as you are repeatedly loading and processing N completely separate regions of memory.
Legion allocations like-entities in contiguous memory, and iterates based on allocated "chunks" for iteration. This means that whenever performing a query against N-components, the memory is almost always guaranteed to be local and adjacent because its archetype is the same for that query.
Кстати о legion ECS
Specs specifically utilizes sparse component storage. That means whenever you are joining 2 or more components, you are jumping between 2 arbitrary locations in memory repeatedly, for every single entity. This is very hard on CPU caching, as you are repeatedly loading and processing N completely separate regions of memory.
Legion allocations like-entities in contiguous memory, and iterates based on allocated "chunks" for iteration. This means that whenever performing a query against N-components, the memory is almost always guaranteed to be local and adjacent because its archetype is the same for that query.
>>650286
напоминаю что речь о рогаликах.
что ты там в системах собрался обновлять каждый кадр? что ты собрался распараллеливать, когда результат каждого хода и каждого события строго зависит от предыдущего?
напоминаю что речь о рогаликах.
что ты там в системах собрался обновлять каждый кадр? что ты собрался распараллеливать, когда результат каждого хода и каждого события строго зависит от предыдущего?
>>650426
Если брать такие рогалики как ADOM, Nethack и суп, то да, это будет совершенно излишним, потому что в них мир существует только в рамках замкнутого данжона.
Но возьми что-то наподобие Cataclysm DDA (с его открытым миром) или Dwarf fortress (с его глобальной симуляцией) то тут уже можно будет пойти другим путём - сделать "ленивые вычисления" глобального окружения опенворлда, ну это как пример.
Далее насчёт распаралеливания. Технически можно не создавать квантированные ходы, а сделать допустим 100 милисекунд. Игра будет "как-бы" технически рилтайм, но на деле игра будет ждать действия игрока, выполнять его (пойти в клетку, атаковать) а потом опять застывать и ждать.
Любые выполняемые действия в игровом мире имеют точку старта и точку завершения, ничего не происходит мгновенно и любое действие прерывается при определённых обстоятельствах (потеря равновесия или отмена действия самим игроком, если он конечно успеет.)
Если брать такие рогалики как ADOM, Nethack и суп, то да, это будет совершенно излишним, потому что в них мир существует только в рамках замкнутого данжона.
Но возьми что-то наподобие Cataclysm DDA (с его открытым миром) или Dwarf fortress (с его глобальной симуляцией) то тут уже можно будет пойти другим путём - сделать "ленивые вычисления" глобального окружения опенворлда, ну это как пример.
Далее насчёт распаралеливания. Технически можно не создавать квантированные ходы, а сделать допустим 100 милисекунд. Игра будет "как-бы" технически рилтайм, но на деле игра будет ждать действия игрока, выполнять его (пойти в клетку, атаковать) а потом опять застывать и ждать.
Любые выполняемые действия в игровом мире имеют точку старта и точку завершения, ничего не происходит мгновенно и любое действие прерывается при определённых обстоятельствах (потеря равновесия или отмена действия самим игроком, если он конечно успеет.)
>>649142
>>649175
Что в этом сложного? Я в своём движке называю это "библиотекой ресурсов". Общий принцип таков: все ресурсы загружаются через библиотеку, а библиотека сама решает, когда нужно загрузить файл с диска, а когда достаточно отдать ссылку в памяти на уже загруженный ресурс.
Интерфейс:
Library["путь\к\ресурсу"];
Использование, к примеру, загрузка картинки:
Texture := Library["..\Data\Textures\Monster.png"];
Что делает библиотека (лень копипастить код, импровизирую):
function TResourceLibrary.GetResource(const Path: string): TGameResource;
var Resource: TGameResource;
begin
Result := nil;
for Resource in FResources do // ищем среди уже загруженных
if Resource.Path = Path then // нашли загруженный ресурс, отдаём его
Result := Resource;
if Result = nil then // никогда раньше такого не загружали
begin
FResources += TGameResource.Create(Path); // загружаем, сохраняем
Result := FResources[High(FResources)]; // отдаём загруженное
end;
end;
Если потребуется две копии в памяти (чтоб редактировать, например), то можно так:
Texture := Library.Clone("..\Data\Textures\Monster.png", "Clone\Monster-modified.png");
Тогда TResourceLibrary.Clone() сделает копию, сохранит в FResources и вернёт ссылку.
Чтобы получить клон, просто используем его личное имя:
Texture := Library["Clone\Monster-modified.png"];
Вот, собственно, и всё. Абсолютно ничего сложного, и уж намного проще ECS.
>префабы - это отдельная сложная тема
>>649175
>Ты же не будешь для каждого монстра подгружать одну и ту же картинку с диска
Что в этом сложного? Я в своём движке называю это "библиотекой ресурсов". Общий принцип таков: все ресурсы загружаются через библиотеку, а библиотека сама решает, когда нужно загрузить файл с диска, а когда достаточно отдать ссылку в памяти на уже загруженный ресурс.
Интерфейс:
Library["путь\к\ресурсу"];
Использование, к примеру, загрузка картинки:
Texture := Library["..\Data\Textures\Monster.png"];
Что делает библиотека (лень копипастить код, импровизирую):
function TResourceLibrary.GetResource(const Path: string): TGameResource;
var Resource: TGameResource;
begin
Result := nil;
for Resource in FResources do // ищем среди уже загруженных
if Resource.Path = Path then // нашли загруженный ресурс, отдаём его
Result := Resource;
if Result = nil then // никогда раньше такого не загружали
begin
FResources += TGameResource.Create(Path); // загружаем, сохраняем
Result := FResources[High(FResources)]; // отдаём загруженное
end;
end;
Если потребуется две копии в памяти (чтоб редактировать, например), то можно так:
Texture := Library.Clone("..\Data\Textures\Monster.png", "Clone\Monster-modified.png");
Тогда TResourceLibrary.Clone() сделает копию, сохранит в FResources и вернёт ссылку.
Чтобы получить клон, просто используем его личное имя:
Texture := Library["Clone\Monster-modified.png"];
Вот, собственно, и всё. Абсолютно ничего сложного, и уж намного проще ECS.
>>649142
>>649175
Что в этом сложного? Я в своём движке называю это "библиотекой ресурсов". Общий принцип таков: все ресурсы загружаются через библиотеку, а библиотека сама решает, когда нужно загрузить файл с диска, а когда достаточно отдать ссылку в памяти на уже загруженный ресурс.
Интерфейс:
Library["путь\к\ресурсу"];
Использование, к примеру, загрузка картинки:
Texture := Library["..\Data\Textures\Monster.png"];
Что делает библиотека (лень копипастить код, импровизирую):
function TResourceLibrary.GetResource(const Path: string): TGameResource;
var Resource: TGameResource;
begin
Result := nil;
for Resource in FResources do // ищем среди уже загруженных
if Resource.Path = Path then // нашли загруженный ресурс, отдаём его
Result := Resource;
if Result = nil then // никогда раньше такого не загружали
begin
FResources += TGameResource.Create(Path); // загружаем, сохраняем
Result := FResources[High(FResources)]; // отдаём загруженное
end;
end;
Если потребуется две копии в памяти (чтоб редактировать, например), то можно так:
Texture := Library.Clone("..\Data\Textures\Monster.png", "Clone\Monster-modified.png");
Тогда TResourceLibrary.Clone() сделает копию, сохранит в FResources и вернёт ссылку.
Чтобы получить клон, просто используем его личное имя:
Texture := Library["Clone\Monster-modified.png"];
Вот, собственно, и всё. Абсолютно ничего сложного, и уж намного проще ECS.
>префабы - это отдельная сложная тема
>>649175
>Ты же не будешь для каждого монстра подгружать одну и ту же картинку с диска
Что в этом сложного? Я в своём движке называю это "библиотекой ресурсов". Общий принцип таков: все ресурсы загружаются через библиотеку, а библиотека сама решает, когда нужно загрузить файл с диска, а когда достаточно отдать ссылку в памяти на уже загруженный ресурс.
Интерфейс:
Library["путь\к\ресурсу"];
Использование, к примеру, загрузка картинки:
Texture := Library["..\Data\Textures\Monster.png"];
Что делает библиотека (лень копипастить код, импровизирую):
function TResourceLibrary.GetResource(const Path: string): TGameResource;
var Resource: TGameResource;
begin
Result := nil;
for Resource in FResources do // ищем среди уже загруженных
if Resource.Path = Path then // нашли загруженный ресурс, отдаём его
Result := Resource;
if Result = nil then // никогда раньше такого не загружали
begin
FResources += TGameResource.Create(Path); // загружаем, сохраняем
Result := FResources[High(FResources)]; // отдаём загруженное
end;
end;
Если потребуется две копии в памяти (чтоб редактировать, например), то можно так:
Texture := Library.Clone("..\Data\Textures\Monster.png", "Clone\Monster-modified.png");
Тогда TResourceLibrary.Clone() сделает копию, сохранит в FResources и вернёт ссылку.
Чтобы получить клон, просто используем его личное имя:
Texture := Library["Clone\Monster-modified.png"];
Вот, собственно, и всё. Абсолютно ничего сложного, и уж намного проще ECS.
>>652121
У меня то же самое, только назвал другим словом.
К ECS оно ортогонально, можно эту идею и без ECS использовать, но вместе веселее.
Брат братан братишка
> Общий принцип таков: все ресурсы загружаются через библиотеку, а библиотека сама решает, когда нужно загрузить файл с диска, а когда достаточно отдать ссылку в памяти на уже загруженный ресурс.
У меня то же самое, только назвал другим словом.
> Абсолютно ничего сложного, и уж намного проще ECS.
К ECS оно ортогонально, можно эту идею и без ECS использовать, но вместе веселее.
> Pascal
Брат братан братишка
2,9 Мб, 1098x637На правах бампа - пишу о прогрессе рогалика на питоне.
Долго пинал балду, почему-то не хотелось ничего делать (плюс fallout sonora сожрала неделю, не жалею ни о чем). Но как только открыл код, меня сразу понесло.
Много чего переписал, побаловался с форматом dictionary (все объекты на карте до этого хранил в listах), переписал немного работу со спрайтами pygame - все стало работать пошустрей. Вообще понял, что для меня лучше всего работает подход "реализовать через жопу - отрефакторить."
До сих пор не пофиксил line of sight/field of view. Сломал голову об ECS, в итоге забил, так как понял, что или я в эту тему буду въезжать целую вечность, либо доделаю игру до играбельного состояния. В итоге yolo-кодинг победил.
Из сделанного - монстры убиваются корректно, сделал предметы, которые поднимаются-дропаются, сделал зайчаток инвентаря, сделал открывание закрытых дверей.
Также сделал вывод в консольку черезжопным интересным образом - у каждого creature в игре, включая player-а, есть свой лог, который по сути простой list. Действия аппендятся в этот лист (естественно, если элементов в нем больше 10, то первый удаляется к херам, а новый записывается в конец). И в main-е мы просто дергаем последнюю строку лога playera и выводим ее на экран.
Пока простой концепт рогалика полагаю такой - есть какое-то количество этажей, выход с каждого этажа закрыт, ищем ключ, открываем дверь - ломимся на следующий этаж. На последнем валим жирного монстра - конец игры. Все остальное опционально и в рамках отработки навыков.
Долго пинал балду, почему-то не хотелось ничего делать (плюс fallout sonora сожрала неделю, не жалею ни о чем). Но как только открыл код, меня сразу понесло.
Много чего переписал, побаловался с форматом dictionary (все объекты на карте до этого хранил в listах), переписал немного работу со спрайтами pygame - все стало работать пошустрей. Вообще понял, что для меня лучше всего работает подход "реализовать через жопу - отрефакторить."
До сих пор не пофиксил line of sight/field of view. Сломал голову об ECS, в итоге забил, так как понял, что или я в эту тему буду въезжать целую вечность, либо доделаю игру до играбельного состояния. В итоге yolo-кодинг победил.
Из сделанного - монстры убиваются корректно, сделал предметы, которые поднимаются-дропаются, сделал зайчаток инвентаря, сделал открывание закрытых дверей.
Также сделал вывод в консольку черезжопным интересным образом - у каждого creature в игре, включая player-а, есть свой лог, который по сути простой list. Действия аппендятся в этот лист (естественно, если элементов в нем больше 10, то первый удаляется к херам, а новый записывается в конец). И в main-е мы просто дергаем последнюю строку лога playera и выводим ее на экран.
Пока простой концепт рогалика полагаю такой - есть какое-то количество этажей, выход с каждого этажа закрыт, ищем ключ, открываем дверь - ломимся на следующий этаж. На последнем валим жирного монстра - конец игры. Все остальное опционально и в рамках отработки навыков.
>>655766
На первые проекты такую хуйню довольно тяжело применить, нужно скажем так испытать момент когда сложность кода будет превышать порог относительно лёгкого внедрения фичи. Тогда мозг сам захочет пощупать разные методы организации кода, если он конечно достаточно развит.
Хотя я всё еще не могу понять что могло в ECS тебе быть не понятым. Я в него въехал буквально сразу.
> Сломал голову об ECS, в итоге забил
На первые проекты такую хуйню довольно тяжело применить, нужно скажем так испытать момент когда сложность кода будет превышать порог относительно лёгкого внедрения фичи. Тогда мозг сам захочет пощупать разные методы организации кода, если он конечно достаточно развит.
Хотя я всё еще не могу понять что могло в ECS тебе быть не понятым. Я в него въехал буквально сразу.
15,5 Мб, 1061x744>>655807
Как концепт - понятен. Как его накостылить - не вполне понятно.
Я пытался почитать код пары доступных ecs-систем питонячьих, но там уровень абстракции сразу максимальный, а я птичка, мне такое сложно.
Например, тема с системами не ясна.
Есть у тебя entity player. Ты создаешь объект move - и чего с ним делать-то? Как должен быть сделан этот объект move, чтобы у тебя компонент coordinates в player-е поменялся? Какая система и как его должна подхватить, что с ним сделать?
(алсо, добавил дропы, инвентари мобам, id-шники предметам чтобы спрайты было легче рендерить, тред живи)
Как концепт - понятен. Как его накостылить - не вполне понятно.
Я пытался почитать код пары доступных ecs-систем питонячьих, но там уровень абстракции сразу максимальный, а я птичка, мне такое сложно.
Например, тема с системами не ясна.
Есть у тебя entity player. Ты создаешь объект move - и чего с ним делать-то? Как должен быть сделан этот объект move, чтобы у тебя компонент coordinates в player-е поменялся? Какая система и как его должна подхватить, что с ним сделать?
(алсо, добавил дропы, инвентари мобам, id-шники предметам чтобы спрайты было легче рендерить, тред живи)
>>656680
А его и не надо накостыливать по сути. На ЕСЦ игру с нуля пишут, внедрять его по ходу - это ебантяйство.
Хуёво конечно. Не представляю как ты до сих пор не понял что такое ЕЦС и как он используется, но про пятон сказать ничего не могу.
У тебя неть entity player. У тебя есть просто базовый entity который просто хранит в себе компоненты, и всё.
Если ты имел ввиду систему, то она должна быть одна на всю игру, и вся логика передвижения для ЛЮБОГО объекта в игре должна производитться в ней.
Я вижу что ты пытаешься сейчас через парадигму ООП решить, в этом вся проблема лютая. ECS вообще другая парадигма. в вещественны объекты, которые являются сокрытыми логикой и данными, то есть инкапулированы в единую сущность программную. В ECS У тебя вещественны только данные. Системы это просто код, функции если хочешь, каждая из которых запускается, получает на вход определённые данные (Напимер coordinates и vector/coord_goal, для того чтобы движение совершить), и их либо меняет, либо выполняет другой код/системы. То есть по сути ни entity, ни системы не знают вообще с чем они работают, игрок это, монстр, стул или стена. Система просто перебирает все vector/coord_goal, и изменяет все coordinates в соответствии с ними.
Ещё раз повторю. в ECS главенствующую роль играют компоненты, то есть данные. Они разделяются на типы, и хранятся допустим в массивах прямо штабелями. Системы просто получают на вход весь массив компонентов и обходят их (это в самой примитивной реаализации). entity тут это просто id всех компонентов. Ни о каких инкапсуляциях и классах тут нет и речи.
Вопрос открытый ещё, ты можешь сделать системы которые будут логически разделены, и просто получать какие-то типы компонентов. Я предполагаю что у тебя у всех игровых обектов в мире будет позиция, и вектор движения, или точка куда они должны на следующий ход/тик двинуться. система move просто подхватывает вектор движения и координаты ентити, обсчитывает как надо и переписывает move.
По хорошему советую забить пока NAHOOI на ECS раз тебе так сложно.
>накостылить
А его и не надо накостыливать по сути. На ЕСЦ игру с нуля пишут, внедрять его по ходу - это ебантяйство.
>ecs-систем питонячьих но там уровень абстракции сразу максимальный, а я птичка,
Хуёво конечно. Не представляю как ты до сих пор не понял что такое ЕЦС и как он используется, но про пятон сказать ничего не могу.
>Есть у тебя entity player.
У тебя неть entity player. У тебя есть просто базовый entity который просто хранит в себе компоненты, и всё.
>Ты создаешь объект move
Если ты имел ввиду систему, то она должна быть одна на всю игру, и вся логика передвижения для ЛЮБОГО объекта в игре должна производитться в ней.
>чтобы у тебя компонент coordinates
Я вижу что ты пытаешься сейчас через парадигму ООП решить, в этом вся проблема лютая. ECS вообще другая парадигма. в вещественны объекты, которые являются сокрытыми логикой и данными, то есть инкапулированы в единую сущность программную. В ECS У тебя вещественны только данные. Системы это просто код, функции если хочешь, каждая из которых запускается, получает на вход определённые данные (Напимер coordinates и vector/coord_goal, для того чтобы движение совершить), и их либо меняет, либо выполняет другой код/системы. То есть по сути ни entity, ни системы не знают вообще с чем они работают, игрок это, монстр, стул или стена. Система просто перебирает все vector/coord_goal, и изменяет все coordinates в соответствии с ними.
Ещё раз повторю. в ECS главенствующую роль играют компоненты, то есть данные. Они разделяются на типы, и хранятся допустим в массивах прямо штабелями. Системы просто получают на вход весь массив компонентов и обходят их (это в самой примитивной реаализации). entity тут это просто id всех компонентов. Ни о каких инкапсуляциях и классах тут нет и речи.
>Какая система и как его должна подхватить, что с ним сделать?
Вопрос открытый ещё, ты можешь сделать системы которые будут логически разделены, и просто получать какие-то типы компонентов. Я предполагаю что у тебя у всех игровых обектов в мире будет позиция, и вектор движения, или точка куда они должны на следующий ход/тик двинуться. система move просто подхватывает вектор движения и координаты ентити, обсчитывает как надо и переписывает move.
По хорошему советую забить пока NAHOOI на ECS раз тебе так сложно.
>>656680
А его и не надо накостыливать по сути. На ЕСЦ игру с нуля пишут, внедрять его по ходу - это ебантяйство.
Хуёво конечно. Не представляю как ты до сих пор не понял что такое ЕЦС и как он используется, но про пятон сказать ничего не могу.
У тебя неть entity player. У тебя есть просто базовый entity который просто хранит в себе компоненты, и всё.
Если ты имел ввиду систему, то она должна быть одна на всю игру, и вся логика передвижения для ЛЮБОГО объекта в игре должна производитться в ней.
Я вижу что ты пытаешься сейчас через парадигму ООП решить, в этом вся проблема лютая. ECS вообще другая парадигма. в вещественны объекты, которые являются сокрытыми логикой и данными, то есть инкапулированы в единую сущность программную. В ECS У тебя вещественны только данные. Системы это просто код, функции если хочешь, каждая из которых запускается, получает на вход определённые данные (Напимер coordinates и vector/coord_goal, для того чтобы движение совершить), и их либо меняет, либо выполняет другой код/системы. То есть по сути ни entity, ни системы не знают вообще с чем они работают, игрок это, монстр, стул или стена. Система просто перебирает все vector/coord_goal, и изменяет все coordinates в соответствии с ними.
Ещё раз повторю. в ECS главенствующую роль играют компоненты, то есть данные. Они разделяются на типы, и хранятся допустим в массивах прямо штабелями. Системы просто получают на вход весь массив компонентов и обходят их (это в самой примитивной реаализации). entity тут это просто id всех компонентов. Ни о каких инкапсуляциях и классах тут нет и речи.
Вопрос открытый ещё, ты можешь сделать системы которые будут логически разделены, и просто получать какие-то типы компонентов. Я предполагаю что у тебя у всех игровых обектов в мире будет позиция, и вектор движения, или точка куда они должны на следующий ход/тик двинуться. система move просто подхватывает вектор движения и координаты ентити, обсчитывает как надо и переписывает move.
По хорошему советую забить пока NAHOOI на ECS раз тебе так сложно.
>накостылить
А его и не надо накостыливать по сути. На ЕСЦ игру с нуля пишут, внедрять его по ходу - это ебантяйство.
>ecs-систем питонячьих но там уровень абстракции сразу максимальный, а я птичка,
Хуёво конечно. Не представляю как ты до сих пор не понял что такое ЕЦС и как он используется, но про пятон сказать ничего не могу.
>Есть у тебя entity player.
У тебя неть entity player. У тебя есть просто базовый entity который просто хранит в себе компоненты, и всё.
>Ты создаешь объект move
Если ты имел ввиду систему, то она должна быть одна на всю игру, и вся логика передвижения для ЛЮБОГО объекта в игре должна производитться в ней.
>чтобы у тебя компонент coordinates
Я вижу что ты пытаешься сейчас через парадигму ООП решить, в этом вся проблема лютая. ECS вообще другая парадигма. в вещественны объекты, которые являются сокрытыми логикой и данными, то есть инкапулированы в единую сущность программную. В ECS У тебя вещественны только данные. Системы это просто код, функции если хочешь, каждая из которых запускается, получает на вход определённые данные (Напимер coordinates и vector/coord_goal, для того чтобы движение совершить), и их либо меняет, либо выполняет другой код/системы. То есть по сути ни entity, ни системы не знают вообще с чем они работают, игрок это, монстр, стул или стена. Система просто перебирает все vector/coord_goal, и изменяет все coordinates в соответствии с ними.
Ещё раз повторю. в ECS главенствующую роль играют компоненты, то есть данные. Они разделяются на типы, и хранятся допустим в массивах прямо штабелями. Системы просто получают на вход весь массив компонентов и обходят их (это в самой примитивной реаализации). entity тут это просто id всех компонентов. Ни о каких инкапсуляциях и классах тут нет и речи.
>Какая система и как его должна подхватить, что с ним сделать?
Вопрос открытый ещё, ты можешь сделать системы которые будут логически разделены, и просто получать какие-то типы компонентов. Я предполагаю что у тебя у всех игровых обектов в мире будет позиция, и вектор движения, или точка куда они должны на следующий ход/тик двинуться. система move просто подхватывает вектор движения и координаты ентити, обсчитывает как надо и переписывает move.
По хорошему советую забить пока NAHOOI на ECS раз тебе так сложно.
Как же вы заебали со своими ECS, не ецс. Главное, чтобы проект был удобным в разработке и его расширении в дальнейшем, ну и чтобы код удобно читался. ВСЁ! Найти баланс между этим говном. Если ты нашел идеальный баланс для себя, то остальные абстракции нахуй плодить не надо. Парадигма ооп на сегодняшний день пока одна из самых удобных, а ецс это темный лес. Иногда бывает, что ты сам того не зная, строишь свою смесь из ооп и ецс из говна и палок.
2,3 Мб, 975x628Истинно так.
Хотя до меня тут недавно доперло, что говоря про ecs я на самом деле говорил про паттерн command. И все равно я не понимаю пока как его использовать. Как пойму скажу (как будто кому-то не похуй)
А еще pygame не умеет выводить text в несколько строк, пизда прост. Такие-то костыли воротим
Хотя до меня тут недавно доперло, что говоря про ecs я на самом деле говорил про паттерн command. И все равно я не понимаю пока как его использовать. Как пойму скажу (как будто кому-то не похуй)
А еще pygame не умеет выводить text в несколько строк, пизда прост. Такие-то костыли воротим
>>657505
Я на полшишечки сам читаю, но на pygame пилю только тогда, когда мне заняться нечем
Я на полшишечки сам читаю, но на pygame пилю только тогда, когда мне заняться нечем
>>657505
Да ты пока его вообще не вдуплил.
>>657311
Не ори, дядя.
Как? Покажи удобный метод для создания расширяемого кода. Про абстракции вообще загнул. ООП это тебе тоже абстракция над ASM и что? ECS становится полезен когда программный код изобилует перекрёстными взаимодействиями, или игровые сущности имеют один корень и природу, и должны мочь очень гибко её принимать, не вызывая конфликтов. Такой подход дюже помогает при написании игровых симуляций, или систем, опять же, с большой комплексностью, или перекрёстным взаимодействием. Естественно при таком раскладе для пиления игорей с относительно простой логикой, типо гриндилок, плоской индюшатины, или топорных дунжон кроулеров (чем собственно и завален сейчас игропром, не говорю шо это плохо) ECS нахуй не всрался, и как ты сказал, будет просто не удобен, и есть более удобные и известные методы. Но если ты хочешь сделать что-то такое суканах комплексное, по типу ДФ или Римача (что первое в голову попалось), то тут ECS начинает уже быть чертовски полезным, по вышеописанным причинам.
Если до сих пор вы не вдуплили положняк и у вас не осталось адекватных вопросов, то вы просто долбоёбы блядь и мне страшно за вас и игропром.
Да ты пока его вообще не вдуплил.
>>657311
Не ори, дядя.
>удобным в разработке
>остальные абстракции нахуй плодить не надо
Как? Покажи удобный метод для создания расширяемого кода. Про абстракции вообще загнул. ООП это тебе тоже абстракция над ASM и что? ECS становится полезен когда программный код изобилует перекрёстными взаимодействиями, или игровые сущности имеют один корень и природу, и должны мочь очень гибко её принимать, не вызывая конфликтов. Такой подход дюже помогает при написании игровых симуляций, или систем, опять же, с большой комплексностью, или перекрёстным взаимодействием. Естественно при таком раскладе для пиления игорей с относительно простой логикой, типо гриндилок, плоской индюшатины, или топорных дунжон кроулеров (чем собственно и завален сейчас игропром, не говорю шо это плохо) ECS нахуй не всрался, и как ты сказал, будет просто не удобен, и есть более удобные и известные методы. Но если ты хочешь сделать что-то такое суканах комплексное, по типу ДФ или Римача (что первое в голову попалось), то тут ECS начинает уже быть чертовски полезным, по вышеописанным причинам.
Если до сих пор вы не вдуплили положняк и у вас не осталось адекватных вопросов, то вы просто долбоёбы блядь и мне страшно за вас и игропром.
>>657311
Так шо всё дело в инструменте. Я не говорю что ECS лучшая религия, просто пытаюсь пояснить тутшней питоноуточке за ECS, но что-то он шибко туго всасывает. Плохие догадки о его интеллекте у меня возникают.
Так шо всё дело в инструменте. Я не говорю что ECS лучшая религия, просто пытаюсь пояснить тутшней питоноуточке за ECS, но что-то он шибко туго всасывает. Плохие догадки о его интеллекте у меня возникают.
>>657578
Они только сейчас у тебя возникли?
Человек с двузначным и более IQ не стал бы писать игру на питоне.
>питон
>Плохие догадки о его интеллекте у меня возникают.
Они только сейчас у тебя возникли?
Человек с двузначным и более IQ не стал бы писать игру на питоне.
78 Кб, 433x419>>657614
Лол, у меня кажется у самого двузначный IQ раз я только сейчас на это внимание обратил.
Ну вообще в оправдание скажу, что я думал он просто тренируется или прототипирует.
Алсо, скоро-то тред потонет уже, а Оп давно уже хуй. Не знаю, есть ли смысл перекат делать
Лол, у меня кажется у самого двузначный IQ раз я только сейчас на это внимание обратил.
Ну вообще в оправдание скажу, что я думал он просто тренируется или прототипирует.
Алсо, скоро-то тред потонет уже, а Оп давно уже хуй. Не знаю, есть ли смысл перекат делать
>>657505
В Питоне не нужен паттерн комманд, потому что там функции и без того являются объектами.
В Питоне не нужен паттерн комманд, потому что там функции и без того являются объектами.
2,5 Мб, 1438x767>>657683
Пока не могу прокомментировать, поясни.
https://refactoring.guru/ru/design-patterns/command/python/example говорит, что не так очевидно всё
>>657614
Я еще и код в тред кидать начну, лол.
На самом деле, прямо сейчас начну. На скрине - мой костыльно-заглушковый способ реализации AI.
Все равно никто кроме меня в этот тред контент не кидает, а ваша обратная связь очень ценна.
Пока не могу прокомментировать, поясни.
https://refactoring.guru/ru/design-patterns/command/python/example говорит, что не так очевидно всё
>>657614
Я еще и код в тред кидать начну, лол.
На самом деле, прямо сейчас начну. На скрине - мой костыльно-заглушковый способ реализации AI.
Все равно никто кроме меня в этот тред контент не кидает, а ваша обратная связь очень ценна.
>>657711
Да ладно кидай, это всё равно намного лучше чем сидеть и бухтеть без дела как мы.
Да нет, не то чтобы это неочевидно. В других языках реализация команды обычно сложнее. Через наследование и т.д.
Да ладно кидай, это всё равно намного лучше чем сидеть и бухтеть без дела как мы.
>говорит, что не так очевидно всё
Да нет, не то чтобы это неочевидно. В других языках реализация команды обычно сложнее. Через наследование и т.д.
Ну и еболу же я написал, пиздец
Но все равно ожидаю закидывания хуями, не зря же гифку делал
Но все равно ожидаю закидывания хуями, не зря же гифку делал
>>657731
Говорю же, если ты что-то делаешь, даже хуйню, это всяко лучше чем ничего не делать. Как мимнмум ты опыт получишь.
Говорю же, если ты что-то делаешь, даже хуйню, это всяко лучше чем ничего не делать. Как мимнмум ты опыт получишь.
>>657731
Пока все работает в 60фпс/по дизайну - забей. Дохуя инди игр в релиз с говнокодом выходят, а диванные кукаретики и дальше байты дрочить будут
мимо Тодд Говард
Пока все работает в 60фпс/по дизайну - забей. Дохуя инди игр в релиз с говнокодом выходят, а диванные кукаретики и дальше байты дрочить будут
мимо Тодд Говард
1,1 Мб, 1438x767Как-то так.
Ананасы, а что на счёт рогаликов с сюжетом?
Или же рогалики но не пошаговые? Как это правильно будет называться?
Или же рогалики но не пошаговые? Как это правильно будет называться?
>>659095
Тру рогалики с сюжетом это взаимоисключающие параграфы. Сюжет всегода предполагает более-менее рельсовый геймплей, что для рогаликов вообще-то непростительно. Правила мира там должны всегда работать свободно в каждом моменте времени. Конечно можно говорить про адаптивные системы сторителлинга, которые сюжет бы тебе пилили исходя из твоих действий, но до таких технологий пока люди не досрали.
опять же холивар ебучий, если рогалик не пошаговый - это не рогалик. Вообще сложно сказать как должно быть реально, и какие пункты стоит учитывать. как по мне если игра хорошая, нет смысла нахуй в точности пытаться соблюсти каноны рогаликов, но собственно тогда ты и делаешь не рогалик
rougelite это как попытки под рогалик, но несоблюдающий некоторые пункты. Но вообще с такими вопросами в /ro/
Тру рогалики с сюжетом это взаимоисключающие параграфы. Сюжет всегода предполагает более-менее рельсовый геймплей, что для рогаликов вообще-то непростительно. Правила мира там должны всегда работать свободно в каждом моменте времени. Конечно можно говорить про адаптивные системы сторителлинга, которые сюжет бы тебе пилили исходя из твоих действий, но до таких технологий пока люди не досрали.
>но не пошаговые?
опять же холивар ебучий, если рогалик не пошаговый - это не рогалик. Вообще сложно сказать как должно быть реально, и какие пункты стоит учитывать. как по мне если игра хорошая, нет смысла нахуй в точности пытаться соблюсти каноны рогаликов, но собственно тогда ты и делаешь не рогалик
rougelite это как попытки под рогалик, но несоблюдающий некоторые пункты. Но вообще с такими вопросами в /ro/
>>659115
Я это вообще к чему
Обчитался тут на самоизоляции исходников эмулятора сервера вов (всегда было интересно как работают спелы пускай даже и в эмуляторе), да и руки зачесались что-то такое сделать
Вот и думал как можно отойти от неких установок/канонов чтобы было и интересно и проще играть
Пока додумался до такого: открытый мир (грубо говоря реалтаймовая игра) и подземелья (игра пошаговая)
Но вот как это всё учесть и продумать пока не дошёл до этого
Я это вообще к чему
Обчитался тут на самоизоляции исходников эмулятора сервера вов (всегда было интересно как работают спелы пускай даже и в эмуляторе), да и руки зачесались что-то такое сделать
Вот и думал как можно отойти от неких установок/канонов чтобы было и интересно и проще играть
Пока додумался до такого: открытый мир (грубо говоря реалтаймовая игра) и подземелья (игра пошаговая)
Но вот как это всё учесть и продумать пока не дошёл до этого
949 Кб, 1113x599Похоже я максимально близко подошел к подобию ECS в рогалике. Или нет. Но для меня выглядит удобно.
Некий инсайт дал >>657683-кун - спасибо!
Если на простом примере попробовать объяснить кому блядь? Я один здесь, то выглядит примерно так:
есть у меня родительский класс с пустым initом -
Class map_object:
def __init__(self):
pass
Внутри него есть методы с кучей параметров. Например:
def set(self, x, y, symbol):
self.x = x
self.y = y
self.symbol = symbol
def lever_properties(self):
self.activated_when_stepped_on = False
self.message_on_activation = '-'
self.symbol_opened = '/'
def container_properties(self):
self.items = []
self.destroyed_when_opened = True
def junk_properties(self):
self.четотам = четотам
И теперь, наследуя новый класс от класса map_object, я могу ему в переопределенный __init__ насовать запуск нужных функций из родительского класса:
Class chest(map_object):
def __init__(self):
self.set(x, y, 'D') #спавним предмет по координатам с символом
self.container_properties() #задаем ему свойства контейнера
ну и так далее. Таким образом я могу сделать например рычаг, который будет вести себя как сундук, и прочее.
В связи с этим, начал жесточайший рефакторинг старого кода под этот формат, в частности генератор карты - два дня мозг себе ебал, пробовал новые варианты генерации, стирал к херам, писал новые, стирал - короче, кое-как привел в вид, который мне нравится. Без этого создавать несколько карт было бы лютым пиздецом, а сейчас вроде более-менее удобно стало. Если кому будет интересно, опишу, как это у меня сделано.
Из того, что можно посмотреть - сделал секретные комнаты, которые открываются, когда теребонькаешь рычаг, хе-хе. На гифке можно увидеть ее один тайл, т.к. расчет поля зрения кривой. Переделаю. Когда-нибудь. Наверное.
Некий инсайт дал >>657683-кун - спасибо!
Если на простом примере попробовать объяснить кому блядь? Я один здесь, то выглядит примерно так:
есть у меня родительский класс с пустым initом -
Class map_object:
def __init__(self):
pass
Внутри него есть методы с кучей параметров. Например:
def set(self, x, y, symbol):
self.x = x
self.y = y
self.symbol = symbol
def lever_properties(self):
self.activated_when_stepped_on = False
self.message_on_activation = '-'
self.symbol_opened = '/'
def container_properties(self):
self.items = []
self.destroyed_when_opened = True
def junk_properties(self):
self.четотам = четотам
И теперь, наследуя новый класс от класса map_object, я могу ему в переопределенный __init__ насовать запуск нужных функций из родительского класса:
Class chest(map_object):
def __init__(self):
self.set(x, y, 'D') #спавним предмет по координатам с символом
self.container_properties() #задаем ему свойства контейнера
ну и так далее. Таким образом я могу сделать например рычаг, который будет вести себя как сундук, и прочее.
В связи с этим, начал жесточайший рефакторинг старого кода под этот формат, в частности генератор карты - два дня мозг себе ебал, пробовал новые варианты генерации, стирал к херам, писал новые, стирал - короче, кое-как привел в вид, который мне нравится. Без этого создавать несколько карт было бы лютым пиздецом, а сейчас вроде более-менее удобно стало. Если кому будет интересно, опишу, как это у меня сделано.
Из того, что можно посмотреть - сделал секретные комнаты, которые открываются, когда теребонькаешь рычаг, хе-хе. На гифке можно увидеть ее один тайл, т.к. расчет поля зрения кривой. Переделаю. Когда-нибудь. Наверное.
949 Кб, 1113x599Похоже я максимально близко подошел к подобию ECS в рогалике. Или нет. Но для меня выглядит удобно.
Некий инсайт дал >>657683-кун - спасибо!
Если на простом примере попробовать объяснить кому блядь? Я один здесь, то выглядит примерно так:
есть у меня родительский класс с пустым initом -
Class map_object:
def __init__(self):
pass
Внутри него есть методы с кучей параметров. Например:
def set(self, x, y, symbol):
self.x = x
self.y = y
self.symbol = symbol
def lever_properties(self):
self.activated_when_stepped_on = False
self.message_on_activation = '-'
self.symbol_opened = '/'
def container_properties(self):
self.items = []
self.destroyed_when_opened = True
def junk_properties(self):
self.четотам = четотам
И теперь, наследуя новый класс от класса map_object, я могу ему в переопределенный __init__ насовать запуск нужных функций из родительского класса:
Class chest(map_object):
def __init__(self):
self.set(x, y, 'D') #спавним предмет по координатам с символом
self.container_properties() #задаем ему свойства контейнера
ну и так далее. Таким образом я могу сделать например рычаг, который будет вести себя как сундук, и прочее.
В связи с этим, начал жесточайший рефакторинг старого кода под этот формат, в частности генератор карты - два дня мозг себе ебал, пробовал новые варианты генерации, стирал к херам, писал новые, стирал - короче, кое-как привел в вид, который мне нравится. Без этого создавать несколько карт было бы лютым пиздецом, а сейчас вроде более-менее удобно стало. Если кому будет интересно, опишу, как это у меня сделано.
Из того, что можно посмотреть - сделал секретные комнаты, которые открываются, когда теребонькаешь рычаг, хе-хе. На гифке можно увидеть ее один тайл, т.к. расчет поля зрения кривой. Переделаю. Когда-нибудь. Наверное.
Некий инсайт дал >>657683-кун - спасибо!
Если на простом примере попробовать объяснить кому блядь? Я один здесь, то выглядит примерно так:
есть у меня родительский класс с пустым initом -
Class map_object:
def __init__(self):
pass
Внутри него есть методы с кучей параметров. Например:
def set(self, x, y, symbol):
self.x = x
self.y = y
self.symbol = symbol
def lever_properties(self):
self.activated_when_stepped_on = False
self.message_on_activation = '-'
self.symbol_opened = '/'
def container_properties(self):
self.items = []
self.destroyed_when_opened = True
def junk_properties(self):
self.четотам = четотам
И теперь, наследуя новый класс от класса map_object, я могу ему в переопределенный __init__ насовать запуск нужных функций из родительского класса:
Class chest(map_object):
def __init__(self):
self.set(x, y, 'D') #спавним предмет по координатам с символом
self.container_properties() #задаем ему свойства контейнера
ну и так далее. Таким образом я могу сделать например рычаг, который будет вести себя как сундук, и прочее.
В связи с этим, начал жесточайший рефакторинг старого кода под этот формат, в частности генератор карты - два дня мозг себе ебал, пробовал новые варианты генерации, стирал к херам, писал новые, стирал - короче, кое-как привел в вид, который мне нравится. Без этого создавать несколько карт было бы лютым пиздецом, а сейчас вроде более-менее удобно стало. Если кому будет интересно, опишу, как это у меня сделано.
Из того, что можно посмотреть - сделал секретные комнаты, которые открываются, когда теребонькаешь рычаг, хе-хе. На гифке можно увидеть ее один тайл, т.к. расчет поля зрения кривой. Переделаю. Когда-нибудь. Наверное.
А, бля, мужики! Я же годноту вам принес, и забыл запостить.
Когда искал 16-пиксельные тайлы для референса, набрел на просто охуенные два инструмента - tilemancer и tilesetter.
Первый для процедурной генерации тайлов и бесплатный, второй - для генерации сетов тайлов и платный.
Видос для первого - https://www.youtube.com/watch?v=idP3uO9gxlM&t.
Базарю, еще захотите.
Когда искал 16-пиксельные тайлы для референса, набрел на просто охуенные два инструмента - tilemancer и tilesetter.
Первый для процедурной генерации тайлов и бесплатный, второй - для генерации сетов тайлов и платный.
Видос для первого - https://www.youtube.com/watch?v=idP3uO9gxlM&t.
Базарю, еще захотите.
>>662926
если пошаговые то вроде как нихуя неинтересны. некоторые шизойды-завсегдатаи этого треда считают что рогалик должен быть обязательно пошаговым
если пошаговые то вроде как нихуя неинтересны. некоторые шизойды-завсегдатаи этого треда считают что рогалик должен быть обязательно пошаговым
>>657665
Я здесь и постоянно заглядываю в тред. Писать сейчас просто нечего: работаю РАБоту, самоизолируюсь потихоньку. Времени на петпрржекты просто нет, с голоду бы не сдохнуть. Перекатывать однозначно стоит, потому что тема треда много кому интересна, как оказалось
>Алсо, скоро-то тред потонет уже, а Оп давно уже хуй. Не знаю, есть ли смысл перекат делать
Я здесь и постоянно заглядываю в тред. Писать сейчас просто нечего: работаю РАБоту, самоизолируюсь потихоньку. Времени на петпрржекты просто нет, с голоду бы не сдохнуть. Перекатывать однозначно стоит, потому что тема треда много кому интересна, как оказалось
>>664282
Договорились
Договорились
>>664175
Ну я когда думал много пердел над гейдизайном, имхо конечно стандартная пошаговость Роугов уже протухла нахуй, при этом если хочешь въебать мультиплеер скорее всего тут требуется использовать рил тайм, или какие-то хитровыебанные методы. Но суть в том что рогалики это не какой-то спинномозговой дроч а тактика. А без пауз или пошаговости хуй тебе а не тактика. думал над какими-то системами а-ля Divinity original sin, где образуется "пузырь" в котором действовать могут все только по шагам. Но при этом этом на подумать у всех будет не так много времени, секунд 10-15 наверное. Но такая механика очень сильно неестественная, поэтому надо думать.
Ну я когда думал много пердел над гейдизайном, имхо конечно стандартная пошаговость Роугов уже протухла нахуй, при этом если хочешь въебать мультиплеер скорее всего тут требуется использовать рил тайм, или какие-то хитровыебанные методы. Но суть в том что рогалики это не какой-то спинномозговой дроч а тактика. А без пауз или пошаговости хуй тебе а не тактика. думал над какими-то системами а-ля Divinity original sin, где образуется "пузырь" в котором действовать могут все только по шагам. Но при этом этом на подумать у всех будет не так много времени, секунд 10-15 наверное. Но такая механика очень сильно неестественная, поэтому надо думать.
>>664659
Просто темп игры не должен быть слишком быстрым
К примеру автоатака раз в полторы-две сек, таргетная система боя
Можно даже без коллизий между юнитами делать, а учитывать только расстояние до цели, угол
Просто темп игры не должен быть слишком быстрым
К примеру автоатака раз в полторы-две сек, таргетная система боя
Можно даже без коллизий между юнитами делать, а учитывать только расстояние до цели, угол
>>664889
Ну про то что темп не должен быть слишком быстрым это да, как вариант скажем так.
Про последнее не понял.
Ну про то что темп не должен быть слишком быстрым это да, как вариант скажем так.
Про последнее не понял.
>>664889
а что, это вполне интересная идея, есть даже вполне успешные примеры(хотя к рогаликам они относятся вообще никак) - в FF14 емнип каждый тик равен строго 2.5 секундам. и ничего, люди вполне привыкают к такой системе, какие-то действия наперед просчитывают.
запилить что-то вроде такого а то и дольше - здесь возможно поиграться надо, может быть добавить какой-нибудь класс для спинномозговых с менее зависящими от тика способностями, может вполне выйти неплохо и нашим и вашим
>К примеру автоатака раз в полторы-две сек, таргетная система боя
а что, это вполне интересная идея, есть даже вполне успешные примеры(хотя к рогаликам они относятся вообще никак) - в FF14 емнип каждый тик равен строго 2.5 секундам. и ничего, люди вполне привыкают к такой системе, какие-то действия наперед просчитывают.
запилить что-то вроде такого а то и дольше - здесь возможно поиграться надо, может быть добавить какой-нибудь класс для спинномозговых с менее зависящими от тика способностями, может вполне выйти неплохо и нашим и вашим
>>664900
система может и интересная, но мне как человек который дрочит на симулятивность кажется искуственной и ограниченной. Но как обусловненная игровая механика нормально.
система может и интересная, но мне как человек который дрочит на симулятивность кажется искуственной и ограниченной. Но как обусловненная игровая механика нормально.
>>664898
Это я привёл в пример автоатаку, а вот допустим как было бы с кастерами
Например, каст идёт 1-1,5 сек, за это время ты думаешь что можно использовать дальше, как может ответить противник
Если это мгновенные заклинания (например, наложение доты), то надо прикинуть сколько она нанесёт урона за всё время (как вариант скалирование урона должно производится во время каста, а не постоянно обновляться)
Это я имел ввиду карту и управление персонажем
Если формат тайловый, то тут, в принципе, не может быть понятия "удар в спину" и поэтому персонажу не нужно поворачиваться к противнику
Если же нет, то персонажа нужно повернуть к противнику
>>664900
Ну не обязательно фиксированный тик
Я рассуждал так: я знаю свои статы, свой урон, знаю хп противника, что он может сделать и исходя из этого я прикидываю за сколько секунд я его разложу (сколько ударов будет, какие способности я буду использовать и тд)
> Ну про то что темп не должен быть слишком быстрым это да, как вариант скажем так.
Это я привёл в пример автоатаку, а вот допустим как было бы с кастерами
Например, каст идёт 1-1,5 сек, за это время ты думаешь что можно использовать дальше, как может ответить противник
Если это мгновенные заклинания (например, наложение доты), то надо прикинуть сколько она нанесёт урона за всё время (как вариант скалирование урона должно производится во время каста, а не постоянно обновляться)
> Про последнее не понял.
Это я имел ввиду карту и управление персонажем
Если формат тайловый, то тут, в принципе, не может быть понятия "удар в спину" и поэтому персонажу не нужно поворачиваться к противнику
Если же нет, то персонажа нужно повернуть к противнику
>>664900
Ну не обязательно фиксированный тик
Я рассуждал так: я знаю свои статы, свой урон, знаю хп противника, что он может сделать и исходя из этого я прикидываю за сколько секунд я его разложу (сколько ударов будет, какие способности я буду использовать и тд)
>>664906
Опять же имхо это довольно аркадная конечно боёвочка. Если и брать рилтайм боёвку, то я бы выбрал что-то а-ля Rimworld, только заточеную под прямое управление. Только там надо порботать с тем как способности бы использовались.
Опять же имхо это довольно аркадная конечно боёвочка. Если и брать рилтайм боёвку, то я бы выбрал что-то а-ля Rimworld, только заточеную под прямое управление. Только там надо порботать с тем как способности бы использовались.
>>664908
Ну в моих кирилливаниях способности и их использонваие особым образом структурированы. Будет специальное меню способностей или навыков, в котором будет 2 метода использования способности. Первый - способность можно использовать из контекстного или радиального меню, которое вызывается если зажать кнопку способности. Это быстрый способ. Выбрал способность зажатием, и использовал. Но ограничение на одну кнопку способностей 8, или того меньше. Таких кнопки будет 2-4. Второй метод уже будет длинный, прямо непосредственно вызывает всё дерево или список способностей, так как они будут все размещены иерархично. Но при этом там будут сразу все способности для использования.
Ну в моих кирилливаниях способности и их использонваие особым образом структурированы. Будет специальное меню способностей или навыков, в котором будет 2 метода использования способности. Первый - способность можно использовать из контекстного или радиального меню, которое вызывается если зажать кнопку способности. Это быстрый способ. Выбрал способность зажатием, и использовал. Но ограничение на одну кнопку способностей 8, или того меньше. Таких кнопки будет 2-4. Второй метод уже будет длинный, прямо непосредственно вызывает всё дерево или список способностей, так как они будут все размещены иерархично. Но при этом там будут сразу все способности для использования.
>>664908
Алсо. Система конечно вырвана из контекста. Потому что подразумевается что она будет использоваться в игре где этих самых способностей довольно дохуя. По сути любые действия игрока могут попасть в эту категори, просто которые acton, а ля копать, разбирать, ссать и срать не используются так часто как присесть, пойти вправовлево, использовать и прочее, и выносить их в отдельную клавишу (как делают поехавшие рогули древности) вообще нет никакого ризона.
Алсо. Система конечно вырвана из контекста. Потому что подразумевается что она будет использоваться в игре где этих самых способностей довольно дохуя. По сути любые действия игрока могут попасть в эту категори, просто которые acton, а ля копать, разбирать, ссать и срать не используются так часто как присесть, пойти вправовлево, использовать и прочее, и выносить их в отдельную клавишу (как делают поехавшие рогули древности) вообще нет никакого ризона.
>>664911
Ну 99% возможностей игрока, как я себе представлял, будут реализованы через способности.
Не все из них активные (те которые может использовать игрок), а просто как бы скрыты.
Например способность атаковать, носить определённые предметы, использовать какую-то магию и тд.
Ну 99% возможностей игрока, как я себе представлял, будут реализованы через способности.
Не все из них активные (те которые может использовать игрок), а просто как бы скрыты.
Например способность атаковать, носить определённые предметы, использовать какую-то магию и тд.
232 Кб, 1341x872>>664912
Да. типо того. Вообще в идеале под любое действие любого существа должен быть единый фрейворк блять, ну или точнее технически это должно быть одного и то же действие. К слову насчёт магии - мне не нравится современное представление магии как просто ссаные действия которые делают урон и стоят маны, и всё, хуйня ебаная нассал.
Более интересна в этом плане система которая была в magicka, но при этом она довольно полсковатая конечно. Сила заклинаний там фиксированная, маны нет, нельзя регулировать мощность заклинаний соотвественно. А ведь тут такое раздолье для всяких интересных геймплейных механик. От простого создания нефиксированного манапула, который надо будет правильно менеджить и восстанавливать. Ведь по сути мана это свеого рода ресурс разума наверное. Тобишь если слишком истощать манапул мощными заклинаниями, то можно умереть нахуй. Но если знать ритмы восстановления маны, можно в них как бы входить и хоть не сильно ебашить заклинаниями так за то бесперерывно. Вообще в голове целая система есть ебическая, но я пока не знаю надо ли её вываливать.
Пик - кусок моих высерков.
Да. типо того. Вообще в идеале под любое действие любого существа должен быть единый фрейворк блять, ну или точнее технически это должно быть одного и то же действие. К слову насчёт магии - мне не нравится современное представление магии как просто ссаные действия которые делают урон и стоят маны, и всё, хуйня ебаная нассал.
Более интересна в этом плане система которая была в magicka, но при этом она довольно полсковатая конечно. Сила заклинаний там фиксированная, маны нет, нельзя регулировать мощность заклинаний соотвественно. А ведь тут такое раздолье для всяких интересных геймплейных механик. От простого создания нефиксированного манапула, который надо будет правильно менеджить и восстанавливать. Ведь по сути мана это свеого рода ресурс разума наверное. Тобишь если слишком истощать манапул мощными заклинаниями, то можно умереть нахуй. Но если знать ритмы восстановления маны, можно в них как бы входить и хоть не сильно ебашить заклинаниями так за то бесперерывно. Вообще в голове целая система есть ебическая, но я пока не знаю надо ли её вываливать.
Пик - кусок моих высерков.
>>664914
Ну я больше рассуждаю о технической стороне
Имел ввиду такое: у способности есть эффекты (какое-то их количество). Например, эффект нанесения урона, эффект накладывает (бафф\дебафф) что-то на цель (переодический урон\щит, к примеру) и тд
В общем, по сути, всевозможные механики игры.
> Вообще в идеале под любое действие любого существа должен быть единый фрейворк блять, ну или точнее технически это должно быть одного и то же действие
Ну я больше рассуждаю о технической стороне
Имел ввиду такое: у способности есть эффекты (какое-то их количество). Например, эффект нанесения урона, эффект накладывает (бафф\дебафф) что-то на цель (переодический урон\щит, к примеру) и тд
В общем, по сути, всевозможные механики игры.
>>664916
А я тоже про техническое вообще-то.
Просто тут да, выставляется вопрос того как прикреплять логику к этим действиям. Будем мыслить в рамках ECS. Допустим у нас у базовой способности будут методы для получения каких-то данных. Мы можем получать допустим эти данные с помощью вспомогательных методов, которые могут дать нам:
- глобальные переменные
- данные от self ентити
- данные определённого ентити
- от всех ентити в определённой клетке
- от всех данных в определённой области.
Также мы может полученные данные собственно изменять.
Ещё нужно уметь чтобы с помощью способности можно было вызывать новые entity. Допустим нам надо создать какой-то эффект, или запустить процедуру вызова существа и прочее.
А я тоже про техническое вообще-то.
Просто тут да, выставляется вопрос того как прикреплять логику к этим действиям. Будем мыслить в рамках ECS. Допустим у нас у базовой способности будут методы для получения каких-то данных. Мы можем получать допустим эти данные с помощью вспомогательных методов, которые могут дать нам:
- глобальные переменные
- данные от self ентити
- данные определённого ентити
- от всех ентити в определённой клетке
- от всех данных в определённой области.
Также мы может полученные данные собственно изменять.
Ещё нужно уметь чтобы с помощью способности можно было вызывать новые entity. Допустим нам надо создать какой-то эффект, или запустить процедуру вызова существа и прочее.
>>664918
Думаю просто на каждый этот эффект пишется своя функция и всё
> Просто тут да, выставляется вопрос того как прикреплять логику к этим действиям
Думаю просто на каждый этот эффект пишется своя функция и всё
>>664918
Всё, мне кажется, не предусмотреть.
Я у эффектов сделаю поле "цель", точнее там перечисление: сам кастер, перед кастером, союзники рядом, случайный противник в радиусе от кастера и тд и тп
> Допустим у нас у базовой способности будут методы для получения каких-то данных. Мы можем получать допустим эти данные с помощью вспомогательных методов, которые могут дать нам:
Всё, мне кажется, не предусмотреть.
Я у эффектов сделаю поле "цель", точнее там перечисление: сам кастер, перед кастером, союзники рядом, случайный противник в радиусе от кастера и тд и тп
>>666172
Ну конечно не предусмотерть, но всегда можно максимально возможно охватить вероятности всякие бля. Вот какие фичи может быть тяжело или невозможно реализовать из того что предложил я?
Ну конечно не предусмотерть, но всегда можно максимально возможно охватить вероятности всякие бля. Вот какие фичи может быть тяжело или невозможно реализовать из того что предложил я?
>>666766
Да ты не то чтобы что то не правильно сказал. Тут скорее просто с наскока не пояснить за то как стоит вообще логику игры организовывать. условно говоря когда у тебя код организован классами, все данные в нём строго инкапсулированы, и у них как бы есть такие интерфейсы через которые код может общаться, то есть ты не можешь просто взять и из класса с одной логикой въебать модификацию данных в соседнюю логику (можешь считать это системой, или чем паче вообще объектом игровым). тебе обязательно нужно прописать взаимодействие это. Тобишь между разными кусками кода тебе приходится пилить паутину связей, чтобы всё работало. Это огроме переусложение, и создаёт большую связность. Это как раз причина того почему комплексных игорей очень мало, потому что писать логику в таком положении ебически сложно, так как связность растёт геометрически. (Возможно я драматизирую но пока из того что я видел получается именно так)
Да ты не то чтобы что то не правильно сказал. Тут скорее просто с наскока не пояснить за то как стоит вообще логику игры организовывать. условно говоря когда у тебя код организован классами, все данные в нём строго инкапсулированы, и у них как бы есть такие интерфейсы через которые код может общаться, то есть ты не можешь просто взять и из класса с одной логикой въебать модификацию данных в соседнюю логику (можешь считать это системой, или чем паче вообще объектом игровым). тебе обязательно нужно прописать взаимодействие это. Тобишь между разными кусками кода тебе приходится пилить паутину связей, чтобы всё работало. Это огроме переусложение, и создаёт большую связность. Это как раз причина того почему комплексных игорей очень мало, потому что писать логику в таком положении ебически сложно, так как связность растёт геометрически. (Возможно я драматизирую но пока из того что я видел получается именно так)
>>666766
тут я виноват что привёл довольно просто пример, который можно легко разрулить и обычным способом, поэтому показалось что я несу хуйню.
Я пытался просто пояснить тебе некоторую концепцию организации кода, на парадигме DOD, когда данные валяются в общей куче и любая система, логика или скрипт свободно может иметь ко всем этим данным доступ. Поэтому мы можем легко писать и вызываю из любых точек кода любые системы которые могут без предварительной смазки читать и менять данные по всему игровому миру.
https://translate.google.com/translate?hl=ru&sl=fr&tl=ru&u=https://github.com/adnzzzzZ/blog/issues/24
Вот тут кароче поясняется суть этого принципа.
тут я виноват что привёл довольно просто пример, который можно легко разрулить и обычным способом, поэтому показалось что я несу хуйню.
Я пытался просто пояснить тебе некоторую концепцию организации кода, на парадигме DOD, когда данные валяются в общей куче и любая система, логика или скрипт свободно может иметь ко всем этим данным доступ. Поэтому мы можем легко писать и вызываю из любых точек кода любые системы которые могут без предварительной смазки читать и менять данные по всему игровому миру.
https://translate.google.com/translate?hl=ru&sl=fr&tl=ru&u=https://github.com/adnzzzzZ/blog/issues/24
Вот тут кароче поясняется суть этого принципа.
>>666808
Выше я скинул гуглоперевод стати где говорится что то шо япытаюсь пояснить будет приводить свои дивиденты только позже, когда код твоей игры станет уже слишком сложным.
Да, надо действительно сделать какой-никакой прототип. Слухай, у тебя есть телега или мою возьми @adeeee6622, а то мы тонем тут немного...
Выше я скинул гуглоперевод стати где говорится что то шо япытаюсь пояснить будет приводить свои дивиденты только позже, когда код твоей игры станет уже слишком сложным.
Да, надо действительно сделать какой-никакой прототип. Слухай, у тебя есть телега или мою возьми @adeeee6622, а то мы тонем тут немного...
Эх, все обсуждают дженерик рогалики, но никто не пилит свою уютную сосаку-13, там ведь логики гораздо больше надо пилить и думать больше надо.
Например если просчет электричества ещё не такое сложное занятие (хотя там тоже можно вставить всякие законы ома и прочее в отличии от оригинала), то современный просчет физики газов и их смешивания, химия и генетика (а не та бутафория в нынешней сосаке), медицина, операции и болезни потребуют пиздец дохуя сеансов мозгового штурма.
В соло подобное пилю, но единомышленника пиздец как не хватает.
Например если просчет электричества ещё не такое сложное занятие (хотя там тоже можно вставить всякие законы ома и прочее в отличии от оригинала), то современный просчет физики газов и их смешивания, химия и генетика (а не та бутафория в нынешней сосаке), медицина, операции и болезни потребуют пиздец дохуя сеансов мозгового штурма.
В соло подобное пилю, но единомышленника пиздец как не хватает.
>>667135
Space Station 13
Space Station 13
>>667281
Не. Рогалик максимально упрощённый. Я о таком мечтаю уже лет жпять.
Там же кроме ходьбы и стрельбы ничего нет. Но каков геймплей!
Не. Рогалик максимально упрощённый. Я о таком мечтаю уже лет жпять.
Там же кроме ходьбы и стрельбы ничего нет. Но каков геймплей!
>>667630
Я хочу себе симулятор инженера/электрика запилить с корвоанами в виде симуляции виздуха, пока исходный код сосаки читаю. Вот это будет вин.
Я хочу себе симулятор инженера/электрика запилить с корвоанами в виде симуляции виздуха, пока исходный код сосаки читаю. Вот это будет вин.
>>667630
Дум выпустили в 93 году, играй
> Я о таком мечтаю уже лет жпять.
> Там же кроме ходьбы и стрельбы ничего нет. Но каков геймплей!
Дум выпустили в 93 году, играй
>>667658
Алсо, хуй знает как правильно настроить симуляцию воздуха. По сути, она должна работать как вода, но тогда как один газ будет смешиваться с другим? Как будет создаваться новый объект из этих двух? Можно накладывать один объект воздуха на другой (ака слоенный пирог), но это слишком просто. Я не хочу стопроцентной симуляции, но хочу сделать чуть лучше, чем то, что существует в сс13 на сегодняшний день.
Алсо, хуй знает как правильно настроить симуляцию воздуха. По сути, она должна работать как вода, но тогда как один газ будет смешиваться с другим? Как будет создаваться новый объект из этих двух? Можно накладывать один объект воздуха на другой (ака слоенный пирог), но это слишком просто. Я не хочу стопроцентной симуляции, но хочу сделать чуть лучше, чем то, что существует в сс13 на сегодняшний день.
Бля, забыл, что там по сути несколько типов газов могли находиться в одном тайле, не? Уже несколько лет в эту хуйню не играл.
Но в любом случае пришла идея, когда вместо определенного газа, тайл с воздухом будет тупо содержать данные о концентрации газов на этом тайле. А может в сс13 подобное и используется лол.
Но в любом случае пришла идея, когда вместо определенного газа, тайл с воздухом будет тупо содержать данные о концентрации газов на этом тайле. А может в сс13 подобное и используется лол.
>>667690
Не, если бы меня и интересовал сюжет, то скорее какой-нибудь детектив в космосе, ну или чужой с чувством тотального пиздеца и одиночества. А декомпрессия это ещё не вся симуляция тащемта
Не, если бы меня и интересовал сюжет, то скорее какой-нибудь детектив в космосе, ну или чужой с чувством тотального пиздеца и одиночества. А декомпрессия это ещё не вся симуляция тащемта
>>667693
Чтобы сделать детектив или хоррор - нужен писатель. У меня есть пара братюнь, но их заинтересовать нужно.
Ну ладно, чо трепаться. Удачи тебе в запиле.
Чтобы сделать детектив или хоррор - нужен писатель. У меня есть пара братюнь, но их заинтересовать нужно.
Ну ладно, чо трепаться. Удачи тебе в запиле.
>>667090
Блять ты где сука была пидр а? Я нормального человека который бы хотел в реально комплексные игори не видал. Я бы помог чем понемногу, сам думаю за хуйню логику хуё-моё ток давай перекат в телегу ибо скоро тред рухнет @adeeee6622
Блять ты где сука была пидр а? Я нормального человека который бы хотел в реально комплексные игори не видал. Я бы помог чем понемногу, сам думаю за хуйню логику хуё-моё ток давай перекат в телегу ибо скоро тред рухнет @adeeee6622
>>667687
Алсо. Ебану сразу идею сюда. Ты спокойно можешь сделать так чтобы у тебя в одной клетке были как массивом несколько типов геймобжектов-веществ, которые при попадании в тайл просто чекали на возможность смешивания, или в самом тайле был булевой переменная указывающая что на тайле имеются неиннертные вещества, ну для небольшого оптимзиона. Также можно попробовать алгоритмы sparse quadtree для ещё большего оптимизона.
Алсо. Ебану сразу идею сюда. Ты спокойно можешь сделать так чтобы у тебя в одной клетке были как массивом несколько типов геймобжектов-веществ, которые при попадании в тайл просто чекали на возможность смешивания, или в самом тайле был булевой переменная указывающая что на тайле имеются неиннертные вещества, ну для небольшого оптимзиона. Также можно попробовать алгоритмы sparse quadtree для ещё большего оптимизона.
>>667812
Ну я много хуйни придумал, ты вообще насколько хочешь полностью воссоздать ссОЧКУ, ведь можно же лучше сделать есившто. Как нпример систему анатомии немного допилить, аугментациии въебать систему навыков (которые будут скорее использоваться в контексте активации аугментаций, или мутаций допустим. Ну много куда можно. Я выше описывал вродею)
Ну я много хуйни придумал, ты вообще насколько хочешь полностью воссоздать ссОЧКУ, ведь можно же лучше сделать есившто. Как нпример систему анатомии немного допилить, аугментациии въебать систему навыков (которые будут скорее использоваться в контексте активации аугментаций, или мутаций допустим. Ну много куда можно. Я выше описывал вродею)
Ребзя, а какую РПГ систему запихнуть в рогалик? Я думаю GURPS lite, но может что-то есть фриварное?
>>668057
d20
d20
Бамп вялому треду.
Переделал line of sight. Не смог въехать в подход Boba Nystroma с октантами, так что взял рейкаст с roguebasina, причесал и использовал.
Переделал поведение мобов - теперь похоже на осмысленное. Окружают, ищут альтернативные пути. Алгоритмы поиска пути никакие не используются - только поиск ближайшего доступного для шага тайла, который ведет к позиции цели.
Сделал сундуки и их содержимое. Сделал и протестировал переключатели, которые включаются когда на них наступаешь, но пока никак не использовал.
Ужасающее количество времени убил на переделку работы со спрайтами. Pygame невероятно уебищен в этом плане, чтобы сделать анимации без дропа фпс мне пришлось трижды вывернуться. Возможно на питоне больше ничего такого писать не буду.
А, да, сделал простые анимации через жопу конечно же и переход с одной карты на другую - это оказалось проще чем я думал.
Призываю бампать тред своим прогрессом Или ниграми, хоть чем-нибудь. И перекат давайте.
Переделал line of sight. Не смог въехать в подход Boba Nystroma с октантами, так что взял рейкаст с roguebasina, причесал и использовал.
Переделал поведение мобов - теперь похоже на осмысленное. Окружают, ищут альтернативные пути. Алгоритмы поиска пути никакие не используются - только поиск ближайшего доступного для шага тайла, который ведет к позиции цели.
Сделал сундуки и их содержимое. Сделал и протестировал переключатели, которые включаются когда на них наступаешь, но пока никак не использовал.
Ужасающее количество времени убил на переделку работы со спрайтами. Pygame невероятно уебищен в этом плане, чтобы сделать анимации без дропа фпс мне пришлось трижды вывернуться. Возможно на питоне больше ничего такого писать не буду.
А, да, сделал простые анимации через жопу конечно же и переход с одной карты на другую - это оказалось проще чем я думал.
Призываю бампать тред своим прогрессом Или ниграми, хоть чем-нибудь. И перекат давайте.
>>670530
Exp +1 (те уже говорили что питун медленный)
Тут ОП должен был перекатить, но как-то никак. Если вдруг потонем, смогёшь сам перекатить с тем же заголовоком?
>Возможно на питоне больше ничего такого писать не буду.
Exp +1 (те уже говорили что питун медленный)
Тут ОП должен был перекатить, но как-то никак. Если вдруг потонем, смогёшь сам перекатить с тем же заголовоком?
МТред утонул или удален.
Это копия, сохраненная 1 августа 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 1 августа 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.