Этого треда уже нет.
Это копия, сохраненная 1 августа 2021 года.

Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
cogmindasciiartcompilation.png20 Кб, 1115x1003
Говорят рогалики можно кирилить десятилетиями. Поехали! 558349 В конец треда | Веб
Говорят рогалики можно кирилить десятилетиями.

Поехали!
# OP 2 558350
В треде будут по большей части рассуждения, так как я не знаю как реализовать ту или иную функцию. Для начала моя самая большая хотелка: Уникальная система крафта персонажа, предметов, окружения, врагов, эффектов. То есть, все находящееся в игровом пространстве может быть как разбито на некие составляющие, так и быть составлено из них. На самом деле все, на этом все заканчивается, но посмотрим как реализовать хотя бы это. Интересует меня в большей степени внутренняя составляющая игры, поэтому графику и прочее я оставлю на потом.
# OP 3 558351
Писать планирую на C# с оглядкой на многочисленные библиотеки со вспомогательными функциями для создания roguelike игр (там тебе и генерация карт и игровые сущности). В общем, есть куда подсмотреть в случае чего
# OP 4 558364
Ну так вот, рассуждения:

Есть некая область (обычный прямоугольник, для начала) внутри нее расположены игровые сущности, такие как сам игрок, враги, предметы, также в каждой клетке имеется что-то вроде эффекта, который невидим с точки зрения занимаемого пространства, но вполне себе может оказывать влияние на окружающее пространство со всеми объектами в нем. Также я бы выделил такой базовый объект как действие, с помощью которого игровые объекты будут влиять как на себя, так и друг на друга.

Итого:
Пространство
Игрок, враги (или экземпляры одного объекта или просто наследуются от общего опредка)
Предмет
Эффект
Действие
# OP 5 558373
Само собой для простоты разработки все должно быть разбито на группы, то есть, если это это эффект, то у него должна быть определенная природа (физическое воздействие, химическое или наоборот, защита от этого воздействия), если это предмет, то его свойства должны также учитывать наличие этих типов взаимодействия
6 558380
Ну нихуя себе ты неочевидностей рассказал ммм...
# OP 7 558391
>>558380
Ого, кто-то впервые столкнулся с проектированием архитектуры.
8 558392
>>558391
Лично я столкнулся с очередным маняфантазированием в гд, вот сижу прикидываю через сколько дней сдохнет тред.
# OP 9 558393
>>558392
Так через сколько сдохнет? Мне интересно же.
10 558394
>>558393
Думаю максимум через 3 дня. Скорее всего раньше.
# OP 11 558395
>>558394
Ого, целых три дня. Не плохо. Я то думал уже сегодня вечером исчезнуть из треда
12 558396
»558364
Почему у тебя "эффект" и "действие" - базовые объекты? Не кажется ли тебе оптимальным описать всевозможные взаимоидействия и эффекты внутри классов "игрок, враги" и "предметы", ты вообще с ООП знаком? Ну и рогалики, требущие .net - такое себе, конечно.
# OP 13 558398
>>558396

>Почему у тебя "эффект" и "действие" - базовые объекты?


Разве так не будет проще их переиспользовать?

> Не кажется ли тебе оптимальным описать всевозможные взаимоидействия и эффекты внутри классов "игрок, враги" и "предметы"


Что будет в том случае, если классы игрок, враг или предмет должны будут иметь одинаковый эффект или действие? Дублировать код?

>ты вообще с ООП знаком?


Вообще знаком, но критику с радостью приму. Будет круто, если ты чуть более подробно распишешь то, что я делаю не так, потому что сейчас я не понимаю в чем именно проблема. Мне всегда казалось, что ООП должен решать проблему переиспользуемости кода.

>Ну и рогалики, требущие .net - такое себе, конечно.


Согласен, но рогалик, это просто пет. проджект для изучения net, потому и такой стек технологий
# OP 14 558400
>>558398

>Почему у тебя "эффект" и "действие" - базовые объекты?


>Разве так не будет проще их переиспользовать?


И да, любой эффект может применять действие и любое действие может накладывать эффект. Поэтому они должны существовать как отдельные от всего сущности.
15 558402
>>558398

>если классы игрок, враг или предмет должны будут иметь одинаковый эффект или действие? Дублировать код?


>решать проблему переиспользуемости кода


Юзай ECS

А вообще сделай тупой прототип за 2 дня, и там все подводные будет видно. Потом просто с нуля уже начнешь писать с необходимой архитектурой. Главное еще не переусложнять.

мимо
# OP 16 562308
Так, а вот и я.

>>558402
Спасибо, почитал, тема очень интересная, буду продолжать ее изучать. На хабре наткнулся на статью о том как ребята пилил свое решение и оттуда уже нашел еще несколько уже готовых библиотек, но но если все это начать подключать, то никакого фана не будет, поэтому попробую разобраться как это работает и реализую функционал сам.
render1551371195927.gif216 Кб, 1931x460
# OP 17 562309
Сегодня за пару часов накидал небольшой проект с классами базовых объектов, картой и разными вспомогательными плюшками. Выглядит это сейчас так:
# OP 18 562312
Писал с оглядкой на https://github.com/Chris3606/GoRogue , но мне он не очень пока нравится. Например, в классе Coord (Из названия понятно, что он призван облегчить нам работу с координатами) зачем-то используется Xna, который от майкрософта. Также по коду идет много оптимизаций и костылей, которые вроде как описаны и документированы, но все равно режут глаз. В общем, будем писать все свое.
# OP 19 562320
Сейчас нужно немного переосмыслить то, что я тут наделал. Такое ощущение, что я хуйни написал.
20 562325
По мне, ты слишком много внимания уделяешь архитектуре, классам и т.п. Ради чего всё это? Сама то игра у тебя в голове есть?
>>558398

>рогалик, это просто пет. проджект для изучения net


А, ну тогда понятно. Но всё равно, даже практиковаться, имхо, лучше на том к чему есть хоть какие-то идеи и интерес.
# OP 21 562332
>>562325
Есть и интерес и идеи. Обычные приложения пилить как раз намного более скучное дело, чем игру. Тем более, что мелкие приложения уже все запилены, а что-то более масштабное в одиночку просто не поднять. Тем более, что сам я страдаю уже несколько лет игровой импотенцией и мне всегда чего-то не хватало в играх.
# OP 22 562333
>>562325

>По мне, ты слишком много внимания уделяешь архитектуре, классам и т.п. Ради чего всё это?


И да, для меня написание всего этого - уже игра. Получаю удовольствие от построения архитектуры
23 562397
>>558349 (OP)

>пикрелейтед


Это из cogmind? Бля, надо добраться до нее наконец-то.
14315047902312.jpg21 Кб, 349x356
24 562398
>>558398

>ООП должен решать проблему переиспользуемости кода.


Ну да, должен ;) ;) ;)
25 562448
>>562398
А что, нет?
У меня есть базовый класс "иди нахуй", в котором очень много витиеватого трёхэтажного кода, написанного много раз. Теперь, чтобы послать нахуй залётного ЕЦС-чушкана, мне достаточно просто сконструировать класс с инициализатором. И это всё одной строкой!
var посыл = ИдиНахуй.new(){КогоПослать = "ЕЦС-чушкан"}
Далее, если мне нужно плотно работать с чушканом (если он с первого раза не понял), я могу унаследоваться от базового класса:
class ИдиНахуйЕЦСЧушкан : ИдиНахуй { КогоПослать = "ЕЦС-чушкан" }
И далее, просто конструировать класс-потомок.
26 562451
>>562448
Ничего себе, ты дажи класы с носледованием выучил. Кокой ты крутой прогромист.
Шучу, на самом деле твой пост детектит в тебе нюфаню.
27 562576
>>562398
>>562451
Нут ты и траль, дружище. Ты же даже никак не аргументировал свою точку зрения. Если тебе есть что сказать по теме, то давай, ждём. А пока создаётся впечатление, что ты сам ничего в этом не понимаешь.
28 562578
>>562576
И да, добавлю: серебряной пули не существет. Не стоит толкать ООП туда где ему не место и наоборот, если проблема отлично решается средствами ООП, то почему бы его не применить?
29 562582
>>562397
Скрин из их инструмента для рисования
30 562585
>>562576
>>562578
Все твои рассуждения разбиваются о тот простой факт, что ECS это паттерн ООП.
31 562587
>>562585
Такие факты надо пруфать.
Хотя банально по определению понятно, что это абсолютно не так.
32 562609
>>562585

>ECS это паттерн ООП.


Ты не мог не обосраться
33 562749
>>558364
Ты просто движкописец. Видимо твоё призвание - писить движки
# OP 34 563596
Движкописец в треде.
В общем, переосмыслил написанное ранее. Пришел к выводу, что нужно делать так:
1. Есть карта
2. На карте расположены ячейки (Cell) в виде двумерной сетки с координатами x и y соответственно
3. У каждой ячейки есть своя координата и массив объектов находящияхся в ней [в ячейке]
4. Каждый объект находящийся в ячейке может иметь метод Step, который, собственно и может реализовывать часть логики отвечающей за ход данного объекта

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


На самом деле никого бы не сожрали, потому что плесень умеет только двигаться
render1551806207527.gif558 Кб, 1931x670
# OP 35 563597
36 563601
>>563596

>ползет плотоядная плесень


Которая, кстати, реализована с помощью клеточного автомата: https://ru.wikipedia.org/wiki/Клеточный_автомат
95049A77-9CF5-45D4-8322-41B0D9EC8147.png7 Кб, 225x192
37 563726
>>563601
Но сама логика автомата пока собрана из говна и палок. В итоге хотелось бы прийти к описательному формату типа пикрил
38 563729
>>563726

>пик


Это откуда?
39 563732
>>563729
Если про код, то из моей головы. Так вижу решение проблемы описания правил для клеточного автомата. Решение не окончательное, конечно, а просто как пример. А скрин из какой-то онлайновой ide, чтобы подсветка кода была
40 570391
Ты это всё мутишь на С#? Блин, мне тоже интересна тема рогаликоварения, правда я начал с С++. Хотелось бы тоже обоюдный обмен опытом на стабильной основе запилить, дашь фейкомыло?
41 570398
>>558398

>пет. проджект


Пет у тебя сокращение от "петтинг"?
>>563596
У каждой ячейки есть своя координата и массив объектов находящияхся в ней [в ячейке]

>Каждый объект находящийся в ячейке может иметь метод Step


И потом, чтобы stepнуть все объекты, ты будешь перебирать все ячейки?
мимопроходил
42 570451
>>570398
Это сделать же можно через доп bool active, что то такое? чтобы в массив обработки степа добавлялись только обьекты с этим фрагом, и степпер обсчтиывал только их. А пуляться и забираться обьекты будут при их появлении/уничтожении. Не знаю как идея, расскажите о подводных

мимо-не-оп
43 570452
>>570451

>с этим флагом


самофикс
44 570617
>>570398

>И потом, чтобы stepнуть все объекты, ты будешь перебирать все ячейки?


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

Мимо ОП
45 570619
Рад, что тред не умирает и даже кому-то интересен. У меня тут нужда небольшая в деньгах появилась и по вечерам шабашу. Как только закрою проект, так сразу продолжим кодить, а пока можно подумать над альтернативой регистрацией объекта в ячейку и отдельное хранилище. Мне кажется, что это не самый лучший способ
46 570623
>>570391
Пиши в тред, друг. Здесь, если мы хуйни понарошку нас хоть люди поправят, но если очень хочется, то я позже заведу фейк и кину в тред

Оп
47 570624
>>570623

>понарошку


Понапишем
48 570626
>>570619

>регистрацией объекта в ячейку и отдельное хранилище. Мне кажется, что это не самый лучший способ


Объясню пока. Это скорее даже не костыль, а просто плохо масштабируемое решение. Если представить, что у нас появляются ещё какие-то критерии по которым мы бы хотели делать выборки, то сразу становится ясно, что ми по итогу просто будем перебирать каждый раз это самое общее хранилище. Непорядок.
49 570652
>>570623
Лишь бы ты не ищезал внезапно.
К слову, я смотрю ты филигранно расставляешь архитектуру игры, но у тебя есть концепт со стороны пользователя? Вот что он будет видеть?
Мне тоже интересна дико тема проработки архитектуры, правда пока-что не хватает умишка прорабатывать это всё. И твоя идея даже подожгла немного меня.

То есть допустим, несмотря на то, что у тебя шикарная идея, не понятно как это будет со стороны пользователя выглядеть, что ты хза игру создать хочешь, что за вселенную, чем там можно и нужно будет заниматься? Чем она будет увлекать? Насколько можно будет отождествляться со своим персонажем? (Как пример, тут Cogmind несмотря на всю свою эпичность механик, сильно проигрывает в связи с персонажем Cataclysm DDA, предполагаю, что причина тому совершенно ни на что не похожий мир, и персонаж, который представляется абстрактным роботом) Рогалики это довольно неординарная ветвь игр, но её основное требование, и в то же время преимущество, это то, что здесь можно невозбранно экспериментировать с механиками, структурой мира, ядром игры и прочим. Создавать по-настоящему симулятивные программы. Очень хороший пример это Дварф Фортресс.

Я лично, хотел бы поэкспериментировать с механом магически/псионических способностей (совсем не в том виде, в котором их видит фентези), или с механом повреждения и модификации человека. Тобишь все органы работют, всё можно при определённых условиях заменить (и не только на бионические протезы). Но это пока просто маняфантазии

Я хотел получить почту, или что-нибудь еще (телегу дискорд или тому подобное) чтобы более оперативно общаться на эту тему.
3DEA5F79-1110-4415-B32F-C22DC6D08521.png142 Кб, 800x800
50 570950
>>570652
На самом деле о геймплее очень рано заводить речь. Будет так: у меня есть ряд технологий, которые мне сейчас интересно освоить. Это и клеточные автоматы, и ии (ml.net), и скриптовые языки внутри приложения. И как будет запилен некий набор функций, я его облачу в геймплей в сеттинге «самосборка». С таким подходом модно будет даже попробовать поэкспериментировать с геймплеем, используя пикрил архитектуру
51 571030
>>570950
Кстати я тоже маняфантазировал, как бы самосбор выглядел в рогалике.

Я думаю что это всё должно так или ниаче паралельно идти. Потому что вдруг ты сочтёшь нужным применить какую-нибудь геймплейную механику, а у тебя тех возможности не будет нормальной, и придётся пилить это через костыли, или вообще отказаться от этой идеи.

Кстати, я в этой теме далеко не ведающий, пояснить как ты будет машин лёрнинг использовать?
Как можно расшифровать пикрил?

К слову, как у тебя будет карта реализована? стандартным нетхаковским методом? (одна карта на весь экран, каждый z уровень отдельно, а не является 3д структурой), или как в том же катаклизме? (герой в центре бесшовной карты, а z уровни являются частью игры (хотя конечно в кате с я уровнями проблема ебанутая, там вообще их по сути нету, но кит исправился во второй части. И забросил её.))

И как ты видишь Самосбор рогалик? Как выживастик? Или как симуляцию, где @ должен будет существовать?
52 571140
>>571030

>Я думаю что это всё должно так или ниаче паралельно идти. Потому что вдруг ты сочтёшь нужным применить какую-нибудь геймплейную механику, а у тебя тех возможности не будет нормальной, и придётся пилить это через костыли, или вообще отказаться от этой идеи.


Если для описания игровой логики (геймплея) мне чего-то не хватает и приходится городить костыли, значит я что-то сделал неправильно и нужно будет это исправлять, а не городить костыли. Цель - не конечный результат, а скорее увлекательный процесс написания и проектирования движка.

>пояснить как ты будет машин лёрнинг использовать


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

>Как можно расшифровать пикрил?


https://metanit.com/sharp/mvc5/23.1.php
Там все доступно рассказнно.

>К слову, как у тебя будет карта реализована? стандартным нетхаковским методом?


У меня пока это просто 2д сетка, по которой перемещаются игровые объекты. Она не бесконечная.

>И как ты видишь Самосбор рогалик? Как выживастик? Или как симуляцию, где @ должен будет существовать?


Во всех рогаликах, что я играл, мне не хватало "глубины" погружения. Создавалось впечатление каких-то пластмассовых, заскриптованых декораций, по которым бродит персонаж. По задумке, все функции, которые я реализую, должны каким-то образом комбинироваться порождая огромное число разных механик. Конечно, все это может вырости в неуправляемую хуету, но так даже интереснее. В общем, будет некий, существующий по своим внутренним законам мир, а персонаж просто будет по нему бегать.
53 571141
>>571140
Галочка
54 571236
>>571140

>У меня пока это просто 2д сетка, по которой перемещаются игровые объекты. Она не бесконечная.



Тобишь ты будешь потом перепиливать всё?

>майкрософт выпустили библиотеку для машинлернинга, которая может встраиваться в .net приложения с минимальной болью, считай просто из коробки. Применений можно придумать много, но все это будет понятно, когда я начну ее изучать.



Насколько я знаю, машин лёрнинг пока можно обучать в очень узких специальностях. Может быть можно написать площадку с группой юинтов А, и одним юнитом Б, и их обучать убиению друг друга, тренируя pathfinding и стратегию, хотя я честно не уверен насколько это возможно.

Еще можно натренировать чтобы локации генерировались более интересным образом.

Еще были маняидеи насчёт написания StoryTeller'a, грубо говоря бота рассказчика, который бы формировал текст путешествия в форме логов, но при этом учитывая огромное количество переменных, или может даже меня окружение/квесты.

>Во всех рогаликах, что я играл, мне не хватало "глубины" погружения. Создавалось впечатление каких-то пластмассовых, заскриптованых декораций, по которым бродит персонаж.


Это конечно да, не спорю...

>По задумке, все функции, которые я реализую, должны каким-то образом комбинироваться порождая огромное число разных механик.



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

К слову, чего пишешь сейчас там? Интересно узнать как сама разработка происходит.
55 571305
>>571236

>Тобишь ты будешь потом перепиливать всё?


Если текущее решение не будет меня устраивать - конечно. Проблемы в этом никакой нет, ведь с каждым разом должно получаться все лучше и лучше

>Вот в этом проблема уже есть, в плане того, что у тебя так или иначе должно быть понимание как всё работает, и должна быть единая система, полностью изначально расписанная.


Расписал крупноблочно (на высоком уровне абстракции так сказатб) чтобы определиться с направлением. Сейчас идет этап исследования, когда я просто экспериментирую. Обычно после этого этапа требования и уточняются.

>К слову, чего пишешь сейчас там? Интересно узнать как сама разработка происходит.


Сейчас работаю над другими проектами (за которые мне платят), а рогалик, это домашний проект, который получается все оставшееся время (которого пока нет). Поэтому пока ничего нового показать не смогу
56 571307
>>571305
>>571236
Вообще, цель, это не рогалик как законченный продукт, а сам процесс разработки, в течении которого я смогу пощупать кучу всего нового. Да, было бы очень хорошо, если бы мне его удалось закончить, но нужно быть готовым, что это затянется надолго.
57 571333
>>571307
Да, ты писал уже об этом. Ну буду мониторить тебя. К слову, може ты на гитхаб зальёшь исходники, или как-нибудь еще рашшеришь? Мне интересно посмотреть исходники
58 571357
>>571333
Да, так позже и сделаю.
59 572060
че блять умер что ли, ну ебана
60 572114
>>572060
Работу работаю. Абу мне не платит за этот тред и приходится зарабатывать работая на дядю. Так что давай запасемся терпением лучше.
61 572199
>>572114
ты сюда время от времени хотя бы измышления свои вываливай, может думки по механикам и архитекртуре там.
62 572299
Присоединяюсь! Какой язык используете?
63 572300
64 572301
>>572300
Сделал уже что-нибудь? Или может есть предыдущие проекты?
65 572302
>>572301
Если ты про игровые проекты, то это первый.
66 572307
>>572300
А пчому именно С# то? Чем он лучше Спп?
67 572311
>>572302
Ааа, ладно. Завтра планирую новый рогалик начать писать, ибо мне не очень понравилось как я реализовал предыдущий, хоть и много всего сделал, если вам будет интересно может буду показывать свои результаты, не знаю.
68 572312
>>572311
А ты ОП штоле?
69 572313
>>572312
Неа.
70 572314
>>572313
А что у тебя за рогалик? И почему ты решил остановиться? Что не так было с предыдущим? Какая там архитектура была?
71 572316
>>572307
Ничем. Смотри >>558398

>Согласен, но рогалик, это просто пет. проджект для изучения net, потому и такой стек технологий

72 572317
>>572314
Вообще читая тред я наверное осознал какой простой у меня рогалик, ибо у меня все как то намного проще получилось, да и вообще зашкварно или нет, но я его писал на lua, думаю может на c++ попробовать, хз. Ну вообще рогалик как рогалик получился, графика тайловая, в папке с игрой лежит тайлсет чтоб каждый мог изменять его, над генерацией я не сильно заморачивался, думал и пытался реализовать чтоб были подземелья, комнаты все такое, а в итоге получился генератор пещеры, ну я и решил оставить ибо выглядело неплохо. Игра очень сложная, мобы живут своей жизнью, размножаются, игрок может свой мини домик построить. 10 класс и 10 рас, в общем довольно много сделал, долго объяснять) Но как то мне он не нравится, по этому планирую новый рогалик с опорой на реализм в механике боевки, типа можем атаковать любую часть тела моба, моб будет погибать от тяжёлых ран или от потери крови, скиллы прокачиваются взависимости от того, что ты делаешь, в общем наверное как то так, ух, многовато как то я написал.
73 572319
>>572317
Неплохо. Мне казалось фундамент так или иначе нужно будет закладывать на С++, или С#. Я просто начал плюски задрачивать, потому и выбрал их. А ОП о-очень интересные идеи в плане архитектуры подаёт. С заделом на будущее.

Идея написать полное и гибкое ядро на спп допустим, а остальной контент и функционал пилить на том же луа, или питоне. Как по мне, так это довольно интересная задумка, которая позволит создать универсальный движок для рогаликов. Но это конечно надо тщательно прорабатывать архитекртуру, и обдрачиваться предиктивностью. И тут конечно вопрос оптимизации опять вылезет. Хоть рогалик и игра пошаговая, о работать она тоже быстро по-своему должна.
74 572323
>>572319
Круто, в общем завтра скину скриншот рогалика который получился, а сейчас спать, удачи :3
75 572324
>>572323
А графоний на чем пилил, OpenGL/SDL/...?
76 572325
>>572324
а какие плюсы и минусы той или иной либы по отношению к рогаликоварению?
1.png14 Кб, 734x255
77 572335
Так. Сейчас попробуем порассуждать на тему юнитов и принятых ими решений.
Представим, что существует некая условная йоба (человек, дрон, плотоядная плесень, лужа йоба-слизи). Вокруг йобы представлен мир, а у самой йобы имеются некие сенсоры, позволяющие получать информацию из этого самого мира. Если это человек, то в роли сенсоров могут выступать глаза, уши, нос. Если это плесень, то она может получать только информацию о том, что находится в тех клетках где она распространена и немного рядом (те клетки, с которыми она соприкасается). Так как время в игре квантовано (разделено на шаги) очевидно, что каждый ход юнит должен просто анализировать полученную им информацию и выдавать своему телу или чему-то еще команду.

На пике максимум упрощенно показано то, что я сейчас проговорил.

Из чего по итогу состоит юнит:
1. "сенсоры" собирающие данные об окружающем мире и самом юните (например, сенсор отвечающий за чувство голода)
2. модульное тело, каждая часть которого может иметь свои уникальные функции
3. черный ящик принимающий решения и отдающий команды модулям тела

Далее о черном ящике. Сам он должен быть также модульным, (модуль клеточного автомата, модуль ИИ). Даже не один модуль, а целая цепочка, если так как универсальный ИИ создать будет для меня практически невозможно, а вот ИИ отвечающий за какую-то определенну. функцию - легко.

Вообще, по задумке, внутри ящика будет существовать некий объект со внутренней информацией (некий scope, в котором будет храниться также контекст (дополнительная информация))

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

ваш ОП
78 572336
>>572335

>(модуль клеточного автомата, модуль ИИ)


Там же будет какой-нибудь скриптовый язык, чтобы можно было написать логику просто руками. Например, lisp (интерпретатор которого мы напишем сами, конечно же)
79 572343
>>572325
Я сам хз, но по идее для простых рогаликов подойдёт ченить высокоуровневое, сам юзаю OpenGL в самой простой вариации(шэйдеры и массивы примитивов для координат квада) потому что по-другому никак.
Если не охота байтоебить можно начать с Love2D какого-нибудь.
80 572351
>>572336
Ты же на Сишарпе, как лисп воткнёшь?
81 572393
>>572351
Любая достаточно сложная программа на C или Фортране содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp (Филип Гринспен)

А если по существу, то так и воткну. Это же скриптовый язык. Для него лишь необходим так называемый интерпретатор, который в свою очередь может быть написан на чем угодно (уже написан почти на всем, на чем только можно, в том числе c#)
82 572441
>>572427
>>572421
>>572408
>>572405
>>572382
>>572378
>>572376
>>572363
Макаба протекает или вы тредом ошиблись?
83 572452
>>572441
Вайп старыми постами?
84 572461
>>572452
Как-то слабовато получилось
85 572473
Спасибо, Абу, почистил тред
86 572531
>>572335
Ну в общих чертах это конечно очевидное описание. Вот скорее интересно, получается, каждый юнит будет получать каждый ход заного всю карту? как вообще будет представляться в уме ИИ всё пространство? Как информация будет интерпретироваться? Условно, для простого ИИ обычного импа-чухана, можно просто вложить тайлы препятствий, тайлы опасности и тайлы агрессивно-дружественных существ. Хотя каждый ход прогонять заного всё это, смысла особого нет, как по мне. Не оптимальненько. При этом тебе придётся либо писать каждому виду существ "модели" поведения, или же можно создать 1 модульный вид интеллекта, который будет ограничиваться "знаниями", которые у него имеются (а-ля флаги).

Еще к слову вопрос масштабируемости. будет ли у тебя идти "общий" просчёт всего, что находится за "пузырём"? Или же вне, мир будет замирать?

>>572343
Меня парит больше вопрос оптимизации, и кроссплатформенность, Можно и побайтоёбить, но немного, и чтобы не было слишком сложно, а-ля брейнфак бля, без фанатизма в общем.

>>572336
Чем тут Лисп от Луа отличается?
И меня постоянно почему-то парит то, что такие скриптовые языки будут невероятно медленные, по сравнению с компилированным кодом, и что им можно только давать простую логику. Но при этом желание сделать core игры так сказать на Сишке, а дописать механ на Луа довольно неслабо перевешивает.
87 572541
>>572324
К сожалению, не заморачивался над этим, и просто использовал Love 2D, там используется function love.draw(), что довольно все облегчает. В следующем моем посте, прикреплю уже скрины с тем моим рогаликом, о котором я писал.
88 572542
Вот собственно тот рогалик о котором я писал:
1) скрин - меню,создание персонажа, выбор расы и класса. Sy - Satiety, Ka - Karma(в игре можно помолиться богу в сложной ситуации, и чем больше у тебя карма, тем больше шанс, что бог тебе поможет,кстати не все расы веруют в бога, типа есть расы атеисты)
2) скрин - сама игра, спрайты выполнены в размере 21x21, в папке с игрой находится tileset. справа открыт инвентарь, любая вещь имеет свой бафф, урон(если будешь кидать эту вещь во врага), вес и цена. На скрине мы видим торговца, масло на полу(на нем любой может подскользнуться и упасть), ловушки, статую,лестницы вниз и мобов.
3) скрин - игра как она выглядит на самом деле, то есть то, что игрок не сможет увидеть,ибо он видит только то. что в зоне его видимости. Есть 2 типа стен: целые и полуразрушенные. вторые игрок может сломать и руками, но -немного hp будет, либо любую стенку киркой, так же можно и строить стены, статуи, ковер и создать свой домик. Так же на скрине мы видим алтари.
4) скрин - вакханалия, я просто дал убить себя слизням, подождал много ходов и вот они размножились жестко, ибо эт слизни.
89 572543
>>572542
Забыл добавить, чтобы повысить карму, нужно кормить котиков) А еще они всегда за тобой ходят, убив котика ты получишь мясо, но -карма.
tileset.png15 Кб, 645x741
90 572544
>>572542
А вот и мой тайлсет, кстати в игре могут заспавнится надписи, типа тех, кто был здесь до игрока, они выглядят очень неразборчиво, написанные кровью, мелом и тд(это генерируется) и фишка в том, что надпись может быть вообще выглядеть не понятно, типа HEL##O W##LD
91 572551
>>572544
>>572543
>>572542

Неплохо неплохо, опыт значит имеешь уже.

ОП, а ты какие-либо используешь UML системы? Сейчас вот я Enterprise Achitect постигаю. Мне кажется, с ним пилить архитектуру намного легче)
92 572560
Я тут тоже маняфантазиями балуюсь

- Отражать скованность персонажа (от одежды), оглушённость, и невозможность двигаться параметром от 0 да 100%. От громоздкой одежды повышается скованость, также как и от допустим захвата персонажа ручками. Скованость можно распрастраняться на отдельные части тела. "Нулём" можно считать базовую скорость/ловкость персонажа, который "условно" голый. 100 процентов, это полное обездвиживание той или иной части тела.

- Обработку STЕP (каждый ход) можно проводить добавляя в массив все активные объекты в "пузыре", активные объекты будут добавляться при инциализации баббла, а также при удалении или входе в него.

- Все сущности будут иметь физические и нефизические части тела, физические условно создают простой объект среды, коих будет много, на него можно влиять снаружи и он также может влиять. Имеет параметры, и методы воздействия, засчёт как единичных органов, так и комплексных систем, которые получают свой функцинал только когда будут собраны. (Опорной двигательная, пищеварение) Также будут иметься нефизические, вероятно они будут взаимозависимы от физических, и существовать только с помощью физических свойств. Допустим условная "разумность" это блок обработки ИИ, или передача контроля сущностью игроку, которая находится в мозге. Нефизическими могут также быть любые другие объекты, которые являются более абстрактными, и не поддающиммся непосредственному обнаружению в игре (не точно). Вопрос чем это будет, просто преписываемыми к частям тела параметрами (как например душа(ии или игрок) к мозгу). Или они будут занимать не локальную позицию (аки абстрактное количество "чакры" как из Наруто, или же имунная система)

- Любой предмет можно будет использовать для удара по цели, но без условных "знаний" или "перков навыка" удар будет стандартным образом, как если бы оружие не предполагало свойство атаковать им Сила удара будет зависеть от материала, веса, возможно обьема и силы атакующей сущности. Таким образом, чтобы использовать определённый предмет адекватным образом, нужно "знать" его работу. Возможно именно в этом ключе будут работать навыки и "перки", условные знания-умения, позволяющие так или иначе использовать предмет, извлекая из него дополнительную выгоду. Умения также могут древовидно развиваться иногда даже эволюционируя в допустим те же самые боевые искусства, которые технически, будут менять дефолтный метод взаимодействия предмета. В пример, НПС, у которого отсутствует знания об огнестреле, не сможет его использовать, а будет драться им в рукопашную. Все действия, которые можно совершить с предметом (кроме основных, типо стрельбы, или же можно даже это изменить, но выставить стрельбу как дефолтное первичное действие) будут скрыты в меню, которое открывается через R удобно будет выбрать вместо перезарядки r какое либо другое действие. В меню удара или перед атакой или стрельбой можно указывать цель на существе, но становится не понятно как действовать с целями нестандартной анатомии. Каждое существо имеет свою условную "оболочку", которая определяется мышцекостями, и служит ограничением по возможному объёму органов, будут иметься безопасный и максимальный уровни Это позволяет расхардкодить форму любого существа, позволяя менять его оболочку, или даже легко создавать существ прямо внутри игры (привет некромантия) Проблема остаётся при переопределение размеров органов. Изменение органических существ в основном будет производиться из-за мутаций (хотя кач мышц можно также учитывать, вкупе с фактом что сердце объём не меняет от этого), Тем самым изменять органы пропооционально.

- Вопрос организации активируемых способностей игрока. Технически, любое действие игрока, кроме заранее захардкоженых, можно считать активируемой способностью. Определяются и скалируются они из наличия знаний и имеющихся частей организма (бионика и мутации). То есть любая способность будет появляться только в случае, если сущность "знает" как пользоваться той или иной способностью. Из этого появляется вопрос о том, как же структурировать магию, которая технически, будет более комплексными способностями. В то же время, имеется желание отделить магическую систему от обычных способностей, при этом не создавая отдельный, захардкоженый, "висящий в воздухе" модуль.
92 572560
Я тут тоже маняфантазиями балуюсь

- Отражать скованность персонажа (от одежды), оглушённость, и невозможность двигаться параметром от 0 да 100%. От громоздкой одежды повышается скованость, также как и от допустим захвата персонажа ручками. Скованость можно распрастраняться на отдельные части тела. "Нулём" можно считать базовую скорость/ловкость персонажа, который "условно" голый. 100 процентов, это полное обездвиживание той или иной части тела.

- Обработку STЕP (каждый ход) можно проводить добавляя в массив все активные объекты в "пузыре", активные объекты будут добавляться при инциализации баббла, а также при удалении или входе в него.

- Все сущности будут иметь физические и нефизические части тела, физические условно создают простой объект среды, коих будет много, на него можно влиять снаружи и он также может влиять. Имеет параметры, и методы воздействия, засчёт как единичных органов, так и комплексных систем, которые получают свой функцинал только когда будут собраны. (Опорной двигательная, пищеварение) Также будут иметься нефизические, вероятно они будут взаимозависимы от физических, и существовать только с помощью физических свойств. Допустим условная "разумность" это блок обработки ИИ, или передача контроля сущностью игроку, которая находится в мозге. Нефизическими могут также быть любые другие объекты, которые являются более абстрактными, и не поддающиммся непосредственному обнаружению в игре (не точно). Вопрос чем это будет, просто преписываемыми к частям тела параметрами (как например душа(ии или игрок) к мозгу). Или они будут занимать не локальную позицию (аки абстрактное количество "чакры" как из Наруто, или же имунная система)

- Любой предмет можно будет использовать для удара по цели, но без условных "знаний" или "перков навыка" удар будет стандартным образом, как если бы оружие не предполагало свойство атаковать им Сила удара будет зависеть от материала, веса, возможно обьема и силы атакующей сущности. Таким образом, чтобы использовать определённый предмет адекватным образом, нужно "знать" его работу. Возможно именно в этом ключе будут работать навыки и "перки", условные знания-умения, позволяющие так или иначе использовать предмет, извлекая из него дополнительную выгоду. Умения также могут древовидно развиваться иногда даже эволюционируя в допустим те же самые боевые искусства, которые технически, будут менять дефолтный метод взаимодействия предмета. В пример, НПС, у которого отсутствует знания об огнестреле, не сможет его использовать, а будет драться им в рукопашную. Все действия, которые можно совершить с предметом (кроме основных, типо стрельбы, или же можно даже это изменить, но выставить стрельбу как дефолтное первичное действие) будут скрыты в меню, которое открывается через R удобно будет выбрать вместо перезарядки r какое либо другое действие. В меню удара или перед атакой или стрельбой можно указывать цель на существе, но становится не понятно как действовать с целями нестандартной анатомии. Каждое существо имеет свою условную "оболочку", которая определяется мышцекостями, и служит ограничением по возможному объёму органов, будут иметься безопасный и максимальный уровни Это позволяет расхардкодить форму любого существа, позволяя менять его оболочку, или даже легко создавать существ прямо внутри игры (привет некромантия) Проблема остаётся при переопределение размеров органов. Изменение органических существ в основном будет производиться из-за мутаций (хотя кач мышц можно также учитывать, вкупе с фактом что сердце объём не меняет от этого), Тем самым изменять органы пропооционально.

- Вопрос организации активируемых способностей игрока. Технически, любое действие игрока, кроме заранее захардкоженых, можно считать активируемой способностью. Определяются и скалируются они из наличия знаний и имеющихся частей организма (бионика и мутации). То есть любая способность будет появляться только в случае, если сущность "знает" как пользоваться той или иной способностью. Из этого появляется вопрос о том, как же структурировать магию, которая технически, будет более комплексными способностями. В то же время, имеется желание отделить магическую систему от обычных способностей, при этом не создавая отдельный, захардкоженый, "висящий в воздухе" модуль.
93 572678
В попенсорс будешь лить? Интересно будет сравнить подход.
94 574923
>>572678
Ты это кому?
95 606594
Вечер в хату. Не знаю, будет ли галка, но это я - ОП
Проект на c# успешно загнулся, но оставил за собой не мало опыта. Теперь мы возьмем этот опыт и запилим второй проект, но уже на typescript
96 606599
>>606594
Из прошлого проекта мы должны взять все лучшее, а именно - клеточные автоматы. Но на этот раз правила для них будут писаться не руками, а генерироваться. Возникла идея отображения характеристик и свойств объектов некой n-мерной плоскостью, по которой эти клеточные автоматы и будут передвигаться. Непонятно, конечно, как это будет выглядеть, но в голове представить это себе я могу.
97 606943
>>606594

> Не знаю, будет ли галка, но это я - ОП


Поставь в браузер куки-экспортер и носи свои куки с собой.
98 607117
>>606594
а в чём проблема, почему он просто так взял и загнулся?
99 607136
>>607117
Потому что изначально все начиналось как пет проджект для обучения сишарпу. Сишарп был выучен, работа для которой он учился выполнена и я снова вернулся на старые рельсы фронтенд разработки, а там typescript и вот это вот все. На самом деле продолжил бы, но что-то мне не очень понравилось. Не хочу лезть в c# пока дальше.
100 607286
>>607136

> сирешётка


> фронтенд


Говноед-комбо
101 607288
>>607286
Ну ты бы хоть аргументировал, друг
102 607292
>>607288
Назови хоть один успешный проект на сиришотке, кроме ебучего KSP, которое даже на топовом железе умудряется тормозить?
103 607294
>>607292
А чем мы успех измеряем? В компании где я работаю, на c# вполне приличный спрос. И продукты написанные на нем продаются. Или ты намекаешь на низкую производительность?
104 607296
>>607292

>которое даже на топовом железе умудряется тормозить


Играл на 2 ядра-2гига, чет нихуя не тормозило.
145420865324a5b407274d421fea6e8f--sad-anime-anime-guys.jpg7 Кб, 236x223
105 607298
>>606599
Зря бросил прошлый проект на с#, по второму кругу делать будет уже не так интересно + потеряется былой энтузиазм после пары недель. Выглядело между прочем не плохо, подкрутить механики, ui, и вот уже альфа рогалика готова, эх.... анон, анонович...
106 607302
>>607298
Да брось, во второй раз будет еще лучше. Тогда по сути написание кода заняло в общем всего пару дней. Остальное, это размышления, которые прекрасно лягут и по второму кругу.
107 607304
>>607292
We Happy Few
Rust
108 607306
>>607302
Ох ёёёёёё, только заметил дату создания треда, R.I.P в общем.
109 607362
Не совсем ведаю за typescript. Рзве о подойдёт для того чтобы написать более-менее оптимизированный рогуль?
110 607365
>>607362
Нет, конечно. Это говно очевидно будет безбожно глючить, как и любое приложение на js. Оп, наверное, подался в корпоративные рабы, вот и учит тайпскрипт.
111 607367
>>607365
Есть ли альтернатива typescript в мире фронтенда?
112 607371
>>607362

тайпскрипт это джаваскрипт в который добавили минимальную поддержку типов и свою собственную обёртку над прототипами ака классы помимо той что есть в последней версии джаваскрипта

в джаваскрипте ты можешь написать практически всё, я например хочу следующим проектом написать приложение для мобилок для сочинения электронной музыки лол
не очень сложное правда, все-таки поддержка звука в рн не оч.

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

мимо воннаби фронтэндер
113 607373
>>607367
скажет начальник что будешь использовать тайпскрипт значит будешь, не скажет тебя никто не заставляет
114 607374
>>607371
Ну это понятно, но как сказано выше, встаёт вопрос чисто оптимизации всего этого дела. жоваскрипт жеж.
115 607375
>>607373
А ты бы что использовал, для рогаликоварения, кресты?
116 607376
>>607373
Чет не понял посыла. А если нет начальника и нужно выбирать?
117 607377
>>607375
Анреал идеально подойдёт, советую, еще захочешь.
118 607378
>>607377
ты гониш шоле? рогалис на анриле писать, это как пытаться самокат нахуй на базе ракетного шаттла делать. + опять же в анриле много ненужного груза, а для рогаликов, если пилить прямо конкретно его, потребуется для обсчитки много ресурсов. В общем рогули писать это не игры делать, там именно движкописание важно
119 607379
>>607375
ты не понял мой пост
тайпскрипт это суперсет джаваскрипта
буквально джаваскрипт в котором ты можешь указать ожидаемый тип переменной и который будет ругаться но все равно работать если переменная окажется другого типа
он транслирует код в es5 джаваскрипт

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

>>607374
довольно быстрый язык
120 607380
>>607378
Сразу видно что ты не шаришь в анриле. Ничо, для тя поясню - внутри анрила есть 2 классные штуки, первОЯ это кресты, на них можно написать шо душе угодно, но вторая еще вкуснее и проще это блюпринты, так вот, ты идёшь, качаешь бесплатный унрил, куришь мануалы по блюпринтам, и делаешь рогалик не написав не одной строчки кода, ахуеть да? Прогресс то идёт, время дроча консолички, и все остального прошло.
121 607381
>>607376
ты знаешь в чём преимущество типизированых языков над динамическими? можно легче отловить многие невнятные баги. если твой проект сложный может оно того и стоит
122 607382
>>607380
Я знаю про это, и ты меня видать не понял. Я знаю и про бллюпринты и про встроенные кресты, конечно можно написать рогалик, никто не спорит, но суть рогаликов именно и в том, что ты полностью знаешь как у тебя код работает, ты сам подстраиваешь все обработчики и прочеее нахуй хуё моё, а тут в анриле много лишнего функционала, это просто невыгодно нахуй с точки зрения оптитмизации. Конечно если ты лепишь какую нибудь поеботу простецкую (без сложных вычислений имеется), а-ля нетхак то никаких проблем - пиши. Но попробуй тот же ДФ перенести на анрил, что то не подкасывает всё станет ещё несоразмернее хуже с оптимизоном.
123 607383
>>607380
рогалик это очень простая пошаговая игра
зачем ей фреймворк?
ее можно сделать буквально в браузере управляя дом деревом лол
124 607384
простая в визуальном плане в смысле
125 607385
>>607383
смотря какой рогалик исчо. Если добавлять симулятивности, как в теж хе ДФах или CoQ, то уже хуй там.

>>607384
ну это всё меняет
126 607386
>>607385
в дф довольно много вычислений иирк, нужен сервер и какая нибудь либа. в джаваскрипт есть биндинги к куче либ так что при желании можно хоть нейросеть прикрутить
127 607387
>>607382
1. Если ты делаешь 2Д, не 3Д, то проблем с оптимизоном в унриле у тебя не будет, вот 100%, исключение составляют лишь бесконечные циклы если ты где то проебёшься с ними.
2. Если ты знаешь, но не решаешься сделать, значит у тебя не достаточно опыта, либо предвзятое мнение и не желание разбираться в движке.
3. Судя по твоему описанию склоняюсь к тому что уаньку ты мало трогал, и не шаришь в ней, следовательно, идёшь курить мануалы по блюпринтам, это займёт максимум пару дней, и еще пару по поути.
4. Перенести ДФ как раз таки будет легко по причине того что ты видишь конечный продукт + знание механики освобождает от придумывания своей, остаётся только графон и заблюпринтить.
Всё таки советую анон покурить анрильку, думаю ты удивишься сколько всего можно сделать на ней не глюченого, если не 3Д!!

>>607383
Время 3++ в консолечке прошло, ало дядя, за тебя всё движок делает, тебе надо лишь нафантазировать механики, спиздить графон и музон, всё!
128 607388
ну в смысле сервер если это веб рогалик, но это не обязательно
129 607389
>>607387
МОжет быть я и ошибаюсь, хочу ошибалться даже. Раз ты такой ведающий, разъясни момент с оптимизацией? Это зависит исключительно от того как написан код самой игры, сложных обработчиков и процедур? Просто ДФ, как ты говоришь перенести легко относительно, никто не спорит, но меня ОЧЕНЬ заботит оптимизация игры, вот захочу я повысить количество обрабатываемых обьектов в мире даже больше чем в ДФ, и что? Насколько сам движок будет влиять? Или допустим ты если пишешь сложную логику, то надо хотя бы иметь опенсурс от анрила, чтобы понимать как те или иные функции работают, это опять же вопрос не невозможности реализовать, а оптимизации этого всего действа.
130 607392
>>607389
Насчёт оптимизации, здесь выигрывают как раз готовые движки по типу анрила, юнити, потому что за нас уже всё продумано и реализовано, и остаётся лишь курить мануалы и применять готовые решения(Не путать с тасканием ассетов!). Вот как писал анон выше, написать рогалик самому к примеру на голых плюсах, или на java, объём работы увеличивается в разы, а с ним самая важная часть, это понимание архитектуры куда, какую функцию записать, что бы определить правильную последовательность обращений из одного файла в другой и т.д, в движке же, как я упомянул раньше всё проще, многие фишки в том числе с оптимизация просто у мешаются в пару строк кода. Из минусов как многие сразу могут написать есть лишь то что закрытый код() и если захочется тонкой настройки это нэт, костыль на костыле будет получаться, Но для обычного инди девелопа идеально подходит, всё что остаётся это творить, и изредка думать над оптимизацией.
1.png63 Кб, 1920x1080
131 607393
>>607389
Если ты будешь пилить на уе4, то должен понимать, что есть просто колоссальное количество подводных камней. Текстовый вывод в консольку? Похуй, нужна видеокарта с DX11. Примитивная игра практически без логики? Похуй, твой восьмиядерный интол будет загружен на 98%. Нет контента? Похуй, билд игры будет весить не меньше гигабайта.
132 607394
>>607393
Ой пиздабол, ой пиздабол... Узнаю стандартные мантры немощного который даже не собирал билд в юньке.
133 607395
>>607394

>быстрофикс


В уиче.
134 607399
>>607392
Да, иммено, ты мне про Фому я те про Ерёму, пиание рогаликов, хардкорное, as it is вообще никак не идёт в сравнение с обычным инди деланием. Это скорее какой-то хтонический байтодрочерский процесс (немного преувеличил но ты понял), где вся архитектура перепиливается с нуля. Естесна если ты хочешь создать простенькую игру которую можно будет только условно назвать рогаликом (на деле симуляции всего и вся там конечно же не будет.), то готовые движки будет самое то. Тут же у нас идёт йобаный хардкор, с пересборкой велосипедов под езде по рельсам и воздухоплаванию одновременно.

>>607393
ЧТД.
135 607400
честно говоря я в игродвижках не разбираюсь (игры слишком долго делать есть много других интересных вещей которые можно сделать быстрее) но как давний фэн рогаликов, который даже написал раз безбиблиотечный простенький рогалик на си на анси-кодах в консоли мне сама идея что монстр вроде юнити будет использоваться для рогалика кажется кощунством лол

в рогаликах главное дизайн игры, мир, механики, генерация уровней т.е. логика, в них перемещение происходит пошагово и по фиксированной двухмерной сетке, зачем для них монстр предназначенный для сложной графики
136 607401
>>607399
эм
какая стимуляция
рогалик это в первую очередь каменный суп, адом, ангбанд с его клонами, нетхак, все такое
137 607403
>>607400
Затем чтобы довести своё поделии до альфы, а не бросить спустя пол года дрочения голого кода.
138 607404
>>607399
Ладн я понял, забей, если ты так одержим своим то лучше это и используй, если получится то супер, если нет, мб пересмотришь свои взгляды в дальнейшем.
139 607405
>>607403
ты не понимаешь, перемещение персонажа по экрану и т.п. фигня в рогалике самое простое и делается день или за несколько дней
140 607406
>>607401
ну вроде как бы и да, но мне кажется что интереснее рогалики-гиганты, типо ДФ, с его невзъебенной симуляцией каждой хуйни и дотошным вычислением всего, Катаклизм ДДА, CoQ и прочее. Мне просто лично кажется обычные-примитивные дунжон кравлеры себя уже давно изжили, и это просто мягко говоря заэбало.
141 607407
>>607405
Ох мой юный анончик, ты даже не представляешь что тебя ждёт впереди... С другой стороны, если попробуешь заниматься гей девом тебе откроется много интересного, завидую тебе даже...
142 607410
>>607406
я лично куууууда больше времени убил на дксс, адом и посченг чем на катаклизм и дф

дело вкуса, дксс вообще вызов был, я спидранил сприганнами лол
687740191365b8c17cc2b.jpg341 Кб, 1024x577
143 607412
>>607403
Считай это своеобразным естественным отбором.

>>607404
Можно сказать и да, но всё же объясни в чём проблема, Ты предлагаешь использование двиков, но я не говорю что движки это плохо, просто это немного не та сфера куда их можно применить. Так что и майкрософт ворд можно на анрил энжон ебануть, лол.

>>607410
Может быть это я просто уже изыгрался, такой метамодерн пошёл.
144 607415
>>607407
и что же? рогалик я лично написал бы браузерный без специального игрового фреймворка, что-то 2д с реалтайм перемещением наверное взял бы какой-нибудь phaser, 3д не трогал бы вообще

но повторю мне написание игр кажется тратой времени, уд слишком много людей их пишет
145 607416
>>607415
Это зависит еще от того что ты сам напишешь. Посредственностей конечно дохуя, но при этом выдающиеся вещи (если таковыю сможешь родить) в узких рогаликоведческих кругах известна будет.
146 607417
>>607415

>слишком много людей их пишет


Ты уж определись ты это делаешь ради денег? Тогда надо идти в мобилкоговно рыночек. Для хобби? Тогда пиши на чём душе угодна, когда угодна, хоть в блокноте, даже если выйдет говно, главное чтобы получалось удовольствие от процесса. Для кого-то? Небольшой публики? Тогда придётся что-то изучать, осваивать, тратить время на не интересные вещи, но нужны для прогресса и понимания.
147 607808
>>572542

>спрайты выполнены в размере 21x21


Почему именно этот размер?
148 607937
>>562448
всегда ору с ооп фанатов и их любви делать классы

>У меня есть базовый класс "иди нахуй", в котором очень много витиеватого трёхэтажного кода, написанного много раз.


>Теперь, чтобы послать нахуй залётного ЕЦС-чушкана, мне достаточно просто сконструировать класс с инициализатором. И это всё одной строкой!


>var посыл = ИдиНахуй.new(){КогоПослать = "ЕЦС-чушкан"}


зачем для этого класс?
const Посыл = require('./посылы/Посыл'); //ты эту часть вообще упустил где у тебя код базового класса хранится
const посылЕЦС = Посыл.кого("ЕЦС-чушкан");
все. никаких конструкторов. никаких классов на пустом месте

>Далее, если мне нужно плотно работать с чушканом (если он с первого раза не понял), я >могу унаследоваться от базового класса:


>class ИдиНахуйЕЦСЧушкан : ИдиНахуй { КогоПослать = "ЕЦС-чушкан" }


>И далее, просто конструировать класс-потомок.


можно сделать обертку с дефолтным значением аргумента
function ИдиНахуй(КогоПослать = "ЕЦС-чушкан") {
const Посыл = require('./посылы/Посыл');
return Посыл.кого(КогоПослать);
}
никакого говнонаследования
149 607940
>>571236

>Насколько я знаю, машин лёрнинг пока можно обучать в очень узких специальностях. Может быть можно написать площадку с группой юинтов А, и одним юнитом Б, и их обучать убиению друг друга, тренируя pathfinding и стратегию, хотя я честно не уверен насколько это возможно.


я скорее не вижу зачем это надо
можно запилить очень эффективное ай без мл см. sil
может с помощью мл можно запилить еще более умных мобов, но... советую поиграть в sil, умные мобы напрягают, конкретно умные мобы будут напрягать конкретно

>>572335
обычно это делается просто через систему видимости (самая простая это конечно сделать левел полностью видимым). она может быть симметричной как в dcss и асимметричной как в *бандах например. симметричная видимость очень забавная вещь кстати, не знаю пофиксили ее или нет, но в dcss некоторые люди проходили игру специально уменьшив себе видимость артифактом - это соответственно уменьшало видимость монстров и делало их слепыми лол. все равно как гулять в клочке тумана. ну и помимо видимости добавляют еще всякое экстрасенсорное восприятие, дрожь поверхности, запах и т.п. чему не мешают стены

>>572531
как насчет сделать функцию/класс/назови как хочешь которая будет вычислять что видит монстр которого ей передали как аргумент и его реакцию в зависимости от флагов самого монстра и уровня который тоже в нее предан как аргумент. возвращать будет движение монстра. просто первое что в голову пришло

>>572542
такая генерация уровней годится только для некоторых открытых уровней имо, надо однозначно сделать и другие уровни, более закрытые, иначе игра будет сплошные разборки со стаями мобов без какой-то особой тактики связанной с местностью. двери нужны кстати. алсо это не пещера а какой-то торговый центр лол

интерфейс странный - на не полностью открытой карте у тебя справа информация о персонаже, а на полностью открытой ее нет. карту нельзя открыть полностью чтоле?

стены надо однозначно темнее

у самого верхнего торговца левый верхний сундук это мимик? если нет, то у тебя наложилось два тайла
149 607940
>>571236

>Насколько я знаю, машин лёрнинг пока можно обучать в очень узких специальностях. Может быть можно написать площадку с группой юинтов А, и одним юнитом Б, и их обучать убиению друг друга, тренируя pathfinding и стратегию, хотя я честно не уверен насколько это возможно.


я скорее не вижу зачем это надо
можно запилить очень эффективное ай без мл см. sil
может с помощью мл можно запилить еще более умных мобов, но... советую поиграть в sil, умные мобы напрягают, конкретно умные мобы будут напрягать конкретно

>>572335
обычно это делается просто через систему видимости (самая простая это конечно сделать левел полностью видимым). она может быть симметричной как в dcss и асимметричной как в *бандах например. симметричная видимость очень забавная вещь кстати, не знаю пофиксили ее или нет, но в dcss некоторые люди проходили игру специально уменьшив себе видимость артифактом - это соответственно уменьшало видимость монстров и делало их слепыми лол. все равно как гулять в клочке тумана. ну и помимо видимости добавляют еще всякое экстрасенсорное восприятие, дрожь поверхности, запах и т.п. чему не мешают стены

>>572531
как насчет сделать функцию/класс/назови как хочешь которая будет вычислять что видит монстр которого ей передали как аргумент и его реакцию в зависимости от флагов самого монстра и уровня который тоже в нее предан как аргумент. возвращать будет движение монстра. просто первое что в голову пришло

>>572542
такая генерация уровней годится только для некоторых открытых уровней имо, надо однозначно сделать и другие уровни, более закрытые, иначе игра будет сплошные разборки со стаями мобов без какой-то особой тактики связанной с местностью. двери нужны кстати. алсо это не пещера а какой-то торговый центр лол

интерфейс странный - на не полностью открытой карте у тебя справа информация о персонаже, а на полностью открытой ее нет. карту нельзя открыть полностью чтоле?

стены надо однозначно темнее

у самого верхнего торговца левый верхний сундук это мимик? если нет, то у тебя наложилось два тайла
150 607967
>>562309

>запускаем сценку из десятка символов несколько секунд


Обмяк с производительности C#.
151 607968
>>558364
Сейчас бы разделять игрока и врагов в рогалике. Все живые существа должны быть частью симуляции и работать по одним правилам.
Поэтому во всех трушных рогаликах игрок и враг это один и тот же класс, они имеют одинаковые параметры, атрибуты, инвентари, и различаются только тем, что игрок управляется через контроллер игрока, враг - через контроллер AI, который посылает по сути те же команды, что и игрок с клавиатуры. Так везде, от dungeon crawl'a до катаклизма.
152 607970
>>607968
Нет, маня, ты не права. Логика врагов основывается на алгоритмах (поиск пути, таргетирование и т.д.), а логика игрока - на том, что у него вместо мозгов в башке. Соотвественно, классы априори уже не могут быть идентичны. Ну или могут, но это будет уже как консируктор солянки. Залупа в общем конская.
153 607974
>>607367
C++, SDL, emscripten.
>>607386

>что при желании можно хоть нейросеть прикрутить


А машинное обучение с бигдатой на блокчейне можно прикрутить, чтобы побыстрее работало? Что ты несешь, дурачок?
>>607392

>Насчёт оптимизации, здесь выигрывают как раз готовые движки по типу анрила, юнити, потому что за нас уже всё продумано и реализовано,


Продуман и реализован движок общего назначения, цель которого покрыть любую возможную разновидность игр. Используя тот же юнити для рогалика, ты будешь юзать 5% от его фич, а остальные фичи будут висеть мертвым грузом в дистрибутиве, ветвлениями в коде. Кастомный движок, написаный с нуля под конкретный набор фич ВСЕГДА разносит по перфомансу и размеру дистрибутива движок общего назначения. На юнити твой рогалик будет весить 200 Мб и позволять обрабатывать 1000 юнитов без просадки фпс, на голых плюсах это будет 10 мегабайт и десятки/сотни тысяч, зависит от твоего скилла и подхода к работе с данными. Чем меньше абстракций, ООП, паттернов, уровней наследования юзается - тем выше перфоманс. На ecs с хитрыми оптимизациями симулировать сотни тысяч сущностей вообще не проблема, даже на не самом топовом железе.
>>607970
Маня, ты путаешь класс персонажа и контроллер персонажа. Сваливать обработку ввода и симуляцию персонажа в один класс это первый признак говноархитектуры, это еще в конце 90х поняли и уже в первом анриле был отдельно Pawn, класс персонажа, и контроллеры PlayerController и AiController, которые работают с одним и тем же персонажем, просто по-разному его контролируют. Персонаж содержит все данные, здоровье, опыт, скиллы, инвентарь, и базовую логику взаимодействия, идти вперед, перейти в точку, атаковать. А контроллер отвечает именно за управление, обработку ввода.
На ecs это элементарно реализуется, контроллер подключается как отдельный компонент и управляет связанным с ним персонажем. В случае контроллера игрока он ловит ввод с клавиатуры, AI контроллер как раз определяет цель и строит путь. С таким унифицированным подходом легко реализовать переселение души, например, просто переключаешь компонент с одного персонажа на другого, и ты можешь управлять уже врагом (либо одним из своих юнитов). Либо наоборот, перевести своего персонажа в режим ИИ, чтобы он автоматом бегал по уровню и дрался.
В ООП это тоже просто делается через агрегацию.
А залупа конская у тебя вместо мозга, похоже.
153 607974
>>607367
C++, SDL, emscripten.
>>607386

>что при желании можно хоть нейросеть прикрутить


А машинное обучение с бигдатой на блокчейне можно прикрутить, чтобы побыстрее работало? Что ты несешь, дурачок?
>>607392

>Насчёт оптимизации, здесь выигрывают как раз готовые движки по типу анрила, юнити, потому что за нас уже всё продумано и реализовано,


Продуман и реализован движок общего назначения, цель которого покрыть любую возможную разновидность игр. Используя тот же юнити для рогалика, ты будешь юзать 5% от его фич, а остальные фичи будут висеть мертвым грузом в дистрибутиве, ветвлениями в коде. Кастомный движок, написаный с нуля под конкретный набор фич ВСЕГДА разносит по перфомансу и размеру дистрибутива движок общего назначения. На юнити твой рогалик будет весить 200 Мб и позволять обрабатывать 1000 юнитов без просадки фпс, на голых плюсах это будет 10 мегабайт и десятки/сотни тысяч, зависит от твоего скилла и подхода к работе с данными. Чем меньше абстракций, ООП, паттернов, уровней наследования юзается - тем выше перфоманс. На ecs с хитрыми оптимизациями симулировать сотни тысяч сущностей вообще не проблема, даже на не самом топовом железе.
>>607970
Маня, ты путаешь класс персонажа и контроллер персонажа. Сваливать обработку ввода и симуляцию персонажа в один класс это первый признак говноархитектуры, это еще в конце 90х поняли и уже в первом анриле был отдельно Pawn, класс персонажа, и контроллеры PlayerController и AiController, которые работают с одним и тем же персонажем, просто по-разному его контролируют. Персонаж содержит все данные, здоровье, опыт, скиллы, инвентарь, и базовую логику взаимодействия, идти вперед, перейти в точку, атаковать. А контроллер отвечает именно за управление, обработку ввода.
На ecs это элементарно реализуется, контроллер подключается как отдельный компонент и управляет связанным с ним персонажем. В случае контроллера игрока он ловит ввод с клавиатуры, AI контроллер как раз определяет цель и строит путь. С таким унифицированным подходом легко реализовать переселение души, например, просто переключаешь компонент с одного персонажа на другого, и ты можешь управлять уже врагом (либо одним из своих юнитов). Либо наоборот, перевести своего персонажа в режим ИИ, чтобы он автоматом бегал по уровню и дрался.
В ООП это тоже просто делается через агрегацию.
А залупа конская у тебя вместо мозга, похоже.
154 607975
вообще одна из самых сложных вещей это время
рогалики конечно пошаговые, но если каждое действие будет отбирать один ход и у всех одна скорость игра будет унылая
тогда как сделать фракционные ходы совсем не просто

>>607968
не совсем так
в адоме раньше когда он собственно и обрёл свою популярность не было инвентаря у мобов например в отличие от игрока
впрочем учитывая что он написан на си там и класса моб наверняка нет и не было лол, хотя объекты в си конечно есть и даже можно методы им приделать

>>607970
чушь какая
см. выше я уже написал как это легко делается функцией которой скармливают объекты мобов
155 607979
>>607974
у джаваскрипта есть биндинг к tensorflow
чем он хуже пистона в конце концов
156 608010
>>607974

>а остальные фичи будут висеть мертвым грузом в дистрибутиве, ветвлениями в коде.


Опять это шизик таблетки не принял.
157 608102
>>607967
Сборка же
dz.png193 Кб, 1024x576
158 608105
>>607974
Всё намного проще, из 100 велосипедистов 1 сделает игру, ну допустим немного другие числа 95/5 и т.д, есть шанс что это будешь ты, но намного больше шансов, что ты забросишь свою разработку, своего уникального движка, всё. Вывод прост, не надо делать велосипед когда ты ставишь себе цель что-то выпустить, а не кодить ради удовольствия.
159 608139
>>608105
ты просто не разбираешься в рогаликах
с одной стороны они достаточно простые в плане графики
с другой их фишкой являются особенности механики
в итоге их сплошь и рядом пишут без фреймворков или со специализированными фреймворками вроде ncurses и libtcod
160 608234
>>608105
Пилили же рогалики десятилетиями до выхода юнитей, и сейчас продолжают пилить, не переживай. Все знаковые рогалики от кравла до катаклизма - на кастомных движках.
Можешь сколько угодно оправдывать своё нежелание писать код, просто скорее всего разработка рогаликов - не твоё. Скачай юнити, таскай ассеты по сценке, сделай шедевр и спокойно продавай его в стиме. А хадркодную разработку оставь увлеченным ребятам.
161 608242
>>608139
>>608234
Вы же сами отвечаете на свои вопросы, сколько десятков, сотен тысяч людей по всему миру вдохновлялись этими десятками тех у кого получилось что либо сделать? Цифры же сами за себя говорят, ~100 рогаликов против ~100.000 тех кто слились, понимаете?
162 608258
>>608242
И что? А ты живешь в сказочном маня-мире, где у всех всё получается и все обязательно приходят к успеху?
Ты в курсе, что в любой деятельности так? 100 крутых музыкантов на 100.000 тех, кто взял в руки гитару, но так и не научился играть. 100 миллионеров на 100.000 нищебродов. 100 успешных юнити-проектов на 100.000 тех, кто скачал юнити, потаскал ассеты по сценке и забил.
Добро пожаловать в реальность, Мань. Пытаются многие, получается у единиц, обладающих специфическими качествами - упорством, силой воли, те кто на самом деле горят и кого не останавливают трудности.
Если человек хочет запилить рогалик, игру, которая на 99% состоит из кода и алгоритмов, но при этом его пугает необходимость написать немного кода своими руками - он уже опустился и проиграл, даже не попробовав.
163 608259
>>608258
Маня тут только ты, мы пришли к цифрам потому что я привёл как пример что шанс придти к успеху выше в 90-95% у тех кто пользуется готовыми материалами(движками), а не кодит всё с нуля. А ты приводишь в пример из общего числа тех кто лишь попытался, это не верно.
164 608269
>>608259

>90-95%


Цифры из своего маня-мирка взял? Или это тебе маркетологи юнити внушили, чтобы ты продлял ежемесячную подписку?
Для рогаликов готовый движок не нужен, фреймворк для вывода буковок/тайлов по сетке напишет студент-первокурсник за пару вечеров. А дальше начинается уже симуляция мира самой игры, которую в любом случае предстоит писать, даже с готовым движком.
А вероятность успеха зависит не от выбора движка/написания своего, а от кучи других факторов. Тот, кто может - сможет и на готовом движке, и на своём, его не остановят трудности и необходимость что-то изучить. Тот, кто изначально ставит себя в положение опущенного, признавая, что ему не по силам писать код и хочет готовенькое - тот скорее всего не сможет ничего сделать и на готовом движке, потому что при разработке будет куча проблем, требующих алгоритмической подготовки для их решения, а нежная манька код писать не приучена.
165 608272
>>608269
Хорошо, ты меня убедил, победа твоя, ты прав. Удаляюсь из треда. Даже не знаю, спойлер так для прикола короч
166 608275
>>608272
чувак, но он прав. рогалики это игры которые пилятся не ради выстреливания, а ради процесса, к тому же использование двигла в среде рогаликоделов скорее моветон.
это всё, разумеется, в силе ровно до тех пор пока ты не решишь делать на них деньги
167 608278
>>608275
Да понял я, понял, уже обоссался и спрятался в уголку.
168 608283
>>608258
В Японии не так, ты занимаешься всю жизнь одним делом, причем скорее всего семейным, которым твой отец и дед занимались, и добиваешься успеха. Если ты художник - ты становишься успешным мангакой и рисуешь аниме. Если ты музыкант - сочиняешь для них опенинги. Только программисты почему-то из японцев хуевые выходят, наверное не было в роду.
169 608290
>>608269
Движок решает совершенно конкретные проблемы и задачи. А именно работу с железом - с тысячами моделей видеокарт со своими тараканами, с сотнями разных дистрибутивов линукса и с десятками версий винды. Те кто отказываются от движка, берут на себя работу пройти весь этот путь по граблям заново и сжечь задницу нахуй.
Да, успешные рогалики были сделаны на самописных движках, потому что они были успешны лет за 20 до появления юнити.
170 608300
>>608283
японец руби создал

>>608275
если взять коммерческие то.. адом - самописный, томе4 - самописный, даже какой нибудь данжн оф дредмор кастомный движок

>>608290
эти проблемы решает среда разработки а не игровой движок лол. игровой движок в основном отвечает за сложную графику и физику, потому он и не интересен особо
171 608304
>>608290

>А именно работу с железом - с тысячами моделей видеокарт со своими тараканами,


DirectX (Direct3d, XAudio, XInput)

>с сотнями разных дистрибутивов линукса


Линукс не нужен
172 608331
>>572542

>спрайты выполнены в размере 21x21


Еще раз спрашиваю. Почему такой странный размер тайлов?
173 608332
>>608300

>японец руби создал


Только подтверждает, лол. Руби на момент создания - ужасно всратый язык.
174 608333
>>608304

>DirectX


Это не гарантирует ни то, что ты на нем сможешь нормально окно инициализировать (учитывая всякие нюансы вроде второго монитора), ни то, что не объебешься где-то в вызовах апи или шейдерах.
175 608338
>>608333
>>608290
Вот это дивный маня-мир, давно такого не встречал.
Ты правда думаешь, что при разработке без движка тебе нужно писать код отдельно для каждой из существующих видеокарт?
Ты вообще не представляешь, что такое кросс-платформенная разработка?
Ты берешь либу типа SDL/GLFW и одной строчкой получаешь окошко с контекстом opengl нужной версии. Под любую систему, от кофеварки до телефона, не говоря про десктопы. Ты даже можешь взять bgfx в качестве абстракции графического апи, на винде он будет компилиться под directx, на линуксе/мобилках - под opengl.
Ты пишешь код один раз, и потом компилишь его без изменений под любую платформу. Версий винды не десятки, на дистрибутивы тоже поебать. В 2к19 достаточно одного билда статического бинарника под x64 шин и одного под x64 линукс. Всё.
Вылезай из маня-мира. А то как-то неудобно получается, убеждаешь всех, что без движка невозможно разрабатывать, но при этом фантазируешь, что там надо писать код под тысячи видеокарт. Зачем фантазировать, если ты не пробовал?
176 608341
>>608338

>Ты правда думаешь, что при разработке без движка тебе нужно писать код отдельно для каждой из существующих видеокарт?


Да, тебе будет нужно учитывать НЮАНСЫ для каждой из существующих видеокарт.
Для того, чтобы ты понимал, отсылаю к блеклисту хрома. А это всего лишь рендер текста и картиночек.
https://chromium.googlesource.com/chromium/src/gpu/+/master/config/software_rendering_list.json

>Ты даже можешь взять bgfx


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

>Версий винды не десятки,


Ну конечно, что еще спизданешь? Для XP и для 10-ки нужны разные сборки, более того, в 10-ке есть разные билды, и иногда софт для новых не работает в старых.

>на дистрибутивы тоже поебать.


Нинужно, ясно-понятно. Бонусом у тебя не будет видимо и андроид версий, тоже нинужно.

>А то как-то неудобно получается, убеждаешь всех, что без движка невозможно разрабатывать, но при этом фантазируешь, что там надо писать код под тысячи видеокарт.


Ну если тебе хочется вместо работы над игрой исправлять баги связанные с видеокартами, потому что тебе весь стим засрут отрицательными отзывами не работает - вперед и с песней.
177 608344
блин какая фигня

вот смотри
https://jsfiddle.net/690wuLxa/

это набросок рогалика, я набросал сегодня под влиянием треда. в нем 135 строк кода. можно ходить кроме стен во всех восьми направлениях, можно убить беззащитного монстра и условно собрать лут. алсо удобный ручной левел редактор прямо в том же флаконе лол. дальше можно было бы запилить видимость и небольшую прокрутку экрана например и все такое

чисто как иллюстрация - он будет работать на любом девайсе который поддерживает современный браузер и десктопную клавиатуру. какие нюансы какие нафиг видеокарты лол. я вообще смутно представляю что такое видеокарта. если бы jsfiddle лучше поддерживал мобилки я бы не поленился сделал бы и поддержку таучскринов
178 608345
>>608341

>XP


>2k19


Ну-ну.

>Нинужно, ясно-понятно.


Нинужно потому, что один статический билд под линукс x64 работает на любом дистрибутиве.

>ля того, чтобы ты понимал, отсылаю к блеклисту хрома.


Сейчас бы сравнивать рендер браузера и рогалика.

>Ну если тебе хочется вместо работы над игрой исправлять баги связанные с видеокартами


Опять пошли маня-фантазии. Ни одной программы не написал, зато испугался багов с видеокартами.
Все правильно пишешь, сложна, нивазможна, даже не пробуй ничего писать сам, если пускаешь жидкую подливу в штаны от одних маня-фантазий, даже не написав ни строчки кода. Видимо геймдев это в целом не твоё.
Возьмешь вот юнити тот же, начнешь что-то пилить и наткнешься на какой-нибудь баг в ui подсистеме, сразу пукнешь в штаны. А если краш словишь, вдруг еще сердце не выдержит от испуга.
179 608347
и да, тайлы тоже несложно прикрутить при желании
180 608351
>>608345

>XP


>2k19


Рогалики всегда славились тем, что могут работать даже в терминале, даже в досе, а твой не может работать нигде ниже win7/10 - вот это реально "ну-ну". Вопрос - а нахуя такой самописный движок нужен тогда?

> один статический билд под линукс x64 работает на любом дистрибутиве.


Линуксоиды тебе просто у виска пальцем покрутят, ну да ладно, линукс же нинужно.

>Сейчас бы сравнивать рендер браузера и рогалика.


И что же в них такого, почему их нельзя сравнивать? Картинки и текст там и там.

> Ни одной программы не написал, зато испугался багов с видеокартами.


>пускаешь жидкую подливу в штаны от одних маня-фантазий, даже не написав ни строчки кода.


Ну все пошли проекции. Иди пиши движки, в /pr например, никто тебе не запрещает. А тут люди игры делают.
181 608352
>>608344
Браузерка это конечно вариант.
Там, естественно, будут свои проблемы, не с видеокартами, а с браузерами. Например, с тем же масштабированием игры под размер окна. Или чтобы работало во всех браузерах, на разных мобильных устройствах, с разным увеличением шрифта, с разным адблоками, и т.д. (уже предвижу нинужно)
182 608353
>>608351

>Рогалики всегда славились тем


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

>Иди пиши движки, в /pr например, никто тебе не запрещает.


НИКТО ТЕБЕ НЕ ЗАПРЕЩАЕТ
@
[ЗАПРЕЩАЕТ]


В голос, какой же кал у тебя в голове

мимо
183 608354
>>608353
Шизик, таблеточки попей.
184 608355
>>608354
То есть аргументов в пользу своей точки зрения у тебя нет, правильно понимаю?
185 608356
>>608355
Ты блядь поехавший нахуй, ты просто высрал рандомные слова, а аргументы требуешь с меня, проорал.
186 608359
>>608356
А, ну так ты сразу бы сказал, что тупой. Давай объясню:
1. То, что рогалики «всегда славились» тем что запускаются даже в терминале, это вообще ничего не значит. Ради примера я привёл тебе маргиналов, которые точно так же носят как и ты, одежду, и обувь, но это не делает тебя таким же маргиналом, ведь нужны какие-то более конкретные признаки. В случае с рогаликами, это берлинская интерпретация (о терминале там ни слова)
2. В одном и том же предложении ты запрещаешь (якобы написание игрового движка, это видите ли не написание самой игры) и сразу же пишешь «никто тебе не запрещает»
187 608365
>>608359
Ты наверное первокурсник или что-то типа того, короче молодой еще и аутично все воспринимаешь буквально. ну давай смахнемся.
1. Рогалики в терминале - это не маргинальность, а мейнстрим. Возможно ты называешь рогаликами рогалайты, но это уже твоя проблема, поскольку у рогаликов довольно четкое определение. И большинство топовых рогаликов запускается в терминале (brogue, dcss, nethack, adom и т.д.)
2. Вот именно что никто ему не запрещает, я же прямым текстом говорю флаг в руки, пиши движок и трать на его поддержку больше времени, чем на написание игры на готовом движке, кто против то? Покажи в каком посте я написал "не сметь, запрещено, не имеешь право" и я сожру какое-нибудь гавно с пруфами.
188 608366
>>608365

>Вот именно что никто ему не запрещает, я же прямым текстом говорю флаг в руки, пиши движок и трать на его поддержку больше времени, чем на написание игры на готовом движке, кто против то? Покажи в каком посте я написал "не сметь, запрещено, не имеешь право" и я сожру какое-нибудь гавно с пруфами.


Вот тебе тобой же написанный текст:

>Ну все пошли проекции. Иди пиши движки, в /pr например, никто тебе не запрещает. А тут люди игры делают.


то есть ты буквально говоришь человеку уйти в другой раздел, потому что «тут люди игры делают»
189 608368
>>608365

>Возможно ты называешь рогаликами рогалайты


А это не одно и то же? Можно объяснения по этому поводу?
190 608370
>>608366

>никто тебе не запрещает

191 608371
>>608370
Никто не запрещает ему в /pr писать движки, а тут запрещают, потому что «тут люди игры делают. На структуру предложения посмотри, даун. Ты либо тупой настолько, что не смог предложение правильно построить, либо не очень, но все же тупой, ведь сейчас так тухло увиливаешь
192 608372
>>608368
Немного лень, вон анон выше писал про берлинскую интерпретацию, можно сказать так: была игра rogue, рогалики это rogue-like, т.е. похожие на нее, а roguelite это roguelike-like, т.е. похожие на рогалик, но не имеющие каких то ключевых моментов, или слишком сильно изменившие механику или дизайн.
Например, Faster Than Lite часто записывают в рогалики, но ведь всем понятно что это не рогалик, ты же не чистишь пещеры, лол. Это чисто маркетинг.
193 608373
>>608371
Предложение составлено тонко, а в том что ты его так интерпретируешь виноват только ты сам :3 Нигде не сказано что движки делают только в /pr.
194 608374
>>608372
Ссылочку на требования поддержки терминала, плиз
195 608375
>>608371

>а тут запрещают,


>тут


Кстати ты тож маневрируешь, изначально то ты утверждал что "вообще" запрещают.
196 608376
>>608373

>Нигде не сказано что движки делают только в /pr.


Достаточно того, что сказано, что их не делают в gd
197 608377
>>608374
Ты уже дрожащими руками промахиваешься кому ответить?
198 608396
>>607974

>На ecs с хитрыми оптимизациями симулировать сотни тысяч сущностей вообще не проблема, даже на не самом топовом железе.



Ебать, поясни конкретнее, такое рил возможно? Вот захочу я въебать овер 100 сущностей на карте, у каждого из которых будет свои инвентари и сложная анатомия, разве это возможно чтобы двигло и проц эту всю хуйню вывозили? я просто смотрю на те же Дварф фортерсы и котяклизьмы, там что-то подобных совсем не пахнет.
199 608415
>>608352

я выше писал что проблемы с железом решает среда. это не уникально для браузерки, например пишешь под андроид их решили бы андроид специфичные библиотеки. это слишком низкоуровневые проблемы чтобы большинству кодеров интересоваться ими

> Например, с тем же масштабированием игры под размер окна.


>с разным увеличением шрифта



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

>Или чтобы работало во всех браузерах



будет. я написал сейчас в es6, он поддерживается всеми браузерами кроме осла, но совсем несложно транслировать в es5 и поддержать даже дрова мамонта

>на разных мобильных устройствах



для поддержки мобилок надо всего лишь добавить поддержку таучскринов, это несложно, ещё один ивент листенер, надо только придумать как именно юзер будет использовать пальцы, т.к. просто таскать героя по экрану пальцем ему конечно нельзя позволять, надо или регистрировать пуш и вычислять в какую сторону двинуть героя чтобы он шёл к точке пуша, или делать дрэг не более чем на а одну клетку за раз, или делать визуальные кнопочки перемещения для мобилок (для действий все-равно придётся т.к. мобильные клавиатуры не фигачат кейдаун ивенты)

>с разным адблоками, и т.д.



вот, это проблема, но её никакой игровой фреймворк не решит, монетизировать браузерный рогалик наверное сложно. можно сделать отслеживалку адблока, которая лочила бы страницу с просьбой отключить адблок, боюсь так можно многих распугать, плюс надо платить за сервер и все равно много не набежит, наверное

для монетизации я бы в react native скорее писал бы и выложил в гугл плей
200 608418
>>608415

>это слишком низкоуровневые проблемы чтобы большинству кодеров интересоваться ими


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

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


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

>я написал сейчас в es6, он поддерживается всеми браузерами


Смотря каких фич ты туда надобавляешь, например нет гарантии что это будет работать на встроенном браузере андроида 4.4

>для поддержки мобилок надо всего лишь добавить


Не только, например еще придется повоевать с вылезающими тулбарами сверху и снизу.

>монетизировать


А я не в плане монетизации говорил, а в плане технической работы, у разных людей в разных браузерах стоят разные дополнения, которые могут резать всякий контент от чего верстка поедет.
201 608419
>>608396
я видел сотни существ на карте и достаточно сложных хотя анатомии у них толком не было иирк. инвентари, куча скиллов и итемов и они друг с другом дрались ещё под управлением компьютера

incursion та же

только все шансы что на плюсах это у тебя будет течь и глючить как все та же incursion
202 608423
>>608419
А при чём тут плюсы, если не секрет? Может это просто скорее вопрос оптимизации, кода?
203 608426
>>608423
мне показалось тот анон который интересуется сложной симуляцией - плюсовик и я его предупреждаю что на плюсах это может быть непросто, это сложный язык
204 608428
>>608426
Если брать с++11 и делать без raw указателей, то не так уж и страшно в наши дни.
205 608437
>>608426
Да, это я, и я предполагал С++, но я подводных не знаю. В каком образе он непростой? И ты можешь порекомендовать что-то лучше?
206 608454
>>608351

> а твой не может работать нигде ниже win7/10 - вот это реально "ну-ну".


Схуяли? Как раз таки рогалик на моём самописном движке сможет работать где угодно. Я могу запилить логику в бэкенде + фроненд под терминал, под дос, подо что угодно. Могу поддерживать любые системы.
А на готовом движке ты соснешь хуйца, тот же юнити под xp без костылей не заведется, насколько знаю.
207 608456
>>608351

>Линуксоиды тебе просто у виска пальцем покрутят, ну да ладно, линукс же нинужно.


Спешите видеть, манька не знает, что такое статическая линковка. И линукс наверное видела только на картинках. Зато с умным видом кудахтает что-то от имени линуксоидов.

>И что же в них такого, почему их нельзя сравнивать? Картинки и текст там и там.


Потому что это абсолютно разные по сложности, объему и принципу работы вещи, в принципе не сравниваемые. Рендер браузера во много раз сложнее рендера любой 2д игры, не обязательно текстовой, dom-дерево отрендерить со всеми css правилами это не хуй собачий.
В общем, можешь продолжать подливиться и дристать себе на лицо, но посоветую тебе проследовать в юнити тред и там кудахтать.
208 608457
>>608365

>И большинство топовых рогаликов запускается в терминале


>чем на написание игры на готовом движке, кто против то


Боюсь спросить, как ты собрался рогалик на юнити запускать в терминале.
209 608458
>>608437
Если хочешь по хардкору упороться, то для рогалика с тяжелой симуляцией мира rust лучше С++ по всем параметрам.
Там в принципе невозможен ряд проблем, которые бывают с плюсами - утечки памяти, сегфолты. При этом, код летает так же быстро. Но придется вложить время в изучение.
210 608460
>>608437

>С++, но я подводных не знаю.


Тяжело тогда придется.

>можешь порекомендовать что-то лучше?


Самые быстрые языки это C/C++/Rust. Но они и сложные.
А из остальных пофиг что брать, C#/Java/Go/JS/Swift они там примерно одинаковы по скорости. Только питон медленнее.
211 608461
>>608454
Вот когда напишешь и отладишь под все платформы, тогда и приходи. Может поддерживать он, лол.
212 608462
>>608461
А ты когда на готовом движке сделаешь хоть что-то, тоже приходи.
213 608463
>>608458

>Там в принципе невозможен ряд проблем, которые бывают с плюсами - утечки памяти, сегфолты


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

мимо другой анон
214 608464
>>608456

>Спешите видеть, манька не знает, что такое статическая линковка.


Ты прям все ядро с собой прилинкуешь, и никаких системных вызовов делать не будешь, а рисовать и ввод делать будет святой дух, ясно-понятно. Если бы все было так просто как ты говоришь, то всякие вальвы бы так и релизили, но однако же это так не работает.

>Потому что это абсолютно разные по сложности, объему и принципу работы вещи, в принципе не сравниваемые.


Нет, это не так.

>. Рендер браузера во много раз сложнее рендера любой 2д игры


Нет, не сложнее, 2д игры это несколько слоев с разным параллаксом, динамическое освещение, деревья сцен и объектов, ровно то же самое.

> dom-дерево отрендерить со всеми css правилами это не хуй собачий.


А вот это показывает, что ты тупой даун и вообще не понимаешь, о чем шла речь. Я где-то писал о разборе dom и css? Нет, я писал только о том, что когда рендерят то, что уже разобрано, в opengl и подобном, глючит на реальном железе и драйверах.
Свободен.
215 608465
>>608463
Это пиздец ебанутый язык, тебе там придется управлять временем жизни, и уговаривать компилятор собрать хоть что нибудь, короче мем уровня хаскеля, делать на нем конечно ничего не возможно, а учить наверное дольше чем c++ раз в 10.
216 608469
>>608465

>делать на нем конечно ничего не возможно


Ну да, а посоны-то и не знали. Уже овердохуя компаний юзает его в продакшене.
https://www.rust-lang.org/production/users

>Это пиздец ебанутый язык


Я так понял, что для тебя всё, что не юнити и все, где нельзя таскать ассеты по сценке - пиздец ебанутое. Можешь не продолжать.
>>608464

>Ты прям все ядро с собой прилинкуешь, и никаких системных вызовов делать не будешь, а рисовать и ввод делать будет святой дух, ясно-понятно.


Я даже разбирать это не буду, бред шизофреника, видевшего линукс только на картинке и не понимающего смысла слов, которые он пишет.
Вот тебе пример статического бинарника, который просто качается и запускается на любом дистрибутиве.
https://godotengine.org/download/linux

>Нет, это не так.


Нет, это так. Можешь посмотреть исходники какого-нибудь хромиума, там один рендеринг по объему кода больше чем весь условный годот.

>Нет, не сложнее, 2д игры это несколько слоев с разным параллаксом, динамическое освещение, деревья сцен и объектов, ровно то же самое.


А вот это показывает, что ты тупой даун и вообще не понимаешь, о чем шла речь. Я где-то писал о разборе слоёв и паралакса, и дерева сцен? Нет, я писал только о том, что когда рендерят то, что уже разобрано, в opengl и подобном, глючит на реальном железе и драйверах.
В общем, обдристался ты знатно, лучше не продолжай дальше позориться.
Не переживай, это анонимный форум, никто не запомнит твой обсёр, так что можешь расслабиться и перестать усираться в ответ.
217 608470
>>608469

>Ну да, а посоны-то и не знали. Уже овердохуя компаний юзает его в продакшене.


Его юзают професси_аналы с з/п от 200к рублей, причем тут 2ch gd?
218 608471
>>608470
звучит как повод выучить раст лол

вангую впрочем что туда сложно вкатиться и большинство борщехлебы на низкой зп
219 608472
>>608470
Ну ты изначально спизданул что-то про язык-мем и что на нём ничего нельзя сделать, а теперь пытаешься оправдаться и соскочить за счет того, что на 2ch gd не может сидеть профессиональный программист.
220 608475
>>608471
Раст для вката в айти не подходит, никому джуны на расте не нужны, его юзают как второй язык бэкендщики с опытом, когда у плюсов не хватает безопасности, а у какой-нибудь джавы скорости.
А для программирования для души он отлично подходит, в том числе и для геймдева. Много обучающих материалов, удобная экосистема, пакетный менеджер.
221 608476
>>608471
Выучи, если сможешь. Там и игровые движки уже есть так то.
222 608477
>>608472
Так и на Хаскеле несколько человек в мире пишет всякую телефонию, но для большинства он иначе как мемом не является.
223 608481
>>608477

>приравнивать несколько человек и несколько сотен компаний уровня mozilla, dropbox, atlassian, cloudflare, npm


Я надеюсь, что это троллинг тупостью, потому что если у тебя на полном серьёзе такое в голове, то это даже немного грустно.
224 608483
>>608481
А в чем ты усматриваешь противоречие? В mozilla, dropbox, npm и т.д тоже не все на расте пишут, наверное это очевидно, что там тоже всего несколько человек этим занимается?
У хаскеля тоже есть именитые компании
Напрмер Intel, nvidia, qualcomm, AT&T, пара банков америки и т.д.
https://wiki.haskell.org/Haskell_in_industry
225 608486
>>608469

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


А тут даже и видеть линукс не надо, качаем твою годотю, открываем в readelf, читаем вывод. Опа, ты пиздабол, NEEDED libc и прочее конкретной версии. Вот тебе и "все" дистры в пролете.

>Нет, это так. Можешь посмотреть исходники какого-нибудь хромиума, там один рендеринг по объему кода больше чем весь условный годот.


Раздутость хрома как аргумент? Нет пути! ну давай сравнивать, ой, как же так, размер годотю которую ты скинул такой же как у хромиум эмбеддед, надо же оказывается ты опять напиздел!

>А вот это показывает, что ты тупой даун и вообще не понимаешь, о чем шла речь. Я где-то писал о разборе слоёв и паралакса, и дерева сцен?


А, ты решил паясничать, клоун, ну окей. Тогда и в хроме нет никаких dom и css а есть только текст и картинки.

>Нет, я писал только о том, что когда рендерят то, что уже разобрано, в opengl и подобном, глючит на реальном железе и драйверах.


Хорошо что ты наконец признал, что на реальном железе и драйерах глючит и движкописателю с этим разбираться.

>В общем, обдристался ты знатно, лучше не продолжай дальше позориться.


>Не переживай, это анонимный форум, никто не запомнит твой обсёр, так что можешь расслабиться и перестать усираться в ответ.


Пока что обсираешься только ты, шизюнь.
226 608492
>>608483

>Напрмер Intel, nvidia, qualcomm, AT&T, пара банков америки и т.д.



Ничего серьезного там на хаскеле не пишут. Какие-то энтузиасты по недосмотру начальства пишут всякую мелочь типа утилит и генераторов отчетов.

На одной из моих прошлых работ у нас был человек, который написал утилиту на F#, правда никто кроме него ей не пользовался и когда он ушел про нее забыли. Вот примерно на таком уровне весь этот haskell in industry и находится
227 608493
>>608492
Ну вот и раст примерно такой же.
F# охуенный, да. Классный паттерн матчинг, функциональщина, и при этом вся мощь дотнета на кончиках пальцев. Когда годот научится в экспорт c# в emscripten, я сразу перейду на него и прикручу.
18gOLsqBNfc.jpg17 Кб, 400x400
228 608535
>>608460

>Тяжело тогда придется.


>Самые быстрые языки это C/C++/Rust. Но они и сложные.


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

>>608458
Опять же, время на изучение это всё ничто для меня, вот о ряде проблем хотелось бы знать заранее, как избежать их?
-Про уточки памяти я знаю вроде только в общих чертах, но не знаю пока когда они возникают (при ебланском использовании динамической памяти, и не уборке за собой?)
- Про сегфорты не знаю вообще. Разъясните позюзя...
229 608538
>>608535

>Про сегфорты не знаю вообще


ты на плюсах писал хоть что-нибудь...
230 608546
>>608538
Я этот термин не слышал
231 608604
>>608535
int main()
{
((void(*)(void))1)(); //hello segfault
return 0;
}
232 608609
>>608535

> (при ебланском использовании динамической памяти, и не уборке за собой?)


Типа того, когда например вызываешь new для какого-то временного буфера в цикле, а потом не вызываешь delete. И когда выходишь из этого цикла, ты теряешь указатель на эту область и уже ничего не можешь с ней сделать, она остается выделенной.
Но в современном С++ это уже не проблема, можно написать 99% программ вообще без ручного выделения памяти через new, с помощью RAII, умных указателей, стандартных структур типа вектора, и т.д.
Сегфолты возникают тоже при ручной работе с памятью, когда ошибся указателем и лезешь в недоступную область памяти, или пытаешься записать в read-only память.
В расте такие ошибки в принципе невозможны, программа с ними просто не скомпилится.
233 608615
>>608609
Ну впринципе это еще хуйня, то есть банально быть внимательным и уже как бы эти ошибки отсечены. Еще какие-то подводные камни крестов?
Снимок экрана от 2019-09-07 11-50-32.png224 Кб, 870x400
234 608616
>>608486

>Вот тебе и "все" дистры в пролете.


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

>читаем вывод.


Ого, ты умеешь читать, неожиданно. Если внимательно почитаешь список библиотек на скрине, то увидишь, что эти библиотеки есть в любой линукс-системе с установленными иксами, т.е. на любом дистрибутиве, кроме серверных.

>и прочее конкретной версии


Опять пиздёж и непонимание, как работает линковка. Привязки к конкретным версиям системных библиотек нет, автоматически будут подхвачены системные либы, установленные в дистрибутиве, независимо от версии.
libc.so.6, например, это не конкретная версия библиотеки, это симлинк на версию, установленную в системе.
libasound.so.2 например в моём дистре резолвится на ALSA_0.9.0rc4, на другом дистре это может быть другая версия.
Я понимаю, что это так весело, спорить на тему, в которой ты нихуя не понимаешь, про операционную систему, которую ты видел только на картинках и мемах из интернета, сидя под виндовсом, но лучше бы ты прекратил дристать себе в штаны на глазах у всей борды.
235 608618
>>608615

> банально быть внимательным


Это только кажется, что просто. Но весь код просто невозможно контролировать. Вот выделил ты память, потом вызываешь метод из какой-нибудь левой либы, а она бросает эксепшен. Пусть даже у тебя стоит обработчик эксепшенов где-то, ты отловил этот эксепшен, но стек фрейм уже потерян, указатель на выделенную память просран и случилась учетка.

>Еще какие-то подводные камни крестов?


Нет пакетного менеджера, сложно менеджить зависимости, надо либо ставить все либы руками, либо юзать конан, но тогда придется писать под него пакеты, либо пойти по пути годота и тупо переносить исходники зависимостей в свой проект и билдить всё вместе.
Придется разбираться с линковкой, чтобы билдить переносимые бинарники. Ты можешь собрать бинарник, который будет работать у тебя, но пропустить какую-нибудь либу, не вкомпилить её в бинарник, и на другом компе оно не заведется.
Модули пока не завезли, придется ебаться с заголовочными файлами, это не очень удобно, особенно если надо писать темплейты.
В расте всех этих проблем нет, там пакетный менеджер, модули, билд переносимых статических бинарников.
236 608619
>>608616
Да что же тебе так нравится серить себе на голову, а потом размазывать по своим волосам и лицу говно? Все и так уже поняли что у тебя "работает на всех дистрибутивах" означает "на моей убунте запустилось, УМВР", а то что на других семействах может быть libc другой версии, с другим ABI, тебе естественно невдомек. Ну что тут сказать, если уж даже я, который по твоим словам "видел линукс только на мемах" знает больше тебя, выходит ты ламер хуже червя-пидора и обсуждать с тобой тащемта и нечего.
e17d56ee5fdebb9f3cd1e5e5f4b0fc84.jpg49 Кб, 500x361
237 608623
>>608619

>Да что же тебе так нравится серить себе на голову, а потом размазывать по своим волосам и лицу говно? Все и так уже поняли что у тебя "работает на всех дистрибутивах" означает "на моей убунте запустилось, УМВР", а то что на других семействах может быть libc другой версии, с другим ABI, тебе естественно невдомек. Ну что тут сказать, если уж даже я, который по твоим словам "видел линукс только на мемах" знает больше тебя, выходит ты ламер хуже червя-пидора и обсуждать с тобой тащемта и нечего.

238 608626
>>608619

>, а то что на других семействах может быть libc другой версии, с другим ABI,


Так вроде бы еще с начала девяностых на всех десктопных дистрах стоит libc.so.6.
А в целом, в теории конечно может, у одного процента пердоликов, билдивших линукс из сорцов, или у какого-нибудь любителя некрожелеза. А у 99% юзеров обычных десктопных дистров будет стоять libc.so.6.
Но твою позицию я понял, если твой билд не будет работать у одного пердолика из пяти миллионов обычных пользователей, то это конечно пиздец как хуёво, с таким раскладом лучше вообще ничего не программировать и не компилировать. А то вдруг именно этот пердолик скачает, а у него не запустится, это пиздец как хуёво будет, что посоны подумают.
239 608627
>>608618
у меня пока синдром утёнка не разрешает перейти на раст, я этот язык мало знаю, и пока не уверен в его скажем так эффективности по сравнению с крестами теми же. А за поясняловую благодарствую
240 608638
Поясните анончики любимые, смысл срача? Почему всем не придерживаться просто правила -> Хочешь делать игру, берёшь Юнити,Уеч,гейм макер. Хочешь просто кодить -> любой голый язык или веб. Всё, срачи пропадут.
Screenshot2019-09-07-20-13-22-916com.opera.browser.png84 Кб, 720x1280
241 608648
>>608638
если ты делаешь рогалик или даже платформер тебе не особо нужен фреймворк вообще

вот поиграй например в платформер в несколько сотен строк https://eloquentjavascript.net/17_canvas.html
пикрил где искать на странице и как запустить, я пишу с мобилы, но там нужен десктоп

в рогаликах от фреймворка вообще мало толку, в платформерах хоть риал тайм физика есть и она более менее универсальная. а в рогалике тайловый пошаговый мир с одной стороны, это несложно в плане перемещения и столкновений, а с другой например я хочу такую вот систему видимости, а фреймворк её делает по другому, короче связывает руки
242 608660
>>608648
РРРЯЯ НИВАЗМОЖНАЯ ЮПИНИ НАДА БРАТЬ!! НИЛЬЗЯ ТАК, ТЫ САМЫЙ УМНЫЙ ЧТОЛИ? ЮПИТИ ПРИДУМАЛИ, НАДО ЕГО БРАТЬ, ТОЛЬКО В ЮПЕИТИ МОЖНО ДЕЛАТЬ ИГРЫ!!11
243 608661
>>608660
Гоудотер порваный?
244 608663
>>608661
Хорошо потушил, клоун
245 608669
>>608663
Пощютил те за щеку, проверяй, петушара.
1567857497493.jpg7 Кб, 273x184
246 608691
247 608693
>>608691
Сорян, в отличие от тебя сосуна я релизю игры и делаю тысячи бакинских в месяц ;)
15669168775200.png559 Кб, 538x589
248 608696
>>608693

>Сорян, в отличие от тебя сосуна я релизю игры и делаю тысячи бакинских в месяц ;)

249 608698
>>608696
Эх эти боевые картиночки...
15668428752830.png398 Кб, 780x1040
250 608700
>>608698

>Эх эти боевые картиночки...

251 608895
>>572542

>спрайты выполнены в размере 21x21


Сука, ты заебал. Что так сложно ответить почему выбрал такой размер спрайтов?
252 608901
>>608895
Какая разница то лол? Ну выбрал он и выбрал. Нечетный размер позволяет симметрию кстати.
253 609330
>>607968

>> Поэтому во всех трушных рогаликах игрок и враг это один и тот же класс. Так везде, от dungeon crawl'a до катаклизма.


И там и там разные. Ты хоть в код заглядывал, а не в свои фантазии?
254 609360
>>609330
Мимокрокодил, заинтересовался. Поясните, какие подводные камни, если сделать класс Персонаж, в котором описать меш, коллизии, анимации движения, от него унаследовать класс "Игрок" в котором описать управление с инпута, и класс "НПЦ" в котором описать управление от ИИ?
Или, если кому неугодно, сделать класс "Персонаж", в котором описать меш, коллизии, анимации движения, а так же задать поле для хранения компонентов, создать класс "Компонент", от него унаследовать класс "Управление", от него унаследовать класс "Игрок" в котором описать управление с инпута, и класс "НПЦ" в котором описать управление от ИИ и объекту "Игрок" класса "Персонаж" накинуть компонент "Игрок"?
255 609366
>>609360
Сейчас 2к19, никто не наследует то что можно сделать через ECS
256 609387
>>609366
Ебать ты тупой. Слово "компонент" не нашёл? Или после слова "наследовать" дальшенечитал?
Стикер512x512
257 609395
>>609387

>"Компонент"


>от него унаследовать


>от него унаследовать

258 609397
>>609360

>. Поясните, какие подводные камни, если сделать класс Персонаж, в котором описать меш, коллизии, анимации движения, от него унаследовать класс "Игрок" в котором описать управление с инпута, и класс "НПЦ" в котором описать управление от ИИ?


Если ты захочешь одновременно подключить и управление игроком, и управление ИИ, ты соснул с наследованием. Например, чтобы персонаж автоматом уклонялся от пуль, но при этом можно было контролировать его вручную.
Компоненты в ecs подразумевают модульность, их можно подключать сразу несколько к одной сущности.
Накидываешь компонент брони на сущность шлема, можешь надевать его. Накидываешь еще компонент оружия с колющим уроном - можешь дополнительно бодаться им.
А на ООП ты жидко пукнешь спермой, не зная что от чего наследовать, шлем от оружия или оружие от шлема.
259 609398
>>609397
ЕЦС это композиция ООП.
Персонаж - сущность. Игрок и ИИ - компоненты.
>>609395
Вот смотри:
using Unity;
public class MyClass : MonoBehaviour { }
Это что? Не наследование? Не классы? Не ООП? А что это?
260 609405
>>609397
В ecs ты точно так же жидко пукаешь, если у тебя коллизия между полями компонентов. Мозг в любом случае придется юзать, чтобы выделять и именовать сущности. Оружие и шлем очевидно пронаследуются от единицы снаряжения.
261 609413
>>609405
Хуя ты ебанашка. Нет никаких коллизий в нормальном ecs, ты видимо просто нормальный не видел, жертва ООП головного мозга.
>>609398

>юнити


>ecs


Проиграл. Иди дальше ассеты по сценке тягай, манька.
262 609421
>>609413
Нет никаких коллизий в нормальном ООП, ты видимо просто нормальный не видел, жертва ECS головного мозга.

>"не зная что от чего наследовать, шлем от оружия или оружие от шлема."


У тебя в ecs будет поле снижение урона в броне и снижение урона в шлеме, и ты не будешь знать каким пользоваться - вот уровень твоей аргументации.
263 609429
>>609360
Если ты спрашиваешь за код тех проектов, то так не делали, т.к. у тех же зомби в кате нет кучи параметров, что есть у персонажа, которые им вообще не нужны или делают симуляцию избыточной, что отжирает ресурсы, которые перенаправляют на что-то более полезное.
Да, это красивая история про то, что можно давать управление персонажа компу, но почти всегда это не оправдано больше ничем, кроме просто затем, чтобы было.
Про то, что ты описал - выше уже сказали, что лучше сделать через ecs. У тебя будет компонент отображения: меш, анимации, частицы.. компонент контроллер: игрок/ии.. все это компоненты какой-то сущности будут, например, персонаж.
264 609435
>>609421
Еще раз, возвращайся в свой юнити-загон. Я понимаю, ты скачал юнити, научился таскать ассеты по сценке, и тебе теперь до сверби в очке хочется спиздануть своё экспертное мнение, но иногда лучше промолчать, чтобы не позориться.

>Оружие и шлем очевидно пронаследуются от единицы снаряжения.


Ты даже не понял смысл компонентов ecs, что впрочем неудивительно для умственно-отсталого пользователя юнити.
Ладно, еще раз объясню, может дойдет со второго раза. Есть компонент оружия, есть компонент шлема. Логика оружия и атак в компоненте оружия, кол-во брони и логика защиты в компоненте шлема. Если ты делаешь обычное оружие, ты используешь один компонент оружия. Обычный шлем - компонент шлема. А если захотел, то комбинируешь два компонента в одной сущности, получаешь рогатый шлем, который дает защиту, и позволяет атаковать рогами.
В рамках ООП тебе уже придется делать наследование от двух классов с общим родительским классом, что приводит к diamond problem. Да и во многих языках множественное наследование запрещено, т.к. приводит к куче проблем. Разве что в С++ можно полноценно юзать множественное наследование, но поскольку ты умственно отсталый, то вряд ли умеешь писать на плюсах.
А если тебе отрубили рога, ты просто на лету дропаешь компонент и получаешь опять обычный шлем без атаки. В нормальном ecs все компоненты хранятся в раздельных хранилищах, поэтому компоненты легко отсоединяются/отключаются, память при этом освобождается.
В ООП так не получится сделать, если юзаешь наследование/агрегацию, в рантайме на лету ты не разделишь компоненты сущности.
265 609442
>>609435
Дегенерат, ты высрал много хуйни и даже не понял мой простейший пост - в ecs у тебя ровно та же самая diamond problem, ты от нее никогда не уйдешь, просто сдвигаешь немного в другую плоскость, да даже на твоем же примере, хуй разберешься как рассчитывать атаку, поскольку она идет и от оружия и от рогов шлема, значит у тебя уже ограничение, что можно атаковать только одним из них, то есть ничем не лучше как если бы в ооп ты наследовался не множественным наследованием а ограничивал все одним предком.
266 609448
>>609442
Вот это обида умственно отсталого. Ничего, всё нормально, не обижайся, ты хороший мальчик. Иди запусти юнити, скачай ассет из стора, перетащи на сцену. Молодец, ты у нас умница, почти как настоящий взрослый разрабочик игр.

> в ecs у тебя ровно та же самая diamond problem


Нет, её нет.

>хуй разберешься как рассчитывать атаку


Элементарно разберёшься.

> значит у тебя уже ограничение, что можно атаковать только одним из них


Зависит от механик игры. Можно атаковать одним, сортировать компоненты по атрибуту приоритета/урону.
Можно проводить двойную атаку, в духе нескольких бросков кубика в d&d играх.
Можно давать игроку список действий на выбор,пробегаться по всем подключенным компонентам и строить набор доступных действий - стукнуть мечом, боднуть, пнуть, бросить этот сраный шлем во врага - этот функционал легко включить, просто подключив компонент "Бросаемый" к шлему. Ты можешь подключить этот же компонент к тому же мечу одной строчкой в конфиге сущностей, и для его броска будет задействован тот же код. Он будет так же бросаться, действие для броска так же автоматически будет доступно, без строчки дополнительного кода.
Удачи в ООП пробегаться по всем предкам сущности, чтобы понять, какие действия с ней можно делать.
267 609457
>>609448
Лол, вот это боль юнитимакаки, которая умеет только возякать ассеты, и ничего не понимает в ООП.

>Можно давать игроку список действий на выбор,пробегаться по всем подключенным компонентам и строить набор доступных действий - стукнуть мечом, боднуть, пнуть, бросить этот сраный шлем во врага


Ты даже не понимаешь, шизоид, что ты просто ручками прописываешь все то, что у тебя будет само работать с наследованием. Просто смирись, программирование и геймдев - это не для всех, иди раскладывать товары в пятерочке.
sage 268 609459
>>609448

>запусти юнити, скачай ассет из стора, перетащи на сцену. Молодец, ты у нас умница, почти как настоящий взрослый разрабочик игр.


хуесос, ассет от моделлера чемменяет этот процесс? прекроди срать себе в рот
e17d56ee5fdebb9f3cd1e5e5f4b0fc84.jpg49 Кб, 500x361
269 609465
>>609459

>хуесос, ассет от моделлера чемменяет этот процесс?

270 609702
>>609435

> если юзаешь наследование/агрегацию, в рантайме на лету ты не разделишь компоненты сущности


using Unity;

public class Component {}

public class Entity {
public List<Component> components
}

Дальше разъёбывать тебя, энтитух? Или ты уже понял, где обосрался?
1568216498127.png135 Кб, 300x190
271 609709
>>609429

> почти всегда это не оправдано больше ничем, кроме просто затем, чтобы было


Это даёт мододелам возможность пилить моды со своими сюжетами любого уровня сложности. Например, в основной игре, ты даже не думал о том, персонажем игрока может управлять ИИ, но всё же вложил эту возможность. И вот один моддер сделал мод, где все персонажи управляются игроком в стиле изометрических РПГ. А другой моддер запилил мод с квестом, в рамках которого некий монстр может удалённо контролировать персонажа игрока и игроку предстоит с этим разобраться. А третий моддер запилил мод на оборотня, где ГГ по ночам теряет разум и бежит охотиться, а игрок в ужасе наблюдает, не в силах ничего поделать. А пятый моддер запилил еблемод, где ГГ ебут.
272 609745
>>609709

>моды


Ненужно.
273 609749
>>609745
Нам очень важно ваше мнение. Пожалуйста, оставайтесь на линии, ближайший освободившийся оператор службы выслушивания охуительно важных мнений школоты и хомячья, обязательно ответит вам!
274 609751
>>609749
Моды это и есть для школоты. Нормальные люди играют в готовый контент.
275 609755
>>609709

>один моддер сделал мод, где все персонажи управляются игроком в стиле изометрических РПГ


Ты мог бы продать две игры, а в результате продал одну, а эту идею подарил какому то моддеру. Потом он выпускает игру ТОДА 2, которая становится популярной, а твой проект сосет бибу.
276 609756
>>609751
Нам очень важно ваше мнение. Пожалуйста, оставайтесь на линии, ближайший освободившийся оператор службы выслушивания охуительно важных мнений школоты и хомячья, обязательно ответит вам!
277 609757
>>609755
Кто не рискует, тот не нюхает кокс с жоп шлюх.
278 609758
>>609756
Я понял, понял. У вас там в школе все заняты хомячками.
15583899661130.png129 Кб, 480x480
279 609849
>>609702

>using Unity


Нахуя там юнити? Там же юзаются один List из стандартной либы. Или ты без юнити пукнуть уже не можешь?

>Дальше разъёбывать тебя, энтитух?


Ну давай, разберем по частям тобою написанное.
Твоя реализация по перфомансу против полноценного ECS - это как бабка на костылях против спорткара.
В ECS компоненты хранятся в cache-friendly структурах, плотными массивами, при обработке системой они выгружаются на линии кэша процессора пачками и молниеносно обрабатываются.
У тебя же список, который хранит указатели на объекты в рандомных местах кучи, т.е. вся куча засрана дерьмом, по которому приходится скакать при обработке, кэш при этом вымывается мусором при каждой итерации.
Дальше, ты как ты представляешь себе код обработки высранной тобой структуры? Как системы узнают, что у сущности X в листе компонентов находятся компоненты типа, обрабатываемого данной системой? Я так полагаю, ты собрался для каждой сущности пробегаться по всем компонентам и делать тайп чек? Ты представляешь какой это оверхед по сравнению с настоящей реализацией ECS, где все компоненты одного типа лежат в отдельном массиве, и каждая система заранее знает, где взять эти компоненты без оверхеда?
Так что обосрался прямо себе на лицо пока что только ты.
Впрочем, от умственно отсталого потребителя юнити ничего другого и не ожидалось.
280 609928
>>609709
Так то, что я описал никак не мешает мододелу добавить/убрать нужные компоненты персонажу/мобу и передать управление игроку/ИИ/аллаху.
>>609745

>> Ненужно.


Нужно, очень важная составляющая качественной игры.
281 609943
>>609928

>моды


>качественной игры


Выбери что-нибудь одно.
282 609951
>>609943
Я выбираю скайрим. Игру года. Игру десятилетия. Хуй ты оспоришь.
283 609955
>>609951
Скайрим без модов некачественный, ты обосрался.
284 609978
>>609849

>15583899661130.png


Ты понимаешь, что ты поехавший?
285 610063
>>609955
У меня сейчас будет аргумент уровня "миллионы мух не могут ошибаться", но скайрим блядь, так много раз продавался, что об этом в интернетах легенды (и мемасы) ходят. И бойчее всего он продаётся на платформах, где моддинг затруднён.
286 610198
>>609943
Во вселенной своих фантазий ты волен выбирать, что угодно.
287 611572
>>558393
Он там в стиме на альфаре уже выкатился, игрокам нравится и выглядит очень необычно.
sage 288 614729
как заебало это натужное прохрюкивание оскотинившихся пидоpax >>609755 >>609749 >>609928
289 614757
>>614729
Пацаны, смотрите, бота как далеко занесло.
image.png89 Кб, 1223x855
290 616191
Небольшие попытки осмыслить архитектуру ECS, как метод выражения Сущностей игрового мира
291 616228
>>616191
я не понимаю в чем вы все страдаете этим ECS? это же абстракция ради абстракций, когда простые вещи делаются через стопятсот абстрактностей ради какой-то мифической расширяемости которой на самом деле никогда не будет (не будет у тебя никогда стопятсот компонент)

(это как в свое время с++шники страдали шаблономагией из-за выхода книги от Александреску
А еще упарывались дата-драйверцы со своими горячими перезагрузками и джейсон-ресурсами которые нахрен никому не сдались (в юнини вон так и забросили эту идею и работает там через одно место)
Там где-то еще эвентники вклинивались со своим "все должно быть на событиях"
А дедушки наверное вспомнят функциональщиков...

короче, всё это говно, мода пройдет и закопают. ECS ничего не дает кроме вымышленных решений на будущее, тогда как надо писать на сейчас.

впрочем у тебя на скрине не ECS.
292 616233
>>616228
Дед, не ори.
Просто ты уже старенький стал, мозги закостенели, за старое держижшься, ух.

И что ж ты предложишь? ООП?
293 616249
>>616228
+ где тут написано что это ECS?
294 616298
>>616228
пиздец ты школьник, не нюхавший программирования) Ну когда будете проходить про расположение структур в памяти, тогда пояснят принципиальную разницу oop/ecs для высоконагруженных приложений.
Понятно, что для твоих задачек школьных и хеллоуворлдов по урокам с ютьюбчика пойдет любое и разницы ты не увидишь.
image.png62 Кб, 288x175
295 616357
>>616233
что еще можно предложить?
296 616358
>>616298

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


Так он то же самое и написал, только про тебя.
297 616359
>>616298
сразу видно школьника, ты бы хоть сам-то узнал что такое ECS
Но я добрый, лови статейку где все разжевано
https://github.com/SanderMertens/ecs-faq

>>проходить про расположение структур в памяти,


ну во-первых не структуры, ты даже в терминологию не можешь.

Во-вторых от того что ты решил что у тебя ECS, твой код не станет кешфрендли и это тебя не спасет от сache miss.

Как минимум придется написать и свой аллокатор памяти чтобы гарантировать что твои компоненты реально лежат друг за другом, а не по всей памяти.
Да и вообще побайтоебить... Ведь вот какой прикол, гарантированное расположение в памяти тебе дается только для POD структур, только вот там запрещен полиморфизм (виртуальное наследование)
https://ru.wikipedia.org/wiki/Простая_структура_данных
298 616361
>>616359
Естественно у ECS свои проблемы, тут спору нет. Но мне кажется это не так страшно, по сравнению в вечным рефакторингом ООП, когда ты только собираешься въебать новый функционал.
299 616362
>>616359
Так шо я думаю, блядь, ну блять, ECS метод, он относительно молодой, и хули, понятное дело что он будет вызывать новвые проблемы. Но бяддь, мне вот лично не западло изучить еще небольшую тонну материала, и разобраться по хорошему с аллокацией памяти, побайтоёбить, и создать просто хороший, добротный движок для рогулька, на основе ECS. Дык в итоге это же будет монолитный фундамент, на который ты сможешь СТОЛЬКО вещей надеть, добавить, постоянно модифицировать, что оно всё окупит.
300 616410
>>616359

>Ведь вот какой прикол, гарантированное расположение в памяти тебе дается только для POD структур, только вот там запрещен полиморфизм (виртуальное наследование)


Вот сижу и думаю, от чего бы мне отнаследовать количество здоровья персонажа, или его координаты. Ведь компоненты в ecs ну никак нельзя делать без виртуального наследования. Нельзя же просто сделать using Health = float, надо обязательно сделать class Health : public AbstractHealth, а AbstractHealth - наследовать от AbstractComponent, а AbstractComponent от AbstractProxyFactorySingletonComponentFactoryBean, иначе не трушное ООП получится.
301 616411
>>616410
Компоненты не надо наследовать. И вообще это должны быть не классы, а структуры. И называться типа HasHealth. И на каждой итерации твоя HealthSystem проверяет все компоненты HasHealth, и если значение достигло нуля, то удаляет эту сущность, например
302 616412
>>616411
А, это ирония была, ну ладно
303 616451
>>616411
А почему нельзя не итерациями производить события, а условно создать поток, или пул, в который каждый компонент, если он должен измениться будет вкидывать себя на очередь, допустим? Какие подводные?
304 616459
>>616451
Ты вообще можешь сделать как хочешь. ECS это просто реализация поведения объектов, которое описывается набором характеристик. Например, объект реализует поведение оружия, если у него есть характеристики предмет и стреляющий.
Системы - это конкретный процедурный способ реализации поведения объекта. Можно сделать как в юнити, и поведения добавить внутрь самих компонентов.
305 616478
>>616459
Ну как бы да, могу как хочу, это был скорее вопрос к самой ценности вышевысказанной идеи.
306 616629
>>616359
а что у вас в школе маллоки не проходят уже, что написать аллокатор памяти для своих структур в игре - это проблема?
а, нынче только сисярпить могут
307 616630
>>616459
Если как раньше в юнитях, то это EC архитектура у них была, на ECS они только переходят.
308 616631
>>616451
Потому что компонент ничего не знает о том, что он должен как-то изменится. Это просто набор данных.
309 616632
>>616631
Обосрался, не компонент а система.
310 616635
>>616632
Система как раз и знает как изменяются компоненты и содержит логику их изменений. Удачи в школе сегодня.
311 616636
Возрадуйтесь, ибо грядет)
https://suvitruf.ru/2019/07/20/6387/csharp-android-support-godot-3-2/
312 616641
>>616635
Да это то понятно, умник ёпта. Я просто думал над оптимизацией самого процесса вызова этих функций. Как в пример можно взять события через Update на юнити. Которые засирают нахуй пул ненужным мусором. Но при этом нам надо как-то отображать изменеия тех или иных объектов во времени. Вот я и думаю, насчёт идеи создания пула, в который будут все изменения вкидываться уже самими функциями, когда они хотят изменить что-то и выполняться уже в порядке очереди.
313 616653
>>616641
Ну это юнити, страдай.
314 616655
>>616653
Ты чего злой такой, пиздец? Я вообще просто как пример неэффектисвной реализации привёл, я юнитями не пользуюсь. А ты блять вот так нахуй. Как так нахуй?
315 616658
>>616629
щас бы аллокатор на маллоках писать, лол.

Вот тебе случайный аллокатор
https://github.com/EmuraDaisuke/MemoryAllocator.KanameShiki
316 616659
>>616658
А есть какая-нибудь соотвествующая лит-ра, где о проблемах аллокации говорится вот прямо подробно. И желательно вообще о любых проблемах-решениях оптимизации на уровне железа, или байтоёбства?

буду намагниченной иголочкой транзисторы флипать аыаыа
317 616660
>>616659
была бы вообще хоть какая-то единая обобщенная лит-ра... эх.
А так смотришь чужие презентации (что-нибудь по поиску Game Dev Memory Allocation или Engine Memory Allocation),
плюс вникаешь в работу процессора с памятью...

Суть там в чем:
1) в основном цикле не должно быть выделений памяти, потому что это дорого. Выделять можно в начале, или там один раз
2) память любит срать во все дыры (фрагментация - то есть твой класс раскидывается по всем уголкам), а процессору очень тяжело прыгать по памяти, а еще он верит что следующий блок ему нужен (и если это не так, то бо-бо)... Тут короче гуглить кеш промахи (Cache Miss) и всё про это

по 1 пункту - в низкоуровневых компиляторах есть возможность выделить кусок памяти, а потом в него писать (В С++ это делается через placement new).
по 2 пункту... ведь данные у нас часто одинакого размера (например миллион transform компонент), можно под каждый тип данных выделить свой блок памяти - тогда фрагментации не будет (удалил один, на его место записал другой)

Короче, тема слишком большая, вникать долго. Не факт что нужно.

Просто стоит понять что ECS из коробки оптимизации не даст, если не разбираешься в работе с памятью
318 616661
>>616660
Я от ECS панацеи не ждал, ясен хуебасен что без прямых рук, свежей головы и какой нибудь хуйни еще можно и ECS засрать. Мне этот паттерн понравился больше из за гибкости в перепиливании, и добавлении новых вещей. А то что можно хорошо так, по доброму еще и с памятью поработать, оптимизировать движок, то это вообще роскошь.

А за литературу да... НА ум только совершенный код приходит, и еще книжечка одна про компиляторы. Не знаю насколько это в сама деле полезно.
319 616662
>>616661
вообще всегда можно глянуть как сделано у серьезных дядек.

например скачай исходники unity 4 (спираченные китайцами, а не огрызок от разработчика). (старье, да, но с другой стороны 4 версия не тормозила даже на кофеварках в отличие от текущих)

Там понятный код аллокатора. (или исходники unigine 2010 - там вообще легко читается)

(но ссылку на код юньки не помню, надо в китайских помойках копаться что-то на source leak unity 4 yoyoyo)
320 616663
>>616662
Уох бля, слили? Вот так внезапно. Ну ладно, буду посмотреть. А вообще, вернёмся к теме рогуляков. Есть ли смысл тут задрачиваться так с памятью и оптимизацией, и если есть, какие бенефиты это может привнести? Вот допустим если есть идея создать игровой мир так Это выглядит как убераутизм, но это и есть смысл RLSim'ов название придумал вчера, чтобы внутри каждого существа, каждый обьект-орган был включён, и здоровье было не просто как счётчик, а фактическое состояие существ. НУ вот в пример возьмём Dwarf Fortress. Я уже думал над тем, как можно сохранять тонны предметов в одном "существе", каким образом можно говорить системам что "вот это у нас для дыхания, а вот это кровеносная система, но немного не в порядке, потому что давление падает из за повреждения сосудов левой пятки правой ноги".
Я уже накириллил в Evernote пару десятков листов подобного сырого описания механик и алгоримтов. Если надо, могу высрать.
321 616664
>>616663
Если у тебя в игре будет 10 дварфов с органами, то можшь не заморачиваться. Если предполагается обсчет 1000 существ и физика мира будет достаточно сложной, то - да, стоит.
322 616666
>>616663
по теме сложно сказать. в 90% индюшатины (и тем более рогаликов) - не нужно.
С другой стороны если делать Dwarf Fortress - то там очень даже нужно - DF тормозит еще так - много расчетов (а может просто разрабу лень что-то оптимизировать)

>>616663
Во, оказывается слив юнити и на дваче обсуждали (из архива - успей пока не удалили https://m2ch.hk/pr/res/1252860.html)
323 616667
>>616664
Ну физика не сказать чтобы прямо сложная будет, хотя предполагается что в баббле могут начать пиздиться и активно производить тактические манёвры 300-500 ёбел. При этом стоит не забывать что мир трёхмерный. При этом также будут иметься движущиеся механизмы (машины, или огромные крепости). Вот с последним я думал думал, там пиздец нахуй морока будет. Ибо пересчитывать перемещение каждой клеточки, это можно ебануться к хуям. Думал можно поизъёбываться, и сделать так, что в мире у движущегося механизма будет единый центральный блок, который только будет двигаться, и все внутренние вычисления перемещения будут происходить уже относительно него. Тобишь двигать каждый блок уже не потребуется, хотя думаю тут если дойдет до оптимизиации, вылезит такое дикое количество нюансов, что жопу придётся рвать крайне интенсивно.

>>616666
Там даже потоковость не поодерживается. Да и что-то мне подсказывает, что автор проебал уже давно всю последвательность архитектурную, и просто городушки делает, не знаю. Но да, оптимизон нужон.
324 616668
>>616666

>https://m2ch.hk/pr/res/1252860.html



Я спиздил. Красиво. Буду копать.
325 616671
>>616667
Ну если вводишь многоклеточные структуры и такие эпичные битвы - тогда лучше с начала разработки учесть методы оптимизации при проектировании.

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


Так коллизию всей этой структуры все равно придется точно также обсчитывать в трехмерном мире: т.е. все граничные клетки твоей структуры в направлении вектора движения.
326 616682
>>616671
Естественно, никто не спорит.

А про оптимизацию да, я собственно, по этой причине-то и интерисуюсь
327 616689
>>616682
так он увидит, что не хватает парного символа табуляции
328 616690
329 616692
>>616690
ну если конкретно для цикла

Правильный вариант:
for
отступ body
Пропускаем отступ:
for
body
- получаем ошибку, что не хватает знака табуляции после объявления цикла
330 616693
>>616692
Ебать опять боты пизданулись, че за хуйня
331 616697
>>616690
промахнулся, не тебе
332 618792
ТЭкс, пока ОП умер нахуй, я решил сам начать пилить Движок, и сам рогалик. Пока в быстром порядке отзубриваю кресты С++, ООП, ЕЦС, SDL и прочее ебланство, попутно нанизывая на собранный ручками из говна и палок недодвижок. Сразу вопрос про либку SDL. Это вообще законно/канонично, если я начну хуячить весь рендер (Сейчас я по немного разделяю рендер архитектурно через интерфейс) через SDL_Renderer, или мне лучше попробовать подрочиться с windows.h, и пилить вывод прямо в терминал? Я хочу как минимум его на Win32/Linux въебать, но совершенно не знаю особенности кроссплатформенности под линукс.
333 618797
>>618792

>Я хочу как минимум его на Win32/Linux въебать


Раз так, то тебе стоит сфокусироваться на SDL. Для неё вроде даже есть драйвер, выводящий картинку в ascii-art.
334 618800
>>618797
Ну это не будет само собой непосредственно терминальное окно. Там получается что вот пока у меня выводится графическиий рендер, на котором уже ttf текст рендерится. Вроде как бы и норм, но по мне так исполнение - дикая хуйня. И поясни за драйваер, он прямо непосредственно буфер терминала перехватывает, или просто какая-то свистоперделка для рендерера?
335 618801
>>618797
Хотя если так подумать, хуй еще пойми, реально ли надо именно таким "стандартным" для рогулей образом выводить игру. хуй еще знает кароче.
337 618811
>>618810
Ебать, разве это не просто обработчик медиа под стиль ASCII?
338 619409
>>618792
Попробуй ascii графику в consolegameengine on OneLoneCoder
339 619411
>>619409
Я пока решил начать пилить рогуль с BearLibTerminal, в ней очень много всяких плюшечек есть, и она вполне себе хорошо подходит для моих задач. НА первое время, скажем так, можно взять её. Вкручу её в код через интерфейсы, потом может когда-нибудь, если понадобится, напишу собственный рендерер, а пока буду занят чисто логикой игры и структурой кода
340 637624
>>558349 (OP)
Есть у кого-нибудь опыт с T-Engine 4? Это на котором ToME4 написан. Там луа, и разобраться вроде несложно, но я так и не понял, насколько движок свободный. Смогу я игру, сделанную на нём, продавать в стиме? Алсо, не могу понять, можно ли сделать полностью отдельную игру, а не .team-мод для ToME, хотя на 4drl вроде делали.
341 637625
>>637624

>4drl


7drl
16pixel 343 647714
Вкатываюсь в тред, пилю рогуалик на питоне, вывод графики через pygame, остальное сам пишу ибо интересно.
И раз тут нашелся такой уютный тредос, поделюсь наболевшим.

Пилил короче генерацию данжа, решил от квадратных комнат перейти к пещерообразным. Почитал про cellular automata, реализовал невзъебенную функцию в пол-экрана, которая генерит комнату и "причесывает" ее 5 раз, чтобы было похоже на пещеру, все в соответствии со статьями на roguebasine - но закономерно столкнулся с проблемой, что алгоритм может тебе сделать 2 или более несоединенных пещер, а значит это тоже надо проверять. Сделал доп. функцию, которая проверяет цельность пещеры, если не цельна - переделывает. И короче при таком подходе одна пещера генерится секунд 5-7. Одна!

Долго думал, что где оптимизировать, но кодер я так себе, так что хрен там. Но через день случайно почитал про алгоритм drunkard walk или random walk. Реализовал функцию в пять строк. И о чудо! Пещеры генерятся моментально, эффект точно такой же, как в предыдущем варианте, может даже лучше.

Короче нахуй cellular automata, посоны. Юзайте drunkard walk и будет вам счастье.
344 647749
>>647714
Ты не показал содержимое find_4_tiles_around() подозреваю, что там 6-8 строк, но тем не менее, тут можно доебаться.
345 647868
>>647714

> Короче нахуй cellular automata, посоны. Юзайте drunkard walk и будет вам счастье.


Спасибо за инсайт, сделал пометочку в своём эверноте.

> кодер я так себе, так что хрен там


Если что, спрашивай, я как раз на питонах зарабатываю на хлебушек.

Удачи
У тебя на скрине ГГ лысый лол
346 648012
>>647868
А питонисты разве до сих пор нужны? Как вообще там? Я сам изучаю раст, но чую что он пока мало кому нужен, хотя язык лучше даже крестов в каком-то смысле
347 648013
>>648012
>>647868

На нём же кстати и буду пилить свой рогалик.
348 648014
>>648012
Учил бы го - нужен был бы всем и задорого.
349 648025
>>648012

> А питонисты разве до сих пор нужны?


Более чем все прочие. У меня между разными галерами пауз в работе больше месяца не было.

> Как вообще там?


Как земля. Что узнать-то хотел? Конкретно спрашивай.

> раст, но чую что он пока мало кому нужен


Правильно чуешь.
350 648037
Кириллишь десятилетиями рогалик мечты.
@
Авторы холлов найт нюхают кокс с жоп шлюх.
@
Авторы ори купили по второй ферари.
@
Жидко пукнув помираешь от старости.
351 648038
>>648037
Бля. Рогалики с метроивданиями перепутал. Удолити пост. Стыдно.
hqdefault.jpg12 Кб, 480x360
352 648076
353 648095
>>648014
А я его и начинал учить кстати, пока не понял что ебись оно всё в жопу эти ебучие GC.
Ну значит потом буду снова его учить.

>>648025

>Что узнать-то хотел? Конкретно спрашивай.


Конкретно о том какие задачи на нём чаще всего приходится решать , и какой уровень тупизны ваших братьев погромистов там (Про тебя ничего не говорю).

>Правильно чуешь.
Но он мне люто нравится, поэту я буду продолжать его учить.
354 648106
>>648076
Не прав. Метроидвания - пик развития платформера.
355 648218
>>648095

> Конкретно о том какие задачи на нём чаще всего приходится решать


Я на нём по работе лабаю вебсервисы на джанге. Ещё есть слухи, что в нашу контору хайрили датасатаниста, тоже на питонах, удои повышать.

> какой уровень тупизны ваших братьев погромистов там


У меня охуенные коллеги, от которых я узнаю много новых полезных штук, но, возможно, это мне так повезло. В среднем в этой области, как я понимаю, дохуя вкатывальщиков.

> Но он мне люто нравится, поэту я буду продолжать его учить.


Бесценное время твоей жизни принадлежит только тебе, решать, на что его тратить, тоже только тебе.
356 648219
>>648106
Органически не переношу игры, для игры в которые нужен только раздроченный спинной мозг, так что ну его нахуй я всё в INT вкачал, AGI у меня околонулевое
357 648374
>>648106
А рогалик - пик развития топдаун эрпогэ?
16pixel 358 648959
Продолжаем попил приключений лысого ананаса в подземельях с монстрами.

Сделал кривейший line of sight и fog of war через такие костыли, что просто ужас. Но эй, оно работает и не тормозит, так что - пойдет.

Как сделал los: Как водится, через рейкастинг - но потайловый; берем начальную координату (позицию лысого), и потайлово проверяем в каком-либо направлении, не уперлись ли мы в стену или закрытую дверь. Проверяется так только 8 направлений, т. к. мне было лень нормально делать, так что я до кучи добавляю в los все тайлы комнаты, если она next to лысый. Сам в ужасе от системы, но мне нравится придерживаться позиции "хочешь сделать что-то - сделай как-нибудь, потом почитай у умных дядек, как правильно".

Как сделал fog of var:
Покрыл все тайлы стен и пола доп. слоем спрайтов шахматной сетки, который рендерю, если он не попадает в los. Все остальное рендерится, если попадает в los. Ну, кроме стен, дверей и тайлов - они рендерятся, если попали в los хоть раз.

Вообще, писать о процессе довольно сильно включает критическое мышление на тему "чего я хочу от того, что делаю". Так что всем рекомендую. Может девблог завести какой-нить
359 648986
>>648959

>если он не попадает в los


что это?
На чём пишешь?
Можешь пример кода привести.
16pixel 360 649102
>>648986
Тред не читай @ сразу отвечай

los это список координат [x,y]. заполняется каждый ход. Каждый ход происходит проверка, попали ли в [x, y] мобы, тайлы и прочее барахло.

Кто-нибудь может адекватно за ECS пояснить? Не вкуриваю концепт вообще.
361 649122
>>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 и готовлюсь по чуть чуть свой рогуль с анатомией и аутизмом делать. Но нужно время.
361 649122
>>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 и готовлюсь по чуть чуть свой рогуль с анатомией и аутизмом делать. Но нужно время.
362 649124
>>649122
https://habr.com/ru/post/343778/
Добавлю вот эту статью. У этого паренька лютая ECS. Хотя для моих запросов не подходит.
363 649132
>>649122
Падажжи, а кто системе движения подготовил эти массивы векторов?
364 649142
>>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/
365 649163
>>649132
>>649142

Это кстати не я отвечал (составитель высера про ECS), а какой-то другой чел. Я вообще не знаю про префабы, это что-то связанное с Юнити ECS а мне на него как-то похуй в силу того что я двиг только для рогалика затачиваю.

>>649132
Опять же, ты можешь любым образом как хочешь это делать. Можно создавать разные деревья систем, где одна другие будет вызывать и инициализировать. Можно создать систему которая будет подгружать сохранение, другое, а потом любые системы будут уже иметь доступ к этим массивам. Это в общем довольно узкий и местечковый вопрос.

>>649142
Годные ссылки. Что есть такое Префабы, это же действительно только в юнити ЕЦС реализации встречается? или я только что гранату?
photo2018-12-0601-13-20.jpg53 Кб, 604x604
366 649165
>>649142
Я вообще думал чтобы внутри игры у меня был огромный такой блядь сисЭм, который как планировщик принимал разные таски, или составлял расписание обхода по флагам, которые стоят у предметов. Не знаю точно, пока очень усердно думаю над тем как это можно разрулить это дело, чтобы изначально всё сука такое гибкое было пиздец. Есть уже много абстрактных описаний того как это будет работать, но пока не подвёл все эти вещи под общий знаменатель.
367 649175
>>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/
368 649178
>>649175
А, то есть паттерны такие? Ну вот допустим я когда задумывался над этой темой пришёл в выводу о том что следует создавать отдельную систему и тип компонентов отвественных за подгрузку моделек в игру, а там уже для каждой ентити просто опять же давать id этой модельки, или текстурки. Но не знал что такой метод называется префабом.

Кстати почему ты так красноречиво отозвался о юнити? я слышал краем уха про его Job System и Burst, разве это дело не исправило? (Сам потом подумывал после рогуля попробовать юнити как движок для песочницы)
369 649182
>>649175
да, я думал про то как такие префабы организовывать в условии когда у меня каждое существо будет состоять из органов тканей и прочего, как это ToadOne делает, только более интересным образом я это провернул. Там у меня получаются лютые деревья, и я пока вообще совершенно не имею понятия как организовывать gameObject-creature. Я могу высраться о том что я там накириллил в еверноуте, раз Оп давно обосрался насмерть.
370 649183
>>649182
Братюнь, каждый день, когда ты думаешь над своей мега-системой, ты над ней не работаешь. Это у тебя такая форма прокрастинации. Начни делать хоть как-то, хоть по чуть-чуть, сделай первую хуёвую верию, зато сделав её, поймёшь, как надо делать лучше и начнёшь делать лучше. Я сам такой.

> Кстати почему ты так красноречиво отозвался о юнити?


Потому что хуюнити вообще и сирешётка в частности - это распиаренное говно для нубов, которые существуют только из-за нечеловеческих вливаний бабла в их маркетинг мокросовтом. Человек, профессионально занимающийся программированием или геймдевом, это говно будет десятой дорогой обходить.
Если перейти на язык метафор, это как если бы качок вместо того, чтобы готовить себе условную куру с гречей и прочий спортпит, жрал бы в макдаке.
gaem.gif604 Кб, 800x595
16pixel 371 649187
Ого как тред подорвало.
Ну, во-первых, братюни, спасибо за обстоятельные ответы.
Прежде чем сформулировать следующий вопрос, отправляюсь изучать данные ссылки и матчасть.

Гифка текущего прогресса, ака "костыли и велосипеды", для поддержания интереса к треду.
372 649191
>>649183
Да, я слышал что решётка это хуйпизда по перфомансу, поэтому сразу перепрыннул на Rust-lang.

>Братюнь, каждый день, когда ты думаешь над своей мега-системой, ты над ней не работаешь.



Весь как раз СЭС в том сейчас, что я стараюсь изо всех сил задрочить погромирование хоть на каком-то уровне чтобы написать что-то годное. Сейчас конкретно вроде более менее немного осталось чтобы уже схватить за жопу legion ECS (быстрая как понос либа на расте, на которой я немного попрототипирую) и bearLib чтобы попробовать хоть что-то высрать.

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

>>649187
Тут нас по идее 3 аутиста всего навскидку. Я тред уже год мониторю, ОП точно сдох.
373 649193
мне до сих пор не ясно нахера в "игровом движке" наружу торчит только шарп(который потом все равно в крешты перекатывается)
зачем эта прокладка? типа легче что ли?
374 649194
>>649191
Ну и ладно, качество > количества. И я не ожидал, честно говоря, что задав вопрос получу ответ, это же двач. А оно вон как.

И раз тред называется "рогалики", я так понимаю что это не тред одного анона а что-то вроде sharing saturday на r/roguelikedev, так что можно лить любой свой высер (что и делаю, лол).
=> Давайте лить.

(алсо, разглядывая гифку, нашел багу в расчете line of sight. Так что постить в тред еще и полезно!)
375 649196
>>649194
определённо это дело надо оживлять.

>>649193
Я вообще ни шарп ни уните не знаю, но предположу что шарп легче + есть возможности использовать заместо стандартного GC шарпа какие- то хитрые GC в Burst заточенные именно под игорьки
My+eyes+bleed+from+reading+so+much+in+one+sitting+c2b1cc660[...].png21 Кб, 297x200
376 649211
>>649187

> Comic sans

377 649212
>>649191

> Да, я слышал что решётка это хуйпизда по перфомансу, поэтому сразу перепрыннул на Rust-lang.


Тоже зашквар, конечно, но не такой страшный, как мокросовт - ржавчину проталкивает мозилла, они, несмотря на засилье сжв-пидоров, вроде как за свободный интернет и всё такое.
378 649215
>>649212
Почему Rust зашквар? Он довольно быстрый, очень безопасный, что для многопоточных приложений вообще самая мякотка. Чтобы писать такого же качества код без сегфолтов на С++ надо отхуярить на нём десяток лет.
379 649368
>>649215

> Он довольно быстрый, очень безопасный, что для многопоточных приложений вообще самая мякотка. Чтобы писать такого же качества код без сегфолтов на С++ надо отхуярить на нём десяток лет.


Если закрыть глаза на сырость языка, с этим твоим аргументом я полностью согласен. Повторю свой аргумент ещё раз: rust проталкивает mozilla. Я не верю в языки, в маркетинг которых вкладываются многомиллионные транснациональные корпорации. Если язык так хорош, зачем ему маркетинг? Спецы увидят, что он хорош и будут его использовать из-за того, что он хорош, а не из-за того, что из каждого утюга им говорят, что он хорош.
380 649376
>>649368

>rust проталкивает mozilla


Зачем?
381 649388
>>649376
Я думаю, чтобы вставлять палки в колёса гуглу с его Goвном. Зачем, по-твоему, были созданы Java, C#, Go, Rust? Чтобы оттяпать долю айтишного рынка.
382 649411
>>649368
Ну во первых это уже выходит за рамки самого языка, а входит в рамки психологии, что там кто увидит и почему кому-то внезапно надо переходить на Rust.

Могу сказать только то, что он удобный, у него есть хороший подгрузчик модулей crates, но пока попросту нету софта нужного. Вообще я понял что разрабам С++, особенно старичкам таким будет очень хуёво на Rust из за того что правила написания кода запрещают мутить просто так какую-то хтоническую хуйню с памятью, чем обычно и занимались они на крестах. Вместо этого подобные проблемы на расте решаются общим пересмотром метода решения задачи. Конечно если и единицы исключения, которым будет легко поменять парадигму в голове, но таких много. Вот и получается, кто старший давится синдромум утёнка и говорит что раст это говно, а кто младший и только вкатывается в основном обсираются из за его сложности. Я в общем-то срал на все эти политические маняврирования корпораций, просто похуй, понимаешь бля? Если я беру инструмент и смотрю что он хороший, то похуй какой там логотип.

>>649388
Вот опять же, нас эта пизделовка вообще не касается, потому что если человек достаточно ясно видит всю хуйню, он сам увидит пытается ли маркетинг сраку жёваную впарить или же что-то стоящее. Реальность over Видение.
383 649419
>>649368

>Если закрыть глаза на сырость языка


Первая стабильная версия вышла 5 лет назад, проснись.
Язык уже стабильнее некуда, никакой "сырости" там нет, его уже спокойно юзают в продакшене овердохуя компаний.

>Я не верю в языки, в маркетинг которых вкладываются многомиллионные транснациональные корпорации


Шизик, тогда тебе нельзя программировать на c# - его многомиллионный майкрософт создал и продвигал. На джаве тоже нельзя - её многомиллионный оракл продвигал.
На С++ тоже нельзя, его развитием и продвижением занимались десятки многомиллионных компаний, в том числе и майкрософт.
С твоими критериями тебе остается два языка на выбор - бейсик и фри паскаль, выбирай.

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


Чтобы "спецы" про него узнали, нет? Откуда они еще узнают про язык, если про него не будут рассказывать, а просто где-то на серваке будет лежать билд, без описания, документации, статей.
Ты совсем поехавший, или притворяешься?
384 649420
>>649419
Я не он, но анонче не ругайся и не разводи срачи. Блять хоть не тут, нас и так мало вы ещё срётесь.
385 649421
>>649419

> тебе нельзя программировать на c#


А я что, разве давал повод подозревать себя в таком страшном говноедстве?
386 649448
раз уж тут за языки трут, что думаете о jai посоны? пилится игроделом для игроделов, философия мне по нраву
https://sites.google.com/site/jailanguageprimer/
image.png61 Кб, 881x628
387 649454
>>649448
Ну у него интересные есть особенности, бесспорно. Но без долгой разработки и большой базы людей которые работают с этим ЯП это к сожалению говно без задач. Есть огромное количество всяких годных языков андеграундных языков, но мне кажется адекватный человек который собирается пилить долгоиграющий и большой проект не будет выбирать что-то подобное. К сожалению.

Алсо, нашёл репку на гитхабе и обосрался. Нет спасибо точно не надо.
388 649475
>>649454

>ряя я не верю в языки, в маркетинг которых вкладываются многомиллионные транснациональные корпорации


>ряя язык пилит полтора инвалида в свободное от работы время, нинужон


У тебя биполярочка?
gaemcons.gif100 Кб, 654x458
16pixel 389 649495
А мы продолжаем пилить рогалик на пиииииитонеее 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 для каждого этого объекта.

Так примерно?
390 649519
>>649495
Зачем тебе в рогалике ECS?
16pixel 391 649521
>>649519
Ну надо
gaemcons.gif150 Кб, 655x458
16pixel 392 649525
А, line of sight забыл!
Поправлено.
Все что угодно, лишь бы нормально не писать дальше. Хотя именно эту часть мне кажется я сделал заебца.
16pixel 393 649551
Так, падажжите посоны, я кажется вкурил в ецс
Попробую - отпишу
394 649559
>>649475
Конечно, потому что это писал не я.
395 649560
>>649551
Дак я что, недостаточно выше описал а бляТЬ? Просил же вопросы вопрошай.
396 649562
>>649495
Из того, что я понял про ECS, чтобы адекватно перекатить это все в эту модель, нужно:
1. Удалить нахуй Класс Creature Создать Класс Component и написать ему базовые методы взаимодействия (добавить удалить найти). Отнаследовать Component и сделать каждый такой тип, а также массив данных внутри него.
2. Все методы и весь испольняющий код вытащить наружу и сделать только как классы без полей. Сделать так чтобы системы были ориентированы только на работу с определёнными компонентами.

Но понимаешь какая фишка. Сейчас твой год нельзя просто взять и перенести на ECS, потому что ECS это очень глобальное изменение архитектуры кода. Советую сразу найти либу на питон для ECS и не пытаться что-то своё городить если не понимаешь есц глубоко.
А вообще советую хуй забить на него потому что реально без понимания ты только ещё больше запутаешься в каше из методологий ООП и ЕЦС и потом будешь орать "УЛЮЛЮ ЕСЦ ГОВНО БЕЗ ЗАДАЧ ДЛЯ ПИТУШКОВ"
image.png31 Кб, 765x537
397 649563
>>649519
Да в любой игре если она обещает быть комплексной более менее требуется ЕСЦ, потому что он решает проблемы связности кода, перекрёстности механик, и скорости работы.
Конечно если ручки прямые.
А для рогаликов писать их на ECS сам бох велел
398 649564
>>649495
https://habr.com/ru/post/490500/

Вот хорошая статья кстати
399 649586
>>649563
Можно конкретный пример, как ецс облегчает жизнь?
400 649600
>>649586
Орды зомби. Если выхватить из толпы одного из них, он ведёт себя как зомби: бежит, хватает, кусает, рычит. Все вместе они обсчитываются, как жидкость, которая растекается по локации, заполняя пустоты.
На других паттернах ты заебёшься такое делать, а сделав, заебёшься оптимизировать. На ЕЦС у тебя будет две системы: зомбиОрда - обсчитывающая поведение жидкости, состоящая из частиц в виде отдельных зомби, бегущих при движении и стоящих при остановке, и зомбиНПЦ - которая выхватывает "частицы" у орды, накидывает на них свой набор компонентов и убирает компоненты орды. После чего частица жидкости превращается в зомби и накидывается на тебя. Соответственно, перехватывает частицы при приближении к игроку, отпускает при удалении (при условии, что выделенный зомби перестал преследовать) и зомбиОрда снова подхватывает ничейную сущность, как свою частицу, навешивая на неё свои компоненты.
Соответственно, при добавлении простых НПЦ, если они заражаются, они перехватываются одной из вышеуказанных систем.
401 649601
>>649586
Связности меньше. У тебя есть данные, разные виды которых ты можешь свободно удалять и добавлять. Есть системы, которые друг с другом не пересекаются по сути и не лезут в функционал друг друга. Опять же не связные.

В большинстве приложений (особенно сделаными дилетантами) связанная архитектура можешь сам нагуглить проекты, примеры или игры если хочешь это подтвердить, не хочу тратиь на это время. Тобишь отдельные части системы связанны между собой, легко изменяемы и прочее. Если мы берём в пример игру, то при использовании стандартных методов проектирования её системы растут и вверх (наследование) и в стороны. части программы должны как-то общаться и часто сложным образом взаимодействовать между собой. Из за этого части модули очень крепко подогнаны под вероятный функционал других модулей, из за чего добавление нового функционала становится всё сложнее и сложнее, а баги скрывающиеся в этой паутине могут быть очень заковыристыми. ЕСЦ просто растаскивает данные и логику по разным углам, поэтому системам не требуется доступ к другим системам, потому что они ничего не хранят ВООБЩЕ (ну разве что может какие-нибудь внутренние служебные переменные исчезающие при проходе системы). Из за этого связность очень сильно уменьшается, приложение растёт теперь только по горизонтали, любой модуль можно спокойно вытащить и переписать не боясь что он что-то сломает (если конечно ты сам не напортачил, потому что шанс обосраться тебе дан всегда.)

Читани тут
https://github.com/adnzzzzZ/blog/issues/24
402 649602
>>649600
Какое у тебя конечно ебанутое описание, анон)
403 649616
>>649586
Поиграй в caves of qud, хороший пример рогалика, построенного на ecs.
В ней все предметы, артефакты состоят из компонентов.
Например, есть броня, к которой подключен компонент контейнера для жидкости - и в ней можно хранить воду, сюжетно это объясняется тем, что в неё встроены меха для хранения воды. Если подключить компонент питания от батарейки - броне потребуется заряд, нужно вставить в неё батарейку, чтобы работала, и т.д.
С ООП подходом ты быстро и элегантно это не решишь, т.к. множественного наследования нет в большинстве языков, а там где есть - это костыль и антипаттерн, тебе придется городить костыли и обрабатывать этот случай в особом порядке. А с ecs все просто, у тебя есть базовая сущность, ты накидываешь на неё набор компонентов - компонент брони, контейнеры, питания - и ты можешь надевать этот предмет, хранить в нем воду, питать от батарейки.
>>649495
Начни с того, что выкинь питухон и возьми нормальный язык с готовыми многопоточными реализациями ecs, например rust + specs/legion.
404 649627
>>649616
Ну наконец-то нормальные советы подъехали, как же я без этого жил-то. Теперь точно перейду на нормальный язык, либы подключу нормальные, рогалик напишу многопоточный, с ECS у меня наконец будет.

Серьезно, давай без языкосрача. Я пишу рогалик потому что меня конкретные вопросы волнуют; я их решаю и учусь на этом. Вопрос выбора языка в этих вопроса не присутствует.

>>649562
Скоро отпишусь по теме
405 649632
>>649627
>>649616

Внезапно на питоне тоже есть ECS реализации. Напиши свою или возьми эту. Тоже интересный экспириенсь
gaem.gif5,2 Мб, 945x565
16pixel 406 650122
В общем, про 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/, но я вкуриваю тупо и медленно, поэтому пока без теней - реализовал расчет октантов и накостылил гибрид рейкастинга и кастинга октантов. Гифку прилагаю.

Ах да, двойной вывод, лол.

Всем добра
407 650130
>>650122

>Применение данного подхода требует определенного анти-логического мышления - очень непривычно, что все объекты, с которыми ты в коде работаешь (ну, или максимальное их количество - смотря как напишешь ECS) это просто обертка, в которую может быть насовано все что угодно, любые методы, которые на самом деле еще и объекты.



Это значит что ты его нихуя не понял. Как раз копоненты и есть более естественный метод для программирования не только игр вышесказанных, но и вообще любых симуляций (читай игр) где у тебя есть много одинаковых объектов или большое количество пересекающихся аспектов программы (это важная черта игр.)
408 650136
>>649632

> ECS реализации


Второй год удивляюсь, как народ трепещет перед ЕЦС, будто это какая-то невъебенно сложная технология. ЕЦС состоит из 2х частей:
1. Никакого наследования, только композиция.
2. Глобальные переменные достаём из файлов с данными.
Вот и весь ЕЦС.
409 650145
>>650136
Потому что когда дело доходит до реализации всплывает немало проблем связанных с тем что технология требует использовать другую парадигму построения программы, не ООП к котому все привыкли а компонентно ориентированную. Также есть много проблем связанных с тем как реализовать саму ECS, ведь там есть сотни разных подходов так скажем.
410 650152
>>650136

>Вот и весь ЕЦС.


У кукаретиков всё просто, а ты попробуй написать нормальный производительный рантайм для ецс, жидко обмякнешь.
Specs например строит граф зависимостей систем, смотрит какие системы какие компоненты используют, и на основе этого параллелит выполнение по ядрам процессора, чтобы ты мог не Х сущностей обработать за такт, а число ядер * X.
Legion ecs позволяет делать sql-подобные запросы, чтобы отбирать сущности для обработки, типа, выбрать сущности, у которых есть компонент Х, нет компонента У, а параметр Z компонента W больше или равен какой-то величине, при этом работает это очень быстро.
411 650272
>>650152
Подтверждаю.
Подходов для даже простого решения как реализовать хранение компонентов и каком виде немало. При том что каждый из них даёт свои бенефиты но и ограничивает.

>>650122
А тебе скажу - выброси нахуй ЕСЦ если пользоваться им не умеешь. Нельзя просто части игры перевести нп использование комопнетов, ты только больше усложнишь код и сделаешь такую хуйню в которой сам увязнешь.
412 650281
>>650152

>Specs например строит граф зависимостей систем


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

алсо, ты не понимаешь сути рогалика. там событийная архитектура. там нет смысла в чистом ECS. компоненты - это по сути просто обработчики событий.
14928254377633.jpg68 Кб, 640x622
413 650286
>>650281

>компоненты - это по сути просто обработчики событий.


сука иди нахуй необучаемый
414 650288
>>650286
У него все нипанимают, один он ПОНИМАЕТ.
Ни одного рогалика, тем более на ecs, он естественно, не сделал. Он просто ПОНИМАЕТ.
415 650289
>>650122

>ECS штука совершенно роскошная, если ты пишешь что-то типа dwarf fortress или caves of cud, где тебе нужно, допустим, чтобы сундук и предметы хранил и диалоги мог разговаривать



А вот если бы ты прочитал книгу банды четырех про паттерны, то внезапно бы обнаружил что данная задача (а именно конструирование объекта из компонент (не путай с ecs)) давно уже решена в классическом ООП множеством способов

(подозреваю что многие "фанаты" ECS просто ничего не читали по ООП, вот им и кажется что это идеальное решение.

То что сейчас все писаются радугой при любом упоминании ECS - потому что такова природа программистов - все хотят быть не как все. Мода пройдет, и ECS станет антипаттерном за который через пять лет будут бить по рукам топором.

А всё потому что у ECS есть куча недостатков:
- плодит сущности, что сильно усложняет код и ведет к спагетти-коду. Читать такой код невозможно. В реальном мире, в мире программистов и в мире ООП - сундук, это сундук. В ECS - нет никакого сундука. Есть цифровой идентификатор под номером таким-то, есть стопятсот компонент и есть стопятсот систем под каждый компонент.
- совершенно не приспособлено для отладки - так как часто невозможно идентифицировать логические связи.
- кроме того по факту почти невозможно выделить компоненты независимыми друг от друга - рендердрав никак не сможет без трансформа и т.д. из-за чего ECS все равно превращается в обычное ООП с костылями чтобы сохранять видимость ECS (аля юнити)

Короче, у ECS нет будущего.
416 650290
>>650130

>Как раз копоненты и есть более естественный метод для программирования не только игр вышесказанных, но и вообще любых симуляций (читай игр) где у тебя есть много одинаковых объектов или большое количество пересекающихся аспектов программы (это важная черта игр.)


нет. ECS реально требует другого мышления. А то что ты описал - это обычная агрегация из ООП (то есть возможность выделять разные черты в разные классы - это не компоненты из ECS)
417 650291
>>650289
давно уже решена в классическом ООП множеством способов
Ну так покажи мне пожалуйста хоть один удобоваримый способ, чтобы это не проёбывало масштабируемость и не срало на раскладку данных в памяти пожалуйста.
418 650293
>>650290
Подумал немного, с этим согласен что агрегация/композиция тут будет более "естественна", но при правильном подходе ECS может очень гибко жонглировать свойствами объектов даже прямо в runtime.
15453633836143.jpg263 Кб, 604x604
419 650294
>>650289

>есть стопятсот компонент и есть стопятсот систем под каждый компонент.


Вопрос организации кода. Если на ум ничего больше не приходит как нахуярить сотни компонентов, то это проблемы твои а не концепции.

>совершенно не приспособлено для отладки - так как часто невозможно идентифицировать логические связи.


опять же глупость полнейшая, написать профилировщик или отладчик который будет выводить информацию по иерархии систем или создавать слепки с ентити, распределяя их по типам (опять же это всё вопросы реализации)

>кроме того по факту почти невозможно выделить компоненты независимыми друг от друга


Кто вообще сказал что их нужно разделять и делать независимыми?

В общем вся твоя писанина выглядит так что ты намеренно не пытаешься копать глубже а твоя задача обосрать ECS по дефолту, намернно подибраешь самые глупые из возможных решений в ECS реализациях чтобы выставить его говном a priori, а не понять что действительно лучше. Если будешь продолжать в том же духе, то уёбывай дядя.
420 650321
>>650291

>Ну так покажи мне пожалуйста хоть один удобоваримый способ, чтобы это не проёбывало масштабируемость


решений много. Даже банально:
class Entity{
array<Component> c;
};
(то есть избавляемся от систем, и храним компоненты в самом Entity - это ООП, а не ECS)
А так, фасад, билдер, фабрики и т.д.
На геймдеве еще был пример асспекто-ориентированного подхода.

>>650291

>и не срало на раскладку данных в памяти пожалуйста.


а ты уверен что тебе в твоем рогалике это нужно? кеш-фредли вообще-то для консолей старого поколения делали, у которых процы как говно. Для пк это уровень "буду писать рогалик на ассемблере".
ААА игры на классической нодсцене ни у кого не тормозили даже 20 лет назад, а твой рогалик вот не сможет работать?
421 650322
>>650294

>Вопрос организации кода. Если на ум ничего больше не приходит как нахуярить сотни компонентов, то это проблемы твои а не концепции.


если ты весь функционал фигачишь в один компонент - то ты нарушаешь концепцию ECS
В ECS ты должен выделять наибольшее количество компонентов. И конечно под каждое из них будет своя система. В тех же презентациях рогаликов показывали на экране сотни компонент.

>>650294

>Кто вообще сказал что их нужно разделять и делать независимыми?


сама философия ECS.

Короче, всегда ржал с людей которые защищают ECS, но при этом совершенно неправильно его понимают.
422 650326
>>650321
>>650322

>решений много.


Вопрос реализации.

>а твой рогалик вот не сможет работать


Запас производительности всегда можно куда-нибудь потратить.

>В ECS ты должен выделять наибольшее количество компонентов.


>если ты весь функционал фигачишь в один компонент - то ты нарушаешь концепцию ECS.


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

>сама философия ECS.


Философия ECS говорит делать данные от систем независимыми. А отношениря между саими данными регламентируются не так прочно и являются предметом споров.

>но при этом совершенно неправильно его понимают.


Ты блять пропогандист своего мнения просто, и этот >>650288 среньк про тебя скорее.

В общем отвечу если что когда что-нибудь годное по-настоящему выскажешь.
423 650327
>>650326

>Вопрос реализации.


ну вот например я сейчас ковыряюсь с паттерном property container - оно делает то что нужно - возможность добавлять новые свойства классу без всяких там наследований и т.д.

>>650326

>Запас производительности всегда можно куда-нибудь потратить.


не факт что этот запас будет, да, компоненты кеш-фредли, но вот оно будет жрать больше памяти (потому что компоненты надо выделять один раз с запасом в огромном куске памяти, иначе не будет этого кеш-фредли).
Да и там возможно такие мизерные запасы
424 650332
>>650327

>ну вот например я сейчас ковыряюсь с паттерном property container


Интересная штука. Насколько абстрактно она реализуется?

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


ну в основном это относится к менеджменту памяти. Обычно компоненты всегда лежат одинаковыми блоками. Конечно постоянное удаление-добавление фрагментирует память, но вполне можно сохранять свободные индексы или дефрагментировать в потоке это всё дело. Наблюдай за тем как legion ECS справляется с этой задачей, я его как раз ковыряю сейчас.
425 650348
>>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.
426 650426
>>650286
напоминаю что речь о рогаликах.
что ты там в системах собрался обновлять каждый кадр? что ты собрался распараллеливать, когда результат каждого хода и каждого события строго зависит от предыдущего?
427 650437
>>650426
Если брать такие рогалики как ADOM, Nethack и суп, то да, это будет совершенно излишним, потому что в них мир существует только в рамках замкнутого данжона.

Но возьми что-то наподобие Cataclysm DDA (с его открытым миром) или Dwarf fortress (с его глобальной симуляцией) то тут уже можно будет пойти другим путём - сделать "ленивые вычисления" глобального окружения опенворлда, ну это как пример.

Далее насчёт распаралеливания. Технически можно не создавать квантированные ходы, а сделать допустим 100 милисекунд. Игра будет "как-бы" технически рилтайм, но на деле игра будет ждать действия игрока, выполнять его (пойти в клетку, атаковать) а потом опять застывать и ждать.
Любые выполняемые действия в игровом мире имеют точку старта и точку завершения, ничего не происходит мгновенно и любое действие прерывается при определённых обстоятельствах (потеря равновесия или отмена действия самим игроком, если он конечно успеет.)
428 650451
>>650426
>>650437

только в рамках замкнутого, квантированного по времени мира.
429 651304
>>650451
У тебя есть примеры неквантируемого мира?
430 651305
>>651304
Выгляни в окошко да посмотри.
431 651440
>>651304
Примеров по-сути нет, тут скорее хотел указать на явное разделение.

>>651305
Лол да.
432 652121
>>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.
432 652121
>>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.
433 652146
>>652121

> Общий принцип таков: все ресурсы загружаются через библиотеку, а библиотека сама решает, когда нужно загрузить файл с диска, а когда достаточно отдать ссылку в памяти на уже загруженный ресурс.


У меня то же самое, только назвал другим словом.

> Абсолютно ничего сложного, и уж намного проще ECS.


К ECS оно ортогонально, можно эту идею и без ECS использовать, но вместе веселее.

> Pascal


Брат братан братишка
progress.gif2,9 Мб, 1098x637
16pixel 434 655766
На правах бампа - пишу о прогрессе рогалика на питоне.

Долго пинал балду, почему-то не хотелось ничего делать (плюс fallout sonora сожрала неделю, не жалею ни о чем). Но как только открыл код, меня сразу понесло.

Много чего переписал, побаловался с форматом dictionary (все объекты на карте до этого хранил в listах), переписал немного работу со спрайтами pygame - все стало работать пошустрей. Вообще понял, что для меня лучше всего работает подход "реализовать через жопу - отрефакторить."

До сих пор не пофиксил line of sight/field of view. Сломал голову об ECS, в итоге забил, так как понял, что или я в эту тему буду въезжать целую вечность, либо доделаю игру до играбельного состояния. В итоге yolo-кодинг победил.

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

Также сделал вывод в консольку черезжопным интересным образом - у каждого creature в игре, включая player-а, есть свой лог, который по сути простой list. Действия аппендятся в этот лист (естественно, если элементов в нем больше 10, то первый удаляется к херам, а новый записывается в конец). И в main-е мы просто дергаем последнюю строку лога playera и выводим ее на экран.

Пока простой концепт рогалика полагаю такой - есть какое-то количество этажей, выход с каждого этажа закрыт, ищем ключ, открываем дверь - ломимся на следующий этаж. На последнем валим жирного монстра - конец игры. Все остальное опционально и в рамках отработки навыков.
435 655807
>>655766

> Сломал голову об ECS, в итоге забил


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

Хотя я всё еще не могу понять что могло в ECS тебе быть не понятым. Я в него въехал буквально сразу.
progress.gif15,5 Мб, 1061x744
16pixel 436 656680
>>655807
Как концепт - понятен. Как его накостылить - не вполне понятно.

Я пытался почитать код пары доступных ecs-систем питонячьих, но там уровень абстракции сразу максимальный, а я птичка, мне такое сложно.

Например, тема с системами не ясна.

Есть у тебя entity player. Ты создаешь объект move - и чего с ним делать-то? Как должен быть сделан этот объект move, чтобы у тебя компонент coordinates в player-е поменялся? Какая система и как его должна подхватить, что с ним сделать?

(алсо, добавил дропы, инвентари мобам, id-шники предметам чтобы спрайты было легче рендерить, тред живи)
437 656742
>>656680

>накостылить


А его и не надо накостыливать по сути. На ЕСЦ игру с нуля пишут, внедрять его по ходу - это ебантяйство.

>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 раз тебе так сложно.
437 656742
>>656680

>накостылить


А его и не надо накостыливать по сути. На ЕСЦ игру с нуля пишут, внедрять его по ходу - это ебантяйство.

>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 раз тебе так сложно.
438 657311
Как же вы заебали со своими ECS, не ецс. Главное, чтобы проект был удобным в разработке и его расширении в дальнейшем, ну и чтобы код удобно читался. ВСЁ! Найти баланс между этим говном. Если ты нашел идеальный баланс для себя, то остальные абстракции нахуй плодить не надо. Парадигма ооп на сегодняшний день пока одна из самых удобных, а ецс это темный лес. Иногда бывает, что ты сам того не зная, строишь свою смесь из ооп и ецс из говна и палок.
progress.gif2,3 Мб, 975x628
16pixel 439 657505
Истинно так.

Хотя до меня тут недавно доперло, что говоря про ecs я на самом деле говорил про паттерн command. И все равно я не понимаю пока как его использовать. Как пойму скажу (как будто кому-то не похуй)

А еще pygame не умеет выводить text в несколько строк, пизда прост. Такие-то костыли воротим
440 657513
>>657505
Я на полшишечки сам читаю, но на pygame пилю только тогда, когда мне заняться нечем
441 657572
>>657505
Да ты пока его вообще не вдуплил.

>>657311
Не ори, дядя.

>удобным в разработке


>остальные абстракции нахуй плодить не надо


Как? Покажи удобный метод для создания расширяемого кода. Про абстракции вообще загнул. ООП это тебе тоже абстракция над ASM и что? ECS становится полезен когда программный код изобилует перекрёстными взаимодействиями, или игровые сущности имеют один корень и природу, и должны мочь очень гибко её принимать, не вызывая конфликтов. Такой подход дюже помогает при написании игровых симуляций, или систем, опять же, с большой комплексностью, или перекрёстным взаимодействием. Естественно при таком раскладе для пиления игорей с относительно простой логикой, типо гриндилок, плоской индюшатины, или топорных дунжон кроулеров (чем собственно и завален сейчас игропром, не говорю шо это плохо) ECS нахуй не всрался, и как ты сказал, будет просто не удобен, и есть более удобные и известные методы. Но если ты хочешь сделать что-то такое суканах комплексное, по типу ДФ или Римача (что первое в голову попалось), то тут ECS начинает уже быть чертовски полезным, по вышеописанным причинам.
Если до сих пор вы не вдуплили положняк и у вас не осталось адекватных вопросов, то вы просто долбоёбы блядь и мне страшно за вас и игропром.
442 657578
>>657311
Так шо всё дело в инструменте. Я не говорю что ECS лучшая религия, просто пытаюсь пояснить тутшней питоноуточке за ECS, но что-то он шибко туго всасывает. Плохие догадки о его интеллекте у меня возникают.
443 657614
>>657578

>питон


>Плохие догадки о его интеллекте у меня возникают.


Они только сейчас у тебя возникли?
Человек с двузначным и более IQ не стал бы писать игру на питоне.
15770447782280.jpg78 Кб, 433x419
444 657665
>>657614
Лол, у меня кажется у самого двузначный IQ раз я только сейчас на это внимание обратил.

Ну вообще в оправдание скажу, что я думал он просто тренируется или прототипирует.

Алсо, скоро-то тред потонет уже, а Оп давно уже хуй. Не знаю, есть ли смысл перекат делать
445 657683
>>657505
В Питоне не нужен паттерн комманд, потому что там функции и без того являются объектами.
progress.gif2,5 Мб, 1438x767
16pixel 446 657711
>>657683

Пока не могу прокомментировать, поясни.
https://refactoring.guru/ru/design-patterns/command/python/example говорит, что не так очевидно всё

>>657614
Я еще и код в тред кидать начну, лол.
На самом деле, прямо сейчас начну. На скрине - мой костыльно-заглушковый способ реализации AI.

Все равно никто кроме меня в этот тред контент не кидает, а ваша обратная связь очень ценна.
447 657712
>>657711
Да ладно кидай, это всё равно намного лучше чем сидеть и бухтеть без дела как мы.

>говорит, что не так очевидно всё


Да нет, не то чтобы это неочевидно. В других языках реализация команды обычно сложнее. Через наследование и т.д.
448 657731
Ну и еболу же я написал, пиздец
Но все равно ожидаю закидывания хуями, не зря же гифку делал
449 657734
>>657731
Говорю же, если ты что-то делаешь, даже хуйню, это всяко лучше чем ничего не делать. Как мимнмум ты опыт получишь.
450 657735
>>657731
Пока все работает в 60фпс/по дизайну - забей. Дохуя инди игр в релиз с говнокодом выходят, а диванные кукаретики и дальше байты дрочить будут
мимо Тодд Говард
progress.gif1,1 Мб, 1438x767
451 657753
Как-то так.
452 659095
Ананасы, а что на счёт рогаликов с сюжетом?
Или же рогалики но не пошаговые? Как это правильно будет называться?
453 659115
>>659095
Тру рогалики с сюжетом это взаимоисключающие параграфы. Сюжет всегода предполагает более-менее рельсовый геймплей, что для рогаликов вообще-то непростительно. Правила мира там должны всегда работать свободно в каждом моменте времени. Конечно можно говорить про адаптивные системы сторителлинга, которые сюжет бы тебе пилили исходя из твоих действий, но до таких технологий пока люди не досрали.

>но не пошаговые?


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

rougelite это как попытки под рогалик, но несоблюдающий некоторые пункты. Но вообще с такими вопросами в /ro/
454 659411
>>659115
Я это вообще к чему
Обчитался тут на самоизоляции исходников эмулятора сервера вов (всегда было интересно как работают спелы пускай даже и в эмуляторе), да и руки зачесались что-то такое сделать
Вот и думал как можно отойти от неких установок/канонов чтобы было и интересно и проще играть
Пока додумался до такого: открытый мир (грубо говоря реалтаймовая игра) и подземелья (игра пошаговая)
Но вот как это всё учесть и продумать пока не дошёл до этого
progress.gif949 Кб, 1113x599
16pixel 455 660288
Похоже я максимально близко подошел к подобию 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() #задаем ему свойства контейнера

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

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

Из того, что можно посмотреть - сделал секретные комнаты, которые открываются, когда теребонькаешь рычаг, хе-хе. На гифке можно увидеть ее один тайл, т.к. расчет поля зрения кривой. Переделаю. Когда-нибудь. Наверное.
progress.gif949 Кб, 1113x599
16pixel 455 660288
Похоже я максимально близко подошел к подобию 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() #задаем ему свойства контейнера

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

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

Из того, что можно посмотреть - сделал секретные комнаты, которые открываются, когда теребонькаешь рычаг, хе-хе. На гифке можно увидеть ее один тайл, т.к. расчет поля зрения кривой. Переделаю. Когда-нибудь. Наверное.
16pixel 456 660293
А, бля, мужики! Я же годноту вам принес, и забыл запостить.

Когда искал 16-пиксельные тайлы для референса, набрел на просто охуенные два инструмента - tilemancer и tilesetter.

Первый для процедурной генерации тайлов и бесплатный, второй - для генерации сетов тайлов и платный.

Видос для первого - https://www.youtube.com/watch?v=idP3uO9gxlM&t.
Базарю, еще захотите.
457 660566
>>660293
Они всрантые довольно если честно

>>660288
Я рад шо у тебя получается что-то придумывать, охуенно. Только пока это не ecs а шото страшное пиздец. Но норм, хорошо идёшь
458 662926
Что на счёт сетевых рогаликов? Насколько они интересны?
459 664175
>>662926
если пошаговые то вроде как нихуя неинтересны. некоторые шизойды-завсегдатаи этого треда считают что рогалик должен быть обязательно пошаговым
460 664227
>>657665

>Алсо, скоро-то тред потонет уже, а Оп давно уже хуй. Не знаю, есть ли смысл перекат делать


Я здесь и постоянно заглядываю в тред. Писать сейчас просто нечего: работаю РАБоту, самоизолируюсь потихоньку. Времени на петпрржекты просто нет, с голоду бы не сдохнуть. Перекатывать однозначно стоит, потому что тема треда много кому интересна, как оказалось
461 664282
>>664227
Ну сам и перекатишь.
462 664353
>>664282
Договорились
463 664627
>>664175
Тогда надо делать сетевуху на подобие гантлента
https://www.youtube.com/watch?v=Kp9Mo9QuV2w
464 664659
>>664175
Ну я когда думал много пердел над гейдизайном, имхо конечно стандартная пошаговость Роугов уже протухла нахуй, при этом если хочешь въебать мультиплеер скорее всего тут требуется использовать рил тайм, или какие-то хитровыебанные методы. Но суть в том что рогалики это не какой-то спинномозговой дроч а тактика. А без пауз или пошаговости хуй тебе а не тактика. думал над какими-то системами а-ля Divinity original sin, где образуется "пузырь" в котором действовать могут все только по шагам. Но при этом этом на подумать у всех будет не так много времени, секунд 10-15 наверное. Но такая механика очень сильно неестественная, поэтому надо думать.
465 664889
>>664659
Просто темп игры не должен быть слишком быстрым
К примеру автоатака раз в полторы-две сек, таргетная система боя
Можно даже без коллизий между юнитами делать, а учитывать только расстояние до цели, угол
466 664898
>>664889
Ну про то что темп не должен быть слишком быстрым это да, как вариант скажем так.

Про последнее не понял.
467 664900
>>664889

>К примеру автоатака раз в полторы-две сек, таргетная система боя


а что, это вполне интересная идея, есть даже вполне успешные примеры(хотя к рогаликам они относятся вообще никак) - в FF14 емнип каждый тик равен строго 2.5 секундам. и ничего, люди вполне привыкают к такой системе, какие-то действия наперед просчитывают.
запилить что-то вроде такого а то и дольше - здесь возможно поиграться надо, может быть добавить какой-нибудь класс для спинномозговых с менее зависящими от тика способностями, может вполне выйти неплохо и нашим и вашим
468 664904
>>664900
система может и интересная, но мне как человек который дрочит на симулятивность кажется искуственной и ограниченной. Но как обусловненная игровая механика нормально.
469 664906
>>664898

> Ну про то что темп не должен быть слишком быстрым это да, как вариант скажем так.


Это я привёл в пример автоатаку, а вот допустим как было бы с кастерами
Например, каст идёт 1-1,5 сек, за это время ты думаешь что можно использовать дальше, как может ответить противник
Если это мгновенные заклинания (например, наложение доты), то надо прикинуть сколько она нанесёт урона за всё время (как вариант скалирование урона должно производится во время каста, а не постоянно обновляться)

> Про последнее не понял.


Это я имел ввиду карту и управление персонажем
Если формат тайловый, то тут, в принципе, не может быть понятия "удар в спину" и поэтому персонажу не нужно поворачиваться к противнику
Если же нет, то персонажа нужно повернуть к противнику

>>664900
Ну не обязательно фиксированный тик
Я рассуждал так: я знаю свои статы, свой урон, знаю хп противника, что он может сделать и исходя из этого я прикидываю за сколько секунд я его разложу (сколько ударов будет, какие способности я буду использовать и тд)
470 664907
>>664906
Опять же имхо это довольно аркадная конечно боёвочка. Если и брать рилтайм боёвку, то я бы выбрал что-то а-ля Rimworld, только заточеную под прямое управление. Только там надо порботать с тем как способности бы использовались.
471 664908
>>664907

> Только там надо порботать с тем как способности бы использовались.


Что ты имеешь ввиду?
472 664910
>>664908
Ну в моих кирилливаниях способности и их использонваие особым образом структурированы. Будет специальное меню способностей или навыков, в котором будет 2 метода использования способности. Первый - способность можно использовать из контекстного или радиального меню, которое вызывается если зажать кнопку способности. Это быстрый способ. Выбрал способность зажатием, и использовал. Но ограничение на одну кнопку способностей 8, или того меньше. Таких кнопки будет 2-4. Второй метод уже будет длинный, прямо непосредственно вызывает всё дерево или список способностей, так как они будут все размещены иерархично. Но при этом там будут сразу все способности для использования.
473 664911
>>664908
Алсо. Система конечно вырвана из контекста. Потому что подразумевается что она будет использоваться в игре где этих самых способностей довольно дохуя. По сути любые действия игрока могут попасть в эту категори, просто которые acton, а ля копать, разбирать, ссать и срать не используются так часто как присесть, пойти вправовлево, использовать и прочее, и выносить их в отдельную клавишу (как делают поехавшие рогули древности) вообще нет никакого ризона.
474 664912
>>664911
Ну 99% возможностей игрока, как я себе представлял, будут реализованы через способности.
Не все из них активные (те которые может использовать игрок), а просто как бы скрыты.
Например способность атаковать, носить определённые предметы, использовать какую-то магию и тд.
image.png232 Кб, 1341x872
475 664914
>>664912
Да. типо того. Вообще в идеале под любое действие любого существа должен быть единый фрейворк блять, ну или точнее технически это должно быть одного и то же действие. К слову насчёт магии - мне не нравится современное представление магии как просто ссаные действия которые делают урон и стоят маны, и всё, хуйня ебаная нассал.

Более интересна в этом плане система которая была в magicka, но при этом она довольно полсковатая конечно. Сила заклинаний там фиксированная, маны нет, нельзя регулировать мощность заклинаний соотвественно. А ведь тут такое раздолье для всяких интересных геймплейных механик. От простого создания нефиксированного манапула, который надо будет правильно менеджить и восстанавливать. Ведь по сути мана это свеого рода ресурс разума наверное. Тобишь если слишком истощать манапул мощными заклинаниями, то можно умереть нахуй. Но если знать ритмы восстановления маны, можно в них как бы входить и хоть не сильно ебашить заклинаниями так за то бесперерывно. Вообще в голове целая система есть ебическая, но я пока не знаю надо ли её вываливать.

Пик - кусок моих высерков.
476 664916
>>664914

> Вообще в идеале под любое действие любого существа должен быть единый фрейворк блять, ну или точнее технически это должно быть одного и то же действие



Ну я больше рассуждаю о технической стороне
Имел ввиду такое: у способности есть эффекты (какое-то их количество). Например, эффект нанесения урона, эффект накладывает (бафф\дебафф) что-то на цель (переодический урон\щит, к примеру) и тд
В общем, по сути, всевозможные механики игры.
477 664918
>>664916
А я тоже про техническое вообще-то.
Просто тут да, выставляется вопрос того как прикреплять логику к этим действиям. Будем мыслить в рамках ECS. Допустим у нас у базовой способности будут методы для получения каких-то данных. Мы можем получать допустим эти данные с помощью вспомогательных методов, которые могут дать нам:
- глобальные переменные
- данные от self ентити
- данные определённого ентити
- от всех ентити в определённой клетке
- от всех данных в определённой области.

Также мы может полученные данные собственно изменять.
Ещё нужно уметь чтобы с помощью способности можно было вызывать новые entity. Допустим нам надо создать какой-то эффект, или запустить процедуру вызова существа и прочее.
478 664920
>>664918

> Просто тут да, выставляется вопрос того как прикреплять логику к этим действиям


Думаю просто на каждый этот эффект пишется своя функция и всё
479 666172
>>664918

> Допустим у нас у базовой способности будут методы для получения каких-то данных. Мы можем получать допустим эти данные с помощью вспомогательных методов, которые могут дать нам:



Всё, мне кажется, не предусмотреть.
Я у эффектов сделаю поле "цель", точнее там перечисление: сам кастер, перед кастером, союзники рядом, случайный противник в радиусе от кастера и тд и тп
480 666326
>>666172
Ну конечно не предусмотерть, но всегда можно максимально возможно охватить вероятности всякие бля. Вот какие фичи может быть тяжело или невозможно реализовать из того что предложил я?
481 666363
>>666326
Имеешь ввиду это >>664914 ?
Ну это просто похоже на какое-то описание школы магии или способностей.
Вот, к примеру, "Сбивающий поток воздуха" это стан цели. "Пневмовзрыв" может быть откидывание врагов на небольшое расстояние. "Защитный вихрь" ну это щит поглощающий урон.
482 666756
>>666363
Ты не в ту сторону думаешь
483 666766
>>666756
Объясни тогда своё виденье
484 666795
>>666766
Да ты не то чтобы что то не правильно сказал. Тут скорее просто с наскока не пояснить за то как стоит вообще логику игры организовывать. условно говоря когда у тебя код организован классами, все данные в нём строго инкапсулированы, и у них как бы есть такие интерфейсы через которые код может общаться, то есть ты не можешь просто взять и из класса с одной логикой въебать модификацию данных в соседнюю логику (можешь считать это системой, или чем паче вообще объектом игровым). тебе обязательно нужно прописать взаимодействие это. Тобишь между разными кусками кода тебе приходится пилить паутину связей, чтобы всё работало. Это огроме переусложение, и создаёт большую связность. Это как раз причина того почему комплексных игорей очень мало, потому что писать логику в таком положении ебически сложно, так как связность растёт геометрически. (Возможно я драматизирую но пока из того что я видел получается именно так)
485 666796
>>666795
Ой блять падажи. у меня шиза ебанула, я не о том написал.
486 666808
>>666795
>>666796
Короче говоря, нужно сделать прототип чтобы было наглядно
487 666809
>>666766

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

Я пытался просто пояснить тебе некоторую концепцию организации кода, на парадигме DOD, когда данные валяются в общей куче и любая система, логика или скрипт свободно может иметь ко всем этим данным доступ. Поэтому мы можем легко писать и вызываю из любых точек кода любые системы которые могут без предварительной смазки читать и менять данные по всему игровому миру.

https://translate.google.com/translate?hl=ru&sl=fr&tl=ru&u=https://github.com/adnzzzzZ/blog/issues/24

Вот тут кароче поясняется суть этого принципа.
488 666813
>>666808
Выше я скинул гуглоперевод стати где говорится что то шо япытаюсь пояснить будет приводить свои дивиденты только позже, когда код твоей игры станет уже слишком сложным.

Да, надо действительно сделать какой-никакой прототип. Слухай, у тебя есть телега или мою возьми @adeeee6622, а то мы тонем тут немного...
489 667090
Эх, все обсуждают дженерик рогалики, но никто не пилит свою уютную сосаку-13, там ведь логики гораздо больше надо пилить и думать больше надо.
Например если просчет электричества ещё не такое сложное занятие (хотя там тоже можно вставить всякие законы ома и прочее в отличии от оригинала), то современный просчет физики газов и их смешивания, химия и генетика (а не та бутафория в нынешней сосаке), медицина, операции и болезни потребуют пиздец дохуя сеансов мозгового штурма.
В соло подобное пилю, но единомышленника пиздец как не хватает.
490 667135
>>667090
Сто такое соска13?
491 667239
>>667135
Space Station 13
492 667269
>>667090
А попроще ничего нет желания? Типа в районе DoomRL?
493 667281
>>667269
Так це ж рогалик обыкновенный
494 667630
>>667281
Не. Рогалик максимально упрощённый. Я о таком мечтаю уже лет жпять.
Там же кроме ходьбы и стрельбы ничего нет. Но каков геймплей!
495 667658
>>667630
Я хочу себе симулятор инженера/электрика запилить с корвоанами в виде симуляции виздуха, пока исходный код сосаки читаю. Вот это будет вин.
496 667667
>>667630

> Я о таком мечтаю уже лет жпять.


> Там же кроме ходьбы и стрельбы ничего нет. Но каков геймплей!



Дум выпустили в 93 году, играй
497 667687
>>667658
Алсо, хуй знает как правильно настроить симуляцию воздуха. По сути, она должна работать как вода, но тогда как один газ будет смешиваться с другим? Как будет создаваться новый объект из этих двух? Можно накладывать один объект воздуха на другой (ака слоенный пирог), но это слишком просто. Я не хочу стопроцентной симуляции, но хочу сделать чуть лучше, чем то, что существует в сс13 на сегодняшний день.
498 667688
Бля, забыл, что там по сути несколько типов газов могли находиться в одном тайле, не? Уже несколько лет в эту хуйню не играл.
Но в любом случае пришла идея, когда вместо определенного газа, тайл с воздухом будет тупо содержать данные о концентрации газов на этом тайле. А может в сс13 подобное и используется лол.
499 667690
>>667658
Я хочу думрл, но на космических кораблях, чтобы стены взрывались и декомпрессия. Вот тебе и симуляция воздуха.
>>667667
Прошёл ещё в 95-м, а потом ещё раз сто.
500 667693
>>667690
Не, если бы меня и интересовал сюжет, то скорее какой-нибудь детектив в космосе, ну или чужой с чувством тотального пиздеца и одиночества. А декомпрессия это ещё не вся симуляция тащемта
501 667728
>>667693
Чтобы сделать детектив или хоррор - нужен писатель. У меня есть пара братюнь, но их заинтересовать нужно.
Ну ладно, чо трепаться. Удачи тебе в запиле.
502 667731
>>667090
Блять ты где сука была пидр а? Я нормального человека который бы хотел в реально комплексные игори не видал. Я бы помог чем понемногу, сам думаю за хуйню логику хуё-моё ток давай перекат в телегу ибо скоро тред рухнет @adeeee6622
503 667732
>>667687
Алсо. Ебану сразу идею сюда. Ты спокойно можешь сделать так чтобы у тебя в одной клетке были как массивом несколько типов геймобжектов-веществ, которые при попадании в тайл просто чекали на возможность смешивания, или в самом тайле был булевой переменная указывающая что на тайле имеются неиннертные вещества, ну для небольшого оптимзиона. Также можно попробовать алгоритмы sparse quadtree для ещё большего оптимизона.
504 667812
>>667732
Неплохая идея, попробую реализовать.
505 667813
>>667812
Ну я много хуйни придумал, ты вообще насколько хочешь полностью воссоздать ссОЧКУ, ведь можно же лучше сделать есившто. Как нпример систему анатомии немного допилить, аугментациии въебать систему навыков (которые будут скорее использоваться в контексте активации аугментаций, или мутаций допустим. Ну много куда можно. Я выше описывал вродею)
506 668057
Ребзя, а какую РПГ систему запихнуть в рогалик? Я думаю GURPS lite, но может что-то есть фриварное?
507 668070
16pixel 508 670530
Бамп вялому треду.

Переделал line of sight. Не смог въехать в подход Boba Nystroma с октантами, так что взял рейкаст с roguebasina, причесал и использовал.
Переделал поведение мобов - теперь похоже на осмысленное. Окружают, ищут альтернативные пути. Алгоритмы поиска пути никакие не используются - только поиск ближайшего доступного для шага тайла, который ведет к позиции цели.
Сделал сундуки и их содержимое. Сделал и протестировал переключатели, которые включаются когда на них наступаешь, но пока никак не использовал.
Ужасающее количество времени убил на переделку работы со спрайтами. Pygame невероятно уебищен в этом плане, чтобы сделать анимации без дропа фпс мне пришлось трижды вывернуться. Возможно на питоне больше ничего такого писать не буду.
А, да, сделал простые анимации через жопу конечно же и переход с одной карты на другую - это оказалось проще чем я думал.

Призываю бампать тред своим прогрессом Или ниграми, хоть чем-нибудь. И перекат давайте.
sage 509 670541
>>670530

>Возможно на питоне больше ничего такого писать не буду.


Exp +1 (те уже говорили что питун медленный)

Тут ОП должен был перекатить, но как-то никак. Если вдруг потонем, смогёшь сам перекатить с тем же заголовоком?
510 671019
>>670541
Перекатил https://2ch.hk/gd/res/671018.html (М)

мимооп
Тред утонул или удален.
Это копия, сохраненная 1 августа 2021 года.

Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
« /gd/В начало тредаВеб-версияНастройки
/a//b//mu//s//vg/Все доски