Как реализовать игровую логику на примере данного приложения?

Question

[levedun]

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

Comments

[pavel null]

Не понятно, что именно вы хотите сделать ? Бота для складывания или логику игры?

[levedun]

Не бота, складывает сам человек. Вращает объекты, не передвигает. А логика определит есть ли энергия в правильно сложенных объектах. .. Представьте в реальной жизни как. По проводам идет ток..но если провод допустим оборвать посередине, то в первой половине ,где есть источник энергии ток останется в другой половине его не будет. Вот логика как это все проверить. Я сделал пример но он ограничен на +1 позицию..то есть если обрываю провод то во второй части "энергия" остается. Мозг сломал уже, настроения никакого..

Answer 1

[Espleth]

Не совсем понимаю, а что тут особо сложного? Что-то типа простенькой задачи на графах. У каждой ячейки поля есть свойства: bool - есть ли в ней провод (или string/int, если может быть не только провод, но и еще что-то, например лампа), и еще 4 bool соответствующие сторонам (вверх, вниз, влево, вправо), по которым становится понятно, куда выходит провод. при каждом обновлении игры (обновлении в плане поворота провода или что-то типа того) в лоб идти по всем источникам питания по очереди и смотреть, выходят ли на лампу провода от нее. Если выходят - зажигать ее. С ходу мне чем то напомнило алгоритм Прима. Хотя тут совсем другое, но что-то общее в них определенно есть, а именно мне так кажется рекурсивная функция для прохода всех вариантов тут будет функцию для проверки на наличие зацикливаний в том алгоритме

Comments

[levedun]

Вот и проблема была в том чтобы идти по всем источникам питания и проверять. Спасибо проверю алгоритм Прима. Реализовать то реализовал как вы выше писали. У меня каждый объект имеет свой идентификатор, значение поворота. Значение зон контактов и значение активности. Получалось как. Вращаю объект. Записываю его позицию,т.е поворот. и проверяю относительно типа объекта и типа позиции с чем он контачит. Если область контакта равна определенной позиции определенного объекта и при этом данный объект активен, то повернутый объект тоже делаю активным. И так далее. Но при этом обновление происходит после нажатия. Проверял по двойному циклу for . Который показал что непрпавильно все организовано. Т.е он считывает все по порядку х и у. А тут его нет. Нужна альтернатива. Может Прим поможет.

[Макс]

Почему вы так сильно любите bool и игнорируете enum? :)

[levedun]

От отсутствия знаний видимо)

[Espleth]

levedun: В общем да, думаю лучше всего делать рекурсивную функцию, которая будет перебирать все дороги. То есть идет рекурсивная функция, выбирает дорогу, и так доходит до конца (отслеживая уже пройденные точки, это важно, иначе прога зациклится), потом если в конце лампа, то зажигает ее, если нет возвращается на несколько ступенек рекурсии назад, пока не дойдет до развилки, и так пока все варианты не кончатся, рекурсия вернется в самый первый вызов и завершится. Должно получиться изящно и просто, с возможностями для оптимизации (которая скорее всего и не понадобится даже на слабых устройствах, правда)
mbelskiy: Потому что первое, что пришло в голову. Да и enum я использовал только в c# и c++, про то, есть ли он на других языках - не знаю.

[Espleth]

levedun: кстати, еще один алгоритм пришел в голову, наверное он даже проще будет, итеративным:
в начале хода обнуляем электричество во всех проводах. Наверняка можно и без этого, но мне лень думать =)
в цикле: проходим по всем элементам массива. если у элемента массива есть электричество, смотрим 4 элемента вокруг него. если к ним можно проложить электричество, то прокладываем. Помечаем этот элемент как использованный, чтобы больше не смотреть на него в этом ходу. и так для всех элементов.
повторяем цикл, пока будет хотя бы 1 элемент, который получил электричество в последнем проходе цикла
Если говорить о скорости, то мне кажется такой алгоритм будет работать быстрее в случаях, когда будет куча источников питания и разных проводов, но медленнее рекурсивного, когда источников питания мало, а дорогу преодолевать току большую.

[levedun]

Артем: спасибо за ответы, есть над чем подумать))

Answer 2

[Sergey Lerg]

Всё просто. У вас есть 2d массив - карта поля. В каждой ячейке хранится объект - лампа, батарея, провод. У проводов есть свойство - четыре переменные проводимости: left, right, up, down. Какая из них true - значит в ту сторону есть соединение.
Далее создаёте второй 2d массив - карта электричества, размер такой же, но в каждой ячейке значение true/false - есть электричество или нет электричества.
Теперь ваша задача в том, чтобы, начиная от батарей, заполнить карту электричества согласно проводам.
Как только это сделано, смотрите на ваши лампы, смотрите куда у них идёт контакт, есть ли у той ячейки электричество и есть ли соединение с этой ячейкой.

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

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

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

Comments

[levedun]

Спасибо, о чем то нечтом и думал, знаний не хватает. Уместно ли здесь использование enum ,как выше писали , или оно категорически обязательно?)

[Sergey Lerg]

levedun: не принципиально. С Enum будет элегантнее, но алгоритм прекрасно можно сделать и без них.

[levedun]

Sergey Lerg: еще небольшой вопрос "Для этого в цикле обрабатываете каждую батарею: начинаете с позиции батареи присваивать true в карту электричества, идёте по карте по направлению проводов," Каким это циклом организовывать ? Вот есть позиция батареи, я проверю совпадения положений провода и дальше должен буду передать проверку проводу...мне кажется или это похоже на goto ,т.е переход проверки условия уже с новыми значениями(сделав провод батареей) . Как почитал goto в jave нет. Есть продолжение с помощью continue ...куда копать то =) Или в рекурсию. Чтобы метод сам себя вызывал..

[Sergey Lerg]

levedun: цикл for по всем батареям, а внутри рекурсивная функция обхода карты по проводам. Батарею, кстати, тоже можно на провод заменить при проходе карты.

[levedun]

Sergey Lerg: Примерно так?
Запускаю цикл проверки 2д массива объектов посредством for. (перед этим обнулив значения активных элементов.) Расчет идет строго по х и у.
(использую от 1 до 4 потому что контакты объектов заходят за поле видимости еще) (от 0 да 3 выдает ошибку, да это не так важно в принципе)
for(int dx=1 ;dx< 4 ;dx++)
for(int dy=1 ;dy< 4 ;dy++)
{....}

Если найденный объект==батарее выполняю рекурсию по проводам.

При любом изменении положении объекта обнуляю данные запускаю поиск батареи с включенной рекурсией.
Т.е прописываю вызов данной функции 2 раза . при запуске и при нажатии на объект

Похожу основная моя задача собрать рекурсию...

[Sergey Lerg]

levedun: можно так, да. Я бы держал в памяти массив со всеми батареями и всегда знал бы их положение x, y на поле. При перемещении батареи - обновлял бы этот массив.
В интернете примеров рекурсивного обхода 2d карт достаточно - разберётесь.