Говорят рогалики можно кирилить десятилетиями. Поехали!

 Аноним 19/02/19 Втр 11:55:23 #1 №558349 
cogmindasciiartcompilation.png
Говорят рогалики можно кирилить десятилетиями.

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

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

Итого:
Пространство
Игрок, враги (или экземпляры одного объекта или просто наследуются от общего опредка)
Предмет
Эффект
Действие
Аноним OP 19/02/19 Втр 13:12:01 #5 №558373 
Само собой для простоты разработки все должно быть разбито на группы, то есть, если это это эффект, то у него должна быть определенная природа (физическое воздействие, химическое или наоборот, защита от этого воздействия), если это предмет, то его свойства должны также учитывать наличие этих типов взаимодействия
Аноним 19/02/19 Втр 13:26:26 #6 №558380 
Ну нихуя себе ты неочевидностей рассказал ммм...
Аноним OP 19/02/19 Втр 13:39:49 #7 №558391 
>>558380
Ого, кто-то впервые столкнулся с проектированием архитектуры.
Аноним 19/02/19 Втр 13:42:19 #8 №558392 
>>558391
Лично я столкнулся с очередным маняфантазированием в гд, вот сижу прикидываю через сколько дней сдохнет тред.
Аноним OP 19/02/19 Втр 13:44:38 #9 №558393 
>>558392
Так через сколько сдохнет? Мне интересно же.
Аноним 19/02/19 Втр 13:46:14 #10 №558394 
>>558393
Думаю максимум через 3 дня. Скорее всего раньше.
Аноним OP 19/02/19 Втр 13:49:39 #11 №558395 
>>558394
Ого, целых три дня. Не плохо. Я то думал уже сегодня вечером исчезнуть из треда
Аноним 19/02/19 Втр 13:50:58 #12 №558396 
»558364
Почему у тебя "эффект" и "действие" - базовые объекты? Не кажется ли тебе оптимальным описать всевозможные взаимоидействия и эффекты внутри классов "игрок, враги" и "предметы", ты вообще с ООП знаком? Ну и рогалики, требущие .net - такое себе, конечно.
Аноним OP 19/02/19 Втр 14:04:09 #13 №558398 
>>558396
>Почему у тебя "эффект" и "действие" - базовые объекты?
Разве так не будет проще их переиспользовать?

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

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

>Ну и рогалики, требущие .net - такое себе, конечно.
Согласен, но рогалик, это просто пет. проджект для изучения net, потому и такой стек технологий
Аноним OP 19/02/19 Втр 14:07:32 #14 №558400 
>>558398
>Почему у тебя "эффект" и "действие" - базовые объекты?
>Разве так не будет проще их переиспользовать?
И да, любой эффект может применять действие и любое действие может накладывать эффект. Поэтому они должны существовать как отдельные от всего сущности.
Аноним 19/02/19 Втр 14:13:37 #15 №558402 
>>558398
>если классы игрок, враг или предмет должны будут иметь одинаковый эффект или действие? Дублировать код?
>решать проблему переиспользуемости кода
Юзай ECS

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

мимо
Аноним OP 28/02/19 Чтв 19:30:42 #16 №562308 
Так, а вот и я.

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

Аноним OP 28/02/19 Чтв 19:32:09 #17 №562309 
render1551371195927.gif
Сегодня за пару часов накидал небольшой проект с классами базовых объектов, картой и разными вспомогательными плюшками. Выглядит это сейчас так:
Аноним OP 28/02/19 Чтв 19:40:50 #18 №562312 
Писал с оглядкой на https://github.com/Chris3606/GoRogue , но мне он не очень пока нравится. Например, в классе Coord (Из названия понятно, что он призван облегчить нам работу с координатами) зачем-то используется Xna, который от майкрософта. Также по коду идет много оптимизаций и костылей, которые вроде как описаны и документированы, но все равно режут глаз. В общем, будем писать все свое.
Аноним OP 28/02/19 Чтв 19:54:17 #19 №562320 
Сейчас нужно немного переосмыслить то, что я тут наделал. Такое ощущение, что я хуйни написал.
Аноним 28/02/19 Чтв 20:38:12 #20 №562325 
По мне, ты слишком много внимания уделяешь архитектуре, классам и т.п. Ради чего всё это? Сама то игра у тебя в голове есть?
>>558398
>рогалик, это просто пет. проджект для изучения net
А, ну тогда понятно. Но всё равно, даже практиковаться, имхо, лучше на том к чему есть хоть какие-то идеи и интерес.
Аноним OP 28/02/19 Чтв 20:53:24 #21 №562332 
>>562325
Есть и интерес и идеи. Обычные приложения пилить как раз намного более скучное дело, чем игру. Тем более, что мелкие приложения уже все запилены, а что-то более масштабное в одиночку просто не поднять. Тем более, что сам я страдаю уже несколько лет игровой импотенцией и мне всегда чего-то не хватало в играх.
Аноним OP 28/02/19 Чтв 20:54:15 #22 №562333 
>>562325
>По мне, ты слишком много внимания уделяешь архитектуре, классам и т.п. Ради чего всё это?
И да, для меня написание всего этого - уже игра. Получаю удовольствие от построения архитектуры
Аноним 01/03/19 Птн 01:23:23 #23 №562397 
>>558349 (OP)
>пикрелейтед
Это из cogmind? Бля, надо добраться до нее наконец-то.
Аноним 01/03/19 Птн 01:24:41 #24 №562398 
14315047902312.jpg
>>558398
>ООП должен решать проблему переиспользуемости кода.
Ну да, должен ;) ;) ;)
Аноним 01/03/19 Птн 08:31:28 #25 №562448 
>>562398
А что, нет?
У меня есть базовый класс "иди нахуй", в котором очень много витиеватого трёхэтажного кода, написанного много раз. Теперь, чтобы послать нахуй залётного ЕЦС-чушкана, мне достаточно просто сконструировать класс с инициализатором. И это всё одной строкой!
var посыл = ИдиНахуй.new(){КогоПослать = "ЕЦС-чушкан"}
Далее, если мне нужно плотно работать с чушканом (если он с первого раза не понял), я могу унаследоваться от базового класса:
class ИдиНахуйЕЦСЧушкан : ИдиНахуй { КогоПослать = "ЕЦС-чушкан" }
И далее, просто конструировать класс-потомок.
Аноним 01/03/19 Птн 08:43:14 #26 №562451 
>>562448
Ничего себе, ты дажи класы с носледованием выучил. Кокой ты крутой прогромист.
Шучу, на самом деле твой пост детектит в тебе нюфаню.
Аноним 01/03/19 Птн 18:33:41 #27 №562576 
>>562398
>>562451
Нут ты и траль, дружище. Ты же даже никак не аргументировал свою точку зрения. Если тебе есть что сказать по теме, то давай, ждём. А пока создаётся впечатление, что ты сам ничего в этом не понимаешь.
Аноним 01/03/19 Птн 18:36:11 #28 №562578 
>>562576
И да, добавлю: серебряной пули не существет. Не стоит толкать ООП туда где ему не место и наоборот, если проблема отлично решается средствами ООП, то почему бы его не применить?
Аноним 01/03/19 Птн 18:43:30 #29 №562582 
>>562397
Скрин из их инструмента для рисования
Аноним 01/03/19 Птн 18:51:40 #30 №562585 
>>562576
>>562578
Все твои рассуждения разбиваются о тот простой факт, что ECS это паттерн ООП.
Аноним 01/03/19 Птн 18:59:51 #31 №562587 
>>562585
Такие факты надо пруфать.
Хотя банально по определению понятно, что это абсолютно не так.
Аноним 01/03/19 Птн 20:11:43 #32 №562609 
>>562585
>ECS это паттерн ООП.
Ты не мог не обосраться
Аноним 02/03/19 Суб 11:12:41 #33 №562749 
>>558364
Ты просто движкописец. Видимо твоё призвание - писить движки
Аноним OP 05/03/19 Втр 20:24:08 #34 №563596 
Движкописец в треде.
В общем, переосмыслил написанное ранее. Пришел к выводу, что нужно делать так:
1. Есть карта
2. На карте расположены ячейки (Cell) в виде двумерной сетки с координатами x и y соответственно
3. У каждой ячейки есть своя координата и массив объектов находящияхся в ней [в ячейке]
4. Каждый объект находящийся в ячейке может иметь метод Step, который, собственно и может реализовывать часть логики отвечающей за ход данного объекта

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


На самом деле никого бы не сожрали, потому что плесень умеет только двигаться
Аноним OP 05/03/19 Втр 20:24:25 #35 №563597 
render1551806207527.gif
>>563596
Аноним 05/03/19 Втр 20:33:20 #36 №563601 
>>563596
>ползет плотоядная плесень
Которая, кстати, реализована с помощью клеточного автомата: https://ru.wikipedia.org/wiki/%D0%9A%D0%BB%D0%B5%D1%82%D0%BE%D1%87%D0%BD%D1%8B%D0%B9_%D0%B0%D0%B2%D1%82%D0%BE%D0%BC%D0%B0%D1%82
Аноним 06/03/19 Срд 09:13:57 #37 №563726 
95049A77-9CF5-45D4-8322-41B0D9EC8147.png
>>563601
Но сама логика автомата пока собрана из говна и палок. В итоге хотелось бы прийти к описательному формату типа пикрил
Аноним 06/03/19 Срд 09:31:04 #38 №563729 
>>563726
>пик
Это откуда?
Аноним 06/03/19 Срд 09:53:12 #39 №563732 
>>563729
Если про код, то из моей головы. Так вижу решение проблемы описания правил для клеточного автомата. Решение не окончательное, конечно, а просто как пример. А скрин из какой-то онлайновой ide, чтобы подсветка кода была
Аноним 31/03/19 Вск 17:45:47 #40 №570391 
Ты это всё мутишь на С#? Блин, мне тоже интересна тема рогаликоварения, правда я начал с С++. Хотелось бы тоже обоюдный обмен опытом на стабильной основе запилить, дашь фейкомыло?
Аноним 31/03/19 Вск 18:51:22 #41 №570398 
>>558398
>пет. проджект
Пет у тебя сокращение от "петтинг"?
>>563596
У каждой ячейки есть своя координата и массив объектов находящияхся в ней [в ячейке]
>Каждый объект находящийся в ячейке может иметь метод Step
И потом, чтобы stepнуть все объекты, ты будешь перебирать все ячейки?
мимопроходил
Аноним 01/04/19 Пнд 04:13:14 #42 №570451 
>>570398
Это сделать же можно через доп bool active, что то такое? чтобы в массив обработки степа добавлялись только обьекты с этим фрагом, и степпер обсчтиывал только их. А пуляться и забираться обьекты будут при их появлении/уничтожении. Не знаю как идея, расскажите о подводных

мимо-не-оп
Аноним 01/04/19 Пнд 04:13:56 #43 №570452 
>>570451
>с этим флагом
самофикс
Аноним 01/04/19 Пнд 21:12:41 #44 №570617 
>>570398
>И потом, чтобы stepнуть все объекты, ты будешь перебирать все ячейки?
Нет, все объекты, которые можно будет степнуть в том числе регистрируются в специальном синглтон-хранилище, откуда я их переберу обычным циклом. В ячейках они регистрируются чтобы удобнее было делать потом выборку указав конкретную ячейку

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

Оп
Аноним 01/04/19 Пнд 21:30:45 #47 №570624 
>>570623
>понарошку
Понапишем

Аноним 01/04/19 Пнд 21:37:25 #48 №570626 
>>570619
>регистрацией объекта в ячейку и отдельное хранилище. Мне кажется, что это не самый лучший способ
Объясню пока. Это скорее даже не костыль, а просто плохо масштабируемое решение. Если представить, что у нас появляются ещё какие-то критерии по которым мы бы хотели делать выборки, то сразу становится ясно, что ми по итогу просто будем перебирать каждый раз это самое общее хранилище. Непорядок.
Аноним 02/04/19 Втр 04:08:27 #49 №570652 
>>570623
Лишь бы ты не ищезал внезапно.
К слову, я смотрю ты филигранно расставляешь архитектуру игры, но у тебя есть концепт со стороны пользователя? Вот что он будет видеть?
Мне тоже интересна дико тема проработки архитектуры, правда пока-что не хватает умишка прорабатывать это всё. И твоя идея даже подожгла немного меня.

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

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

Я хотел получить почту, или что-нибудь еще (телегу дискорд или тому подобное) чтобы более оперативно общаться на эту тему.
Аноним 02/04/19 Втр 22:55:04 #50 №570950 
3DEA5F79-1110-4415-B32F-C22DC6D08521.png
>>570652
На самом деле о геймплее очень рано заводить речь. Будет так: у меня есть ряд технологий, которые мне сейчас интересно освоить. Это и клеточные автоматы, и ии (ml.net), и скриптовые языки внутри приложения. И как будет запилен некий набор функций, я его облачу в геймплей в сеттинге «самосборка». С таким подходом модно будет даже попробовать поэкспериментировать с геймплеем, используя пикрил архитектуру
Аноним 03/04/19 Срд 03:49:39 #51 №571030 
>>570950
Кстати я тоже маняфантазировал, как бы самосбор выглядел в рогалике.

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

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

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

И как ты видишь Самосбор рогалик? Как выживастик? Или как симуляцию, где @ должен будет существовать?
Аноним 03/04/19 Срд 17:18:26 #52 №571140 
>>571030
>Я думаю что это всё должно так или ниаче паралельно идти. Потому что вдруг ты сочтёшь нужным применить какую-нибудь геймплейную механику, а у тебя тех возможности не будет нормальной, и придётся пилить это через костыли, или вообще отказаться от этой идеи.
Если для описания игровой логики (геймплея) мне чего-то не хватает и приходится городить костыли, значит я что-то сделал неправильно и нужно будет это исправлять, а не городить костыли. Цель - не конечный результат, а скорее увлекательный процесс написания и проектирования движка.

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

>Как можно расшифровать пикрил?
https://metanit.com/sharp/mvc5/23.1.php
Там все доступно рассказнно.

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

>И как ты видишь Самосбор рогалик? Как выживастик? Или как симуляцию, где @ должен будет существовать?
Во всех рогаликах, что я играл, мне не хватало "глубины" погружения. Создавалось впечатление каких-то пластмассовых, заскриптованых декораций, по которым бродит персонаж. По задумке, все функции, которые я реализую, должны каким-то образом комбинироваться порождая огромное число разных механик. Конечно, все это может вырости в неуправляемую хуету, но так даже интереснее. В общем, будет некий, существующий по своим внутренним законам мир, а персонаж просто будет по нему бегать.
Аноним 03/04/19 Срд 17:18:42 #53 №571141 
>>571140
Галочка
Аноним 04/04/19 Чтв 04:20:33 #54 №571236 

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

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

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

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

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

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

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

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

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

К слову, чего пишешь сейчас там? Интересно узнать как сама разработка происходит.
Аноним 04/04/19 Чтв 14:27:05 #55 №571305 
>>571236
>Тобишь ты будешь потом перепиливать всё?
Если текущее решение не будет меня устраивать - конечно. Проблемы в этом никакой нет, ведь с каждым разом должно получаться все лучше и лучше

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

>К слову, чего пишешь сейчас там? Интересно узнать как сама разработка происходит.
Сейчас работаю над другими проектами (за которые мне платят), а рогалик, это домашний проект, который получается все оставшееся время (которого пока нет). Поэтому пока ничего нового показать не смогу
Аноним 04/04/19 Чтв 14:32:21 #56 №571307 
>>571305
>>571236
Вообще, цель, это не рогалик как законченный продукт, а сам процесс разработки, в течении которого я смогу пощупать кучу всего нового. Да, было бы очень хорошо, если бы мне его удалось закончить, но нужно быть готовым, что это затянется надолго.
Аноним 04/04/19 Чтв 18:05:24 #57 №571333 
>>571307
Да, ты писал уже об этом. Ну буду мониторить тебя. К слову, може ты на гитхаб зальёшь исходники, или как-нибудь еще рашшеришь? Мне интересно посмотреть исходники
Аноним 04/04/19 Чтв 21:06:13 #58 №571357 
>>571333
Да, так позже и сделаю.
Аноним 08/04/19 Пнд 07:13:37 #59 №572060 
че блять умер что ли, ну ебана
Аноним 08/04/19 Пнд 17:50:10 #60 №572114 
>>572060
Работу работаю. Абу мне не платит за этот тред и приходится зарабатывать работая на дядю. Так что давай запасемся терпением лучше.
Аноним 09/04/19 Втр 07:07:13 #61 №572199 
>>572114
ты сюда время от времени хотя бы измышления свои вываливай, может думки по механикам и архитекртуре там.
Аноним 09/04/19 Втр 18:35:38 #62 №572299 
Присоединяюсь! Какой язык используете?
Аноним 09/04/19 Втр 18:36:09 #63 №572300 
>>572299
C#
Аноним 09/04/19 Втр 18:37:17 #64 №572301 
>>572300
Сделал уже что-нибудь? Или может есть предыдущие проекты?
Аноним 09/04/19 Втр 18:39:09 #65 №572302 
>>572301
Если ты про игровые проекты, то это первый.
Аноним 09/04/19 Втр 18:45:28 #66 №572307 
>>572300
А пчому именно С# то? Чем он лучше Спп?
Аноним 09/04/19 Втр 18:50:08 #67 №572311 
>>572302
Ааа, ладно. Завтра планирую новый рогалик начать писать, ибо мне не очень понравилось как я реализовал предыдущий, хоть и много всего сделал, если вам будет интересно может буду показывать свои результаты, не знаю.
Аноним 09/04/19 Втр 18:50:53 #68 №572312 
>>572311
А ты ОП штоле?
Аноним 09/04/19 Втр 18:52:35 #69 №572313 
>>572312
Неа.
Аноним 09/04/19 Втр 18:53:21 #70 №572314 
>>572313
А что у тебя за рогалик? И почему ты решил остановиться? Что не так было с предыдущим? Какая там архитектура была?
Аноним 09/04/19 Втр 19:08:33 #71 №572316 
>>572307
Ничем. Смотри >>558398
>Согласен, но рогалик, это просто пет. проджект для изучения net, потому и такой стек технологий
Аноним 09/04/19 Втр 19:10:31 #72 №572317 
>>572314
Вообще читая тред я наверное осознал какой простой у меня рогалик, ибо у меня все как то намного проще получилось, да и вообще зашкварно или нет, но я его писал на lua, думаю может на c++ попробовать, хз. Ну вообще рогалик как рогалик получился, графика тайловая, в папке с игрой лежит тайлсет чтоб каждый мог изменять его, над генерацией я не сильно заморачивался, думал и пытался реализовать чтоб были подземелья, комнаты все такое, а в итоге получился генератор пещеры, ну я и решил оставить ибо выглядело неплохо. Игра очень сложная, мобы живут своей жизнью, размножаются, игрок может свой мини домик построить. 10 класс и 10 рас, в общем довольно много сделал, долго объяснять) Но как то мне он не нравится, по этому планирую новый рогалик с опорой на реализм в механике боевки, типа можем атаковать любую часть тела моба, моб будет погибать от тяжёлых ран или от потери крови, скиллы прокачиваются взависимости от того, что ты делаешь, в общем наверное как то так, ух, многовато как то я написал.
Аноним 09/04/19 Втр 19:16:35 #73 №572319 
>>572317
Неплохо. Мне казалось фундамент так или иначе нужно будет закладывать на С++, или С#. Я просто начал плюски задрачивать, потому и выбрал их. А ОП о-очень интересные идеи в плане архитектуры подаёт. С заделом на будущее.

Идея написать полное и гибкое ядро на спп допустим, а остальной контент и функционал пилить на том же луа, или питоне. Как по мне, так это довольно интересная задумка, которая позволит создать универсальный движок для рогаликов. Но это конечно надо тщательно прорабатывать архитекртуру, и обдрачиваться предиктивностью. И тут конечно вопрос оптимизации опять вылезет. Хоть рогалик и игра пошаговая, о работать она тоже быстро по-своему должна.
Аноним 09/04/19 Втр 19:25:56 #74 №572323 
>>572319
Круто, в общем завтра скину скриншот рогалика который получился, а сейчас спать, удачи :3
Аноним 09/04/19 Втр 19:32:47 #75 №572324 
>>572323
А графоний на чем пилил, OpenGL/SDL/...?
Аноним 09/04/19 Втр 19:35:11 #76 №572325 
>>572324
а какие плюсы и минусы той или иной либы по отношению к рогаликоварению?
Аноним 09/04/19 Втр 20:55:15 #77 №572335 
1.png
Так. Сейчас попробуем порассуждать на тему юнитов и принятых ими решений.
Представим, что существует некая условная йоба (человек, дрон, плотоядная плесень, лужа йоба-слизи). Вокруг йобы представлен мир, а у самой йобы имеются некие сенсоры, позволяющие получать информацию из этого самого мира. Если это человек, то в роли сенсоров могут выступать глаза, уши, нос. Если это плесень, то она может получать только информацию о том, что находится в тех клетках где она распространена и немного рядом (те клетки, с которыми она соприкасается). Так как время в игре квантовано (разделено на шаги) очевидно, что каждый ход юнит должен просто анализировать полученную им информацию и выдавать своему телу или чему-то еще команду.

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

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

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

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

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

ваш ОП
Аноним 09/04/19 Втр 20:57:06 #78 №572336 
>>572335
>(модуль клеточного автомата, модуль ИИ)
Там же будет какой-нибудь скриптовый язык, чтобы можно было написать логику просто руками. Например, lisp (интерпретатор которого мы напишем сами, конечно же)
Аноним 09/04/19 Втр 21:09:56 #79 №572343 
>>572325
Я сам хз, но по идее для простых рогаликов подойдёт ченить высокоуровневое, сам юзаю OpenGL в самой простой вариации(шэйдеры и массивы примитивов для координат квада) потому что по-другому никак.
Если не охота байтоебить можно начать с Love2D какого-нибудь.
Аноним 09/04/19 Втр 21:10:46 #80 №572351 
>>572336
Ты же на Сишарпе, как лисп воткнёшь?
Аноним 09/04/19 Втр 21:11:40 #81 №572363 DELETED
>>547389
ты как cчитаeшь? Почти двe тыщи копий, 53% на рашкy: 1000 копий в рашкe по цeнe 200 р = 200 000 р.
47% (нy пycть бyдeт 900 копий) по цeнe 10$ ≈ 9000$ => 630 000 р

630 + 200 = 830 000 рyблeй.
Аноним 09/04/19 Втр 21:12:38 #82 №572376 DELETED
>>528118
пoдсoсoк фалкo на мoиx двачаx, неoжиданнo.
а зачем ты защищаешь вoрьё, все деньги кoтoрoгo идyт с развoда пoльзoвателей через малвары? ты в шайке с этим гнидoй, да?
Аноним 09/04/19 Втр 21:12:41 #83 №572378 DELETED
>>406050
Bозможно это мecто ужe пpодaно, и оно cущecтвуeт только в кaчecтвe cтимулa
Аноним 09/04/19 Втр 21:12:51 #84 №572379 DELETED
>>554271
В cтатьe жe наобоpот нe peкомeндyeтcя игpы по тpи года дeлать.
Аноним 09/04/19 Втр 21:13:06 #85 №572380 DELETED
>>572302
Aaa, лaдно. Зaвтpa плaниpyю новый pогaлик нaчaть пиcaть, ибо мнe нe очeнь понpaвилоcь кaк я peaлизовaл пpeдыдyщий, хоть и много вceго cдeлaл, ecли вaм бyдeт интepecно можeт бyдy покaзывaть cвои peзyльтaты, нe знaю.
Аноним 09/04/19 Втр 21:13:14 #86 №572382 DELETED
>>571682
Кoгда придeт врeмя, 2д ничтoжeствo тeтрисoкалoвoe, кoгда придeт врeмя.
Аноним 09/04/19 Втр 21:13:54 #87 №572393 
>>572351
Любая достаточно сложная программа на C или Фортране содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp (Филип Гринспен)

А если по существу, то так и воткну. Это же скриптовый язык. Для него лишь необходим так называемый интерпретатор, который в свою очередь может быть написан на чем угодно (уже написан почти на всем, на чем только можно, в том числе c#)
Аноним 09/04/19 Втр 21:14:47 #88 №572405 DELETED
Hовый рeндeр повысил количeство дровколов большe чeм в 2 раза, правда в фортнайтe. Eсли статика eщё большe, выигрыш можeт повысится в нeсколько раз(в 6-7 раз)
Аноним 09/04/19 Втр 21:14:52 #89 №572408 DELETED
>>570775
PlayerPrefs xpaню и eщё нecкoлькo json-oв c тeкущим пpoгpeccoм в PersistentDataPath. Ho кoгдa бaгa пpoxoдит, вce фaйлы нa мecтe и нopмaльнo читaютcя.
Аноним 09/04/19 Втр 21:15:39 #90 №572421 DELETED
>>566235 знак yмнoжeния нe прoлec
12х0.66х0.58/2.56= 1.76 oчкoв
Аноним 09/04/19 Втр 21:16:06 #91 №572427 DELETED
>>571922
>>571923
еcли ты не знaешь то хyли ты лезешь?
Аноним 09/04/19 Втр 21:17:57 #92 №572441 
>>572427
>>572421
>>572408
>>572405
>>572382
>>572378
>>572376
>>572363
Макаба протекает или вы тредом ошиблись?
Аноним 09/04/19 Втр 21:19:03 #93 №572444 DELETED
>>569570
Пpыснул еще беленким на макушку, для ума и чтоб волосы здоpовее были.
Аноним 09/04/19 Втр 21:21:01 #94 №572452 
>>572441
Вайп старыми постами?
Аноним 09/04/19 Втр 21:24:33 #95 №572461 
>>572452
Как-то слабовато получилось
Аноним 09/04/19 Втр 21:24:58 #96 №572462 DELETED
>>571816
Нy вот всё ж понимaешь вроде, a серишь.
Аноним 09/04/19 Втр 21:36:16 #97 №572473 
Спасибо, Абу, почистил тред
Аноним 10/04/19 Срд 04:03:49 #98 №572531 
>>572335
Ну в общих чертах это конечно очевидное описание. Вот скорее интересно, получается, каждый юнит будет получать каждый ход заного всю карту? как вообще будет представляться в уме ИИ всё пространство? Как информация будет интерпретироваться? Условно, для простого ИИ обычного импа-чухана, можно просто вложить тайлы препятствий, тайлы опасности и тайлы агрессивно-дружественных существ. Хотя каждый ход прогонять заного всё это, смысла особого нет, как по мне. Не оптимальненько. При этом тебе придётся либо писать каждому виду существ "модели" поведения, или же можно создать 1 модульный вид интеллекта, который будет ограничиваться "знаниями", которые у него имеются (а-ля флаги).

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

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

>>572336
Чем тут Лисп от Луа отличается?
И меня постоянно почему-то парит то, что такие скриптовые языки будут невероятно медленные, по сравнению с компилированным кодом, и что им можно только давать простую логику. Но при этом желание сделать core игры так сказать на Сишке, а дописать механ на Луа довольно неслабо перевешивает.
Аноним 10/04/19 Срд 09:06:50 #99 №572541 
>>572324
К сожалению, не заморачивался над этим, и просто использовал Love 2D, там используется function love.draw(), что довольно все облегчает. В следующем моем посте, прикреплю уже скрины с тем моим рогаликом, о котором я писал.
Аноним 10/04/19 Срд 09:37:33 #100 №572542 
1.png
2.png
3.png
4.png
Вот собственно тот рогалик о котором я писал:
1) скрин - меню,создание персонажа, выбор расы и класса. Sy - Satiety, Ka - Karma(в игре можно помолиться богу в сложной ситуации, и чем больше у тебя карма, тем больше шанс, что бог тебе поможет,кстати не все расы веруют в бога, типа есть расы атеисты)
2) скрин - сама игра, спрайты выполнены в размере 21x21, в папке с игрой находится tileset. справа открыт инвентарь, любая вещь имеет свой бафф, урон(если будешь кидать эту вещь во врага), вес и цена. На скрине мы видим торговца, масло на полу(на нем любой может подскользнуться и упасть), ловушки, статую,лестницы вниз и мобов.
3) скрин - игра как она выглядит на самом деле, то есть то, что игрок не сможет увидеть,ибо он видит только то. что в зоне его видимости. Есть 2 типа стен: целые и полуразрушенные. вторые игрок может сломать и руками, но -немного hp будет, либо любую стенку киркой, так же можно и строить стены, статуи, ковер и создать свой домик. Так же на скрине мы видим алтари.
4) скрин - вакханалия, я просто дал убить себя слизням, подождал много ходов и вот они размножились жестко, ибо эт слизни.
Аноним 10/04/19 Срд 09:39:22 #101 №572543 
>>572542
Забыл добавить, чтобы повысить карму, нужно кормить котиков) А еще они всегда за тобой ходят, убив котика ты получишь мясо, но -карма.
Аноним 10/04/19 Срд 09:47:25 #102 №572544 
tileset.png
>>572542
А вот и мой тайлсет, кстати в игре могут заспавнится надписи, типа тех, кто был здесь до игрока, они выглядят очень неразборчиво, написанные кровью, мелом и тд(это генерируется) и фишка в том, что надпись может быть вообще выглядеть не понятно, типа HEL##O W##LD
Аноним 10/04/19 Срд 10:23:50 #103 №572551 
>>572544
>>572543
>>572542

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

ОП, а ты какие-либо используешь UML системы? Сейчас вот я Enterprise Achitect постигаю. Мне кажется, с ним пилить архитектуру намного легче)
Аноним 10/04/19 Срд 11:34:10 #104 №572560 
ShwrwLO-ip4.jpg
DV5onpaVQAAzmLG.jpglarge.jpg
Cosmology.jpg
Я тут тоже маняфантазиями балуюсь


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

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


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


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

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



Аноним 10/04/19 Срд 21:36:10 #105 №572678 
В попенсорс будешь лить? Интересно будет сравнить подход.
Аноним 19/04/19 Птн 17:32:40 #106 №574923 
>>572678
Ты это кому?
Аноним 31/08/19 Суб 22:56:27 #107 №606594 
Вечер в хату. Не знаю, будет ли галка, но это я - ОП
Проект на c# успешно загнулся, но оставил за собой не мало опыта. Теперь мы возьмем этот опыт и запилим второй проект, но уже на typescript
Аноним 31/08/19 Суб 23:17:58 #108 №606599 
>>606594
Из прошлого проекта мы должны взять все лучшее, а именно - клеточные автоматы. Но на этот раз правила для них будут писаться не руками, а генерироваться. Возникла идея отображения характеристик и свойств объектов некой n-мерной плоскостью, по которой эти клеточные автоматы и будут передвигаться. Непонятно, конечно, как это будет выглядеть, но в голове представить это себе я могу.
Аноним 02/09/19 Пнд 09:35:32 #109 №606943 
>>606594
> Не знаю, будет ли галка, но это я - ОП
Поставь в браузер куки-экспортер и носи свои куки с собой.
Аноним 02/09/19 Пнд 17:30:02 #110 №607117 
>>606594
а в чём проблема, почему он просто так взял и загнулся?
Аноним 02/09/19 Пнд 18:43:55 #111 №607136 
>>607117
Потому что изначально все начиналось как пет проджект для обучения сишарпу. Сишарп был выучен, работа для которой он учился выполнена и я снова вернулся на старые рельсы фронтенд разработки, а там typescript и вот это вот все. На самом деле продолжил бы, но что-то мне не очень понравилось. Не хочу лезть в c# пока дальше.
Аноним 03/09/19 Втр 12:55:34 #112 №607286 
>>607136
> сирешётка
> фронтенд
Говноед-комбо
Аноним 03/09/19 Втр 13:01:21 #113 №607288 
>>607286
Ну ты бы хоть аргументировал, друг
Аноним 03/09/19 Втр 13:15:42 #114 №607292 
>>607288
Назови хоть один успешный проект на сиришотке, кроме ебучего KSP, которое даже на топовом железе умудряется тормозить?
Аноним 03/09/19 Втр 13:28:54 #115 №607294 
>>607292
А чем мы успех измеряем? В компании где я работаю, на c# вполне приличный спрос. И продукты написанные на нем продаются. Или ты намекаешь на низкую производительность?
Аноним 03/09/19 Втр 13:34:08 #116 №607296 
>>607292
>которое даже на топовом железе умудряется тормозить
Играл на 2 ядра-2гига, чет нихуя не тормозило.
Аноним 03/09/19 Втр 13:42:27 #117 №607298 
145420865324a5b407274d421fea6e8f--sad-anime-anime-guys.jpg
>>606599
Зря бросил прошлый проект на с#, по второму кругу делать будет уже не так интересно + потеряется былой энтузиазм после пары недель. Выглядело между прочем не плохо, подкрутить механики, ui, и вот уже альфа рогалика готова, эх.... анон, анонович...
Аноним 03/09/19 Втр 13:49:52 #118 №607302 
>>607298
Да брось, во второй раз будет еще лучше. Тогда по сути написание кода заняло в общем всего пару дней. Остальное, это размышления, которые прекрасно лягут и по второму кругу.
Аноним 03/09/19 Втр 13:53:49 #119 №607304 
>>607292
We Happy Few
Rust
Аноним 03/09/19 Втр 13:55:18 #120 №607306 
>>607302
Ох ёёёёёё, только заметил дату создания треда, R.I.P в общем.
Аноним 03/09/19 Втр 15:34:54 #121 №607362 
Не совсем ведаю за typescript. Рзве о подойдёт для того чтобы написать более-менее оптимизированный рогуль?
Аноним 03/09/19 Втр 15:49:18 #122 №607365 
>>607362
Нет, конечно. Это говно очевидно будет безбожно глючить, как и любое приложение на js. Оп, наверное, подался в корпоративные рабы, вот и учит тайпскрипт.
Аноним 03/09/19 Втр 16:00:38 #123 №607367 
>>607365
Есть ли альтернатива typescript в мире фронтенда?
Аноним 03/09/19 Втр 16:07:36 #124 №607371 
>>607362

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

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

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

мимо воннаби фронтэндер
Аноним 03/09/19 Втр 16:10:30 #125 №607373 
>>607367
скажет начальник что будешь использовать тайпскрипт значит будешь, не скажет тебя никто не заставляет
Аноним 03/09/19 Втр 16:10:51 #126 №607374 
>>607371
Ну это понятно, но как сказано выше, встаёт вопрос чисто оптимизации всего этого дела. жоваскрипт жеж.
Аноним 03/09/19 Втр 16:11:09 #127 №607375 
>>607373
А ты бы что использовал, для рогаликоварения, кресты?
Аноним 03/09/19 Втр 16:12:11 #128 №607376 
>>607373
Чет не понял посыла. А если нет начальника и нужно выбирать?
Аноним 03/09/19 Втр 16:12:31 #129 №607377 
>>607375
Анреал идеально подойдёт, советую, еще захочешь.
Аноним 03/09/19 Втр 16:15:50 #130 №607378 
>>607377
ты гониш шоле? рогалис на анриле писать, это как пытаться самокат нахуй на базе ракетного шаттла делать. + опять же в анриле много ненужного груза, а для рогаликов, если пилить прямо конкретно его, потребуется для обсчитки много ресурсов. В общем рогули писать это не игры делать, там именно движкописание важно
Аноним 03/09/19 Втр 16:17:22 #131 №607379 
>>607375
ты не понял мой пост
тайпскрипт это суперсет джаваскрипта
буквально джаваскрипт в котором ты можешь указать ожидаемый тип переменной и который будет ругаться но все равно работать если переменная окажется другого типа
он транслирует код в es5 джаваскрипт

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

>>607374
довольно быстрый язык
Аноним 03/09/19 Втр 16:17:42 #132 №607380 
>>607378
Сразу видно что ты не шаришь в анриле. Ничо, для тя поясню - внутри анрила есть 2 классные штуки, первОЯ это кресты, на них можно написать шо душе угодно, но вторая еще вкуснее и проще это блюпринты, так вот, ты идёшь, качаешь бесплатный унрил, куришь мануалы по блюпринтам, и делаешь рогалик не написав не одной строчки кода, ахуеть да? Прогресс то идёт, время дроча консолички, и все остального прошло.
Аноним 03/09/19 Втр 16:19:41 #133 №607381 
>>607376
ты знаешь в чём преимущество типизированых языков над динамическими? можно легче отловить многие невнятные баги. если твой проект сложный может оно того и стоит
Аноним 03/09/19 Втр 16:21:00 #134 №607382 
>>607380
Я знаю про это, и ты меня видать не понял. Я знаю и про бллюпринты и про встроенные кресты, конечно можно написать рогалик, никто не спорит, но суть рогаликов именно и в том, что ты полностью знаешь как у тебя код работает, ты сам подстраиваешь все обработчики и прочеее нахуй хуё моё, а тут в анриле много лишнего функционала, это просто невыгодно нахуй с точки зрения оптитмизации. Конечно если ты лепишь какую нибудь поеботу простецкую (без сложных вычислений имеется), а-ля нетхак то никаких проблем - пиши. Но попробуй тот же ДФ перенести на анрил, что то не подкасывает всё станет ещё несоразмернее хуже с оптимизоном.
Аноним 03/09/19 Втр 16:21:33 #135 №607383 
>>607380
рогалик это очень простая пошаговая игра
зачем ей фреймворк?
ее можно сделать буквально в браузере управляя дом деревом лол
Аноним 03/09/19 Втр 16:22:28 #136 №607384 
простая в визуальном плане в смысле
Аноним 03/09/19 Втр 16:23:04 #137 №607385 
>>607383
смотря какой рогалик исчо. Если добавлять симулятивности, как в теж хе ДФах или CoQ, то уже хуй там.

>>607384
ну это всё меняет
Аноним 03/09/19 Втр 16:25:56 #138 №607386 
>>607385
в дф довольно много вычислений иирк, нужен сервер и какая нибудь либа. в джаваскрипт есть биндинги к куче либ так что при желании можно хоть нейросеть прикрутить
Аноним 03/09/19 Втр 16:26:19 #139 №607387 
>>607382
1. Если ты делаешь 2Д, не 3Д, то проблем с оптимизоном в унриле у тебя не будет, вот 100%, исключение составляют лишь бесконечные циклы если ты где то проебёшься с ними.
2. Если ты знаешь, но не решаешься сделать, значит у тебя не достаточно опыта, либо предвзятое мнение и не желание разбираться в движке.
3. Судя по твоему описанию склоняюсь к тому что уаньку ты мало трогал, и не шаришь в ней, следовательно, идёшь курить мануалы по блюпринтам, это займёт максимум пару дней, и еще пару по поути.
4. Перенести ДФ как раз таки будет легко по причине того что ты видишь конечный продукт + знание механики освобождает от придумывания своей, остаётся только графон и заблюпринтить.
Всё таки советую анон покурить анрильку, думаю ты удивишься сколько всего можно сделать на ней не глюченого, если не 3Д!!

>>607383
Время 3++ в консолечке прошло, ало дядя, за тебя всё движок делает, тебе надо лишь нафантазировать механики, спиздить графон и музон, всё!
Аноним 03/09/19 Втр 16:26:50 #140 №607388 
ну в смысле сервер если это веб рогалик, но это не обязательно
Аноним 03/09/19 Втр 16:30:14 #141 №607389 
>>607387
МОжет быть я и ошибаюсь, хочу ошибалться даже. Раз ты такой ведающий, разъясни момент с оптимизацией? Это зависит исключительно от того как написан код самой игры, сложных обработчиков и процедур? Просто ДФ, как ты говоришь перенести легко относительно, никто не спорит, но меня ОЧЕНЬ заботит оптимизация игры, вот захочу я повысить количество обрабатываемых обьектов в мире даже больше чем в ДФ, и что? Насколько сам движок будет влиять? Или допустим ты если пишешь сложную логику, то надо хотя бы иметь опенсурс от анрила, чтобы понимать как те или иные функции работают, это опять же вопрос не невозможности реализовать, а оптимизации этого всего действа.
Аноним 03/09/19 Втр 16:37:33 #142 №607392 
>>607389
Насчёт оптимизации, здесь выигрывают как раз готовые движки по типу анрила, юнити, потому что за нас уже всё продумано и реализовано, и остаётся лишь курить мануалы и применять готовые решения(Не путать с тасканием ассетов!). Вот как писал анон выше, написать рогалик самому к примеру на голых плюсах, или на java, объём работы увеличивается в разы, а с ним самая важная часть, это понимание архитектуры куда, какую функцию записать, что бы определить правильную последовательность обращений из одного файла в другой и т.д, в движке же, как я упомянул раньше всё проще, многие фишки в том числе с оптимизация просто у мешаются в пару строк кода. Из минусов как многие сразу могут написать есть лишь то что закрытый код() и если захочется тонкой настройки это нэт, костыль на костыле будет получаться, Но для обычного инди девелопа идеально подходит, всё что остаётся это творить, и изредка думать над оптимизацией.
Аноним 03/09/19 Втр 16:38:55 #143 №607393 
1.png
>>607389
Если ты будешь пилить на уе4, то должен понимать, что есть просто колоссальное количество подводных камней. Текстовый вывод в консольку? Похуй, нужна видеокарта с DX11. Примитивная игра практически без логики? Похуй, твой восьмиядерный интол будет загружен на 98%. Нет контента? Похуй, билд игры будет весить не меньше гигабайта.
Аноним 03/09/19 Втр 16:40:15 #144 №607394 
>>607393
Ой пиздабол, ой пиздабол... Узнаю стандартные мантры немощного который даже не собирал билд в юньке.
Аноним 03/09/19 Втр 16:40:31 #145 №607395 
>>607394
>быстрофикс
В уиче.
Аноним 03/09/19 Втр 16:45:13 #146 №607399 
>>607392
Да, иммено, ты мне про Фому я те про Ерёму, пиание рогаликов, хардкорное, as it is вообще никак не идёт в сравнение с обычным инди деланием. Это скорее какой-то хтонический байтодрочерский процесс (немного преувеличил но ты понял), где вся архитектура перепиливается с нуля. Естесна если ты хочешь создать простенькую игру которую можно будет только условно назвать рогаликом (на деле симуляции всего и вся там конечно же не будет.), то готовые движки будет самое то. Тут же у нас идёт йобаный хардкор, с пересборкой велосипедов под езде по рельсам и воздухоплаванию одновременно.

>>607393
ЧТД.
Аноним 03/09/19 Втр 16:47:51 #147 №607400 
честно говоря я в игродвижках не разбираюсь (игры слишком долго делать есть много других интересных вещей которые можно сделать быстрее) но как давний фэн рогаликов, который даже написал раз безбиблиотечный простенький рогалик на си на анси-кодах в консоли мне сама идея что монстр вроде юнити будет использоваться для рогалика кажется кощунством лол

в рогаликах главное дизайн игры, мир, механики, генерация уровней т.е. логика, в них перемещение происходит пошагово и по фиксированной двухмерной сетке, зачем для них монстр предназначенный для сложной графики
Аноним 03/09/19 Втр 16:49:20 #148 №607401 
>>607399
эм
какая стимуляция
рогалик это в первую очередь каменный суп, адом, ангбанд с его клонами, нетхак, все такое
Аноним 03/09/19 Втр 16:49:59 #149 №607403 
>>607400
Затем чтобы довести своё поделии до альфы, а не бросить спустя пол года дрочения голого кода.
Аноним 03/09/19 Втр 16:50:45 #150 №607404 
>>607399
Ладн я понял, забей, если ты так одержим своим то лучше это и используй, если получится то супер, если нет, мб пересмотришь свои взгляды в дальнейшем.
Аноним 03/09/19 Втр 16:51:44 #151 №607405 
>>607403
ты не понимаешь, перемещение персонажа по экрану и т.п. фигня в рогалике самое простое и делается день или за несколько дней
Аноним 03/09/19 Втр 16:53:09 #152 №607406 
>>607401
ну вроде как бы и да, но мне кажется что интереснее рогалики-гиганты, типо ДФ, с его невзъебенной симуляцией каждой хуйни и дотошным вычислением всего, Катаклизм ДДА, CoQ и прочее. Мне просто лично кажется обычные-примитивные дунжон кравлеры себя уже давно изжили, и это просто мягко говоря заэбало.
Аноним 03/09/19 Втр 16:54:04 #153 №607407 
>>607405
Ох мой юный анончик, ты даже не представляешь что тебя ждёт впереди... С другой стороны, если попробуешь заниматься гей девом тебе откроется много интересного, завидую тебе даже...
Аноним 03/09/19 Втр 16:55:57 #154 №607410 
>>607406
я лично куууууда больше времени убил на дксс, адом и посченг чем на катаклизм и дф

дело вкуса, дксс вообще вызов был, я спидранил сприганнами лол
Аноним 03/09/19 Втр 16:58:35 #155 №607412 
687740191365b8c17cc2b.jpg
>>607403
Считай это своеобразным естественным отбором.

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

>>607410
Может быть это я просто уже изыгрался, такой метамодерн пошёл.
Аноним 03/09/19 Втр 17:02:16 #156 №607415 
>>607407
и что же? рогалик я лично написал бы браузерный без специального игрового фреймворка, что-то 2д с реалтайм перемещением наверное взял бы какой-нибудь phaser, 3д не трогал бы вообще

но повторю мне написание игр кажется тратой времени, уд слишком много людей их пишет
Аноним 03/09/19 Втр 17:05:12 #157 №607416 
>>607415
Это зависит еще от того что ты сам напишешь. Посредственностей конечно дохуя, но при этом выдающиеся вещи (если таковыю сможешь родить) в узких рогаликоведческих кругах известна будет.
Аноним 03/09/19 Втр 17:09:36 #158 №607417 
>>607415
>слишком много людей их пишет
Ты уж определись ты это делаешь ради денег? Тогда надо идти в мобилкоговно рыночек. Для хобби? Тогда пиши на чём душе угодна, когда угодна, хоть в блокноте, даже если выйдет говно, главное чтобы получалось удовольствие от процесса. Для кого-то? Небольшой публики? Тогда придётся что-то изучать, осваивать, тратить время на не интересные вещи, но нужны для прогресса и понимания.
Аноним 04/09/19 Срд 20:20:21 #159 №607808 
>>572542
>спрайты выполнены в размере 21x21
Почему именно этот размер?
Аноним 05/09/19 Чтв 02:57:10 #160 №607937 
>>562448
всегда ору с ооп фанатов и их любви делать классы
>У меня есть базовый класс "иди нахуй", в котором очень много витиеватого трёхэтажного кода, написанного много раз.
>Теперь, чтобы послать нахуй залётного ЕЦС-чушкана, мне достаточно просто сконструировать класс с инициализатором. И это всё одной строкой!
>var посыл = ИдиНахуй.new(){КогоПослать = "ЕЦС-чушкан"}
зачем для этого класс?
const Посыл = require('./посылы/Посыл'); //ты эту часть вообще упустил где у тебя код базового класса хранится
const посылЕЦС = Посыл.кого("ЕЦС-чушкан");
все. никаких конструкторов. никаких классов на пустом месте
>Далее, если мне нужно плотно работать с чушканом (если он с первого раза не понял), я >могу унаследоваться от базового класса:
>class ИдиНахуйЕЦСЧушкан : ИдиНахуй { КогоПослать = "ЕЦС-чушкан" }
>И далее, просто конструировать класс-потомок.
можно сделать обертку с дефолтным значением аргумента
function ИдиНахуй(КогоПослать = "ЕЦС-чушкан") {
const Посыл = require('./посылы/Посыл');
return Посыл.кого(КогоПослать);
}
никакого говнонаследования

Аноним 05/09/19 Чтв 03:28:18 #161 №607940 
>>571236
>Насколько я знаю, машин лёрнинг пока можно обучать в очень узких специальностях. Может быть можно написать площадку с группой юинтов А, и одним юнитом Б, и их обучать убиению друг друга, тренируя pathfinding и стратегию, хотя я честно не уверен насколько это возможно.
я скорее не вижу зачем это надо
можно запилить очень эффективное ай без мл см. sil
может с помощью мл можно запилить еще более умных мобов, но... советую поиграть в sil, умные мобы напрягают, конкретно умные мобы будут напрягать конкретно

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

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

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

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

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

у самого верхнего торговца левый верхний сундук это мимик? если нет, то у тебя наложилось два тайла
Аноним 05/09/19 Чтв 09:34:06 #162 №607967 
>>562309
>запускаем сценку из десятка символов несколько секунд
Обмяк с производительности C#.
Аноним 05/09/19 Чтв 09:39:37 #163 №607968 
>>558364
Сейчас бы разделять игрока и врагов в рогалике. Все живые существа должны быть частью симуляции и работать по одним правилам.
Поэтому во всех трушных рогаликах игрок и враг это один и тот же класс, они имеют одинаковые параметры, атрибуты, инвентари, и различаются только тем, что игрок управляется через контроллер игрока, враг - через контроллер AI, который посылает по сути те же команды, что и игрок с клавиатуры. Так везде, от dungeon crawl'a до катаклизма.
Аноним 05/09/19 Чтв 09:45:23 #164 №607970 
>>607968
Нет, маня, ты не права. Логика врагов основывается на алгоритмах (поиск пути, таргетирование и т.д.), а логика игрока - на том, что у него вместо мозгов в башке. Соотвественно, классы априори уже не могут быть идентичны. Ну или могут, но это будет уже как консируктор солянки. Залупа в общем конская.
Аноним 05/09/19 Чтв 10:03:56 #165 №607974 
>>607367
C++, SDL, emscripten.
>>607386
>что при желании можно хоть нейросеть прикрутить
А машинное обучение с бигдатой на блокчейне можно прикрутить, чтобы побыстрее работало? Что ты несешь, дурачок?
>>607392
>Насчёт оптимизации, здесь выигрывают как раз готовые движки по типу анрила, юнити, потому что за нас уже всё продумано и реализовано,
Продуман и реализован движок общего назначения, цель которого покрыть любую возможную разновидность игр. Используя тот же юнити для рогалика, ты будешь юзать 5% от его фич, а остальные фичи будут висеть мертвым грузом в дистрибутиве, ветвлениями в коде. Кастомный движок, написаный с нуля под конкретный набор фич ВСЕГДА разносит по перфомансу и размеру дистрибутива движок общего назначения. На юнити твой рогалик будет весить 200 Мб и позволять обрабатывать 1000 юнитов без просадки фпс, на голых плюсах это будет 10 мегабайт и десятки/сотни тысяч, зависит от твоего скилла и подхода к работе с данными. Чем меньше абстракций, ООП, паттернов, уровней наследования юзается - тем выше перфоманс. На ecs с хитрыми оптимизациями симулировать сотни тысяч сущностей вообще не проблема, даже на не самом топовом железе.
>>607970
Маня, ты путаешь класс персонажа и контроллер персонажа. Сваливать обработку ввода и симуляцию персонажа в один класс это первый признак говноархитектуры, это еще в конце 90х поняли и уже в первом анриле был отдельно Pawn, класс персонажа, и контроллеры PlayerController и AiController, которые работают с одним и тем же персонажем, просто по-разному его контролируют. Персонаж содержит все данные, здоровье, опыт, скиллы, инвентарь, и базовую логику взаимодействия, идти вперед, перейти в точку, атаковать. А контроллер отвечает именно за управление, обработку ввода.
На ecs это элементарно реализуется, контроллер подключается как отдельный компонент и управляет связанным с ним персонажем. В случае контроллера игрока он ловит ввод с клавиатуры, AI контроллер как раз определяет цель и строит путь. С таким унифицированным подходом легко реализовать переселение души, например, просто переключаешь компонент с одного персонажа на другого, и ты можешь управлять уже врагом (либо одним из своих юнитов). Либо наоборот, перевести своего персонажа в режим ИИ, чтобы он автоматом бегал по уровню и дрался.
В ООП это тоже просто делается через агрегацию.
А залупа конская у тебя вместо мозга, похоже.
Аноним 05/09/19 Чтв 10:08:20 #166 №607975 
вообще одна из самых сложных вещей это время
рогалики конечно пошаговые, но если каждое действие будет отбирать один ход и у всех одна скорость игра будет унылая
тогда как сделать фракционные ходы совсем не просто

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

>>607970
чушь какая
см. выше я уже написал как это легко делается функцией которой скармливают объекты мобов
Аноним 05/09/19 Чтв 10:10:24 #167 №607979 
>>607974
у джаваскрипта есть биндинг к tensorflow
чем он хуже пистона в конце концов
Аноним 05/09/19 Чтв 12:58:50 #168 №608010 
>>607974
>а остальные фичи будут висеть мертвым грузом в дистрибутиве, ветвлениями в коде.
Опять это шизик таблетки не принял.
Аноним 05/09/19 Чтв 18:00:37 #169 №608102 
>>607967
Сборка же
Аноним 05/09/19 Чтв 18:05:57 #170 №608105 
dz.png
>>607974
Всё намного проще, из 100 велосипедистов 1 сделает игру, ну допустим немного другие числа 95/5 и т.д, есть шанс что это будешь ты, но намного больше шансов, что ты забросишь свою разработку, своего уникального движка, всё. Вывод прост, не надо делать велосипед когда ты ставишь себе цель что-то выпустить, а не кодить ради удовольствия.
Аноним 05/09/19 Чтв 18:41:16 #171 №608139 
>>608105
ты просто не разбираешься в рогаликах
с одной стороны они достаточно простые в плане графики
с другой их фишкой являются особенности механики
в итоге их сплошь и рядом пишут без фреймворков или со специализированными фреймворками вроде ncurses и libtcod
Аноним 05/09/19 Чтв 22:03:42 #172 №608234 
>>608105
Пилили же рогалики десятилетиями до выхода юнитей, и сейчас продолжают пилить, не переживай. Все знаковые рогалики от кравла до катаклизма - на кастомных движках.
Можешь сколько угодно оправдывать своё нежелание писать код, просто скорее всего разработка рогаликов - не твоё. Скачай юнити, таскай ассеты по сценке, сделай шедевр и спокойно продавай его в стиме. А хадркодную разработку оставь увлеченным ребятам.
Аноним 05/09/19 Чтв 22:29:18 #173 №608242 
>>608139
>>608234
Вы же сами отвечаете на свои вопросы, сколько десятков, сотен тысяч людей по всему миру вдохновлялись этими десятками тех у кого получилось что либо сделать? Цифры же сами за себя говорят, ~100 рогаликов против ~100.000 тех кто слились, понимаете?
Аноним 05/09/19 Чтв 22:49:54 #174 №608258 
>>608242
И что? А ты живешь в сказочном маня-мире, где у всех всё получается и все обязательно приходят к успеху?
Ты в курсе, что в любой деятельности так? 100 крутых музыкантов на 100.000 тех, кто взял в руки гитару, но так и не научился играть. 100 миллионеров на 100.000 нищебродов. 100 успешных юнити-проектов на 100.000 тех, кто скачал юнити, потаскал ассеты по сценке и забил.
Добро пожаловать в реальность, Мань. Пытаются многие, получается у единиц, обладающих специфическими качествами - упорством, силой воли, те кто на самом деле горят и кого не останавливают трудности.
Если человек хочет запилить рогалик, игру, которая на 99% состоит из кода и алгоритмов, но при этом его пугает необходимость написать немного кода своими руками - он уже опустился и проиграл, даже не попробовав.
Аноним 05/09/19 Чтв 22:52:44 #175 №608259 
>>608258
Маня тут только ты, мы пришли к цифрам потому что я привёл как пример что шанс придти к успеху выше в 90-95% у тех кто пользуется готовыми материалами(движками), а не кодит всё с нуля. А ты приводишь в пример из общего числа тех кто лишь попытался, это не верно.
Аноним 05/09/19 Чтв 23:01:17 #176 №608269 
>>608259
>90-95%
Цифры из своего маня-мирка взял? Или это тебе маркетологи юнити внушили, чтобы ты продлял ежемесячную подписку?
Для рогаликов готовый движок не нужен, фреймворк для вывода буковок/тайлов по сетке напишет студент-первокурсник за пару вечеров. А дальше начинается уже симуляция мира самой игры, которую в любом случае предстоит писать, даже с готовым движком.
А вероятность успеха зависит не от выбора движка/написания своего, а от кучи других факторов. Тот, кто может - сможет и на готовом движке, и на своём, его не остановят трудности и необходимость что-то изучить. Тот, кто изначально ставит себя в положение опущенного, признавая, что ему не по силам писать код и хочет готовенькое - тот скорее всего не сможет ничего сделать и на готовом движке, потому что при разработке будет куча проблем, требующих алгоритмической подготовки для их решения, а нежная манька код писать не приучена.
Аноним 05/09/19 Чтв 23:03:26 #177 №608272 
>>608269
Хорошо, ты меня убедил, победа твоя, ты прав. Удаляюсь из треда. Даже не знаю, спойлер так для прикола короч
Аноним 05/09/19 Чтв 23:10:03 #178 №608275 
>>608272
чувак, но он прав. рогалики это игры которые пилятся не ради выстреливания, а ради процесса, к тому же использование двигла в среде рогаликоделов скорее моветон.
это всё, разумеется, в силе ровно до тех пор пока ты не решишь делать на них деньги
Аноним 05/09/19 Чтв 23:12:36 #179 №608278 
>>608275
Да понял я, понял, уже обоссался и спрятался в уголку.
Аноним 05/09/19 Чтв 23:22:16 #180 №608283 
>>608258
В Японии не так, ты занимаешься всю жизнь одним делом, причем скорее всего семейным, которым твой отец и дед занимались, и добиваешься успеха. Если ты художник - ты становишься успешным мангакой и рисуешь аниме. Если ты музыкант - сочиняешь для них опенинги. Только программисты почему-то из японцев хуевые выходят, наверное не было в роду.
Аноним 05/09/19 Чтв 23:36:12 #181 №608290 
>>608269
Движок решает совершенно конкретные проблемы и задачи. А именно работу с железом - с тысячами моделей видеокарт со своими тараканами, с сотнями разных дистрибутивов линукса и с десятками версий винды. Те кто отказываются от движка, берут на себя работу пройти весь этот путь по граблям заново и сжечь задницу нахуй.
Да, успешные рогалики были сделаны на самописных движках, потому что они были успешны лет за 20 до появления юнити.
Аноним 06/09/19 Птн 03:09:47 #182 №608300 
>>608283
японец руби создал

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

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

Аноним 06/09/19 Птн 04:14:11 #183 №608302 DELETED
Аноним 06/09/19 Птн 04:43:24 #184 №608304 
>>608290
>А именно работу с железом - с тысячами моделей видеокарт со своими тараканами,
DirectX (Direct3d, XAudio, XInput)

>с сотнями разных дистрибутивов линукса
Линукс не нужен
Аноним 06/09/19 Птн 09:33:15 #185 №608331 
>>572542
>спрайты выполнены в размере 21x21
Еще раз спрашиваю. Почему такой странный размер тайлов?
Аноним 06/09/19 Птн 09:35:06 #186 №608332 
>>608300
>японец руби создал
Только подтверждает, лол. Руби на момент создания - ужасно всратый язык.
Аноним 06/09/19 Птн 09:36:54 #187 №608333 
>>608304
>DirectX
Это не гарантирует ни то, что ты на нем сможешь нормально окно инициализировать (учитывая всякие нюансы вроде второго монитора), ни то, что не объебешься где-то в вызовах апи или шейдерах.
Аноним 06/09/19 Птн 09:55:24 #188 №608338 
>>608333
>>608290
Вот это дивный маня-мир, давно такого не встречал.
Ты правда думаешь, что при разработке без движка тебе нужно писать код отдельно для каждой из существующих видеокарт?
Ты вообще не представляешь, что такое кросс-платформенная разработка?
Ты берешь либу типа SDL/GLFW и одной строчкой получаешь окошко с контекстом opengl нужной версии. Под любую систему, от кофеварки до телефона, не говоря про десктопы. Ты даже можешь взять bgfx в качестве абстракции графического апи, на винде он будет компилиться под directx, на линуксе/мобилках - под opengl.
Ты пишешь код один раз, и потом компилишь его без изменений под любую платформу. Версий винды не десятки, на дистрибутивы тоже поебать. В 2к19 достаточно одного билда статического бинарника под x64 шин и одного под x64 линукс. Всё.
Вылезай из маня-мира. А то как-то неудобно получается, убеждаешь всех, что без движка невозможно разрабатывать, но при этом фантазируешь, что там надо писать код под тысячи видеокарт. Зачем фантазировать, если ты не пробовал?
Аноним 06/09/19 Птн 10:05:30 #189 №608341 
>>608338
>Ты правда думаешь, что при разработке без движка тебе нужно писать код отдельно для каждой из существующих видеокарт?
Да, тебе будет нужно учитывать НЮАНСЫ для каждой из существующих видеокарт.
Для того, чтобы ты понимал, отсылаю к блеклисту хрома. А это всего лишь рендер текста и картиночек.
https://chromium.googlesource.com/chromium/src/gpu/+/master/config/software_rendering_list.json
>Ты даже можешь взять bgfx
Началось сектанство, твой bgfx уже везде обоссали, те кто им пользовался как раз ноют от того, что он нихуя не кроссплатформенный, что его внутренний абстрактный язык шейдеров раскрывается на реальном железе в нерабочие конструкции.
>Версий винды не десятки,
Ну конечно, что еще спизданешь? Для XP и для 10-ки нужны разные сборки, более того, в 10-ке есть разные билды, и иногда софт для новых не работает в старых.
>на дистрибутивы тоже поебать.
Нинужно, ясно-понятно. Бонусом у тебя не будет видимо и андроид версий, тоже нинужно.
>А то как-то неудобно получается, убеждаешь всех, что без движка невозможно разрабатывать, но при этом фантазируешь, что там надо писать код под тысячи видеокарт.
Ну если тебе хочется вместо работы над игрой исправлять баги связанные с видеокартами, потому что тебе весь стим засрут отрицательными отзывами не работает - вперед и с песней.
Аноним 06/09/19 Птн 10:25:35 #190 №608344 
блин какая фигня

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

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

чисто как иллюстрация - он будет работать на любом девайсе который поддерживает современный браузер и десктопную клавиатуру. какие нюансы какие нафиг видеокарты лол. я вообще смутно представляю что такое видеокарта. если бы jsfiddle лучше поддерживал мобилки я бы не поленился сделал бы и поддержку таучскринов
Аноним 06/09/19 Птн 10:25:52 #191 №608345 
>>608341
>XP
>2k19
Ну-ну.
>Нинужно, ясно-понятно.
Нинужно потому, что один статический билд под линукс x64 работает на любом дистрибутиве.
>ля того, чтобы ты понимал, отсылаю к блеклисту хрома.
Сейчас бы сравнивать рендер браузера и рогалика.
>Ну если тебе хочется вместо работы над игрой исправлять баги связанные с видеокартами
Опять пошли маня-фантазии. Ни одной программы не написал, зато испугался багов с видеокартами.
Все правильно пишешь, сложна, нивазможна, даже не пробуй ничего писать сам, если пускаешь жидкую подливу в штаны от одних маня-фантазий, даже не написав ни строчки кода. Видимо геймдев это в целом не твоё.
Возьмешь вот юнити тот же, начнешь что-то пилить и наткнешься на какой-нибудь баг в ui подсистеме, сразу пукнешь в штаны. А если краш словишь, вдруг еще сердце не выдержит от испуга.
Аноним 06/09/19 Птн 10:28:18 #192 №608347 
и да, тайлы тоже несложно прикрутить при желании
Аноним 06/09/19 Птн 10:56:41 #193 №608351 
>>608345
>XP
>2k19
Рогалики всегда славились тем, что могут работать даже в терминале, даже в досе, а твой не может работать нигде ниже win7/10 - вот это реально "ну-ну". Вопрос - а нахуя такой самописный движок нужен тогда?
> один статический билд под линукс x64 работает на любом дистрибутиве.
Линуксоиды тебе просто у виска пальцем покрутят, ну да ладно, линукс же нинужно.
>Сейчас бы сравнивать рендер браузера и рогалика.
И что же в них такого, почему их нельзя сравнивать? Картинки и текст там и там.
> Ни одной программы не написал, зато испугался багов с видеокартами.
>пускаешь жидкую подливу в штаны от одних маня-фантазий, даже не написав ни строчки кода.
Ну все пошли проекции. Иди пиши движки, в /pr например, никто тебе не запрещает. А тут люди игры делают.
Аноним 06/09/19 Птн 11:02:39 #194 №608352 
>>608344
Браузерка это конечно вариант.
Там, естественно, будут свои проблемы, не с видеокартами, а с браузерами. Например, с тем же масштабированием игры под размер окна. Или чтобы работало во всех браузерах, на разных мобильных устройствах, с разным увеличением шрифта, с разным адблоками, и т.д. (уже предвижу нинужно)
Аноним 06/09/19 Птн 11:03:00 #195 №608353 
>>608351
>Рогалики всегда славились тем
Те кто ебется в очко и любит быть обоссаным, всегда славились тем, что носят обувь и верхнюю одежду.

>Иди пиши движки, в /pr например, никто тебе не запрещает.
НИКТО ТЕБЕ НЕ ЗАПРЕЩАЕТ
@
[ЗАПРЕЩАЕТ]


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

мимо
Аноним 06/09/19 Птн 11:06:59 #196 №608354 
>>608353
Шизик, таблеточки попей.
Аноним 06/09/19 Птн 11:08:29 #197 №608355 
>>608354
То есть аргументов в пользу своей точки зрения у тебя нет, правильно понимаю?
Аноним 06/09/19 Птн 11:14:58 #198 №608356 
>>608355
Ты блядь поехавший нахуй, ты просто высрал рандомные слова, а аргументы требуешь с меня, проорал.
Аноним 06/09/19 Птн 11:24:08 #199 №608359 
>>608356
А, ну так ты сразу бы сказал, что тупой. Давай объясню:
1. То, что рогалики «всегда славились» тем что запускаются даже в терминале, это вообще ничего не значит. Ради примера я привёл тебе маргиналов, которые точно так же носят как и ты, одежду, и обувь, но это не делает тебя таким же маргиналом, ведь нужны какие-то более конкретные признаки. В случае с рогаликами, это берлинская интерпретация (о терминале там ни слова)
2. В одном и том же предложении ты запрещаешь (якобы написание игрового движка, это видите ли не написание самой игры) и сразу же пишешь «никто тебе не запрещает»

Аноним 06/09/19 Птн 11:45:58 #200 №608365 
>>608359
Ты наверное первокурсник или что-то типа того, короче молодой еще и аутично все воспринимаешь буквально. ну давай смахнемся.
1. Рогалики в терминале - это не маргинальность, а мейнстрим. Возможно ты называешь рогаликами рогалайты, но это уже твоя проблема, поскольку у рогаликов довольно четкое определение. И большинство топовых рогаликов запускается в терминале (brogue, dcss, nethack, adom и т.д.)
2. Вот именно что никто ему не запрещает, я же прямым текстом говорю флаг в руки, пиши движок и трать на его поддержку больше времени, чем на написание игры на готовом движке, кто против то? Покажи в каком посте я написал "не сметь, запрещено, не имеешь право" и я сожру какое-нибудь гавно с пруфами.
Аноним 06/09/19 Птн 11:53:56 #201 №608366 
>>608365
>Вот именно что никто ему не запрещает, я же прямым текстом говорю флаг в руки, пиши движок и трать на его поддержку больше времени, чем на написание игры на готовом движке, кто против то? Покажи в каком посте я написал "не сметь, запрещено, не имеешь право" и я сожру какое-нибудь гавно с пруфами.
Вот тебе тобой же написанный текст:
>Ну все пошли проекции. Иди пиши движки, в /pr например, никто тебе не запрещает. А тут люди игры делают.
то есть ты буквально говоришь человеку уйти в другой раздел, потому что «тут люди игры делают»
Аноним 06/09/19 Птн 11:54:48 #202 №608368 
>>608365
>Возможно ты называешь рогаликами рогалайты
А это не одно и то же? Можно объяснения по этому поводу?
Аноним 06/09/19 Птн 11:57:44 #203 №608370 
>>608366
>никто тебе не запрещает
Аноним 06/09/19 Птн 12:02:19 #204 №608371 
>>608370
Никто не запрещает ему в /pr писать движки, а тут запрещают, потому что «тут люди игры делают. На структуру предложения посмотри, даун. Ты либо тупой настолько, что не смог предложение правильно построить, либо не очень, но все же тупой, ведь сейчас так тухло увиливаешь
Аноним 06/09/19 Птн 12:03:26 #205 №608372 
>>608368
Немного лень, вон анон выше писал про берлинскую интерпретацию, можно сказать так: была игра rogue, рогалики это rogue-like, т.е. похожие на нее, а roguelite это roguelike-like, т.е. похожие на рогалик, но не имеющие каких то ключевых моментов, или слишком сильно изменившие механику или дизайн.
Например, Faster Than Lite часто записывают в рогалики, но ведь всем понятно что это не рогалик, ты же не чистишь пещеры, лол. Это чисто маркетинг.
Аноним 06/09/19 Птн 12:04:16 #206 №608373 
>>608371
Предложение составлено тонко, а в том что ты его так интерпретируешь виноват только ты сам :3 Нигде не сказано что движки делают только в /pr.
Аноним 06/09/19 Птн 12:04:50 #207 №608374 
>>608372
Ссылочку на требования поддержки терминала, плиз
Аноним 06/09/19 Птн 12:05:21 #208 №608375 
>>608371
>а тут запрещают,
>тут
Кстати ты тож маневрируешь, изначально то ты утверждал что "вообще" запрещают.
Аноним 06/09/19 Птн 12:06:05 #209 №608376 
>>608373
>Нигде не сказано что движки делают только в /pr.
Достаточно того, что сказано, что их не делают в gd
Аноним 06/09/19 Птн 12:06:07 #210 №608377 
>>608374
Ты уже дрожащими руками промахиваешься кому ответить?
Аноним 06/09/19 Птн 14:15:03 #211 №608396 
>>607974
>На ecs с хитрыми оптимизациями симулировать сотни тысяч сущностей вообще не проблема, даже на не самом топовом железе.

Ебать, поясни конкретнее, такое рил возможно? Вот захочу я въебать овер 100 сущностей на карте, у каждого из которых будет свои инвентари и сложная анатомия, разве это возможно чтобы двигло и проц эту всю хуйню вывозили? я просто смотрю на те же Дварф фортерсы и котяклизьмы, там что-то подобных совсем не пахнет.
Аноним 06/09/19 Птн 15:15:19 #212 №608415 
>>608352

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

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

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

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

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

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

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

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

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

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


Аноним 06/09/19 Птн 15:26:01 #213 №608418 
>>608415
>это слишком низкоуровневые проблемы чтобы большинству кодеров интересоваться ими
Верно, а при написании своего движка придется в этом разбираться. Потому что именно он будет мостом между игровой логикой и средой, называй как хочешь.
>это элементарный веб дизайн, адаптивная верстка, это все обычнейшие вещи которые решает создатель любой веб странички
На словах у всех все элементарно, лол, а потом везде ничего не влезает и вылезают скроллбары по бокам.
>я написал сейчас в es6, он поддерживается всеми браузерами
Смотря каких фич ты туда надобавляешь, например нет гарантии что это будет работать на встроенном браузере андроида 4.4
>для поддержки мобилок надо всего лишь добавить
Не только, например еще придется повоевать с вылезающими тулбарами сверху и снизу.
>монетизировать
А я не в плане монетизации говорил, а в плане технической работы, у разных людей в разных браузерах стоят разные дополнения, которые могут резать всякий контент от чего верстка поедет.
Аноним 06/09/19 Птн 15:31:22 #214 №608419 
>>608396
я видел сотни существ на карте и достаточно сложных хотя анатомии у них толком не было иирк. инвентари, куча скиллов и итемов и они друг с другом дрались ещё под управлением компьютера

incursion та же

только все шансы что на плюсах это у тебя будет течь и глючить как все та же incursion
Аноним 06/09/19 Птн 15:35:17 #215 №608423 
>>608419
А при чём тут плюсы, если не секрет? Может это просто скорее вопрос оптимизации, кода?
Аноним 06/09/19 Птн 15:42:36 #216 №608426 
>>608423
мне показалось тот анон который интересуется сложной симуляцией - плюсовик и я его предупреждаю что на плюсах это может быть непросто, это сложный язык
Аноним 06/09/19 Птн 15:48:29 #217 №608428 
>>608426
Если брать с++11 и делать без raw указателей, то не так уж и страшно в наши дни.
Аноним 06/09/19 Птн 16:33:39 #218 №608437 
>>608426
Да, это я, и я предполагал С++, но я подводных не знаю. В каком образе он непростой? И ты можешь порекомендовать что-то лучше?
Аноним 06/09/19 Птн 18:49:19 #219 №608454 
>>608351
> а твой не может работать нигде ниже win7/10 - вот это реально "ну-ну".
Схуяли? Как раз таки рогалик на моём самописном движке сможет работать где угодно. Я могу запилить логику в бэкенде + фроненд под терминал, под дос, подо что угодно. Могу поддерживать любые системы.
А на готовом движке ты соснешь хуйца, тот же юнити под xp без костылей не заведется, насколько знаю.
Аноним 06/09/19 Птн 18:53:43 #220 №608456 
>>608351
>Линуксоиды тебе просто у виска пальцем покрутят, ну да ладно, линукс же нинужно.
Спешите видеть, манька не знает, что такое статическая линковка. И линукс наверное видела только на картинках. Зато с умным видом кудахтает что-то от имени линуксоидов.
>И что же в них такого, почему их нельзя сравнивать? Картинки и текст там и там.
Потому что это абсолютно разные по сложности, объему и принципу работы вещи, в принципе не сравниваемые. Рендер браузера во много раз сложнее рендера любой 2д игры, не обязательно текстовой, dom-дерево отрендерить со всеми css правилами это не хуй собачий.
В общем, можешь продолжать подливиться и дристать себе на лицо, но посоветую тебе проследовать в юнити тред и там кудахтать.
Аноним 06/09/19 Птн 18:54:53 #221 №608457 
>>608365
>И большинство топовых рогаликов запускается в терминале
>чем на написание игры на готовом движке, кто против то
Боюсь спросить, как ты собрался рогалик на юнити запускать в терминале.
Аноним 06/09/19 Птн 18:57:17 #222 №608458 
>>608437
Если хочешь по хардкору упороться, то для рогалика с тяжелой симуляцией мира rust лучше С++ по всем параметрам.
Там в принципе невозможен ряд проблем, которые бывают с плюсами - утечки памяти, сегфолты. При этом, код летает так же быстро. Но придется вложить время в изучение.
Аноним 06/09/19 Птн 18:58:17 #223 №608460 
>>608437
>С++, но я подводных не знаю.
Тяжело тогда придется.
>можешь порекомендовать что-то лучше?
Самые быстрые языки это C/C++/Rust. Но они и сложные.
А из остальных пофиг что брать, C#/Java/Go/JS/Swift они там примерно одинаковы по скорости. Только питон медленнее.
Аноним 06/09/19 Птн 18:59:07 #224 №608461 
>>608454
Вот когда напишешь и отладишь под все платформы, тогда и приходи. Может поддерживать он, лол.
Аноним 06/09/19 Птн 19:00:43 #225 №608462 
>>608461
А ты когда на готовом движке сделаешь хоть что-то, тоже приходи.
Аноним 06/09/19 Птн 19:07:04 #226 №608463 
>>608458
>Там в принципе невозможен ряд проблем, которые бывают с плюсами - утечки памяти, сегфолты
что-то ты меня заинтересовал, я когда-то учил си и мне интересно как это язык быстрый без проблем ручного управления памятью, надо почитать о нём

мимо другой анон
Аноним 06/09/19 Птн 19:07:49 #227 №608464 
>>608456
>Спешите видеть, манька не знает, что такое статическая линковка.
Ты прям все ядро с собой прилинкуешь, и никаких системных вызовов делать не будешь, а рисовать и ввод делать будет святой дух, ясно-понятно. Если бы все было так просто как ты говоришь, то всякие вальвы бы так и релизили, но однако же это так не работает.
>Потому что это абсолютно разные по сложности, объему и принципу работы вещи, в принципе не сравниваемые.
Нет, это не так.
>. Рендер браузера во много раз сложнее рендера любой 2д игры
Нет, не сложнее, 2д игры это несколько слоев с разным параллаксом, динамическое освещение, деревья сцен и объектов, ровно то же самое.
> dom-дерево отрендерить со всеми css правилами это не хуй собачий.
А вот это показывает, что ты тупой даун и вообще не понимаешь, о чем шла речь. Я где-то писал о разборе dom и css? Нет, я писал только о том, что когда рендерят то, что уже разобрано, в opengl и подобном, глючит на реальном железе и драйверах.
Свободен.
Аноним 06/09/19 Птн 19:09:42 #228 №608465 
>>608463
Это пиздец ебанутый язык, тебе там придется управлять временем жизни, и уговаривать компилятор собрать хоть что нибудь, короче мем уровня хаскеля, делать на нем конечно ничего не возможно, а учить наверное дольше чем c++ раз в 10.
Аноним 06/09/19 Птн 19:21:35 #229 №608469 
>>608465
>делать на нем конечно ничего не возможно
Ну да, а посоны-то и не знали. Уже овердохуя компаний юзает его в продакшене.
https://www.rust-lang.org/production/users
>Это пиздец ебанутый язык
Я так понял, что для тебя всё, что не юнити и все, где нельзя таскать ассеты по сценке - пиздец ебанутое. Можешь не продолжать.
>>608464
>Ты прям все ядро с собой прилинкуешь, и никаких системных вызовов делать не будешь, а рисовать и ввод делать будет святой дух, ясно-понятно.
Я даже разбирать это не буду, бред шизофреника, видевшего линукс только на картинке и не понимающего смысла слов, которые он пишет.
Вот тебе пример статического бинарника, который просто качается и запускается на любом дистрибутиве.
https://godotengine.org/download/linux
>Нет, это не так.
Нет, это так. Можешь посмотреть исходники какого-нибудь хромиума, там один рендеринг по объему кода больше чем весь условный годот.
>Нет, не сложнее, 2д игры это несколько слоев с разным параллаксом, динамическое освещение, деревья сцен и объектов, ровно то же самое.
А вот это показывает, что ты тупой даун и вообще не понимаешь, о чем шла речь. Я где-то писал о разборе слоёв и паралакса, и дерева сцен? Нет, я писал только о том, что когда рендерят то, что уже разобрано, в opengl и подобном, глючит на реальном железе и драйверах.
В общем, обдристался ты знатно, лучше не продолжай дальше позориться.
Не переживай, это анонимный форум, никто не запомнит твой обсёр, так что можешь расслабиться и перестать усираться в ответ.
Аноним 06/09/19 Птн 19:25:13 #230 №608470 
>>608469
>Ну да, а посоны-то и не знали. Уже овердохуя компаний юзает его в продакшене.
Его юзают професси_аналы с з/п от 200к рублей, причем тут 2ch gd?
Аноним 06/09/19 Птн 19:30:09 #231 №608471 
>>608470
звучит как повод выучить раст лол

вангую впрочем что туда сложно вкатиться и большинство борщехлебы на низкой зп
Аноним 06/09/19 Птн 19:31:42 #232 №608472 
>>608470
Ну ты изначально спизданул что-то про язык-мем и что на нём ничего нельзя сделать, а теперь пытаешься оправдаться и соскочить за счет того, что на 2ch gd не может сидеть профессиональный программист.
Аноним 06/09/19 Птн 19:39:17 #233 №608475 
>>608471
Раст для вката в айти не подходит, никому джуны на расте не нужны, его юзают как второй язык бэкендщики с опытом, когда у плюсов не хватает безопасности, а у какой-нибудь джавы скорости.
А для программирования для души он отлично подходит, в том числе и для геймдева. Много обучающих материалов, удобная экосистема, пакетный менеджер.
Аноним 06/09/19 Птн 19:40:26 #234 №608476 
>>608471
Выучи, если сможешь. Там и игровые движки уже есть так то.
Аноним 06/09/19 Птн 19:41:14 #235 №608477 
>>608472
Так и на Хаскеле несколько человек в мире пишет всякую телефонию, но для большинства он иначе как мемом не является.
Аноним 06/09/19 Птн 20:12:57 #236 №608481 
>>608477
>приравнивать несколько человек и несколько сотен компаний уровня mozilla, dropbox, atlassian, cloudflare, npm
Я надеюсь, что это троллинг тупостью, потому что если у тебя на полном серьёзе такое в голове, то это даже немного грустно.
Аноним 06/09/19 Птн 20:16:23 #237 №608483 
>>608481
А в чем ты усматриваешь противоречие? В mozilla, dropbox, npm и т.д тоже не все на расте пишут, наверное это очевидно, что там тоже всего несколько человек этим занимается?
У хаскеля тоже есть именитые компании
Напрмер Intel, nvidia, qualcomm, AT&T, пара банков америки и т.д.
https://wiki.haskell.org/Haskell_in_industry
Аноним 06/09/19 Птн 20:31:42 #238 №608486 
1455294212640.png
1536498832106.png
>>608469
>Вот тебе пример статического бинарника, который просто качается и запускается на любом дистрибутиве.
А тут даже и видеть линукс не надо, качаем твою годотю, открываем в readelf, читаем вывод. Опа, ты пиздабол, NEEDED libc и прочее конкретной версии. Вот тебе и "все" дистры в пролете.
>Нет, это так. Можешь посмотреть исходники какого-нибудь хромиума, там один рендеринг по объему кода больше чем весь условный годот.
Раздутость хрома как аргумент? Нет пути! ну давай сравнивать, ой, как же так, размер годотю которую ты скинул такой же как у хромиум эмбеддед, надо же оказывается ты опять напиздел!
>А вот это показывает, что ты тупой даун и вообще не понимаешь, о чем шла речь. Я где-то писал о разборе слоёв и паралакса, и дерева сцен?
А, ты решил паясничать, клоун, ну окей. Тогда и в хроме нет никаких dom и css а есть только текст и картинки.
>Нет, я писал только о том, что когда рендерят то, что уже разобрано, в opengl и подобном, глючит на реальном железе и драйверах.
Хорошо что ты наконец признал, что на реальном железе и драйерах глючит и движкописателю с этим разбираться.
>В общем, обдристался ты знатно, лучше не продолжай дальше позориться.
>Не переживай, это анонимный форум, никто не запомнит твой обсёр, так что можешь расслабиться и перестать усираться в ответ.
Пока что обсираешься только ты, шизюнь.
Аноним 06/09/19 Птн 21:16:36 #239 №608492 
>>608483
>Напрмер Intel, nvidia, qualcomm, AT&T, пара банков америки и т.д.

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

На одной из моих прошлых работ у нас был человек, который написал утилиту на F#, правда никто кроме него ей не пользовался и когда он ушел про нее забыли. Вот примерно на таком уровне весь этот haskell in industry и находится
Аноним 06/09/19 Птн 21:19:05 #240 №608493 
>>608492
Ну вот и раст примерно такой же.
F# охуенный, да. Классный паттерн матчинг, функциональщина, и при этом вся мощь дотнета на кончиках пальцев. Когда годот научится в экспорт c# в emscripten, я сразу перейду на него и прикручу.
Аноним 07/09/19 Суб 04:02:06 #241 №608535 
18gOLsqBNfc.jpg
>>608460
>Тяжело тогда придется.
>Самые быстрые языки это C/C++/Rust. Но они и сложные.
На сложность пiхуй, я готов въебать и наебать и того сего нахуй, динамическая память тыры пыры ебать делать, в общем под завязку обмазаться этим языком, если как говорите они сложные только, то всё тогда хорошо.

>>608458
Опять же, время на изучение это всё ничто для меня, вот о ряде проблем хотелось бы знать заранее, как избежать их?
-Про уточки памяти я знаю вроде только в общих чертах, но не знаю пока когда они возникают (при ебланском использовании динамической памяти, и не уборке за собой?)
- Про сегфорты не знаю вообще. Разъясните позюзя...
Аноним 07/09/19 Суб 04:40:45 #242 №608538 
>>608535
>Про сегфорты не знаю вообще
ты на плюсах писал хоть что-нибудь...
Аноним 07/09/19 Суб 06:24:34 #243 №608546 
>>608538
Я этот термин не слышал
Аноним 07/09/19 Суб 11:05:13 #244 №608604 
>>608535
int main()
{
((void(*)(void))1)(); //hello segfault
return 0;
}
Аноним 07/09/19 Суб 11:36:22 #245 №608609 
>>608535
> (при ебланском использовании динамической памяти, и не уборке за собой?)
Типа того, когда например вызываешь new для какого-то временного буфера в цикле, а потом не вызываешь delete. И когда выходишь из этого цикла, ты теряешь указатель на эту область и уже ничего не можешь с ней сделать, она остается выделенной.
Но в современном С++ это уже не проблема, можно написать 99% программ вообще без ручного выделения памяти через new, с помощью RAII, умных указателей, стандартных структур типа вектора, и т.д.
Сегфолты возникают тоже при ручной работе с памятью, когда ошибся указателем и лезешь в недоступную область памяти, или пытаешься записать в read-only память.
В расте такие ошибки в принципе невозможны, программа с ними просто не скомпилится.
Аноним 07/09/19 Суб 11:55:30 #246 №608615 
>>608609
Ну впринципе это еще хуйня, то есть банально быть внимательным и уже как бы эти ошибки отсечены. Еще какие-то подводные камни крестов?
Аноним 07/09/19 Суб 11:58:03 #247 №608616 
Снимок экрана от 2019-09-07 11-50-32.png
>>608486
>Вот тебе и "все" дистры в пролете.
А посоны-то и не знали. Они спокойно юзали бинарник годота на любом дистрибутиве, но тут пришла чмоня с двача и сказал, что они все оказывается в пролёте
>читаем вывод.
Ого, ты умеешь читать, неожиданно. Если внимательно почитаешь список библиотек на скрине, то увидишь, что эти библиотеки есть в любой линукс-системе с установленными иксами, т.е. на любом дистрибутиве, кроме серверных.
>и прочее конкретной версии
Опять пиздёж и непонимание, как работает линковка. Привязки к конкретным версиям системных библиотек нет, автоматически будут подхвачены системные либы, установленные в дистрибутиве, независимо от версии.
libc.so.6, например, это не конкретная версия библиотеки, это симлинк на версию, установленную в системе.
libasound.so.2 например в моём дистре резолвится на ALSA_0.9.0rc4, на другом дистре это может быть другая версия.
Я понимаю, что это так весело, спорить на тему, в которой ты нихуя не понимаешь, про операционную систему, которую ты видел только на картинках и мемах из интернета, сидя под виндовсом, но лучше бы ты прекратил дристать себе в штаны на глазах у всей борды.
Аноним 07/09/19 Суб 12:08:19 #248 №608618 
>>608615
> банально быть внимательным
Это только кажется, что просто. Но весь код просто невозможно контролировать. Вот выделил ты память, потом вызываешь метод из какой-нибудь левой либы, а она бросает эксепшен. Пусть даже у тебя стоит обработчик эксепшенов где-то, ты отловил этот эксепшен, но стек фрейм уже потерян, указатель на выделенную память просран и случилась учетка.
>Еще какие-то подводные камни крестов?
Нет пакетного менеджера, сложно менеджить зависимости, надо либо ставить все либы руками, либо юзать конан, но тогда придется писать под него пакеты, либо пойти по пути годота и тупо переносить исходники зависимостей в свой проект и билдить всё вместе.
Придется разбираться с линковкой, чтобы билдить переносимые бинарники. Ты можешь собрать бинарник, который будет работать у тебя, но пропустить какую-нибудь либу, не вкомпилить её в бинарник, и на другом компе оно не заведется.
Модули пока не завезли, придется ебаться с заголовочными файлами, это не очень удобно, особенно если надо писать темплейты.
В расте всех этих проблем нет, там пакетный менеджер, модули, билд переносимых статических бинарников.
Аноним 07/09/19 Суб 12:09:21 #249 №608619 
>>608616
Да что же тебе так нравится серить себе на голову, а потом размазывать по своим волосам и лицу говно? Все и так уже поняли что у тебя "работает на всех дистрибутивах" означает "на моей убунте запустилось, УМВР", а то что на других семействах может быть libc другой версии, с другим ABI, тебе естественно невдомек. Ну что тут сказать, если уж даже я, который по твоим словам "видел линукс только на мемах" знает больше тебя, выходит ты ламер хуже червя-пидора и обсуждать с тобой тащемта и нечего.
Аноним 07/09/19 Суб 12:16:46 #250 №608623 
e17d56ee5fdebb9f3cd1e5e5f4b0fc84.jpg
>>608619
>Да что же тебе так нравится серить себе на голову, а потом размазывать по своим волосам и лицу говно? Все и так уже поняли что у тебя "работает на всех дистрибутивах" означает "на моей убунте запустилось, УМВР", а то что на других семействах может быть libc другой версии, с другим ABI, тебе естественно невдомек. Ну что тут сказать, если уж даже я, который по твоим словам "видел линукс только на мемах" знает больше тебя, выходит ты ламер хуже червя-пидора и обсуждать с тобой тащемта и нечего.
Аноним 07/09/19 Суб 12:21:47 #251 №608626 
>>608619
>, а то что на других семействах может быть libc другой версии, с другим ABI,
Так вроде бы еще с начала девяностых на всех десктопных дистрах стоит libc.so.6.
А в целом, в теории конечно может, у одного процента пердоликов, билдивших линукс из сорцов, или у какого-нибудь любителя некрожелеза. А у 99% юзеров обычных десктопных дистров будет стоять libc.so.6.
Но твою позицию я понял, если твой билд не будет работать у одного пердолика из пяти миллионов обычных пользователей, то это конечно пиздец как хуёво, с таким раскладом лучше вообще ничего не программировать и не компилировать. А то вдруг именно этот пердолик скачает, а у него не запустится, это пиздец как хуёво будет, что посоны подумают.
Аноним 07/09/19 Суб 12:31:22 #252 №608627 
>>608618
у меня пока синдром утёнка не разрешает перейти на раст, я этот язык мало знаю, и пока не уверен в его скажем так эффективности по сравнению с крестами теми же. А за поясняловую благодарствую
Аноним 07/09/19 Суб 13:07:14 #253 №608638 
Поясните анончики любимые, смысл срача? Почему всем не придерживаться просто правила -> Хочешь делать игру, берёшь Юнити,Уеч,гейм макер. Хочешь просто кодить -> любой голый язык или веб. Всё, срачи пропадут.
Аноним 07/09/19 Суб 13:23:41 #254 №608648 
Screenshot2019-09-07-20-13-22-916com.opera.browser.png
>>608638
если ты делаешь рогалик или даже платформер тебе не особо нужен фреймворк вообще

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

в рогаликах от фреймворка вообще мало толку, в платформерах хоть риал тайм физика есть и она более менее универсальная. а в рогалике тайловый пошаговый мир с одной стороны, это несложно в плане перемещения и столкновений, а с другой например я хочу такую вот систему видимости, а фреймворк её делает по другому, короче связывает руки
Аноним 07/09/19 Суб 14:04:15 #255 №608660 
>>608648
РРРЯЯ НИВАЗМОЖНАЯ ЮПИНИ НАДА БРАТЬ!! НИЛЬЗЯ ТАК, ТЫ САМЫЙ УМНЫЙ ЧТОЛИ? ЮПИТИ ПРИДУМАЛИ, НАДО ЕГО БРАТЬ, ТОЛЬКО В ЮПЕИТИ МОЖНО ДЕЛАТЬ ИГРЫ!!11
Аноним 07/09/19 Суб 14:05:19 #256 №608661 
>>608660
Гоудотер порваный?
Аноним 07/09/19 Суб 14:10:28 #257 №608663 
>>608661
Хорошо потушил, клоун
Аноним 07/09/19 Суб 14:18:14 #258 №608669 
>>608663
Пощютил те за щеку, проверяй, петушара.
Аноним 07/09/19 Суб 14:58:37 #259 №608691 
1567857497493.jpg
>>608669
Аноним 07/09/19 Суб 15:09:10 #260 №608693 
>>608691
Сорян, в отличие от тебя сосуна я релизю игры и делаю тысячи бакинских в месяц ;)
Аноним 07/09/19 Суб 15:15:28 #261 №608696 
15669168775200.png
>>608693
>Сорян, в отличие от тебя сосуна я релизю игры и делаю тысячи бакинских в месяц ;)
Аноним 07/09/19 Суб 15:16:51 #262 №608698 
>>608696
Эх эти боевые картиночки...
Аноним 07/09/19 Суб 15:17:51 #263 №608700 
15668428752830.png
>>608698
>Эх эти боевые картиночки...
Аноним 08/09/19 Вск 15:08:34 #264 №608895 
>>572542
>спрайты выполнены в размере 21x21
Сука, ты заебал. Что так сложно ответить почему выбрал такой размер спрайтов?
Аноним 08/09/19 Вск 15:15:05 #265 №608901 
>>608895
Какая разница то лол? Ну выбрал он и выбрал. Нечетный размер позволяет симметрию кстати.
Аноним 10/09/19 Втр 07:59:17 #266 №609330 
>>607968
>> Поэтому во всех трушных рогаликах игрок и враг это один и тот же класс. Так везде, от dungeon crawl'a до катаклизма.
И там и там разные. Ты хоть в код заглядывал, а не в свои фантазии?
Аноним 10/09/19 Втр 12:49:27 #267 №609360 
>>609330
Мимокрокодил, заинтересовался. Поясните, какие подводные камни, если сделать класс Персонаж, в котором описать меш, коллизии, анимации движения, от него унаследовать класс "Игрок" в котором описать управление с инпута, и класс "НПЦ" в котором описать управление от ИИ?
Или, если кому неугодно, сделать класс "Персонаж", в котором описать меш, коллизии, анимации движения, а так же задать поле для хранения компонентов, создать класс "Компонент", от него унаследовать класс "Управление", от него унаследовать класс "Игрок" в котором описать управление с инпута, и класс "НПЦ" в котором описать управление от ИИ и объекту "Игрок" класса "Персонаж" накинуть компонент "Игрок"?
Аноним 10/09/19 Втр 14:35:22 #268 №609366 
>>609360
Сейчас 2к19, никто не наследует то что можно сделать через ECS
Аноним 10/09/19 Втр 18:49:29 #269 №609387 
>>609366
Ебать ты тупой. Слово "компонент" не нашёл? Или после слова "наследовать" дальшенечитал?
Аноним 10/09/19 Втр 20:11:05 #270 №609395 
Стикер
>>609387
>"Компонент"
>от него унаследовать
>от него унаследовать
Аноним 10/09/19 Втр 20:20:29 #271 №609397 
>>609360
>. Поясните, какие подводные камни, если сделать класс Персонаж, в котором описать меш, коллизии, анимации движения, от него унаследовать класс "Игрок" в котором описать управление с инпута, и класс "НПЦ" в котором описать управление от ИИ?
Если ты захочешь одновременно подключить и управление игроком, и управление ИИ, ты соснул с наследованием. Например, чтобы персонаж автоматом уклонялся от пуль, но при этом можно было контролировать его вручную.
Компоненты в ecs подразумевают модульность, их можно подключать сразу несколько к одной сущности.
Накидываешь компонент брони на сущность шлема, можешь надевать его. Накидываешь еще компонент оружия с колющим уроном - можешь дополнительно бодаться им.
А на ООП ты жидко пукнешь спермой, не зная что от чего наследовать, шлем от оружия или оружие от шлема.
Аноним 10/09/19 Втр 20:28:19 #272 №609398 
>>609397
ЕЦС это композиция ООП.
Персонаж - сущность. Игрок и ИИ - компоненты.
>>609395
Вот смотри:
using Unity;
public class MyClass : MonoBehaviour { }
Это что? Не наследование? Не классы? Не ООП? А что это?
Аноним 10/09/19 Втр 20:56:05 #273 №609405 
>>609397
В ecs ты точно так же жидко пукаешь, если у тебя коллизия между полями компонентов. Мозг в любом случае придется юзать, чтобы выделять и именовать сущности. Оружие и шлем очевидно пронаследуются от единицы снаряжения.
Аноним 10/09/19 Втр 21:23:52 #274 №609413 
>>609405
Хуя ты ебанашка. Нет никаких коллизий в нормальном ecs, ты видимо просто нормальный не видел, жертва ООП головного мозга.
>>609398
>юнити
>ecs
Проиграл. Иди дальше ассеты по сценке тягай, манька.
Аноним 10/09/19 Втр 21:56:08 #275 №609421 
>>609413
Нет никаких коллизий в нормальном ООП, ты видимо просто нормальный не видел, жертва ECS головного мозга.
>"не зная что от чего наследовать, шлем от оружия или оружие от шлема."
У тебя в ecs будет поле снижение урона в броне и снижение урона в шлеме, и ты не будешь знать каким пользоваться - вот уровень твоей аргументации.
Аноним 10/09/19 Втр 22:21:32 #276 №609429 
>>609360
Если ты спрашиваешь за код тех проектов, то так не делали, т.к. у тех же зомби в кате нет кучи параметров, что есть у персонажа, которые им вообще не нужны или делают симуляцию избыточной, что отжирает ресурсы, которые перенаправляют на что-то более полезное.
Да, это красивая история про то, что можно давать управление персонажа компу, но почти всегда это не оправдано больше ничем, кроме просто затем, чтобы было.
Про то, что ты описал - выше уже сказали, что лучше сделать через ecs. У тебя будет компонент отображения: меш, анимации, частицы.. компонент контроллер: игрок/ии.. все это компоненты какой-то сущности будут, например, персонаж.
Аноним 10/09/19 Втр 22:45:59 #277 №609435 
>>609421
Еще раз, возвращайся в свой юнити-загон. Я понимаю, ты скачал юнити, научился таскать ассеты по сценке, и тебе теперь до сверби в очке хочется спиздануть своё экспертное мнение, но иногда лучше промолчать, чтобы не позориться.
>Оружие и шлем очевидно пронаследуются от единицы снаряжения.
Ты даже не понял смысл компонентов ecs, что впрочем неудивительно для умственно-отсталого пользователя юнити.
Ладно, еще раз объясню, может дойдет со второго раза. Есть компонент оружия, есть компонент шлема. Логика оружия и атак в компоненте оружия, кол-во брони и логика защиты в компоненте шлема. Если ты делаешь обычное оружие, ты используешь один компонент оружия. Обычный шлем - компонент шлема. А если захотел, то комбинируешь два компонента в одной сущности, получаешь рогатый шлем, который дает защиту, и позволяет атаковать рогами.
В рамках ООП тебе уже придется делать наследование от двух классов с общим родительским классом, что приводит к diamond problem. Да и во многих языках множественное наследование запрещено, т.к. приводит к куче проблем. Разве что в С++ можно полноценно юзать множественное наследование, но поскольку ты умственно отсталый, то вряд ли умеешь писать на плюсах.
А если тебе отрубили рога, ты просто на лету дропаешь компонент и получаешь опять обычный шлем без атаки. В нормальном ecs все компоненты хранятся в раздельных хранилищах, поэтому компоненты легко отсоединяются/отключаются, память при этом освобождается.
В ООП так не получится сделать, если юзаешь наследование/агрегацию, в рантайме на лету ты не разделишь компоненты сущности.
Аноним 10/09/19 Втр 23:15:11 #278 №609442 
>>609435
Дегенерат, ты высрал много хуйни и даже не понял мой простейший пост - в ecs у тебя ровно та же самая diamond problem, ты от нее никогда не уйдешь, просто сдвигаешь немного в другую плоскость, да даже на твоем же примере, хуй разберешься как рассчитывать атаку, поскольку она идет и от оружия и от рогов шлема, значит у тебя уже ограничение, что можно атаковать только одним из них, то есть ничем не лучше как если бы в ооп ты наследовался не множественным наследованием а ограничивал все одним предком.
Аноним 10/09/19 Втр 23:44:14 #279 №609448 
>>609442
Вот это обида умственно отсталого. Ничего, всё нормально, не обижайся, ты хороший мальчик. Иди запусти юнити, скачай ассет из стора, перетащи на сцену. Молодец, ты у нас умница, почти как настоящий взрослый разрабочик игр.
> в ecs у тебя ровно та же самая diamond problem
Нет, её нет.
>хуй разберешься как рассчитывать атаку
Элементарно разберёшься.
> значит у тебя уже ограничение, что можно атаковать только одним из них
Зависит от механик игры. Можно атаковать одним, сортировать компоненты по атрибуту приоритета/урону.
Можно проводить двойную атаку, в духе нескольких бросков кубика в d&d играх.
Можно давать игроку список действий на выбор,пробегаться по всем подключенным компонентам и строить набор доступных действий - стукнуть мечом, боднуть, пнуть, бросить этот сраный шлем во врага - этот функционал легко включить, просто подключив компонент "Бросаемый" к шлему. Ты можешь подключить этот же компонент к тому же мечу одной строчкой в конфиге сущностей, и для его броска будет задействован тот же код. Он будет так же бросаться, действие для броска так же автоматически будет доступно, без строчки дополнительного кода.
Удачи в ООП пробегаться по всем предкам сущности, чтобы понять, какие действия с ней можно делать.
Аноним 11/09/19 Срд 00:04:24 #280 №609457 
>>609448
Лол, вот это боль юнитимакаки, которая умеет только возякать ассеты, и ничего не понимает в ООП.
>Можно давать игроку список действий на выбор,пробегаться по всем подключенным компонентам и строить набор доступных действий - стукнуть мечом, боднуть, пнуть, бросить этот сраный шлем во врага
Ты даже не понимаешь, шизоид, что ты просто ручками прописываешь все то, что у тебя будет само работать с наследованием. Просто смирись, программирование и геймдев - это не для всех, иди раскладывать товары в пятерочке.
sageАноним 11/09/19 Срд 00:06:16 #281 №609459 
>>609448
>запусти юнити, скачай ассет из стора, перетащи на сцену. Молодец, ты у нас умница, почти как настоящий взрослый разрабочик игр.
хуесос, ассет от моделлера чемменяет этот процесс? прекроди срать себе в рот
Аноним 11/09/19 Срд 00:27:26 #282 №609465 
e17d56ee5fdebb9f3cd1e5e5f4b0fc84.jpg
>>609459
>хуесос, ассет от моделлера чемменяет этот процесс?
Аноним 11/09/19 Срд 18:34:48 #283 №609702 
>>609435
> если юзаешь наследование/агрегацию, в рантайме на лету ты не разделишь компоненты сущности
using Unity;

public class Component {}

public class Entity {
public List<Component> components
}

Дальше разъёбывать тебя, энтитух? Или ты уже понял, где обосрался?
Аноним 11/09/19 Срд 18:42:00 #284 №609709 
1568216498127.png
>>609429
> почти всегда это не оправдано больше ничем, кроме просто затем, чтобы было
Это даёт мододелам возможность пилить моды со своими сюжетами любого уровня сложности. Например, в основной игре, ты даже не думал о том, персонажем игрока может управлять ИИ, но всё же вложил эту возможность. И вот один моддер сделал мод, где все персонажи управляются игроком в стиле изометрических РПГ. А другой моддер запилил мод с квестом, в рамках которого некий монстр может удалённо контролировать персонажа игрока и игроку предстоит с этим разобраться. А третий моддер запилил мод на оборотня, где ГГ по ночам теряет разум и бежит охотиться, а игрок в ужасе наблюдает, не в силах ничего поделать. А пятый моддер запилил еблемод, где ГГ ебут.
Аноним 11/09/19 Срд 20:07:29 #285 №609745 
>>609709
>моды
Ненужно.
Аноним 11/09/19 Срд 20:12:15 #286 №609749 
>>609745
Нам очень важно ваше мнение. Пожалуйста, оставайтесь на линии, ближайший освободившийся оператор службы выслушивания охуительно важных мнений школоты и хомячья, обязательно ответит вам!
Аноним 11/09/19 Срд 20:17:54 #287 №609751 
>>609749
Моды это и есть для школоты. Нормальные люди играют в готовый контент.
Аноним 11/09/19 Срд 20:19:33 #288 №609755 
>>609709
>один моддер сделал мод, где все персонажи управляются игроком в стиле изометрических РПГ
Ты мог бы продать две игры, а в результате продал одну, а эту идею подарил какому то моддеру. Потом он выпускает игру ТОДА 2, которая становится популярной, а твой проект сосет бибу.
Аноним 11/09/19 Срд 20:19:45 #289 №609756 
>>609751
Нам очень важно ваше мнение. Пожалуйста, оставайтесь на линии, ближайший освободившийся оператор службы выслушивания охуительно важных мнений школоты и хомячья, обязательно ответит вам!
Аноним 11/09/19 Срд 20:20:42 #290 №609757 
>>609755
Кто не рискует, тот не нюхает кокс с жоп шлюх.
Аноним 11/09/19 Срд 20:21:00 #291 №609758 
>>609756
Я понял, понял. У вас там в школе все заняты хомячками.
Аноним 11/09/19 Срд 21:25:46 #292 №609849 
15583899661130.png
>>609702
>using Unity
Нахуя там юнити? Там же юзаются один List из стандартной либы. Или ты без юнити пукнуть уже не можешь?
>Дальше разъёбывать тебя, энтитух?
Ну давай, разберем по частям тобою написанное.
Твоя реализация по перфомансу против полноценного ECS - это как бабка на костылях против спорткара.
В ECS компоненты хранятся в cache-friendly структурах, плотными массивами, при обработке системой они выгружаются на линии кэша процессора пачками и молниеносно обрабатываются.
У тебя же список, который хранит указатели на объекты в рандомных местах кучи, т.е. вся куча засрана дерьмом, по которому приходится скакать при обработке, кэш при этом вымывается мусором при каждой итерации.
Дальше, ты как ты представляешь себе код обработки высранной тобой структуры? Как системы узнают, что у сущности X в листе компонентов находятся компоненты типа, обрабатываемого данной системой? Я так полагаю, ты собрался для каждой сущности пробегаться по всем компонентам и делать тайп чек? Ты представляешь какой это оверхед по сравнению с настоящей реализацией ECS, где все компоненты одного типа лежат в отдельном массиве, и каждая система заранее знает, где взять эти компоненты без оверхеда?
Так что обосрался прямо себе на лицо пока что только ты.
Впрочем, от умственно отсталого потребителя юнити ничего другого и не ожидалось.
Аноним 12/09/19 Чтв 07:25:04 #293 №609928 
>>609709
Так то, что я описал никак не мешает мододелу добавить/убрать нужные компоненты персонажу/мобу и передать управление игроку/ИИ/аллаху.
>>609745
>> Ненужно.
Нужно, очень важная составляющая качественной игры.
Аноним 12/09/19 Чтв 09:47:23 #294 №609943 
>>609928
>моды
>качественной игры
Выбери что-нибудь одно.
Аноним 12/09/19 Чтв 10:23:08 #295 №609951 
>>609943
Я выбираю скайрим. Игру года. Игру десятилетия. Хуй ты оспоришь.
Аноним 12/09/19 Чтв 10:31:25 #296 №609955 
>>609951
Скайрим без модов некачественный, ты обосрался.
Аноним 12/09/19 Чтв 11:07:46 #297 №609978 
>>609849
>15583899661130.png
Ты понимаешь, что ты поехавший?
Аноним 12/09/19 Чтв 15:48:38 #298 №610063 
>>609955
У меня сейчас будет аргумент уровня "миллионы мух не могут ошибаться", но скайрим блядь, так много раз продавался, что об этом в интернетах легенды (и мемасы) ходят. И бойчее всего он продаётся на платформах, где моддинг затруднён.
Аноним 13/09/19 Птн 03:21:11 #299 №610198 
>>609943
Во вселенной своих фантазий ты волен выбирать, что угодно.
Аноним 18/09/19 Срд 22:01:37 #300 №611572 
>>558393
Он там в стиме на альфаре уже выкатился, игрокам нравится и выглядит очень необычно.
sageАноним 01/10/19 Втр 10:22:24 #301 №614729 
как заебало это натужное прохрюкивание оскотинившихся пидоpax >>609755 >>609749 >>609928
Аноним 01/10/19 Втр 11:26:59 #302 №614757 
>>614729
Пацаны, смотрите, бота как далеко занесло.
Аноним 08/10/19 Втр 10:38:04 #303 №616191 
image.png
Небольшие попытки осмыслить архитектуру ECS, как метод выражения Сущностей игрового мира
Аноним 08/10/19 Втр 13:26:04 #304 №616228 
>>616191
я не понимаю в чем вы все страдаете этим ECS? это же абстракция ради абстракций, когда простые вещи делаются через стопятсот абстрактностей ради какой-то мифической расширяемости которой на самом деле никогда не будет (не будет у тебя никогда стопятсот компонент)

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

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

впрочем у тебя на скрине не ECS.
Аноним 08/10/19 Втр 13:41:31 #305 №616233 
>>616228
Дед, не ори.
Просто ты уже старенький стал, мозги закостенели, за старое держижшься, ух.

И что ж ты предложишь? ООП?
Аноним 08/10/19 Втр 15:36:34 #306 №616249 
>>616228
+ где тут написано что это ECS?
Аноним 08/10/19 Втр 19:38:18 #307 №616298 
>>616228
пиздец ты школьник, не нюхавший программирования) Ну когда будете проходить про расположение структур в памяти, тогда пояснят принципиальную разницу oop/ecs для высоконагруженных приложений.
Понятно, что для твоих задачек школьных и хеллоуворлдов по урокам с ютьюбчика пойдет любое и разницы ты не увидишь.
Аноним 09/10/19 Срд 02:35:30 #308 №616357 
image.png
>>616233
что еще можно предложить?
Аноним 09/10/19 Срд 02:52:55 #309 №616358 
>>616298
>для твоих задачек школьных и хеллоуворлдов по урокам с ютьюбчика пойдет любое и разницы ты не увидишь
Так он то же самое и написал, только про тебя.
Аноним 09/10/19 Срд 02:56:48 #310 №616359 
>>616298
сразу видно школьника, ты бы хоть сам-то узнал что такое ECS
Но я добрый, лови статейку где все разжевано
https://github.com/SanderMertens/ecs-faq

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

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

Как минимум придется написать и свой аллокатор памяти чтобы гарантировать что твои компоненты реально лежат друг за другом, а не по всей памяти.
Да и вообще побайтоебить... Ведь вот какой прикол, гарантированное расположение в памяти тебе дается только для POD структур, только вот там запрещен полиморфизм (виртуальное наследование)
https://ru.wikipedia.org/wiki/Простая_структура_данных

Аноним 09/10/19 Срд 04:29:20 #311 №616361 
>>616359
Естественно у ECS свои проблемы, тут спору нет. Но мне кажется это не так страшно, по сравнению в вечным рефакторингом ООП, когда ты только собираешься въебать новый функционал.
Аноним 09/10/19 Срд 04:36:51 #312 №616362 
>>616359
Так шо я думаю, блядь, ну блять, ECS метод, он относительно молодой, и хули, понятное дело что он будет вызывать новвые проблемы. Но бяддь, мне вот лично не западло изучить еще небольшую тонну материала, и разобраться по хорошему с аллокацией памяти, побайтоёбить, и создать просто хороший, добротный движок для рогулька, на основе ECS. Дык в итоге это же будет монолитный фундамент, на который ты сможешь СТОЛЬКО вещей надеть, добавить, постоянно модифицировать, что оно всё окупит.

Аноним 09/10/19 Срд 12:05:55 #313 №616410 
>>616359
>Ведь вот какой прикол, гарантированное расположение в памяти тебе дается только для POD структур, только вот там запрещен полиморфизм (виртуальное наследование)
Вот сижу и думаю, от чего бы мне отнаследовать количество здоровья персонажа, или его координаты. Ведь компоненты в ecs ну никак нельзя делать без виртуального наследования. Нельзя же просто сделать using Health = float, надо обязательно сделать class Health : public AbstractHealth, а AbstractHealth - наследовать от AbstractComponent, а AbstractComponent от AbstractProxyFactorySingletonComponentFactoryBean, иначе не трушное ООП получится.
Аноним 09/10/19 Срд 12:14:33 #314 №616411 
>>616410
Компоненты не надо наследовать. И вообще это должны быть не классы, а структуры. И называться типа HasHealth. И на каждой итерации твоя HealthSystem проверяет все компоненты HasHealth, и если значение достигло нуля, то удаляет эту сущность, например
Аноним 09/10/19 Срд 12:15:10 #315 №616412 
>>616411
А, это ирония была, ну ладно
Аноним 09/10/19 Срд 14:49:37 #316 №616451 
>>616411
А почему нельзя не итерациями производить события, а условно создать поток, или пул, в который каждый компонент, если он должен измениться будет вкидывать себя на очередь, допустим? Какие подводные?
Аноним 09/10/19 Срд 16:35:54 #317 №616459 
>>616451
Ты вообще можешь сделать как хочешь. ECS это просто реализация поведения объектов, которое описывается набором характеристик. Например, объект реализует поведение оружия, если у него есть характеристики предмет и стреляющий.
Системы - это конкретный процедурный способ реализации поведения объекта. Можно сделать как в юнити, и поведения добавить внутрь самих компонентов.
Аноним 09/10/19 Срд 18:21:30 #318 №616478 
>>616459
Ну как бы да, могу как хочу, это был скорее вопрос к самой ценности вышевысказанной идеи.
Аноним 10/10/19 Чтв 07:02:09 #319 №616629 
>>616359
а что у вас в школе маллоки не проходят уже, что написать аллокатор памяти для своих структур в игре - это проблема?
а, нынче только сисярпить могут
Аноним 10/10/19 Чтв 07:04:50 #320 №616630 
>>616459
Если как раньше в юнитях, то это EC архитектура у них была, на ECS они только переходят.
Аноним 10/10/19 Чтв 07:07:01 #321 №616631 
>>616451
Потому что компонент ничего не знает о том, что он должен как-то изменится. Это просто набор данных.
Аноним 10/10/19 Чтв 07:11:39 #322 №616632 
>>616631
Обосрался, не компонент а система.
Аноним 10/10/19 Чтв 07:34:49 #323 №616635 
>>616632
Система как раз и знает как изменяются компоненты и содержит логику их изменений. Удачи в школе сегодня.
Аноним 10/10/19 Чтв 07:37:13 #324 №616636 
Возрадуйтесь, ибо грядет)
https://suvitruf.ru/2019/07/20/6387/csharp-android-support-godot-3-2/
Аноним 10/10/19 Чтв 08:06:07 #325 №616641 
>>616635
Да это то понятно, умник ёпта. Я просто думал над оптимизацией самого процесса вызова этих функций. Как в пример можно взять события через Update на юнити. Которые засирают нахуй пул ненужным мусором. Но при этом нам надо как-то отображать изменеия тех или иных объектов во времени. Вот я и думаю, насчёт идеи создания пула, в который будут все изменения вкидываться уже самими функциями, когда они хотят изменить что-то и выполняться уже в порядке очереди.
Аноним 10/10/19 Чтв 08:53:03 #326 №616653 
>>616641
Ну это юнити, страдай.
Аноним 10/10/19 Чтв 08:55:42 #327 №616655 
>>616653
Ты чего злой такой, пиздец? Я вообще просто как пример неэффектисвной реализации привёл, я юнитями не пользуюсь. А ты блять вот так нахуй. Как так нахуй?
Аноним 10/10/19 Чтв 09:06:31 #328 №616658 
>>616629
щас бы аллокатор на маллоках писать, лол.

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

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

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

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

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

Просто стоит понять что ECS из коробки оптимизации не даст, если не разбираешься в работе с памятью

Аноним 10/10/19 Чтв 09:23:13 #331 №616661 
>>616660
Я от ECS панацеи не ждал, ясен хуебасен что без прямых рук, свежей головы и какой нибудь хуйни еще можно и ECS засрать. Мне этот паттерн понравился больше из за гибкости в перепиливании, и добавлении новых вещей. А то что можно хорошо так, по доброму еще и с памятью поработать, оптимизировать движок, то это вообще роскошь.

А за литературу да... НА ум только совершенный код приходит, и еще книжечка одна про компиляторы. Не знаю насколько это в сама деле полезно.
Аноним 10/10/19 Чтв 09:31:22 #332 №616662 
>>616661
вообще всегда можно глянуть как сделано у серьезных дядек.

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

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

(но ссылку на код юньки не помню, надо в китайских помойках копаться что-то на source leak unity 4 yoyoyo)
Аноним 10/10/19 Чтв 09:38:10 #333 №616663 
>>616662
Уох бля, слили? Вот так внезапно. Ну ладно, буду посмотреть. А вообще, вернёмся к теме рогуляков. Есть ли смысл тут задрачиваться так с памятью и оптимизацией, и если есть, какие бенефиты это может привнести? Вот допустим если есть идея создать игровой мир так Это выглядит как убераутизм, но это и есть смысл RLSim'ов название придумал вчера, чтобы внутри каждого существа, каждый обьект-орган был включён, и здоровье было не просто как счётчик, а фактическое состояие существ. НУ вот в пример возьмём Dwarf Fortress. Я уже думал над тем, как можно сохранять тонны предметов в одном "существе", каким образом можно говорить системам что "вот это у нас для дыхания, а вот это кровеносная система, но немного не в порядке, потому что давление падает из за повреждения сосудов левой пятки правой ноги".
Я уже накириллил в Evernote пару десятков листов подобного сырого описания механик и алгоримтов. Если надо, могу высрать.
Аноним 10/10/19 Чтв 09:53:08 #334 №616664 
>>616663
Если у тебя в игре будет 10 дварфов с органами, то можшь не заморачиваться. Если предполагается обсчет 1000 существ и физика мира будет достаточно сложной, то - да, стоит.
Аноним 10/10/19 Чтв 09:56:35 #335 №616666 
>>616663
по теме сложно сказать. в 90% индюшатины (и тем более рогаликов) - не нужно.
С другой стороны если делать Dwarf Fortress - то там очень даже нужно - DF тормозит еще так - много расчетов (а может просто разрабу лень что-то оптимизировать)


>>616663
Во, оказывается слив юнити и на дваче обсуждали (из архива - успей пока не удалили https://m2ch.hk/pr/res/1252860.html)


Аноним 10/10/19 Чтв 09:59:50 #336 №616667 
>>616664
Ну физика не сказать чтобы прямо сложная будет, хотя предполагается что в баббле могут начать пиздиться и активно производить тактические манёвры 300-500 ёбел. При этом стоит не забывать что мир трёхмерный. При этом также будут иметься движущиеся механизмы (машины, или огромные крепости). Вот с последним я думал думал, там пиздец нахуй морока будет. Ибо пересчитывать перемещение каждой клеточки, это можно ебануться к хуям. Думал можно поизъёбываться, и сделать так, что в мире у движущегося механизма будет единый центральный блок, который только будет двигаться, и все внутренние вычисления перемещения будут происходить уже относительно него. Тобишь двигать каждый блок уже не потребуется, хотя думаю тут если дойдет до оптимизиации, вылезит такое дикое количество нюансов, что жопу придётся рвать крайне интенсивно.

>>616666
Там даже потоковость не поодерживается. Да и что-то мне подсказывает, что автор проебал уже давно всю последвательность архитектурную, и просто городушки делает, не знаю. Но да, оптимизон нужон.
Аноним 10/10/19 Чтв 10:01:48 #337 №616668 
>>616666
>https://m2ch.hk/pr/res/1252860.html

Я спиздил. Красиво. Буду копать.
Аноним 10/10/19 Чтв 10:09:27 #338 №616671 
>>616667
Ну если вводишь многоклеточные структуры и такие эпичные битвы - тогда лучше с начала разработки учесть методы оптимизации при проектировании.
>> Думал можно поизъёбываться, и сделать так, что в мире у движущегося механизма будет единый центральный блок, который только будет двигаться, и все внутренние вычисления перемещения будут происходить уже относительно него.
Так коллизию всей этой структуры все равно придется точно также обсчитывать в трехмерном мире: т.е. все граничные клетки твоей структуры в направлении вектора движения.
Аноним 10/10/19 Чтв 10:57:44 #339 №616682 
>>616671
Естественно, никто не спорит.

А про оптимизацию да, я собственно, по этой причине-то и интерисуюсь
Аноним 10/10/19 Чтв 11:19:31 #340 №616689 
>>616682
так он увидит, что не хватает парного символа табуляции
Аноним 10/10/19 Чтв 11:20:28 #341 №616690 
>>616689
а?
Аноним 10/10/19 Чтв 11:31:09 #342 №616692 
>>616690
ну если конкретно для цикла

Правильный вариант:
for
отступ body
Пропускаем отступ:
for
body
- получаем ошибку, что не хватает знака табуляции после объявления цикла
Аноним 10/10/19 Чтв 11:32:12 #343 №616693 
>>616692
Ебать опять боты пизданулись, че за хуйня
Аноним 10/10/19 Чтв 11:45:17 #344 №616697 
>>616690
промахнулся, не тебе
Аноним 21/10/19 Пнд 09:33:46 #345 №618792 
ТЭкс, пока ОП умер нахуй, я решил сам начать пилить Движок, и сам рогалик. Пока в быстром порядке отзубриваю кресты С++, ООП, ЕЦС, SDL и прочее ебланство, попутно нанизывая на собранный ручками из говна и палок недодвижок. Сразу вопрос про либку SDL. Это вообще законно/канонично, если я начну хуячить весь рендер (Сейчас я по немного разделяю рендер архитектурно через интерфейс) через SDL_Renderer, или мне лучше попробовать подрочиться с windows.h, и пилить вывод прямо в терминал? Я хочу как минимум его на Win32/Linux въебать, но совершенно не знаю особенности кроссплатформенности под линукс.
Аноним 21/10/19 Пнд 11:18:03 #346 №618797 
>>618792
>Я хочу как минимум его на Win32/Linux въебать
Раз так, то тебе стоит сфокусироваться на SDL. Для неё вроде даже есть драйвер, выводящий картинку в ascii-art.
Аноним 21/10/19 Пнд 11:32:08 #347 №618800 
>>618797
Ну это не будет само собой непосредственно терминальное окно. Там получается что вот пока у меня выводится графическиий рендер, на котором уже ttf текст рендерится. Вроде как бы и норм, но по мне так исполнение - дикая хуйня. И поясни за драйваер, он прямо непосредственно буфер терминала перехватывает, или просто какая-то свистоперделка для рендерера?
Аноним 21/10/19 Пнд 11:35:14 #348 №618801 
>>618797
Хотя если так подумать, хуй еще пойми, реально ли надо именно таким "стандартным" для рогулей образом выводить игру. хуй еще знает кароче.
Аноним 21/10/19 Пнд 12:12:27 #349 №618810 
>>618800
https://discourse.libsdl.org/t/ascii-art-driver-for-sdl/1898
Аноним 21/10/19 Пнд 12:19:57 #350 №618811 
>>618810
Ебать, разве это не просто обработчик медиа под стиль ASCII?
Аноним 24/10/19 Чтв 16:15:22 #351 №619409 
>>618792
Попробуй ascii графику в consolegameengine on OneLoneCoder
Аноним 24/10/19 Чтв 16:18:50 #352 №619411 
>>619409
Я пока решил начать пилить рогуль с BearLibTerminal, в ней очень много всяких плюшечек есть, и она вполне себе хорошо подходит для моих задач. НА первое время, скажем так, можно взять её. Вкручу её в код через интерфейсы, потом может когда-нибудь, если понадобится, напишу собственный рендерер, а пока буду занят чисто логикой игры и структурой кода
Аноним 22/01/20 Срд 13:55:39 #353 №637624 
>>558349 (OP)
Есть у кого-нибудь опыт с T-Engine 4? Это на котором ToME4 написан. Там луа, и разобраться вроде несложно, но я так и не понял, насколько движок свободный. Смогу я игру, сделанную на нём, продавать в стиме? Алсо, не могу понять, можно ли сделать полностью отдельную игру, а не .team-мод для ToME, хотя на 4drl вроде делали.
Аноним 22/01/20 Срд 13:57:18 #354 №637625 
>>637624
>4drl
7drl
Аноним 23/01/20 Чтв 07:15:19 #355 №638107 
>>637624
https://www.gnu.org/licenses/quick-guide-gplv3.html
16pixel 10/03/20 Втр 00:16:46 #356 №647714 
game.png
yebani code.png
okcode.png
Вкатываюсь в тред, пилю рогуалик на питоне, вывод графики через pygame, остальное сам пишу ибо интересно.
И раз тут нашелся такой уютный тредос, поделюсь наболевшим.

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

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

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

Аноним 10/03/20 Втр 09:08:58 #357 №647749 
>>647714
Ты не показал содержимое find_4_tiles_around() подозреваю, что там 6-8 строк, но тем не менее, тут можно доебаться.
Аноним 10/03/20 Втр 15:00:23 #358 №647868 
>>647714
> Короче нахуй cellular automata, посоны. Юзайте drunkard walk и будет вам счастье.
Спасибо за инсайт, сделал пометочку в своём эверноте.

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

Удачи
У тебя на скрине ГГ лысый лол
Аноним 11/03/20 Срд 04:58:12 #359 №648012 
>>647868
А питонисты разве до сих пор нужны? Как вообще там? Я сам изучаю раст, но чую что он пока мало кому нужен, хотя язык лучше даже крестов в каком-то смысле
Аноним 11/03/20 Срд 04:58:58 #360 №648013 
>>648012
>>647868

На нём же кстати и буду пилить свой рогалик.
Аноним 11/03/20 Срд 05:42:35 #361 №648014 
>>648012
Учил бы го - нужен был бы всем и задорого.
Аноним 11/03/20 Срд 09:08:53 #362 №648025 
>>648012
> А питонисты разве до сих пор нужны?
Более чем все прочие. У меня между разными галерами пауз в работе больше месяца не было.

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

> раст, но чую что он пока мало кому нужен
Правильно чуешь.
Аноним 11/03/20 Срд 10:17:22 #363 №648037 
Кириллишь десятилетиями рогалик мечты.
@
Авторы холлов найт нюхают кокс с жоп шлюх.
@
Авторы ори купили по второй ферари.
@
Жидко пукнув помираешь от старости.
Аноним 11/03/20 Срд 10:19:54 #364 №648038 
>>648037
Бля. Рогалики с метроивданиями перепутал. Удолити пост. Стыдно.
Аноним 11/03/20 Срд 13:09:36 #365 №648076 
hqdefault.jpg
>>648038
Аноним 11/03/20 Срд 14:26:26 #366 №648095 
>>648014
А я его и начинал учить кстати, пока не понял что ебись оно всё в жопу эти ебучие GC.
Ну значит потом буду снова его учить.

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

>Правильно чуешь.
Но он мне люто нравится, поэту я буду продолжать его учить.
Аноним 11/03/20 Срд 15:18:25 #367 №648106 
>>648076
Не прав. Метроидвания - пик развития платформера.
Аноним 11/03/20 Срд 19:39:34 #368 №648218 
>>648095
> Конкретно о том какие задачи на нём чаще всего приходится решать
Я на нём по работе лабаю вебсервисы на джанге. Ещё есть слухи, что в нашу контору хайрили датасатаниста, тоже на питонах, удои повышать.

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

> Но он мне люто нравится, поэту я буду продолжать его учить.
Бесценное время твоей жизни принадлежит только тебе, решать, на что его тратить, тоже только тебе.
Аноним 11/03/20 Срд 19:41:10 #369 №648219 
>>648106
Органически не переношу игры, для игры в которые нужен только раздроченный спинной мозг, так что ну его нахуй я всё в INT вкачал, AGI у меня околонулевое
Аноним 12/03/20 Чтв 10:13:04 #370 №648374 
>>648106
А рогалик - пик развития топдаун эрпогэ?
16pixel 14/03/20 Суб 12:46:52 #371 №648959 
los.png
fov.png
Продолжаем попил приключений лысого ананаса в подземельях с монстрами.

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

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

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

Вообще, писать о процессе довольно сильно включает критическое мышление на тему "чего я хочу от того, что делаю". Так что всем рекомендую. Может девблог завести какой-нить
Аноним 14/03/20 Суб 16:19:38 #372 №648986 
>>648959
>если он не попадает в los
что это?
На чём пишешь?
Можешь пример кода привести.
16pixel 15/03/20 Вск 01:57:37 #373 №649102 
>>648986
Тред не читай @ сразу отвечай

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

Кто-нибудь может адекватно за ECS пояснить? Не вкуриваю концепт вообще.
Аноним 15/03/20 Вск 06:26:29 #374 №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 и готовлюсь по чуть чуть свой рогуль с анатомией и аутизмом делать. Но нужно время.







Аноним 15/03/20 Вск 06:44:59 #375 №649124 
>>649122
https://habr.com/ru/post/343778/
Добавлю вот эту статью. У этого паренька лютая ECS. Хотя для моих запросов не подходит.
Аноним 15/03/20 Вск 09:24:16 #376 №649132 
>>649122
Падажжи, а кто системе движения подготовил эти массивы векторов?
Аноним 15/03/20 Вск 10:19:03 #377 №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/
Аноним 15/03/20 Вск 13:40:25 #378 №649163 
>>649132
>>649142

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

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

>>649142
Годные ссылки. Что есть такое Префабы, это же действительно только в юнити ЕЦС реализации встречается? или я только что гранату?
Аноним 15/03/20 Вск 13:54:49 #379 №649165 
photo2018-12-0601-13-20.jpg
>>649142
Я вообще думал чтобы внутри игры у меня был огромный такой блядь сисЭм, который как планировщик принимал разные таски, или составлял расписание обхода по флагам, которые стоят у предметов. Не знаю точно, пока очень усердно думаю над тем как это можно разрулить это дело, чтобы изначально всё сука такое гибкое было пиздец. Есть уже много абстрактных описаний того как это будет работать, но пока не подвёл все эти вещи под общий знаменатель.
Аноним 15/03/20 Вск 15:04:04 #380 №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/
Аноним 15/03/20 Вск 15:13:31 #381 №649178 
>>649175
А, то есть паттерны такие? Ну вот допустим я когда задумывался над этой темой пришёл в выводу о том что следует создавать отдельную систему и тип компонентов отвественных за подгрузку моделек в игру, а там уже для каждой ентити просто опять же давать id этой модельки, или текстурки. Но не знал что такой метод называется префабом.

Кстати почему ты так красноречиво отозвался о юнити? я слышал краем уха про его Job System и Burst, разве это дело не исправило? (Сам потом подумывал после рогуля попробовать юнити как движок для песочницы)
Аноним 15/03/20 Вск 15:19:26 #382 №649182 
>>649175
да, я думал про то как такие префабы организовывать в условии когда у меня каждое существо будет состоять из органов тканей и прочего, как это ToadOne делает, только более интересным образом я это провернул. Там у меня получаются лютые деревья, и я пока вообще совершенно не имею понятия как организовывать gameObject-creature. Я могу высраться о том что я там накириллил в еверноуте, раз Оп давно обосрался насмерть.
Аноним 15/03/20 Вск 15:30:10 #383 №649183 
>>649182
Братюнь, каждый день, когда ты думаешь над своей мега-системой, ты над ней не работаешь. Это у тебя такая форма прокрастинации. Начни делать хоть как-то, хоть по чуть-чуть, сделай первую хуёвую верию, зато сделав её, поймёшь, как надо делать лучше и начнёшь делать лучше. Я сам такой.

> Кстати почему ты так красноречиво отозвался о юнити?
Потому что хуюнити вообще и сирешётка в частности - это распиаренное говно для нубов, которые существуют только из-за нечеловеческих вливаний бабла в их маркетинг мокросовтом. Человек, профессионально занимающийся программированием или геймдевом, это говно будет десятой дорогой обходить.
Если перейти на язык метафор, это как если бы качок вместо того, чтобы готовить себе условную куру с гречей и прочий спортпит, жрал бы в макдаке.
16pixel 15/03/20 Вск 15:37:20 #384 №649187 
gaem.gif
Ого как тред подорвало.
Ну, во-первых, братюни, спасибо за обстоятельные ответы.
Прежде чем сформулировать следующий вопрос, отправляюсь изучать данные ссылки и матчасть.

Гифка текущего прогресса, ака "костыли и велосипеды", для поддержания интереса к треду.
Аноним 15/03/20 Вск 15:46:34 #385 №649191 
>>649183
Да, я слышал что решётка это хуйпизда по перфомансу, поэтому сразу перепрыннул на Rust-lang.

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

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

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

>>649187
Тут нас по идее 3 аутиста всего навскидку. Я тред уже год мониторю, ОП точно сдох.
Аноним 15/03/20 Вск 15:52:52 #386 №649193 
мне до сих пор не ясно нахера в "игровом движке" наружу торчит только шарп(который потом все равно в крешты перекатывается)
зачем эта прокладка? типа легче что ли?
Аноним 15/03/20 Вск 15:56:24 #387 №649194 
>>649191
Ну и ладно, качество > количества. И я не ожидал, честно говоря, что задав вопрос получу ответ, это же двач. А оно вон как.

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

(алсо, разглядывая гифку, нашел багу в расчете line of sight. Так что постить в тред еще и полезно!)
Аноним 15/03/20 Вск 16:00:26 #388 №649196 
>>649194
определённо это дело надо оживлять.

>>649193
Я вообще ни шарп ни уните не знаю, но предположу что шарп легче + есть возможности использовать заместо стандартного GC шарпа какие- то хитрые GC в Burst заточенные именно под игорьки
Аноним 15/03/20 Вск 17:04:50 #389 №649211 
My+eyes+bleed+from+reading+so+much+in+one+sitting+c2b1cc660[...].png
>>649187
> Comic sans
Аноним 15/03/20 Вск 17:08:31 #390 №649212 
>>649191
> Да, я слышал что решётка это хуйпизда по перфомансу, поэтому сразу перепрыннул на Rust-lang.
Тоже зашквар, конечно, но не такой страшный, как мокросовт - ржавчину проталкивает мозилла, они, несмотря на засилье сжв-пидоров, вроде как за свободный интернет и всё такое.
Аноним 15/03/20 Вск 17:34:09 #391 №649215 
>>649212
Почему Rust зашквар? Он довольно быстрый, очень безопасный, что для многопоточных приложений вообще самая мякотка. Чтобы писать такого же качества код без сегфолтов на С++ надо отхуярить на нём десяток лет.
Аноним 16/03/20 Пнд 09:23:53 #392 №649368 
>>649215
> Он довольно быстрый, очень безопасный, что для многопоточных приложений вообще самая мякотка. Чтобы писать такого же качества код без сегфолтов на С++ надо отхуярить на нём десяток лет.
Если закрыть глаза на сырость языка, с этим твоим аргументом я полностью согласен. Повторю свой аргумент ещё раз: rust проталкивает mozilla. Я не верю в языки, в маркетинг которых вкладываются многомиллионные транснациональные корпорации. Если язык так хорош, зачем ему маркетинг? Спецы увидят, что он хорош и будут его использовать из-за того, что он хорош, а не из-за того, что из каждого утюга им говорят, что он хорош.
Аноним 16/03/20 Пнд 09:36:22 #393 №649376 
>>649368
>rust проталкивает mozilla
Зачем?
Аноним 16/03/20 Пнд 10:20:31 #394 №649388 
>>649376
Я думаю, чтобы вставлять палки в колёса гуглу с его Goвном. Зачем, по-твоему, были созданы Java, C#, Go, Rust? Чтобы оттяпать долю айтишного рынка.
Аноним 16/03/20 Пнд 12:10:10 #395 №649411 
>>649368
Ну во первых это уже выходит за рамки самого языка, а входит в рамки психологии, что там кто увидит и почему кому-то внезапно надо переходить на Rust.

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

>>649388
Вот опять же, нас эта пизделовка вообще не касается, потому что если человек достаточно ясно видит всю хуйню, он сам увидит пытается ли маркетинг сраку жёваную впарить или же что-то стоящее. Реальность over Видение.
Аноним 16/03/20 Пнд 12:48:11 #396 №649419 
>>649368
>Если закрыть глаза на сырость языка
Первая стабильная версия вышла 5 лет назад, проснись.
Язык уже стабильнее некуда, никакой "сырости" там нет, его уже спокойно юзают в продакшене овердохуя компаний.
>Я не верю в языки, в маркетинг которых вкладываются многомиллионные транснациональные корпорации
Шизик, тогда тебе нельзя программировать на c# - его многомиллионный майкрософт создал и продвигал. На джаве тоже нельзя - её многомиллионный оракл продвигал.
На С++ тоже нельзя, его развитием и продвижением занимались десятки многомиллионных компаний, в том числе и майкрософт.
С твоими критериями тебе остается два языка на выбор - бейсик и фри паскаль, выбирай.
>Если язык так хорош, зачем ему маркетинг? Спецы увидят, что он хорош и будут его использовать
Чтобы "спецы" про него узнали, нет? Откуда они еще узнают про язык, если про него не будут рассказывать, а просто где-то на серваке будет лежать билд, без описания, документации, статей.
Ты совсем поехавший, или притворяешься?
Аноним 16/03/20 Пнд 12:49:48 #397 №649420 
>>649419
Я не он, но анонче не ругайся и не разводи срачи. Блять хоть не тут, нас и так мало вы ещё срётесь.
Аноним 16/03/20 Пнд 13:05:41 #398 №649421 
>>649419
> тебе нельзя программировать на c#
А я что, разве давал повод подозревать себя в таком страшном говноедстве?
Аноним 16/03/20 Пнд 17:15:06 #399 №649448 
раз уж тут за языки трут, что думаете о jai посоны? пилится игроделом для игроделов, философия мне по нраву
https://sites.google.com/site/jailanguageprimer/
Аноним 16/03/20 Пнд 17:42:02 #400 №649454 
image.png
>>649448
Ну у него интересные есть особенности, бесспорно. Но без долгой разработки и большой базы людей которые работают с этим ЯП это к сожалению говно без задач. Есть огромное количество всяких годных языков андеграундных языков, но мне кажется адекватный человек который собирается пилить долгоиграющий и большой проект не будет выбирать что-то подобное. К сожалению.

Алсо, нашёл репку на гитхабе и обосрался. Нет спасибо точно не надо.
Аноним 16/03/20 Пнд 20:22:12 #401 №649475 
>>649454
>ряя я не верю в языки, в маркетинг которых вкладываются многомиллионные транснациональные корпорации
>ряя язык пилит полтора инвалида в свободное от работы время, нинужон
У тебя биполярочка?
16pixel 16/03/20 Пнд 22:19:39 #402 №649495 
gaemcons.gif
А мы продолжаем пилить рогалик на пиииииитонеее 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 для каждого этого объекта.

Так примерно?
Аноним 16/03/20 Пнд 23:32:37 #403 №649519 
>>649495
Зачем тебе в рогалике ECS?
16pixel 16/03/20 Пнд 23:45:28 #404 №649521 
>>649519
Ну надо
16pixel 17/03/20 Втр 00:10:18 #405 №649525 
gaemcons.gif
А, line of sight забыл!
Поправлено.
Все что угодно, лишь бы нормально не писать дальше. Хотя именно эту часть мне кажется я сделал заебца.
16pixel 17/03/20 Втр 03:20:13 #406 №649551 
Так, падажжите посоны, я кажется вкурил в ецс
Попробую - отпишу
Аноним 17/03/20 Втр 05:52:38 #407 №649559 
>>649475
Конечно, потому что это писал не я.
Аноним 17/03/20 Втр 05:54:47 #408 №649560 
>>649551
Дак я что, недостаточно выше описал а бляТЬ? Просил же вопросы вопрошай.
Аноним 17/03/20 Втр 06:02:40 #409 №649562 
>>649495
Из того, что я понял про ECS, чтобы адекватно перекатить это все в эту модель, нужно:
1. Удалить нахуй Класс Creature Создать Класс Component и написать ему базовые методы взаимодействия (добавить удалить найти). Отнаследовать Component и сделать каждый такой тип, а также массив данных внутри него.
2. Все методы и весь испольняющий код вытащить наружу и сделать только как классы без полей. Сделать так чтобы системы были ориентированы только на работу с определёнными компонентами.

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

Вот хорошая статья кстати
Аноним 17/03/20 Втр 10:39:11 #412 №649586 
>>649563
Можно конкретный пример, как ецс облегчает жизнь?
Аноним 17/03/20 Втр 11:48:42 #413 №649600 
>>649586
Орды зомби. Если выхватить из толпы одного из них, он ведёт себя как зомби: бежит, хватает, кусает, рычит. Все вместе они обсчитываются, как жидкость, которая растекается по локации, заполняя пустоты.
На других паттернах ты заебёшься такое делать, а сделав, заебёшься оптимизировать. На ЕЦС у тебя будет две системы: зомбиОрда - обсчитывающая поведение жидкости, состоящая из частиц в виде отдельных зомби, бегущих при движении и стоящих при остановке, и зомбиНПЦ - которая выхватывает "частицы" у орды, накидывает на них свой набор компонентов и убирает компоненты орды. После чего частица жидкости превращается в зомби и накидывается на тебя. Соответственно, перехватывает частицы при приближении к игроку, отпускает при удалении (при условии, что выделенный зомби перестал преследовать) и зомбиОрда снова подхватывает ничейную сущность, как свою частицу, навешивая на неё свои компоненты.
Соответственно, при добавлении простых НПЦ, если они заражаются, они перехватываются одной из вышеуказанных систем.
Аноним 17/03/20 Втр 11:49:50 #414 №649601 
>>649586
Связности меньше. У тебя есть данные, разные виды которых ты можешь свободно удалять и добавлять. Есть системы, которые друг с другом не пересекаются по сути и не лезут в функционал друг друга. Опять же не связные.

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

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

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

>>649562
Скоро отпишусь по теме
Аноним 17/03/20 Втр 14:27:03 #418 №649632 
>>649627
>>649616

Внезапно на питоне тоже есть ECS реализации. Напиши свою или возьми эту. Тоже интересный экспириенсь
16pixel 20/03/20 Птн 00:06:59 #419 №650122 
gaem.gif
В общем, про 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/, но я вкуриваю тупо и медленно, поэтому пока без теней - реализовал расчет октантов и накостылил гибрид рейкастинга и кастинга октантов. Гифку прилагаю.

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

Всем добра
Аноним 20/03/20 Птн 06:01:01 #420 №650130 
>>650122
>Применение данного подхода требует определенного анти-логического мышления - очень непривычно, что все объекты, с которыми ты в коде работаешь (ну, или максимальное их количество - смотря как напишешь ECS) это просто обертка, в которую может быть насовано все что угодно, любые методы, которые на самом деле еще и объекты.

Это значит что ты его нихуя не понял. Как раз копоненты и есть более естественный метод для программирования не только игр вышесказанных, но и вообще любых симуляций (читай игр) где у тебя есть много одинаковых объектов или большое количество пересекающихся аспектов программы (это важная черта игр.)
Аноним 20/03/20 Птн 08:43:26 #421 №650136 
>>649632
> ECS реализации
Второй год удивляюсь, как народ трепещет перед ЕЦС, будто это какая-то невъебенно сложная технология. ЕЦС состоит из 2х частей:
1. Никакого наследования, только композиция.
2. Глобальные переменные достаём из файлов с данными.
Вот и весь ЕЦС.
Аноним 20/03/20 Птн 09:53:14 #422 №650145 
>>650136
Потому что когда дело доходит до реализации всплывает немало проблем связанных с тем что технология требует использовать другую парадигму построения программы, не ООП к котому все привыкли а компонентно ориентированную. Также есть много проблем связанных с тем как реализовать саму ECS, ведь там есть сотни разных подходов так скажем.
Аноним 20/03/20 Птн 11:27:20 #423 №650152 
>>650136
>Вот и весь ЕЦС.
У кукаретиков всё просто, а ты попробуй написать нормальный производительный рантайм для ецс, жидко обмякнешь.
Specs например строит граф зависимостей систем, смотрит какие системы какие компоненты используют, и на основе этого параллелит выполнение по ядрам процессора, чтобы ты мог не Х сущностей обработать за такт, а число ядер * X.
Legion ecs позволяет делать sql-подобные запросы, чтобы отбирать сущности для обработки, типа, выбрать сущности, у которых есть компонент Х, нет компонента У, а параметр Z компонента W больше или равен какой-то величине, при этом работает это очень быстро.
Аноним 21/03/20 Суб 04:57:24 #424 №650272 
>>650152
Подтверждаю.
Подходов для даже простого решения как реализовать хранение компонентов и каком виде немало. При том что каждый из них даёт свои бенефиты но и ограничивает.

>>650122
А тебе скажу - выброси нахуй ЕСЦ если пользоваться им не умеешь. Нельзя просто части игры перевести нп использование комопнетов, ты только больше усложнишь код и сделаешь такую хуйню в которой сам увязнешь.
Аноним 21/03/20 Суб 09:59:28 #425 №650281 
>>650152
>Specs например строит граф зависимостей систем
зачем его должен строить фреймворк, если лучше его явно создать пользователю. в юнити такая-же ерунда. неявное указывание зависимостей размазанное по системам только усложняет программирование. намного проще в одном месте явно создать граф объектов, где какие-то выполняются одновременно, какие-то по очереди.

алсо, ты не понимаешь сути рогалика. там событийная архитектура. там нет смысла в чистом ECS. компоненты - это по сути просто обработчики событий.
Аноним 21/03/20 Суб 11:23:43 #426 №650286 
14928254377633.jpg
>>650281
>компоненты - это по сути просто обработчики событий.
сука иди нахуй необучаемый
Аноним 21/03/20 Суб 11:34:21 #427 №650288 
>>650286
У него все нипанимают, один он ПОНИМАЕТ.
Ни одного рогалика, тем более на ecs, он естественно, не сделал. Он просто ПОНИМАЕТ.
Аноним 21/03/20 Суб 11:41:46 #428 №650289 
>>650122
>ECS штука совершенно роскошная, если ты пишешь что-то типа dwarf fortress или caves of cud, где тебе нужно, допустим, чтобы сундук и предметы хранил и диалоги мог разговаривать

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

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


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

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

Короче, у ECS нет будущего.
Аноним 21/03/20 Суб 11:42:51 #429 №650290 
>>650130
>Как раз копоненты и есть более естественный метод для программирования не только игр вышесказанных, но и вообще любых симуляций (читай игр) где у тебя есть много одинаковых объектов или большое количество пересекающихся аспектов программы (это важная черта игр.)
нет. ECS реально требует другого мышления. А то что ты описал - это обычная агрегация из ООП (то есть возможность выделять разные черты в разные классы - это не компоненты из ECS)
Аноним 21/03/20 Суб 11:45:14 #430 №650291 
>>650289
давно уже решена в классическом ООП множеством способов
Ну так покажи мне пожалуйста хоть один удобоваримый способ, чтобы это не проёбывало масштабируемость и не срало на раскладку данных в памяти пожалуйста.

Аноним 21/03/20 Суб 11:48:03 #431 №650293 
>>650290
Подумал немного, с этим согласен что агрегация/композиция тут будет более "естественна", но при правильном подходе ECS может очень гибко жонглировать свойствами объектов даже прямо в runtime.
Аноним 21/03/20 Суб 11:53:00 #432 №650294 
15453633836143.jpg
>>650289
>есть стопятсот компонент и есть стопятсот систем под каждый компонент.
Вопрос организации кода. Если на ум ничего больше не приходит как нахуярить сотни компонентов, то это проблемы твои а не концепции.

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

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

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



Аноним 21/03/20 Суб 14:06:44 #433 №650321 
>>650291
>Ну так покажи мне пожалуйста хоть один удобоваримый способ, чтобы это не проёбывало масштабируемость
решений много. Даже банально:
class Entity{
array<Component> c;
};
(то есть избавляемся от систем, и храним компоненты в самом Entity - это ООП, а не ECS)
А так, фасад, билдер, фабрики и т.д.
На геймдеве еще был пример асспекто-ориентированного подхода.

>>650291
>и не срало на раскладку данных в памяти пожалуйста.
а ты уверен что тебе в твоем рогалике это нужно? кеш-фредли вообще-то для консолей старого поколения делали, у которых процы как говно. Для пк это уровень "буду писать рогалик на ассемблере".
ААА игры на классической нодсцене ни у кого не тормозили даже 20 лет назад, а твой рогалик вот не сможет работать?
Аноним 21/03/20 Суб 14:09:54 #434 №650322 
>>650294
>Вопрос организации кода. Если на ум ничего больше не приходит как нахуярить сотни компонентов, то это проблемы твои а не концепции.
если ты весь функционал фигачишь в один компонент - то ты нарушаешь концепцию ECS
В ECS ты должен выделять наибольшее количество компонентов. И конечно под каждое из них будет своя система. В тех же презентациях рогаликов показывали на экране сотни компонент.

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

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

Аноним 21/03/20 Суб 14:23:08 #435 №650326 
>>650321
>>650322

>решений много.
Вопрос реализации.

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

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

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

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

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



Аноним 21/03/20 Суб 14:33:24 #436 №650327 
>>650326
>Вопрос реализации.
ну вот например я сейчас ковыряюсь с паттерном property container - оно делает то что нужно - возможность добавлять новые свойства классу без всяких там наследований и т.д.

>>650326
>Запас производительности всегда можно куда-нибудь потратить.
не факт что этот запас будет, да, компоненты кеш-фредли, но вот оно будет жрать больше памяти (потому что компоненты надо выделять один раз с запасом в огромном куске памяти, иначе не будет этого кеш-фредли).
Да и там возможно такие мизерные запасы
Аноним 21/03/20 Суб 14:54:14 #437 №650332 
>>650327
>ну вот например я сейчас ковыряюсь с паттерном property container
Интересная штука. Насколько абстрактно она реализуется?

>потому что компоненты надо выделять один раз с запасом в огромном куске памяти, иначе не будет этого кеш-фредли
ну в основном это относится к менеджменту памяти. Обычно компоненты всегда лежат одинаковыми блоками. Конечно постоянное удаление-добавление фрагментирует память, но вполне можно сохранять свободные индексы или дефрагментировать в потоке это всё дело. Наблюдай за тем как legion ECS справляется с этой задачей, я его как раз ковыряю сейчас.
Аноним 21/03/20 Суб 16:52:05 #438 №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.
Аноним 22/03/20 Вск 01:23:21 #439 №650426 
>>650286
напоминаю что речь о рогаликах.
что ты там в системах собрался обновлять каждый кадр? что ты собрался распараллеливать, когда результат каждого хода и каждого события строго зависит от предыдущего?
Аноним 22/03/20 Вск 04:58:06 #440 №650437 
>>650426
Если брать такие рогалики как ADOM, Nethack и суп, то да, это будет совершенно излишним, потому что в них мир существует только в рамках замкнутого данжона.

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

Далее насчёт распаралеливания. Технически можно не создавать квантированные ходы, а сделать допустим 100 милисекунд. Игра будет "как-бы" технически рилтайм, но на деле игра будет ждать действия игрока, выполнять его (пойти в клетку, атаковать) а потом опять застывать и ждать.
Любые выполняемые действия в игровом мире имеют точку старта и точку завершения, ничего не происходит мгновенно и любое действие прерывается при определённых обстоятельствах (потеря равновесия или отмена действия самим игроком, если он конечно успеет.)
Аноним 22/03/20 Вск 07:37:30 #441 №650451 
>>650426
>>650437

только в рамках замкнутого, квантированного по времени мира.
Аноним 26/03/20 Чтв 19:02:31 #442 №651304 
>>650451
У тебя есть примеры неквантируемого мира?
Аноним 26/03/20 Чтв 19:13:33 #443 №651305 
>>651304
Выгляни в окошко да посмотри.
Аноним 27/03/20 Птн 15:55:05 #444 №651440 
>>651304
Примеров по-сути нет, тут скорее хотел указать на явное разделение.

>>651305
Лол да.
Аноним 30/03/20 Пнд 15:15:45 #445 №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.
Аноним 30/03/20 Пнд 18:16:53 #446 №652146 
>>652121
> Общий принцип таков: все ресурсы загружаются через библиотеку, а библиотека сама решает, когда нужно загрузить файл с диска, а когда достаточно отдать ссылку в памяти на уже загруженный ресурс.
У меня то же самое, только назвал другим словом.

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

> Pascal
Брат братан братишка
16pixel 12/04/20 Вск 01:16:14 #447 №655766 
progress.gif
На правах бампа - пишу о прогрессе рогалика на питоне.

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

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

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

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

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

Пока простой концепт рогалика полагаю такой - есть какое-то количество этажей, выход с каждого этажа закрыт, ищем ключ, открываем дверь - ломимся на следующий этаж. На последнем валим жирного монстра - конец игры. Все остальное опционально и в рамках отработки навыков.
Аноним 12/04/20 Вск 04:33:52 #448 №655807 
>>655766
> Сломал голову об ECS, в итоге забил
На первые проекты такую хуйню довольно тяжело применить, нужно скажем так испытать момент когда сложность кода будет превышать порог относительно лёгкого внедрения фичи. Тогда мозг сам захочет пощупать разные методы организации кода, если он конечно достаточно развит.

Хотя я всё еще не могу понять что могло в ECS тебе быть не понятым. Я в него въехал буквально сразу.
16pixel 13/04/20 Пнд 23:42:44 #449 №656680 
progress.gif
>>655807
Как концепт - понятен. Как его накостылить - не вполне понятно.

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

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

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

(алсо, добавил дропы, инвентари мобам, id-шники предметам чтобы спрайты было легче рендерить, тред живи)
Аноним 14/04/20 Втр 06:26:11 #450 №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 раз тебе так сложно.


Аноним 15/04/20 Срд 22:12:06 #451 №657311 
Как же вы заебали со своими ECS, не ецс. Главное, чтобы проект был удобным в разработке и его расширении в дальнейшем, ну и чтобы код удобно читался. ВСЁ! Найти баланс между этим говном. Если ты нашел идеальный баланс для себя, то остальные абстракции нахуй плодить не надо. Парадигма ооп на сегодняшний день пока одна из самых удобных, а ецс это темный лес. Иногда бывает, что ты сам того не зная, строишь свою смесь из ооп и ецс из говна и палок.
16pixel 16/04/20 Чтв 02:13:32 #452 №657505 
progress.gif
Истинно так.

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

А еще pygame не умеет выводить text в несколько строк, пизда прост. Такие-то костыли воротим
Аноним 16/04/20 Чтв 02:24:56 #453 №657513 
>>657505
Я на полшишечки сам читаю, но на pygame пилю только тогда, когда мне заняться нечем
Аноним 16/04/20 Чтв 05:13:19 #454 №657572 
>>657505
Да ты пока его вообще не вдуплил.

>>657311
Не ори, дядя.
>удобным в разработке
>остальные абстракции нахуй плодить не надо
Как? Покажи удобный метод для создания расширяемого кода. Про абстракции вообще загнул. ООП это тебе тоже абстракция над ASM и что? ECS становится полезен когда программный код изобилует перекрёстными взаимодействиями, или игровые сущности имеют один корень и природу, и должны мочь очень гибко её принимать, не вызывая конфликтов. Такой подход дюже помогает при написании игровых симуляций, или систем, опять же, с большой комплексностью, или перекрёстным взаимодействием. Естественно при таком раскладе для пиления игорей с относительно простой логикой, типо гриндилок, плоской индюшатины, или топорных дунжон кроулеров (чем собственно и завален сейчас игропром, не говорю шо это плохо) ECS нахуй не всрался, и как ты сказал, будет просто не удобен, и есть более удобные и известные методы. Но если ты хочешь сделать что-то такое суканах комплексное, по типу ДФ или Римача (что первое в голову попалось), то тут ECS начинает уже быть чертовски полезным, по вышеописанным причинам.
Если до сих пор вы не вдуплили положняк и у вас не осталось адекватных вопросов, то вы просто долбоёбы блядь и мне страшно за вас и игропром.
Аноним 16/04/20 Чтв 05:33:13 #455 №657578 
>>657311
Так шо всё дело в инструменте. Я не говорю что ECS лучшая религия, просто пытаюсь пояснить тутшней питоноуточке за ECS, но что-то он шибко туго всасывает. Плохие догадки о его интеллекте у меня возникают.
Аноним 16/04/20 Чтв 11:46:36 #456 №657614 
>>657578
>питон
>Плохие догадки о его интеллекте у меня возникают.
Они только сейчас у тебя возникли?
Человек с двузначным и более IQ не стал бы писать игру на питоне.
Аноним 16/04/20 Чтв 13:20:23 #457 №657665 
15770447782280.jpg
>>657614
Лол, у меня кажется у самого двузначный IQ раз я только сейчас на это внимание обратил.

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

Алсо, скоро-то тред потонет уже, а Оп давно уже хуй. Не знаю, есть ли смысл перекат делать
Аноним 16/04/20 Чтв 13:40:59 #458 №657683 
>>657505
В Питоне не нужен паттерн комманд, потому что там функции и без того являются объектами.
16pixel 16/04/20 Чтв 14:33:12 #459 №657711 
progress.gif
>>657683

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

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

Все равно никто кроме меня в этот тред контент не кидает, а ваша обратная связь очень ценна.
Аноним 16/04/20 Чтв 14:37:16 #460 №657712 
>>657711
Да ладно кидай, это всё равно намного лучше чем сидеть и бухтеть без дела как мы.

>говорит, что не так очевидно всё
Да нет, не то чтобы это неочевидно. В других языках реализация команды обычно сложнее. Через наследование и т.д.
Аноним 16/04/20 Чтв 15:00:38 #461 №657731 
Ну и еболу же я написал, пиздец
Но все равно ожидаю закидывания хуями, не зря же гифку делал
Аноним 16/04/20 Чтв 15:02:45 #462 №657734 
>>657731
Говорю же, если ты что-то делаешь, даже хуйню, это всяко лучше чем ничего не делать. Как мимнмум ты опыт получишь.
Аноним 16/04/20 Чтв 15:02:50 #463 №657735 
>>657731
Пока все работает в 60фпс/по дизайну - забей. Дохуя инди игр в релиз с говнокодом выходят, а диванные кукаретики и дальше байты дрочить будут
мимо Тодд Говард
Аноним 16/04/20 Чтв 15:38:22 #464 №657753 
progress.gif
Как-то так.
Аноним 19/04/20 Вск 01:59:49 #465 №659095 
Ананасы, а что на счёт рогаликов с сюжетом?
Или же рогалики но не пошаговые? Как это правильно будет называться?
Аноним 19/04/20 Вск 04:58:09 #466 №659115 
>>659095
Тру рогалики с сюжетом это взаимоисключающие параграфы. Сюжет всегода предполагает более-менее рельсовый геймплей, что для рогаликов вообще-то непростительно. Правила мира там должны всегда работать свободно в каждом моменте времени. Конечно можно говорить про адаптивные системы сторителлинга, которые сюжет бы тебе пилили исходя из твоих действий, но до таких технологий пока люди не досрали.

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

rougelite это как попытки под рогалик, но несоблюдающий некоторые пункты. Но вообще с такими вопросами в /ro/
Аноним 20/04/20 Пнд 00:43:50 #467 №659411 
>>659115
Я это вообще к чему
Обчитался тут на самоизоляции исходников эмулятора сервера вов (всегда было интересно как работают спелы пускай даже и в эмуляторе), да и руки зачесались что-то такое сделать
Вот и думал как можно отойти от неких установок/канонов чтобы было и интересно и проще играть
Пока додумался до такого: открытый мир (грубо говоря реалтаймовая игра) и подземелья (игра пошаговая)
Но вот как это всё учесть и продумать пока не дошёл до этого
16pixel 21/04/20 Втр 23:30:17 #468 №660288 
progress.gif
Похоже я максимально близко подошел к подобию 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 21/04/20 Втр 23:34:17 #469 №660293 
А, бля, мужики! Я же годноту вам принес, и забыл запостить.

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

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

Видос для первого - https://www.youtube.com/watch?v=idP3uO9gxlM&t.
Базарю, еще захотите.
Аноним 22/04/20 Срд 06:09:21 #470 №660566 
>>660293
Они всрантые довольно если честно

>>660288
Я рад шо у тебя получается что-то придумывать, охуенно. Только пока это не ecs а шото страшное пиздец. Но норм, хорошо идёшь
Аноним 26/04/20 Вск 16:08:36 #471 №662926 
Что на счёт сетевых рогаликов? Насколько они интересны?
Аноним 28/04/20 Втр 17:20:22 #472 №664175 
>>662926
если пошаговые то вроде как нихуя неинтересны. некоторые шизойды-завсегдатаи этого треда считают что рогалик должен быть обязательно пошаговым
Аноним 28/04/20 Втр 22:22:17 #473 №664227 
>>657665
>Алсо, скоро-то тред потонет уже, а Оп давно уже хуй. Не знаю, есть ли смысл перекат делать
Я здесь и постоянно заглядываю в тред. Писать сейчас просто нечего: работаю РАБоту, самоизолируюсь потихоньку. Времени на петпрржекты просто нет, с голоду бы не сдохнуть. Перекатывать однозначно стоит, потому что тема треда много кому интересна, как оказалось
Аноним 29/04/20 Срд 06:00:26 #474 №664282 
>>664227
Ну сам и перекатишь.
Аноним 29/04/20 Срд 12:13:17 #475 №664353 
>>664282
Договорились
Аноним 30/04/20 Чтв 00:10:01 #476 №664627 
>>664175
Тогда надо делать сетевуху на подобие гантлента
https://www.youtube.com/watch?v=Kp9Mo9QuV2w
Аноним 30/04/20 Чтв 05:15:04 #477 №664659 
>>664175
Ну я когда думал много пердел над гейдизайном, имхо конечно стандартная пошаговость Роугов уже протухла нахуй, при этом если хочешь въебать мультиплеер скорее всего тут требуется использовать рил тайм, или какие-то хитровыебанные методы. Но суть в том что рогалики это не какой-то спинномозговой дроч а тактика. А без пауз или пошаговости хуй тебе а не тактика. думал над какими-то системами а-ля Divinity original sin, где образуется "пузырь" в котором действовать могут все только по шагам. Но при этом этом на подумать у всех будет не так много времени, секунд 10-15 наверное. Но такая механика очень сильно неестественная, поэтому надо думать.
Аноним 01/05/20 Птн 04:07:17 #478 №664889 
>>664659
Просто темп игры не должен быть слишком быстрым
К примеру автоатака раз в полторы-две сек, таргетная система боя
Можно даже без коллизий между юнитами делать, а учитывать только расстояние до цели, угол
Аноним 01/05/20 Птн 06:05:23 #479 №664898 
>>664889
Ну про то что темп не должен быть слишком быстрым это да, как вариант скажем так.

Про последнее не понял.
Аноним 01/05/20 Птн 06:07:32 #480 №664900 
>>664889
>К примеру автоатака раз в полторы-две сек, таргетная система боя
а что, это вполне интересная идея, есть даже вполне успешные примеры(хотя к рогаликам они относятся вообще никак) - в FF14 емнип каждый тик равен строго 2.5 секундам. и ничего, люди вполне привыкают к такой системе, какие-то действия наперед просчитывают.
запилить что-то вроде такого а то и дольше - здесь возможно поиграться надо, может быть добавить какой-нибудь класс для спинномозговых с менее зависящими от тика способностями, может вполне выйти неплохо и нашим и вашим
Аноним 01/05/20 Птн 06:29:43 #481 №664904 
>>664900
система может и интересная, но мне как человек который дрочит на симулятивность кажется искуственной и ограниченной. Но как обусловненная игровая механика нормально.
Аноним 01/05/20 Птн 07:28:08 #482 №664906 
>>664898
> Ну про то что темп не должен быть слишком быстрым это да, как вариант скажем так.
Это я привёл в пример автоатаку, а вот допустим как было бы с кастерами
Например, каст идёт 1-1,5 сек, за это время ты думаешь что можно использовать дальше, как может ответить противник
Если это мгновенные заклинания (например, наложение доты), то надо прикинуть сколько она нанесёт урона за всё время (как вариант скалирование урона должно производится во время каста, а не постоянно обновляться)

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

>>664900
Ну не обязательно фиксированный тик
Я рассуждал так: я знаю свои статы, свой урон, знаю хп противника, что он может сделать и исходя из этого я прикидываю за сколько секунд я его разложу (сколько ударов будет, какие способности я буду использовать и тд)
Аноним 01/05/20 Птн 07:31:28 #483 №664907 
>>664906
Опять же имхо это довольно аркадная конечно боёвочка. Если и брать рилтайм боёвку, то я бы выбрал что-то а-ля Rimworld, только заточеную под прямое управление. Только там надо порботать с тем как способности бы использовались.
Аноним 01/05/20 Птн 07:36:51 #484 №664908 
>>664907
> Только там надо порботать с тем как способности бы использовались.
Что ты имеешь ввиду?
Аноним 01/05/20 Птн 08:22:04 #485 №664910 
>>664908
Ну в моих кирилливаниях способности и их использонваие особым образом структурированы. Будет специальное меню способностей или навыков, в котором будет 2 метода использования способности. Первый - способность можно использовать из контекстного или радиального меню, которое вызывается если зажать кнопку способности. Это быстрый способ. Выбрал способность зажатием, и использовал. Но ограничение на одну кнопку способностей 8, или того меньше. Таких кнопки будет 2-4. Второй метод уже будет длинный, прямо непосредственно вызывает всё дерево или список способностей, так как они будут все размещены иерархично. Но при этом там будут сразу все способности для использования.
Аноним 01/05/20 Птн 08:25:58 #486 №664911 
>>664908
Алсо. Система конечно вырвана из контекста. Потому что подразумевается что она будет использоваться в игре где этих самых способностей довольно дохуя. По сути любые действия игрока могут попасть в эту категори, просто которые acton, а ля копать, разбирать, ссать и срать не используются так часто как присесть, пойти вправовлево, использовать и прочее, и выносить их в отдельную клавишу (как делают поехавшие рогули древности) вообще нет никакого ризона.
Аноним 01/05/20 Птн 08:29:24 #487 №664912 
>>664911
Ну 99% возможностей игрока, как я себе представлял, будут реализованы через способности.
Не все из них активные (те которые может использовать игрок), а просто как бы скрыты.
Например способность атаковать, носить определённые предметы, использовать какую-то магию и тд.
Аноним 01/05/20 Птн 08:36:57 #488 №664914 
image.png
>>664912
Да. типо того. Вообще в идеале под любое действие любого существа должен быть единый фрейворк блять, ну или точнее технически это должно быть одного и то же действие. К слову насчёт магии - мне не нравится современное представление магии как просто ссаные действия которые делают урон и стоят маны, и всё, хуйня ебаная нассал.

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

Пик - кусок моих высерков.
Аноним 01/05/20 Птн 08:52:14 #489 №664916 
>>664914
> Вообще в идеале под любое действие любого существа должен быть единый фрейворк блять, ну или точнее технически это должно быть одного и то же действие

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

Также мы может полученные данные собственно изменять.
Ещё нужно уметь чтобы с помощью способности можно было вызывать новые entity. Допустим нам надо создать какой-то эффект, или запустить процедуру вызова существа и прочее.
Аноним 01/05/20 Птн 09:32:11 #491 №664920 
>>664918
> Просто тут да, выставляется вопрос того как прикреплять логику к этим действиям
Думаю просто на каждый этот эффект пишется своя функция и всё
Аноним 05/05/20 Втр 19:21:25 #492 №666172 
>>664918
> Допустим у нас у базовой способности будут методы для получения каких-то данных. Мы можем получать допустим эти данные с помощью вспомогательных методов, которые могут дать нам:

Всё, мне кажется, не предусмотреть.
Я у эффектов сделаю поле "цель", точнее там перечисление: сам кастер, перед кастером, союзники рядом, случайный противник в радиусе от кастера и тд и тп
Аноним 06/05/20 Срд 12:21:18 #493 №666326 
>>666172
Ну конечно не предусмотерть, но всегда можно максимально возможно охватить вероятности всякие бля. Вот какие фичи может быть тяжело или невозможно реализовать из того что предложил я?
Аноним 06/05/20 Срд 16:16:56 #494 №666363 
>>666326
Имеешь ввиду это >>664914 ?
Ну это просто похоже на какое-то описание школы магии или способностей.
Вот, к примеру, "Сбивающий поток воздуха" это стан цели. "Пневмовзрыв" может быть откидывание врагов на небольшое расстояние. "Защитный вихрь" ну это щит поглощающий урон.
Аноним 07/05/20 Чтв 14:18:55 #495 №666756 
>>666363
Ты не в ту сторону думаешь
Аноним 07/05/20 Чтв 15:03:17 #496 №666766 
>>666756
Объясни тогда своё виденье
Аноним 07/05/20 Чтв 16:37:18 #497 №666795 
>>666766
Да ты не то чтобы что то не правильно сказал. Тут скорее просто с наскока не пояснить за то как стоит вообще логику игры организовывать. условно говоря когда у тебя код организован классами, все данные в нём строго инкапсулированы, и у них как бы есть такие интерфейсы через которые код может общаться, то есть ты не можешь просто взять и из класса с одной логикой въебать модификацию данных в соседнюю логику (можешь считать это системой, или чем паче вообще объектом игровым). тебе обязательно нужно прописать взаимодействие это. Тобишь между разными кусками кода тебе приходится пилить паутину связей, чтобы всё работало. Это огроме переусложение, и создаёт большую связность. Это как раз причина того почему комплексных игорей очень мало, потому что писать логику в таком положении ебически сложно, так как связность растёт геометрически. (Возможно я драматизирую но пока из того что я видел получается именно так)
Аноним 07/05/20 Чтв 16:37:38 #498 №666796 
>>666795
Ой блять падажи. у меня шиза ебанула, я не о том написал.
Аноним 07/05/20 Чтв 17:02:53 #499 №666808 
>>666795
>>666796
Короче говоря, нужно сделать прототип чтобы было наглядно
Аноним 07/05/20 Чтв 17:03:33 #500 №666809 
>>666766



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

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

https://translate.google.com/translate?hl=ru&sl=fr&tl=ru&u=https%3A%2F%2Fgithub.com%2FadnzzzzZ%2Fblog%2Fissues%2F24

Вот тут кароче поясняется суть этого принципа.
Аноним 07/05/20 Чтв 17:05:22 #501 №666813 
>>666808
Выше я скинул гуглоперевод стати где говорится что то шо япытаюсь пояснить будет приводить свои дивиденты только позже, когда код твоей игры станет уже слишком сложным.

Да, надо действительно сделать какой-никакой прототип. Слухай, у тебя есть телега или мою возьми @adeeee6622, а то мы тонем тут немного...
Аноним 08/05/20 Птн 04:28:33 #502 №667090 
Эх, все обсуждают дженерик рогалики, но никто не пилит свою уютную сосаку-13, там ведь логики гораздо больше надо пилить и думать больше надо.
Например если просчет электричества ещё не такое сложное занятие (хотя там тоже можно вставить всякие законы ома и прочее в отличии от оригинала), то современный просчет физики газов и их смешивания, химия и генетика (а не та бутафория в нынешней сосаке), медицина, операции и болезни потребуют пиздец дохуя сеансов мозгового штурма.
В соло подобное пилю, но единомышленника пиздец как не хватает.
Аноним 08/05/20 Птн 10:20:24 #503 №667135 
>>667090
Сто такое соска13?
Аноним 08/05/20 Птн 14:36:29 #504 №667239 
>>667135
Space Station 13
Аноним 08/05/20 Птн 15:59:02 #505 №667269 
>>667090
А попроще ничего нет желания? Типа в районе DoomRL?
Аноним 08/05/20 Птн 16:37:19 #506 №667281 
>>667269
Так це ж рогалик обыкновенный
Аноним 09/05/20 Суб 01:20:46 #507 №667630 
>>667281
Не. Рогалик максимально упрощённый. Я о таком мечтаю уже лет жпять.
Там же кроме ходьбы и стрельбы ничего нет. Но каков геймплей!
Аноним 09/05/20 Суб 02:12:52 #508 №667658 
>>667630
Я хочу себе симулятор инженера/электрика запилить с корвоанами в виде симуляции виздуха, пока исходный код сосаки читаю. Вот это будет вин.
Аноним 09/05/20 Суб 02:22:21 #509 №667667 
>>667630
> Я о таком мечтаю уже лет жпять.
> Там же кроме ходьбы и стрельбы ничего нет. Но каков геймплей!

Дум выпустили в 93 году, играй
Аноним 09/05/20 Суб 03:15:04 #510 №667687 
>>667658
Алсо, хуй знает как правильно настроить симуляцию воздуха. По сути, она должна работать как вода, но тогда как один газ будет смешиваться с другим? Как будет создаваться новый объект из этих двух? Можно накладывать один объект воздуха на другой (ака слоенный пирог), но это слишком просто. Я не хочу стопроцентной симуляции, но хочу сделать чуть лучше, чем то, что существует в сс13 на сегодняшний день.
Аноним 09/05/20 Суб 03:17:28 #511 №667688 
Бля, забыл, что там по сути несколько типов газов могли находиться в одном тайле, не? Уже несколько лет в эту хуйню не играл.
Но в любом случае пришла идея, когда вместо определенного газа, тайл с воздухом будет тупо содержать данные о концентрации газов на этом тайле. А может в сс13 подобное и используется лол.
Аноним 09/05/20 Суб 03:46:49 #512 №667690 
>>667658
Я хочу думрл, но на космических кораблях, чтобы стены взрывались и декомпрессия. Вот тебе и симуляция воздуха.
>>667667
Прошёл ещё в 95-м, а потом ещё раз сто.
Аноним 09/05/20 Суб 04:00:37 #513 №667693 
>>667690
Не, если бы меня и интересовал сюжет, то скорее какой-нибудь детектив в космосе, ну или чужой с чувством тотального пиздеца и одиночества. А декомпрессия это ещё не вся симуляция тащемта
Аноним 09/05/20 Суб 11:48:38 #514 №667728 
>>667693
Чтобы сделать детектив или хоррор - нужен писатель. У меня есть пара братюнь, но их заинтересовать нужно.
Ну ладно, чо трепаться. Удачи тебе в запиле.
Аноним 09/05/20 Суб 12:18:21 #515 №667731 
>>667090
Блять ты где сука была пидр а? Я нормального человека который бы хотел в реально комплексные игори не видал. Я бы помог чем понемногу, сам думаю за хуйню логику хуё-моё ток давай перекат в телегу ибо скоро тред рухнет @adeeee6622

Аноним 09/05/20 Суб 12:21:29 #516 №667732 
>>667687
Алсо. Ебану сразу идею сюда. Ты спокойно можешь сделать так чтобы у тебя в одной клетке были как массивом несколько типов геймобжектов-веществ, которые при попадании в тайл просто чекали на возможность смешивания, или в самом тайле был булевой переменная указывающая что на тайле имеются неиннертные вещества, ну для небольшого оптимзиона. Также можно попробовать алгоритмы sparse quadtree для ещё большего оптимизона.
Аноним 09/05/20 Суб 15:51:53 #517 №667812 
>>667732
Неплохая идея, попробую реализовать.
Аноним 09/05/20 Суб 15:57:15 #518 №667813 
>>667812
Ну я много хуйни придумал, ты вообще насколько хочешь полностью воссоздать ссОЧКУ, ведь можно же лучше сделать есившто. Как нпример систему анатомии немного допилить, аугментациии въебать систему навыков (которые будут скорее использоваться в контексте активации аугментаций, или мутаций допустим. Ну много куда можно. Я выше описывал вродею)
Аноним 10/05/20 Вск 00:45:41 #519 №668057 
Ребзя, а какую РПГ систему запихнуть в рогалик? Я думаю GURPS lite, но может что-то есть фриварное?
Аноним 10/05/20 Вск 01:53:03 #520 №668070 
>>668057
d20
16pixel 18/05/20 Пнд 02:11:40 #521 №670530 
progress.gif
progress2.gif
Бамп вялому треду.

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

Призываю бампать тред своим прогрессом Или ниграми, хоть чем-нибудь. И перекат давайте.
sageАноним 18/05/20 Пнд 05:46:38 #522 №670541 
>>670530
>Возможно на питоне больше ничего такого писать не буду.
Exp +1 (те уже говорили что питун медленный)

Тут ОП должен был перекатить, но как-то никак. Если вдруг потонем, смогёшь сам перекатить с тем же заголовоком?
Аноним 19/05/20 Втр 11:11:27 #523 №671019 
>>670541
Перекатил https://2ch.hk/gd/res/671018.html

мимооп
comments powered by Disqus

Отзывы и предложения