Игровая концепция "Tetrian"
Подставляю в граничные условия идеи тетриса вместо квадратика его диагонально отхваченную половинку, и получаю определение фигуры в граничных условиях тетриана :
- фигура - это геометрический объект, образованный четвёркой прямоугольных равнобедренных треугольников, вписывающийся в граничные условия игрового поля в клеточку и обладающий свойством целостности - то есть не содержащий разрывов на стыках между соседними треугольниками
- вращение фигуры, сохраняющее совместимость со способом её расположения на поле в клеточку, сохраняет тождество фигуры самой себе (в зависимости от принадлежности фигуры к одной из 5-ти групп симметрии таких способов её расположения может быть от 1-го до 8-ми, а конкретно - [1,2,4,4,8])
В пределах соблюдения перечисленных условий возможно образование всего 14-ти разных фигур :
В тетрисе их всего 5, и столь существенная разница не могла не привлечь моего внимания в плане ёмкости элементной базы для построения игровой концепции. Примечательно, что каждая из пяти фигур тетриса принадлежит к отдельной группе симметрии, коих как было сказано всего существует ровно пять, ну а в случае с тетрианом для 14-ти фигур вместо пяти единиц получается распределение [1,1,3,4,5], в соответствии с которым фигуры расположены в списке.
Необходимые определения даны, и теперь как это водится включаю ПМД (возможно правильнее здесь будут сказать "ПСП" - то есть Принцип "Сначала и по Порядку"). Следующим "по списку" шагом требуется определить игровое поле - надо же эти фигуры куда-то потом складировать (такой способ "складирования", при котором фигуры "падают в стакан" как в тетрисе, тут явно не годится). Любое приличное поле так или иначе должно обладать свойством симметрии, и применительно к данному случаю "включить ПМД" означает наделить поле из клеточек и их половинок свойством полной симметрии, согласно которому его как ни вращай ничего не изменится. Тогда как минимум это поле должно быть квадратным и любой из составляющих его треугольничков должен отзеркаливаться соответствующим образом "на все четыре стороны". Также из соображений совместимости с фигурами, ну и просто из эстетических, придётся наделить его свойством целостности и монолитности. Минимальный размер такого поля - 2*2 клетки, содержимое каждой из которых отзеркаливается на остальные. Здесь возможно всего два варианта формы поля - собственно квадрат 2*2, а также квадрат косящий под ромб, образованный путём отзеркаливания на все четыре клетки треугольничка (эквивалент первой фигуры в списке). Тут явно не хватает "игрового размаху", так что размер отзеркаливаемого шаблона придётся инкрементировать с 1*1 до 2*2, и как следствие увеличить размер результирующего пространства с 2*2 до 4*4. При соблюдении перечисленных требований к форме поля доступно всего 7 её вариаций :
Существенно здесь то, что фигуры как и в тетрисе состоят из 4-х атомарных элементов, а количество половинок квадрата, из которых состоят симметричные поля, всегда кратно 4-м, и как следствие любое из них можно заполнить без пропусков и наложений целым числом фигур. Над каждым из изображённых полей висит количество n необходимых для сборки поля фигур, а под каждым из них - количество N всех возможных и при этом разных комбинаций из n фигур, которыми можно заполнить данное поле. Теперь уже есть где развернуться для выстраивания на этой базе игровой концепции. Во-первых, бросается в глаза резкий скачок числа N при переходе к двум последним полям размером 7 и 8 фигур соответственно, вызванный скачком показателя обтекаемости их формы. Если расположить показатели N в порядке их возрастания [2,9,10,18,28,531,968] то для элементов этого множества до шестого будет выполняться условие "непревышения суммы двух предыдущих" (при наличии обоих слагаемых), при том что шестой почти в 8 раз превышает сумму всех пяти слевастоящих. Во-вторых, уникальность свойственна и самим комбинациям : разные поля как бы специализируются на разных фигурах, и в то же время обнаруживается значительный разброс в суммарной востребованности для построения полей каждой из 14-ти фигур (для первых пяти полей эта тенденция особенно ярко выражена). Таким образом, задействуя ПМД я фиксирую элементную базу, обеспечивающую необходимый минимум информации для построения на ней игровой концепции. Возможно он даже более чем необходимый, но если исходить из кратности размера поля размеру фигуры, то здесь едва ли придумаешь что-нибудь проще для получения конкретного результата.
Итак, в игровой концепции "tetrian" все 14 фигур являются целостными образованиями из 4-х диагональных половинок квадрата, все 7 полей являются целостными, симметричными и вписанными в квадрат размером 4*4 клетки образованиями из n фигур, при наличии резкого скачка в количестве N способов заполнения поля фигурами между первыми пятью и последними двумя полями. Последнее обстоятельство естественным образом дифференцирует функции полей, отводя пяти первым роль "целевых" - то есть требующих заполнения одним из N доступных способов, коими они располагают в количестве от 2-х до 28-ми ; а двум последним роль "базовых" - то есть обеспечивающих целевые поля ёмкостью от 4-х до 6-ти фигур необходимыми игровыми ресурсами, коими являются комбинации из 7-ми и 8-ми фигур, закреплённые за полями №6 и №7 в количестве 531 и 968 штук соответственно. Как следствие, вектор дальнейших размышлений устремляется у меня в направлении составления правил, обеспечивающих возможности черпания ресурсов из базовых полей и заполнения ими целевых одним из N доступных им способов.
На этом месте можно "записываться", поскольку при дальнейшем уточнении правил даже ПМД не поможет выдерживать однозначность причинно-следственных связей. Таким образом, предыдущий абзац можно считать определением игровой концепции "tetrian", наследуемой правилами конкретной логической игры или используемой для прикручивания к какому-нибудь игровому движку.
Далее проведу первичный количественный анализ полученных данных :
- общее количество целевых комбинаций : 2 + 9 + 10 + 18 + 28 = 67
- общее количество фигур, участвующих в 67-ми способах заполнения целевых полей : 2*4 + 9*6 + 10*5 + 18*4 + 28*6 = 352
- общее количество базовых комбинаций : 531 + 968 = 1499
- общее количество фигур, участвующих в 1499-ти способах заполнения базовых полей : 7*531 + 8*968 = 11461
- отношение количества "базовых" фигур к количеству "целевых" : 11461 / 352 = 32.6
Дифференциация полей на "базовые" и "целевые" ещё более усугубляет разброс в востребованности фигур для выбивания целевых комбинаций, и в следующей таблице приведено соотношение предложение/спрос для каждой из 14-ти в порядке убывания их востребованности, усреднённый показатель которой согласно расчётам равен 32.6 :
Как видно из таблицы, наряду с избирательностью, специализированностью каждого целевого поля на своих фигурах, прослеживаются довольно контрастные показатели востребованности фигур базовых полей для выбивания целевых комбинаций. Подобная асимметрия полезна с точки зрения игрового разнообразия, так что при составлении игровых правил не помешает этот момент учитывать, пользуясь тем что предложенный способ взаимодействия полей естественным образом распределяет в довольно широком диапазоне ценности фигур как базовых элементов данной игровой концепции.
В общем всё как обычно - вы глядя на это клипаете в недоумении глазами, а я играю в свои игры по мною же придуманным правилам. Но мало ли - вдруг кто-нить идею интересную подкинет насчёт того куда здесь можно думать дальше.
| Вложение | Размер |
|---|---|
| pols.jpg | 45.42 КБ |
| figures.jpg | 17.24 КБ |
| tab.jpg | 49.63 КБ |
- Для комментирования войдите или зарегистрируйтесь
Философский штурм | Совместное философское творчество © 2006-2014
Сайт представляет собой площадку для функционирования философского интернет-сообщества, участники которого заинтересованы не только в индивидуальном, но и в коллективном философском творчестве.
Комментарии
Если кому охота побаловаться раскладыванием этого пасьянса, могу предложить соответствующее ПО. Но тогда о мыши придётся забыть - там всё управление на клавиатуре. Не пугайтесь размера этого файла - засунул туда всю яву. Запускать если что "start.bat", а описание управления в одноимённом текстовом файле. Там же исходники, правда без комментов, но думаю что при наличии желания достраивать над этим свои классы и выстраивать чего-то своего какие-то куски там можно использовать. Здесь если что jar-файл, он в несколько тысяч раз меньше первого, но там придётся прописывать в "start.bat" путь к папке "java\bin".
Но не думаю что кому-то понадобится выходить за рамки минимума функциональности этой программы, там просто можно полистать комбинации фигур для заполнения полей, отсортированные по группам симметрии - то есть в порядке убывания повторяемости в комбинации одинаковых фигур. Остальная часть функциональности крутит движок игры (да и то не доделанный толком), для которой я установил "правила по умолчанию". Игра по таким правилам не отличается динамичностью (я бы даже сказал что это последнее что о ней можно сказать), и её стратегия сводится к "голой комбинаторике", исключающей случайные события и направленной на решение вопроса "существует ли при таких правилах игры хоть один способ сложить этот пасьянс". Я более склонен отрицательно отвечать на этот вопрос, но там есть пара нюансов, с помощью которых можно расширить игровые возможности. При составлении "правил по умолчанию" главный упор я делал на минимальных информационных затратах, и дальнейшим хотел выяснить вопрос о том, какие именно дополнительные опции там нужно включить или выключить, чтобы принципиальная возможность собрать этот пасьянс существовала, но количество способов его собрать стремилось бы к минимуму, в идеале (скорее всего недостижимом ввиду минимальности числа доступных для переключения опций) - к единице.
В общем где-то на этом месте у меня мысля остановилась, и для того чтобы с вашим или без участием её развить я собственно и решил создать эту тему.
Алгоритм игры такой :
Вот в таком виде сейчас реализован игровой движок. Первым делом необходимо выбрать стартовую позицию, коих всего 531*968 ~ полмиллиона вариантов, из которых примерно восьмая часть непригодна к использованию, поскольку из 15-ти составляющих обе базовые комбинации фигур невозможно выбить ни одной из 67-ми целевых комбинаций - так что в эту игру можно проиграть не успев её начать. Но если рассматривать одно из базовых полей по отдельности, то для любой из 531/968 его комбинаций на втором поле всегда найдётся такая, что из 7+8=15-ти соответствующих фигур можно будет хоть что-то выбить - то есть заведомо лишних комбинаций там нет (минимум пригодных для выбивания сочетаний из 15-ти фигур зарегистрирован для комбинации из пяти ромбов - 96 из 514008, ну и вообще комбинации "пятерного" поля в этом отношении "самые несговорчивые"). В общем есть тут свои плюсы и минусы, но всё-таки мне кажется что минусов больше - то есть при таких правилах собрать этот пасьянс невозможно. Об этом чуть подробней.
Согласно приведённому алгоритму цель игры состоит в том чтобы сделать множество целевых комбинаций пустым - то есть выбить их ровно 67, ни больше ни меньше. Выбить их больше запрещает отмеченный звёздочкой последний пункт второго шага, и если его отменить, то появится возможность повторного выбивания целевых комбинаций. По всей видимости придётся так и сделать - так и правила станут короче, и появится возможность использовать эти комбинации для удаления с базовых полей мешающих фигур. Ну например в игре становится актуальным вопрос о том куда девать наименее востребованные "широкие параллелограммы", которых в базовых комбинациях пруд пруди, а для выбивания целевых их требуется всего 5 штук (есть и другие "маловостребованные и частомелькающие" фигуры - см. таблицу). В общем одну опцию похоже что придётся убрать, и в таком виде правила этого пасьянса будут пожалуй что наиболее компактными. Можно конечно гипотетически предположить, что при столь жёстких ограничениях найдётся хоть один из полумиллиона стартовых раскладов, для которого найдётся хоть один из астрономического числа вариантов выбивания всех 67-ми целевых комбинаций, но навскидку это весьма сомнительно.
Есть ещё один нюанс, который желательно было бы доработать в правилах, связанный с распределением показателя n для целевых полей : [4,4,5,6,6]. При отсутствии оговорок на повторное выбивание целевой комбинации без обновления базовых полей (см. третье действие третьего шага алгоритма) список целевых комбинаций первых двух полей можно объединить в один (и то же самое относится к двум последним), поскольку с точки зрения возможности эти комбинации выбить все они представляют из себя "разные множества из n фигур", и в силу равенства этого n для двух полей информация о том что их целевые комбинации принадлежат разным полям не имеет в игре никакого значения. Для того чтобы эта информация стала значимой (то есть для того чтобы разнесение этих комбинаций по разным полям было не просто формальностью), придётся добавлять к правилам новую опцию. По принципу "наименьшей лукавости мудрствования" я добавляю к правилам "запрет на повторное использование целевого поля до обновления обоих базовых". Это означает, что как только выбивается целевая комбинация, поле которому она принадлежит становится временно недоступным, а как только текущие ресурсы обновляются до 15-ти фигур, все целевые поля восстанавливаются. Включение этой опции несколько сужает игровые возможности, но в сравнении с расширением возможностей после отключения опции "удалять выбитые комбинации из списка доступных данному целевому полю" этим ограничением можно пренебречь. Зато теперь информация о принадлежности "четверных" и "шестерных" целевых комбинаций к разным полям становится значимой, а не так, "для мебели".
Тем не менее, далеко не факт что удаление из алгоритма "пункта 2.3" обеспечит возможность достижения цели игры, даже если отключить вторую из рассмотренных опций : 32.6 базовых фигуры в среднем на одну целевую выглядят конечно обнадёживающе, но слишком уж в узких рамках приходится держаться при выбивании целевых комбинаций - например ни одна из 10-ти комбинаций среднего ("пятерного") поля не выбивается ни из одной базовой комбинации, взятой по отдельности (то есть без участия фигур второго базового поля). Если и при таких правилах игра непроходима, придётся расширять возможности другим способом - например разрешить перекладывание фигур между базовыми полями. Включение этой опции даст ещё больше возможностей чем отключение первой, и тогда возможно первую придётся включить для сведения к минимуму количества способов собрать этот ребус.
Думаю что трёх перечисленных опций вполне хватит для того чтобы из восьми определённых ими сочетаний можно было выбрать оптимальный вариант правил. В порядке рабочий гипотезы я бы предложил следующий :
Проверять эту гипотезу я вряд ли стану - там придётся комбинаторику прикручивать с элементами ИИ, который бы сортировал доступные варианты хода в порядке убывания показателя их оптимальности, потом долго возиться раскладывая этот пасьянс и вникая в детали, на что я уже вряд ли сподоблюсь. На уровне же предварительных теоретических соображений думаю что этой информацией можно ограничиться, а вариант с "пасьянсом" я привёл больше для проформы и дальше его раскапывать не планировал.
На этом думаю тему можно закрывать, вряд ли здесь у кого-то возникнет желание чем-то её дополнить.
Скачал,загрузил в netbeans из под Debian....для начала ругнулся,
1)пришлось прописывать абсолютный путь для файла variants.txt ,если делать правильно,т.е.распространять прогу в jar файле, необходимо для таких файлов определять файл ресурсов в сети есть информация,как сделать правильно.
2)Вы используете библиотеку awt,а почему не swing?Можно было бы задействовать мышь,использовать drag and drop,вращать базовые элементы,пробуя состыковать один с другим.При этом игровое поле ,было бы одним общим ,а фигурки ,которые можно получить(то что у вас под номерами 12..8) были бы в задании.Можно усложнять игру создавая фигурки ,каких-то зверушек и т.д.
3)Сама игра у меня не пошла.Вернее загрузился frame Face слушатель клавиатуры ,половины key не видит.Просто демонстрирует ваши заготовки pic.
4)Пробую разобраться дальше.Тяжело без комментариев,хотя бы к классам и основным методам.Интуитивно по идентификаторам не совсем понятно,особенно в деталях реализации интерфейсов .Признаюсь,сам никогда комментариев тоже не писал,казалось ,что всё яснее ясного.Многие свои программы,сейчас не понимаю,приходится тратит кучу времени на то ,чтобы понять то,что сам когда-то написал...парадокс.Может конечно ,потому,что сам не занимаюсь профессиональным программированием,скорее хобби,больше люблю ситсему ,Linux,системные утилиты и т.д.
Когда-то мне всё это уже приходилось делать - лет десять назад портировал игрушки для мобильников. Попробую освежить в памяти...
Вот уже вражеская идеология - так с наскоку не удалось "зажарить" проект, похоже с ресурсами действительно придётся решать вопрос отдельно. Java она конечно удобна для разработки неприхотливых графических приложений, но когда узнаёшь о том какой ценой это удобство достигается, становится трудно удержаться от матов. Короче надо подробнее разбираться.
Потому что для рисования треугольников не требуется привлечения каких-то специфических графических возможностей.
В этом нет смысла, поскольку при вращении всё равно требуется преобразование данных, представленных во внутреннем формате, после чего всё сводится к перерисовке всё тех же треугольников. А вручную там ничего вращать не нужно - все варианты хода просчитываются автоматически и остаётся лишь выбрать нужный. Поэтому я намеренно отключил мышь, там в ней нет особой надобности.
Роль этих "зверушек" выполняют поля, предназначенные для заполнения, и за рамки этой концепции я пока не собирался выходить, сводя цель игры к раскладыванию пасьянса, правила которого описал выше.
Скорее всего проблема возникает из-за ненахождения файла "variants.txt" (тщательно спрятанном мною в корневой папке проекта), без которого выполнение программы и не должно продвинуться дальше создания фрейма. Попытаюсь её решить, если конечно для этого не потребуется сутки гугл штудировать.
Да, мне этот "парадокс" хорошо знаком, поэтому мне проще с нуля программы создавать, чем копаться в уже готовых, пусть даже своих, а настолько ёмких проектов, когда этот вопрос становится актуальным, мне ещё не приходилось клепать. Были бы хоть названия функций "говорящими", но я и здесь привык экономить символы. В общем согласен с тем что оформление исходников не способствует их повторному использованию, разве что несколько полезных функций выдрать чтобы по новой их не писать, если клепать по мотивам этой темы что-нибудь своё.
Да, никсы конечно не идут ни в какое в сравнение с виндой, но поскольку я не использую компьютер для решения серьёзных задач, то и не заморачиваюсь по поводу выбора оси - привык уже как-то к этой "Windows", поэтому кроме мультизагрузки осей или виртуальной машины пока к сожалению ничего не могу предложить. Если получится сделать рабочий jar, скину на файлообменник.
Я решил эту проблему следующим образом.В классе Game в конструкторе прописал абсолютный путь до variants.txt введя переменную str
Game() {
BufferedReader br = null;
String str="/home/ser/source_file/tetrian/variants.txt";
try {
FileInputStream fstream = new FileInputStream(str);ame() {
BufferedReader br = null;
String str="/home/mikl/source_file/tetrian/variants.txt";
try {
FileInputStream fstream = new FileInputStream(str);
а вот в классе Face
addKeyListener(new KeyAdapter() {
public void keyPressed(KeyEvent e) {
int key = e.getKeyCode(), activ = engine.activ;
if (key==113) engine.info = "saved";
System.out.println("pressed key with cod "+key);
вы подключаете анонимного слушателя и в его методе у вас всё управление пасьянсом и крутиться,Я расскоментировал System.out.println("pressed key with cod "+key);
пытаюсь разобраться на соответствие кодов клавиш..но пока оставил эту работу,появилась другая более спешная...а так любопытно...обязательно разберусь...правда к jave .год точно не прикасался,забывается всё моментально,поэтому и посетовал на отсутствие комментариев...
Вроде удалось "зажарить", не прибегая к использованию каких-то специфических приёмов - ссылка. Если не затруднит, проверьте пожалуйста запустится программа в таком виде или нет (у меня под XP всё работает, достаточно только прописать в "start.bat" путь к java\bin).
А вообще, если любите программированием баловаться на досуге, то я бы порекламендовал Вам язык D, если конечно уже им не пользуетесь. По моим строгим критериям С++ явно недоработан, а в D все эти дырки довольно плотно заделаны - по крайней мере на базовом уровне воплощения идеи ООП. Мне так понравилось на нём программировать, что даже не хотелось его портить прикручиванием каких-то сторонних GUI-ёв, поэтому когда к "голой комбинаторике" мне потребовался графический интерфейс, я вспомнил об "отдыхающей в сторонке яве", на которой мне как-то привычнее игрушки делать, так что пришлось все основные функции перегнать с D на Jav-у. Вот тогда я почувствовал разницу, матерясь на каждом шагу - ну типа выражение "a += b>0" интерпретируется явой как "опасная операция", которую типа для пущей надёжности программы лучше выполнять через "if". С++ хоть и не позволяет себе таких безобразий, но тем не менее обнаруживает довольно серьёзные недоработки на базовом уровне реализации, которые в D на мой взгляд все и около того устранены.