мысли по клонированию игры gnh20
суть такова: пошаговая бродилка с видом сбоку по клеточкам, с элементами рогалика
(жанр)
доступна новая демка!
Демо №3, ссылки на скачивание:
http://soflot.ho.ua/RogCloneDemo3_20150628.rar
http://soflot.ho.ua/RogCloneDemo3_20150628.zip
В новой демке можно лазить по деревьям, ползать по глубоким пещерам, убегать от ядовитых улиток.
Занудное видео старой демки (с объяснениями про псевдофизику и трещины в камне):
Если кто-то хочеть дать советы по доработке геймплея демки, то можно отталкиваться от записей в посте #34 - http://www.gamedev.ru/flame/forum/?id=176297&page=3#m33
Прошлое технодемо:
технодемо №2 от 29 июля 2014 - http://soflot.ho.ua/PreTechAlphaRogCloneDemo20140729.zip
беклог задач:
- более корректное передвижение персонажей
- инвентарь доработать
- доработка управления мышью
+ ещё много всего надо
---
---
Оригинал gnh20: http://www.gamedev.ru/flame/forum/?id=159858
Концепция для клона:
Игровой мир из клеточек, пошаговая игра. Весь мир просчитывается каждый ход. Идут разные процессы, мир меняется со временем.
Клетки могут быть разные по содержимому - воздух, вода, камень, дерево, кирпичи, лестницы и т.д. По клеткам могут ходить монстры (и ГГ), обычно по воздуху и по лестницам ходят, а по остальному нет (проходимые и непроходимые клетки)
Есть ещё предметы (шмот, оставляемый монстрами, сундуки и т.п.) - они и не клетки и не монстры, а нечто другое. Монстры все размером в 1 клетку, других пока не рассматриваем.
На блоки клеток, на монстряков и предметы действует гравитация и прочие закономерности (например сгорание в лаве, рост деревьев)
ГГ может ходить и лазить, собирать минералы, крафтить предметы, копать проходы, ставить новые блоки. Также ГГ сражается с монстрами (и возможно некоторые монстры между собой), но боевую систему оригинала брать не стоит, лучше или переработать или другую.
Что из оригинала оставить:
- постановка блоков
- обвалы (но надо более точную физическую модель)
- растущие и размножающиеся деревья
- вулканы (надо переработать)
- модификация местности монстрами, постройка монстрами домов
- сбор редких минералов в пещерах
- крафт, создание новых предметов
- генерируемые системы, в которых не всегда есть прходы, но есть тонкие стены которые можно прокопать
- дом (или дома) героя, который должен иметь стратегическое значение
- геймплейная необходимость лазить по новым пещерам и исследовать их, но при этом иногда возвращатьсяв уже освоенные места
- эрозия почвы, остывание лавы
Что из оригинала выкинуть:
- сохранение книгами, ограничения сохранений
- интерфейс
- управление
- светотени
- мёртвый песок
- тормоза в просчёте мира (по возможности)
- боевая система (надо бы переработать)
Продолжаю писать мысли по клонированию.
Гравитация связана с физическоймоделью в игре вообще. Все подряд блоки не могут падать. Но и висеть в воздухе всё подряд тоже не должо. Должны быть блоки, у кторых "внутренняя опора". Например, большие массивы камня. Они как бы продолжаются в третье измерение, будто на экране видим тонкий срез, а по обе стороны этого среза идёт большой массив породы. Если прорыть узкий горизонтальный тоннель под горой, то она не упадёт. Может быть даже узкие тоннели по-собому воспринимаются. А вот если есть узкий горизонтально выступающий кусок скалы, и срть ему основание (ту часть, где он крепится к крепкой скале), то горизонтальный висящий кусок упадёт, т.к. вроде потерял опору. Без опоры мелкие скалы падают сразу.
Если же подрыть той же горизонтально торчащей скале опору и оставить тонкую перемычку, то будет держаться, но при нагрузке перемычка может лопнуть и кусок оторвётся.
То же касается и блоков. поставленных игроком. Учитывается точка крепления, конфигурация, вес самих блоков, дополнительная нагрузка. Вес ГГ и монстров может быть тоже стоит учитывать. Но как бы ГГ таскает с собой много блоков и может/должен много весить? Вот например, ГГ занимает одну клетку. И может поставить 20 блоков кирпича, которые носит с собой. Значит ли это что ГГ должен весить как 20 блоков кирпича, если они у него в кармане? Или плюнуть на реализм и считать что его вес фиксированный, а поставленные блоки - отдельно? И тогда будет что если ГГ стоит на мосту и начинает вынимать из кармана кирпичи и класть рядом, то мост не выдерживает веса и обрушивается, а пока кирпичи лежали в кармане - мост выдерживал вес.
Но всё же концепт закреплённых и висячих блоков пусть будет. Блоки, которые ставит ГГ, учитывают точку закрепления. Может быть даже стоит учитывать связи между отдельными клетками. Например, две больших глыбы упали и лежат впритык. А потом мы под одной из них подкопали и она может падать. Так пусть и падает, ведь она ещё не успела приклеиться к другой глыбе. Поставленные ГГ-ом блоки обычно крепко привязываются ко всему, к чему могут. Для просвёта напряжений и отрывов надо продумать правила, алгоритмы.
в оригинале камни не падали как единая глыба. Там вроде бы мог падать большой кусок скалы, но он не был цельным а был как гора щебня - не было цельности этой падающей глыбы. В клоне я хотел бы чтобы крупные куски скал могли падать как единое целое (цепляясь по дороге за препятствия и не разваливаясь от касания)
Надо как-то ограничивать масштабы, не использовать для просчёта слишком дальние связи. Разбивать по возможности на кластеры, использовать кеширование, не пересчитывать всё каждый ход. Но это в финале, а для этапа протоипа можно и каждый ход пересчитывать.
Алгоритмы назначения закреплённых камней надо продумать. Самый простой способ это считать жёстко закреплёнными те камни, которые находятся внутри больших массивов камней. А всё, что по краям - висящие, но прикреплённые к ним.
Застывающая лава идругие новопоявляющиеся камни не считаются в большие массиывы сразу. Они должны окаменеть. Упавшие камни сначала тоже не считаются, они должны прирасти к скале с течением времени.
Вес тоже учитывается. Один крепкий камень не удержит скалу, если ей накидать камней сверху. Отсутствие связи камней может можно показывать трещинками
ГГ не от фонаря может ставить блоки. Одиночные блоки "дороже". А есть "оптовые": горизонтальные балки-планки-мосты и вертикальные лестницы. В оригинале (в релизе) количество поставленных блоков ограничивалось только терпением игрока, т.к. деревянные блоки были бесконечные. Мне кстати больше нравилось когда надо было рубить деревья, чтобы пополнять расходуемый ресурс древесины. Как раз была причина подниматься на поверхность. Можно ещё поковырять в этом направлении: с одной стороны, ставить сразу пачку блоков, чтобы не приходилось много раз тыкать мышью или возить ею с зажатой кнопкой, а с другой - чтобы этот ресурс был ограничен, и игрок ставил блоки вдумчиво, а не бездумно лепил лишь бы куда.
Вот кстати нашёл пост в оригинале про "робота-мостоукладчика" http://www.gamedev.ru/flame/forum/?id=159858&page=8#m119
Надо эти идеи опять пересмотреть в свете концепта клона
Эти блоки могут ломаться от нагрузки и от времени, старения. Например, лестница-подпорка. Она может удерживать от падения большую глыбу нестабильных блоков, но которые друг за друга держатся. И вся эта глыба опирается на лестницу, или на несколько лестниц. Пока лестницы крепкие, глыба держится. когда лестницы постареют и ослабнут, то под весом глыбы сломаются и глыба упадёт.
----
Пока думал, вспомнил что это уже обсуждали в оригинале:
начиная с поста №253 http://www.gamedev.ru/flame/forum/?id=159858&page=17#m253 пошло обсуждение физики блоков. Как получилось в итоге - мы видели. В клоне можно попробовать какой-то другой вариант, отличающийся от оригинала.
начиная с №271 kipar рисовал схемки http://www.gamedev.ru/flame/forum/?id=159858&page=19#m271
и я тоже немножечко подбрасывал в №276 http://www.gamedev.ru/flame/forum/?id=159858&page=19#m275
---
И ещё, нашёл хороший кусок текста с описанием фич (http://www.gamedev.ru/flame/forum/?id=159858&page=17#m253):
sb3d
> .... Про живой мир
> чуть подробнее. Это вот что такое: движения земной коры, образование вулканов и
> наводнений, автоматический рост и смерть лесов, нашествия различных кого-нибудь
> и так далее. То есть не должно быть такого, что выкопал туннель, и он таким и
> останется на веки вечные. Должно идти образование новых ископаемых под
> давлением и температурой, должно быть старение некоторых конструкций, гниение
> дерева, например. В общем вот.
некоторые штуки выше я уже записал, но из уст автора оригинальной игры это звучит как-то более весомо.
---
Опять про материалы и физику: пожалуй мне стоит описать примеры конструкций и как они должны себя вести, а потом выбрать такую псевдофизику, которая бы обеспечивала такое поведение и по другим параметрам тоже бы подходила (простота реализации, быстродействие, ресурсоёмкость, масштабируемость)
--
Кстати, какой размер мира оригинальной игры? (финальной релиз-версии) sb3d, может ты подскажешь? Хочется ориентироваться на оригинал, хотя возможно придётся урезать для обеспечения вменяемого быстродействия.
soflot
Потребляй слово задумка, вместо слова концепция.
Мир меняется - хорошо.
Мир из клеточек - норма.
Вид сбоку - фигня.
Три-мерность - норма.
Тотальная три-мерность - фигня.
Пошаговость - фигня.
Тактическая пауза - норма.
Монстры гасят друг-друга - хорошо.
soflot
> Кстати, какой размер мира оригинальной игры? (финальной релиз-версии) sb3d,
> может ты подскажешь?
На память не скажу точно, а только примерно: 500х500 блоков, примерно. Изначально миры были существенно больше, но после многих жалоб от людей на тормоза пришлось урезать. В основном тормозил рассчёт прочности конструкций, ведь его нужно было считать по всему размеру мира.
slatazan
> Пошаговость - фигня.
Нифига не согласен. :)
Хотя, именно на пошаговость было больше всего жалоб на смалл-геймсе. Я это объясняю тем, что люди ждали террарию, хотели видеть террарию. А с классическим рогаликом и не знакомы вовсе. В этих условиях, конечно, они не воспринимали пошаговость.
slatazan
ты играл в gnh20? ты смотрел скриншоты, видео по игре? ты читал обсуждение?
Ты пишешь совсем не в тему. То предлагаешь 3д, то про какие-то бамбуки пишешь... это совсем не вписывается в концепцию.
----
По физике камней: клетки-блоки важны, но связи между ними не менее важны. Надо описать конструкции, ситуации и желаемое поведение, а потом под них выбирать алгоритмы (этакое Test driven development).
Большой кусок камня, где все блоки жёстко связаны: при размерах 3х3 игровых экрана в центре уже будет дофига закреплённых блоков, неподвижных. А бублик вокруг них цельный неразваливающийся и закреплён, прицеплен к центральной крепкой части (по всему периметру). Поэтому весь большой блок висит и не падает.
Большой кусок камня, где между блоками нет связей вообще: алгоритм определяет, что в нём нет большого цельного массива камня, значит нет закреплённых блоков (они только в центре больших цельных массивов), значит блокам не за что держаться (Да и не могут они друг за друга держаться, сязей нету), и вся эта груда отдельных камней падает.
Маленький кусок жёстко связанных камней (например, 4х4 блока). В нём не найдётся закреплённых блоков, т.к. он слишком маленький. Ни один из блоков не имеет опоры, и они все падают вниз как единое целое. Т.е. если при падении хоть даже один блок скраю зацепится за что-то, то вся глыба остановится, хоть это и некрасиво выглядит с точки зрения реализма.
Отсюда можно сформулировать состояния: новый /закреплённый/незакреплённый.
Для незакреплённых можно было бы ещё вести состояние - падает или стабилен, но по факту это лишнее. Надо на события ориентироваться для оптимизации.
Случай горизонтальной балки, в которой все блоки связаны, которая не слишком длинная и одним концом закреплена в неподвижный блок (горизонтальная связь, вертикальной опоры нет). Эта балка должна оставаться на месте и не падать, связи не должны разрушаться.
Похожая, но слишком длинная балка: она в результате обрывает связь у самого основания, в месте крепления к неподвижному блоку, и падает вниз как единое целое.
Похожая которкая балка + тяжёлая глыба, которая на неё падает. Сама по себе балка держится, но после того, как на неё упала глыба, балка ломается у основания и дальше летят 2 куска. Балка и глыба, каждая группа как единое целое, но без связи между группами.
Вертикальная короткая балка, которая сверху прикрепена к неподвижному блоку. Она должна оставаться неподвжно висеть, не должно быть разрыва связей.
Похожая балка, но слишком длинная. Она должна оторваться у онснования, в месте крепления к неподвижному блоку, и падать вниз как единое целое.
короткая горизонтальная балка из скреплённых блоков, которая ни к чему не привязана, и лежит одним концом на неподвижном блоке. В результате балка должна оставаться неподвижной, не должно быть разрыва связей.
Похожая балка, но слишком длинная. Она должна сломаться в том месте, где заканчивается опора под балкой, и оторванный кусок должен начать падать вниз. Даже если балка опирается на неподвижный блок только одной клеточкой. Тогда эта клеточка остаётся а всё остальное падает вниз.
Вертикальная колонна из скреплённых блоков, прикреплённая внизу к неподвижному блоку, стоящая на нём. В результате она должна продолжать стоять, связи не должны рваться.
Похожая колонна, но слишком высокая. У неё в результате должно как-то рушиться основание и рваться связи у основания. Надо имитировать разрушение блоков под нагрузкой на сжатие. (Боковые связи - рвутся нагрузкой на сдвиг, а вертикальные - нагрузкой на растяжение).
Если блок сжат выше предела а рядом сбоку пусто, то он туда выскакивает, рвя все свои связи. Или можно просто сделать чтобы у блока рвались связи, независимо от того выскакивает ли он куда-то. Пожалуй этот предел на сжатие у обычного камня должен быть очень высок, может даже такой чтобы он был недостижимым, или даже вообще считать опредлённые виды материалов бесконечно прочными на сжатие. А вот для деревянных блоков это может быть актуально, или ещё для каких-то неконсистентных малопрочных пород, вроде песка или чего-то пористого. Таким образом если будет "гриб" с тяжёлой шляпкой и прочной ножкой - он будет стоять, а если ножка будет из дерева или из песка, то она будет обрушаться.
Ещё вариант: связанная конструкция в виде буквы U, обе верхушки тонкие и прикреплены к неподвижным блокам. Внутри у конструкции лежит груз, он достаточно тяжёлый чтобы оторвать каждую из верхушек поотдельности, но так как конструкция прочная и нагрузка передаётся по всей конструкции, то на каждую верхушку должно приходиться только половина веса груза, и в результате они не должны отрываться. Конструкция и груз должны оставаться неподвижными, не должно быть разрывов связей.
Похожий вариант, но конструкция более сложная, в виде буквы L, вся из связанных блоков. Горизонтальная часть с одной стороны опирается на неподвижный блок снизу, на самом краю, а верхушка вертикальной части прикреплена к неподвижному блоку сверху. По середине горизонтальной части лежит груз. Он достаточно тяжёлый чтобы порвать единичную связь вертикальной части, и чтобы сломать едиичную связь в горизонтальной части, опирающейся на неподвижный блок. Но так как нагрузка в конструкции распределяется, то как бы половина нагрузки идёт на растяжение вертикальной части (и не может разорвать), а половина идёт на сдвиг/срез/излом опирающейся горизонтальной части, и не может её сломать. В результате вся конструкция и груз остаются неподвижными, никакие связи не разрываются.
Но эти 2 последние варианта скорее всего нереалистичны для реализации в рогалике. Полный физ.движок может такое бы обеспечил, для подогнанной модели. И можно придумать фейковое что-то, чтобы заранее такие варианты опознавало и учитывало отдельно, а вот сделать цельный упрощённый физ-движок, чтбы ещё и остальные варианты кроме этих двух считал, может и не получится.
---
По всем этим вариантам надо нарисовать картинки чтобы проиллюстрировать.
soflot
> Клонирование gnh20 рогалика
За тебя никто ничего делать не будет. Поэтому вопрос лишь в том, сколько лично ты готов вложить в это дело.
Причём вложения в любом случае будут значительные.
Либо ты сам вместо работы год пилишь код. В убытке - год жизни и незаработанные за год деньги.
Либо ты оплачиваешь, чтобы кто-либо пилил код. В убытке - те же деньги, плюс нервы, потраченные на объяснение, чего именно ты хочешь.
sb3d
> За тебя никто ничего делать не будет
Да. Но если кто-то захочет помочь, то я не буду так рьяно отказываться, как это делаешь ты.
Сделал процедурку, которая считает падающие и зацепившиеся блоки (пока на участке 5х5). По волновому алгоритму. Пока сила связей, их разрывы и вес блоков никак не учитываются. Сначала все блоки "необработанные. Алгоритм выдаёт какие из них упадут, а какие держатся.
. O . F F
|
O-F . V O
V . . . .
|
V V F-O-O
. . . . ."." - пусто
"F" - фиксированный блок (не падает, за него можно держаться)
"O" - держащися блок
"V" - падающий блок (ему не за что держаться)
"-" - горизонтальная связь
"|" - вертикальная связь
soflot
> Сделал процедурку, которая считает падающие и зацепившиеся блоки (пока на
> участке 5х5).
Видео сними, с квадратиками.
И откуда 5х5? 6х6 уже память-быстродействие в компьютере заканчивается? Такие параметры нужно сразу делать произвольными.
Как себя ведут такие конструкции:
а) длинный горизонтальный мост от прочного основания?
б) длинная вертикальная колонны вверх-вниз от прочного основания?
в) Сложные конструкции?
г) Кто расставляет связи и где они храняться?
sb3d
> Видео сними, с квадратиками.
я не делал пока функции падения, она простая, неинтересная и не нужная сейчас. Блоки только отмечаются для падения, но самого падения я не делал.
Кстати, ты бы того, отдыхал чтоли... Отпуск всё-таки, дача...
>И откуда 5х5?
>г) Кто расставляет связи и где они храняться?
связи и блоки расставляю я в самом коде, сразу вношу в массив в начале. Маленький 5х5 кусок быстро и легко заполнять, его достаточно для задания показательных случаев. Да и вывод в консоль не сделаешь просто так для 100х100.
>Как себя ведут такие конструкции
пока что никак. Сложно будет найти связи, которые должны разорваться. У меня уже 13 страниц тетрадных размышлений по поводу этого алгоритма. Хочется чтобы нагрузка распределялась по толстому блоку, но при этом чтобы если нагрузка превышает прочность, то рвались бы самые нагруженные связи, самые слабые места как можно ближе к слишком тяжёлому грузу.
В общих чертах алгоритм придумал, но детали надо ещё продумать. Продумываю по дороге с работы и на работу. А ещё у меня опасения что алгоритм окажется неточным, дающим нереалистичные результаты, с неопределённым поведением, трудно отлаживаемый, черезмерно прожорливый по памяти и медленный. Когда продумаю все детали то начну потихоньку реализовывать для тех же 5х5 клеток.
Такой момент, закреплённая в 2х местах балка по моим правилам должна рваться в одном месте, а не в двух сразу. И надо как-то определять в каком. Использовать для этого рандом не хочу, и жёстко прописывать вроде "рвётся связь у клетки с меньшим индексом X+Y*Width". Хочется чтобы не было рандома, и чтобы не было перекоса в одну сторону. Наверно сделаю так чтобы для каждого такого случая попеременно бралась связь то с большим индексом, то с меньшим.
Если (внезапно) у кого-то есть уже готовые алгоритмы, более менее подходящие под описанные мной случаи, или есть идеи как бы это попроще и получше реализовать, то пишите.
soflot
> Если (внезапно) у кого-то есть уже готовые алгоритмы
Слушай, не хочется тебя разочаровывать, но для твоих целей нужен полноценный физический рассчёт напряжений в конструкции. Что и ты не потянешь, и комп реалтайм не потянет.
В Двадцатой было сделано вот так: а) Два типа блоков, стабильные и нет. б) Если касание с ближайшим стабильным блоком дальше, чем в 15 ячейках, нестабильный падает. Всё. И даже эта простейшая проверка офигительно тормозила. А всего делов то - проверить, есть ли касание стабильного блока не далее, чем в 15 ячейках.
> Кстати, ты бы того, отдыхал чтоли... Отпуск всё-таки, дача...
Если моё присутсвие в теме нежелательно, только скажи, я сотру любой из своих постов.
дешёвый ход для поддержания интереса к теме: выхлоп недоделанной части алгоритма распределения нагрузки
Схема
O-F-O-O-O
|
. . . . O
|
. . . . O
|
F-O-O-O-A
. . . . .
начальное состояние
[__.__.__] 8[__.__.__]10[__.__.__]50[__.__.__]10[__.__.__]
__ __ __ __ 40
[__.__.__]__[__.__.__]__[__.__.__]__[__.__.__]__[__.__.__]
__ __ __ __ 12
[__.__.__]__[__.__.__]__[__.__.__]__[__.__.__]__[__.__.__]
__ __ __ __ 15
[__.__.__]30[__.__.__]22[__.__.__]21[__.__.__]10[ 1.10. 1]
__ __ __ __ __
[__.__.__]__[__.__.__]__[__.__.__]__[__.__.__]__[__.__.__]
конечное состояние
[__.__.__] 8[__. 5. 7] 5[16.__. 6]45[16.__. 5] 5[16.__. 4]
__ __ __ __ 35
[__.__.__]__[__.__.__]__[__.__.__]__[__.__.__]__[ 4.__. 3]
__ __ __ __ 7
[__.__.__]__[__.__.__]__[__.__.__]__[__.__.__]__[ 4.__. 2]
__ __ __ __ 10
[__. 5. 5]25[16.__. 4]17[16.__. 3]16[16.__. 2] 5[21.__. 1]
__ __ __ __ __
[__.__.__]__[__.__.__]__[__.__.__]__[__.__.__]__[__.__.__]овер 1000 строк говнокода, btw. Объяснять шифр нарочно не буду :-Р
sb3d
> Что и ты не потянешь, и комп реалтайм не потянет.
Я собираюсь использовать три метода борьбы (сразу), которые ты не использовал в своё вермя:
- Кеширование, не повторять расчёт если не поменялось ничего в каком-то куске мира;
- Расчёт наперёд, на будущее на основе прогноза ходов, во время пока игрок думает между ходами;
- Использование видеокарты для расчётов.
Чтоб поддержать автора темы, скажу, что тема лично мне интересна. Сам в свое время хотел (и до сих пор хочу) клонировать gnh20 с бОльшим уклоном на тему богов. Но для начала так же хотелось повторить динамический, постоянно изменяющийся мир, с катаклизмами и прочим. Но за год или того больше, кроме как вывода буковок на экран ничего не сделал :(
(почти полгода прошло)
алгоритм распределения нагрузки сделал (написал по-другому). Вроде работает верно.
Иллюстрация:
исходное состояние
. . . O-O . . O-O . . O-O . . O-O . . . | F O-O . .
состояние связей, вес
[ 0. 0, 0] 0 [ 0. 0, 0] 0 [ 0. 0, 0] 0 [ 0. 0, 2] 0 [ 0. 0, 3] 0
0( 0^ 0 0( 0^ 0 0( 0^ 0 0( 0^ 3 0( 0^ 0
[ 0. 0, 0] 0 [ 0. 0, 0] 0 [ 0. 0, 2] 0 [ 0. 0, 2] 0 [ 0. 0, 0] 0
0( 0^ 0 0( 0^ 0 0( 0^ 7 0( 0^ 0 0( 0^ 0
[ 0. 0, 0] 0 [ 0. 0, 2] 0 [ 0. 0, 2] 0 [ 0. 0, 0] 0 [ 0. 0, 0] 0
0( 0^ 0 0( 0^ 10 0( 0^ 0 0( 0^ 0 0( 0^ 0
[ 0. 0, 2] 0 [ 0. 0, 2] 0 [ 0. 0, 0] 0 [ 0. 0, 0] 0 [ 0. 0, 0] 0
0( 0^ 14 0( 9^ 0 0( 0^ 0 0( 0^ 0 0( 0^ 0
[ 0. 0v 0] 0 [ 0. 0, 0] 0 [ 0. 0, 0] 0 [ 0. 0, 0] 0 [ 0. 0, 0] 0
0( 0^ 0 0( 0^ 11 0( 0^ 0 0( 0^ 0 0( 0^ 0пояснения:
[ А. Б, В] Г
Д( Е^ Ж
В - вес, Е - прочность связи от данного блока вниз, Ж - прочность связи от данного блока вправо, Г - нагрузка на горизонтальную связь (знак - для учёта направления), Д - нагрузка на вертикальную связь, А и Б - для вывода вспомогательных промежуточных данных, тут - не нужны.
финальное состояние
. . . . . . . . . . . O . . . O-O . . . F . . . .
[ 0. 0, 0] 0 [ 0. 0, 0] 0 [ 0. 0, 0] 0 [ 0. 0, 0] 0 [ 0. 0, 0] 0
0( 0^ 0 0( 0^ 0 0( 0^ 0 0( 0^ 0 0( 0^ 0
[ 0. 0, 0] 0 [ 0. 0, 0] 0 [ 0. 0, 0] 0 [ 0. 0, 0] 0 [ 0. 0, 0] 0
0( 0^ 0 0( 0^ 0 0( 0^ 0 0( 0^ 0 0( 0^ 0
[ 0. 0, 0] 0 [ 1. 0, 2] 0 [ 0. 0, 0] 0 [ 0. 0, 0] 0 [ 0. 0, 0] 0
0( 0^ 0 2( 0^ 0 0( 0^ 0 0( 0^ 0 0( 0^ 0
[ 3. 0, 2] -4 [ 2. 0, 2] 0 [ 0. 0, 0] 0 [ 0. 0, 0] 0 [ 0. 0, 0] 0
6( 0^ 14 0( 0^ 0 0( 0^ 0 0( 0^ 0 0( 0^ 0
[ 0. 0v 0] 0 [ 0. 0, 0] 0 [ 0. 0, 0] 0 [ 0. 0, 0] 0 [ 0. 0, 0] 0
0( 0^ 0 0( 0^ 0 0( 0^ 0 0( 0^ 0 0( 0^ 0В реальности такая конструкция бы опрокинулась, но для поклеточного мира это всё равно будет некрасиво, поэтому в алгоритме предусмотрено что поворот блоков не используется.
---
пре-альфо-техно-демки-скриншот 
пре-альфо-техно-демка, показывает в основном физику падения камней, постановки лестниц со связями.
Управление: стрелки, лестницы BHNMU, перегенерация уровня F, пропуск хода R
ссылка:
>(правка, пересобрал)
http://soflot.ho.ua/PreTechAlphaRogCloneDemo20140118a.rar
+Видео старой демки (показаны трещины в камне):
https://www.dropbox.com/s/6o5xqepuhf5ejwk/RogCloneTechDemoConv2.avi
известные косяки:
- медленно;
- иногда большой груз висит на слабой связи и не может её порвать (баг);
- ходьба вниз корявая, по 2 клетки;
- ГГ может вдавить в падающий камень;
(+ вообще всё сырое)
Ожидаемая обратная связь по демке:
- возможно кто-то захочет помочь программировать;
- возможно кто-то подскажет как лучше оптимизировать чтобы быстрее работало;
- моральная поддержка в разработке
Тема в архиве.