Игростроение лингвофорумчан

[Toman]

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

Итак, второй вариант. Тут всё просто: отличие от вышеописанного базового варианта в том, что выживание клеток с 7-8 соседями происходит только в том случае, если все эти соседи одного цвета с данной клеткой. В результате в стационарном режиме из случайного начального заполнения цветные поля становятся крупнее по размеру - меньше чересполосицы.

Базовый вариант:


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


Третий вариант чуть сложнее. Вначале я попробовал сделать просто наоборот - т.е. выживание клеток с 7-8 соседями происходит только в том случае, если хотя бы один из этих соседей отличается по цвету от данной клетки (а значит, в чисто одноцветных областях всё работает идентично классическому правилу 23/3). Но оказалось, что этого недостаточно, чтобы активность не затухала. Пришлось сделать то же самое, но уже для вариантов 6-8 соседей, если хотя бы один отличается по цвету от данной клетки. В этом случае при достаточно большом поле активность не затухает сколь угодно долго, а очаги активности, естественно, обязаны представлять собой совсем мелколоскутную многоцветную мешанину - но они занимают меньшую часть площади, а бо́льшую часть занимают сравнительно крупные области, занятые обычным "пеплом" разных цветов, ну и периодически там происходит какая-то одноцветная активность (порождаемая многоцветными очагами, а сама по себе в долгосрочной перспективе обречённая на затухание).

[Easyskanker]

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

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

[Toman]

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

Не знаю уж, как Буд (не знаю, почему вы так уверенно говорите об этом), а я вот точно работал с ним (и другими вариациями правил) самостоятельно. Когда-то совсем давно (в начале 90-х) на Бейсике на старой XT-шке, а в начале нулевых в C++Builder'е. То, что вы описываете дальше - не варианты его реализации, а реализация некого совсем другого алгоритма, с другими правилами. Варианты реализации одного алгоритма обязаны давать один и тот же результат, соответствующий тем же правилам.

Когда слева от глайдера "Г" рождается клетка А, одновременно под А рождается клетка Б, поскольку вместе с ножкой глайдера "Г" и клеткой А вокруг Б три живые клетки. Мертвая Б обсчитывает окрестность одновременно с рождением А, и одновременно же с ее рождением становится живой.

Это не одновременно - это после.

В моем варианте клетка В точно так же умерщвлялась, но поскольку она умерщвлялась одновременно с рождением А, которое одновременно порождало рождение Б, ее умерщвление не успевало препятствовать рождению Б.

И это тоже не одновременно, а после.

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

[Easyskanker]

Базовый вариант:

Второй вариант

Третий вариант

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

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

Это какого?

[Easyskanker]

не знаю, почему вы так уверенно говорите об этом

Потому что это вытекает из упорного непонимания, которое заметно и у вас. Причем Буду еще простительно - мало ли, не интересно вникать человеку, может он на самом деле и писал подобные программы - а вам уже разжевали и в рот положили, и все равно никак, так что вы либо полностью забыли, как щупали правило 2378/3 двадцать лет назад, либо взяли готовый в основе код и только чуть меняли.

[Toman]

Это какого?

Ну вот видите красную область? Занимает где-то с четверть поля. В принципе каждый из пяти цветов "хотел бы" занимать области примерно таких размеров - так что с учётом хаотичности размеров и неправильности форм областей поле 625 на 400 реально маловато, чтоб им нормально развернуться.

[Bhudh]

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

Может, стоило сначала спросить, прежде чем утверждать?
Я писал реализацию игры "Жизнь", и она прекрасно у меня работала, и в принципе могу написать сейчас код ещё раз, это несложно.

[Bhudh]

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

Когда клетка при своём рождении сразу начинает влиять на соседние клетки и участвует в их обсчёте — это совсем не про "Жизнь".
В "Жизни" следующее поколение сохраняется не на том же поле (т. е. не в том же массиве), а на следующем.

[Bhudh]

И вообще пора процитировать Линуса Торвальдса и сказать:

Болтовня ничего не стоит. Покажите мне код.

[kemerover]

Да хотя бы псевдокод какой-нибудь. В Жизни всё просто,

новое_состояние = (текущее_состояние == 1) * ( (колво_соседей == 2) + (колво_соседей == 3) ) + (текущее_состояние == 0) * (колво_соседей == 3)

Где тут построчная проверка и что значит непострочная проверка — непонятно.

[Awwal12]

Осваиваю C# (при околонулевом опыте с языками семейства C вообще). Пожелайте удачи, что ли...

[Bhudh]

Вот "Жизнь" первым делом и закодьте . С битовым кодированием поля, вон как kemerover подсказал, и с произвольной установкой правил.

[kemerover]

Осваиваю C# (при околонулевом опыте с языками семейства C вообще).

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

[злой]

Я Си Шарп не изучал, но слышал, что он сделан по мотивам Java, а не C++. Соответственно, там должны быть интерфейсы, а не множественное наследование. Но я так понял, что если знаешь Java, с Шарпом быстро освоишься, хотя у меня необходимости не было (мне и Java-то больше для общего развития была нужна).

[Awwal12]

Я Си Шарп не изучал, но слышал, что он сделан по мотивам Java, а не C++.

Так Java однохренственно основана на синтаксисе C. У меня же до этого практически весь опыт был на Basic (Turbo Basic, Quick Basic, Visual Basic и VBA), и лишь немного на C-подобных языках (в частности, в Game Maker).
Впрочем, пожалуй, разница между Turbo Basic и Visual Basic в чём-то даже глубже, чем между большинством перечисленных (процедурное vs. объектно-ориентированное программирование).

[Python]

Так Java однохренственно основана на синтаксисе C.

Там много кто основан на синтаксисе С (С++, Java, JS, PHP...). Но если смотреть не синтаксис, а философию языка (набор активно используемых парадигм), то Java и C# сильно напоминают Delphi (то же ООП с классами и интерфейсами, сборщик мусора), JavaScrip — Python (динамическая типизация, JSON-подобные структуры, элементы ФП...). C++ — вообще другое ООП, на самом базовом уровне аналогичное ему пробовали делать в ТурбоПаскале (где тоже были статичные объекты), но в плюсах больше наворотов, чем в чем-либо еще, с неограниченными возможностями «прострелить себе ногу» в любом месте. Обычный Си — тот же Паскаль (плюс-минус строгость типизации и вариации на тему вложенности).

[Bhudh]

JavaScript похож на Python тем, что в нём есть JavaScript Object Notation-подобные структуры...
Хм... Ну, ладно.

[Python]

JavaScript похож на Python тем, что в нём есть JavaScript Object Notation-подобные структуры...
Хм... Ну, ладно.

Факт в том, что списки и словари для питона родные, прошитые на уровне синтаксиса, как и JSON для JS. Java тоже имеет списки и ассоциативные структуры, но они реализованы не как часть синтаксиса (в отличие от, например, массивов), а лишь как классы стандартной библиотеки — работая с ними, мы не можем присвоить объекту сразу всю готовую древовидную структуру — можем лишь (в части случаев) конвертировать из массива, а то и вовсе складывать по одному элементу.

[злой]

Не так давно решил попробовать написать на Си кое-что посложнее Hello World, и убедился, что вот эти типы а-ля u_int8_t и ручное управление памятью по принципу "выделил место - сделал свои дела - убрал за собой" после Node.js - это, конечно, жесть та ещё. Вроде просто для понимания, но возни много.

[Easyskanker]

Может, стоило сначала спросить, прежде чем утверждать?
Я писал реализацию игры "Жизнь", и она прекрасно у меня работала, и в принципе могу написать сейчас код ещё раз, это несложно.

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

И вообще пора процитировать Линуса Торвальдса и сказать:

Болтовня ничего не стоит. Покажите мне код.

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

Эксперимент:

Оригинальный алгоритм (эту программу тоже написал я, если вы и этот момент упустили):

[Easyskanker]

Где тут построчная проверка и что значит непострочная проверка — непонятно.

Строки в двумерной матрице. Вы вообще матрицы проходили, мистер Умник?

Когда клетка при своём рождении сразу начинает влиять на соседние клетки и участвует в их обсчёте — это совсем не про "Жизнь".
В "Жизни" следующее поколение сохраняется не на том же поле (т. е. не в том же массиве), а на следующем.

Именно. Что я и пытался безуспешно втолковать некоторым присутствующим.

[Easyskanker]

поле 625 на 400

Я это и спрашивал. Спасибо.

[kemerover]

Строки в двумерной матрице. Вы вообще матрицы проходили, мистер Умник?

Так и чем отличается построчная проверка от непострочной? Непонятно, что имеется ввиду. Вот я привёл описание игры жизнь. В чём проявляется её (не)построчность?

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

[Bhudh]

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

Если экспериментировать, то это будут уже другие правила, а не классическая «Жизнь».

Я в Гейммейкере делал, ностальгировал. Вы знаете, что такое Гейммейкер? Если не знаете, код из него вам ничего не даст.

Ваше высокомерие без причины не делает Вам чести.

Оригинальный алгоритм

Правила совпадают с оригинальной «Жизнью», это видно.

Эксперимент

Происходящее на экране и в демонстрации (я её открывал, вопреки Вашему предположению) не соответствует описанным там и здесь правилам.

Правило:
- если из восьми клеток вокруг белой клетки более шести черные, клетка становится черной;
- если из восьми клеток вокруг черной клетки более трех белые, клетка становится белой.

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

В классических записях правил (выживание/рождение) правила должны выглядеть так: 0123456/45678.
Открываем программу, оставляем тип правил «Life», устанавливаем эти правила:Рисуем глайдер, запускаем и на втором же поколении видим статичную фигуру.
Ибо

У меня каждая клетка обсчитывает окрестность Мура вокруг себя самостоятельно, все клетки считают вокруг себя одновременно, и разница скорее всего из-за этого.

Хотя

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

Вот мне и интересно, в результате каких экспериментов можно прийти к столь нетривиальным результатам и мысли о поклеточном обсчитывании, которое в корне противоречит концепции классической «Жизни».

[Bhudh]

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

В оригинальной "Жизни" не построчная проверка. В оригинальной "Жизни" проверка каждой клетки по отдельности до тех пор, пока не закончатся клетки, способные к изменению.
И меняется поле не построчно, а сразу целиком.
И вообще "построчность" как свойство двумерной матрицы — это всего лишь деталь реализации игры. Если размеры поля конечны, его можно записать в однострочный вектор-массив, как, например, записывается двумерная картинка методом CanvasRenderingContext2D.getImageData в JavaScript. При известной ширине поля W точки в n-ной строке адресуются со смещением W*n. Матрица для этого не нужна.