Pull to refresh

Comments 26

А зачем для поиска линий перебирать всё поле? Достаточно взять только те фишки, которые изменили своё положение, и проверить вверх/вниз/в стороны от них.
Для случая «поменяли две фишки местами» проверка будет проведена только для двух фишек, для случая «проверям, не образовали ли упавшие фишки новые линии» будет, разумеется, больше, но всё равно несравнимо меньше, чем полный перебор.
Спасибо за советы, они помогут улучшить и оптимизировать этот алгоритм. Просто напомню, я не создавал урок, я его всего лишь перевел.

В любом случае, полный перебор нужен в самом начале. Плюс, если мы хотим делать подсказки, придется полностью перебирать. Иначе все это придется хранить отдельно и в конце концов будет легче плюнуть на все и провести полный перебор.
С удовольствием принимаются любые коменты по поводу улучшения алгоритма, ведь я именно для этого и перевел статью. Чтоб каждый желающий мог для себя понять механику мач-3, обработать ее и запилить свою с «блекджеком и шлюхами».
Мне кажется вы не такой человек, который получает удовольствие от произношения фразы «с блекджеком и шлюхами»:))
Спасибо, вы в общем-то правы) Иворачиваюсь, чтоб было понятно всем, что я имел в виду.
Хотя тут скорее пункт 2, но тем не менее.
Да, тут именно второй пункт. Дело в том, что когда я публиковал эту статью в личном блоге и нашем сообществе, у меня не было достаточно к-пунктов для опубликования здесь профильного топика. Каюсь. Но, тем не менее, мне очень хотелось донести этот перевод до всех желающих. Больше мнение, больше обсуждения, больше пользы для алгоритма.
Главное, что можно отвлечься от Flash-платформы, понять для себя механику и сделать свой мач-3 на любой удобной вам платформе.
За проделанную работу плюс несомненно, но если не секрет почему вы выбрали Flash?
Я про вступление.
Спасибо. Я уже ответил коментарием выше что можно отвлечься от Flash-платформы, понять для себя механику и сделать свой мач-3 на любой удобной вам платформе.
Мне интересно почему лично вы решили сейчас стать FlashGame-разработчиком.
До этого пробовал на вкус XNA, UDK, Delphi в связке с OpenGl и DirectX. То ли не хватило терпения, то ли лень победила (что более вероятно), но ничего особого я не выдал. И прошлой осенью решил заняться чем-то серьезно, т.к. в планах переезд в другую страну. И так совпало, что прочитал в сентябре статью в Хакере. Здесь она на сайте автора. Ну и решил попробовать, а почему бы не Flash. Сейчас в моем личном блоге можно проследить небольшой путь становления).
Теперь конкретно, почему Flash. Сейчас Flash стал для меня инструментом воплощения детской мечты, потому что игры писать хотелось с самого раннего детства, а как это делать, не знал. Но, после почти года работы с Flash и ActionScript, могу сказать уверенно одно. Если вы знакомы с принципами ООП любого языка, хорошо им владеете, вам не составит труда за короткое время освоить синтаксис любого другого смежного языка и начать на нем разработку. Я не работал с Java и с Objective-C, но думаю, что если вы сделали пару толковых игр на Flash, если вы серьезно настроенный программист, вы без проблем можете начать разработку под Android и i-платформу. (Главное решить, нужно ли оно вам)
Как делал я. Вместо того, чтобы делать двумерный массив для шариков, я решил сделать одномерный. У каждого шарика сделал 4 указателя на соседей. Примерно таким вот образом:



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

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



при этой схеме легко масштабируется, например, на шестиугольное поле, как например Здесь
А нет проблем на проверку больше чем 3 последовательностей?
Хотя, в принципе понятно, вы находите последовательность-3 и начинаете опрашивать крайние фишки в последовательности. Я прав?
имеется в виду для последовательности более чем из 3-х шариков? нет. Схема примерно такая: в цикле пробегаем по всем шарикам, каждый шарик опрашивает соседей. Если соседей того же цвета больше 3-х в одном ряду, то шарик помечается как желающий погибнуть.
Следующей функцией все шарики, желающие погибнуть, переносятся наверх в своем ряду, и меняют свой цвет на случайный.
Хотя тут возникает проблема с определением количества шариков в последовательности, но она мной тоже как-то решалась :-)
Вот-вот, я сейчас сижу все это и обдумываю. Мне кажется в пределах 1-мерного массива это довольно запутанно. Не то чтобы невозможно, но и не очень просто.
Да ладно Вы… Я сижу и обдумываю, чем я руководствовался, когда придумал такой принцип. Хотя когда год назад писал, все казалось очень правильно и логично :-).
видео с собственно игрой: www.youtube.com/watch?v=ZbTd8v_Dvcc
Хотя тут как раз видно, что по отдельности последовательности не обрабатываются
Ха-ха, вот видите, никогда не поздно улучшить алгоритм. Веселый зоопарк у вас там в игрушке.
Тем более эта механика, ведь не претендует на оригинальность.
Я вспомнил как последовательности определялись в одной из версий, где они должны были по отдельности быть! Там рекурсия :-). Механика скорее претендует на банальность. Наверное самая заезженная в казуальном игрострое.
Да я вообще-то имел в виду механику в топике )
Sign up to leave a comment.

Articles